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

Martin Steinmann [mailto:martin@ezuce.com]:
> I have been on this list for a long time, likely like many others who are
> wondering what is going on.
> 
> Does anyone really expect Google and Mozilla to change their
> implementation just because some other companies want to build, for the
> most part, proprietary peer-to-peer systems? 

No. But I'm not sure what you're talking about here. Lync, for instance, is a very standards-based system. Skype is a proprietary peer-to-peer system that is in the midst of a vast transformation to a server-based system that will undoubtedly find good standards to pick from as it undergoes that transformation.

> To transform the multi-billion
> dollar telecoms industry into a Web economy you need legacy interop and a
> consistent and simple (high-level) API that facilitates interoperability.  From
> an economic perspective this is very simple.

Those are two different things. The current specification does not in any way give us "legacy interop". Even if one discounts the requirement for ICE and the requirement for DTLS-SRTP, the SDP generated by the two browsers produced by the vendors you mentioned is hardly compatible with any legacy SIP+SDP system... nor of course is it compatible with any other type of legacy system running (for example) H.323 or Jingle as its signaling protocol.

The current specification gives us what some might call a "simple high-level API"... but it certainly isn't one that facilitates interoperability. Having to take the SDP that is emitted and parse it down into bits and reassemble new SIP or Jingle messages containing SDP that the far end will understand is in no way "facilitating interoperability". In fact, as some developers who have tried to achieve true interoperability here on the list have stated, a different API, one that provides direct manipulation and doesn't embed an RFC3264 O/A state machine would be easier, for them, to use to achieve interoperability.

 
> Elevating this discussion from a pure technical argument and into the real
> world would require those who say they represent browser vendors to
> actually state what standard these browsers would support and by when and
> how these standards would facilitate interop.  Are the IE, Lync, and Skype
> teams all on the same page?  Such a commitment would make a real
> difference and resonate with the industry at large.

Microsoft (my employer) has a policy of not providing advance information about what features or specification implementations it will or will not commit to in future software releases, including releases of Internet Explorer. It is unlikely that an exception will be made in this case.

I can tell you that 1) The "Lync and Skype teams" are, and have been for almost half a year, a single organization (in the Skype division until a few days ago) and 2) The combined Lync and Skype organization has the expertise that would be involved in any work done to implement RTC in Internet Explorer.
 
> What we the users and developers of apps really need is consensus and
> commitment for browser support, desktop and mobile.  I have seen the
> Skype team propose CU-RTC-Web, but would IE support it? How about Lync?

Again, Microsoft is not going to make commitments as to which versions of which specifications will ship in future software products.

> And would Microsoft support the industry making the implementation
> available in open source and with a royalty free patent grant?  What is the
> argument to convince Google and Mozilla to re-implement?  Without
> thinking this through the best API proposal is pretty useless and the
> argument mainly academic.

It is no less "mainly academic" than the current situation, which is that we have an unfinished API specification that has made approximately zero progress in six to nine months and which has holes big enough to drive a truck through.

I can tell you that, at Microsoft, we are not going to be reading Google or Mozilla source code in order to create an interoperable implementation of anything, and so either there will be a specification that we write or a specification that is sufficiently detailed coming from the W3C that we can consider implementing.


> The current draft spec is very nicely setup to meet the larger objectives
> towards broad adoption. 

I think that's incorrect (see above about how well it facilitates interoperability, for instance)

> To counter that will require an all-encompassing
> proposal and committment and not just another technical spec thrown into
> the ring.

I doubt that would even be sufficient, given the sort of messages that have been coming from the leaders of the working groups to anyone with any type of alternative proposal. That's a problem.

Matthew Kaufman

Received on Saturday, 20 July 2013 03:58:03 UTC