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

What is PeerConnection.connectionState when some IceTransports are new and some are connected?

From: Peter Thatcher <pthatcher@google.com>
Date: Fri, 18 Sep 2015 15:40:57 -0700
Message-ID: <CAJrXDUE1JZUWM-oCCSBwkXW7bMcuW5xOxFOJRLU=Lue1kRTsyQ@mail.gmail.com>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
Someone already tried to implement PeerConnection.connectionState:
https://github.com/fippo/adapter/commit/ae3004a9a8efed0eee419e07a037904701679e0d

While reading it, I realized we have a state in PR #291 which isn't
covered:  if there are some IceTranpsorts in the new state and other
IceTranpsorts in the connected state.  What's the aggregate state?  At the
f2f, the rules I put on the slide made it into the connected state.  But
the rules I typed in the PR leave it undefined.   Currently in the PR, the
rules are, basically:

If any connecting (ignoring closed/failed/disconnected) => connecting
If all connected (ignoring closed/failed/disconnected) => connected

Which leaves it unclear what to do with some connected but non connecting.


In other words, imagine this timeline:

T0: transport1 = new; aggregate: new
T1: transport1 = connecting; aggregate: connecting
T1: transport1 = connected;  aggregate: connected
T2: transport1 = connected; transport2 = new; aggregate: ???
T3: transport1 = connecting; transport2 = connecting; aggregate: connecting
T4: transport1 = connecting; transport2 = connecting; transport3 = new;
aggregate: connecting
T5: transport1 = connecting; transport2 = connected; transport3 = new;
aggregate: ???


I think our choices are:

A.  aggregate at T2/T5 is new.  This means that transport2 going from
connecting to connected at T5 causes the aggregate to go from connecting to
new, which is a little weird.  This is how my slides at the f2f proposed it.

B.  aggregate at T2/T5 is connected.  This means adding a new transport at
T2 doesn't affect the aggregate until it goes to connecting at T3, which is
a little weird.

C.  aggregate at T2/T5 is new and aggregate at T3 is also new.  This means
that a transport going to connecting doesn't affect the aggregate until all
of the transports get past the "new" state, which means that the aggregate
a T3 is new, even though transport2 is already connecting, which is a
little weird.

D.  Add a new state.  partially-connected?


As weird as it sounds, I'm thinking D is the best option.  At least it
tells JS exactly what is going on; it's partially connected, it isn't
connecting, it isn't failed, and it isn't disconnected.
Received on Friday, 18 September 2015 22:42:04 UTC

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