Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened

[Gustavo García <[e-mail]>]

"We reject kings, presidents and voting. We believe in rough consensus and running code". (IETF TAO)

- Lot of developers building stuff beyond a PSTN interconnection demo are having problems with the existing model.   Complexity, limitations and incompatibilities make us feel like fighting an API instead of using it.
- There are a lot of issues (bugs, incompatibilities, feature requests) because of SDP and O/A.  Take a look at webrtc issue tracker.
- The actual experience of people using the API should be a stronger argument than a voting done one year ago.  Specially when most of developers are not participating in IETF voting and after realizing the implications of SDP and O/A model f.e. on all those endless Plan-XXX  discussions.
- There is a much more simple solution (something like CU-RTC-Web) and you can always write a SDP/O/A/PeerConnection API on top of it (I had a prototype working in a couple of hours), but the other way around is much more hard if not impossible. 

In my opinion the only reasonable approaches are:
- Change the API now
- Change the API in one year

+1 to Iñaki's request too

G.

On 18/06/2013, at 15:19, Matthew Jordan wrote:

> 
> On Tue, Jun 18, 2013 at 1:22 PM, Adrian Georgescu <[e-mail]> wrote:
> +1
> 
> While working with the specs, some may have realised that SDP is not such a great idea to put in practice and may also want to come forward to admit their mistake.
> 
> Regards,
> Adrian
> 
> 
> In the Asterisk project, we were able to use our legacy SIP stack to enable very basic WebRTC communication with Chrome and FireFox. That sounds nice, until you realize we have to continually preface that with "sometimes".
> 
> Because the answer is, more often than not, something breaks. Invariably, the breakages have been in the SDPs sent to Asterisk by the browser. What SDP breaks us changes depending on the browser being used, the version of said browser, and whether or not some new WebRTC SDP feature has been put in the browser's latest release. And just when we think we have to modify Asterisk to handle the new SDP sent by some browser, the browser changes again. As a result, Asterisk 11 hasn't changed a lot since we released; we've been trying to avoid coding to a moving target. We always envisioned that things would quiet down and the browsers would settle on an implementation of SDP that we could adapt to - but it doesn't seem like things are quieting down as much as we'd like. And sure, the SIP stack in Asterisk is crufty, and sure, sometimes the fault is in our implementation, not the browser's - but I think we on the Asterisk project can certainly say that relying on SDP hasn't been a panacea for interoperability.
> 
> It feels like maintaining compatibility with "traditional" SDP implementations is getting harder for the browsers to manage and holding the entire process back. As one of those older "traditional" implementations, I'd rather write an entirely new channel driver for Asterisk than have to re-write our SDP handling.
> 
> So... +1 to Inaki's request.
> 
> Matt
> 
> -- 
> Matthew Jordan
> Digium, Inc. | Engineering Manager
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at: http://digium.com & http://asterisk.org
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb