- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Mon, 19 Mar 2012 18:13:40 +0100
- To: "public-webrtc@w3.org" <public-webrtc@w3.org>
Hi Here are some examples on how to do ICE candidate trickling and local signaling message modification with the existing API. The intention is to start a discussion around API capabilities. *** ICE trickling *** This is a simple case where signaling messages are passed between the browsers without modification. pc = new PeerConnection("TURNS example.net", signalingChannel.send); signalingChannel.onmessage = function (evt) { pc.processSignalingMessage(evt.data); }; The intention is to let ICE candidate trickling be the default since it may offer better performance in the browser to browser case (which this API is optimized for). The first offer dispatched contains the media offer including the local candidate. Consecutive dispatched candidates are also transported to the remote peer via the same mechanism. *** Local SDP modification *** This example shows how an offer is modified and fed back into the PeerConnection object before it is sent to the remote peer. pc = new PeerConnection("TURNS example.net", function (sdp) { var msg = new SignalingMessage(sdp); if (msg.type == "offer") { // call methods on 'msg' to alter session description pc.processSignalingMessage(msg); } signalingChannel.send(msg); }); In this example, SignalingMessage is a structured API to parse and modify signaling messages, implemented in JavaScript with a toString() method to serialize it back to an sdp. An alternative approach could be to let the signaling callback provide an object directly instead of a string. Such an object would initially only contain a type attribute and a toString() method, but could be populated with functionality as we decide what to expose and get feedback from developers. In the meantime, JavaScript developers can add more functionality to the object's prototype. Modifying answers would be done in a similar way. /Adam
Received on Monday, 19 March 2012 17:19:33 UTC