RFC 5245
Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols
8. Concluding ICE Processing
This section describes how an agent completes ICE.8.1. Procedures for Full Implementations
Concluding ICE involves nominating pairs by the controlling agent and updating of state machinery.8.1.1. Nominating Pairs
The controlling agent nominates pairs to be selected by ICE by using one of two techniques: regular nomination or aggressive nomination. If its peer has a lite implementation, an agent MUST use a regular nomination algorithm. If its peer is using ICE options (present in an ice-options attribute from the peer) that the agent does not understand, the agent MUST use a regular nomination algorithm. If its peer is a full implementation and isn't using any ICE options or is using ICE options understood by the agent, the agent MAY use either the aggressive or the regular nomination algorithm. However, the regular algorithm is RECOMMENDED since it provides greater stability.
8.1.1.1. Regular Nomination
With regular nomination, the agent lets some number of checks complete, each of which omit the USE-CANDIDATE attribute. Once one or more checks complete successfully for a component of a media stream, valid pairs are generated and added to the valid list. The agent lets the checks continue until some stopping criterion is met, and then picks amongst the valid pairs based on an evaluation criterion. The criteria for stopping the checks and for evaluating the valid pairs is entirely a matter of local optimization. When the controlling agent selects the valid pair, it repeats the check that produced this valid pair (by enqueuing the pair that generated the check into the triggered check queue), this time with the USE-CANDIDATE attribute. This check should succeed (since the previous did), causing the nominated flag of that and only that pair to be set. Consequently, there will be only a single nominated pair in the valid list for each component, and when the state of the check list moves to completed, that exact pair is selected by ICE for sending and receiving media for that component. Regular nomination provides the most flexibility, since the agent has control over the stopping and selection criteria for checks. The only requirement is that the agent MUST eventually pick one and only one candidate pair and generate a check for that pair with the USE- CANDIDATE attribute present. Regular nomination also improves ICE's resilience to variations in implementation (see Section 14). Regular nomination is also more stable, allowing both agents to converge on a single pair for media without any transient selections, which can happen with the aggressive algorithm. The drawback of regular nomination is that it is guaranteed to increase latencies because it requires an additional check to be done.8.1.1.2. Aggressive Nomination
With aggressive nomination, the controlling agent includes the USE- CANDIDATE attribute in every check it sends. Once the first check for a component succeeds, it will be added to the valid list and have its nominated flag set. When all components have a nominated pair in the valid list, media can begin to flow using the highest priority nominated pair. However, because the agent included the USE- CANDIDATE attribute in all of its checks, another check may yet complete, causing another valid pair to have its nominated flag set. ICE always selects the highest-priority nominated candidate pair from the valid list as the one used for media. Consequently, the selected pair may actually change briefly as ICE checks complete, resulting in a set of transient selections until it stabilizes.
8.1.2. Updating States
For both controlling and controlled agents, the state of ICE processing depends on the presence of nominated candidate pairs in the valid list and on the state of the check list. Note that, at any time, more than one of the following cases can apply: o If there are no nominated pairs in the valid list for a media stream and the state of the check list is Running, ICE processing continues. o If there is at least one nominated pair in the valid list for a media stream and the state of the check list is Running: * The agent MUST remove all Waiting and Frozen pairs in the check list and triggered check queue for the same component as the nominated pairs for that media stream. * If an In-Progress pair in the check list is for the same component as a nominated pair, the agent SHOULD cease retransmissions for its check if its pair priority is lower than the lowest-priority nominated pair for that component. o Once there is at least one nominated pair in the valid list for every component of at least one media stream and the state of the check list is Running: * The agent MUST change the state of processing for its check list for that media stream to Completed. * The agent MUST continue to respond to any checks it may still receive for that media stream, and MUST perform triggered checks if required by the processing of Section 7.2. * The agent MUST continue retransmitting any In-Progress checks for that check list. * The agent MAY begin transmitting media for this media stream as described in Section 11.1. o Once the state of each check list is Completed: * The agent sets the state of ICE processing overall to Completed. * If an agent is controlling, it examines the highest-priority nominated candidate pair for each component of each media stream. If any of those candidate pairs differ from the
default candidate pairs in the most recent offer/answer
exchange, the controlling agent MUST generate an updated offer
as described in Section 9. If the controlling agent is using
an aggressive nomination algorithm, this may result in several
updated offers as the pairs selected for media change. An
agent MAY delay sending the offer for a brief interval (one
second is RECOMMENDED) in order to allow the selected pairs to
stabilize.
o If the state of the check list is Failed, ICE has not been able to
complete for this media stream. The correct behavior depends on
the state of the check lists for other media streams:
* If all check lists are Failed, ICE processing overall is
considered to be in the Failed state, and the agent SHOULD
consider the session a failure, SHOULD NOT restart ICE, and the
controlling agent SHOULD terminate the entire session.
* If at least one of the check lists for other media streams is
Completed, the controlling agent SHOULD remove the failed media
stream from the session in its updated offer.
* If none of the check lists for other media streams are
Completed, but at least one is Running, the agent SHOULD let
ICE continue.
8.2. Procedures for Lite Implementations
Concluding ICE for a lite implementation is relatively
straightforward. There are two cases to consider:
The implementation is lite, and its peer is full.
The implementation is lite, and its peer is lite.
The effect of ICE concluding is that the agent can free any allocated
host candidates that were not utilized by ICE, as described in
Section 8.3.
8.2.1. Peer Is Full
In this case, the agent will receive connectivity checks from its
peer. When an agent has received a connectivity check that includes
the USE-CANDIDATE attribute for each component of a media stream, the
state of ICE processing for that media stream moves from Running to
Completed. When the state of ICE processing for all media streams is
Completed, the state of ICE processing overall is Completed.
The lite implementation will never itself determine that ICE processing has failed for a media stream; rather, the full peer will make that determination and then remove or restart the failed media stream in a subsequent offer.8.2.2. Peer Is Lite
Once the offer/answer exchange has completed, both agents examine their candidates and those of its peer. For each media stream, each agent pairs up its own candidates with the candidates of its peer for that media stream. Two candidates are paired up when they are for the same component, utilize the same transport protocol (UDP in this specification), and are from the same IP address family (IPv4 or IPv6). o If there is a single pair per component, that pair is added to the Valid list. If all of the components for a media stream had one pair, the state of ICE processing for that media stream is set to Completed. If all media streams are Completed, the state of ICE processing is set to Completed overall. This will always be the case for implementations that are IPv4 only. o If there is more than one pair per component: * The agent MUST select a pair based on local policy. Since this case only arises for IPv6, it is RECOMMENDED that an agent follow the procedures of RFC 3484 [RFC3484] to select a single pair. * The agent adds the selected pair for each component to the valid list. As described in Section 11.1, this will permit media to begin flowing. However, it is possible (and in fact likely) that both agents have chosen different pairs. * To reconcile this, the controlling agent MUST send an updated offer as described in Section 9.1.3, which will include the remote-candidates attribute. * The agent MUST NOT update the state of ICE processing when the offer is sent. If this subsequent offer completes, the controlling agent MUST change the state of ICE processing to Completed for all media streams, and the state of ICE processing overall to Completed. The states for the controlled agent are set based on the logic in Section 9.2.3.
8.3. Freeing Candidates
8.3.1. Full Implementation Procedures
The procedures in Section 8 require that an agent continue to listen for STUN requests and continue to generate triggered checks for a media stream, even once processing for that stream completes. The rules in this section describe when it is safe for an agent to cease sending or receiving checks on a candidate that was not selected by ICE, and then free the candidate. When ICE is used with SIP, and an offer is forked to multiple recipients, ICE proceeds in parallel and independently with each answerer, all using the same local candidates. Once ICE processing has reached the Completed state for all peers for media streams using those candidates, the agent SHOULD wait an additional three seconds, and then it MAY cease responding to checks or generating triggered checks on that candidate. It MAY free the candidate at that time. Freeing of server reflexive candidates is never explicit; it happens by lack of a keepalive. The three-second delay handles cases when aggressive nomination is used, and the selected pairs can quickly change after ICE has completed.8.3.2. Lite Implementation Procedures
A lite implementation MAY free candidates not selected by ICE as soon as ICE processing has reached the Completed state for all peers for all media streams using those candidates.9. Subsequent Offer/Answer Exchanges
Either agent MAY generate a subsequent offer at any time allowed by RFC 3264 [RFC3264]. The rules in Section 8 will cause the controlling agent to send an updated offer at the conclusion of ICE processing when ICE has selected different candidate pairs from the default pairs. This section defines rules for construction of subsequent offers and answers. Should a subsequent offer be rejected, ICE processing continues as if the subsequent offer had never been made.
9.1. Generating the Offer
9.1.1. Procedures for All Implementations
9.1.1.1. ICE Restarts
An agent MAY restart ICE processing for an existing media stream. An ICE restart, as the name implies, will cause all previous states of ICE processing to be flushed and checks to start anew. The only difference between an ICE restart and a brand new media session is that, during the restart, media can continue to be sent to the previously validated pair. An agent MUST restart ICE for a media stream if: o The offer is being generated for the purposes of changing the target of the media stream. In other words, if an agent wants to generate an updated offer that, had ICE not been in use, would result in a new value for the destination of a media component. o An agent is changing its implementation level. This typically only happens in third party call control use cases, where the entity performing the signaling is not the entity receiving the media, and it has changed the target of media mid-session to another entity that has a different ICE implementation. These rules imply that setting the IP address in the c line to 0.0.0.0 will cause an ICE restart. Consequently, ICE implementations MUST NOT utilize this mechanism for call hold, and instead MUST use a=inactive and a=sendonly as described in [RFC3264]. To restart ICE, an agent MUST change both the ice-pwd and the ice- ufrag for the media stream in an offer. Note that it is permissible to use a session-level attribute in one offer, but to provide the same ice-pwd or ice-ufrag as a media-level attribute in a subsequent offer. This is not a change in password, just a change in its representation, and does not cause an ICE restart. An agent sets the rest of the fields in the SDP for this media stream as it would in an initial offer of this media stream (see Section 4.3). Consequently, the set of candidates MAY include some, none, or all of the previous candidates for that stream and MAY include a totally new set of candidates gathered as described in Section 4.1.1.
9.1.1.2. Removing a Media Stream
If an agent removes a media stream by setting its port to zero, it MUST NOT include any candidate attributes for that media stream and SHOULD NOT include any other ICE-related attributes defined in Section 15 for that media stream.9.1.1.3. Adding a Media Stream
If an agent wishes to add a new media stream, it sets the fields in the SDP for this media stream as if this was an initial offer for that media stream (see Section 4.3). This will cause ICE processing to begin for this media stream.9.1.2. Procedures for Full Implementations
This section describes additional procedures for full implementations, covering existing media streams. The username fragments, password, and implementation level MUST remain the same as used previously. If an agent needs to change one of these, it MUST restart ICE for that media stream. Additional behavior depends on the state ICE processing for that media stream.9.1.2.1. Existing Media Streams with ICE Running
If an agent generates an updated offer including a media stream that was previously established, and for which ICE checks are in the Running state, the agent follows the procedures defined here. An agent MUST include candidate attributes for all local candidates it had signaled previously for that media stream. The properties of that candidate as signaled in SDP -- the priority, foundation, type, and related transport address -- SHOULD remain the same. The IP address, port, and transport protocol, which fundamentally identify that candidate, MUST remain the same (if they change, it would be a new candidate). The component ID MUST remain the same. The agent MAY include additional candidates it did not offer previously, but which it has gathered since the last offer/answer exchange, including peer reflexive candidates. The agent MAY change the default destination for media. As with initial offers, there MUST be a set of candidate attributes in the offer matching this default destination.
9.1.2.2. Existing Media Streams with ICE Completed
If an agent generates an updated offer including a media stream that was previously established, and for which ICE checks are in the Completed state, the agent follows the procedures defined here. The default destination for media (i.e., the values of the IP addresses and ports in the m and c lines used for that media stream) MUST be the local candidate from the highest-priority nominated pair in the valid list for each component. This "fixes" the default destination for media to equal the destination ICE has selected for media. The agent MUST include candidate attributes for candidates matching the default destination for each component of the media stream, and MUST NOT include any other candidates. In addition, if the agent is controlling, it MUST include the a=remote-candidates attribute for each media stream whose check list is in the Completed state. The attribute contains the remote candidates from the highest-priority nominated pair in the valid list for each component of that media stream. It is needed to avoid a race condition whereby the controlling agent chooses its pairs, but the updated offer beats the connectivity checks to the controlled agent, which doesn't even know these pairs are valid, let alone selected. See Appendix B.6 for elaboration on this race condition.9.1.3. Procedures for Lite Implementations
9.1.3.1. Existing Media Streams with ICE Running
This section describes procedures for lite implementations for existing streams for which ICE is running. A lite implementation MUST include all of its candidates for each component of each media stream in an a=candidate attribute in any subsequent offer. These candidates are formed identically to the procedures for initial offers, as described in Section 4.2. A lite implementation MUST NOT add additional host candidates in a subsequent offer. If an agent needs to offer additional candidates, it MUST restart ICE. The username fragments, password, and implementation level MUST remain the same as used previously. If an agent needs to change one of these, it MUST restart ICE for that media stream.
9.1.3.2. Existing Media Streams with ICE Completed
If ICE has completed for a media stream, the default destination for that media stream MUST be set to the remote candidate of the candidate pair for that component in the valid list. For a lite implementation, there is always just a single candidate pair in the valid list for each component of a media stream. Additionally, the agent MUST include a candidate attribute for each default destination. Additionally, if the agent is controlling (which only happens when both agents are lite), the agent MUST include the a=remote-candidates attribute for each media stream. The attribute contains the remote candidates from the candidate pairs in the valid list (one pair for each component of each media stream).9.2. Receiving the Offer and Generating an Answer
9.2.1. Procedures for All Implementations
When receiving a subsequent offer within an existing session, an agent MUST reapply the verification procedures in Section 5.1 without regard to the results of verification from any previous offer/answer exchanges. Indeed, it is possible that a previous offer/answer exchange resulted in ICE not being used, but it is used as a consequence of a subsequent exchange.9.2.1.1. Detecting ICE Restart
If the offer contained a change in the a=ice-ufrag or a=ice-pwd attributes compared to the previous SDP from the peer, it indicates that ICE is restarting for this media stream. If all media streams are restarting, then ICE is restarting overall. If ICE is restarting for a media stream: o The agent MUST change the a=ice-ufrag and a=ice-pwd attributes in the answer. o The agent MAY change its implementation level in the answer. An agent sets the rest of the fields in the SDP for this media stream as it would in an initial answer to this media stream (see Section 4.3). Consequently, the set of candidates MAY include some, none, or all of the previous candidates for that stream and MAY include a totally new set of candidates gathered as described in Section 4.1.1.
9.2.1.2. New Media Stream
If the offer contains a new media stream, the agent sets the fields in the answer as if it had received an initial offer containing that media stream (see Section 4.3). This will cause ICE processing to begin for this media stream.9.2.1.3. Removed Media Stream
If an offer contains a media stream whose port is zero, the agent MUST NOT include any candidate attributes for that media stream in its answer and SHOULD NOT include any other ICE-related attributes defined in Section 15 for that media stream.9.2.2. Procedures for Full Implementations
Unless the agent has detected an ICE restart from the offer, the username fragments, password, and implementation level MUST remain the same as used previously. If an agent needs to change one of these it MUST restart ICE for that media stream by generating an offer; ICE cannot be restarted in an answer. Additional behaviors depend on the state of ICE processing for that media stream.9.2.2.1. Existing Media Streams with ICE Running and no remote- candidates
If ICE is running for a media stream, and the offer for that media stream lacked the remote-candidates attribute, the rules for construction of the answer are identical to those for the offerer as described in Section 9.1.2.1.9.2.2.2. Existing Media Streams with ICE Completed and no remote- candidates
If ICE is Completed for a media stream, and the offer for that media stream lacked the remote-candidates attribute, the rules for construction of the answer are identical to those for the offerer as described in Section 9.1.2.2, except that the answerer MUST NOT include the a=remote-candidates attribute in the answer.9.2.2.3. Existing Media Streams and remote-candidates
A controlled agent will receive an offer with the a=remote-candidates attribute for a media stream when its peer has concluded ICE processing for that media stream. This attribute is present in the offer to deal with a race condition between the receipt of the offer,
and the receipt of the Binding response that tells the answerer the candidate that will be selected by ICE. See Appendix B.6 for an explanation of this race condition. Consequently, processing of an offer with this attribute depends on the winner of the race. The agent forms a candidate pair for each component of the media stream by: o Setting the remote candidate equal to the offerer's default destination for that component (e.g., the contents of the m and c lines for RTP, and the a=rtcp attribute for RTCP) o Setting the local candidate equal to the transport address for that same component in the a=remote-candidates attribute in the offer. The agent then sees if each of these candidate pairs is present in the valid list. If a particular pair is not in the valid list, the check has "lost" the race. Call such a pair a "losing pair". The agent finds all the pairs in the check list whose remote candidates equal the remote candidate in the losing pair: o If none of the pairs are In-Progress, and at least one is Failed, it is most likely that a network failure, such as a network partition or serious packet loss, has occurred. The agent SHOULD generate an answer for this media stream as if the remote- candidates attribute had not been present, and then restart ICE for this stream. o If at least one of the pairs is In-Progress, the agent SHOULD wait for those checks to complete, and as each completes, redo the processing in this section until there are no losing pairs. Once there are no losing pairs, the agent can generate the answer. It MUST set the default destination for media to the candidates in the remote-candidates attribute from the offer (each of which will now be the local candidate of a candidate pair in the valid list). It MUST include a candidate attribute in the answer for each candidate in the remote-candidates attribute in the offer.9.2.3. Procedures for Lite Implementations
If the received offer contains the remote-candidates attribute for a media stream, the agent forms a candidate pair for each component of the media stream by:
o Setting the remote candidate equal to the offerer's default
destination for that component (e.g., the contents of the m and c
lines for RTP, and the a=rtcp attribute for RTCP).
o Setting the local candidate equal to the transport address for
that same component in the a=remote-candidates attribute in the
offer.
It then places those candidates into the Valid list for the media
stream. The state of ICE processing for that media stream is set to
Completed.
Furthermore, if the agent believed it was controlling, but the offer
contained the remote-candidates attribute, both agents believe they
are controlling. In this case, both would have sent updated offers
around the same time. However, the signaling protocol carrying the
offer/answer exchanges will have resolved this glare condition, so
that one agent is always the 'winner' by having its offer received
before its peer has sent an offer. The winner takes the role of
controlled, so that the loser (the answerer under consideration in
this section) MUST change its role to controlled. Consequently, if
the agent was going to send an updated offer since, based on the
rules in Section 8.2.2, it was controlling, it no longer needs to.
Besides the potential role change, change in the Valid list, and
state changes, the construction of the answer is performed
identically to the construction of an offer as described in
Section 9.1.3.
9.3. Updating the Check and Valid Lists
9.3.1. Procedures for Full Implementations
9.3.1.1. ICE Restarts
The agent MUST remember the highest-priority nominated pairs in the
Valid list for each component of the media stream, called the
previous selected pairs, prior to the restart. The agent will
continue to send media using these pairs, as described in
Section 11.1. Once these destinations are noted, the agent MUST
flush the valid and check lists, and then recompute the check list
and its states as described in Section 5.7.
9.3.1.2. New Media Stream
If the offer/answer exchange added a new media stream, the agent MUST
create a new check list for it (and an empty Valid list to start of
course), as described in Section 5.7.
9.3.1.3. Removed Media Stream
If the offer/answer exchange removed a media stream, or an answer rejected an offered media stream, an agent MUST flush the Valid list for that media stream. It MUST terminate any STUN transactions in progress for that media stream. An agent MUST remove the check list for that media stream and cancel any pending ordinary checks for it.9.3.1.4. ICE Continuing for Existing Media Stream
The valid list is not affected by an updated offer/answer exchange unless ICE is restarting. If an agent is in the Running state for that media stream, the check list is updated (the check list is irrelevant if the state is completed). To do that, the agent recomputes the check list using the procedures described in Section 5.7. If a pair on the new check list was also on the previous check list, and its state was Waiting, In-Progress, Succeeded, or Failed, its state is copied over. Otherwise, its state is set to Frozen. If none of the check lists are active (meaning that the pairs in each check list are Frozen), the full-mode agent sets the first pair in the check list for the first media stream to Waiting, and then sets the state of all other pairs in that check list for the same component ID and with the same foundation to Waiting as well. Next, the agent goes through each check list, starting with the highest-priority pair. If a pair has a state of Succeeded, and it has a component ID of 1, then all Frozen pairs in the same check list with the same foundation whose component IDs are not 1 have their state set to Waiting. If, for a particular check list, there are pairs for each component of that media stream in the Succeeded state, the agent moves the state of all Frozen pairs for the first component of all other media streams (and thus in different check lists) with the same foundation to Waiting.9.3.2. Procedures for Lite Implementations
If ICE is restarting for a media stream, the agent MUST start a new Valid list for that media stream. It MUST remember the pairs in the previous Valid list for each component of the media stream, called the previous selected pairs, and continue to send media there as described in Section 11.1. The state of ICE processing for each media stream MUST change to Running, and the state of ICE processing MUST change to Running.
10. Keepalives
All endpoints MUST send keepalives for each media session. These keepalives serve the purpose of keeping NAT bindings alive for the media session. These keepalives MUST be sent regardless of whether the media stream is currently inactive, sendonly, recvonly, or sendrecv, and regardless of the presence or value of the bandwidth attribute. These keepalives MUST be sent even if ICE is not being utilized for the session at all. The keepalive SHOULD be sent using a format that is supported by its peer. ICE endpoints allow for STUN-based keepalives for UDP streams, and as such, STUN keepalives MUST be used when an agent is a full ICE implementation and is communicating with a peer that supports ICE (lite or full). An agent can determine that its peer supports ICE by the presence of a=candidate attributes for each media session. If the peer does not support ICE, the choice of a packet format for keepalives is a matter of local implementation. A format that allows packets to easily be sent in the absence of actual media content is RECOMMENDED. Examples of formats that readily meet this goal are RTP No-Op [NO-OP-RTP], and in cases where both sides support it, RTP comfort noise [RFC3389]. If the peer doesn't support any formats that are particularly well suited for keepalives, an agent SHOULD send RTP packets with an incorrect version number, or some other form of error that would cause them to be discarded by the peer. If there has been no packet sent on the candidate pair ICE is using for a media component for Tr seconds (where packets include those defined for the component (RTP or RTCP) and previous keepalives), an agent MUST generate a keepalive on that pair. Tr SHOULD be configurable and SHOULD have a default of 15 seconds. Tr MUST NOT be configured to less than 15 seconds. Alternatively, if an agent has a dynamic way to discover the binding lifetimes of the intervening NATs, it can use that value to determine Tr. Administrators deploying ICE in more controlled networking environments SHOULD set Tr to the longest duration possible in their environment. If STUN is being used for keepalives, a STUN Binding Indication is used [RFC5389]. The Indication MUST NOT utilize any authentication mechanism. It SHOULD contain the FINGERPRINT attribute to aid in demultiplexing, but SHOULD NOT contain any other attributes. It is used solely to keep the NAT bindings alive. The Binding Indication is sent using the same local and remote candidates that are being used for media. Though Binding Indications are used for keepalives, an agent MUST be prepared to receive a connectivity check as well. If a connectivity check is received, a response is generated as discussed in [RFC5389], but there is no impact on ICE processing otherwise.
An agent MUST begin the keepalive processing once ICE has selected candidates for usage with media, or media begins to flow, whichever happens first. Keepalives end once the session terminates or the media stream is removed.11. Media Handling
11.1. Sending Media
Procedures for sending media differ for full and lite implementations.11.1.1. Procedures for Full Implementations
Agents always send media using a candidate pair, called the selected candidate pair. An agent will send media to the remote candidate in the selected pair (setting the destination address and port of the packet equal to that remote candidate), and will send it from the local candidate of the selected pair. When the local candidate is server or peer reflexive, media is originated from the base. Media sent from a relayed candidate is sent from the base through that TURN server, using procedures defined in [RFC5766]. If the local candidate is a relayed candidate, it is RECOMMENDED that an agent create a channel on the TURN server towards the remote candidate. This is done using the procedures for channel creation as defined in Section 11 of [RFC5766]. The selected pair for a component of a media stream is: o empty if the state of the check list for that media stream is Running, and there is no previous selected pair for that component due to an ICE restart o equal to the previous selected pair for a component of a media stream if the state of the check list for that media stream is Running, and there was a previous selected pair for that component due to an ICE restart o equal to the highest-priority nominated pair for that component in the valid list if the state of the check list is Completed If the selected pair for at least one component of a media stream is empty, an agent MUST NOT send media for any component of that media stream. If the selected pair for each component of a media stream has a value, an agent MAY send media for all components of that media stream.
Note that the selected pair for a component of a media stream may not equal the default pair for that same component from the most recent offer/answer exchange. When this happens, the selected pair is used for media, not the default pair. When ICE first completes, if the selected pairs aren't a match for the default pairs, the controlling agent sends an updated offer/answer exchange to remedy this disparity. However, until that updated offer arrives, there will not be a match. Furthermore, in very unusual cases, the default candidates in the updated offer/answer will not be a match.11.1.2. Procedures for Lite Implementations
A lite implementation MUST NOT send media until it has a Valid list that contains a candidate pair for each component of that media stream. Once that happens, the agent MAY begin sending media packets. To do that, it sends media to the remote candidate in the pair (setting the destination address and port of the packet equal to that remote candidate), and will send it from the local candidate.11.1.3. Procedures for All Implementations
ICE has interactions with jitter buffer adaptation mechanisms. An RTP stream can begin using one candidate, and switch to another one, though this happens rarely with ICE. The newer candidate may result in RTP packets taking a different path through the network -- one with different delay characteristics. As discussed below, agents are encouraged to re-adjust jitter buffers when there are changes in source or destination address of media packets. Furthermore, many audio codecs use the marker bit to signal the beginning of a talkspurt, for the purposes of jitter buffer adaptation. For such codecs, it is RECOMMENDED that the sender set the marker bit [RFC3550] when an agent switches transmission of media from one candidate pair to another.11.2. Receiving Media
ICE implementations MUST be prepared to receive media on each component on any candidates provided for that component in the most recent offer/answer exchange (in the case of RTP, this would include both RTP and RTCP if candidates were provided for both). It is RECOMMENDED that, when an agent receives an RTP packet with a new source or destination IP address for a particular media stream, that the agent re-adjust its jitter buffers. RFC 3550 [RFC3550] describes an algorithm in Section 8.2 for detecting synchronization source (SSRC) collisions and loops. These algorithms are based, in part, on seeing different source transport
addresses with the same SSRC. However, when ICE is used, such changes will sometimes occur as the media streams switch between candidates. An agent will be able to determine that a media stream is from the same peer as a consequence of the STUN exchange that proceeds media transmission. Thus, if there is a change in source transport address, but the media packets come from the same peer agent, this SHOULD NOT be treated as an SSRC collision.12. Usage with SIP
12.1. Latency Guidelines
ICE requires a series of STUN-based connectivity checks to take place between endpoints. These checks start from the answerer on generation of its answer, and start from the offerer when it receives the answer. These checks can take time to complete, and as such, the selection of messages to use with offers and answers can affect perceived user latency. Two latency figures are of particular interest. These are the post-pickup delay and the post-dial delay. The post-pickup delay refers to the time between when a user "answers the phone" and when any speech they utter can be delivered to the caller. The post-dial delay refers to the time between when a user enters the destination address for the user and ringback begins as a consequence of having successfully started ringing the phone of the called party. Two cases can be considered -- one where the offer is present in the initial INVITE and one where it is in a response.12.1.1. Offer in INVITE
To reduce post-dial delays, it is RECOMMENDED that the caller begin gathering candidates prior to actually sending its initial INVITE. This can be started upon user interface cues that a call is pending, such as activity on a keypad or the phone going offhook. If an offer is received in an INVITE request, the answerer SHOULD begin to gather its candidates on receipt of the offer and then generate an answer in a provisional response once it has completed that process. ICE requires that a provisional response with an SDP be transmitted reliably. This can be done through the existing Provisional Response Acknowledgment (PRACK) mechanism [RFC3262] or through an optimization that is specific to ICE. With this optimization, provisional responses containing an SDP answer that begins ICE processing for one or more media streams can be sent reliably without RFC 3262. To do this, the agent retransmits the provisional response with the exponential backoff timers described in RFC 3262. Retransmits MUST cease on receipt of a STUN Binding
request for one of the media streams signaled in that SDP (because receipt of a Binding request indicates the offerer has received the answer) or on transmission of the answer in a 2xx response. If the peer agent is lite, there will never be a STUN Binding request. In such a case, the agent MUST cease retransmitting the 18x after sending it four times (ICE will actually work even if the peer never receives the 18x; however, experience has shown that sending it is important for middleboxes and firewall traversal). If no Binding request is received prior to the last retransmit, the agent does not consider the session terminated. Despite the fact that the provisional response will be delivered reliably, the rules for when an agent can send an updated offer or answer do not change from those specified in RFC 3262. Specifically, if the INVITE contained an offer, the same answer appears in all of the 1xx and in the 2xx response to the INVITE. Only after that 2xx has been sent can an updated offer/answer exchange occur. This optimization SHOULD NOT be used if both agents support PRACK. Note that the optimization is very specific to provisional response carrying answers that start ICE processing; it is not a general technique for 1xx reliability. Alternatively, an agent MAY delay sending an answer until the 200 OK; however, this results in a poor user experience and is NOT RECOMMENDED. Once the answer has been sent, the agent SHOULD begin its connectivity checks. Once candidate pairs for each component of a media stream enter the valid list, the answerer can begin sending media on that media stream. However, prior to this point, any media that needs to be sent towards the caller (such as SIP early media [RFC3960]) MUST NOT be transmitted. For this reason, implementations SHOULD delay alerting the called party until candidates for each component of each media stream have entered the valid list. In the case of a PSTN gateway, this would mean that the setup message into the PSTN is delayed until this point. Doing this increases the post-dial delay, but has the effect of eliminating 'ghost rings'. Ghost rings are cases where the called party hears the phone ring, picks up, but hears nothing and cannot be heard. This technique works without requiring support for, or usage of, preconditions [RFC3312], since it's a localized decision. It also has the benefit of guaranteeing that not a single packet of media will get clipped, so that post-pickup delay is zero. If an agent chooses to delay local alerting in this way, it SHOULD generate a 180 response once alerting begins.
12.1.2. Offer in Response
In addition to uses where the offer is in an INVITE, and the answer is in the provisional and/or 200 OK response, ICE works with cases where the offer appears in the response. In such cases, which are common in third party call control [RFC3725], ICE agents SHOULD generate their offers in a reliable provisional response (which MUST utilize RFC 3262), and not alert the user on receipt of the INVITE. The answer will arrive in a PRACK. This allows for ICE processing to take place prior to alerting, so that there is no post-pickup delay, at the expense of increased call setup delays. Once ICE completes, the callee can alert the user and then generate a 200 OK when they answer. The 200 OK would contain no SDP, since the offer/answer exchange has completed. Alternatively, agents MAY place the offer in a 2xx instead (in which case the answer comes in the ACK). When this happens, the callee will alert the user on receipt of the INVITE, and the ICE exchanges will take place only after the user answers. This has the effect of reducing call setup delay, but can cause substantial post-pickup delays and media clipping.12.2. SIP Option Tags and Media Feature Tags
[RFC5768] specifies a SIP option tag and media feature tag for usage with ICE. ICE implementations using SIP SHOULD support this specification, which uses a feature tag in registrations to facilitate interoperability through signaling intermediaries.12.3. Interactions with Forking
ICE interacts very well with forking. Indeed, ICE fixes some of the problems associated with forking. Without ICE, when a call forks and the caller receives multiple incoming media streams, it cannot determine which media stream corresponds to which callee. With ICE, this problem is resolved. The connectivity checks which occur prior to transmission of media carry username fragments, which in turn are correlated to a specific callee. Subsequent media packets that arrive on the same candidate pair as the connectivity check will be associated with that same callee. Thus, the caller can perform this correlation as long as it has received an answer.12.4. Interactions with Preconditions
Quality of Service (QoS) preconditions, which are defined in RFC 3312 [RFC3312] and RFC 4032 [RFC4032], apply only to the transport addresses listed as the default targets for media in an offer/answer.
If ICE changes the transport address where media is received, this change is reflected in an updated offer that changes the default destination for media to match ICE's selection. As such, it appears like any other re-INVITE would, and is fully treated in RFCs 3312 and 4032, which apply without regard to the fact that the destination for media is changing due to ICE negotiations occurring "in the background". Indeed, an agent SHOULD NOT indicate that QoS preconditions have been met until the checks have completed and selected the candidate pairs to be used for media. ICE also has (purposeful) interactions with connectivity preconditions [SDP-PRECON]. Those interactions are described there. Note that the procedures described in Section 12.1 describe their own type of "preconditions", albeit with less functionality than those provided by the explicit preconditions in [SDP-PRECON].12.5. Interactions with Third Party Call Control
ICE works with Flows I, III, and IV as described in [RFC3725]. Flow I works without the controller supporting or being aware of ICE. Flow IV will work as long as the controller passes along the ICE attributes without alteration. Flow II is fundamentally incompatible with ICE; each agent will believe itself to be the answerer and thus never generate a re-INVITE. The flows for continued operation, as described in Section 7 of RFC 3725, require additional behavior of ICE implementations to support. In particular, if an agent receives a mid-dialog re-INVITE that contains no offer, it MUST restart ICE for each media stream and go through the process of gathering new candidates. Furthermore, that list of candidates SHOULD include the ones currently being used for media.13. Relationship with ANAT
RFC 4091 [RFC4091], the Alternative Network Address Types (ANAT) Semantics for the SDP grouping framework, and RFC 4092 [RFC4092], its usage with SIP, define a mechanism for indicating that an agent can support both IPv4 and IPv6 for a media stream, and it does so by including two m lines, one for v4 and one for v6. This is similar to ICE, which allows for an agent to indicate multiple transport addresses using the candidate attribute. However, ANAT relies on static selection to pick between choices, rather than a dynamic connectivity check used by ICE.
This specification deprecates RFC 4091 and RFC 4092. Instead, agents wishing to support dual stack will utilize ICE.14. Extensibility Considerations
This specification makes very specific choices about how both agents in a session coordinate to arrive at the set of candidate pairs that are selected for media. It is anticipated that future specifications will want to alter these algorithms, whether they are simple changes like timer tweaks or larger changes like a revamp of the priority algorithm. When such a change is made, providing interoperability between the two agents in a session is critical. First, ICE provides the a=ice-options SDP attribute. Each extension or change to ICE is associated with a token. When an agent supporting such an extension or change generates an offer or an answer, it MUST include the token for that extension in this attribute. This allows each side to know what the other side is doing. This attribute MUST NOT be present if the agent doesn't support any ICE extensions or changes. At this time, no IANA registry or registration procedures are defined for these option tags. At time of writing, it is unclear whether ICE changes and extensions will be sufficiently common to warrant a registry. One of the complications in achieving interoperability is that ICE relies on a distributed algorithm running on both agents to converge on an agreed set of candidate pairs. If the two agents run different algorithms, it can be difficult to guarantee convergence on the same candidate pairs. The regular nomination procedure described in Section 8 eliminates some of the tight coordination by delegating the selection algorithm completely to the controlling agent. Consequently, when a controlling agent is communicating with a peer that supports options it doesn't know about, the agent MUST run a regular nomination algorithm. When regular nomination is used, ICE will converge perfectly even when both agents use different pair prioritization algorithms. One of the keys to such convergence is triggered checks, which ensure that the nominated pair is validated by both agents. Consequently, any future ICE enhancements MUST preserve triggered checks. ICE is also extensible to other media streams beyond RTP, and for transport protocols beyond UDP. Extensions to ICE for non-RTP media streams need to specify how many components they utilize, and assign component IDs to them, starting at 1 for the most important component ID. Specifications for new transport protocols must define how, if at all, various steps in the ICE processing differ from UDP.
15. Grammar
This specification defines seven new SDP attributes -- the "candidate", "remote-candidates", "ice-lite", "ice-mismatch", "ice- ufrag", "ice-pwd", and "ice-options" attributes.15.1. "candidate" Attribute
The candidate attribute is a media-level attribute only. It contains a transport address for a candidate that can be used for connectivity checks. The syntax of this attribute is defined using Augmented BNF as defined in RFC 5234 [RFC5234]: candidate-attribute = "candidate" ":" foundation SP component-id SP transport SP priority SP connection-address SP ;from RFC 4566 port ;port from RFC 4566 SP cand-type [SP rel-addr] [SP rel-port] *(SP extension-att-name SP extension-att-value) foundation = 1*32ice-char component-id = 1*5DIGIT transport = "UDP" / transport-extension transport-extension = token ; from RFC 3261 priority = 1*10DIGIT cand-type = "typ" SP candidate-types candidate-types = "host" / "srflx" / "prflx" / "relay" / token rel-addr = "raddr" SP connection-address rel-port = "rport" SP port extension-att-name = byte-string ;from RFC 4566 extension-att-value = byte-string ice-char = ALPHA / DIGIT / "+" / "/" This grammar encodes the primary information about a candidate: its IP address, port and transport protocol, and its properties: the foundation, component ID, priority, type, and related transport address: <connection-address>: is taken from RFC 4566 [RFC4566]. It is the IP address of the candidate, allowing for IPv4 addresses, IPv6 addresses, and fully qualified domain names (FQDNs). When parsing this field, an agent can differentiate an IPv4 address and an IPv6
address by presence of a colon in its value - the presence of a
colon indicates IPv6. An agent MUST ignore candidate lines that
include candidates with IP address versions that are not supported
or recognized. An IP address SHOULD be used, but an FQDN MAY be
used in place of an IP address. In that case, when receiving an
offer or answer containing an FQDN in an a=candidate attribute,
the FQDN is looked up in the DNS first using an AAAA record
(assuming the agent supports IPv6), and if no result is found or
the agent only supports IPv4, using an A. If the DNS query
returns more than one IP address, one is chosen, and then used for
the remainder of ICE processing.
<port>: is also taken from RFC 4566 [RFC4566]. It is the port of
the candidate.
<transport>: indicates the transport protocol for the candidate.
This specification only defines UDP. However, extensibility is
provided to allow for future transport protocols to be used with
ICE, such as TCP or the Datagram Congestion Control Protocol
(DCCP) [RFC4340].
<foundation>: is composed of 1 to 32 <ice-char>s. It is an
identifier that is equivalent for two candidates that are of the
same type, share the same base, and come from the same STUN
server. The foundation is used to optimize ICE performance in the
Frozen algorithm.
<component-id>: is a positive integer between 1 and 256 that
identifies the specific component of the media stream for which
this is a candidate. It MUST start at 1 and MUST increment by 1
for each component of a particular candidate. For media streams
based on RTP, candidates for the actual RTP media MUST have a
component ID of 1, and candidates for RTCP MUST have a component
ID of 2. Other types of media streams that require multiple
components MUST develop specifications that define the mapping of
components to component IDs. See Section 14 for additional
discussion on extending ICE to new media streams.
<priority>: is a positive integer between 1 and (2**31 - 1).
<cand-type>: encodes the type of candidate. This specification
defines the values "host", "srflx", "prflx", and "relay" for host,
server reflexive, peer reflexive, and relayed candidates,
respectively. The set of candidate types is extensible for the
future.
<rel-addr> and <rel-port>: convey transport addresses related to the
candidate, useful for diagnostics and other purposes. <rel-addr>
and <rel-port> MUST be present for server reflexive, peer
reflexive, and relayed candidates. If a candidate is server or
peer reflexive, <rel-addr> and <rel-port> are equal to the base
for that server or peer reflexive candidate. If the candidate is
relayed, <rel-addr> and <rel-port> is equal to the mapped address
in the Allocate response that provided the client with that
relayed candidate (see Appendix B.3 for a discussion of its
purpose). If the candidate is a host candidate, <rel-addr> and
<rel-port> MUST be omitted.
The candidate attribute can itself be extended. The grammar allows
for new name/value pairs to be added at the end of the attribute. An
implementation MUST ignore any name/value pairs it doesn't
understand.
15.2. "remote-candidates" Attribute
The syntax of the "remote-candidates" attribute is defined using
Augmented BNF as defined in RFC 5234 [RFC5234]. The remote-
candidates attribute is a media-level attribute only.
remote-candidate-att = "remote-candidates" ":" remote-candidate
0*(SP remote-candidate)
remote-candidate = component-ID SP connection-address SP port
The attribute contains a connection-address and port for each
component. The ordering of components is irrelevant. However, a
value MUST be present for each component of a media stream. This
attribute MUST be included in an offer by a controlling agent for a
media stream that is Completed, and MUST NOT be included in any other
case.
15.3. "ice-lite" and "ice-mismatch" Attributes
The syntax of the "ice-lite" and "ice-mismatch" attributes, both of
which are flags, is:
ice-lite = "ice-lite"
ice-mismatch = "ice-mismatch"
"ice-lite" is a session-level attribute only, and indicates that an
agent is a lite implementation. "ice-mismatch" is a media-level
attribute only, and when present in an answer, indicates that the
offer arrived with a default destination for a media component that
didn't have a corresponding candidate attribute.
15.4. "ice-ufrag" and "ice-pwd" Attributes
The "ice-ufrag" and "ice-pwd" attributes convey the username fragment and password used by ICE for message integrity. Their syntax is: ice-pwd-att = "ice-pwd" ":" password ice-ufrag-att = "ice-ufrag" ":" ufrag password = 22*256ice-char ufrag = 4*256ice-char The "ice-pwd" and "ice-ufrag" attributes can appear at either the session-level or media-level. When present in both, the value in the media-level takes precedence. Thus, the value at the session-level is effectively a default that applies to all media streams, unless overridden by a media-level value. Whether present at the session or media-level, there MUST be an ice-pwd and ice-ufrag attribute for each media stream. If two media streams have identical ice-ufrag's, they MUST have identical ice-pwd's. The ice-ufrag and ice-pwd attributes MUST be chosen randomly at the beginning of a session. The ice-ufrag attribute MUST contain at least 24 bits of randomness, and the ice-pwd attribute MUST contain at least 128 bits of randomness. This means that the ice-ufrag attribute will be at least 4 characters long, and the ice-pwd at least 22 characters long, since the grammar for these attributes allows for 6 bits of randomness per character. The attributes MAY be longer than 4 and 22 characters, respectively, of course, up to 256 characters. The upper limit allows for buffer sizing in implementations. Its large upper limit allows for increased amounts of randomness to be added over time.15.5. "ice-options" Attribute
The "ice-options" attribute is a session-level attribute. It contains a series of tokens that identify the options supported by the agent. Its grammar is: ice-options = "ice-options" ":" ice-option-tag 0*(SP ice-option-tag) ice-option-tag = 1*ice-char16. Setting Ta and RTO
During the gathering phase of ICE (Section 4.1.1) and while ICE is performing connectivity checks (Section 7), an agent sends STUN and TURN transactions. These transactions are paced at a rate of one every Ta milliseconds, and utilize a specific RTO. This section describes how the values of Ta and RTO are computed. This
computation depends on whether ICE is being used with a real-time media stream (such as RTP) or something else. When ICE is used for a stream with a known maximum bandwidth, the computation in Section 16.1 MAY be followed to rate-control the ICE exchanges. For all other streams, the computation in Section 16.2 MUST be followed.16.1. RTP Media Streams
The values of RTO and Ta change during the lifetime of ICE processing. One set of values applies during the gathering phase, and the other, for connectivity checks. The value of Ta SHOULD be configurable, and SHOULD have a default of: For each media stream i: Ta_i = (stun_packet_size / rtp_packet_size) * rtp_ptime 1 Ta = MAX (20ms, ------------------- ) k ---- \ 1 > ------ / Ta_i ---- i=1 where k is the number of media streams. During the gathering phase, Ta is computed based on the number of media streams the agent has indicated in its offer or answer, and the RTP packet size and RTP ptime are those of the most preferred codec for each media stream. Once an offer and answer have been exchanged, the agent recomputes Ta to pace the connectivity checks. In that case, the value of Ta is based on the number of media streams that will actually be used in the session, and the RTP packet size and RTP ptime are those of the most preferred codec with which the agent will send. In addition, the retransmission timer for the STUN transactions, RTO, defined in [RFC5389], SHOULD be configurable and during the gathering phase, SHOULD have a default of: RTO = MAX (100ms, Ta * (number of pairs)) where the number of pairs refers to the number of pairs of candidates with STUN or TURN servers.
For connectivity checks, RTO SHOULD be configurable and SHOULD have a
default of:
RTO = MAX (100ms, Ta*N * (Num-Waiting + Num-In-Progress))
where Num-Waiting is the number of checks in the check list in the
Waiting state, and Num-In-Progress is the number of checks in the In-
Progress state. Note that the RTO will be different for each
transaction as the number of checks in the Waiting and In-Progress
states change.
These formulas are aimed at causing STUN transactions to be paced at
the same rate as media. This ensures that ICE will work properly
under the same network conditions needed to support the media as
well. See Appendix B.1 for additional discussion and motivations.
Because of this pacing, it will take a certain amount of time to
obtain all of the server reflexive and relayed candidates.
Implementations should be aware of the time required to do this, and
if the application requires a time budget, limit the number of
candidates that are gathered.
The formulas result in a behavior whereby an agent will send its
first packet for every single connectivity check before performing a
retransmit. This can be seen in the formulas for the RTO (which
represents the retransmit interval). Those formulas scale with N,
the number of checks to be performed. As a result of this, ICE
maintains a nicely constant rate, but becomes more sensitive to
packet loss. The loss of the first single packet for any
connectivity check is likely to cause that pair to take a long time
to be validated, and instead, a lower-priority check (but one for
which there was no packet loss) is much more likely to complete
first. This results in ICE performing sub-optimally, choosing lower-
priority pairs over higher-priority pairs. Implementors should be
aware of this consequence, but still should utilize the timer values
described here.
16.2. Non-RTP Sessions
In cases where ICE is used to establish some kind of session that is
not real time, and has no fixed rate associated with it that is known
to work on the network in which ICE is deployed, Ta and RTO revert to
more conservative values. Ta SHOULD be configurable, SHOULD have a
default of 500 ms, and MUST NOT be configurable to be less than 500
ms.
In addition, the retransmission timer for the STUN transactions, RTO,
SHOULD be configurable and during the gathering phase, SHOULD have a
default of:
RTO = MAX (500ms, Ta * (number of pairs))
where the number of pairs refers to the number of pairs of candidates
with STUN or TURN servers.
For connectivity checks, RTO SHOULD be configurable and SHOULD have a
default of:
RTO = MAX (500ms, Ta*N * (Num-Waiting + Num-In-Progress))
(page 79 continued on part 4)
