Re: ice restart ?

I think your option "a" is sufficient. It keeps API surface down and 
achieves the result. Option "d" could be supported in the future but I 
don't see much real world benefit being able to rewire the 
RTCIceTransport to a new RTCIceListener at this point in time.

My only concern now is ICE freezing ordering in a restart so I'm eager 
to see PT's proposal for ICE "context / session" (and rtp / rtcp non-mux).

-Robin

> Peter Thatcher <mailto:pthatcher@google.com>
> April 28, 2014 at 1:42 PM
>
>
>
> On Mon, Apr 28, 2014 at 10:33 AM, Robin Raymond <robin@hookflash.com 
> <mailto:robin@hookflash.com>> wrote:
>
>
>     Thanks for a great summary.
>
>     Yes, I agree those are the three options. I think I prefer option "a".
>
>     Let me list my reasons:
>
>     a. Makes sense to me, attach a new listener to transport or create
>     a brand new one and it forces a restart
>
>
> ​Wait... you're suggesting swapping the listener inside of the 
> IceTransport?  Hmmm... that would be an interesting approach that I 
> hadn't considered.  I guess that would be "option D".
>
>     b. I worry about the security implications, specifically if ice is
>     still being used for consent reasons. By not doing this we don't
>     have to fear that.
>
>
>     c. My only concern is that two RTCIceTransports could the same
>     RTCIceListener so calling a iceTransport1.restart() in that cause
>     would actually affect the other iceTransport2 indirectly because
>     what's actually being restarted is not the RTCIceTransport but the
>     RTCIceListener which both are attached.
>
>
> ​If you called IceTransport.restart()​ on an IceTransport that came 
> from IceListener, that would "detach" itself from the Listener.  Why 
> would you want to stay attached to the IceListener?
>