Re: remote side is restarting ICE issues

FWIW, while a SIP re-INVITE can be on a new IP address with new codecs and
potentially new crypto, it is always in the same dialog and hence between
the same two endpoints. I know we chatted about this on the last CG meeting
so I appologise if I mislead but while anything can change, the device is
supposed to be the same.

Not sure to what extent we should care exactly but what got me thinking was
the fact that mandating a new DTLS handshake on every ICE restart could
potentially be somewhat disruptive. Media is supposed to continue flowing
during an ICE restart so that you could only switch once you have
connectivity on a new candidate pair and potentially keep the entire
"handover" seamless.

I think requiring a new DTLS handshake could still be OK but we might want
to make sure that the old context is not invalidated before the new one
succeeds.

--sent from my mobile
On 22 Jul 2014 3:09 PM, "Robin Raymond" <robin@hookflash.com> wrote:

>
> Couple of issues:
>
> 1) We embed the ufrag/password in the “start” method of the ICE transport.
> If the remote side is restarting, does that mean we need to restart too?
> Presumable we have to at minimum flush all candidates. But we can’t call
> start again to update the remote ufrag/password
>
> 2) When I asked about restart causing a retargeting to a new device (i.e.
> new DTLS credentials), I’ve received conflicting information. I heard that
> retargeting only applies to something like TURN vs local candidates not a
> change in device. However, apparently a SIP re-invite can mean targeting to
> an entirely new device. Thus we may receive new ufrag/password and assuming
> it’s a remote restart but it’s actually a retarget to a new device. We have
> no way to know the difference thus we must always assume it’s a new device
> and redo the DTLS handshakes.
>
> --
> Robin Raymond
>
>