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

Iñaki Baz Castillo <> Thu, 15 September 2011 10:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 28EE121F84DC for <>; Thu, 15 Sep 2011 03:47:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.65
X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[AWL=0.027, 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 4qPrZC-vhDwk for <>; Thu, 15 Sep 2011 03:47:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8CEA821F84D9 for <>; Thu, 15 Sep 2011 03:47:17 -0700 (PDT)
Received: by qyk32 with SMTP id 32so4862896qyk.10 for <>; Thu, 15 Sep 2011 03:49:28 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id r20mr791209qci.64.1316083768677; Thu, 15 Sep 2011 03:49:28 -0700 (PDT)
Received: by with HTTP; Thu, 15 Sep 2011 03:49:28 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Thu, 15 Sep 2011 12:49:28 +0200
Message-ID: <>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <>
To: Matthew Kaufman <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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 10:47:18 -0000

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

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


Iñaki Baz Castillo