Re: [rtcweb] Another consideration about signaling

Iñaki Baz Castillo <> Tue, 11 October 2011 07:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C3B4221F861E for <>; Tue, 11 Oct 2011 00:41:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id L6-E1VAoU8my for <>; Tue, 11 Oct 2011 00:41:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3918421F8B8E for <>; Tue, 11 Oct 2011 00:41:09 -0700 (PDT)
Received: by vcbfo11 with SMTP id fo11so6522097vcb.31 for <>; Tue, 11 Oct 2011 00:41:09 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id et7mr17239844vdc.35.1318318869351; Tue, 11 Oct 2011 00:41:09 -0700 (PDT)
Received: by with HTTP; Tue, 11 Oct 2011 00:41:09 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
Date: Tue, 11 Oct 2011 09:41:09 +0200
Message-ID: <>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <>
To: Ted Hardie <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [rtcweb] Another consideration about signaling
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Oct 2011 07:41:12 -0000

2011/10/10 Ted Hardie <>om>:
> If you believe that each RTCWeb Javascript/server pair needs to implement an
> SDP-based offer/answer protocol, but that it may choose among different
> syntaxes for carrying the SDP, then I think you're a lot closer to what I
> would call "having standard signaling" than not.

Hi Ted, alice from her browser can only establish a media session with
bob if both visit the same website so they already share the same JS
code dictaminating the signaling protocol to use (which can be SIP, or
XMPP or some custom JSON based protocol).

I just said that, regardless the chosen signaling protocol, such
protocol would require some way to send and receive a SDP (or
something that looks an SDP), so the JS API for dealing with media in
a RTCweb capable browser will deal, at the end, with SDP's. IMHO
that's obvious.

But of course, depending on the chosen protocol, it could be simpler
(don't allow parallel forking, don't allow renegotiation of the media
after a call is established...) or complex (building a full SIP
implementation). That's up to the site admin.

I'n not speaking about a "standard signaling", not at all.

>   That could be described
> in a document in pseudo-code which could be translated to JSON structures or
> whatever the current flavor of the month is easily enough.  Because each
> offer/answer protocol had to support the same basic things the requirements
> on the Javascript/Browser API go down to a common core, which is far easier
> to get.
> I personally would describe that in some existing offer/answer protocol,
> just for clarity, but, as I said, that is largely a matter of taste.

Sure. Taking a working signaling protocol to build the RTCweb JS API
on top of that is a good idea since we can find the requirements for
such API.

Iñaki Baz Castillo