RE: Microsoft API Proposal

On the issue of replacing SDP, I'm trying to understand how the RealTimeMedia description would be signaled between the peers.  Examples 1 and 2 in Section 2 show side A calling:
  signalingChannel.send(description.toDictionary());

Then on the receiving side B we have:
 function receiveDescriptionFromSignaling(remoteDescription) {.....

So it appears that something on side B had to receive the message, recognize that it was a RealTimeMediaDictionary, build the appropriate structure, and then call receiveDescriptionFromSignalling.  Is the browser supposed to do this?  How would the two ends agree on the signaling protocol?  I thought that the point of SDP was to solve this kind of problem.  You may have a better solution in mind, but I haven't been able to figure out what it is.

- Jim



-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Tuesday, August 07, 2012 11:55 AM
To: Stefan Hakansson LK
Cc: public-webrtc@w3.org
Subject: 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 17:39:04 UTC