W3C home > Mailing lists > Public > public-webrtc@w3.org > March 2012

Draft of alternative JSEP API proposal

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Wed, 14 Mar 2012 20:41:47 +0100
Message-ID: <4F60F47B.7000600@ericsson.com>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
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


Received on Wednesday, 14 March 2012 19:47:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 14 March 2012 19:47:50 GMT