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

On 09/18/2015 03:40 PM, Peter Thatcher 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 this point I'd like to examine the purpose of the aggregate state.

I *think* the point is to answer the question "does everything work at
the moment?".

In the fully bundled case, adding a new ICETransport does not happen.
In the unbundled case, adding a new ICETransport can happen as the
result of a negotiation - adding new tracks that should go over a
different transport. Thus, after adding the new transport, there are
things that do NOT work (the tracks that were supposed to go over the
new ICETransport).

Result: at T2 and T3, the aggregate state should NOT be "connected".

Note: The list of states for RTCIceConnectionState is still "new",
"checking", "connected", "completed".
It's the "new" and "checking" state that should not cause the aggregate
state to be "connected".
I can't bring myself to care much whether it's "new" or "connecting" -
both seem reasonably true.

Note(2): RTCICEConnectionState "new" is a bit weird, in that it
collapses 2 things:
- ICE Agent is gathering addresses (and will leave the state automagically)
- ICE Agent is waiting for remote addresses to be supplied (and won't
leave the state until it gets some).
It's tempting to define only the last one as "new". But that's not the
present discussion.

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


-- 
Surveillance is pervasive. Go Dark.