Re: remote side is restarting ICE issues

Thanks Emil. I’m not certain you are wrong though. What should be done vs what is done aren’t always the same.

But it also occurred to me after that we can tell if a device has changed or not by virtue of the fingerprint changing. No fingerprint change = no device change. Fingerprint change = device change + redoing of DTLS handshake.

Thus if they need to do a change, they can do so by creating new DTLS transport objects and new ICE transport objects in that situation to be sure packets are routed properly to the correct DTLS context.

-- 
Robin Raymond

On July 30, 2014 at 3:13:02 AM, Emil Ivov (emcho@jitsi.org) wrote:

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

Received on Wednesday, 30 July 2014 11:58:24 UTC