- From: Peter Thatcher <pthatcher@google.com>
- Date: Fri, 2 May 2014 18:21:57 -0700
- To: "public-ortc@w3.org" <public-ortc@w3.org>
- Message-ID: <CAJrXDUFm+=p2L2C6D=xygLkpuynGfUvHBV3nnXJpLi=CDtDayQ@mail.gmail.com>
This could probably be two separate proposals, but they are slightly related, so the proposal and example here will go together. Just a reminder about the problems we're solving: 1. We don't have a way for the app to express that i t wants to have RTCP that isn't multiplexed with RTP. We can create a separate IceTransport for RTCP, but we don't have a way to tie it to tie it to the RTP transport. 2. We don't have a way of expressing that a set of IceTransports are tied together in a way such that the right ICE freezing behavior happens, and in particular that the JS can express which IceTransport(s) should come first. So, here's how we can solve these two things: // From [RFC 5245] 4.1.1.1. enum IceComponent { RTCP = 2 } interface IceTransport { // ... all the existing stuff // Create ICE transport for RTCP via createAssociatedTransport(RTCP) // and associate it with this ICE transport. // When the transport for RTP is supplied to RtpSender/Receiver, // an RTCP transport, if present, is implicitly associated as well. // If called more than once for the same component, // the old one is ".stop()"ed, and the new one replaces it // (or do we just want to fail?) IceTransport createAssociatedTransport(IceComponent component); } dictionary RtpParameters { // ... all the existing stuff // Defaults to true. If false in RtpSender.send() or RtpReceiver.receive(), // the IceTransport must have an associated IceTransport with component == // RTCP, in which case RTCP will be sent on the associated IceTransport . bool rtcpMux; } interface TransportController { sequence<IceTransport> getTransports(); // Adds a transport to the controller for the purposes of managing // ICE freezing and sharing BWE. ICE transports will be unfrozen // according to their index. // Inserts at |index|, or the end if no index specified. // Fails if |index| is greater than the current number of transports. // Fails if |transport| is already added to another TransportController. // Fails if |transport| is for the RTCP component. void addTransport(IceTransport transport, int index = null); // Do we need this? Assume not for now. // Calling transport.stop() should be sufficient. // void removeTransport(IceTransport transport); } Here's an example: var audioRtpIceTransport = new RTCIceTransport(...); var audioRtcpIceTransport = audioRtpIceTransport.createAssociatedTransport( IceComponent.RTCP); var videoRtpIceTransport = new RTCIceTransport(...); var videoRtcpIceTransport = audioRtpIceTransport.createAssociatedTransport( IceComponent.RTCP); // ... start the ICE and DTLS transports var controller = new TransportController(); controller.addTransport(audioRtpIceTransport); controller.addTransport(videoRtpIceTransport); audioSender = new RtpSender(...); videoSender = new RtpSender(...); audioReceiver = new RtpSender(...); videoReceiver = new RtpSender(...); var audioParams = RtpSender.createParams(); var videoParams = RtpSender.createParams(); // Sender can disable RTCP mux to start, // to see if responder will enable it. audioParams.rtcpMux = false; videoParams.rtcpMux = false; // At this point, the sender can send the params to the receiver. // If the receiver leaves it disable, or enables it, either way it works. audioSender.send(audioParams); videoSender.send(videoParams); audioReceiver.receive(audioParams); videoReceiver.receive(videoParams); // If the receiver does enable RTCP - mux, 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. if (audioParams.rtcpMux) { audioRtcpIceTransport.stop(); } if (videoParams.rtcpMux) { videoRtcpIceTransport.stop(); } This has the following benefits: 1. It allows non-muxed RTCP 2. It allows proper ICE freezing behavior. 3. The additional complexity added to the API is small. 4. The burden on users who don't care about non-muxed RTCP or ICE freezing order is basically zero. 5. The users who do care about non-muxed RTCP and ICE freezing have a pretty clean API to work with, and the only tricky part is remembering to stop transports you don't use anymore.
Received on Saturday, 3 May 2014 01:23:05 UTC