Re: [rtcweb] About defining a signaling protocol for WebRTC (or not)

Tim Panton <> Thu, 15 September 2011 11:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 43BDC21F8A66 for <>; Thu, 15 Sep 2011 04:47:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.417
X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rI6r8e5Fnxe8 for <>; Thu, 15 Sep 2011 04:47:42 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 95BD821F8A35 for <>; Thu, 15 Sep 2011 04:47:42 -0700 (PDT)
Received: from [] (unknown []) by (Postfix) with ESMTP id 481A837A902; Thu, 15 Sep 2011 13:02:44 +0100 (BST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: Tim Panton <>
In-Reply-To: <>
Date: Thu, 15 Sep 2011 12:49:48 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= <>
X-Mailer: Apple Mail (2.1084)
Subject: Re: [rtcweb] About defining a signaling protocol for WebRTC (or not)
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: Thu, 15 Sep 2011 11:47:43 -0000

On 15 Sep 2011, at 11:49, Iñaki Baz Castillo wrote:

> 2011/9/15 Matthew Kaufman <>et>:
>> On 9/14/11 4:56 PM, Iñaki Baz Castillo wrote:
>>> So my proposal is that WebRTC should not mandate a signaling protocol
>>> in the web-browser, but just define a requeriment for managing
>>> multimedia sessions from the JavaScript code given a well defined API.
>> I think this is exactly what I've been advocating, so I agree as well.
>> I'd go one step further to say that the "well defined API" shouldn't be "SDP
>> offer/answer via events" for negotiating codec parameters, but should
>> instead be a way to manage the codec settings, with offer/answer or capneg
>> or whatever you want implemented in the Javascript (or up at the server,
>> your choice).
> Hi Matthew,
> You mean a way to simplify the "SDP management" from the JavaScript
> code, am I right?
> The web-browser JavaScript stack could include a native library to
> parse a SDP body (maybe plain SDP as defined in RFC 4566 and also the
> XML version used in XMPP/Jingle) so it returns some kind of JS
> struct/object describing the peer-requested streams (something easier
> than full understanding of SDP).
> An also another native JS function to generate a SDP (plain or XML)
> given some arguments (enable-audio, enable-video, and so on) to be
> included in a custom signaling message (which could also be SIP or
> XMPP).
> Also functions for adding/modifying/deleting a stream, and callbacks
> for the case in which the remote puts on hold a specific stream,
> adds/modifies/deletes a stream...
> This is: make an API that exposes SDP capabilities without requiring
> understanding of the complex RFC 4566 (SDP).
> Regards.

Are we saying that SDP is so impossible to parse that the only way to do it 
is with a pre-existing native library ?!? If not I think we can do that transformation 
(when needed) in JavaScript.