On Sep 15, 2011, at 9:09 AM, Harald Alvestrand wrote:

> The disadvantage of parsing to another structure (I am fond of JSON myself) is that one has to maintain a data definition for the format being parsed to, a defined transform between that and the "canonical SDP structure" has to be implemented in user space when one does SDP interoperability, both of those have to be updated for every SDP extension that someone defines somewhere, and one is still not free to define extensions on the non-SDP side if one still requires the ability to map them into SDP.
> 
> If one uses the "native" SDP format, which is the format in which every extension to the format gets documented, the browsers are the ones who *have* to parse it (although others are likely to).


Right so the above paragraphs get to the heart of the matter, methinks.  Ultimately we need W3C to define an API, and the API has to provide a means of learning RTP/media info from the browser and commanding the browser to perform certain things with RTP/media.  One could expose this API as a true data structure, or as a long string of tokens to be parsed/serialized back/forth.  If the latter, then the choices are basically JSON or SDP.  And SDP seems advantageous because it appears to be the least work for the simple use-cases, because the javascript could just copy back/forth the SDP between the browser and server.  In other words you're optimizing for the very simple use-cases, in exchange for making it more complicated for the advanced use-cases.  Right?

OK, that's a laudable goal.  And I recognize that the decision has basically already been made, and nothing's going to change it. 

But email's free... so for the sake of posterity (and email archiving) here're some reasons not to use SDP anyway:
1) Incorporating SDP and the offer/answer model into the Browser and W3C API inexorably ties the W3C to the IETF MMUSIC working group for all time.  So far, I had been going on the assumption the IETF would be defining what the RTP library had to do/expose, while W3C would define the API.  But if the API includes SDP offer/answer, that portion is the IETF's domain too, afaik.  Anything the W3C wants to do in the future for that has to go through the IETF, not just IANA. (right?)

2) This isn't just about JSON vs. SDP - it's about SDP *offer/answer*.  SDP offer/answer wasn't meant to be an API between an application and its RTP library - it's a *protocol* between applications.  One side-effect of this is it has historic state.  For example, if an SDP offer contains two media lines, and one media is removed, the number of SDP media lines don't reduce back to one - EVER.  So if PeerConnection.removeStream() is invoked, the Browser needs to remember there was that stream and signal it in SDP as disabled for all time, until PeerConnection is closed.  If addStream() is invoked later, it could/could-not re-use that same (disabled) media line, or add a new one.

As another example, if a new SDP offer is sent out in SIP and gets rejected with a 488, the session reverts to the previously agreed SDP state.  The Browser would therefore have to keep state of previous SDP and revert to it to handle this case.  For example, if my Javascript started with only an audio MediaStream in PeerConnection and later added a video MediaStream to it, the new SDP offer would contain two media lines - if the offer gets rejected with 488, how is that communicated to the Browser and what will the browser do?

3) You might well want information conveyed across that "API" that is not meant to be sent on the wire in SDP - things you don't want defined by IANA as SDP tokens.  For example, you may want to provide packet counts, jitter, latency, and other meta-information about individual RTP codecs.  Using JSON allows you to have data member variables which will not get serialized into SDP, but are purely for the javascript's use, while still within the referential tree structure of the media stream info.  Or they may be for sending to peers, but simply not for SDP. (like you could send the jitter/latency info through the signaling channel)

4) Obviously if the application as a whole needs to do SDP offer/answer, then *someone* will have to implement it correctly, including the state-related stuff.  It could be the browser or the javascript that do this.  Chrome may do a perfect job of that in the browser, afaik.  But there are other browser vendors, including niche ones such as Dolphin and Skyfire.  What are the odds they all get it right the first time?

So which would you rather have updating an SDP engine, if one is even needed... or updating "every SDP extension that someone defines somewhere": the javascript which is written by the developer that knows what they want when they want it, and can update their code by updating their javascript (or not if they don't need to); or the browsers which are written by companies not under the javascript developer's control, at a time of the browser companies' choosing? 

Obviously for some things the browser will have to be updated regardless, for example to understand rather than just ignore new JSON entries, to provide new codecs, etc.  But not all new SDP attributes require changes in the media plane, nor encoding into JSON.  In fact, a lot doesn't - some of it's higher-application info, not really for the RTP library, and more of it's coming in the future. 

-hadriel