Re: remote side is restarting ICE issues

On Wed, Jul 30, 2014 at 12:13 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.

The "handover" can be seamless, because the JS need not call
RtpReceiver.setTransport on the new DtlsTransport until it is in a
functioning state.  It can continue on the old DtlsTransport until
then.  There is no problem with having multiple DtlsTransport objects
at the same time.


>
> --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 16:53:19 UTC