RE: DTLS/SRTP: potential API issues?

Roman said:

[BA] It is true that the developer could construct a new RTCDtlsTransport based on an existing RTCIceTransport and then call RTCDtlsTransport.start().  However, my assumption is that doing this would not result in a DTLS re-negotiation (e.g. a DTLS exchange using an existing crypto-context) or a session resumption, although it would cause a new DTLS negotiation to occur.  So yes, the DTLS role, fingerprints, etc. would change and a new DTLS/SRTP key would be derived.   Are you saying that a new DTLS negotiation on an existing IceTransport would be likely to fail with existing implementations?

This is exactly what I am saying. Existing implementation will only expect a new DTLS session negotiation if transport parameters have changed. They will not handle a new DTLS session over the existing ICE transport connection and they have no way to demultiplex two DTLS sessions over the same ICE connection.

[BA] I guess there are two ways to address this:


1.       Prevent an RTCDtlsTransport from being constructed from an RTCIceTransport that isn’t in the “new” state (e.g. construct the RTCDtlsTransport before calling IceTransport.start()) OR

2.       Clarify the protocol specifications to require that implementations support renegotiation and DTLS/SRTP rekey.