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: Justin Uberti <juberti@google.com>
Date: Tue, 7 Aug 2012 02:11:27 +0200
Message-ID: <CAOJ7v-3w+AUR08PtOZgVQJDnswjCsBwd0iPyzpdR8VFy7JYhUA@mail.gmail.com>
To: Matthew Kaufman <matthew.kaufman@skype.net>
Cc: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On Mon, Aug 6, 2012 at 11:51 PM, Matthew Kaufman

> 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.

While there is a simple state machine, with JSEP you can drive the state
machine to any state you want, easily. To say that it bakes in SDP
offer/answer is inaccurate; if you don't want to use offer/answer you can
just set the local or remote description at any time (followed by
reapplying the existing remote/local description to complete the sequence).

This could of course be streamlined, but this could be done as an evolution
of the existing API.

> > - 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.

As others have pointed out, these kinds of hooks have been discussed but
haven't yet made it into the current API 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 Tuesday, 7 August 2012 00:12:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:32 UTC