Re: JavaScript API on top of SDP

On Jul 15, 2013, at 9:58 AM, Roman Shpount <roman@telurix.com> wrote:

> 
> On Mon, Jul 15, 2013 at 10:06 AM, Jim Barnett <Jim.Barnett@genesyslab.com> wrote:
> We could add an object-oriented API that defined a javascript structure representing the SDP.  Developers could modify the structure using JavaScript, rather than having to parse it themselves.  Given such a JS structure, it would be easy to serialize it as JSON, so developers wouldn't  need to touch the SDP directly.  But they would still have the option to do so, if they wanted to do something that the API didn't cover (and it would be up to us to decide how much the API covered.)
> 
> - Jim
> 
> 
> I think this API would be of very little use at best. The issue is that SDP in WebRTC is under-defined. Unless it is clearly specified what SDP features are supported, which portions of SDP can be modified and what these modifications mean, SDP does not present a valid API surface. It is possible to parse SDP and serialize it back from JavaScript. If you take a look at almost every WebRTC JavaScript library created so far, you would see that  practically each of them parses SDP. The problem is that SDP produced by the browser can change in a way that will render any code that relies on SDP data unoperational. For example, adding bundle will almost guarantee to break all current JavaScript code that deals with parsed SDP. Not the SDP parser, which will continue to work, but interpretation of this parsed data will no longer work and will need to be updated. Unless the meaning of each attribute and supported attribute values in SDP are defined somewhere, giving me a list of parsed attributes does not help me in any way.

This is just wrong. Code that parses SDP has to follow the relevant specs. People regularly make software that parses SDP and successful deals with changes to SDP that happen after that code was written. SDP is carefully designed to supper this. Yes some problems have come up but largely they have been resolved. 

I agree with Mathew on we need to full specify what you need to know what to implement in a browser. The drafts have a lot of that nailed down and sure there is a bit more to do.  There are things that are not defined in SDP that we are working on (such as simulcast) but you can see lots of it just work today. 


> 
> So, unless you are planning to propose an API that replaces SDP with a JavaScript object with a well defined set of methods, and by doing so clearly specify supported media description functionality, this new API will not help in any meaningful way. Furthermore, unless supported SDP is clearly defined or replaced by well defined API this specification could never become a complete standard.
> _____________
> Roman Shpount
>

Received on Wednesday, 24 July 2013 03:30:58 UTC