Re: Cross posting: Re: [rtcweb] SDP is not suitable for WebRTC

On Jul 30, 2013, at 4:52 AM, Iņaki Baz Castillo <ibc@aliax.net> wrote:

> I will summarize my SDP/Plan-Unified concern here. I hope that those
> who are fine with SDP and Plan-Unified (i.e. Google and Cisco) will
> express their opinion:

I am not "fine" with using SDP, nor with the Unified-Plan.  But I'll express my opinion anyway...


> QUESTION:
> 
> How can my browser join the conference without requiring SDP
> renegotiation from the server and, at the same time, being able to
> send its audio/video tracks and receive audio/video from all the participants?

I think you're asking the wrong question.  Or rather, you're making assumptions that I don't think have to be made.  Your question hinges on the: "without requiring SDP renegotiation from the server end".

For one thing, SDP does NOT have to be sent on-the-wire between the browser JS and the peer.  Nothing in WebRTC mandates what your JS sends over HTTP or a direct data channel.  The SDP is purely between your JS and the Browser, as an API. (it's nuts, but that's what it is)  You can, for example, write your JS to only deal with SDP locally between the JS and the browser, and send media-related information using JSON or XML or whatever to the remote peer, with whatever state/semantics model you wish.  Obviously the general concept is to let you send the SDP back/forth with peers, but it's not mandatory.  

If you implement "SIP" for your on-the-wire signaling, then obviously you do have to send SDP and use offer/answer; but by definition if you use SIP then you have to follow the SIP RFCs, including RFC 3264 offer/answer and 4566 SDP.  Nothing in WebRTC forces you to implement SIP, however.  That's a choice you made.

Secondly, you imply a need to accomplish something in one signaling round-trip, as if your application won't work if it needs to perform two or more round-trips.  Why won't it work with two round-trips?  Clearly it's not optimal for your use-case, but does it actually prevent it being usable/possible?

Taking a step back from your particular use-case... the proponents of SDP argued that it made sense to use SDP for the API because it let *simple* WebRTC use-cases be easy, while still letting complicated things be possible (but neither simple nor easy).  In other words, the design was driven by a goal to let an app developer use WebRTC for a simple audio/video/data-channel communication mechanism, with very few lines of JS code.

We've always known that doing anything else but a simple scenario would not be trivial.  It would either require the JS developer to munge SDP, or use SDP only locally while doing something else on-the-wire, or have a lot of offer/answer round-trips.  But that was the price the W3C and IETF decided it was worth paying, in exchange for making simple use-cases easy to implement in JS.[1]

-hadriel
[1] I'm not claiming it was the right decision, but as far as I can recall that was the main argument.  And I'm ignoring the fact that once one of the WG member companies discovered they had an advanced use-case and it would be annoying to write the JS to handle it, they then went and started asking for changes to SDP offer/answer to handle their particular not-so-simple use-case.

Received on Thursday, 8 August 2013 14:19:40 UTC