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

[Tim Panton <[e-mail]>]

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

> 2011/9/15 Matthew Kaufman <[e-mail]>:
>> 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.

Tim.