- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Fri, 10 Feb 2012 11:25:26 +0100
- 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 UTC