RE: JavaScript API on top of SDP

I think that the group has always known/assumed that we would need to specify what SDP features are supported, what can be modified, etc.  Maybe I've missed something, but I haven't heard anyone say that this wasn't necessary.   It's just that we haven't gotten around to it yet.


-          Jim

From: Roman Shpount [mailto:roman@telurix.com]
Sent: Monday, July 15, 2013 11:59 AM
To: Jim Barnett
Cc: public-webrtc@w3.org
Subject: Re: JavaScript API on top of SDP


On Mon, Jul 15, 2013 at 10:06 AM, Jim Barnett <Jim.Barnett@genesyslab.com<mailto: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.

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