RE: DTLS/SRTP: potential API issues?

Roman said:

“Based on this, your initial statement about calling start on RTCDtlsTransport once is effectively irrelevant. An API user can initiate a new DTLS handshake at any time (including re-key) by creating a new RTCDtlsTransport, configuring the relevant parameters and associating it with an existing RTCICETransport. All the tools needed to shoot oneself in the foot with the current WebRTC implementation are ready and provided to the API user. On the other hand, I do not think this needs to be specifically disabled since there are valid use cases when such functionality is needed to interwork with valid DTLS and DTLS-SRTP implementations.”

[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?