RE: Issue 197: RTCIceTransportState and IceGatherer pruning

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.

-----Original Message-----
From: Bernard Aboba 
Sent: Monday, May 4, 2015 1:06 PM
To: public-ortc@w3.org
Subject: Issue 197: RTCIceTransportState and IceGatherer pruning

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

Received on Tuesday, 5 May 2015 18:02:02 UTC