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

Ted Hardie <> Fri, 14 October 2011 22:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E4BC221F8C22 for <>; Fri, 14 Oct 2011 15:42:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.765
X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id V0OZwYph7IMI for <>; Fri, 14 Oct 2011 15:42:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 173FE21F8C0E for <>; Fri, 14 Oct 2011 15:41:58 -0700 (PDT)
Received: by ggnk3 with SMTP id k3so1860910ggn.31 for <>; Fri, 14 Oct 2011 15:41:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2K71qB6XZBrAcgfnZlnO2oW9oQARm2H4pyBlyTRJRhk=; b=xH4yRkgUN28e0cXirD0VuuqRjno79WFmn2iHpVPp3RcvgT0HNfXv5tXCI1K2F71abI jFlLvuyDTOHhW4gZL1f8zuD5FqxvgEQ3iJeL54NGJnFfWEJojTLtVjYKjQJ6Yg5+VX1f UxYgJX96mI881HbSGAc1fJOAEzFypTLxDAe0c=
MIME-Version: 1.0
Received: by with SMTP id x24mr14902865yhm.74.1318632117558; Fri, 14 Oct 2011 15:41:57 -0700 (PDT)
Received: by with HTTP; Fri, 14 Oct 2011 15:41:57 -0700 (PDT)
In-Reply-To: <>
References: <AAE428925197FE46A5F94ED6643478FEA925614C6A@HE111644.EMEA1.CDS.T-INTERNAL.COM> <> <> <> <> <> <> <>
Date: Fri, 14 Oct 2011 15:41:57 -0700
Message-ID: <>
From: Ted Hardie <>
To: Iñaki Baz Castillo <>
Content-Type: multipart/alternative; boundary="20cf303dd9d0f4db8f04af49f647"
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: Fri, 14 Oct 2011 22:42:01 -0000

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?

> 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.

> 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,
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.

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.