Re: remote side is restarting ICE issues

If we keep the DtlsTransport, we need DtlsTransport.setTransport, which we
don't currently have (right?).


On Tue, Jul 29, 2014 at 5:11 PM, Bernard Aboba <Bernard.Aboba@microsoft.com>
wrote:

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