Re: ice restart ?

On Sat, Apr 26, 2014 at 5:42 AM, Robin Raymond <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
>
>
>