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

On Fri, Aug 7, 2015 at 1:47 PM, Peter Thatcher <pthatcher@google.com> wrote:

> 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.
>

Yes, this sees like it



> 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.
>

A seems wrong :)

Maybe we need some sort of bigger "This connection is busted" thing




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

How do you expect this to happen? The other side rejects the use_srtp
extension?

-Ekr

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 :).
>
>
>
>
>
>