RTCIceTransportState and IceGatherer pruning

[aboba]

From Robin Raymond:

If an ice transport has exhausted all candidate testing possible (but not found any route) but end of candidates is not received yet, what state is the ice transport in?

not connected - no route is possible
not complete - no route is possible
not checking - no candidate available to check
disconnected?? - kind of implies it’s failed / done, but with Trickle ICE it’s not either failed or done in this case.

In Section 3.7, the definition of "disconnected" state says:

“Liveness checks have failed (such as those in [CONSENT]). This may trigger intermittently (and resolve itself without action).”

Based on that text, it would seem that RTCIceTransportState should be "disconnected", BUT...

We are proposing that Section 5.1 (RTCIceGatherer Overview) say the following:

“The RTCIceGatherer does not prune local candidates until at least one RTCIceTransport object has become associated and all associated RTCIceTransport objects are in the "completed" or "disconnected" state.”

But we don’t want to prune in disconnected state when there’s no “end of candidates”.

[aboba]

Here is what draft-ietf-mmusic-trickle-ice Section 8.1 says:

8.1. Check List and Timer State Updates

The vanilla ICE specification requires that agents update check lists
and timer states upon completing a connectivity check transaction.
During such an update vanilla ICE agents would set the state of a
check list to Failed if the following two conditions are satisfied:

o all of the pairs in the check list are either in the Failed or
Succeeded state;

o if at least one of the components of the media stream has no pairs
in its valid list.

With trickle ICE, the above situation would often occur when
candidate harvesting and trickling are still in progress and it is
perfectly possible that future checks will succeed. For this reason
trickle ICE agents add the following conditions to the above list:

o all candidate harvesters have completed and the agent is not
expecting to discover any new local candidates;

o the remote agent has sent an end-of-candidates indication for that
check list as described in Section 9.3.

Vanilla ICE requires that agents then update all other check lists,
placing one pair in each of them into the Waiting state, effectively
unfreezing all remaining check lists. Given that with trickle ICE,
other check lists may still be empty at that point, a trickle ICE
agent SHOULD also maintain an explicit Active/Frozen state for every
check list, rather than deducing it from the state of the pairs it
contains. This state should be set to Active when unfreezing the
first pair in a list or when that couldn't happen because a list was
empty.

Also, Section 9.3 says:

Receiving an end-of-candidates notification allows an agent to update
check list states and, in case valid pairs do not exist for every
component in every media stream, determine that ICE processing has
failed. It also allows agents to speed ICE conclusion in cases where
a candidate pair has been validates but it involves the use of lower-
preference transports such as TURN. In such situations some
implementations may choose to wait in case higher-priority candidates
are received and end-of-candidates provides an indication that this
is not going to happen.

An agent MAY also choose to generate an end-of-candidates event
before candidate harvesting has actually completed, if the agent
determines that harvesting has continued for more than an acceptable
period of time. However, an agent MUST NOT send any more candidates
after it has send an end-of-candidates notification.

When performing half trickle agents SHOULD send end-of-candidates
together with their initial offer unless they are planning on
potentially sending additional candidates in case the remote party
turns out to actually support trickle ICE.

When end-of-candidates is sent as part of an offer or an answer it
can appear as a session-level attribute, which would be equivalent to
having it appear in all m-lines.

Once an agent sends the end-of-candidates event, it will update the
state of the corresponding check list as explained in section
Section 8.1. Past that point agents MUST NOT send any new
candidates. Once an agent has received an end-of-candidates
indication, it MUST also ignore any newly received candidates for
that media stream. Adding new candidates to the negotiation is hence
only possible through an ICE restart.

[aboba]

How about the following edits to Section 3.7?

new
The RTCIceTransport object is waiting for remote candidates to be supplied. In this state the object can respond to incoming connectivity checks.

checking
The RTCIceTransport has received at least one remote candidate, and a local and remote RTCIceCandidateComplete dictionary was not added as the last candidate. In this state the RTCIceTransport is checking candidate pairs but has not yet found a successful candidate pair, or liveness checks have failed (such as those in [CONSENT]) on a previously successful candidate pair.

connected
The RTCIceTransport has received a response to an outgoing connectivity check, or has received incoming DTLS/media after a successful response to an incoming connectivity check, but is still checking other candidate pairs to see if there is a better connection. In this state outgoing media is permitted.

completed
A local and remote RTCIceCandidateComplete dictionary was added as the last candidate to the RTCIceTransport and all appropriate candidate pairs have been tested and at least one functioning candidate pair has been found.

disconnected
A local and remote RTCIceCandidateComplete dictionary was added as the last candidate to the RTCIceTransport and all appropriate candidate pairs have been tested and failed.

closed
The ICE Transport has shut down and is no longer responding to STUN requests.