Re: [rtcweb] SDP offer/answer vs. JSON (was: About defining a signaling protocol for WebRTC (or not))

[Henry Sinnreich <[e-mail]>]

+1

Very solidly argued.

Henry


On 9/16/11 1:29 PM, "Hadriel Kaplan" <[e-mail]> wrote:

> 
> 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
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb