Re: When is RTCIceTransportController needed?

Another issue occurred to me… ICE restart is supposed to be signalled through a change in ufrag and password. But in a re-invite situation if the offer contains a new ufrag and password but it’s rejected a role back must occur. Not sure how that is supposed to happen if the old ufrag/password are toast. Personally I don’t like roll back anyway but seems to be there’s a problem that is can’t be supported via a restart method. In that case it would require two ICETransport objects be created so the old one be disposed when confirmed. “restart()” doesn’t support rollback.

So your option #3 looks mighty good to me (and for the record I’ve always been in favour of not having a restart() method). The concern was though that if we create/dispose new transports it messes up the ICETransport controller. That you have to do crazy management to swap in out transports in that situation. I’m not so sure because to me it’s a brand new controller too in 99% of cases since it’s likely going to be a "restart" on all related transports anyway and not just one.

-- 
Robin Raymond

On July 29, 2014 at 8:14:57 PM, Peter Thatcher (pthatcher@google.com) wrote:

Actually, the more I think about this, the more I am confused about it.  Maybe there is something I am missing.

I'm sure there's a good reason, but I have forgotten.  Currently, we can create a new IceTransport and a new DtlsTransport around it and then switch out the transport under the RtpSender or RtpReceiver.  If we do so, we effectively get an ICE restart but without calling restart.   So why do we have a restart() method again?  The only advantage I see to an explicit restart method is that we don't need to redo the DTLS handshake, and that it's a little bit easier to do. 

And if I call restart(), and signal it to the remote side, what does the remote side do?  We don't have IceTransport.setRemoteParameters to pass in the new ufrag/pwd, so the only thing the remote side can do is create a new IceTransport and new DtlsTransport, which removes the only big advantage I see for having a restart() method.  

It seems like we have 3 options:
1.  Have IceController.restart() and IceTransport.setRemoteParameters, which seems asymmetric.
2.  Don't have IceController.restart() and just create new IceTransports and new DtlsTransports.
3.  Don't have IceController.restart(), but do have DtlsTransport.setTransport, which allows swapping out the IceTransport under it.  Create new IceTransports, but not new DtlsTransports.

Again, I feel like I am missing something.  Can someone please help me figure it out? 


On Tue, Jul 29, 2014 at 2:55 PM, Bernard Aboba <Bernard.Aboba@microsoft.com> wrote:
At the July 20 ORTC CG meeting, we talked about adding restart() and gather() methods to the RTCIceTransportController object, and removing gather() from the RTCIceTransport.

One question was whether this implied that RTCIceTransportController was needed, even for simple cases, such as when both A/V mux and RTP/RTCP mux is used.

In looking through the current examples in the spec, it was not very clear when RTCIceTransportController would be needed:

1.     Section 3.16, Example 3. This example assumes a single ICE and DTLS transport (implying A/V and RTP/RTCP mux), so it didn't construct an RTCIceTransportController. Note that this example doesn't call RTCIceTransport.gather(), so it seems to imply that gathering is initiated via the start() method. Since this example doesn't need either ICE restart or gather(), is it necessary to construct an RTCIceTransportController?

2.     Section 4.4, Example 5. This is a more complicated example where the Initiator constructs ICE transports, DTLS transports, sender and receiver objects, assuming no A/V or RTP/RTCP mux, then determines whether the responder can do RTP/RTCP mux. Here also there is no ICE restart or use of gather(), only RTCIceTransport.start(). And there is no RTCIceTransportController constructed. Do we need to construct one, or since there are separate A/V transports, it is "implicitly" contructed somehow??

3.     Section 5.4, Example 6: This is a forking example with an RTCRtpIceListener and no RTP/RTCP mux. Again, it only uses RTCIceTransport.start, not restart() or gather(), and no RTCIceTransportController object is constructed.