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

Proposal how to map JSEP to the existing API

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Fri, 10 Feb 2012 11:25:26 +0100
Message-ID: <4F34F096.4040203@ericsson.com>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
Hi

The JavaScript Session Establishment Protocol (JSEP) imposes a new set 
of requirements on the signaling flow. One significant improvement is 
the separation of connectivity establishment (ICE) and media negotiation 
(SDP O-A) to allow for ICE "trickling".
In addition, there are new requirements for handling of session 
descriptions (from the JSEP draft):
1. To know if a session description pertains to the local or remote side.
2. To know if a session description is an offer or an answer.
3. To allow the offer to be specified independently of the answer.

We would like to map this new protocol to the existing API to allow for 
the simple case to remain simple, yet powerful. Key concepts that we 
would like to preserve include that the browser knows when a new 
signaling message needs to be conveyed to the other peer as well as how 
to handle incoming signaling messages. A web developer who would just 
like to get something working should not have to learn specifics about 
ICE and SDP and know how the signaling works and, for example, when some 
local action requires an updated offer to be created.

To support the requirements of JSEP, we propose the following changes to 
the existing API:

For the browser to easily be able to determine whether a signaling 
message is an offer, answer, or candidate line, a corresponding keyword 
is added to the signaling message header (#2 above). For the browser to 
know if an offer or answer was created locally, each PeerConnection 
instance is assigned an internal unique identifier that is also included 
in the signaling message header (#1 above).

To allow emitted offers and answers to be updated locally, 
processSignalingMessage() is changed to support signaling messages to be 
passed into the same PeerConnection instance that they originated from 
(#3 above).

// set local description with offer
processSignalingMessage("SDP OFFER <id>\n<sdp>");     // id is local

// set remote description with offer
processSignalingMessage("SDP OFFER <id>\n<sdp>");     // id is not local

// set local description with answer
processSignalingMessage("SDP ANSWER <id>\n<sdp>");    // id is local

// set remote description with answer
processSignalingMessage("SDP ANSWER <id>\n<sdp>");    // id is not local

// process ICE candidate
processSignalingMessage("SDP CANDIDATE <id>\n<sdp>");

Signaling messages with offers and answers need to be produced 
asynchronously by the browser. When modifications have been made that 
requires an updated offer, a new signaling message is automatically 
emitted when stable state is reached (no change). Likewise, when a 
remote offer is passed into a PeerConnection instance, an answer is 
automatically produced when stable state is reached (no change).

Signaling flow, connectivity establishment
------------------------------------------

A:
new PeerConnection()

// stable state, start gathering ICE candidates

[ signalingCallback ] "SDP CANDIDATE <id>\n<sdp>"
// send candidate to B

B:
new PeerConnection()
processSignalingMessage("SDP CANDIDATE <id>\n<sdp>")

// stable state, start gathering ICE candidates

[ signalingCallback ] "SDP CANDIDATE <id>\n<sdp>"
// send candidate to A

A:
// start establishing connectivity
processSignalingMessage("SDP CANDIDATE <id>\n<sdp>")


Signaling flow, media negotiation
---------------------------------

A:
addStream()

// stable state, create offer
[ signalingCallback ] "SDP OFFER <id>\n<sdp>"

*** Offer may be modified and reinserted locally with 
processSignalingMessage()
// send offer to B

B:
addStream()

// process incoming offer
processSignalingMessage("SDP OFFER <id>\n<sdp>")   // id is not local

// stable state, create answer
[ signalingCallback ] "SDP ANSWER <id>\n<sdp>"
*** Answer may be modified and reinserted locally with 
processSignalingMessage()

// B has all info needed to receive
[ onaddstream ]

// send answer to A

A:
// process incoming answer
processSignalingMessage("SDP ANSWER <id>\n<sdp>")   // id is not local

// media flowing from A to B

[ signalingCallback ] "SDP ACK <id>\n<empty sdp>"

// A has all info needed to receive
[ onaddstream ]

// send ack to B

B:
// process incoming ack
processSignalingMessage("SDP ACK <id>\n<empty sdp>")   // id is not local

// media flowing from B to A

/Adam
Received on Friday, 10 February 2012 10:30:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 10 February 2012 10:30:53 GMT