Re: Draft of alternative JSEP API proposal

Thanks for posting this draft.

We now have some experience developing real applications using the existing ROAP based API and have running code using Phono using WebRTC ROAP as the media layer in Chrome Canary to make both WebRTC/WebRTC and WebRTC/PSTN calls.

Some observations and feedback:

- While the browser maintaining the signalling state machine and invoking the JS using callbacks makes the simple case very easy, it can easily result in spaghetti code for anything more complicated where the state machine needs to be maintained by the JS application. You end up with a split system where you are waiting for a callback which could have just as easily been synchronous (and a lot easier to understand).

- The desire for SIP interop and it's influence on the API is possibly a red herring. From our experience with the SDP generated by Chrome Canary it's very unlikely we'll ever find an existing third party device that will be able to parse it, let alone act on it correctly. We ended up developing a special SBC that could both parse and generate compatible SDP and relay RTP from the SRTP/ICE that is required by WebRTC.

- It turns out that SDP manipulation is a lot easier in javascript than in an SBC, so we ended up tweaking SDP by hand in javascript quite a lot before passing it onwards.

We'll be doing the same exercise with the new JSEP API in Chrome Canary and will compare the results.

Neil

On 14 Mar 2012, at 19:41, Adam Bergkvist wrote:

> Hi
> 
> The editors team has, for a while, been drafting two versions of the PeerConnection API that uses JSEP as the signaling protocol under the hood. One version is the API that's presented in the JSEP draft [1]; the other is JSEP under the existing API as discussed in [2].
> 
> I took the initiative to draft the version that is based on the existing API for the following reasons:
> - We have an API that has been our working assumption for quite some time and it has been implemented and tested in browsers; we should evaluate how the new signaling protocol would work with it.
> - The newly proposed API is, IMO, harder to use than what we have today. For example, the developer has to know what actions (API calls and external events) that requires new signaling. A web developer who just wants to get his application working and is content with whatever media configuration that the browser produces shouldn't have to deal with specifics of ICE or SDP or even the most basic offer-answer semantics.
> 
> The features of the existing API that I think makes it worth preserving are:
> - When the browser detects that a new offer is needed to reflect the media state (e.g. a MediaStream was added to a PeerConnection or a MediaStreamTrack was removed from a MediaStream), it creates an offer and provides it to JavaScript via a callback.
> - A signaling message, received from the other peer, can directly be given to PeerConnection via the processSignalingMessage() method.
> 
> The major semantic changes to the existing API to support JSEP are:
> - Introduce a PeerConnection id that's included in every signaling message to distinguish a locally produced signaling message from a remotely produced one. (Section 4)
> - Update processSignalingMessage() to interpret signaling messages correctly. For example, process a signaling message as a local description of type offer. (Section 4.1.2)
> - Update the algorithm for dispatching new signaling messages to make them understandable by the receiving processSignalingMessage() method. (Section 4)
> 
> What remains to be done:
> - Remove the SDP Agent and the SDP states (shared action between both JSEP API branches).
> 
> The draft also has an updated example. (Section 4.3)
> 
> Please find attached the updated draft document. Feedback and comments are appreciated.
> 
> /Adam
> 
> [1] http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-00
> [2] http://lists.w3.org/Archives/Public/public-webrtc/2012Feb/0044.html
> <webrtc_jsep_easy1-2012-03-14.html>

Received on Thursday, 15 March 2012 11:34:54 UTC