Re: Draft of alternative JSEP API proposal

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