What event do we fire when the DTLS handshake fails, or when DTLS-SRTP key extraction fails?

If a DTLS handshake fails, what event should fire on the PeerConnection?.

I can see three options:

A.  Fire PeerConnection.iceconnectionstatechange, and the state goes to
disconnected/failed.

B.  DtlsTransport.onstatechange, and the state goes to failed.

C.  Add PeerConnection.onerror, and fire that.


I think we should definitely do B.  The question I have is: should we also
do A or C (or both)?

While A is not technically true (it's the DTLS state that's broken, not the
ICE state), the reason for doing this is to avoid the application from
seeing ICE connected, but then having nothing work (I'm guessing very few
applications will remember to listen to DtlsTransport.onstatechange,
whereas nearly all will listen to PeerConnection.iceconnectionstatechange).


FYI, Chrome currently does A.




Similarly, what if DTLS succeeds, but DTLS-SRTP key extraction fails?  Do
we consider it a complete DTLS failure (do A or B), or do we consider the
DTLS transport partially usable (for data channels, but not for RTP)?

FYI, Chrome currently does something quite strange: it returns an error the
next time SetLocalDescription or SetRemoteDescription is called.  This
happens because it signals an internal version of PeerConnection.onerror
internally, but that error never has anywhere to go up to the Javascript.
The impetus for this email is that we want to improve on this behavior, but
we want to make sure we change it to the right behavior so we don't have to
change it again later :).