Re: ice restart ?

Would it make sense to put the four options (A-D) on a slide and bringing
it up at the next VC meeting?  I'm happy with any of them. But I'd like to
hear what other people think.


On Mon, Apr 28, 2014 at 1:13 PM, Robin Raymond <robin@hookflash.com> wrote:

>
>
> 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 <pthatcher@google.com>
>  April 28, 2014 at 1:42 PM
>
>
>
> On Mon, Apr 28, 2014 at 10:33 AM, Robin Raymond <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?
>
>