Re: remote side is restarting ICE issues

Actually, I just thought about IceTransport.setRemoteParameters a
little more, and realized that we maybe don't need it.  We can,
instead, simple create a new IceTransport and start it using the same
listener object with the new remote parameters.  It's the same as
doing a media fork and then stopping the old IceTransport (or letting
it die).  However, this means we either need to create a new
DtlsTransport all the time, or add a DtlsTransport.setTransport
method.

If we had to choose between IceTransport.setRemoteParameters and
DtlsTransport.setTransport, I think I'd rather have
DtlsTransport.setTransport, but I could be convinced either way.

Thoughts from anyone else?

On Thu, Jul 24, 2014 at 2:39 PM, Peter Thatcher <pthatcher@google.com> wrote:
> On Tue, Jul 22, 2014 at 9:08 AM, 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
>
> That's a good point.  The remote side will signal the new
> ufrag/password, and we need a way to pass that down to the local side.
> And it's per-IceTransport, so it should be on the IceTransport, not
> the IceTransportController.  Maybe it should be called
> .setRemoteParameters(IceParameters).
>
>>
>> 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.
>
> If you end up going to somewhere with new DTLS credentials, then you
> need to have those new credentials and you need to make a new
> DltsTransport with those credentials.  If the credentials are the
> same, then you don't need to make a new DtlsTransport, and you can use
> the existing one.  But you can't decide either way what to do until
> you know the new credentials (or that they didn't change).  I don't
> know much about SIP re-invite, but if you end up going to a new device
> and you don't know its new DTLS credentials, then I don't see how it
> can possible work.  Either SIP is totally busted, or you can just make
> a new DtlsTransport at the point in time when you have new DTLS
> credentials.
>
>
>>
>> --
>> Robin Raymond
>>

Received on Thursday, 24 July 2014 18:47:56 UTC