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

On Sun, Sep 20, 2015 at 7:35 AM, Harald Alvestrand <harald@alvestrand.no>
wrote:

> On 09/18/2015 03:40 PM, Peter Thatcher wrote:
>
> Someone already tried to implement PeerConnection.connectionState:
> <https://github.com/fippo/adapter/commit/ae3004a9a8efed0eee419e07a037904701679e0d>
> 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?".
>

​I think it's more like "are we connected?  If not, are we connecting?  If
not, are we completely failed?".​
​


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

​That would rule out B.​


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

​So you'd be happy with A.  ​


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