RE: remote side is restarting ICE issues

Yes that sounds good to me!

--sent from my mobile
On 30 Jul 2014 10:47 PM, "Bernard Aboba" <Bernard.Aboba@microsoft.com>
wrote:

> Emil said:
>
> > 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.
>
> [BA] Yes - so if there is an existing dialog, we can presume that the
> endpoint is the same even if we see a different certificate fingerprint.
>
> > 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.
>
> [BA] If the endpoint remains the same, it would be desirable to avoid a
> new DTLS handshake.  This means not creating a new RTCDtlsTransport, but
> just creating a new RTCIceTransport.  In practice, I think this would
> require RTCDtlsTransport to support a setTransport method, so that the new
> RTCIceTransport could be used when it is ready.
>
> We had had some debate about whether RTCDtlsTransport.setTransport was
> really needed, but this seems like a valid use case for it.
>