W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2013

RE: On babies and bathwater (was Re: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface)

From: Matthew Kaufman (SKYPE) <matthew.kaufman@skype.net>
Date: Sat, 20 Jul 2013 03:15:42 +0000
To: Cullen Jennings <fluffy@iii.ca>, Martin Thomson <martin.thomson@gmail.com>
CC: Adam Roach <adam@nostrum.com>, Iņaki Baz Castillo <ibc@aliax.net>, "<rtcweb@ietf.org>" <rtcweb@ietf.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <AE1A6B5FD507DC4FB3C5166F3A05A484237181A5@TK5EX14MBXC266.redmond.corp.microsoft.com>
From: Cullen Jennings [mailto:fluffy@iii.ca]:
> On Jul 19, 2013, at 9:54 AM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
> 
> > Negotiation is a hole.  A vast, soul-sucking, waste of time.
> 
> That's might be closer to true when you control both ends, like Skype.
> 
> It's not true when a browser from one vendor running an application from a
> scone vendor needs to talk to video conferencing system from a third
> vendor.

If you think that the second vendor's web server + signaling gateway should be doing negotiation between itself and the third vendor's videoconferencing system, then that's fine.

If you think that the second vendor is going to get the first vendor to ship an updated browser to make its SDP O/A 100% compliant with what the third vendor's system is expecting, then you're crazy. It simply isn't going to happen, and what's more, given that the browser from the first vendor contains a complete JavaScript implementation, there's no reason why it should be. The first vendor should provide the JS APIs that are necessary for the second vendor to build the system they want to build. Done. And without the endless pain that trying to make browser SDP O/A compatible with anything else is going to be.

Matthew Kaufman
Received on Saturday, 20 July 2013 03:17:33 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:35 UTC