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

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

From: Peter Thatcher <pthatcher@google.com>
Date: Wed, 23 Sep 2015 09:24:13 -0700
Message-ID: <CAJrXDUHA0QzzbPwRPsD65C4-z+9VFLOx+G3XuV7msNsACV0R8Q@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
I agree with your reasoning and have switched to A, which is "connected if
it's a mix of new and connected".

On Wed, Sep 23, 2015 at 8:54 AM, Peter Thatcher <pthatcher@google.com>
wrote:

>
>
> 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.
>>
>>
>
Received on Wednesday, 23 September 2015 16:25:25 UTC

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