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

Peter said: 

"That's a good point.  We did overlook this a bit.  We need to make sure 1.
 the JS creates a separate DtlsTransport to wrap the associated
IceTransport (created with createAssociatedTransport) and 2.  The RTCP
packets flow over the create DtlsTransport.  I think we can make #2 happen
in the implementation no matter what we do for #1, but question is: what's
the cleanest way to make it clear to the JS developer that they need to
create a DtlsTransport?  Having a constructor argument is one way, having
an RtpSender.setRtcpTransport is another, and having a
DtlsTransport.createAssociatedTransport is another, and magic implicit
behavior is yet another.  I think we need some code samples to decide which
one is cleanest."

[BA]  Below is the proposed code example based on the constructor argument approach, 
including some comments on how it would differ for the other approaches. 
There isn't much difference between the approaches. 

// This is an example of how to utilize distinct ICE transports for RTP and RTCP.
// Assume we have an audioTrack and a videoTrack to send.
//
//create the RTP and RTCP ICE transports for audio and video
var audioRtpIceTransport = new RTCIceTransport(...);
var audioRtcpIceTransport = audioRtpIceTransport.createAssociatedTransport();
var videoRtpIceTransport = new RTCIceTransport(...);
var videoRtcpIceTransport = audioRtpIceTransport.createAssociatedTransport();

//create the DTLS transports
var audioRtpDtlsTransport = new RTCDtlsTransport(audioRtpIceTransport);
var audioRtcpDtlsTransport = new RTCDtlsTransport(audioRtcpIceTransport);  
// var audioRtcpDtlsTransport = audioRtpDtlsTransport.createAssociatedTransport() in the alternative approach
var videoRtpDtlsTransport = new RTCDtlsTransport(videoRtpIceTransport);
var videoRtcpDtlsTransport = new RTCDtlsTransport(videoRtcpIceTransport); 
// var videoRtcpDtlsTransport = videoRtpDtlsTransport.createAssociatedTransport() in the alternative approach

// ... start the ICE and DTLS transports
var controller = new RTCIceTransportController();
controller.addTransport(audioRtpIceTransport);
controller.addTransport(videoRtpIceTransport);
var audioSender = new RtpSender(audioTrack, audioRtpDtlsTransport, audioRtcpDtlsTransport);
// Alternatively this could be: 
// var audioSender = new RtpSender(audioTrack, audioRtpDtlsTransport); 
// RtpSender.setRtcpTransport(audioRtcpDtlsTransport); 
var videoSender = new RtpSender(videoTrack, videoRtpDtlsTransport, videoRtcpDtlsTransport);
var audioReceiver = new RtpReceiver(audioRtpDtlsTransport, audioRtcpDtlsTransport);
var videoReceiver = new RtpReceiver(videoRtpDtlsTransport, videoRtcpDtlsTransport);
var audioRecvCaps = RTCRtpReceiver.getCapabilities("audio"); 
var videoRecvCaps = RTCRtpReceiver.getCapabiltiies("video"); 
var audioSendCaps = RTCRtpSender.getCapabilities("audio");
var videoSendCaps = RTCRtpSender.getCapabilities("video"); 

// At this point, capabilities can be exchanged.
// If both sides support RTP/RTCP multiplexing, it will be enabled.
// We assume that the remote audio sender capabilities are stored in remoteAudioSendCaps and remoteVideoSendCaps.
// If the initiator leaves rtcpMux disabled, or enables it, either way it works.

// If both the initiator and responder support RTCP-mux, we will enable it and therefore 
// we need to remember to stop the unused ICE transports, or else they will go to the
// failed state when the remote endpoint blows theirs away.

// Check that both the local receiver and remote sender support RTP/RTCP multiplexing. 
if (audioRecvCaps.features.rtcpMux && remoteAudioSendCaps.features.rtcpMux) {
 audioRtcpIceTransport.stop();
 audioRtcpDtlsTransport.stop();
}

if (videoRecvCaps.features.rtcpMux && remoteVideoSendCaps.features.rtcpMux) {
 videoRtcpIceTransport.stop();
 videoRtcpDtlsTransport.stop();
}

Received on Wednesday, 4 June 2014 19:00:04 UTC