W3C home > Mailing lists > Public > public-webrtc@w3.org > August 2012

RE: [rtcweb] Microsoft tells W3C and IETF what we are doing no signs of offering real world interoperability

From: Matthew Kaufman <matthew.kaufman@skype.net>
Date: Mon, 6 Aug 2012 21:51:55 +0000
To: Justin Uberti <juberti@google.com>, "Cullen Jennings (fluffy)" <fluffy@cisco.com>
CC: "rtcweb@ietf.org" <rtcweb@ietf.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <AE1A6B5FD507DC4FB3C5166F3A05A4840E4C90A9@TK5EX14MBXC273.redmond.corp.microsoft.com>

From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] on behalf of Justin Uberti [juberti@google.com]:

> In fact, I think the primary novel features of this proposal are:
> - SessionDescriptions are true objects, instead of wrappers around SDP

More important, there is no SDP Offer/Answer state machine within the browser. A developer who desires SDP Offer/Answer semantics may implement that in Javascript or server-side. This is as opposed to JSEP, which includes a particular SDP O/A state machine within the browser, thus requiring it to be interoperable with other SDP O/A state machines both within other vendor browsers as well as existing SIP+SDP equipment and software.

> - Additional control over the ICE Agent
> However, no use cases have yet been outlined that require this functionality.

I believe that there are several use cases, including interoperability use cases, where our proposed solution is more likely to be able to meet all edge cases.

An example would be recovery from call setup in the face of a browser page reload... a case where the state of the browser must be reinitialized, leading to edge cases where it becomes impossible with JSEP for a developer to write Javascript that behaves properly in all cases (because without an offer one cannot generate an answer, and once an offer has been generated one must not generate another offer until the first offer has been answered, but in either case there is no longer sufficient information as to how to proceed). While SDP O/A is a useful abstraction for trunk interconnection of peer endpoints, we do not believe it is a good choice for the Javascript API surface.

Likewise, baking in one ICE implementation is likely to lead to interoperability failures when it is found that it has subtle incompatibilities with other deployed applications, whereas our proposal would allow the developer of the web site or supporting Javascript library to code around these issues once RTC-capable browsers are already fielded.

In addition to these differences that fall out of not baking in the full ICE and SDP O/A state machines, our proposal provides several other capabilities, including hooks that allow a developer to customize their application's response to changing network conditions... an area which is currently completely unaddressed in the current WebRTC draft.

I wouldn't be surprised if the existing use-case document(s) is (are) inadequate to describe situations where, for instance, a developer might wish to prioritize video quality over frame rate, or drop video in order to continue audio, but that just means that we all need to provide more input on those documents as well.

Matthew Kaufman
Received on Monday, 6 August 2012 21:52:29 UTC

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