Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB applications

Iñaki Baz Castillo <> Sat, 15 October 2011 08:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 330C421F8B30 for <>; Sat, 15 Oct 2011 01:43:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.571
X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.106, 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 zRIZLao3td+9 for <>; Sat, 15 Oct 2011 01:43:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7469421F8ACE for <>; Sat, 15 Oct 2011 01:43:38 -0700 (PDT)
Received: by vcbfo1 with SMTP id fo1so1890016vcb.31 for <>; Sat, 15 Oct 2011 01:43:38 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id ci11mr964817vcb.76.1318668217880; Sat, 15 Oct 2011 01:43:37 -0700 (PDT)
Received: by with HTTP; Sat, 15 Oct 2011 01:43:37 -0700 (PDT)
In-Reply-To: <>
References: <AAE428925197FE46A5F94ED6643478FEA925614C6A@HE111644.EMEA1.CDS.T-INTERNAL.COM> <> <> <> <> <> <> <> <>
Date: Sat, 15 Oct 2011 10:43:37 +0200
Message-ID: <>
From: Iñaki Baz Castillo <>
To: Ted Hardie <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "<>" <>
Subject: Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB applications
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: Sat, 15 Oct 2011 08:43:39 -0000

2011/10/15 Ted Hardie <>:
> On Fri, Oct 14, 2011 at 2:41 PM, Iñaki Baz Castillo
>> IMHO RTCweb (specially the JS API for managing media sessions) must be
>> designed in a way that it's possible for a developer to implement a
>> SIP client in JavaScript or another custom signaling protocol having a
>> gateway that maps it to/from SIP. This means that SIP features as
>> parallel forking, early media, conference... should be possible using
>> the RTCweb JavaScript API.
> Do you think you could support SIP identity with a javascript client?

Yes. The spec (RFC 4474) does NOT mandate that the SIP client MUST to
have a list of CA's and verify the retrieved certificate by itself. A
JavaScript client receiving an incoming INVITE with Identity and
Identity-Info header could make a webservice call (i.e. using AJAX)
and ask its web server to retrieve it and verify it in behalf of the
client. And still that is SIP.

So yes, I could support SIP Indentity with a JavaScript client.

>> So, assuming that there MUST NOT exist a *standard* signaling protocol
>> for federation in RTCweb, what is the purpose of speaking about
>> "federation"?
> I don't think RFC 2119 MUST NOTs belong here.
> Understanding federation as a use case does not mandate a "one ring to rule
> them all" approach to federation.  We could define one (as XMPP defines how
> different XMPP servers pass traffic among themselves).  That would not
> mandate that all servers use it.  We could also choose not to define one,
> but if we support the use case, we would have to understand what the minimal
> set of data that had to be pass over the protocols implementing the
> federation would be, what security is required, and so on.

So just imagine that SIP is used for federation and make the
requirements assuming that.

>> Probably we all are speaking about the same concept, but
>> for me "federation" means a RTCweb server communicating with other
>> RTCweb server. If Hadriel and you meant "RTCweb server communicating
>> with a SIP network" then I repeat my first paragraph :)
>> So in order to accomplish with requirements of Hadriel we need to make
>> the RTCweb client stack and the RTCweb JavaScript API flexible enough
>> so all (or most of) the SIP features can be implemented in JavaScript
>> (I mean "audio/video features" since all the signaling can already be
>> coded in different ways).
>> Hope it's more clear now.
> Well, given that you don't believe in the need for a protocol here at all,

A protocol is needed, of course. But not a *specific* protocol.

> but only an incredibly flexible API, it seems a bit unclear why you're not
> making these points on the W3C public mailing list for this activity.

I expect such work must come once the requirements for such API are
done in this WG.

> A truly well structured API here will imply, at least in my view, at least a
> common model for negotiation and a common set of structured data to be
> passed via this javascript-implemented protocol.  Doing that without
> defining a standard protocol is actually harder than doing it while defining
> a protocol.
> I've heard the various arguments against defining one, but none of them
> seems to stand up against the base fact that you can have a standard
> protocol--known to be available--without restricting the ability to create
> proprietary protocols using the same API.

There have been lot of arguments contrary to defining a "default
signaling protocol". I don't want to repeat them again, but neither
answer as if they don't exist.


Iñaki Baz Castillo