Re: remote side is restarting ICE issues

Correct, I agree, and Martin suggested we do exactly that for restart and avoid a restart method. However, there has been some concern expressed about the transport controller and it’s state getting messed up, the process being overly complex to setup again, and/or performing the restart on all transports at the same time.

My personal preference has always been to tell people to create a new transport to do a restart with a new DTLS transport (or reusing existing if that’s possible/necessary).

-- 
Robin Raymond

On July 24, 2014 at 2:47:29 PM, Peter Thatcher (pthatcher@google.com) wrote:

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  
>>