Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RTCIceTransportState and IceGatherer pruning #197

aboba opened this issue May 4, 2015 · 2 comments

RTCIceTransportState and IceGatherer pruning #197

aboba opened this issue May 4, 2015 · 2 comments


Copy link

aboba commented May 4, 2015

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

Copy link
Contributor Author

aboba commented May 5, 2015

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

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 aboba added the 1.1 label May 6, 2015
Copy link
Contributor Author

aboba commented May 6, 2015

How about the following edits to Section 3.7?

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

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.

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.

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.

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.

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

robin-raymond pushed a commit that referenced this issue May 7, 2015

- Clarified handling of incoming connectivity checks prior to calling iceTransport.start(), as noted in:

- Clarified handling of incoming DTLS packets, as noted in:

- Added RTCIceGatherer as an optional argument to the RTCIceTransport constructor, as noted in:

- Clarified handling of contradictory RTP/RTCP multiplexing settings, as noted in:

- Clarified error handling relating to RTCIceTransport, RTCDtlsTransport and RTCIceGatherer objects in the "closed" state, as noted in:

- Added component method and createAssociatedGatherer() method to the RTCIceGatherer object, as noted in:

- Added close() method to the RTCIceGatherer object as noted in:

- Clarified behavior of TCP candidate types, as noted in:

- Clarified behavior of iceGatherer.onlocalcandidate, as noted in:

- Updated terminology in Section 1.1 as noted in:

- Updated RTCDtlsTransportState definitions, as noted in:

- Updated RTCIceTransportState definitions, as noted in:
@aboba aboba closed this as completed May 14, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

2 participants