Re: ice restart ?

Right - in that case I'm fine with your "a" or my new option "d" (which 
I thought was your "a" as I misread your proposal). But either would work.

As for "c", yes if we did an implicit detach and replace of the 
RTCIceListener that would be okay, except you would still need my "d" to 
be able to fix "iceTransport2" when you change "iceTransport1". I'm not 
a fan of "c", although it has the advantage of being very clear how 
restart works but I still don't like it as much and puts more surface to 
the API.

-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?
>
>
>
>     -Robin
>
>
>>     Peter Thatcher <mailto:pthatcher@google.com>
>>     April 28, 2014 at 1:11 PM
>>
>>
>>
>>     On Sat, Apr 26, 2014 at 5:42 AM, Robin Raymond
>>     <robin@hookflash.com <mailto:robin@hookflash.com>> wrote:
>>
>>         [...]
>>
>>
>>
>>     ​We've chatted about this before.  I think our 3 options were:
>>
>>     a.  Create a new IceTranport (or IceListener).  This would
>>     require being able to swap out the .transport of either the
>>     DtlsTransport or the RtpSender/RtpReceiver.  This seems elegant,
>>     but does add some implementation complexity, and some burden to
>>     the JS.
>>
>>     b.  Allo​w the JS to set the ICE ufrag/pwd at any time.  This
>>     would be really simple, but has some security concerns.
>>
>>     c.  Add an IceTransport.restart() method that changes the
>>     ice/frag and restarts the machine.  This is pretty simple and
>>     doesn't have any security concerns, and not much burden to the JS.
>>
>>     ​I don't remember if we ever decided on one. I'd be happy with
>>     any of them.​
>>
>>
>>
>>         -Robin
>>
>>
>>
>
> Peter Thatcher <mailto:pthatcher@google.com>
> April 28, 2014 at 1:11 PM
>
>
>
> On Sat, Apr 26, 2014 at 5:42 AM, Robin Raymond <robin@hookflash.com 
> <mailto:robin@hookflash.com>> wrote:
>
>
>     In WebRTC 1.0 they have the option "iceRestart" to create new ice
>     credentials on an existing transport.
>
>     For the ORTC API, we have an RTCIceListener where every
>     RTCIceTransport created with the same RTCIceListener therefor
>     shares the same ice credentials (because they share the same ice
>     host / reflexive / relay candidates). I'm assuming (maybe
>     incorrectly) that we need to support changing the existing
>     RTCIceListener's ice credentials as well as opposed to just
>     creating a new RTCIceTransport based on a new implicit
>     RTCIceListener. Is this true?
>
>
>     If it's true, then we have to expose the appropriate
>     method/mechanism to allow the restart. If it's false, then
>     creating a new RTCIceTransport could impact the idea of implicit
>     ice freezing based on RTCIceTransport construction order (since
>     new objects are thus put to the last of the implicit freeze order).
>
>     Peter mentioned he was going to propose an alternative strategy
>     for RTC/RTCP non-mux and ice freezing with a similar idea of an
>     RTCSession (or RTCContext) but with a different exposed mechanism.
>     That might address the concern about ice freezing should the
>     answer be "if you want ice restart, simply create a new
>     RTCIceTransport from scratch". So I'm eager to see that proposal.
>
>
>
> ​We've chatted about this before.  I think our 3 options were:
>
> a.  Create a new IceTranport (or IceListener).  This would require 
> being able to swap out the .transport of either the DtlsTransport or 
> the RtpSender/RtpReceiver.  This seems elegant, but does add some 
> implementation complexity, and some burden to the JS.
>
> b.  Allo​w the JS to set the ICE ufrag/pwd at any time.  This would be 
> really simple, but has some security concerns.
>
> c.  Add an IceTransport.restart() method that changes the ice/frag and 
> restarts the machine.  This is pretty simple and doesn't have any 
> security concerns, and not much burden to the JS.
>
> ​I don't remember if we ever decided on one. I'd be happy with any of 
> them.​
>
>
>
>     -Robin
>
>
>
> Robin Raymond <mailto:robin@hookflash.com>
> April 26, 2014 at 8:42 AM
>
> In WebRTC 1.0 they have the option "iceRestart" to create new ice 
> credentials on an existing transport.
>
> For the ORTC API, we have an RTCIceListener where every 
> RTCIceTransport created with the same RTCIceListener therefor shares 
> the same ice credentials (because they share the same ice host / 
> reflexive / relay candidates). I'm assuming (maybe incorrectly) that 
> we need to support changing the existing RTCIceListener's ice 
> credentials as well as opposed to just creating a new RTCIceTransport 
> based on a new implicit RTCIceListener. Is this true?
>
> If it's true, then we have to expose the appropriate method/mechanism 
> to allow the restart. If it's false, then creating a new 
> RTCIceTransport could impact the idea of implicit ice freezing based 
> on RTCIceTransport construction order (since new objects are thus put 
> to the last of the implicit freeze order).
>
> Peter mentioned he was going to propose an alternative strategy for 
> RTC/RTCP non-mux and ice freezing with a similar idea of an RTCSession 
> (or RTCContext) but with a different exposed mechanism. That might 
> address the concern about ice freezing should the answer be "if you 
> want ice restart, simply create a new RTCIceTransport from scratch". 
> So I'm eager to see that proposal.
>
> -Robin
>