RE: remote side is restarting ICE issues

The ufrag/password needs to be changed in the offer which can only be obtained after restart has been called so you can restart after. Only the answer side has that luxury.

-- 
Robin Raymond

On July 30, 2014 at 10:40:32 PM, Peter Thatcher (pthatcher@google.com) wrote:

I had a second thought about the SIP ICE restart rollback thing.  Rather than initiate a restart and the roll it back, could the JS simply not initiate the restart until after it's sure that it won't be rolled back?  Why does it need to initiate the rollback before it is sure that it needs to?

On Jul 30, 2014 1: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.