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

Re: A Proposal for aggregate PeerConnection.dtlsstate

From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 4 Sep 2015 19:37:04 -0700
Message-ID: <CABkgnnU91K73nsxHWsSz=BWZ32q-+p9tiSkmvw_v5+o51oVKXA@mail.gmail.com>
To: Peter Thatcher <pthatcher@google.com>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
I think that I would agree with @juberti's comments on github for
this.  We should look at changing to using a `connectionState` that
encompassed more state rather than providing more knobs that are both
not aggregated enough for the cases you describe and aggregated too
much to be useful for anything else.

On 4 September 2015 at 18:06, Peter Thatcher <pthatcher@google.com> wrote:
> I've been thinking more about https://github.com/w3c/webrtc-pc/issues/278 :
> How does the JS know that something is wrong with DTLS, but not ICE?  And
> I've come to the conclusion that the problem isn't error reporting.  The
> problem is that our PeerConnection "aggregate state" is lacking.
> Right now, PeerConnection has two aggregate state across all IceTransports:
> PeerConnection.iceconnectonstate and PeerConnection.icegatheringstate.  But
> is has no aggregate state across all DtlsTransports.   This means that
> applications that listen to PeerConnection.iceconnectionstate to know if the
> peers are connected will
>
> 1.  Think things are fully connected before they fully are (by at least 2
> RTTs).  No media can flow until DTLS is connected.
> 2.  Thnk things are fully connected even when they are not, in the case that
> DTLS fails to connect but ICE is connected.
>
>
> To fix this, I propose we add one more aggregate state:
>
> partial interface PeerConnection {
>   readonly attribute DtlsTransportState dtlsState;
>   attribute EventHandler ondtlsstatechange;
> }
>
> Where the state is aggregated as follows:
> 1.  if any of the DtlsTransports are in the failed state => failed
> 2.  else if any of the DtlsTransports are in the connecting state =>
> connecting
> 3.  else if all of the DtlsTransports are in the new state or closed state
> => new
> 4.  else if all of the DtlsTransports are in the connected state or closed
> state => connected
> 5.  else => connecting (mix of new and connected)
>
>
> Applications can use it like they are currently are use iceConnectionState,
> except now they will have a more accurate idea of if things a "fully"
> connected:
>
> pc.ondtlsstatechange = function() {
>   if (pc.dtlsstate == "failed") {
>     // Uh-oh!
>   } else if (pc.dtlsstate == "connected") {
>     // Great!
>   } else {
>     // meh
>   }
> }
>
>
>
> For more detail, I have created PR 291
> (https://github.com/w3c/webrtc-pc/pull/291).
Received on Saturday, 5 September 2015 02:37:32 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:46 UTC