Re: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface

[Robin Raymond <[e-mail]>]

+1 on object model with a "toSDP / fromSDP"  (FYI - an object model 
draft is looming shortly)

I think it's best to put "toSDP / fromSDP" outside the browser binary as 
a common github JS library because I know a lot of SIP folks love custom 
SDP extensions and being able to fork/tweak the SDP without petitioning 
the browser vendors for an "update" is important.

-Robin

> Binod <mailto:[e-mail]>
> 4 July, 2013 5:10 AM
> On Thursday 04 July 2013 01:51 PM, Iñaki Baz Castillo wrote:
>> 2013/7/4 Eric Rescorla <[e-mail]>:
>>> Looking back at your posts from back then, I see you did in fact 
>>> suggest
>>> a set of API modifications that would have included an abstract session
>>> description. That would in fact have made Jingle somewhat (though not
>>> really that much) easier. So my last sentence here is unfair. My 
>>> apologies.
>> Initially I though that SessionDescription was a powerful JS Object
>> with all the fields and attributes to construct a SDP, so a developer
>> could extract those media/transport fields and create a SDP via JS. At
>> the same time, the SessionDescription object would include helper
>> methods (defined by the WebRTC API) to build a plain SDP (i.e. toSDP)
>> and some others like XML-SDP (i.e. toXMLSDP).
> I like that approach. Have an API to specify all/most of what is
> in the SDP and then use a toSDP to generate actual SDP string to be sent
> across the wire.
>
> Other side should be able to reconstruct the browser side
> object(s) using the received SDP string.
>
> thanks,
> Binod.