When is RTCIceTransportController needed?

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.