DTLS/SRTP: potential API issues?

There has been a recent post on the RTCWEB WG mailing list relating to WebRTC 1.0 and the behavior of the DTLS/SRTP implementations.  It began with this post:

http://www.ietf.org/mail-archive/web/rtcweb/current/msg13584.html



Some of the points made in the thread:



*       Existing implementations disable renegotiation, session resumption and/or re-export of SRTP keying material.  So to assure interoperability, WebRTC implementations should probably not attempt to renegotiate or resume a session.

*        WebRTC 1.0 does not allow the DTLS role to be changed in mid-stream, and is currently unclear about changing the certificate fingerprint.  Since without renegotiation you can't exchange new certificates, there probably should be a prohibition on changing fingerprints.



Reviewing the implications for the ORTC API, at first glance I didn't see a way for developers to shoot themselves in the foot:



*       Section 2.3.2 prohibits calling RTCDtlsTransport.start() more than once.   As a result, there is no way to change the remote DTLS parameters once .start() is called,. and no way to programmatically force renegotiation.

*       RTCIceTransport is supplied in the constructor and cannot be changed.



Are there potential issues that I missed?  Assuming that clarifications go into the protocol documents, is there any text worth inserting into the ORTC API document?