RE: remote side is restarting ICE issues

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.

Received on Wednesday, 30 July 2014 20:47:33 UTC