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

On Mon, Aug 6, 2012 at 11:51 PM, Matthew Kaufman
<matthew.kaufman@skype.net>wrote:

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