Re: Microsoft API Proposal

On 7 August 2012 01:21, Stefan Hakansson LK
<stefan.lk.hakansson@ericsson.com> wrote:
> I think it would be helpful (when reviewing) if you could in a more concrete
> way point out the key differences, and the reason why your proposal is
> different.

I may have missed something, but the key differences for us are the following:

No SDP

JSEP's reliance on SDP is a source of a number of problems.  Our
experience with SDP shows that it rarely, if ever, successfully
interoperates.

SDP introduces an API surface whereby changes can be introduced by
browser makers without standardization.  These changes cannot be
easily discovered by applications.  Even if we acknowledge that
browsers are unlikely to make changes that affect backward
compatibility (which introduces a significant handicap), even
increasing the flexibility of the browser implementation in light of
modifications to SDP make it such that applications are unable to
discover the capabilities of the browser.

We want to avoid things like browser-sniffing and browser-specific
code, but we don't see an evolution path for this API that doesn't
involve that as long as it contains SDP.

No unnecessary state

JSEP introduces two state machines into PeerConnection that are
unnecessary.  The first is the offer/answer state machine, which is an
evolution of the state machine defined in RFC 3264.  This adds
unnecessary complexity to the browser, which forces applications to
take on the burden of managing that state.  For instance, offer/answer
introduces a deadlock state that an application is forced to discover
and break.

The second piece of state is with the ICE state machine.  ICE state is
currently very poorly defined.  It is also unnecessary.

I have a sketch of an API that does ICE on top of this API.  This
would be pure Javascript, but it could be shipped with browsers.  This
would reduce the complexity for application developers without
removing any flexibility or transparency.

One giant ball of string

PeerConnection is complex thing, see
<http://en.wikipedia.org/wiki/God_object>.  Even with all the missing
functionality it is responsible for too many things.  This results in
an opaque, inflexible structure that hampers application developers.

For instance, it is very important in some interoperability use cases
to create specific transport flows and control how media is allocated
to each.  JSEP doesn't really offer a clear way of doing this.
Manipulating SDP might be possible, depending on how much meddling is
allowed by each browser.  Again, PeerConnection makes this unclear
where it need not be.

Overall, we believe that the API represents a more open, discoverable,
flexible abstraction.

Received on Tuesday, 7 August 2012 15:55:10 UTC