W3C home > Mailing lists > Public > public-webrtc@w3.org > August 2015

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

From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 7 Aug 2015 14:39:54 -0700
Message-ID: <CABcZeBOEaGkdiQeOoxJPe9m5z7TmvMxSD6B3UeZt7iKD8yuXpw@mail.gmail.com>
To: Peter Thatcher <pthatcher@google.com>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
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


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 :).
Received on Friday, 7 August 2015 21:41:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:08 UTC