Re: A proposal for solving non-muxed RTCP *and* ICE freezing

Robin Raymond said: 

"After some thought about this issue, I think your solution of "just 
create a new RTCIceListener" is the right answer, plus we have enough 
knowledge to be able to re-use/recycle that same newly constructed 
RTCIceListeners for forked transports without adding another method 
parameter to "createAssociatedTransport(...)". The entire secondary 
RTCIceListener can be implicitly done in a hidden fashion. So for the 
ORTC API, all we need to put in the proper behaviour language for the 
browser engines to know what to do and for the application developer to 
know what to expect. Bottom line, Peter's solution will work."

[BA] I think it will work, though the implicit creation of an RTCIceListener does require some explanation and also an example. 

Basically, when an RTCIceTransport is constructed from an RTCIceListener object and then 
createAssociatedTransport is called o the newly created RTCIceTransport, a new RTCIceListener object is implicitly created. 

Below is a code example that attempts to show how this works: 

========================
var iceOptions = ...;
var iceListener = new RTCIceListener(iceOptions);
var iceBase = new RTCIceTransport(iceListener);
//create the RTCP ICE transport
var iceBaseRtcp = iceBase.createAssociatedTransport();

sendInitiate(
{
   "ice": iceBase.getLocalParameters(),
   "icertcp": iceBaseRtcp.getLocalParameters()
 },
  function(response) {
  // We may get N responses
  var ice = new RTCIceTransport(iceListener);
  // Create new ice RTCP transport based on the (implicitly created) iceListener 
  var iceRtcp = new RTCIceTransport(iceBaseRtcp.iceListener); 
  ice.start(response.ice, RTCIceRole.controlling);
  iceRtcp.start(response.icertcp, RTCIceRole.controlling); 
  // ... setup DTLS, RTP, SCTP, etc.
});

iceBase.onlocalcandidate = sendLocalCandidate;
iceBaseRtcp.onlocalcandidate = sendLocalCandidate;

Received on Wednesday, 4 June 2014 21:31:35 UTC