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

[Iñaki Baz Castillo <[e-mail]>]

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.


-- 
Iñaki Baz Castillo
<[e-mail]>