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: Fri, 18 Sep 2015 15:57:24 -0700
Message-ID: <CAJrXDUG5OvCtduOg+Lcw=4V80BzNt5bCDx9Qh5uefNha877Zig@mail.gmail.com>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
Actually, I went to type A in the PR, and it was complicated.  Writing the
spec for B is much more simple.  Perhaps that's a sign that it's a better
idea than A (it's easier read and understand what it means).  So I change
my mind:  if we don't want a new state, let's go with B.

And that's what's in the PR now.

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

> 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.
Received on Friday, 18 September 2015 22:58:32 UTC

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