Formalisms (Re: Draft of alternative JSEP API proposal)

As chair... Just a formal note on the status of this.

The editing team has no special formal position in the WG. They edit the 
document according to the decisions of the WG.

The editing team, after discussion, felt that the right way to present 
such a dramatic change as JSEP was to prepare a draft that showed how it 
would look in the document, and ask the WG for consensus on 
incorporating that. These proposals would formally be member submissions.

One editor (Cullen) took on the task of incorporating the API model from 
draft-ietf-rtcweb-jsep, with little or no changes from the proposals. 
This is still work-in-progress, and the member submission will be 
forthcoming.

Adam has decided to present the member submission below. The editing 
team has discussed this proposal, and the editing team members have 
encouraged the publication of the document, but this is a member 
submission, it is not an editing team product.

Thanks to Adam for presenting his proposal in a form complete enough to 
be evaluated!

I will comment on the proposal technically in another note, with my 
member hat on.

                         Harald

On 03/14/2012 08:41 PM, 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

Received on Thursday, 15 March 2012 06:49:41 UTC