Re: When is RTCIceTransportController needed?

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.
>
>
>