Re: A Proposal for aggregate PeerConnection.dtlsstate

OK, I have changed the PR from PeerConnection.dltsState to
PeerConnection.connectionState, with the following logic:

Where the state is aggregated as follows:
1.  if any of the DtlsTransports or IceTransports are in the failed state
=> failed
2.  else if any of the DtlsTransports or IceTransports are in the
connecting state or checking state or disconnected state => connecting
3.  else if all of the DtlsTransports and IceTransports are in the new
state or closed state => disconnected
4.  else if all of the DtlsTransports and IceTransports are in the
connected state or or completed state or closed state => connected
5.  else => connecting (mix of new and connected and checking and closed)

I'm not sure if it's quite right, but it's a start.

On Fri, Sep 4, 2015 at 7:37 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:

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