- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Wed, 14 Mar 2012 20:41:47 +0100
- To: "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <4F60F47B.7000600@ericsson.com>
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
Attachments
- text/html attachment: webrtc_jsep_easy1-2012-03-14.html
Received on Wednesday, 14 March 2012 19:47:49 UTC