- From: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Date: Wed, 30 Jul 2014 00:11:54 +0000
- To: Peter Thatcher <pthatcher@google.com>, Robin Raymond <robin@hookflash.com>
- CC: "public-ortc@w3.org" <public-ortc@w3.org>
- Message-ID: <5c7101474e4d4f9a8ba66c0431563ac5@SN2PR03MB031.namprd03.prod.outlook.com>
Is there an easy way to figure out whether a new RTCDtlsTransport is needed or not? For example, can we create a new RTCDtlsTransport if the certificate fingerprint obtained from the remote peer changes, and keep the existing RTCDtlsTransport if it remains the same? From: Peter Thatcher [mailto:pthatcher@google.com] Sent: Tuesday, July 29, 2014 5:01 PM To: Robin Raymond Cc: public-ortc@w3.org Subject: Re: remote side is restarting ICE issues I'm think I'm OK with requiring a new DTLS transport whenever you do an ICE restart. But if we do that, then why do we need a restart method at all? Couldn't one just create a new IceTransport and new DtlsTransport and swap it out under the RtpSender and RtpReceiver when it's ready? On Thu, Jul 24, 2014 at 12:14 PM, Robin Raymond <robin@hookflash.com<mailto:robin@hookflash.com>> wrote: 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<mailto: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<mailto:pthatcher@google.com>> wrote: > On Tue, Jul 22, 2014 at 9:08 AM, Robin Raymond <robin@hookflash.com<mailto: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 Wednesday, 30 July 2014 00:12:40 UTC