- From: Peter Thatcher <pthatcher@google.com>
- Date: Wed, 23 Sep 2015 09:24:13 -0700
- To: Harald Alvestrand <harald@alvestrand.no>
- Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <CAJrXDUHA0QzzbPwRPsD65C4-z+9VFLOx+G3XuV7msNsACV0R8Q@mail.gmail.com>
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