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

And if don't want a new state, I'd recommend going with A, that it's "new",
which is the least weird, in my opinion.

On Fri, Sep 18, 2015 at 3:40 PM, Peter Thatcher <pthatcher@google.com>
wrote:

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