aboba
commented
9 years ago 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.
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”.