idnits 2.17.1 draft-ietf-mmusic-ice-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 5083. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 5094. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 5101. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 5107. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 20 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? -- The draft header indicates that this document obsoletes RFC4091, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 9, 2007) is 6134 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4091 (Obsoleted by RFC 5245) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-06 == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-03 -- Obsolete informational reference (is this intentional?): RFC 3489 (Obsoleted by RFC 5389) == Outdated reference: A later version (-07) exists of draft-ietf-mmusic-connectivity-precon-02 == Outdated reference: A later version (-07) exists of draft-ietf-avt-rtp-and-rtcp-mux-05 == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-09 Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC J. Rosenberg 3 Internet-Draft Cisco 4 Obsoletes: 4091 (if approved) July 9, 2007 5 Intended status: Standards Track 6 Expires: January 10, 2008 8 Interactive Connectivity Establishment (ICE): A Protocol for Network 9 Address Translator (NAT) Traversal for Offer/Answer Protocols 10 draft-ietf-mmusic-ice-17 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 10, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document describes a protocol for Network Address Translator 44 (NAT) traversal for multimedia sessions established with the offer/ 45 answer model. This protocol is called Interactive Connectivity 46 Establishment (ICE). ICE makes use of the Session Traversal 47 Utilities for NAT (STUN) protocol and its extension, Traversal Using 48 Relay NAT (TURN). ICE can be used by any protocol utilizing the 49 offer/answer model, such as the Session Initiation Protocol (SIP). 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 54 2. Overview of ICE . . . . . . . . . . . . . . . . . . . . . . . 7 55 2.1. Gathering Candidate Addresses . . . . . . . . . . . . . . 9 56 2.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 11 57 2.3. Sorting Candidates . . . . . . . . . . . . . . . . . . . 12 58 2.4. Frozen Candidates . . . . . . . . . . . . . . . . . . . . 13 59 2.5. Security for Checks . . . . . . . . . . . . . . . . . . . 14 60 2.6. Concluding ICE . . . . . . . . . . . . . . . . . . . . . 14 61 2.7. Lite Implementations . . . . . . . . . . . . . . . . . . 16 62 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 16 63 4. Sending the Initial Offer . . . . . . . . . . . . . . . . . . 19 64 4.1. Full Implementation Requirements . . . . . . . . . . . . 19 65 4.1.1. Gathering Candidates . . . . . . . . . . . . . . . . 19 66 4.1.1.1. Host Candidates . . . . . . . . . . . . . . . . . 20 67 4.1.1.2. Server Reflexive and Relayed Candidates . . . . . 20 68 4.1.1.3. Eliminating Redundant Candidates . . . . . . . . 21 69 4.1.1.4. Computing Foundations . . . . . . . . . . . . . . 22 70 4.1.1.5. Keeping Candidates Alive . . . . . . . . . . . . 22 71 4.1.2. Prioritizing Candidates . . . . . . . . . . . . . . . 22 72 4.1.2.1. Recommended Formula . . . . . . . . . . . . . . . 23 73 4.1.2.2. Guidelines for Choosing Type and Local 74 Preferences . . . . . . . . . . . . . . . . . . . 24 75 4.1.3. Choosing Default Candidates . . . . . . . . . . . . . 25 76 4.2. Lite Implementation . . . . . . . . . . . . . . . . . . . 25 77 4.3. Encoding the SDP . . . . . . . . . . . . . . . . . . . . 26 78 5. Receiving the Initial Offer . . . . . . . . . . . . . . . . . 28 79 5.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 28 80 5.2. Determining Role . . . . . . . . . . . . . . . . . . . . 29 81 5.3. Gathering Candidates . . . . . . . . . . . . . . . . . . 30 82 5.4. Prioritizing Candidates . . . . . . . . . . . . . . . . . 30 83 5.5. Choosing Default Candidates . . . . . . . . . . . . . . . 30 84 5.6. Encoding the SDP . . . . . . . . . . . . . . . . . . . . 30 85 5.7. Forming the Check Lists . . . . . . . . . . . . . . . . . 31 86 5.7.1. Forming Candidate Pairs . . . . . . . . . . . . . . . 31 87 5.7.2. Computing Pair Priority and Ordering Pairs . . . . . 33 88 5.7.3. Pruning the Pairs . . . . . . . . . . . . . . . . . . 33 89 5.7.4. Computing States . . . . . . . . . . . . . . . . . . 33 90 5.8. Scheduling Checks . . . . . . . . . . . . . . . . . . . . 36 91 6. Receipt of the Initial Answer . . . . . . . . . . . . . . . . 38 92 6.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 38 93 6.2. Determining Role . . . . . . . . . . . . . . . . . . . . 38 94 6.3. Forming the Check List . . . . . . . . . . . . . . . . . 39 95 6.4. Performing Ordinary Checks . . . . . . . . . . . . . . . 39 97 7. Performing Connectivity Checks . . . . . . . . . . . . . . . 39 98 7.1. STUN Client Procedures . . . . . . . . . . . . . . . . . 39 99 7.1.1. Sending the Request . . . . . . . . . . . . . . . . . 39 100 7.1.1.1. PRIORITY and USE-CANDIDATE . . . . . . . . . . . 40 101 7.1.1.2. ICE-CONTROLLED and ICE-CONTROLLING . . . . . . . 40 102 7.1.1.3. Forming Credentials . . . . . . . . . . . . . . . 40 103 7.1.1.4. DiffServ Treatment . . . . . . . . . . . . . . . 40 104 7.1.2. Processing the Response . . . . . . . . . . . . . . . 41 105 7.1.2.1. Failure Cases . . . . . . . . . . . . . . . . . . 41 106 7.1.2.2. Success Cases . . . . . . . . . . . . . . . . . . 41 107 7.1.2.2.1. Discovering Peer Reflexive Candidates . . . . 42 108 7.1.2.2.2. Constructing a Valid Pair . . . . . . . . . . 42 109 7.1.2.2.3. Updating Pair States . . . . . . . . . . . . 43 110 7.1.2.2.4. Updating the Nominated Flag . . . . . . . . . 44 111 7.1.2.3. Check List and Timer State Updates . . . . . . . 44 112 7.2. STUN Server Procedures . . . . . . . . . . . . . . . . . 45 113 7.2.1. Additional Procedures for Full Implementations . . . 46 114 7.2.1.1. Detecting and Repairing Role Conflicts . . . . . 46 115 7.2.1.2. Computing Mapped Address . . . . . . . . . . . . 47 116 7.2.1.3. Learning Peer Reflexive Candidates . . . . . . . 47 117 7.2.1.4. Triggered Checks . . . . . . . . . . . . . . . . 48 118 7.2.1.5. Updating the Nominated Flag . . . . . . . . . . . 49 119 7.2.2. Additional Procedures for Lite Implementations . . . 49 120 8. Concluding ICE Processing . . . . . . . . . . . . . . . . . . 49 121 8.1. Procedures for Full Implementations . . . . . . . . . . . 50 122 8.1.1. Nominating Pairs . . . . . . . . . . . . . . . . . . 50 123 8.1.1.1. Regular Nomination . . . . . . . . . . . . . . . 50 124 8.1.1.2. Aggressive Nomination . . . . . . . . . . . . . . 51 125 8.1.2. Updating States . . . . . . . . . . . . . . . . . . . 51 126 8.2. Procedures for Lite Implementations . . . . . . . . . . . 52 127 8.2.1. Peer is Full . . . . . . . . . . . . . . . . . . . . 53 128 8.2.2. Peer is Lite . . . . . . . . . . . . . . . . . . . . 53 129 8.3. Freeing Candidates . . . . . . . . . . . . . . . . . . . 54 130 8.3.1. Full Implementation Procedures . . . . . . . . . . . 54 131 8.3.2. Lite Implementations . . . . . . . . . . . . . . . . 54 132 9. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . . . 54 133 9.1. Generating the Offer . . . . . . . . . . . . . . . . . . 55 134 9.1.1. Procedures for All Implementations . . . . . . . . . 55 135 9.1.1.1. ICE Restarts . . . . . . . . . . . . . . . . . . 55 136 9.1.1.2. Removing a Media Stream . . . . . . . . . . . . . 56 137 9.1.1.3. Adding a Media Stream . . . . . . . . . . . . . . 56 138 9.1.2. Procedures for Full Implementations . . . . . . . . . 56 139 9.1.2.1. Existing Media Streams with ICE Running . . . . . 56 140 9.1.2.2. Existing Media Streams with ICE Completed . . . . 57 141 9.1.3. Procedures for Lite Implementations . . . . . . . . . 57 142 9.1.3.1. Existing Media Streams with ICE Running . . . . . 57 143 9.1.3.2. Existing Media Streams with ICE Completed . . . . 58 144 9.2. Receiving the Offer and Generating an Answer . . . . . . 58 145 9.2.1. Procedures for All Implementations . . . . . . . . . 58 146 9.2.1.1. Detecting ICE Restart . . . . . . . . . . . . . . 58 147 9.2.1.2. New Media Stream . . . . . . . . . . . . . . . . 59 148 9.2.1.3. Removed Media Stream . . . . . . . . . . . . . . 59 149 9.2.2. Procedures for Full Implementations . . . . . . . . . 59 150 9.2.2.1. Existing Media Streams with ICE Running and no 151 remote-candidates . . . . . . . . . . . . . . . . 59 152 9.2.2.2. Existing Media Streams with ICE Completed and 153 no remote-candidates . . . . . . . . . . . . . . 59 154 9.2.2.3. Existing Media Streams and remote-candidates . . 59 155 9.2.3. Procedures for Lite Implementations . . . . . . . . . 60 156 9.3. Updating the Check and Valid Lists . . . . . . . . . . . 61 157 9.3.1. Procedures for Full Implementations . . . . . . . . . 61 158 9.3.1.1. ICE Restarts . . . . . . . . . . . . . . . . . . 61 159 9.3.1.2. New Media Stream . . . . . . . . . . . . . . . . 61 160 9.3.1.3. Removed Media Stream . . . . . . . . . . . . . . 62 161 9.3.1.4. ICE Continuing for Existing Media Stream . . . . 62 162 9.3.2. Procedures for Lite Implementations . . . . . . . . . 62 163 10. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 63 164 11. Media Handling . . . . . . . . . . . . . . . . . . . . . . . 64 165 11.1. Sending Media . . . . . . . . . . . . . . . . . . . . . . 64 166 11.1.1. Procedures for Full Implementations . . . . . . . . . 64 167 11.1.2. Procedures for Lite Implementations . . . . . . . . . 65 168 11.1.3. Procedures for All Implementations . . . . . . . . . 65 169 11.2. Receiving Media . . . . . . . . . . . . . . . . . . . . . 65 170 12. Usage with SIP . . . . . . . . . . . . . . . . . . . . . . . 66 171 12.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . 66 172 12.1.1. Offer in INVITE . . . . . . . . . . . . . . . . . . . 66 173 12.1.2. Offer in Response . . . . . . . . . . . . . . . . . . 67 174 12.2. SIP Option Tags and Media Feature Tags . . . . . . . . . 68 175 12.3. Interactions with Forking . . . . . . . . . . . . . . . . 68 176 12.4. Interactions with Preconditions . . . . . . . . . . . . . 68 177 12.5. Interactions with Third Party Call Control . . . . . . . 69 178 13. Relationship with ANAT . . . . . . . . . . . . . . . . . . . 69 179 14. Extensibility Considerations . . . . . . . . . . . . . . . . 69 180 15. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 181 15.1. "candidate" Attribute . . . . . . . . . . . . . . . . . . 71 182 15.2. "remote-candidates" Attribute . . . . . . . . . . . . . . 73 183 15.3. "ice-lite" and "ice-mismatch" Attributes . . . . . . . . 73 184 15.4. "ice-ufrag" and "ice-pwd" Attributes . . . . . . . . . . 73 185 15.5. "ice-options" Attribute . . . . . . . . . . . . . . . . . 74 186 16. Setting Ta and RTO . . . . . . . . . . . . . . . . . . . . . 74 187 17. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 188 18. Security Considerations . . . . . . . . . . . . . . . . . . . 82 189 18.1. Attacks on Connectivity Checks . . . . . . . . . . . . . 82 190 18.2. Attacks on Server Reflexive Address Gathering . . . . . . 84 191 18.3. Attacks on Relayed Candidate Gathering . . . . . . . . . 85 192 18.4. Attacks on the Offer/Answer Exchanges . . . . . . . . . . 86 193 18.5. Insider Attacks . . . . . . . . . . . . . . . . . . . . . 86 194 18.5.1. The Voice Hammer Attack . . . . . . . . . . . . . . . 86 195 18.5.2. STUN Amplification Attack . . . . . . . . . . . . . . 86 196 18.6. Interactions with Application Layer Gateways and SIP . . 87 197 19. STUN Extensions . . . . . . . . . . . . . . . . . . . . . . . 88 198 19.1. New Attributes . . . . . . . . . . . . . . . . . . . . . 88 199 19.2. New Error Response Codes . . . . . . . . . . . . . . . . 89 200 20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 89 201 20.1. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 89 202 20.1.1. candidate Attribute . . . . . . . . . . . . . . . . . 89 203 20.1.2. remote-candidates Attribute . . . . . . . . . . . . . 90 204 20.1.3. ice-lite Attribute . . . . . . . . . . . . . . . . . 90 205 20.1.4. ice-mismatch Attribute . . . . . . . . . . . . . . . 91 206 20.1.5. ice-pwd Attribute . . . . . . . . . . . . . . . . . . 91 207 20.1.6. ice-ufrag Attribute . . . . . . . . . . . . . . . . . 91 208 20.1.7. ice-options Attribute . . . . . . . . . . . . . . . . 92 209 20.2. STUN Attributes . . . . . . . . . . . . . . . . . . . . . 92 210 20.3. STUN Error Responses . . . . . . . . . . . . . . . . . . 93 211 21. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 93 212 21.1. Problem Definition . . . . . . . . . . . . . . . . . . . 93 213 21.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 93 214 21.3. Brittleness Introduced by ICE . . . . . . . . . . . . . . 94 215 21.4. Requirements for a Long Term Solution . . . . . . . . . . 95 216 21.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 95 217 22. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 96 218 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 96 219 23.1. Normative References . . . . . . . . . . . . . . . . . . 96 220 23.2. Informative References . . . . . . . . . . . . . . . . . 97 221 Appendix A. Lite and Full Implementations . . . . . . . . . . . 99 222 Appendix B. Design Motivations . . . . . . . . . . . . . . . . . 100 223 B.1. Pacing of STUN Transactions . . . . . . . . . . . . . . . 101 224 B.2. Candidates with Multiple Bases . . . . . . . . . . . . . 102 225 B.3. Purpose of the and Attributes . . . 104 226 B.4. Importance of the STUN Username . . . . . . . . . . . . . 104 227 B.5. The Candidate Pair Sequence Number Formula . . . . . . . 105 228 B.6. The remote-candidates attribute . . . . . . . . . . . . . 106 229 B.7. Why are Keepalives Needed? . . . . . . . . . . . . . . . 107 230 B.8. Why Prefer Peer Reflexive Candidates? . . . . . . . . . . 108 231 B.9. Why Send an Updated Offer? . . . . . . . . . . . . . . . 108 232 B.10. Why are Binding Indications Used for Keepalives? . . . . 108 233 B.11. Why is the Conflict Resolution Mechanism Needed? . . . . 109 234 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 110 235 Intellectual Property and Copyright Statements . . . . . . . . . 111 237 1. Introduction 239 RFC 3264 [RFC3264] defines a two-phase exchange of Session 240 Description Protocol (SDP) messages [RFC4566] for the purposes of 241 establishment of multimedia sessions. This offer/answer mechanism is 242 used by protocols such as the Session Initiation Protocol (SIP) 243 [RFC3261]. 245 Protocols using offer/answer are difficult to operate through Network 246 Address Translators (NAT). Because their purpose is to establish a 247 flow of media packets, they tend to carry the IP addresses and ports 248 of media sources and sinks within their messages, which is known to 249 be problematic through NAT [RFC3235]. The protocols also seek to 250 create a media flow directly between participants, so that there is 251 no application layer intermediary between them. This is done to 252 reduce media latency, decrease packet loss, and reduce the 253 operational costs of deploying the application. However, this is 254 difficult to accomplish through NAT. A full treatment of the reasons 255 for this is beyond the scope of this specification. 257 Numerous solutions have been proposed for allowing these protocols to 258 operate through NAT. These include Application Layer Gateways 259 (ALGs), the Middlebox Control Protocol [RFC3303], Simple Traversal 260 Underneath NAT (STUN) [RFC3489] and its revision, retitled Session 261 Traversal Utilities for NAT [I-D.ietf-behave-rfc3489bis], Traversal 262 Using Relay NAT (TURN) [I-D.ietf-behave-turn], and Realm Specific IP 263 [RFC3102] [RFC3103] along with session description extensions needed 264 to make them work, such as the Session Description Protocol (SDP) 265 [RFC4566] attribute for the Real Time Control Protocol (RTCP) 266 [RFC3605]. Unfortunately, these techniques all have pros and cons 267 which make each one optimal in some network topologies, but a poor 268 choice in others. The result is that administrators and implementors 269 are making assumptions about the topologies of the networks in which 270 their solutions will be deployed. This introduces complexity and 271 brittleness into the system. What is needed is a single solution 272 which is flexible enough to work well in all situations. 274 This specification defines Interactive Connectivity Establishment 275 (ICE) as a technique for NAT traversal for media streams established 276 by the offer/answer model. ICE is an extension to the offer/answer 277 model, and works by including a multiplicity of IP addresses and 278 ports in SDP offers and answers, which are then tested for 279 connectivity by peer-to-peer STUN exchanges. The IP addresses and 280 ports included in the SDP are gathered using STUN 281 [I-D.ietf-behave-rfc3489bis] and Traversal Using Relay NAT (TURN) 282 [I-D.ietf-behave-turn]. Because ICE exchanges a multiplicity of IP 283 addresses and ports for each media stream, it also allows for address 284 selection for multi-homed and dual-stack hosts, and for this reason 285 it deprecates RFC 4091 [RFC4091]. 287 2. Overview of ICE 289 In a typical ICE deployment, we have two endpoints (known as AGENTS 290 in RFC 3264 terminology) which want to communicate. They are able to 291 communicate indirectly via some signaling protocol (such as SIP), by 292 which they can perform an offer/answer exchange of SDP [RFC3264] 293 messages. Note that ICE is not intended for NAT traversal for SIP, 294 which is assumed to be provided via another mechanism 295 [I-D.ietf-sip-outbound]. At the beginning of the ICE process, the 296 agents are ignorant of their own topologies. In particular, they 297 might or might not be behind a NAT (or multiple tiers of NATs). ICE 298 allows the agents to discover enough information about their 299 topologies to potentially find one or more paths by which they can 300 communicate. 302 Figure 1 shows a typical environment for ICE deployment. The two 303 endpoints are labelled L and R (for left and right, which helps 304 visualize call flows). Both L and R are behind their own respective 305 NATs though they may not be aware of it. The type of NAT and its 306 properties are also unknown. Agents L and R are capable of engaging 307 in an offer/answer exchange by which they can exchange SDP messages, 308 whose purpose is to set up a media session between L and R. 309 Typically, this exchange will occur through a SIP server. 311 In addition to the agents, a SIP server and NATs, ICE is typically 312 used in concert with STUN or TURN servers in the network. Each agent 313 can have its own STUN or TURN server, or they can be the same. 315 +-------+ 316 | SIP | 317 +-------+ | Srvr | +-------+ 318 | STUN | | | | STUN | 319 | Srvr | +-------+ | Srvr | 320 | | / \ | | 321 +-------+ / \ +-------+ 322 / \ 323 / \ 324 / \ 325 / \ 326 / <- Signalling -> \ 327 / \ 328 / \ 329 +--------+ +--------+ 330 | NAT | | NAT | 331 +--------+ +--------+ 332 / \ 333 / \ 334 / \ 335 +-------+ +-------+ 336 | Agent | | Agent | 337 | L | | R | 338 | | | | 339 +-------+ +-------+ 341 Figure 1: ICE Deployment Scenario 343 The basic idea behind ICE is as follows: each agent has a variety of 344 candidate TRANSPORT ADDRESSES (combination of IP address and port) it 345 could use to communicate with the other agent. These might include: 347 o A transport address on a directly attached network interface 349 o A translated transport address on the public side of a NAT (a 350 "server reflexive" address) 352 o The transport address allocated from a TURN server(a "relayed 353 address". 355 Potentially, any of L's candidate transport addresses can be used to 356 communicate with any of R's candidate transport addresses. In 357 practice, however, many combinations will not work. For instance, if 358 L and R are both behind NATs, their directly attached interface 359 addresses are unlikely to be able to communicate directly (this is 360 why ICE is needed, after all!). The purpose of ICE is to discover 361 which pairs of addresses will work. The way that ICE does this is to 362 systematically try all possible pairs (in a carefully sorted order) 363 until it finds one or more that works. 365 2.1. Gathering Candidate Addresses 367 In order to execute ICE, an agent has to identify all of its address 368 candidates. A CANDIDATE is a transport address - a combination of IP 369 address and port for a particular transport protocol. This document 370 defines three types of candidates, some derived from physical or 371 logical network interfaces, others discoverable via STUN and TURN. 372 Naturally, one viable candidate is a transport address obtained 373 directly from a local interface. Such a candidate is called a HOST 374 CANDIDATE. The local interface could be ethernet or WiFi, or it 375 could be one that is obtained through a tunnel mechanism, such as a 376 Virtual Private Network (VPN) or Mobile IP (MIP). In all cases, such 377 a network interface appears to the agent as a local interface from 378 which ports (and thus a candidate) can be allocated. 380 If an agent is multihomed, it obtains a candidate from each 381 interface. Depending on the location of the PEER (the other agent in 382 the session) on the IP network relative to the agent, the agent may 383 be reachable by the peer through one or more of those interfaces. 384 Consider, for example, an agent which has a local interface to a 385 private net 10 network (I1), and a second connected to the public 386 Internet (I2). A candidate from I1 will be directly reachable when 387 communicating with a peer on the same private net 10 network, while a 388 candidate from I2 will be directly reachable when communicating with 389 a peer on the public Internet. Rather than trying to guess which 390 interface will work prior to sending an offer, the offering agent 391 includes both candidates in its offer. 393 Next, the agent uses STUN or TURN to obtain additional candidates. 394 These come in two flavors: translated addresses on the public side of 395 a NAT (SERVER REFLEXIVE CANDIDATES) and addresses on TURN servers 396 (RELAYED CANDIDATES). When TURN servers are utilized, both types of 397 candidates are obtained from the TURN server. If only STUN servers 398 are utilized, only server reflexive canddiates are obtained from 399 them. The relationship of these candidates to the host candidate is 400 shown in Figure 2. In this figure, both types of candidates are 401 discovered using TURN. In the figure, the notation X:x means IP 402 address X and port x. 404 To Internet 406 | 407 | 408 | /------------ Relayed 409 Y:y | / Address 410 +--------+ 411 | | 412 | TURN | 413 | Server | 414 | | 415 +--------+ 416 | 417 | 418 | /------------ Server 419 X1':x1'|/ Reflexive 420 +------------+ Address 421 | NAT | 422 +------------+ 423 | 424 | /------------ Local 425 X:x |/ Address 426 +--------+ 427 | | 428 | Agent | 429 | | 430 +--------+ 432 Figure 2: Candidate Relationships 434 When the agent sends the TURN Allocate Request from IP address and 435 port X:x, the NAT (assuming there is one) will create a binding 436 X1':x1', mapping this server reflexive candidate to the host 437 candidate X:x. Outgoing packets sent from the host candidate will be 438 translated by the NAT to the server reflexive candidate. Incoming 439 packets sent to the server relexive candidate will be translated by 440 the NAT to the host candidate and forwarded to the agent. We call 441 the host candidate associated with a given server reflexive candidate 442 the BASE. 444 NOTE: "Base" refers to the address an agent sends from for a 445 particular candidate. Thus, as a degenerate case host candidates 446 also have a base, but it's the same as the host candidate. 448 When there are multiple NATs between the agent and the TURN server, 449 the TURN request will create a binding on each NAT, but only the 450 outermost server reflexive candidate (the one nearest the TURN 451 server) will be discovered by the agent. If the agent is not behind 452 a NAT, then the base candidate will be the same as the server 453 reflexive candidate and the server reflexive candidate is redundant 454 and will be eliminated. 456 The Allocate request then arrives at the TURN server. The TURN 457 server allocates a port y from its local interface Y, and generates 458 an Allocate response, informing the agent of this relayed candidate. 459 The TURN server also informs the agent of the server reflexive 460 candidate, X1':x1' by copying the source transport address of the 461 Allocate request into the Allocate response. The TURN server acts as 462 a packet relay, forwarding traffic between L and R. In order to send 463 traffic to L, R sends traffic to the TURN server at Y:y, and the TURN 464 server forwards that to X1':x1', which passes through the NAT where 465 it is mapped to X:x and delivered to L. 467 When only STUN servers are utilized, the agent sends a STUN Binding 468 Request [I-D.ietf-behave-rfc3489bis] to its STUN server. The STUN 469 server will inform the agent of the server reflexive candidate 470 X1':x1' by copying the source transport address of the Binding 471 request into the Binding response. 473 2.2. Connectivity Checks 475 Once L has gathered all of its candidates, it orders them in highest 476 to lowest priority and sends them to R over the signalling channel. 477 The candidates are carried in attributes in the SDP offer. When R 478 receives the offer, it performs the same gathering process and 479 responds with its own list of candidates. At the end of this 480 process, each agent has a complete list of both its candidates and 481 its peer's candidates. It pairs them up, resulting in CANDIDATE 482 PAIRS. To see which pairs work, the agent schedules a series of 483 CHECKS. Each check is a STUN request/response transaction that the 484 client will perform on a particular candidate pair by sending a STUN 485 request from the local candidate to the remote candidate. 487 The basic principle of the connectivity checks is simple: 489 1. Sort the candidate pairs in priority order. 491 2. Send checks on each candidate pair in priority order. 493 3. Acknowledge checks received from the other agent. 495 With both agents performing a check on a candidate pair, the result 496 is a 4-way handshake: 498 L R 499 - - 500 STUN request -> \ L's 501 <- STUN response / check 503 <- STUN request \ R's 504 STUN response -> / check 506 Figure 3: Basic Connectivity Check 508 It is important to note that the STUN requests are sent to and from 509 the exact same IP addresses and ports that will be used for media 510 (e.g., RTP and RTCP). Consequently, agents demultiplex STUN and RTP/ 511 RTCP using contents of the packets, rather than the port on which 512 they are received. Fortunately, this demultiplexing is easy to do, 513 especially for RTP and RTCP. 515 Because a STUN Binding Request is used for the connectivity check, 516 the STUN Binding response will contain the agent's translated 517 transport address on the public side any NATs between the agent and 518 its peer. If this transport address is different from other 519 candidates the agent already learned, it represents a new candidate, 520 called a PEER REFLEXIVE CANDIDATE, which then gets tested by ICE just 521 the same as any other candidate. 523 As an optimization, as soon as R gets L's check message, R schedules 524 a connectivity check message to be sent to L on the same candidate 525 pair. This accelerates the process of finding a valid candidate, and 526 is called a TRIGGERED CHECK. 528 At the end of this handshake, both L and R know that they can send 529 (and receive) messages end-to-end in both directions. 531 2.3. Sorting Candidates 533 Because the algorithm above searches all candidate pairs, if a 534 working pair exists it will eventually find it no matter what order 535 the candidates are tried in. In order to produce faster (and better) 536 results, the candidates are sorted in a specified order. The 537 resulting list of sorted candidate pairs is called the CHECK LIST. 538 The algorithm is described in Section 4.1.2 but follows two general 539 principles: 541 o Each agent gives its candidates a numeric priority which is sent 542 along with the candidate to the peer 544 o The local and remote priorities are combined so that each agent 545 has the same ordering for the candidate pairs. 547 The second property is important for getting ICE to work when there 548 are NATs in front of L and R. Frequently, NATs will not allow packets 549 in from a host until the agent behind the NAT has sent a packet 550 towards that host. Consequently, ICE checks in each direction will 551 not succeed until both sides have sent a check through their 552 respective NATs. 554 The agent works through this check list by sending a STUN request for 555 the next candidate pair on the list periodically. These are called 556 ORDINARY CHECKS. 558 In general the priority algorithm is designed so that candidates of 559 similar type get similar priorities and so that more direct routes 560 (that is, through fewer media relays and through fewer NATs) are 561 preferred over indirect ones (ones with more media relays and more 562 NATs). Within those guidelines, however, agents have a fair amount 563 of discretion about how to tune their algorithms. 565 2.4. Frozen Candidates 567 The previous description only addresses the case where the agents 568 wish to establish a media session with one COMPONENT (a piece of a 569 media stream requiring a single transport address; a media stream may 570 require multiple components, each of which has to work for the media 571 stream as a whole to be work). Typically, (e.g., with RTP and RTCP) 572 the agents actually need to establish connectivity for more than one 573 flow. 575 The network properties are likely to be very similar for each 576 component (especially because RTP and RTCP are sent and received from 577 the same IP address). It is usually possible to leverage information 578 from one media component in order to determine the best candidates 579 for another. ICE does this with a mechanism called "frozen 580 candidates." 582 Each candidate is associated with a property called its FOUNDATION. 583 Two candidates have the same foundation when they are "similar" - of 584 the same type and obtained from the same interface and STUN server 585 using the same protocol. Otherwise, their foundation is different. 586 A candidate pair has a foundation too, which is just the 587 concatenation of the foundations of its two candidates. Initially, 588 only the candidate pairs with unique foundations are tested. The 589 other candidate pairs are marked "frozen". When the connectivity 590 checks for a candidate pair succeed, the other candidate pairs with 591 the same foundation are unfrozen. This avoids repeated checking of 592 components which are superficially more attractive but in fact are 593 likely to fail. 595 While we've described "frozen" here as a separate mechanism for 596 expository purposes, in fact it is an integral part of ICE and the 597 the ICE prioritization algorithm automatically ensures that the right 598 candidates are unfrozen and checked in the right order. 600 2.5. Security for Checks 602 Because ICE is used to discover which addresses can be used to send 603 media between two agents, it is important to ensure that the process 604 cannot be hijacked to send media to the wrong location. Each STUN 605 connectivity check is covered by a message authentication code (MAC) 606 computed using a key exchanged in the signalling channel. This MAC 607 provides message integrity and data origin authentication, thus 608 stopping an attacker from forging or modifying connectivity check 609 messages. The MAC also aids in disambiguating ICE exchanges from 610 forked calls when ICE is used with SIP [RFC3261]. 612 2.6. Concluding ICE 614 ICE checks are performed in a specific sequence, so that high 615 priority candidate pairs are checked first, followed by lower 616 priority ones. One way to conclude ICE is to declare victory as soon 617 as a check for each component of each media stream completes 618 successfully. Indeed, this is a reasonable algorithm, and details 619 for it are provided below. However, it is possible that packet 620 losses will cause a higher priority check to take longer to complete. 621 In that case, allowing ICE to run a little longer might produce 622 better results. More fundamentally, however, the prioritization 623 defined by this specification may not yield "optimal" results. As an 624 example, if the aim is to select low latency media paths, usage of a 625 relay is a hint that latencies may be higher, but it is nothing more 626 than a hint. An actual RTT measurement could be made, and it might 627 demonstrate that a pair with lower priority is actually better than 628 one with higher priority. 630 Consequently, ICE assigns one of the agents in the role of the 631 CONTROLLING AGENT, and the other of the CONTROLLED AGENT. The 632 controlling agent gets to nominate which candidate pairs will get 633 used for media amongst the ones that are valid. It can do this in 634 one of two ways - using REGULAR NOMINATION or AGGRESSIVE NOMINATION. 636 With regular nomination, the controlling agent lets the checks 637 continue until at least one valid candidate pair for each media 638 stream is found. Then, it picks amongst those that are valid, and 639 sends a second STUN request on its NOMINATED candidate pair, but this 640 time with a flag set to tell the peer that this pair has been 641 nominated for use. This is shown in Figure 4. 643 L R 644 - - 645 STUN request -> \ L's 646 <- STUN response / check 648 <- STUN request \ R's 649 STUN response -> / check 651 STUN request + flag -> \ L's 652 <- STUN response / check 654 Figure 4: Regular Nomination 656 Once the STUN transaction with the flag completes, both sides cancel 657 any future checks for that media stream. ICE will now send media 658 using this pair. The pair an ICE agent is using for media is called 659 the SELECTED PAIR. 661 In aggressive nomination, the controlling agent puts the flag in 662 every STUN request it sends. This way, once the first check 663 succeeds, ICE processing is complete for that media stream and the 664 controlling agent doesn't have to send a second STUN request. The 665 selected pair will be the highest priority valid pair whose check 666 succeeeded. Aggressive nomination is faster than regular nomination, 667 but gives less flexibility. Aggressive nomination is shown in 668 Figure 5. 670 L R 671 - - 672 STUN request + flag -> \ L's 673 <- STUN response / check 675 <- STUN request \ R's 676 STUN response -> / check 678 Figure 5: Aggressive Nomination 680 Once all of the media streams are completed, the controlling endpoint 681 sends an updated offer if the candidates in the m and c lines for the 682 media stream (called the DEFAULT CANDIDATES) don't match ICE's 683 SELECTED CANDIDATES. 685 Once ICE is concluded, it can be restarted at any time for one or all 686 of the media streams by either agent. This is done by sending an 687 updated offer indicating a restart. 689 2.7. Lite Implementations 691 In order for ICE to be used in a call, both agents need to support 692 it. However, certain agents will always be connected to the public 693 Internet and have a public IP address at which it can receive packets 694 from any correspondent. To make it easier for these devices to 695 support ICE, ICE defines a special type of implementation called LITE 696 (in contrast to the normal FULL implementation). A lite 697 implementation doesn't gather candidates; it includes only host 698 candidates for any media stream. Lite agents do not generate 699 connectivity checks or run the state machines, though they need to be 700 able to respond to connectivity checks. When a lite implementation 701 connects with a full implementation, the full agent takes the role of 702 the controlling agent, and the lite agent takes on the controlled 703 role. When two lite implementations connect, no checks are sent. 705 For guidance on when a lite implementation is appropriate, see the 706 discussion in Appendix A. 708 It is important to note that the lite implementation was added to 709 this specification to provide a stepping stone to full 710 implementation. Even for devices that are always connected to the 711 public Internet, a full implementation is preferable if achievable. 713 3. Terminology 715 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 716 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 717 document are to be interpreted as described in RFC 2119 [RFC2119]. 719 Readers should be familiar with the terminology defined in the offer/ 720 answer model [RFC3264], STUN [I-D.ietf-behave-rfc3489bis] and NAT 721 Behavioral requirements for UDP [RFC4787] 723 This specification makes use of the following additional terminology: 725 Agent: As defined in RFC 3264, an agent is the protocol 726 implementation involved in the offer/answer exchange. There are 727 two agents involved in an offer/answer exchange. 729 Peer: From the perspective of one of the agents in a session, its 730 peer is the other agent. Specifically, from the perspective of 731 the offerer, the peer is the answerer. From the perspective of 732 the answerer, the peer is the offerer. 734 Transport Address: The combination of an IP address and transport 735 protocol (such as UDP or TCP) port. 737 Candidate: A transport address that is a potential point of contact 738 for receipt of media. Candidates also have properties - their 739 type (server reflexive, relayed or host), priority, foundation, 740 and base. 742 Component: A component is a piece of a media stream requiring a 743 single transport address; a media stream may require multiple 744 components, each of which has to work for the media stream as a 745 whole to work. For media streams based on RTP, there are two 746 components per media stream - one for RTP, and one for RTCP. 748 Host Candidate: A candidate obtained by binding to a specific port 749 from an interface on the host. This includes both physical 750 interfaces and logical ones, such as ones obtained through Virtual 751 Private Networks (VPNs) and Realm Specific IP (RSIP) [RFC3102] 752 (which lives at the operating system level). 754 Server Reflexive Candidate: A candidate whose IP address and port 755 are a binding allocated by a NAT for an agent when it sent a 756 packet through the NAT to a server. Server reflexive candidates 757 can be learned by STUN servers using the Binding Request, or TURN 758 servers, which provides both a Relayed and Server Reflexive 759 candidate. 761 Peer Reflexive Candidate: A candidate whose IP address and port are 762 a binding allocated by a NAT for an agent when it sent a STUN 763 Binding Request through the NAT to its peer. 765 Relayed Candidate: A candidate obtained by sending a TURN Allocate 766 request from a host candidate to a TURN server. The relayed 767 candidate is resident on the TURN server, and the TURN server 768 relays packets back towards the agent. 770 Base: The base of a server reflexive candidate is the host candidate 771 from which it was derived. A host candidate is also said to have 772 a base, equal to that candidate itself. Similarly, the base of a 773 relayed candidate is that candidate itself. 775 Foundation: An arbitrary string that is the same for two candidates 776 that have the same type, base IP address, protocol (UDP, TCP, 777 etc.) and STUN or TURN server. If any of these are different then 778 the foundation will be different. Two candidate pairs with the 779 same foundation pairs are likely to have similar network 780 characteristics. Foundations are used in the frozen algorithm. 782 Local Candidate: A candidate that an agent has obtained and included 783 in an offer or answer it sent. 785 Remote Candidate: A candidate that an agent received in an offer or 786 answer from its peer. 788 Default Destination/Candidate: The default destination for a 789 component of a media stream is the transport address that would be 790 used by an agent that is not ICE aware. For the RTP component, 791 the default IP address is in the c line of the SDP, and the port 792 in the m line. For the RTCP component it is in the rtcp attribute 793 when present, and when not present, the IP address in the c line 794 and 1 plus the port in the m line. A default candidate for a 795 component is one whose transport address matches the default 796 destination for that component. 798 Candidate Pair: A pairing containing a local candidate and a remote 799 candidate. 801 Check, Connectivity Check, STUN Check: A STUN Binding Request 802 transaction for the purposes of verifying connectivity. A check 803 is sent from the local candidate to the remote candidate of a 804 candidate pair. 806 Check List: An ordered set of candidate pairs that an agent will use 807 to generate checks. 809 Ordinary Check: A connectivity check generated by an agent as a 810 consequence of a timer that fires periodically, instructing it to 811 send a check. 813 Triggered Check: A connectivity check generated as a consequence of 814 the receipt of a connectivity check from the peer. 816 Valid List: An ordered set of candidate pairs for a media stream 817 that have been validated by a successful STUN transaction. 819 Full: An ICE implementation that performs the complete set of 820 functionality defined by this specification. 822 Lite: An ICE implementation that omits certain functions, 823 implementing only as much as is necessary for a peer 824 implementation that is full to gain the benefits of ICE. Lite 825 implementations do not maintain any of the state machines and do 826 not generate connectivity checks. 828 Controlling Agent: The ICE agent which is responsible for selecting 829 the final choice of candidate pairs and signaling them through 830 STUN and an updated offer, if needed. In any session, one agent 831 is always controlling. The other is the controlled agent. 833 Controlled Agent: An ICE agent which waits for the controlling agent 834 to select the final choice of candidate pairs. 836 Regular Nomination: The process of picking a valid candidate pair 837 for media traffic by validating the pair with one STUN request, 838 and then picking it by sending a second STUN request with a flag 839 indicating its nomination. 841 Aggressive Nomination: The process of picking a valid candidate pair 842 for media traffic by including a flag in every STUN request, such 843 that the first one to produce a valid candidate pair is used for 844 media. 846 Nominated: If a valid candidate pair has its nominated flag set, it 847 means that it may be selected by ICE for sending and receiving 848 media. 850 Selected Pair, Selected Candidate: The candidate pair selected by 851 ICE for sending and receiving media is called the selected pair, 852 and each of its candidates is called the selected candidate. 854 4. Sending the Initial Offer 856 In order to send the initial offer in an offer/answer exchange, an 857 agent must (1) gather candidates, (2) prioritize them, (3) choose 858 default candidates, and then (4) formulate and send the SDP. The 859 first of these four steps differ for full and lite implementations. 861 4.1. Full Implementation Requirements 863 4.1.1. Gathering Candidates 865 An agent gathers candidates when it believes that communications is 866 imminent. An offerer can do this based on a user interface cue, or 867 based on an explicit request to initiate a session. Every candidate 868 is a transport address. It also has a type and a base. Three types 869 are defined and gathered by this specification - host candidates, 870 server reflexive candidates, and relayed candidates. The server 871 reflexive and relayed candidates are gathered using STUN or TURN, and 872 relayed candidates are obtained through TURN. The base of a 873 candidate is the candidate that an agent must send from when using 874 that candidate. 876 4.1.1.1. Host Candidates 878 The first step is to gather host candidates. Host candidates are 879 obtained by binding to ports (typically ephemeral) on an interface 880 (physical or virtual, including VPN interfaces) on the host. The 881 process for gathering host candidates depends on the transport 882 protocol. Procedures are specified here for UDP. 884 For each UDP media stream the agent wishes to use, the agent SHOULD 885 obtain a candidate for each component of the media stream on each 886 interface that the host has. It obtains each candidate by binding to 887 a UDP port on the specific interface. A host candidate (and indeed 888 every candidate) is always associated with a specific component for 889 which it is a candidate. Each component has an ID assigned to it, 890 called the component ID. For RTP-based media streams, the RTP itself 891 has a component ID of 1, and RTCP a component ID of 2. If an agent 892 is using RTCP it MUST obtain a candidate for it. If an agent is 893 using both RTP and RTCP, it would end up with 2*K host candidates if 894 an agent has K interfaces. 896 The base for each host candidate is set to the candidate itself. 898 4.1.1.2. Server Reflexive and Relayed Candidates 900 Agents SHOULD obtain relayed candidates and SHOULD obtain server 901 reflexive candidates. These requirements are at SHOULD strength to 902 allow for provider variation. Use of STUN and TURN servers may be 903 unnecessary in closed networks where agents are never connected to 904 the public Internet or to endpoints outside of the closed network. 905 In such cases, a full implementation would be used for agents that 906 are dual-stack or multi-homed, to select a host candidate. Use of 907 TURN servers is expensive, and when ICE is being used, they will only 908 be utilized when both endpoints are behind NATs that perform address 909 and port dependent mapping. Consequently, some deployments might 910 consider this use case to be marginal, and elect not to use TURN 911 servers. If an agent does not gather server reflexive or relayed 912 candidates, it is RECOMMENDED that the functionality be implemented 913 and just disabled through configuration, so that it can re-enabled 914 through configuration if conditions change in the future. 916 If an agent is gathering both relayed and server reflexive 917 candidates, it uses a TURN server. If it is gathering just server 918 reflexive candidates, it uses a STUN server. 920 The agent next pairs each host candidate with the STUN or TURN server 921 with which it is configured or has discovered by some means. If a 922 STUN or TURN server is configured, it is RECOMMENDED that a domain 923 name be configured, and the DNS procedures in 925 [I-D.ietf-behave-rfc3489bis] (using SRV records with the "stun" 926 service) be used to discover the STUN server, and the DNS procedures 927 in [I-D.ietf-behave-turn] (using SRV records with the "turn" service) 928 be used to discover the TURN server. 930 This specification only considers usage of a single STUN or TURN 931 server. When there are multiple choices for that single STUN or TURN 932 server (when, for example, they are learned through DNS records and 933 multiple results are returned), an agent SHOULD use a single STUN or 934 TURN server (based on its IP address) for all candidates for a 935 particular session. This improves the performance of ICE. The 936 result is a set of pairs of host candidates with STUN or TURN 937 servers. The agent then chooses one pair, and sends a Binding or 938 Allocate request to the server from that host candidate. Binding 939 Requests to a STUN server are not authenticated, and any ALTERNATE- 940 SERVER attribute in a response is ignored. Agents MUST support the 941 backwards compatibility mode for the Binding Request defined in 942 [I-D.ietf-behave-rfc3489bis]. Allocate requests SHOULD be 943 authenticated using a long-term credential provisioned into the 944 client. 946 Every Ta milliseconds thereafter, the agent can generate another new 947 STUN or TURN transaction. This transaction can either be a retry of 948 a previous transaction which failed with a recoverable error (such as 949 authentication failure), or a transaction for a new host candidate 950 and STUN or TURN server pair. The agent SHOULD NOT generate 951 transactions more frequently than one every Ta milliseconds. See 952 Section 16 for guidance on how to set Ta and the STUN retransmit 953 timer, RTO. 955 The agent will receive a Binding or Allocate response. A successful 956 Allocate Response will provide the agent with a server reflexive 957 candidate (obtained from the mapped address) and a relayed candidate 958 in the RELAY-ADDRESS attribute. If the Allocate request is rejected 959 because the server lacks resources to fulfill it, the agent SHOULD 960 instead send a Binding Request to obtain a server reflexive 961 candidate. A Binding Response will provide the agent with only a 962 server reflexive candidate (also obtained from the mapped address). 963 The base of the server reflexive candidate is the host candidate from 964 which the Allocate or Binding request was sent. The base of a 965 relayed candidate is that candidate itself. If a relayed candidate 966 is identical to a host candidate (which can happen in rare cases), 967 the relayed candidate MUST be discarded. 969 4.1.1.3. Eliminating Redundant Candidates 971 Next, the agent eliminates redundant candidates. A candidate is 972 redundant if its transport address equals another candidate, and its 973 base equals the base of that other candidate. Note that two 974 candidates can have the same transport address yet have different 975 bases, and these would not be considered redundant. Frequently, a 976 server reflexive candidate and a host candidate will be redundant 977 when the agent is not behind a NAT. 979 4.1.1.4. Computing Foundations 981 Finally, the agent assigns each candidate a foundation. The 982 foundation is an identifier, scoped within a session. Two candidates 983 MUST have the same foundation ID when all of the following are true: 985 o they are of the same type (host, relayed, server reflexive, or 986 peer reflexive) 988 o their bases have the same IP address (the ports can be different) 990 o for reflexive and relayed candidates, the STUN or TURN servers 991 used to obtain them have the same IP address. 993 o they were obtained using the same transport protocol (TCP, UDP, 994 etc.) 996 Similarly, two candidates MUST have different foundations if their 997 types are different, their bases have different IP addresses, the 998 STUN or TURN servers used to obtain them have different IP addresses, 999 or their transport protocols are different. 1001 4.1.1.5. Keeping Candidates Alive 1003 Once server reflexive and relayed candidates are allocated, they MUST 1004 be kept alive until ICE processing has completed, as described in 1005 Section 8.3. For server reflexive candidates learned through a 1006 Binding request, the bindings MUST be kept alive by another Binding 1007 Request to the server. For relayed candidates learned through an 1008 Allocate request, the keepalive MUST be a new Allocate request. The 1009 Allocate request will also refresh the server reflexive candidate. 1011 4.1.2. Prioritizing Candidates 1013 The prioritization process results in the assignment of a priority to 1014 each candidate. Each candidate for a media stream MUST have a unique 1015 priority that MUST be a positive integer between 1 and (2**32 - 1). 1016 This priority will be used by ICE to determine the order of the 1017 connectivity checks and the relative preference for candidates. 1019 An agent SHOULD compute this priority using the formula in 1020 Section 4.1.2.1 and choose its parameters using the guidelines in 1021 Section 4.1.2.2. If an agent elects to use a different formula, ICE 1022 will take longer to converge since both agents will not be 1023 coordinated in their checks. 1025 4.1.2.1. Recommended Formula 1027 When using the formula, an agent computes the priority by determining 1028 a preference for each type of candidate (server reflexive, peer 1029 reflexive, relayed and host), and, when the agent is multihomed, 1030 choosing a preference for its interfaces. These two preferences are 1031 then combined to compute the priority for a candidate. That priority 1032 is computed using the following formula: 1034 priority = (2^24)*(type preference) + 1035 (2^8)*(local preference) + 1036 (2^0)*(256 - component ID) 1038 The type preference MUST be an integer from 0 to 126 inclusive, and 1039 represents the preference for the type of the candidate (where the 1040 types are local, server reflexive, peer reflexive and relayed). A 1041 126 is the highest preference, and a 0 is the lowest. Setting the 1042 value to a 0 means that candidates of this type will only be used as 1043 a last resort. The type preference MUST be identical for all 1044 candidates of the same type and MUST be different for candidates of 1045 different types. The type preference for peer reflexive candidates 1046 MUST be higher than that of server reflexive candidates. Note that 1047 candidates gathered based on the procedures of Section 4.1.1 will 1048 never be peer reflexive candidates; candidates of these type are 1049 learned from the connectivity checks performed by ICE. 1051 The local preference MUST be an integer from 0 to 65535 inclusive. 1052 It represents a preference for the particular interface from which 1053 the candidate was obtained, in cases where an agent is multihomed. 1054 65535 represents the highest preference, and a zero, the lowest. 1055 When there is only a single interface, this value SHOULD be set to 1056 65535. More generally, if there are multiple candidates for a 1057 particular component for a particular media stream which have the 1058 same type, the local preference MUST be unique for each one. In this 1059 specification, this only happens for multi-homed hosts. 1061 The component ID is the component ID for the candidate, and MUST be 1062 between 1 and 256 inclusive. 1064 4.1.2.2. Guidelines for Choosing Type and Local Preferences 1066 One criteria for selection of the type and local preference values is 1067 the use of a media intermediary, such as a TURN server, VPN server or 1068 NAT. With a media intermediary, if media is sent to that candidate, 1069 it will first transit the media intermediary before being received. 1070 Relayed candidates are one type of candidate that involves a media 1071 intermediary. Another are host candidates obtained from a VPN 1072 interface. When media is transited through a media intermediary, it 1073 can increase the latency between transmission and reception. It can 1074 increase the packet losses, because of the additional router hops 1075 that may be taken. It may increase the cost of providing service, 1076 since media will be routed in and right back out of a media 1077 intermediary run by a provider. If these concerns are important, the 1078 type preference for relayed candidates SHOULD be lower than host 1079 candidates. The RECOMMENDED values are 126 for host candidates, 100 1080 for server reflexive candidates, 110 for peer reflexive candidates, 1081 and 0 for relayed candidates. Furthermore, if an agent is multi- 1082 homed and has multiple interfaces, the local preference for host 1083 candidates from a VPN interface SHOULD have a priority of 0. 1085 Another criteria for selection of preferences is IP address family. 1086 ICE works with both IPv4 and IPv6. It therefore provides a 1087 transition mechanism that allows dual-stack hosts to prefer 1088 connectivity over IPv6, but to fall back to IPv4 in case the v6 1089 networks are disconnected (due, for example, to a failure in a 6to4 1090 relay) [RFC3056]. It can also help with hosts that have both a 1091 native IPv6 address and a 6to4 address. In such a case, higher local 1092 preferences could be assigned to the v6 interface, followed by the 1093 6to4 interfaces, followed by the v4 interfaces. This allows a site 1094 to obtain and begin using native v6 addresses immediately, yet still 1095 fallback to 6to4 addresses when communicating with agents in other 1096 sites that do not yet have native v6 connectivity. 1098 Another criteria for selecting preferences is security. If a user is 1099 a telecommuter, and therefore connected to their corporate network 1100 and a local home network, they may prefer their voice traffic to be 1101 routed over the VPN in order to keep it on the corporate network when 1102 communicating within the enterprise, but use the local network when 1103 communicating with users outside of the enterprise. In such a case, 1104 a VPN interface would have a higher local preference than any other 1105 interface. 1107 Another criteria for selecting preferences is topological awareness. 1108 This is most useful for candidates that make use of intermediaries. 1109 In those cases, if an agent has preconfigured or dynamically 1110 discovered knowledge of the topological proximity of the 1111 intermediaries to itself, it can use that to assign higher local 1112 preferences to candidates obtained from closer intermediaries. 1114 4.1.3. Choosing Default Candidates 1116 A candidate is said to be default if it would be the target of media 1117 from a non-ICE peer; that target being called the DEFAULT 1118 DESTINATION. If the default candidates are not selected by the ICE 1119 algorithm when communicating with an ICE-aware peer, an updated 1120 offer/answer will be required after ICE processing completes in order 1121 to "fix-up" the SDP so that the default destination for media matches 1122 the candidates selected by ICE. If ICE happens to select the default 1123 candidates, no updated offer/answer is required. 1125 An agent MUST choose a set of candidates, one for each component of 1126 each in-use media stream, to be default. A media stream is in-use if 1127 it does not have a port of zero (which is used in RFC 3264 to reject 1128 a media stream). Consequently, a media stream is in-use even if it 1129 is marked as a=inactive [RFC4566] or has a bandwidth value of zero. 1131 It is RECOMMENDED that default candidates be chosen based on the 1132 likelihood of those candidates to work with the peer that is being 1133 contacted. It is RECOMMENDED that the default candidates are the 1134 relayed candidates (if relayed candidates are available), server 1135 reflexive candidates (if server reflexive candidates are available), 1136 and finally host candidates. 1138 4.2. Lite Implementation 1140 Lite implementations only utilize host candidates. A lite 1141 implementation MUST, for each component of each media stream, 1142 allocate zero or one IPv4 candidates. It MAY allocate zero or more 1143 IPv6 candidates, but no more than one per each IPv6 address utilized 1144 by the host. Since there can be no more than one IPv4 candidate per 1145 component of each media stream, if an agent has multiple IPv4 1146 interfaces, it MUST choose one for allocating the candidate. If a 1147 host is dual-stack, it is RECOMMENDED that it allocate one IPv4 1148 candidate and one global IPv6 address. With the lite implementation, 1149 ICE cannot be used to dynamically choose amongst candidates. 1150 Therefore, including more than one candidate from a particular scope 1151 is NOT RECOMMENDED, since only a connectivity check can truly 1152 determine whether to use one address or the other. 1154 Each component has an ID assigned to it, called the component ID. 1155 For RTP-based media streams the RTP itself has a component ID of 1, 1156 and RTCP a component ID of 2. If an agent is using RTCP it MUST 1157 obtain candidates for it. 1159 Each candidate is assigned a foundation. The foundation MUST be 1160 different for two candidates allocated from different IP addresses, 1161 and MUST be the same otherwise. A simple integer that increments for 1162 each IP address will suffice. In addition, each candidate MUST be 1163 assigned a unique priority amongst all candidates for the same media 1164 stream. This priority SHOULD be equal to: 1166 priority = (2^24)*(126) + 1167 (2^8)*(IP precedence) + 1168 (2^0)*(256 - component ID) 1170 If a host is v4-only, it SHOULD set the IP precedence to 65535. If a 1171 host is v6 or dual-stack, the IP precedence is the precedence value 1172 for IP addresses described in RFC 3484 [RFC3484]. 1174 Next, an agent chooses a default candidate for each component of each 1175 media stream. If a host is IPv4 only, there would only be one 1176 candidate for each component of each media stream, and therefore that 1177 candidate is the default. If a host is IPv6 or dual stack, the 1178 selection of default is a matter of local policy. This default 1179 SHOULD be chosen, such that, it is the candidate most likely to be 1180 used with a peer. For IPv6-only hosts, this would typically by a 1181 globally scoped IPv6 address. For dual-stack hosts, the IPv4 address 1182 is RECOMMENDED. 1184 4.3. Encoding the SDP 1186 The process of encoding the SDP is identical between full and lite 1187 implementations. 1189 The agent will include an m-line for each media stream it wishes to 1190 use. The ordering of media streams in the SDP is relevant for ICE. 1191 ICE will perform its connectivity checks for the first m-line first, 1192 and consequently media will be able to flow for that stream first. 1193 Agents SHOULD place their most important media stream, if there is 1194 one, first in the SDP. 1196 There will be a candidate attribute for each candidate for a 1197 particular media stream. Section 15 provides detailed rules for 1198 constructing this attribute. The attribute carries the IP address, 1199 port and transport protocol for the candidate, in addition to its 1200 properties that need to be signaled to the peer for ICE to work: the 1201 priority, foundation, and component ID. The candidate attribute also 1202 carries information about the candidate that is useful for 1203 diagnostics and other functions: its type and related transport 1204 addresses. 1206 STUN connectivity checks between agents are authenticated using the 1207 short term credential mechanism defined for STUN 1208 [I-D.ietf-behave-rfc3489bis]. This mechanism relies on a username 1209 and password that are exchanged through protocol machinery between 1210 the client and server. With ICE, the offer/answer exchange is used 1211 to exchange them. The username part of this credential is formed by 1212 concatenating a username fragment from each agent, separated by a 1213 colon. Each agent also provides a password, used to compute the 1214 message integrity for requests it receives. The username fragment 1215 and password are exchanged in the ice-ufrag and ice-pwd attributes, 1216 respectively. In addition to providing security, the username 1217 provides disambiguation and correlation of checks to media streams. 1218 See Appendix B.4 for motivation. 1220 If an agent is a lite implementation, it MUST include an "a=ice-lite" 1221 session level attribute in its SDP. If an agent is a full 1222 implementation, it MUST NOT include this attribute. 1224 The default candidates are added to the SDP as the default 1225 destination for media. For streams based on RTP, this is done by 1226 placing the IP address and port of the RTP candidate into the c and m 1227 lines, respectively. If the agent is utilizing RTCP, it MUST encode 1228 the RTCP candidate using the a=rtcp attribute as defined in RFC 3605 1229 [RFC3605]. If RTCP is not in use, the agent MUST signal that using 1230 b=RS:0 and b=RR:0 as defined in RFC 3556 [RFC3556]. 1232 The transport addresses that will be the default destination for 1233 media when communicating with non-ICE peers MUST also be present as 1234 candidates in one or more a=candidate lines. 1236 ICE provides for extensibility by allowing an offer or answer to 1237 contain a series of tokens which identify the ICE extensions used by 1238 that agent. If an agent supports an ICE extension, it MUST include 1239 the token defined for that extension in the ice-options attribute. 1241 The following is an example SDP message that includes ICE attributes 1242 (lines folded for readability): 1244 v=0 1245 o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1 1246 s= 1247 c=IN IP4 192.0.2.3 1248 t=0 0 1249 a=ice-pwd:asd88fgpdd777uzjYhagZg 1250 a=ice-ufrag:8hhY 1251 m=audio 45664 RTP/AVP 0 1252 b=RS:0 1253 b=RR:0 1254 a=rtpmap:0 PCMU/8000 1255 a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host 1256 a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 1257 10.0.1.1 rport 8998 1259 Once an agent has sent its offer or sent its answer, that agent MUST 1260 be prepared to receive both STUN and media packets on each candidate. 1261 As discussed in Section 11.1, media packets can be sent to a 1262 candidate prior to its appearance as the default destination for 1263 media in an offer or answer. 1265 5. Receiving the Initial Offer 1267 When an agent receives an initial offer, it will check if the offerer 1268 supports ICE, determine its own role, gather candidates, prioritize 1269 them, choose default candidates, encode and send an answer, and for 1270 full implementations, form the check lists and begin connectivity 1271 checks. 1273 5.1. Verifying ICE Support 1275 The agent will proceed with the ICE procedures defined in this 1276 specification if, for each media stream in the SDP it received, the 1277 default destination for each component of that media stream appears 1278 in a candidate attribute. For example, in the case of RTP, the IP 1279 address and port in the c and m line, respectively, appears in a 1280 candidate attribute and the value in the rtcp attribute appears in a 1281 candidate attribute. 1283 If this condition is not met, the agent MUST process the SDP based on 1284 normal RFC 3264 procedures, without using any of the ICE mechanisms 1285 described in the remainder of this specification with the following 1286 exceptions: 1288 1. The agent MUST follow the rules of Section 10, which describe 1289 keepalive procedures for all agents. 1291 2. If the agent is not proceeding with ICE because there were 1292 a=candidate attributes, but none that matched the default 1293 destination of the media stream, the agent MUST include an a=ice- 1294 mismatch attribute in its answer. 1296 5.2. Determining Role 1298 For each session, each agent takes on a role. There are two roles - 1299 controlling, and controlled. The controlling agent is responsible 1300 for the choice of the final candidate pairs used for communications. 1301 For a full agent, this means nominating the candidate pairs that can 1302 be used by ICE for each media stream, and for generating the updated 1303 offer based on ICE's selection, when needed. For a lite 1304 implementation, being the controlling agent means selecting a 1305 candidate pair based on the ones in the offer and answer (for IPv4, 1306 there is only ever one pair), and then generating an updated offer 1307 reflecting that selection, when needed (it is never needed for an 1308 IPv4 only host). The controlled agent is told which candidate pairs 1309 to use for each media stream, and does not generate an updated offer 1310 to signal this information. The sections below describe in detail 1311 the actual procedures following by controlling and controlled nodes. 1313 The rules for determining the role and the impact on behavior are as 1314 follows: 1316 Both agents are full: The agent which generated the offer which 1317 started the ICE processing MUST take the controlling role, and the 1318 other MUST take the controlled role. Both agents will form check 1319 lists, run the ICE state machines, and generate connectivity 1320 checks. The controlling agent will execute the logic in 1321 Section 8.1 to nominate pairs that will be selected by ICE, and 1322 then both agents end ICE as described in Section 8.1.2. In 1323 unusual cases, described in Appendix B.11, it is possible for both 1324 agents to mistakenly believe they are controlled or controlling. 1325 To resolve this, each agent MUST select a random number, called 1326 the tie-breaker, uniformly distributed between 0 and (2**64) - 1 1327 (that is, a 64 bit positive integer). This number is used in 1328 connectivity checks to detect and repair this case, as described 1329 in Section 7.1.1.2. 1331 One agent Full, one Lite: The full agent MUST take the controlling 1332 role, and the lite agent MUST take the controlled role. The full 1333 agent will form check lists, run the ICE state machines, and 1334 generate connectivity checks. That agent will execute the logic 1335 in Section 8.1 to nominate pairs that will be selected by ICE, and 1336 use the logic in Section 8.1.2 to end ICE. The lite 1337 implementation will just listen for connectivity checks, receive 1338 them and respond to them, and then conclude ICE as described in 1339 Section 8.2. For the lite implementation, the state of ICE 1340 processing for each media stream is considered to be Running, and 1341 the state of ICE overall is Running. 1343 Both Lite: The agent which generated the offer which started the ICE 1344 processing MUST take the controlling role, and the other MUST take 1345 the controlled role. In this case, no connectivity checks are 1346 ever sent. Rather, once the offer/answer exchange completes, each 1347 agent performs the processing described in Section 8 without 1348 connectivity checks. It is possible that both agents will believe 1349 they are controlled or controlling. In the latter case, the 1350 conflict is resolved through glare detection capabilities in the 1351 signaling protocol carrying the offer/answer exchange. The state 1352 of ICE processing for each media stream is considered to be 1353 Running, and the state of ICE overall is Running. 1355 Once roles are determined for a session, they persist unless ICE is 1356 restarted. A ICE restart (Section 9.1) causes a new selection of 1357 roles and tie-breakers. 1359 5.3. Gathering Candidates 1361 The process for gathering candidates at the answerer is identical to 1362 the process for the offerer as described in Section 4.1.1 for full 1363 implementations and Section 4.2 for lite implementations. It is 1364 RECOMMENDED that this process begin immediately on receipt of the 1365 offer, prior to alerting the user. Such gathering MAY begin when an 1366 agent starts. 1368 5.4. Prioritizing Candidates 1370 The process for prioritizing candidates at the answerer is identical 1371 to the process followed by the offerer, as described in Section 4.1.2 1372 for full implementations and Section 4.2 for lite implementations. 1374 5.5. Choosing Default Candidates 1376 The process for selecting default candidates at the answerer is 1377 identical to the process followed by the offerer, as described in 1378 Section 4.1.3 for full implementations and Section 4.2 for lite 1379 implementations. 1381 5.6. Encoding the SDP 1383 The process for encoding the SDP at the answerer is identical to the 1384 process followed by the offerer for both full and lite 1385 implementations, as described in Section 4.3. 1387 5.7. Forming the Check Lists 1389 Forming check lists is done only by full implementations. Lite 1390 implementations MUST skip the steps defined in this section. 1392 There is one check list per in-use media stream resulting from the 1393 offer/answer exchange. To form the check list for a media stream, 1394 the agent forms candidate pairs, computes a candidate pair priority, 1395 orders the pairs by priority, prunes them, and sets their states. 1396 These steps are described in this section. 1398 5.7.1. Forming Candidate Pairs 1400 First, the agent takes each of its candidates for a media stream 1401 (called LOCAL CANDIDATES) and pairs them with the candidates it 1402 received from its peer (called REMOTE CANDIDATES) for that media 1403 stream. In order to prevent the attacks described in Section 18.5.2, 1404 agents MAY limit the number of candidates they'll accept in an offer 1405 or answer. A local candidate is paired with a remote candidate if 1406 and only if the two candidates have the same component ID and have 1407 the same IP address version. It is possible that some of the local 1408 candidates don't get paired with a remote candidate, and some of the 1409 remote candidates don't get paired with local candidates. This can 1410 happen if one agent didn't include candidates for the all of the 1411 components for a media stream. If this happens, the number of 1412 components for that media stream is effectively reduced, and 1413 considered to be equal to the minimum across both agents of the 1414 maximum component ID provided by each agent across all components for 1415 the media stream. 1417 In the case of RTP, this would happen when one agent provided 1418 candidates for RTCP, and the other did not. As another example, the 1419 offerer can multiplex RTP and RTCP on the same port and signals it 1420 can do that in the SDP through an SDP attribute 1421 [I-D.ietf-avt-rtp-and-rtcp-mux]. However, since the offerer doesn't 1422 know if the answerer can perform such multiplexing, the offerer 1423 includes candidates for RTP and RTCP on separate ports, so that the 1424 offer has two components per media stream. If the answerer can 1425 perform such multiplexing, it would include just a single component 1426 for each candidate - for the combined RTP/RTCP mux. ICE would end up 1427 acting as if there was just a single component for this candidate. 1429 The candidate pairs whose local and remote candidates were both the 1430 default candidates for a particular component is called, 1431 unsurprisingly, the default candidate pair for that component. This 1432 is the pair that would be used to transmit media if both agents had 1433 not been ICE aware. 1435 In order to aid understanding, Figure 9 shows the relationships 1436 between several key concepts - transport addresses, candidates, 1437 candidate pairs, and check lists, in addition to indicating the main 1438 properties of candidates and candidate pairs. 1440 +------------------------------------------+ 1441 | | 1442 | +---------------------+ | 1443 | |+----+ +----+ +----+ | +Type | 1444 | || IP | |Port| |Tran| | +Priority | 1445 | ||Addr| | | | | | +Foundation | 1446 | |+----+ +----+ +----+ | +ComponentiD | 1447 | | Transport | +RelatedAddr | 1448 | | Addr | | 1449 | +---------------------+ +Base | 1450 | Candidate | 1451 +------------------------------------------+ 1452 * * 1453 * ************************************* 1454 * * 1455 +-------------------------------+ 1456 .| | 1457 | Local Remote | 1458 | +----+ +----+ +default? | 1459 | |Cand| |Cand| +valid? | 1460 | +----+ +----+ +nominated?| 1461 | +State | 1462 | | 1463 | | 1464 | Candidate Pair | 1465 +-------------------------------+ 1466 * * 1467 * ************ 1468 * * 1469 +------------------+ 1470 | Candidate Pair | 1471 +------------------+ 1472 +------------------+ 1473 | Candidate Pair | 1474 +------------------+ 1475 +------------------+ 1476 | Candidate Pair | 1477 +------------------+ 1479 Check 1480 List 1481 Figure 9: Conceptual Diagram of a Check List 1483 5.7.2. Computing Pair Priority and Ordering Pairs 1485 Once the pairs are formed, a candidate pair priority is computed. 1486 Let G be the priority for the candidate provided by the controlling 1487 agent. Let D be the priority for the candidate provided by the 1488 controlled agent. The priority for a pair is computed as: 1490 pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0) 1492 Where G>D?1:0 is an expression whose value is 1 if G is greater than 1493 D, and 0 otherwise. This formula ensures a unique priority for each 1494 pair. Once the priority is assigned, the agent sorts the candidate 1495 pairs in decreasing order of priority. If two pairs have identical 1496 priority, the ordering amongst them is arbitrary. 1498 5.7.3. Pruning the Pairs 1500 This sorted list of candidate pairs is used to determine a sequence 1501 of connectivity checks that will be performed. Each check involves 1502 sending a request from a local candidate to a remote candidate. 1503 Since an agent cannot send requests directly from a reflexive 1504 candidate, but only from its base, the agent next goes through the 1505 sorted list of candidate pairs. For each pair where the local 1506 candidate is server reflexive, the server reflexive candidate MUST be 1507 replaced by its base. Once this has been done, the agent MUST prune 1508 the list. This is done by removing a pair if its local and remote 1509 candidates are identical to the local and remote candidates of a pair 1510 higher up on the priority list. The result is a sequence of ordered 1511 candidate pairs, called the check list for that media stream. 1513 In addition, in order to limit the attacks described in 1514 Section 18.5.2, an agent SHOULD limit the total number of 1515 connectivity checks they perform across all check lists to 100, by 1516 discarding the lower priority candidate pairs until there are less 1517 than 100. 1519 5.7.4. Computing States 1521 Each candidate pair in the check list has a foundation and a state. 1522 The foundation is the combination of the foundations of the local and 1523 remote candidates in the pair. The state is assigned once the check 1524 list for each media stream has been computed. There are five 1525 potential values that the state can have: 1527 Waiting: A check has not been performed for this pair, and can be 1528 performed as soon as it is the highest priority Waiting pair on 1529 the check list. 1531 In-Progress: A check has been sent for this pair, but the 1532 transaction is in progress. 1534 Succeeded: A check for this pair was already done and produced a 1535 successful result. 1537 Failed: A check for this pair was already done and failed, either 1538 never producing any response or producing an unrecoverable failure 1539 response. 1541 Frozen: A check for this pair hasn't been performed, and it can't 1542 yet be performed until some other check succeeds, allowing this 1543 pair to unfreeze and move into the Waiting state. 1545 As ICE runs, the pairs will move between states as shown in 1546 Figure 10. 1548 +-----------+ 1549 | | 1550 | | 1551 | Frozen | 1552 | | 1553 | | 1554 +-----------+ 1555 | 1556 |unfreeze 1557 | 1558 V 1559 +-----------+ +-----------+ 1560 | | | | 1561 | | perform | | 1562 | Waiting |-------->|In-Progress| 1563 | | | | 1564 | | | | 1565 +-----------+ +-----------+ 1566 / | 1567 // | 1568 // | 1569 // | 1570 / | 1571 // | 1572 failure // |success 1573 // | 1574 / | 1575 // | 1576 // | 1577 // | 1578 V V 1579 +-----------+ +-----------+ 1580 | | | | 1581 | | | | 1582 | Failed | | Succeeded | 1583 | | | | 1584 | | | | 1585 +-----------+ +-----------+ 1587 Figure 10: Pair State FSM 1589 The initial states for each pair in a check list are computed by 1590 performing the following sequence of steps: 1592 1. The agent sets all of the pairs in each check list to the Frozen 1593 state. 1595 2. The agent examines the check list for the first media stream (a 1596 media stream is the first media stream when it is described by 1597 the first m-line in the SDP offer and answer). For that media 1598 stream, it: 1600 * Groups together all of the pairs with the same foundation, 1602 * For each group, sets the state of the pair with the lowest 1603 component ID to Waiting. If there is more than one such pair, 1604 the one with the highest priority is used. 1606 One of the check lists will have some number of pairs in the Waiting 1607 state, and the other check lists will have all of their pairs in the 1608 Frozen state. A check list with at least one pair that is Waiting is 1609 called an active check list, and a check list with all pairs frozen 1610 is called a frozen check list. 1612 The check list itself is associated with a state, which captures the 1613 state of ICE checks for that media stream. There are three states: 1615 Running: In this state, ICE checks are still in progress for this 1616 media stream. 1618 Completed: In this state, ICE checks have produced nominated pairs 1619 for each component of the media stream. Consequently, ICE has 1620 succeeded and media can be sent. 1622 Failed: In this state, the ICE checks have not completed 1623 successfully for this media stream. 1625 When a check list is first constructed as the consequence of an 1626 offer/answer exchange, it is placed in the Running state. 1628 ICE processing across all media streams also has a state associated 1629 with it. This state is equal to Running while ICE processing is 1630 underway. The state is Completed when ICE processing is complete and 1631 Failed if it failed without success. Rules for transitioning between 1632 states are described below. 1634 5.8. Scheduling Checks 1636 Checks are generated only by full implementations. Lite 1637 implementations MUST skip the steps described in this section. 1639 An agent performs ordinary checks and triggered checks. The 1640 generation of both checks is governed by a timer which fires 1641 periodically for each media stream. The agent maintains a FIFO 1642 queue, called the triggered check queue, which contains candidate 1643 pairs for which checks are to be sent at the next available 1644 opportunity. When the timer fires, the agent removes the top pair 1645 from triggered check queue, performs a connectivity check on that 1646 pair, and sets the state of the candidate pair to In-Progress. If 1647 there are no pairs in the triggered check queue, an ordinary check is 1648 sent. 1650 Once the agent has computed the check lists as described in 1651 Section 5.7, it sets a timer for each active check list. The timer 1652 fires every Ta*N seconds, where N is the number of active check lists 1653 (initially, there is only one active check list). Implementations 1654 MAY set the timer to fire less frequently than this. Implementations 1655 SHOULD take care to spread out these timers so that they do not fire 1656 at the same time for each media stream. Ta and the retransmit timer 1657 RTO are computed as described in Section 16. Multiplying by N allows 1658 this aggregate check throughput to be split between all active check 1659 lists. The first timer fires immediately, so that the agent performs 1660 a connectivity check the moment the offer/answer exchange has been 1661 done, followed by the next check Ta seconds later (since there is 1662 only one active check list). 1664 When the timer fires, and there is no triggered check to be sent, the 1665 agent MUST choose an ordinary check as follows: 1667 o Find the highest priority pair in that check list that is in the 1668 Waiting state. 1670 o If there is such a pair: 1672 * Send a STUN check from the local candidate of that pair to the 1673 remote candidate of that pair. The procedures for forming the 1674 STUN request for this purpose are described in Section 7.1.1. 1676 * Set the state of the candidate pair to In-Progress. 1678 o If there is no such pair: 1680 * Find the highest priority pair in that check list that is in 1681 the Frozen state. 1683 * If there is such a pair: 1685 + Unfreeze the pair. 1687 + Perform a check for that pair, causing its state to 1688 transition to In-Progress. 1690 * If there is no such pair: 1692 + Terminate the timer for that check list. 1694 To compute the message integrity for the check, the agent uses the 1695 remote username fragment and password learned from the SDP from its 1696 peer. The local username fragment is known directly by the agent for 1697 its own candidate. 1699 6. Receipt of the Initial Answer 1701 This section describes the procedures that an agent follows when it 1702 receives the answer from the peer. It verifies that its peer 1703 supports ICE, determines its role, and for full implementations, 1704 forms the check list and begins performing ordinary checks. 1706 When ICE is used with SIP, forking may result in a single offer 1707 generating a multiplicity of answers. In that each, ICE proceeds 1708 completely in parallel and independently for each answer, treating 1709 the combination of its offer and each answer as an independent offer/ 1710 answer exchange, with its own set of pairs, check lists, states, and 1711 so on. The only case in which processing of one pair impacts another 1712 is freeing of candidates, discussed below in Section 8.3. 1714 6.1. Verifying ICE Support 1716 The logic at the offerer is identical to that of the answerer as 1717 described in Section 5.1, with the exception that an offerer would 1718 not ever generate a=ice-mismatch attributes in an SDP. 1720 In some cases, the answer may omit a=candidate attributes for the 1721 media streams, and instead include an a=ice-mismatch attribute for 1722 one or more of the media streams in the SDP. This signals to the 1723 offerer that the answerer supports ICE, but that ICE processing was 1724 not used for the session because a signaling intermediary modified 1725 the default destination for media components without modifying the 1726 corresponding candidate attributes. See Section 18 for a discussion 1727 of cases where this can happen. This specification provides no 1728 guidance on how an agent should proceed in such a failure case. 1730 6.2. Determining Role 1732 The offerer follows the same procedures described for the answerer in 1733 Section 5.2. 1735 6.3. Forming the Check List 1737 Formation of check lists is performed only by full implementations. 1738 The offerer follows the same procedures described for the answerer in 1739 Section 5.7. 1741 6.4. Performing Ordinary Checks 1743 Ordinary checks are performed only by full implementations. The 1744 offerer follows the same procedures described for the answerer in 1745 Section 5.8. 1747 7. Performing Connectivity Checks 1749 This section describes how connectivity checks are performed. All 1750 ICE implementations are required to be compliant to 1751 [I-D.ietf-behave-rfc3489bis], as opposed to the older [RFC3489]. 1752 However, whereas a full implementation will both generate checks 1753 (acting as a STUN client) and receive them (acting as a STUN server), 1754 a lite implementation will only ever receive checks, and thus will 1755 only act as a STUN server. 1757 7.1. STUN Client Procedures 1759 These procedures define how an agent sends a connectivity check, 1760 whether it is an ordinary or a triggered check. These procedures are 1761 only applicable to full implementations. 1763 7.1.1. Sending the Request 1765 The check is generated by sending a Binding Request from a local 1766 candidate, to a remote candidate. [I-D.ietf-behave-rfc3489bis] 1767 describes how Binding Requests are constructed and generated. A 1768 connectivity check MUST utilize the STUN short term credential 1769 mechanism. Support for backwards compatibility with RFC 3489 MUST 1770 NOT be used or assumed with connectivity checks. The FINGERPRINT 1771 mechanism MUST be used for connectivity checks. 1773 ICE extends STUN by defining several new attributes, including 1774 PRIORITY, USE-CANDIDATE, ICE-CONTROLLED, and ICE-CONTROLLING. These 1775 new attributes are formally defined in Section 19.1, and their usage 1776 is described in the subsections below. These STUN extensions are 1777 applicable only to connectivity checks used for ICE. 1779 7.1.1.1. PRIORITY and USE-CANDIDATE 1781 An agent MUST include the PRIORITY attribute in its Binding Request. 1782 The attribute MUST be set equal to the priority that would be 1783 assigned, based on the algorithm in Section 4.1.2, to a peer 1784 reflexive candidate, should one be learned as a consequence of this 1785 check (see Section 7.1.2.2.1 for how peer reflexive candidates are 1786 learned). This priority value will be computed identically to how 1787 the priority for the local candidate of the pair was computed, except 1788 that the type preference is set to the value for peer derived 1789 candidate types. 1791 The controlling agent MAY include the USE-CANDIDATE attribute in the 1792 Binding Request. The controlled agent MUST NOT include it in its 1793 Binding Request. This attribute signals that the controlling agent 1794 wishes to cease checks for this component, and use the candidate pair 1795 resulting from the check for this component. Section 8.1.1 provides 1796 guidance on determining when to include it. 1798 7.1.1.2. ICE-CONTROLLED and ICE-CONTROLLING 1800 The agent MUST include the ICE-CONTROLLED attribute in the request if 1801 it is in the controlled role, and MUST include the ICE-CONTROLLING 1802 attribute in the request if it is in the controlling role. The 1803 content of either attribute MUST be the tie breaker that was 1804 determined in Section 5.2. These attributes are defined fully in 1805 Section 19.1. 1807 7.1.1.3. Forming Credentials 1809 A Binding Request serving as a connectivity check MUST utilize the 1810 STUN short term credential mechanism. The username for the 1811 credential is formed by concatenating the username fragment provided 1812 by the peer with the username fragment of the agent sending the 1813 request, separated by a colon (":"). The password is equal to the 1814 password provided by the peer. For example, consider the case where 1815 agent L is the offerer, and agent R is the answerer. Agent L 1816 included a username fragment of LFRAG for its candidates, and a 1817 password of LPASS. Agent R provided a username fragment of RFRAG and 1818 a password of RPASS. A connectivity check from L to R (and its 1819 response of course) utilize the username RFRAG:LFRAG and a password 1820 of RPASS. A connectivity check from R to L (and its response) 1821 utilize the username LFRAG:RFRAG and a password of LPASS. 1823 7.1.1.4. DiffServ Treatment 1825 If the agent is using Diffserv Codepoint markings [RFC2475] in its 1826 media packets, it SHOULD apply those same markings to its 1827 connectivity checks. 1829 7.1.2. Processing the Response 1831 When a Binding Response is received, it is correlated to its Binding 1832 Request using the transaction ID, as defined in 1833 [I-D.ietf-behave-rfc3489bis], which then ties it to the candidate 1834 pair for which the Binding Request was sent. This section defines 1835 additional procedures for processing Binding Responses, specific to 1836 this usage of STUN. 1838 7.1.2.1. Failure Cases 1840 If the STUN transaction generates a 487 (Role Conflict) error 1841 response, the agent checks whether it had included the ICE-CONTROLLED 1842 or ICE-CONTROLLING attribute in the Binding Request. If the request 1843 had contained the ICE-CONTROLLED attribute, the agent MUST switch to 1844 the controlling role if it has not already done so. If the request 1845 had contained the ICE-CONTROLLING attribute, the agent MUST switch to 1846 the controlled role if it has not already done so. Once it has 1847 switched, the agent MUST enqueue the candidate pair whose check 1848 generated the 487 into the triggered check queue. The state of that 1849 pair is set to Waiting. When the triggered check is sent, it will 1850 contain an ICE-CONTROLLING or ICE-CONTROLLED attribute reflecting its 1851 new role. Note, however, that the tie-breaker value MUST NOT be 1852 reselected. 1854 Agents MAY support receipt of ICMP errors for connectivity checks. 1855 If the STUN transaction generates an ICMP error, the agent sets the 1856 state of the pair to Failed. If the STUN transaction generates a 1857 STUN error response that is unrecoverable (as defined in 1858 [I-D.ietf-behave-rfc3489bis]), or times out, the agent sets the state 1859 of the pair to Failed. 1861 The agent MUST check that the source IP address and port of the 1862 response equals the destination IP address and port that the Binding 1863 Request was sent to, and that the destination IP address and port of 1864 the response match the source IP address and port that the Binding 1865 Request was sent from. In other words, the source and destination 1866 transport addresses in the request and responses are the symmetric. 1867 If they are not symmetric, the agent sets the state of the pair to 1868 Failed. 1870 7.1.2.2. Success Cases 1872 A check is considered to be a success if all of the following are 1873 true: 1875 o the STUN transaction generated a success response 1877 o the source IP address and port of the response equals the 1878 destination IP address and port that the Binding Request was sent 1879 to 1881 o the destination IP address and port of the response match the 1882 source IP address and port that the Binding Request was sent from 1884 7.1.2.2.1. Discovering Peer Reflexive Candidates 1886 The agent checks the mapped address from the STUN response. If the 1887 transport address does not match any of the local candidates that the 1888 agent knows about, the mapped address represents a new candidate - a 1889 peer reflexive candidate. Like other candidates, it has a type, 1890 base, priority and foundation. They are computed as follows: 1892 o Its type is equal to peer reflexive. 1894 o Its base is set equal to the local candidate of the candidate pair 1895 from which the STUN check was sent. 1897 o Its priority is set equal to the value of the PRIORITY attribute 1898 in the Binding Request. 1900 o Its foundation is selected as described in Section 4.1.1. 1902 This peer reflexive candidate is then added to the list of local 1903 candidates for the media stream. Its username fragment and password 1904 are the same as all other local candidates for that media stream. 1905 However, the peer reflexive candidate is not paired with other remote 1906 candidates. This is not necessary; a valid pair will be generated 1907 from it momentarily based on the procedures in Section 7.1.2.2.2. If 1908 an agent wishes to pair the peer reflexive candidate with other 1909 remote candidates besides the one in the valid pair that will be 1910 generated, the agent MAY generate an updated offer which includes the 1911 peer reflexive candidate. This will cause it to be paired with all 1912 other remote candidates. 1914 7.1.2.2.2. Constructing a Valid Pair 1916 The agent constructs a candidate pair whose local candidate equals 1917 the mapped address of the response, and whose remote candidate equals 1918 the destination address to which the request was sent. This is 1919 called a valid pair, since it has been validated by a STUN 1920 connectivity check. The valid pair may equal the pair that generated 1921 the check, may equal a different pair in the check list, or may be a 1922 pair not currently on any check list. If the pair equals the pair 1923 that generated the check or is on a check list currently, it is also 1924 added to the VALID LIST, which is maintained by the agent for each 1925 media stream. This list is empty at the start of ICE processing, and 1926 fills as checks are performed, resulting in valid candidate pairs. 1928 It will be very common that the pair will not be on any check list. 1929 Recall that the check list has pairs whose local candidates are never 1930 server reflexive; those pairs had their local candidates converted to 1931 the base of the server reflexive candidates, and then pruned if they 1932 were redundant. When the response to the STUN check arrives, the 1933 mapped address will be reflexive if there is a NAT between the two. 1934 In that case, the valid pair will have a local candidate that doesn't 1935 match any of the pairs in the check list. 1937 If the pair is not on any check list, the agent computes the priority 1938 for the pair based on the priority of each candidate, using the 1939 algorithm in Section 5.7. The priority of the local candidate 1940 depends on its type. If it is not peer reflexive, it is equal to the 1941 priority signaled for that candidate in the SDP. If it is peer 1942 reflexive, it is equal to the PRIORITY attribute the agent placed in 1943 the Binding Request which just completed. The priority of the remote 1944 candidate is taken from the SDP of the peer. If the candidate does 1945 not appear there, then the check must have been a triggered check to 1946 a new remote candidate. In that case, the priority is taken as the 1947 value of the PRIORITY attribute in the Binding Request which 1948 triggered the check that just completed. The pair is then added to 1949 the VALID LIST. 1951 7.1.2.2.3. Updating Pair States 1953 The agent sets the state of the pair that generated the check to 1954 Succeeded. The success of this check might also cause the state of 1955 other checks to change as well. The agent MUST perform the following 1956 two steps: 1958 1. The agent changes the states for all other Frozen pairs for the 1959 same media stream and same foundation to Waiting. Typically 1960 these other pairs will have different component IDs but not 1961 always. 1963 2. If there is a pair in the valid list for every component of this 1964 media stream (where this is the actual number of components being 1965 used, in cases where the number of components signaled in the SDP 1966 differs from offerer to answerer), the success of this check may 1967 unfreeze checks for other media streams. Note that this step is 1968 followed not just the first time the valid list under 1969 consideration has a pair for every component, but every 1970 subsequent time a check succeeds and adds yet another pair to 1971 that valid list. The agent examines the check list for each 1972 other media stream in turn: 1974 * If the check list is active, the agent changes the state of 1975 all Frozen pairs in that check list whose foundation matches a 1976 pair in the valid list under consideration, to Waiting. 1978 * If the check list is frozen, and there is at least one pair in 1979 the check list whose foundation matches a pair in the valid 1980 list under consideration, the state of all pairs in the check 1981 list whose foundation matches a pair in the valid list under 1982 consideration are set to Waiting. This will cause the check 1983 list to become active, and ordinary checks will begin for it, 1984 as described in Section 5.8. 1986 * If the check list is frozen, and there are no pairs in the 1987 check list whose foundation matches a pair in the valid list 1988 under consideration, the agent 1990 + Groups together all of the pairs with the same foundation, 1992 + For each group, sets the state of the pair with the lowest 1993 component ID to Waiting. If there is more than one such 1994 pair, the one with the highest priority is used. 1996 7.1.2.2.4. Updating the Nominated Flag 1998 If the agent was a controlling agent, and it had included a USE- 1999 CANDIDATE attribute in the Binding Request, the valid pair generated 2000 from that check has its nominated flag set to true. This flag 2001 indicates that this valid pair should be used for media if it is the 2002 highest priority one amongst those whose nominated flag is set. This 2003 may conclude ICE processing for this media stream or all media 2004 streams; see Section 8. 2006 If the agent is the controlled agent, the response may result in the 2007 valid pair having its nominated flag set. See Section 7.2.1.5 for 2008 the procedure. 2010 7.1.2.3. Check List and Timer State Updates 2012 Regardless of whether the check was successful or failed, the 2013 completion of the transaction may require updating of check list and 2014 timer states. 2016 If all of the pairs in the check list are now either in the Failed or 2017 Succeeded state: 2019 o If there is not a pair in the valid list for each component of the 2020 media stream, the state of the check list is set to Failed. 2022 o For each frozen check list, the agent: 2024 * Groups together all of the pairs with the same foundation, 2026 * For each group, sets the state of the pair with the lowest 2027 component ID to Waiting. If there is more than one such pair, 2028 the one with the highest priority is used. 2030 If none of the pairs in the check list are in the Waiting or Frozen 2031 state, the check list is no longer considered active, and will not 2032 count towards the value of N in the computation of timers for 2033 ordinary checks as described in Section 5.8. 2035 7.2. STUN Server Procedures 2037 An agent MUST be prepared to receive a Binding Request on the base of 2038 each candidate it included in its most recent offer or answer. This 2039 requirement holds even if the peer is a lite implementation. 2041 The agent MUST use a short term credential to authenticate the 2042 request and perform a message integrity check. The agent MUST 2043 consider the username to be valid if it consists of two values 2044 separated by a colon, where the first value is equal to the username 2045 fragment generated by the agent in an offer or answer for a session 2046 in-progress. It is possible (and in fact very likely) that an 2047 offerer will receive a Binding Request prior to receiving the answer 2048 from its peer. If this happens, the agent MUST immediately generate 2049 a response (including computation of the mapped address as described 2050 in Section 7.2.1.2. The agent has sufficient information at this 2051 point to generate the response; the password from the peer is not 2052 required. Once the answer is received, it MUST proceed with the 2053 remaining steps required, namely Section 7.2.1.3, Section 7.2.1.4, 2054 and Section 7.2.1.5 for full implementations. In cases where 2055 multiple STUN requests are received before the answer, this may cause 2056 several pairs to be queued up in the triggered check queue. 2058 An agent MUST NOT utilize the ALTERNATE-SERVER mechanism, and MUST 2059 NOT support the backwards compatibility mechanisms to RFC 3489. It 2060 MUST utilize the FINGERPRINT mechanism. 2062 If the agent is using Diffserv Codepoint markings [RFC2475] in its 2063 media packets, it SHOULD apply those same markings to its responses 2064 to Binding Requests. The same would apply to any layer 2 markings 2065 the endpoint might be applying to media packets. 2067 7.2.1. Additional Procedures for Full Implementations 2069 This subsection defines the additional server procedures applicable 2070 to full implementations. 2072 7.2.1.1. Detecting and Repairing Role Conflicts 2074 Normally, the rules for selection of a role in Section 5.2 will 2075 result in each agent selecting a different role - one controlling, 2076 and one controlled. However, in unusual call flows, typically 2077 utilizing third party call control, it is possible for both agents to 2078 select the same role. This section describes procedures for checking 2079 for this case and repairing it. 2081 An agent MUST examine the Binding Request for either the ICE- 2082 CONTROLLING or ICE-CONTROLLED attribute. It MUST follow these 2083 procedures: 2085 o If neither ICE-CONTROLLING or ICE-CONTROLLED are present in the 2086 request, the peer agent may have implemented a previous version of 2087 this specification. There may be a conflict, but it cannot be 2088 detected. 2090 o If the agent is in the controlling role, and the ICE-CONTROLLING 2091 attribute is present in the request: 2093 * If the agent's tie-breaker is larger than or equal to the 2094 contents of the ICE-CONTROLLING attribute, the agent generates 2095 a Binding Error Response and includes an ERROR-CODE attribute 2096 with a value of 487 (Role Conflict) but retains its role. 2098 * If the agent's tie-breaker is less than the contents of the 2099 ICE-CONTROLLING attribute, the agent switches to the controlled 2100 role. 2102 o If the agent is in the controlled role, and the ICE-CONTROLLED 2103 attribute is present in the request: 2105 * If the agent's tie-breaker is larger than or equal to the 2106 contents of the ICE-CONTROLLED attribute, the agent switches to 2107 the controlling role. 2109 * If the agent's tie-breaker is less than the contents of the 2110 ICE-CONTROLLED attribute, the agent generates a Binding Error 2111 Response and includes an ERROR-CODE attribute with a value of 2112 487 (Role Conflict) but retains its role. 2114 o If the agent is in the controlled role and the ICE-CONTROLLING 2115 attribute was present in the request, or the agent was in the 2116 controlling role and the ICE-CONTROLLED attribute was present in 2117 the request, there is no conflict. 2119 A change in roles will require an agent to recompute pair priorities 2120 Section 5.7.2, since those priorities are a function of controlling 2121 and controlled role. The change in role will also impact whether the 2122 agent is responsible for selecting nominated pairs and generated 2123 updated offers upon conclusion of ICE. 2125 The remaining sections in Section 7.2.1 are followed if the server 2126 generated a successful response to the Binding Request, even if the 2127 agent changed roles. 2129 7.2.1.2. Computing Mapped Address 2131 For requests being received on a relayed candidate, the source 2132 transport address used for STUN processing (namely, generation of the 2133 XOR-MAPPED-ADDRESS attribute) is the transport address as seen by the 2134 TURN server. That source transport address will be present in the 2135 REMOTE-ADDRESS attribute of a Data Indication message, if the Binding 2136 Request was delivered through a Data Indication (a TURN server 2137 delivers packets encapsulated in a Data Indication when no active 2138 destination is set). If the Binding Request was not encapsulated in 2139 a Data Indication, that source address is equal to the current active 2140 destination for the TURN session. 2142 7.2.1.3. Learning Peer Reflexive Candidates 2144 If the source transport address of the request does not match any 2145 existing remote candidates, it represents a new peer reflexive remote 2146 candidate. This candidate is constructed as follows: 2148 o The priority of the candidate is set to the PRIORITY attribute 2149 from the request. 2151 o The type of the candidate is set to peer reflexive. 2153 o The foundation of the candidate is set to an arbitrary value, 2154 different from the foundation for all other remote candidates. If 2155 any subsequent offer/answer exchanges contain this peer reflexive 2156 candidate in the SDP, it will signal the actual foundation for the 2157 candidate. 2159 o The component ID of this candidate is set to the component ID for 2160 the local candidate to which the request was sent. 2162 This candidate is added to the list of remote candidates. However, 2163 the agent does not pair this candidate with any local candidates. 2165 7.2.1.4. Triggered Checks 2167 Next, the agent constructs a pair whose local candidate is equal to 2168 the transport address on which the STUN request was received, and a 2169 remote candidate equal to the source transport address where the 2170 request came from (which may be peer-reflexive remote candidate that 2171 was just learned). Since both candidates are known to the agent, it 2172 can obtain their priorities and compute the candidate pair priority. 2173 This pair is then looked up in the check list. There can be one of 2174 several outcomes: 2176 o If the pair is already on the check list: 2178 * If the state of that pair is Waiting or Frozen, a check for 2179 that pair is enqueued into the triggered check queue. 2181 * If the state of that pair is In-Progress, the agent cancels the 2182 in-progress transaction. Cancellation means that the agent 2183 will not retransmit the request, will not treat the lack of 2184 response to be a failure, but will wait the duration of the 2185 transaction timeout for a response. In addition, the agent 2186 MUST create a new connectivity check for that pair 2187 (representing a new STUN Binding Request transaction) by 2188 enqueueing the pair in the triggered check queue. The state of 2189 the pair is then changed to Waiting. 2191 * If the state of the pair is Failed, it is changed to Waiting 2192 and the agent MUST create a new connectivity check for that 2193 pair (representing a new STUN Binding Request transaction), by 2194 enqueueing the pair in the triggered check queue. 2196 * If the state of that pair is Succeeded, nothing further is 2197 done. 2199 o These steps are done to facilitate rapid completion of ICE when 2200 both agents are behind NAT. 2202 o If the pair is not already on the check list: 2204 * The pair is inserted into the check list based on its priority 2206 * Its state is set to Waiting 2208 * The pair is enqueued into the triggered check queue. 2210 When a triggered check is to be sent, it is constructed and processed 2211 as described in Section 7.1.1. These procedures require the agent to 2212 know the transport address, username fragment and password for the 2213 peer. The username fragment for the remote candidate is equal to the 2214 part after the colon of the USERNAME in the Binding Request that was 2215 just received. Using that username fragment, the agent can check the 2216 SDP messages received from its peer (there may be more than one in 2217 cases of forking), and find this username fragment. The 2218 corresponding password is then selected. 2220 7.2.1.5. Updating the Nominated Flag 2222 If the Binding Request received by the agent had the USE-CANDIDATE 2223 attribute set, and the agent is in the controlled role, the agent 2224 looks at the state of the pair computed in Section 7.2.1.4: 2226 o If the state of this pair is Succeeded, it means that the check 2227 generated by this pair produced a successful response. This would 2228 have caused the agent to construct a valid pair when that success 2229 response was received (see Section 7.1.2.2.2). The agent now sets 2230 the nominated flag in the valid pair to true. This may end ICE 2231 processing for this media stream; see Section 8. 2233 o If the state of this pair is In-Progress, if its check produces a 2234 successful result, the resulting valid pair has its nominated flag 2235 set when the response arrives. This may end ICE processing for 2236 this media stream when it arrives; see Section 8. 2238 7.2.2. Additional Procedures for Lite Implementations 2240 If the check that was just received contained a USE-CANDIDATE 2241 attribute, the agent constructs a candidate pair whose local 2242 candidate is equal to the transport address on which the request was 2243 received, and whose remote candidate is equal to the source transport 2244 address of the request that was received. This candidate pair is 2245 assigned an arbitrary priority, and placed into a list of valid 2246 candidates called the valid list. The agent sets the nominated flag 2247 for that pair to true. ICE processing is considered complete for a 2248 media stream if the valid list contains a candidate pair for each 2249 component. 2251 8. Concluding ICE Processing 2253 This section describes how an agent completes ICE. 2255 8.1. Procedures for Full Implementations 2257 Concluding ICE involves nominating pairs by the controlling agent and 2258 updating of state machinery. 2260 8.1.1. Nominating Pairs 2262 The controlling agent nominates pairs to be selected by ICE by using 2263 one of two techniques: regular nomination or aggressive nomination. 2264 If its peer has a lite implementation, an agent MUST use a regular 2265 nomination algorithm. If its peer is using ICE options (present in 2266 an ice-options attribute from the peer) that the agent does not 2267 understand, the agent MUST use a regular nomination algorithm. If 2268 its peer is a full implementation and isn't using any ICE options or 2269 is using ICE options understood by the agent, the agent MAY use 2270 either the aggressive or the regular nomination algorithm. However, 2271 the regular algorithm is RECOMMENDED since it provides greater 2272 stability. 2274 8.1.1.1. Regular Nomination 2276 With regular nomination, the agent lets some number of checks 2277 complete, each of which omit the USE-CANDIDATE attribute. Once one 2278 or more checks complete successfully for a component of a media 2279 stream, valid pairs are generated and added to the valid list. The 2280 agent lets the checks continue until some stopping criteria is met, 2281 and then picks amongst the valid pairs based on an evaluation 2282 criteria. The criteria for stopping the checks and for evaluating 2283 the valid pairs is entirely a matter of local optimization. 2285 When the controlling agent selects the valid pair, it repeats the 2286 check that produced this valid pair (by enqueuing the pair that 2287 generated the check into the triggered check queue), this time with 2288 the USE-CANDIDATE attribute. This check should succeed (since the 2289 previous did), causing the nominated flag of that and only that pair 2290 to be set. Consequently, there will be only a single nominated pair 2291 in the valid list for each component, and when the state of the check 2292 list moves to completed, that exact pair is selected by ICE for 2293 sending and receiving media for that component. 2295 Regular nomination provides the most flexibility, since the agent has 2296 control over the stopping and selection criteria for checks. The 2297 only requirement is that the agent MUST eventually pick one and only 2298 one candidate pair and generate a check for that pair with the USE- 2299 CANDIDATE attribute present. Regular nomination also improves ICE's 2300 resilience to variations in implementation (see Section 14). Regular 2301 nomination is also more stable, allowing both agents to converge on a 2302 single pair for media without any transient selections, which can 2303 happen with the aggressive algorithm. The drawback of regular 2304 nomination is that it is guaranteed to increase latencies because it 2305 requires an additional check to be done. 2307 8.1.1.2. Aggressive Nomination 2309 With aggressive nomination, the controlling agent includes the USE- 2310 CANDIDATE attribute in every check it sends. Once the first check 2311 for a component succeeds, it will be added to the valid list, and 2312 have its nominated flag set. When all components have a nominated 2313 pair in the valid list, it will cause ICE processing to cease for 2314 this check list. However, because the agent included the USE- 2315 CANDIDATE attribute in all of its checks, another check may yet 2316 complete, causing another valid pair to have its nominated flag set. 2317 ICE always selects the highest priority nominated candidate pair from 2318 the valid list as the one used for media. Consequently, the selected 2319 pair may actually change briefly as ICE checks complete, resulting in 2320 a set of transient selections until it stabilizes. 2322 8.1.2. Updating States 2324 For both controlling and controlled agents, the state of ICE 2325 processing depends on the presence of nominated candidate pairs in 2326 the valid list and on the state of the check list. Note that, at any 2327 time, more than one of the following cases can apply: 2329 o If there are no nominated pairs in the valid list for a media 2330 stream and the state of the check list is Running, ICE processing 2331 continues. 2333 o If there is at least one nominated pair in the valid list for a 2334 media stream and the state of the check list is Running: 2336 * The agent MUST remove all Waiting and Frozen pairs in the check 2337 list and triggered check queue for the same component as the 2338 nominated pairs for that media stream 2340 * If an In-Progress pair in the check list is for the same 2341 component as a nominated pair, the agent SHOULD cease 2342 retransmissions for its check if its pair priority is lower 2343 than the lowest priority nominated pair for that component 2345 o Once there is at least one nominated pair in the valid list for 2346 every component of at least one media stream and the state of the 2347 check list is Running: 2349 * The agent MUST change the state of processing for its check 2350 list for that media stream to Completed. 2352 * The agent MUST continue to respond to any checks it may still 2353 receive for that media stream, and MUST perform triggered 2354 checks if required by the processing of Section 7.2. 2356 * The agent MAY begin transmitting media for this media stream as 2357 described in Section 11.1 2359 o Once the state of each check list is Completed: 2361 * The agent sets the state of ICE processing overall to 2362 Completed. 2364 * If an agent is controlling, it examines the highest priority 2365 nominated candidate pair for each component of each media 2366 stream. If any of those candidate pairs differ from the 2367 default candidate pairs in the most recent offer/answer 2368 exchange, the controlling agent MUST generate an updated offer 2369 as described in Section 9. If the controlling agent is using 2370 an aggressive nomination algorithm, this may result in several 2371 updated offers as the pairs selected for media change. An 2372 agent MAY delay sending the offer for a brief interval (one 2373 second is RECOMMENDED) in order to allow the selected pairs to 2374 stabilize. 2376 o If the state of the check list is Failed, ICE has not been able to 2377 complete for this media stream. The correct behavior depends on 2378 the state of the check lists for other media streams: 2380 * If all check lists are Failed, ICE processing overall is 2381 considered to be in the Failed state, and the agent SHOULD 2382 consider the session a failure, SHOULD NOT restart ICE, and the 2383 controlling agent SHOULD terminate the entire session. 2385 * If at least one of the check lists for other media streams is 2386 Completed, the controlling agent SHOULD remove the failed media 2387 stream from the session in its updated offer. 2389 * If none of the check lists for other media streams are 2390 Completed, but at least one is Running, the agent SHOULD let 2391 ICE continue. 2393 8.2. Procedures for Lite Implementations 2395 Concluding ICE for a lite implementation is relatively 2396 straightforward. There are two cases to consider: 2398 The implementation is lite, and its peer is full. 2400 The implementation is lite, and its peer is lite. 2402 The effect of ICE concluding is that the agent can free any allocated 2403 host candidates that were not utilized by ICE, as described in 2404 Section 8.3. 2406 8.2.1. Peer is Full 2408 In this case, the agent will receive connectivity checks from its 2409 peer. When an agent has received a connectivity check that includes 2410 the USE-CANDIDATE attribute for each component of a media stream, the 2411 state of ICE processing for that media stream moves from Running to 2412 Completed. When the state of ICE processing for all media streams is 2413 Completed, the state of ICE processing overall is Completed. 2415 The lite implementation will never itself determine that ICE 2416 processing has failed for a media stream; rather, the full peer will 2417 make that determination and then remove or restart the failed media 2418 stream in a subsequent offer. 2420 8.2.2. Peer is Lite 2422 Once the offer/answer exchange has completed, both agents examine 2423 their candidates and those of its peer. For each media stream, each 2424 agent pairs up its own candidates with the candidates of its peer for 2425 that media stream. Two candidates are paired up when they are for 2426 the same component, utilize the same transport protocol (UDP in this 2427 specification), and are from the same IP address family (IPv4 or 2428 IPv6). 2430 o If there is a single pair per component, that pair is added to the 2431 Valid list. If all of the components for a media stream had one 2432 pair, the state of ICE processing for that media stream is set to 2433 Completed. If all media streams are Completed, the state of ICE 2434 processing is set to Completed overall. This will always be the 2435 case for implementations that are IPv4 only. 2437 o If there is more than one pair per component: 2439 * The agent MUST select a pair based on local policy. Since this 2440 case only arises for IPv6, it is RECOMMENDED that an agent 2441 follow the procedures of RFC 3484 [RFC3484] to select a single 2442 pair. 2444 * The agent adds the selected pair for each component to the 2445 valid list. As described in Section 11.1, this will permit 2446 media to begin flowing. However, it is possible (and in fact 2447 likely) that both agents have chosen different pairs. 2449 * To reconcile this, the controlling agent MUST send an updated 2450 offer as described in Section 9.1.3, which will include the 2451 remote-candidates attribute. 2453 * The agent MUST NOT update the state of ICE processing when the 2454 offer is sent. If this subsequent offer completes, the 2455 controlling agent MUST change the state of ICE processing to 2456 Completed for all media streams, and the state of ICE 2457 processing overall to Completed. The states for the controlled 2458 agent are set based on the logic in Section 9.2.3. 2460 8.3. Freeing Candidates 2462 8.3.1. Full Implementation Procedures 2464 The procedures in Section 8 require that an agent continue to listen 2465 for STUN requests and continue to generate triggered checks for a 2466 media stream, even once processing for that stream completes. The 2467 rules in this section describe when it is safe for an agent to cease 2468 sending or receiving checks on a candidate that was not selected by 2469 ICE, and then free the candidate. 2471 When ICE is used with SIP, and an offer is forked to multiple 2472 recipients, ICE proceeds in parallel and independently with each 2473 answerer, all using the same local candidates. Once ICE processing 2474 has reached the Completed state for all peers for media streams using 2475 those candidates, the agent SHOULD wait an additional three seconds, 2476 and then it MAY cease responding to checks or generating triggered 2477 checks on that candidate. It MAY free the candidate at that time. 2478 Freeing of server reflexive candidates is never explicit; it happens 2479 by lack of a keepalive. The three second delay handles cases when 2480 aggressive nomination is used, and the selected pairs can quickly 2481 change after ICE has completed. 2483 8.3.2. Lite Implementations 2485 A lite implementation MAY free candidates not selected by ICE as soon 2486 as ICE processing has reached the completed state for all peers for 2487 all media streams using those candidates. 2489 9. Subsequent Offer/Answer Exchanges 2491 Either agent MAY generate a subsequent offer at any time allowed by 2492 RFC 3264 [RFC3264]. The rules in Section 8 will cause the 2493 controlling agent to send an updated offer at the conclusion of ICE 2494 processing when ICE has selected different candidate pairs from the 2495 default pairs. This section defines rules for construction of 2496 subsequent offers and answers. 2498 Should a subsequent offer be rejected, ICE processing continues as if 2499 the subsequent offer had never been made. 2501 9.1. Generating the Offer 2503 9.1.1. Procedures for All Implementations 2505 9.1.1.1. ICE Restarts 2507 An agent MAY restart ICE processing for an existing media stream. An 2508 ICE restart, as the name implies, will cause all previous state of 2509 ICE processing to be flushed and checks to start anew. The only 2510 difference between an ICE restart and a brand new media session is 2511 that, during the restart, media can continue to be sent to the 2512 previously validated pair. 2514 An agent MUST restart ICE for a media stream if: 2516 o The offer is being generated for the purposes of changing the 2517 target of the media stream. In other words, if an agent wants to 2518 generated an updated offer which, had ICE not been in use, would 2519 result in a new value for the destination of a media component. 2521 o An agent is changing its implementation level. This typically 2522 only happens in third party call control use cases, where the 2523 entity performing the signaling is not the entity receiving the 2524 media, and it has changed the target of media mid-session to 2525 another entity that has a different ICE implementation. 2527 These rules imply that setting the IP address in the c line to 2528 0.0.0.0 will cause an ICE restart. Consequently, ICE implementations 2529 MUST NOT utilize this mechanism for call hold, and instead MUST use 2530 a=inactive and a=sendonly as described in [RFC3264] 2532 To restart ICE, an agent MUST change both the ice-pwd and the ice- 2533 ufrag for the media stream in an offer. Note that it is permissible 2534 to use a session-level attribute in one offer, but to provide the 2535 same ice-pwd or ice-ufrag as a media-level attribute in a subsequent 2536 offer. This is not a change in password, just a change in its 2537 representation, and does not cause an ICE restart. 2539 An agent sets the rest of the fields in the SDP for this media stream 2540 as it would in an initial offer of this media stream (see 2541 Section 4.3). Consequently, the set of candidates MAY include some, 2542 none, or all of the previous candidates for that stream and MAY 2543 include a totally new set of candidates gathered as described in 2544 Section 4.1.1. 2546 9.1.1.2. Removing a Media Stream 2548 If an agent removes a media stream by setting its port to zero, it 2549 MUST NOT include any candidate attributes for that media stream and 2550 SHOULD NOT include any other ICE-related attributes defined in 2551 Section 15 for that media stream. 2553 9.1.1.3. Adding a Media Stream 2555 If an agent wishes to add a new media stream, it sets the fields in 2556 the SDP for this media stream as if this was an initial offer for 2557 that media stream (see Section 4.3). This will cause ICE processing 2558 to begin for this media stream. 2560 9.1.2. Procedures for Full Implementations 2562 This section describes additional procedures for full 2563 implementations, covering existing media streams. 2565 The username fragments, password, and implementation level MUST 2566 remain the same as used previously. If an agent needs to change one 2567 of these it MUST restart ICE for that media stream. 2569 Additional behavior depends on the state ICE processing for that 2570 media stream. 2572 9.1.2.1. Existing Media Streams with ICE Running 2574 If an agent generates an updated offer including media stream that 2575 was previously established, and for which ICE checks are in the 2576 Running state, the agent follows the procedures defined here. 2578 An agent MUST include candidate attributes for all local candidates 2579 it had signaled previously for that media stream. The properties of 2580 that candidate as signaled in SDP - the priority, foundation, type 2581 and related transport address SHOULD remain the same. The IP 2582 address, port and transport protocol, which fundamentally identify 2583 that candidate, MUST remain the same (if they change, it would be a 2584 new candidate). The component ID MUST remain the same. The agent 2585 MAY include additional candidates it did not offer previously, but 2586 which it has gathered since the last offer/answer exchange, including 2587 peer reflexive candidates. 2589 The agent MAY change the default destination for media. As with 2590 initial offers, there MUST be a set of candidate attributes in the 2591 offer matching this default destination. 2593 9.1.2.2. Existing Media Streams with ICE Completed 2595 If an agent generates an updated offer including media stream that 2596 was previously established, and for which ICE checks are in the 2597 Completed state, the agent follows the procedures defined here. 2599 The default destination for media (i.e., the values of the IP 2600 addresses and ports in the m and c line used for that media stream) 2601 MUST be the local candidate from the highest priority nominated pair 2602 in the valid list for each component. This "fixes" the default 2603 destination for media to equal the destination ICE has selected for 2604 media. 2606 The agent MUST include a candidate attributes for candidates matching 2607 the default destination for each component of the media stream, and 2608 MUST NOT include any other candidates. 2610 In addition, if the agent is controlling, it MUST include the 2611 a=remote-candidates attribute for each media stream whose check list 2612 is in the Completed state. The attribute contains the remote 2613 candidates from the highest priority nominated pair in the valid list 2614 for each component of that media stream. It is needed to avoid a 2615 race condition whereby the controlling agent chooses its pairs, but 2616 the updated offer beats the connectivity checks to the controlled 2617 agent, which doesn't even know these pairs are valid, let alone 2618 selected. See Appendix B.6 for elaboration on this race condition. 2620 9.1.3. Procedures for Lite Implementations 2622 9.1.3.1. Existing Media Streams with ICE Running 2624 This section describes procedures for lite implementations for 2625 existing streams for which ICE is running. 2627 A lite implementation MUST include all of its candidates for each 2628 component of each media stream in an a=candidate attribute in any 2629 subsequent offer. These candidates are formed identically to the 2630 procedures for initial offers, as described in Section 4.2. 2632 A lite implementation MUST NOT add additional host candidates in a 2633 subsequent offer. If an agent needs to offer additional candidates, 2634 it MUST restart ICE. 2636 The username fragments, password, and implementation level MUST 2637 remain the same as used previously. If an agent needs to change one 2638 of these it MUST restart ICE for that media stream. 2640 9.1.3.2. Existing Media Streams with ICE Completed 2642 If ICE has completed for a media stream, the default destination for 2643 that media stream MUST be set to the remote candidate of the 2644 candidate pair for that component in the valid list. For a lite 2645 implementation, there is always just a single candidate pair in the 2646 valid list for each component of a media stream. Additionally, the 2647 agent MUST include a candidate attribute for each default 2648 destination. 2650 Additionally, if the agent is controlling (which only happens when 2651 both agents are lite), the agent MUST include the a=remote-candidates 2652 attribute for each media stream. The attribute contains the remote 2653 candidates from the candidate pairs in the valid list (one pair for 2654 each component of each media stream). 2656 9.2. Receiving the Offer and Generating an Answer 2658 9.2.1. Procedures for All Implementations 2660 When receiving a subsequent offer within an existing session, an 2661 agent MUST re-apply the verification procedures in Section 5.1 2662 without regard to the results of verification from any previous 2663 offer/answer exchanges. Indeed, it is possible that a previous 2664 offer/answer exchange resulted in ICE not being used, but it is used 2665 as a consequence of a subsequent exchange. 2667 9.2.1.1. Detecting ICE Restart 2669 If the offer contained a change in the a=ice-ufrag or a=ice-pwd 2670 attributes compared to the previous SDP from the peer, it indicates 2671 that ICE is restarting for this media stream. If all media streams 2672 are restarting, than ICE is restarting overall. 2674 If ICE is restarting for a media stream: 2676 o The agent MUST change the a=ice-ufrag and a=ice-pwd attributes in 2677 the answer. 2679 o The agent MAY change its implementation level in the answer. 2681 An agent sets the rest of the fields in the SDP for this media stream 2682 as it would in an initial answer to this media stream (see 2683 Section 4.3). Consequently, the set of candidates MAY include some, 2684 none, or all of the previous candidates for that stream and MAY 2685 include a totally new set of candidates gathered as described in 2686 Section 4.1.1. 2688 9.2.1.2. New Media Stream 2690 If the offer contains a new media stream, the agent sets the fields 2691 in the answer as if it had received an initial offer containing that 2692 media stream (see Section 4.3). This will cause ICE processing to 2693 begin for this media stream. 2695 9.2.1.3. Removed Media Stream 2697 If an offer contains a media stream whose port is zero, the agent 2698 MUST NOT include any candidate attributes for that media stream in 2699 its answer and SHOULD NOT include any other ICE-related attributes 2700 defined in Section 15 for that media stream. 2702 9.2.2. Procedures for Full Implementations 2704 Unless the agent has detected an ICE restart from the offer, the 2705 username fragments, password, and implementation level MUST remain 2706 the same as used previously. If an agent needs to change one of 2707 these it MUST restart ICE for that media stream by generating an 2708 offer; ICE cannot be restarted in an answer. 2710 Additional behaviors depend on the state of ICE processing for that 2711 media stream. 2713 9.2.2.1. Existing Media Streams with ICE Running and no remote- 2714 candidates 2716 If ICE is running for a media stream, and the offer for that media 2717 stream lacked the remote-candidates attribute, the rules for 2718 construction of the answer are identical to those for the offerer as 2719 described in Section 9.1.2.1. 2721 9.2.2.2. Existing Media Streams with ICE Completed and no remote- 2722 candidates 2724 If ICE is Completed for a media stream, and the offer for that media 2725 stream lacked the remote-candidates attribute, the rules for 2726 construction of the answer are identical to those for the offerer as 2727 described in Section 9.1.2.2, except that the answerer MUST NOT 2728 include the a=remote-candidates attribute in the answer. 2730 9.2.2.3. Existing Media Streams and remote-candidates 2732 A controlled agent will receive an offer with the a=remote-candidates 2733 attribute for a media stream when its peer has concluded ICE 2734 processing for that media stream. This attribute is present in the 2735 offer to deal with a race condition between the receipt of the offer, 2736 and the receipt of the Binding Response which tells the answerer the 2737 candidate which will be selected by ICE. See Appendix B.6 for an 2738 explanation of this race condition. Consequently, processing of an 2739 offer with this attribute depends on the winner of the race. 2741 The agent forms a candidate pair for each component of the media 2742 stream by: 2744 o Setting the remote candidate equal to the offerers default 2745 destination for that component (e.g., the contents of the m and 2746 c-lines for RTP, and the a=rtcp attribute for RTCP) 2748 o Setting the local candidate equal to the transport address for 2749 that same component in the a=remote-candidates attribute in the 2750 offer. 2752 The agent then sees if each of these candidate pairs are present in 2753 the valid list. If a particular pair is not in the valid list, the 2754 check has "lost" the race. Call such a pair a "losing pair". 2756 The agent finds all the pairs in the check list whose remote 2757 candidates equal the remote candidate in the losing pair: 2759 o If none of the pairs are In-Progress, and at least one is Failed, 2760 it is most likely that a network failure, such as a network 2761 partition or serious packet loss, has occurred. The agent SHOULD 2762 generate an answer for this media stream as if the remote- 2763 candidates attribute had not been present, and then restart ICE 2764 for this stream. 2766 o If at least one of the pairs are In-Progress, the agent SHOULD 2767 wait for those checks to complete, and as each completes, redo the 2768 processing in this section until there are no losing pairs. 2770 Once there are no losing pairs, the agent can generate the answer. 2771 It MUST set the default destination for media to the candidates in 2772 the remote-candidates attribute from the offer (each of which will 2773 now be the local candidate of a candidate pair in the valid list). 2774 It MUST include a candidate attribute in the answer for each 2775 candidate in the remote-candidates attribute in the offer. 2777 9.2.3. Procedures for Lite Implementations 2779 If the received offer contains the remote-candidates attribute for a 2780 media stream, the agent forms a candidate pair for each component of 2781 the media stream by: 2783 o Setting the remote candidate equal to the offerers default 2784 destination for that component (e.g., the contents of the m and 2785 c-lines for RTP, and the a=rtcp attribute for RTCP) 2787 o Setting the local candidate equal to the transport address for 2788 that same component in the a=remote-candidates attribute in the 2789 offer. 2791 It then places those candidates into the Valid list for the media 2792 stream. The state of ICE processing for that media stream is set to 2793 Completed. 2795 Furthermore, if the agent believed it was controlling, but the offer 2796 contained the remote-candidates attribute, both agents believe they 2797 are controlling. In this case, both would have sent updated offers 2798 around the same time. However, the signaling protocol carrying the 2799 offer/answer exchanges will have resolved this glare condition, so 2800 that one agent is always the 'winner' by having its offer received 2801 before its peer has sent an offer. The winner takes the role of 2802 controlled, so that the loser (the answerer under consideration in 2803 this section MUST change its role to controlled. Consequently, if 2804 the agent was going to send an updated offer since, based on the 2805 rules in Section 8.2.2, it was controlling, it no longer needs to. 2807 Besides the potential role change, change in the Valid list, and 2808 state changes, the construction of the answer is performed 2809 identically to the construction of an offer as described in 2810 Section 9.1.3. 2812 9.3. Updating the Check and Valid Lists 2814 9.3.1. Procedures for Full Implementations 2816 9.3.1.1. ICE Restarts 2818 The agent MUST remember the highest priority nominated pairs in the 2819 Valid list for each component of the media stream, called the 2820 previous selected pairs, prior to the restart. The agent will 2821 continue to send media using these pairs, as described in 2822 Section 11.1. Once these destinations are noted, the agent MUST 2823 flush the valid and check lists, and then recompute the check list 2824 and its states as described in Section 5.7. 2826 9.3.1.2. New Media Stream 2828 If the offer/answer exchange added a new media stream, the agent MUST 2829 create a new check list for it (and an empty Valid list to start of 2830 course), as described in Section 5.7. 2832 9.3.1.3. Removed Media Stream 2834 If the offer/answer exchange removed a media stream, or an answer 2835 rejected an offered media stream, an agent MUST flush the Valid list 2836 for that media stream. It MUST terminate any STUN transactions in 2837 progress for that media stream. An agent MUST remove the check list 2838 for that media stream and cancel any pending ordinary checks for it. 2840 9.3.1.4. ICE Continuing for Existing Media Stream 2842 The valid list is not affected by an updated offer/answer exchange 2843 unless ICE is restarting. 2845 If an agent is in the Running state for that media stream, the check 2846 list is updated (the check list is irrelevant if the state is 2847 completed). To do that, the agent recomputes the check list using 2848 the procedures described in Section 5.7. If a pair on the new check 2849 list was also on the previous check list, and its state was Waiting, 2850 In-Progress, Succeeded or Failed, its state is copied over. 2851 Otherwise, its state is set to Frozen. 2853 If none of the check lists are active (meaning that the pairs in each 2854 check list are Frozen), the full-mode agent sets the first pair in 2855 the check list for the first media stream to Waiting, and then sets 2856 the state of all other pairs in that check list for the same 2857 component ID and with the same foundation to Waiting as well. 2859 Next, the agent goes through each check list, starting with the 2860 highest priority pair. If a pair has a state of Succeeded, and it 2861 has a component ID of 1, then all Frozen pairs in the same check list 2862 with the same foundation whose component IDs are not 1, have their 2863 state set to Waiting. If, for a particular check list, there are 2864 pairs for each component of that media stream in the Succeeded state, 2865 the agent moves the state of all Frozen pairs for the first component 2866 of all other media streams (and thus in different check lists) with 2867 the same foundation to Waiting. 2869 9.3.2. Procedures for Lite Implementations 2871 If ICE is restarting for a media stream, the agent MUST start a new 2872 Valid list for that media stream. It MUST remember the pairs in the 2873 previous Valid list for each component of the media stream, called 2874 the previous selected pairs, and continue to send media there as 2875 described in Section 11.1. The state of ICE processing for each 2876 media stream MUST change to Running, and the state of ICE processing 2877 MUST change to running. 2879 10. Keepalives 2881 All endpoints MUST send keepalives for each media session. These 2882 keepalives serve the purpose of keeping NAT bindings alive for the 2883 media session. These keepalives MUST be sent regardless of whether 2884 the media stream is currently inactive, sendonly, recvonly or 2885 sendrecv, and regardless of the presence or value of the bandwidth 2886 attribute. These keepalives MUST be sent even if ICE is not being 2887 utilized for the session at all. The keepalive SHOULD be sent using 2888 a format which is supported by its peer. ICE endpoints allow for 2889 STUN-based keepalives for UDP streams, and as such, STUN keepalives 2890 MUST be used when an agent is a full ICE implementation and is 2891 communicating with a peer that supports ICE (lite or full). An agent 2892 can determine that its peer supports ICE by the presence of 2893 a=candidate attributes for each media session. If the peer does not 2894 support ICE, the choice of a packet format for keepalives is a matter 2895 of local implementation. A format which allows packets to easily be 2896 sent in the absence of actual media content is RECOMMENDED. Examples 2897 of formats which readily meet this goal are RTP No-Op 2898 [I-D.ietf-avt-rtp-no-op], and in cases where both sides support it, 2899 RTP comfort noise [RFC3389]. If the peer doesn't support any formats 2900 that are particularly well suited for keepalives, an agent SHOULD 2901 send RTP packets with an incorrect version number, or some other form 2902 of error which would cause them to be discarded by the peer. 2904 If there has been no packet sent on the candidate pair ICE is using 2905 for a media component for Tr seconds (where packets include those 2906 defined for the component (RTP or RTCP) and previous keepalives), an 2907 agent MUST generate a keepalive on that pair. Tr SHOULD be 2908 configurable and SHOULD have a default of 15 seconds. Alternatively, 2909 if an agent has a dynamic way to discover the binding lifetimes of 2910 the intervening NATs, it can use that value to determine Tr. 2912 If STUN is being used for keepalives, a STUN Binding Indication is 2913 used [I-D.ietf-behave-rfc3489bis]. The Indication MUST NOT utilize 2914 any authentication mechanism, and SHOULD NOT contain any attributes. 2915 It is used solely to keep the NAT bindings alive. The Binding 2916 Indication is sent using the same local and remote candidates that 2917 are being used for media. Though Binding Indications are used for 2918 keepalives, an agent MUST be prepared to receive a connectivity check 2919 as well. If a connectivity check is received, a response is 2920 generated as discussed in [I-D.ietf-behave-rfc3489bis], but there is 2921 no impact on ICE processing otherwise. 2923 An agent MUST begin the keepalive processing once ICE has selected 2924 candidates for usage with media, or media begins to flow, whichever 2925 happens first. Keepalives end once the session terminates or the 2926 media stream is removed. 2928 11. Media Handling 2930 11.1. Sending Media 2932 Procedures for sending media differ for full and lite 2933 implementations. 2935 11.1.1. Procedures for Full Implementations 2937 Agents always send media using a candidate pair, called the selected 2938 candidate pair. An agent will send media to the remote candidate in 2939 the selected pair (setting the destination address and port of the 2940 packet equal to that remote candidate), and will send it from the 2941 local candidate of the selected pair. When the local candidate is 2942 server or peer reflexive, media is originated from the base. Media 2943 sent from a relayed candidate is sent from the base through that TURN 2944 server, using procedures defined in [I-D.ietf-behave-turn]. 2946 The selected pair for a component of a media stream is: 2948 o empty if the state of the check list for that media stream is 2949 Running, and there is no previous selected pair for that component 2950 due to an ICE restart 2952 o equal to the previous selected pair for a component of a media 2953 stream if the state of the check list for that media stream is 2954 Running, and there was a previous selected pair for that component 2955 due to an ICE restart 2957 o equal to the highest priority nominated pair for that component in 2958 the valid list if the state of the check list is Completed 2960 If the selected pair for at least one component of a media stream is 2961 empty, an agent MUST NOT send media for any component of that media 2962 stream. If the selected pair for each component of a media stream 2963 has a value, an agent MAY send media for all components of that media 2964 stream. 2966 Note that the selected pair for a component of a media stream may not 2967 equal the default pair for that same component from the most recent 2968 offer/answer exchange. When this happens, the selected pair is used 2969 for media, not the default pair. When ICE first completes, if the 2970 selected pairs aren't a match for the default pairs, the controlling 2971 agent sends an updated offer/answer exchange to remedy this 2972 disparity. However, until that updated offer arrives, there will not 2973 be a match. Furthermore, in very unusual cases, the default 2974 candidates in the updated offer/answer will not be a match. 2976 11.1.2. Procedures for Lite Implementations 2978 A lite implementation MUST NOT send media until it has a Valid list 2979 that contains a candidate pair for each component of that media 2980 stream. Once that happens, the agent MAY begin sending media 2981 packets. To do that, it sends media to the remote candidate in the 2982 pair (setting the destination address and port of the packet equal to 2983 that remote candidate), and will send it from the local candidate. 2985 11.1.3. Procedures for All Implementations 2987 ICE has interactions with jitter buffer adaptation mechanisms. An 2988 RTP stream can begin using one candidate, and switch to another one, 2989 though this happens rarely with ICE. The newer candidate may result 2990 in RTP packets taking a different path through the network - one with 2991 different delay characteristics. As discussed below, agents are 2992 encouraged to re-adjust jitter buffers when there are changes in 2993 source or destination address of media packets. Furthermore, many 2994 audio codecs use the marker bit to signal the beginning of a 2995 talkspurt, for the purposes of jitter buffer adaptation. For such 2996 codecs, it is RECOMMENDED that the sender set the marker bit 2997 [RFC3550] when an agent switches transmission of media from one 2998 candidate pair to another. 3000 11.2. Receiving Media 3002 ICE implementations MUST be prepared to receive media on each 3003 component on any candidates provided for that component in the most 3004 recent offer/answer exchange (in the case of RTP, this would include 3005 both RTP and RTCP if candidates were provided for both). 3007 It is RECOMMENDED that, when an agent receives an RTP packet with a 3008 new source or destination IP address for a particular media stream, 3009 that the agent re-adjust its jitter buffers. 3011 RFC 3550 [RFC3550] describes an algorithm in Section 8.2 for 3012 detecting SSRC collisions and loops. These algorithms are based, in 3013 part, on seeing different source transport addresses with the same 3014 SSRC. However, when ICE is used, such changes will sometimes occur 3015 as the media streams switch between candidates. An agent will be 3016 able to determine that a media stream is from the same peer as a 3017 consequence of the STUN exchange that proceeds media transmission. 3018 Thus, if there is a change in source transport address, but the media 3019 packets come from the same peer agent, this SHOULD NOT be treated as 3020 an SSRC collision. 3022 12. Usage with SIP 3024 12.1. Latency Guidelines 3026 ICE requires a series of STUN-based connectivity checks to take place 3027 between endpoints. These checks start from the answerer on 3028 generation of its answer, and start from the offerer when it receives 3029 the answer. These checks can take time to complete, and as such, the 3030 selection of messages to use with offers and answers can effect 3031 perceived user latency. Two latency figures are of particular 3032 interest. These are the post-pickup delay and the post-dial delay. 3033 The post-pickup delay refers to the time between when a user "answers 3034 the phone" and when any speech they utter can be delivered to the 3035 caller. The post-dial delay refers to the time between when a user 3036 enters the destination address for the user, and ringback begins as a 3037 consequence of having successfully started ringing the phone of the 3038 called party. 3040 Two cases can be considered - one where the offer is present in the 3041 initial INVITE, and one where it is in a response. 3043 12.1.1. Offer in INVITE 3045 To reduce post-dial delays, it is RECOMMENDED that the caller begin 3046 gathering candidates prior to actually sending its initial INVITE. 3047 This can be started upon user interface cues that a call is pending, 3048 such as activity on a keypad or the phone going offhook. 3050 If an offer is received in an INVITE request, the answerer SHOULD 3051 begin to gather its candidates on receipt of the offer and then 3052 generate an answer in a provisional response once it has completed 3053 that process. ICE requires that a provisional response with an SDP 3054 be transmitted reliably. This can be done through the existing PRACK 3055 mechanism [RFC3262], or through an optimization that is specific to 3056 ICE. With this optimization, provisional responses containing an SDP 3057 answer that begins ICE processing for one or more media streams can 3058 be sent reliably without RFC 3262. To do this, the agent retransmits 3059 the provisional response with the exponential backoff timers 3060 described in RFC 3262. Retransmits MUST cease on receipt of a STUN 3061 Binding Request for one of the media streams signaled in that SDP 3062 (because receipt of a binding request indicates the offerer has 3063 received the answer) or on transmission of the answer in a 2xx 3064 response. If the peer agent is lite, there will never be a STUN 3065 Binding Request. In such a case, the agent MUST cease retransmitting 3066 the 18x after sending it four times (ICE will actually work even if 3067 the peer never receives the 18x; however, experience has shown that 3068 sending it is important for middleboxes and firewall traversal). If 3069 no Binding Request is received prior to the last retransmit, the 3070 agent does not consider the session terminated. Despite the fact 3071 that the provisional response will be delivered reliably, the rules 3072 for when an agent can send an updated offer or answer do not change 3073 from those specified in RFC 3262. Specifically, if the INVITE 3074 contained an offer, the same answer appears in all of the 1xx and in 3075 the 2xx response to the INVITE. Only after that 2xx has been sent 3076 can an updated offer/answer exchange occur. This optimization SHOULD 3077 NOT be used if both agents support PRACK. Note that the optimization 3078 is very specific to provisional response carrying answers that start 3079 ICE processing; it is not a general technique for 1xx reliability. 3081 Alternatively, an agent MAY delay sending an answer until the 200 OK, 3082 however this results in a poor user experience and is NOT 3083 RECOMMENDED. 3085 Once the answer has been sent, the agent SHOULD begin its 3086 connectivity checks. Once candidate pairs for each component of a 3087 media stream enter the valid list, the answerer can begin sending 3088 media on that media stream. 3090 However, prior to this point, any media that needs to be sent towards 3091 the caller (such as SIP early media [RFC3960] MUST NOT be 3092 transmitted. For this reason, implementations SHOULD delay alerting 3093 the called party until candidates for each component of each media 3094 stream have entered the valid list. In the case of a PSTN gateway, 3095 this would mean that the setup message into the PSTN is delayed until 3096 this point. Doing this increases the post-dial delay, but has the 3097 effect of eliminating 'ghost rings'. Ghost rings are cases where the 3098 called party hears the phone ring, picks up, but hears nothing and 3099 cannot be heard. This technique works without requiring support for, 3100 or usage of, preconditions [RFC3312], since its a localized decision. 3101 It also has the benefit of guaranteeing that not a single packet of 3102 media will get clipped, so that post-pickup delay is zero. If an 3103 agent chooses to delay local alerting in this way, it SHOULD generate 3104 a 180 response once alerting begins. 3106 12.1.2. Offer in Response 3108 In addition to uses where the offer is in an INVITE, and the answer 3109 is in the provisional and/or 200 OK response, ICE works with cases 3110 where the offer appears in the response. In such cases, which are 3111 common in third party call control [RFC3725], ICE agents SHOULD 3112 generate their offers in a reliable provisional response (which MUST 3113 utilize RFC 3262), and not alert the user on receipt of the INVITE. 3114 The answer will arrive in a PRACK. This allows for ICE processing to 3115 take place prior to alerting, so that there is no post-pickup delay, 3116 at the expense of increased call setup delays. Once ICE completes, 3117 the callee can alert the user and then generate a 200 OK when they 3118 answer. The 200 OK would contain no SDP, since the offer/answer 3119 exchange has completed. 3121 Alternatively, agents MAY place the offer in a 2xx instead (in which 3122 case the answer comes in the ACK). When this happens, the callee 3123 will alert the user on receipt of the INVITE, and the ICE exchanges 3124 will take place only after the user answers. This has the effect of 3125 reducing call setup delay, but can cause substantial post-pickup 3126 delays and media clipping. 3128 12.2. SIP Option Tags and Media Feature Tags 3130 [I-D.ietf-sip-ice-option-tag] specifies a SIP option tag and media 3131 feature tag for usage with ICE. ICE implementations using SIP SHOULD 3132 support this specification, which uses a feature tag in registrations 3133 to facilitate interoperability through signaling intermediaries 3135 12.3. Interactions with Forking 3137 ICE interacts very well with forking. Indeed, ICE fixes some of the 3138 problems associated with forking. Without ICE, when a call forks and 3139 the caller receives multiple incoming media streams, it cannot 3140 determine which media stream corresponds to which callee. 3142 With ICE, this problem is resolved. The connectivity checks which 3143 occur prior to transmission of media carry username fragments, which 3144 in turn are correlated to a specific callee. Subsequent media 3145 packets which arrive on the same candidate pair as the connectivity 3146 check will be associated with that same callee. Thus, the caller can 3147 perform this correlation as long as it has received an answer. 3149 12.4. Interactions with Preconditions 3151 Quality of Service (QoS) preconditions, which are defined in RFC 3312 3152 [RFC3312] and RFC 4032 [RFC4032], apply only to the transport 3153 addresses listed as the default targets for media in an offer/answer. 3154 If ICE changes the transport address where media is received, this 3155 change is reflected in an updated offer which changes the default 3156 destination for media to match ICE's selection. As such, it appears 3157 like any other re-INVITE would, and is fully treated in RFC 3312 and 3158 4032, which apply without regard to the fact that the destination for 3159 media is changing due to ICE negotiations occurring "in the 3160 background". 3162 Indeed, an agent SHOULD NOT indicate that Qos preconditions have been 3163 met until the checks have completed and selected the candidate pairs 3164 to be used for media. 3166 ICE also has (purposeful) interactions with connectivity 3167 preconditions [I-D.ietf-mmusic-connectivity-precon]. Those 3168 interactions are described there. Note that the procedures described 3169 in Section 12.1 describe their own type of "preconditions", albeit 3170 with less functionality than those provided by the explicit 3171 preconditions in [I-D.ietf-mmusic-connectivity-precon]. 3173 12.5. Interactions with Third Party Call Control 3175 ICE works with Flows I, III and IV as described in [RFC3725]. Flow I 3176 works without the controller supporting or being aware of ICE. Flow 3177 IV will work as long as the controller passes along the ICE 3178 attributes without alteration. Flow II is fundamentally incompatible 3179 with ICE; each agent will believe itself to be the answerer and thus 3180 never generate a re-INVITE. 3182 The flows for continued operation, as described in Section 7 of RFC 3183 3725, require additional behavior of ICE implementations to support. 3184 In particular, if an agent receives a mid-dialog re-INVITE that 3185 contains no offer, it MUST restart ICE for each media stream and go 3186 through the process of gathering new candidates. Furthermore, that 3187 list of candidates SHOULD include the ones currently being used for 3188 media. 3190 13. Relationship with ANAT 3192 RFC 4091 [RFC4091] defines a mechanism for indicating that an agent 3193 can support both IPv4 and IPv6 for a media stream, and it does so by 3194 including two m-lines, one for v4, and one for v6. This is similar 3195 to ICE, which allows for an agent to indicate multiple transport 3196 addresses using the candidate attribute. However, ANAT relies on 3197 static selection to pick between choices, rather than a dynamic 3198 connectivity check used by ICE. 3200 This specification deprecates RFC 4091. Instead, agents wishing to 3201 support dual-stack will utilize ICE. Because a dual-stack agent will 3202 require at least two candidates, one for IPv4 and one for IPv6, dual- 3203 stack agents MUST be full implementations. However, agents that are 3204 implementing dual-stack and are running on closed networks where it 3205 is known that there are no NAT, MAY include only host candidates in 3206 their offers, skipping server reflexive and relayed candidates. 3208 14. Extensibility Considerations 3210 This specification makes very specific choices about how both agents 3211 in a session coordinate to arrive at the set of candidate pairs that 3212 are selected for media. It is anticipated that future specifications 3213 will want to alter these algorithms, whether they are simple changes 3214 like timer tweaks, or larger changes like a revamp of the priority 3215 algorithm. When such a change is made, providing interoperability 3216 between the two agents in a session is critical. 3218 First, ICE provides the a=ice-options SDP attribute. Each extension 3219 or change to ICE is associated with a token. When an agent 3220 supporting such an extension or change generates an offer or an 3221 answer, it MUST include the token for that extension in this 3222 attribute. This allows each side to know what the other side is 3223 doing. This attribute MUST NOT be present if the agent doesn't 3224 support any ICE extensions or changes. 3226 At this time, no IANA registry or registration procedures are defined 3227 for these option tags. At time of writing, it is unclear whether ICE 3228 changes and extensions will be sufficiently common to warrrant a 3229 registry. 3231 One of the complications in achieving interoperability is that ICE 3232 relies on a distributed algorithm running on both agents to converge 3233 on an agreed set of candidate pairs. If the two agents run different 3234 algorithms, it can be difficult to guarantee convergence on the same 3235 candidate pairs. The regular nomination procedure described in 3236 Section 8 eliminates some of the tight coordination by delegating the 3237 selection algorithm completely to the controlling agent. 3238 Consequently, when a controlling agent is communicating with a peer 3239 that supports options it doesn't know about, the agent MUST run a 3240 regular nomination algorithm. When regular nomination is used, ICE 3241 will converge perfectly even when both agents use different pair 3242 prioritization algorithms. One of the keys to such convergence are 3243 triggered checks, which ensure that the nominated pair is validated 3244 by both agents. Consequently, any future ICE enhancements MUST 3245 preserve triggered checks. 3247 ICE is also extensible to other media streams beyond RTP, and for 3248 transport protocols beyond UDP. Extensions to ICE for non-RTP media 3249 streams need to specify how many components they utilize, and assign 3250 component IDs to them, starting at 1 for the most important component 3251 ID. Specifications for new transport protocols must define how, if 3252 at all, various steps in the ICE processing differ from UDP. 3254 15. Grammar 3256 This specification defines seven new SDP attributes - the 3257 "candidate", "remote-candidates", "ice-lite", "ice-mismatch", "ice- 3258 ufrag", "ice-pwd" and "ice-options" attributes. 3260 15.1. "candidate" Attribute 3262 The candidate attribute is a media-level attribute only. It contains 3263 a transport address for a candidate that can be used for connectivity 3264 checks. 3266 The syntax of this attribute is defined using Augmented BNF as 3267 defined in RFC 4234 [RFC4234]: 3269 candidate-attribute = "candidate" ":" foundation SP component-id SP 3270 transport SP 3271 priority SP 3272 connection-address SP ;from RFC 4566 3273 port ;port from RFC 4566 3274 SP cand-type 3275 [SP rel-addr] 3276 [SP rel-port] 3277 *(SP extension-att-name SP 3278 extension-att-value) 3280 foundation = 1*32ice-char 3281 component-id = 1*5DIGIT 3282 transport = "UDP" / transport-extension 3283 transport-extension = token ; from RFC 3261 3284 priority = 1*10DIGIT 3285 cand-type = "typ" SP candidate-types 3286 candidate-types = "host" / "srflx" / "prflx" / "relay" / token 3287 rel-addr = "raddr" SP connection-address 3288 rel-port = "rport" SP port 3289 extension-att-name = byte-string ;from RFC 4566 3290 extension-att-value = byte-string 3291 ice-char = ALPHA / DIGIT / "+" / "/" 3293 This grammar encodes the primary information about a candidate: its 3294 IP address, port and transport protocol, and its properties: the 3295 foundation, component ID, priority, type, and related transport 3296 address: 3298 : is taken from RFC 4566 [RFC4566]. It is the 3299 IP address of the candidate, allowing for IPv4 addresses, IPv6 3300 addresses and FQDNs. An IP address SHOULD be used, but an FQDN 3301 MAY be used in place of an IP address. In that case, when 3302 receiving an offer or answer containing an FQDN in an a=candidate 3303 attribute, the FQDN is looked up in the DNS first using an AAAA 3304 record (assuming the agent supports IPv6), and if no result is 3305 found or the agent only supports IPv4, using an A. If the DNS 3306 query returns more than one IP address, one is chosen, and then 3307 used for the remainder of ICE processing. 3309 : is also taken from RFC 4566 [RFC4566]. It is the port of 3310 the candidate. 3312 : indicates the transport protocol for the candidate. 3313 This specification only defines UDP. However, extensibility is 3314 provided to allow for future transport protocols to be used with 3315 ICE, such as TCP or the Datagram Congestion Control Protocol 3316 (DCCP) [RFC4340]. 3318 : is composed of one to thirty two . It is an 3319 identifier that is equivalent for two candidates that are of the 3320 same type, share the same base, and come from the same STUN 3321 server. The foundation is used to optimize ICE performance in the 3322 Frozen algorithm. 3324 : is a positive integer between 1 and 256 which 3325 identifies the specific component of the media stream for which 3326 this is a candidate. It MUST start at 1 and MUST increment by 1 3327 for each component of a particular candidate. For media streams 3328 based on RTP, candidates for the actual RTP media MUST have a 3329 component ID of 1, and candidates for RTCP MUST have a component 3330 ID of 2. Other types of media streams which require multiple 3331 components MUST develop specifications which define the mapping of 3332 components to component IDs. See Section 14 for additional 3333 discussion on extending ICE to new media streams. 3335 : is a positive integer between 1 and (2**32 - 1). 3337 : encodes the type of candidate. This specification 3338 defines the values "host", "srflx", "prflx" and "relay" for host, 3339 server reflexive, peer reflexive and relayed candidates, 3340 respectively. The set of candidate types is extensible for the 3341 future. 3343 and : convey transport addresses related to the 3344 candidate, useful for diagnostics and other purposes. 3345 and MUST be present for server reflexive, peer 3346 reflexive and relayed candidates. If a candidate is server or 3347 peer reflexive, and is equal to the base for 3348 that server or peer reflexive candidate. If the candidate is 3349 relayed, and is equal to the mapped address 3350 in the Allocate Response that provided the client with that 3351 relayed candidate (see Appendix B.3 for a discussion of its 3352 purpose). If the candidate is a host candidate and 3353 MUST be omitted. 3355 The candidate attribute can itself be extended. The grammar allows 3356 for new name/value pairs to be added at the end of the attribute. An 3357 implementation MUST ignore any name/value pairs it doesn't 3358 understand. 3360 15.2. "remote-candidates" Attribute 3362 The syntax of the "remote-candidates" attribute is defined using 3363 Augmented BNF as defined in RFC 4234 [RFC4234]. The remote- 3364 candidates attribute is a media level attribute only. 3366 remote-candidate-att = "remote-candidates" ":" remote-candidate 3367 0*(SP remote-candidate) 3368 remote-candidate = component-ID SP connection-address SP port 3370 The attribute contains a connection-address and port for each 3371 component. The ordering of components is irrelevant. However, a 3372 value MUST be present for each component of a media stream. This 3373 attribute MUST be included in an offer by a controlling agent for a 3374 media stream that is Completed, and MUST NOT be included in any other 3375 case. 3377 15.3. "ice-lite" and "ice-mismatch" Attributes 3379 The syntax of the "ice-lite" and "ice-mismatch" attributes, both of 3380 which are flags, is: 3382 ice-lite = "ice-lite" 3383 ice-mismatch = "ice-mismatch" 3385 "ice-lite" is a session level attribute only, and indicates that an 3386 agent is a lite implementation. "ice-mismatch" is a media level 3387 attribute only, and when present in an answer, indicates that the 3388 offer arrived with a default destination for a media component that 3389 didn't have a corresponding candidate attribute. 3391 15.4. "ice-ufrag" and "ice-pwd" Attributes 3393 The "ice-ufrag" and "ice-pwd" attributes convey the username fragment 3394 and password used by ICE for message integrity. Their syntax is: 3396 ice-pwd-att = "ice-pwd" ":" password 3397 ice-ufrag-att = "ice-ufrag" ":" ufrag 3398 password = 22*1024ice-char 3399 ufrag = 4*1024ice-char 3400 The "ice-pwd" and "ice-ufrag" attributes can appear at either the 3401 session-level or media-level. When present in both, the value in the 3402 media-level takes precedence. Thus, the value at the session level 3403 is effectively a default that applies to all media streams, unless 3404 overriden by a media-level value. Whether present at the session or 3405 media level, there MUST be an ice-pwd and ice-ufrag attribute for 3406 each media stream. If two media streams have identical ice-ufrag's, 3407 they MUST have identical ice-pwd's. 3409 The ice-ufrag and ice-pwd attributes MUST be chosen randomly at the 3410 beginning of a session. The ice-ufrag attribute MUST contain at 3411 least 24 bits of randomness, and the ice-pwd attribute MUST contain 3412 at least 128 bits of randomness. This means that the ice-ufrag 3413 attribute will be at least 4 characters long, and the ice-pwd at 3414 least 22 characters long, since the grammar for these attributes 3415 allows for 6 bits of randomness per character. The attributes MAY be 3416 longer than 4 and 22 characters respectively, of course, up to 1024 3417 characters. The upper limit allows for buffer sizing in 3418 implementations. Its large upper limit allows for increased amounts 3419 of randomness to be added over time. 3421 15.5. "ice-options" Attribute 3423 The "ice-options" attribute is a session level attribute. It 3424 contains a series of tokens which identify the options supported by 3425 the agent. Its grammar is: 3427 ice-options = "ice-options" ":" ice-option-tag 3428 0*(SP ice-option-tag) 3429 ice-option-tag = 1*ice-char 3431 16. Setting Ta and RTO 3433 During the gathering phase of ICE (Section 4.1.1) and while ICE is 3434 performing connectivity checks (Section 7), an agent sends STUN and 3435 TURN transactions. These transcations are paced at a rate of one 3436 every Ta milliseconds, and utilize a specific RTO. This section 3437 describes how the value of Ta and RTO are computed. Their values 3438 change during the lifetime of ICE processing. One set of values 3439 applies during the gathering phase, and the other, for connectivity 3440 checks. 3442 The value of Ta SHOULD be configurable, and SHOULD have a default of: 3444 For each media stream i: 3445 Ta_i = (stun_packet_size / rtp_packet_size) * rtp_ptime 3447 1 3448 Ta = MAX (20ms, ------------------- ) 3449 k 3450 ---- 3451 \ 1 3452 > ------ 3453 / Ta_i 3454 ---- 3455 i=1 3457 Where k is the number of media streams. During the gathering phase, 3458 Ta is computed based on the number of media streams the agent has 3459 indicated in its offer or answer, and the RTP packet size and RTP 3460 ptime are those of the most preferred codec for each media stream. 3461 Once an offer and answer have been exchanged, the agent recomputes Ta 3462 to pace the connectivity checks. In that case, the value of Ta is 3463 based on the number of media streams that will actually be used in 3464 the session, and the RTP packet size and RTP ptime are those of the 3465 most preferred codec that the agent will send with. 3467 In addition, the retransmission timer for the STUN transactions, RTO, 3468 defined in [I-D.ietf-behave-rfc3489bis], SHOULD be configurable and 3469 during the gathering phase, SHOULD have a default of: 3471 RTO = MAX (100ms, Ta * (number of pairs)) 3473 Where the number of pairs refers to the number of pairs of candidates 3474 with STUN or TURN servers. 3476 For connectivity checks, RTO SHOULD be configurable and SHOULD have a 3477 default of: 3479 RTO = MAX (100ms, Ta*N * (Num-Waiting)) 3481 Where Num-Waiting are the number of checks in the check list in the 3482 Waiting state. Note that the RTO will be different for each 3483 transaction as the number of checks in the Waiting state changes. 3485 These formulas are aimed at causing STUN transactions to be paced at 3486 the same rate as media. This ensures that ICE will work properly 3487 under the same network conditions needed to support the media as 3488 well. See Appendix B.1 for additional discussion and motivations. 3490 Because of this pacing, it will take a certain amount of time to 3491 obtain all of the server reflexive and relayed candidates. 3492 Implementations should be aware of the time required to do this, and 3493 if the application requires a time budget, limit the number of 3494 candidates which are gathered. 3496 17. Example 3498 The example is based on the simplified topology of Figure 19. 3500 +-----+ 3501 | | 3502 |STUN | 3503 | Srvr| 3504 +-----+ 3505 | 3506 +---------------------+ 3507 | | 3508 | Internet | 3509 | | 3510 | | 3511 +---------------------+ 3512 | | 3513 | | 3514 +---------+ | 3515 | NAT | | 3516 +---------+ | 3517 | | 3518 | | 3519 | | 3520 +-----+ +-----+ 3521 | | | | 3522 | L | | R | 3523 | | | | 3524 +-----+ +-----+ 3526 Figure 19: Example Topology 3528 Two agents, L and R, are using ICE. Both are full-mode ICE 3529 implementations. Both agents have a single IPv4 interface. For 3530 agent L, it is 10.0.1.1 in private address space [RFC1918], and for 3531 agent R, 192.0.2.1 on the public Internet. Both are configured with 3532 the same STUN server (shown in this example for simplicity, although 3533 in practice the agents do not need to use the same STUN server), 3534 which is listening for STUN Binding Requests at an IP address of 3535 192.0.2.2 and port 3478. TURN servers are not used in this example. 3537 Agent L is behind a NAT, and agent R is on the public Internet. The 3538 NAT has an endpoint independent mapping property and an address 3539 dependent filtering property. The public side of the NAT has an IP 3540 address of 192.0.2.3. 3542 To facilitate understanding, transport addresses are listed using 3543 variables that have mnemonic names. The format of the name is 3544 entity-type-seqno, where entity refers to the entity whose interface 3545 the transport address is on, and is one of "L", "R", "STUN", or 3546 "NAT". The type is either "PUB" for transport addresses that are 3547 public, and "PRIV" for transport addresses that are private. 3548 Finally, seq-no is a sequence number that is different for each 3549 transport address of the same type on a particular entity. Each 3550 variable has an IP address and port, denoted by varname.IP and 3551 varname.PORT, respectively, where varname is the name of the 3552 variable. 3554 The STUN server has advertised transport address STUN-PUB-1 (which is 3555 192.0.2.2:3478). 3557 In the call flow itself, STUN messages are annotated with several 3558 attributes. The "S=" attribute indicates the source transport 3559 address of the message. The "D=" attribute indicates the destination 3560 transport address of the message. The "MA=" attribute is used in 3561 STUN Binding Response messages and refers to the mapped address. 3562 "USE-CAND" implies the presence of the USE-CANDIDATE attribute. 3564 The call flow examples omit STUN authentication operations and RTCP, 3565 and focus on RTP for a single media stream between two full 3566 implementations. 3568 L NAT STUN R 3569 |RTP STUN alloc. | | 3570 |(1) STUN Req | | | 3571 |S=$L-PRIV-1 | | | 3572 |D=$STUN-PUB-1 | | | 3573 |------------->| | | 3574 | |(2) STUN Req | | 3575 | |S=$NAT-PUB-1 | | 3576 | |D=$STUN-PUB-1 | | 3577 | |------------->| | 3578 | |(3) STUN Res | | 3579 | |S=$STUN-PUB-1 | | 3580 | |D=$NAT-PUB-1 | | 3581 | |MA=$NAT-PUB-1 | | 3582 | |<-------------| | 3583 |(4) STUN Res | | | 3584 |S=$STUN-PUB-1 | | | 3585 |D=$L-PRIV-1 | | | 3586 |MA=$NAT-PUB-1 | | | 3587 |<-------------| | | 3588 |(5) Offer | | | 3589 |------------------------------------------->| 3590 | | | |RTP STUN alloc. 3591 | | |(6) STUN Req | 3592 | | |S=$R-PUB-1 | 3593 | | |D=$STUN-PUB-1 | 3594 | | |<-------------| 3595 | | |(7) STUN Res | 3596 | | |S=$STUN-PUB-1 | 3597 | | |D=$R-PUB-1 | 3598 | | |MA=$R-PUB-1 | 3599 | | |------------->| 3600 |(8) answer | | | 3601 |<-------------------------------------------| 3602 | |(9) Bind Req | | 3603 | |S=$R-PUB-1 | | 3604 | |D=L-PRIV-1 | | 3605 | |<----------------------------| 3606 | |Dropped | | 3607 |(10) Bind Req | | | 3608 |S=$L-PRIV-1 | | | 3609 |D=$R-PUB-1 | | | 3610 |USE-CAND | | | 3611 |------------->| | | 3612 | |(11) Bind Req | | 3613 | |S=$NAT-PUB-1 | | 3614 | |D=$R-PUB-1 | | 3615 | |USE-CAND | | 3616 | |---------------------------->| 3617 | |(12) Bind Res | | 3618 | |S=$R-PUB-1 | | 3619 | |D=$NAT-PUB-1 | | 3620 | |MA=$NAT-PUB-1 | | 3621 | |<----------------------------| 3622 |(13) Bind Res | | | 3623 |S=$R-PUB-1 | | | 3624 |D=$L-PRIV-1 | | | 3625 |MA=$NAT-PUB-1 | | | 3626 |<-------------| | | 3627 |RTP flows | | | 3628 | |(14) Bind Req | | 3629 | |S=$R-PUB-1 | | 3630 | |D=$NAT-PUB-1 | | 3631 | |<----------------------------| 3632 |(15) Bind Req | | | 3633 |S=$R-PUB-1 | | | 3634 |D=$L-PRIV-1 | | | 3635 |<-------------| | | 3636 |(16) Bind Res | | | 3637 |S=$L-PRIV-1 | | | 3638 |D=$R-PUB-1 | | | 3639 |MA=$R-PUB-1 | | | 3640 |------------->| | | 3641 | |(17) Bind Res | | 3642 | |S=$NAT-PUB-1 | | 3643 | |D=$R-PUB-1 | | 3644 | |MA=$R-PUB-1 | | 3645 | |---------------------------->| 3646 | | | |RTP flows 3648 Figure 20: Example Flow 3650 First, agent L obtains a host candidate from its local interface (not 3651 shown), and from that, sends a STUN Binding Request to the STUN 3652 server to get a server reflexive candidate (messages 1-4). Recall 3653 that the NAT has the address and port independent mapping property. 3654 Here, it creates a binding of NAT-PUB-1 for this UDP request, and 3655 this becomes the server reflexive candidate for RTP. 3657 Agent L sets a type preference of 126 for the host candidate and 100 3658 for the server reflexive. The local preference is 65535. Based on 3659 this, the priority of the host candidate is 2130706431 and for the 3660 server reflexive candidate is 1694498815. The host candidate is 3661 assigned a foundation of 1, and the server reflexive, a foundation of 3662 2. It chooses its server reflexive candidate as the default 3663 candidate, and encodes it into the m and c lines. The resulting 3664 offer (message 5) looks like (lines folded for clarity): 3666 v=0 3667 o=jdoe 2890844526 2890842807 IN IP4 $L-PRIV-1.IP 3668 s= 3669 c=IN IP4 $NAT-PUB-1.IP 3670 t=0 0 3671 a=ice-pwd:asd88fgpdd777uzjYhagZg 3672 a=ice-ufrag:8hhY 3673 m=audio $NAT-PUB-1.PORT RTP/AVP 0 3674 b=RS:0 3675 b=RR:0 3676 a=rtpmap:0 PCMU/8000 3677 a=candidate:1 1 UDP 2130706431 $L-PRIV-1.IP $L-PRIV-1.PORT typ host 3678 a=candidate:2 1 UDP 1694498815 $NAT-PUB-1.IP $NAT-PUB-1.PORT typ 3679 srflx raddr $L-PRIV-1.IP rport $L-PRIV-1.PORT 3681 The offer, with the variables replaced with their values, will look 3682 like (lines folded for clarity): 3684 v=0 3685 o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1 3686 s= 3687 c=IN IP4 192.0.2.3 3688 t=0 0 3689 a=ice-pwd:asd88fgpdd777uzjYhagZg 3690 a=ice-ufrag:8hhY 3691 m=audio 45664 RTP/AVP 0 3692 b=RS:0 3693 b=RR:0 3694 a=rtpmap:0 PCMU/8000 3695 a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host 3696 a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 3697 10.0.1.1 rport 8998 3699 This offer is received at agent R. Agent R will obtain a host 3700 candidate, and from it, obtain a server reflexive candidate (messages 3701 6-7). Since R is not behind a NAT, this candidate is identical to 3702 its host candidate, and they share the same base. It therefore 3703 discards this redundant candidate and ends up with a single host 3704 candidate. With identical type and local preferences as L, the 3705 priority for this candidate is 2130706431. It chooses a foundation 3706 of 1 for its single candidate. Its resulting answer looks like: 3708 v=0 3709 o=bob 2808844564 2808844564 IN IP4 $R-PUB-1.IP 3710 s= 3711 c=IN IP4 $R-PUB-1.IP 3712 t=0 0 3713 a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh 3714 a=ice-ufrag:9uB6 3715 m=audio $R-PUB-1.PORT RTP/AVP 0 3716 b=RS:0 3717 b=RR:0 3718 a=rtpmap:0 PCMU/8000 3719 a=candidate:1 1 UDP 2130706431 $R-PUB-1.IP $R-PUB-1.PORT typ host 3721 With the variables filled in: 3723 v=0 3724 o=bob 2808844564 2808844564 IN IP4 192.0.2.1 3725 s= 3726 c=IN IP4 192.0.2.1 3727 t=0 0 3728 a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh 3729 a=ice-ufrag:9uB6 3730 m=audio 3478 RTP/AVP 0 3731 b=RS:0 3732 b=RR:0 3733 a=rtpmap:0 PCMU/8000 3734 a=candidate:1 1 UDP 2130706431 192.0.2.1 3478 typ host 3736 Since neither side indicated that they are lite, the agent which sent 3737 the offer that began ICE processing (agent L) becomes the controlling 3738 agent. 3740 Agents L and R both pair up the candidates. They both initially have 3741 two pairs. However, agent L will prune the pair containing its 3742 server reflexive candidate, resulting in just one. At agent L, this 3743 pair has a local candidate of $L_PRIV_1 and remote candidate of 3744 $R_PUB_1, and has a candidate pair priority of 4.57566E+18 (note that 3745 an implementation would represent this as a 64 bit integer so as not 3746 to lose precision). At agent R, there are two pairs. The highest 3747 priority has a local candidate of $R_PUB_1 and remote candidate of 3748 $L_PRIV_1 and has a priority of 4.57566E+18, and the second has a 3749 local candidate of $R_PUB_1 and remote candidate of $NAT_PUB_1 and 3750 priority 3.63891E+18. 3752 Agent R begins its connectivity check (message 9) for the first pair 3753 (between the two host candidates). Since R is the controlled agent 3754 for this session, the check omits the USE-CANDIDATE attribute. The 3755 host candidate from agent L is private and behind a NAT, and thus 3756 this check won't be successful, because the packet cannot be routed 3757 from R to L. 3759 When agent L gets the answer, it performs its one and only 3760 connectivity check (messages 10-13). It implements the aggressive 3761 nomination algorithm, and thus includes a USE-CANDIDATE attribute in 3762 this check. Since the check succeeds, agent L creates a new pair, 3763 whose local candidate is from the mapped address in the binding 3764 response (NAT-PUB-1 from message 13) and whose remote candidate is 3765 the destination of the request (R-PUB-1 from message 10). This is 3766 added to the valid list. In addition, it is marked as selected since 3767 the Binding Request contained the USE-CANDIDATE attribute. Since 3768 there is a selected candidate in the Valid list for the one component 3769 of this media stream, ICE processing for this stream moves into the 3770 Completed state. Agent L can now send media if it so chooses. 3772 Soon after receipt of the STUN Binding Request from agent L (message 3773 11), agent R will generate its triggered check. This check happens 3774 to match the next one on its check list - from its host candidate to 3775 agent L's server reflexive candidate. This check (messages 14-17) 3776 will succeed. Consequently, agent R constructs a new candidate pair 3777 using the mapped address from the response as the local candidate 3778 (R-PUB-1) and the destination of the request (NAT-PUB-1) as the 3779 remote candidate. This pair is added to the Valid list for that 3780 media stream. Since the check was generated in the reverse direction 3781 of a check that contained the USE-CANDIDATE attribute, the candidate 3782 pair is marked as selected. Consequently, processing for this stream 3783 moves into the Completed state, and agent R can also send media. 3785 18. Security Considerations 3787 There are several types of attacks possible in an ICE system. This 3788 section considers these attacks and their countermeasures. 3790 18.1. Attacks on Connectivity Checks 3792 An attacker might attempt to disrupt the STUN connectivity checks. 3793 Ultimately, all of these attacks fool an agent into thinking 3794 something incorrect about the results of the connectivity checks. 3795 The possible false conclusions an attacker can try and cause are: 3797 False Invalid: An attacker can fool a pair of agents into thinking a 3798 candidate pair is invalid, when it isn't. This can be used to 3799 cause an agent to prefer a different candidate (such as one 3800 injected by the attacker), or to disrupt a call by forcing all 3801 candidates to fail. 3803 False Valid: An attacker can fool a pair of agents into thinking a 3804 candidate pair is valid, when it isn't. This can cause an agent 3805 to proceed with a session, but then not be able to receive any 3806 media. 3808 False Peer-Reflexive Candidate: An attacker can cause an agent to 3809 discover a new peer reflexive candidate, when it shouldn't have. 3810 This can be used to redirect media streams to a DoS target or to 3811 the attacker, for eavesdropping or other purposes. 3813 False Valid on False Candidate: An attacker has already convinced an 3814 agent that there is a candidate with an address that doesn't 3815 actually route to that agent (for example, by injecting a false 3816 peer reflexive candidate or false server reflexive candidate). It 3817 must then launch an attack that forces the agents to believe that 3818 this candidate is valid. 3820 If an attacker can cause a false per-reflexive candidate or false 3821 valid on a false candidate, it can launch any of the attacks 3822 described in draft-ietf-behave-rfc3489bis 3823 [I-D.ietf-behave-rfc3489bis]. 3825 To force the false invalid result, the attacker has to wait for the 3826 connectivity check from one of the agents to be sent. When it is, 3827 the attacker needs to inject a fake response with an unrecoverable 3828 error response, such as a 400. However, since the candidate is, in 3829 fact, valid, the original request may reach the peer agent, and 3830 result in a success response. The attacker needs to force this 3831 packet or its response to be dropped, through a DoS attack, layer 2 3832 network disruption, or other technique. If it doesn't do this, the 3833 success response will also reach the originator, alerting it to a 3834 possible attack. Fortunately, this attack is mitigated completely 3835 through the STUN short term credential mechanism. The attacker needs 3836 to inject a fake response, and in order for this response to be 3837 processed, the attacker needs the password. If the offer/answer 3838 signaling is secured, the attacker will not have the password and its 3839 response will be discarded. 3841 Forcing the fake valid result works in a similar way. The agent 3842 needs to wait for the Binding Request from each agent, and inject a 3843 fake success response. The attacker won't need to worry about 3844 disrupting the actual response since, if the candidate is not valid, 3845 it presumably wouldn't be received anyway. However, like the fake 3846 invalid attack, this attack is mitigated by the STUN short term 3847 credential mechanism in conjunction with a secure offer/answer 3848 exchange. 3850 Forcing the false peer reflexive candidate result can be done either 3851 with fake requests or responses, or with replays. We consider the 3852 fake requests and responses case first. It requires the attacker to 3853 send a Binding Request to one agent with a source IP address and port 3854 for the false candidate. In addition, the attacker must wait for a 3855 Binding Request from the other agent, and generate a fake response 3856 with a XOR-MAPPED-ADDRESS attribute containing the false candidate. 3857 Like the other attacks described here, this attack is mitigated by 3858 the STUN message integrity mechanisms and secure offer/answer 3859 exchanges. 3861 Forcing the false peer reflexive candidate result with packet replays 3862 is different. The attacker waits until one of the agents sends a 3863 check. It intercepts this request, and replays it towards the other 3864 agent with a faked source IP address. It must also prevent the 3865 original request from reaching the remote agent, either by launching 3866 a DoS attack to cause the packet to be dropped, or forcing it to be 3867 dropped using layer 2 mechanisms. The replayed packet is received at 3868 the other agent, and accepted, since the integrity check passes (the 3869 integrity check cannot and does not cover the source IP address and 3870 port). It is then responded to. This response will contain a XOR- 3871 MAPPED-ADDRESS with the false candidate, and will be sent to that 3872 false candidate. The attacker must then receive it and relay it 3873 towards the originator. 3875 The other agent will then initiate a connectivity check towards that 3876 false candidate. This validation needs to succeed. This requires 3877 the attacker to force a false valid on a false candidate. Injecting 3878 of fake requests or responses to achieve this goal is prevented using 3879 the integrity mechanisms of STUN and the offer/answer exchange. 3880 Thus, this attack can only be launched through replays. To do that, 3881 the attacker must intercept the check towards this false candidate, 3882 and replay it towards the other agent. Then, it must intercept the 3883 response and replay that back as well. 3885 This attack is very hard to launch unless the attacker is identified 3886 by the fake candidate. This is because it requires the attacker to 3887 intercept and replay packets sent by two different hosts. If both 3888 agents are on different networks (for example, across the public 3889 Internet), this attack can be hard to coordinate, since it needs to 3890 occur against two different endpoints on different parts of the 3891 network at the same time. 3893 If the attacker themself is identified by the fake candidate the 3894 attack is easier to coordinate. However, if SRTP is used [RFC3711], 3895 the attacker will not be able to play the media packets, they will 3896 only be able to discard them, effectively disabling the media stream 3897 for the call. However, this attack requires the agent to disrupt 3898 packets in order to block the connectivity check from reaching the 3899 target. In that case, if the goal is to disrupt the media stream, 3900 its much easier to just disrupt it with the same mechanism, rather 3901 than attack ICE. 3903 18.2. Attacks on Server Reflexive Address Gathering 3905 ICE endpoints make use of STUN Binding requests for gathering server 3906 reflexive andidates from a STUN server. These requests are not 3907 authenticated in any way. As a consequence, there are numerous 3908 techinques an attacker can employ to provide the client with a false 3909 server reflexive candidate: 3911 o An attacker can compromise the DNS, causing DNS queries to return 3912 a rogue STUN server address. That server can provide the client 3913 with fake server reflexive candidates. This attack is mitigated 3914 by DNS security, though DNS-SEC is not required to address it. 3916 o An attacker that can observe STUN messages (such as an attacker on 3917 a shared network segment, like WiFi), can inject a fake response 3918 that is valid and will be accepted by the client. 3920 o An attacker can compromise a STUN server by means of a virus, and 3921 cause it to send responses with incorrect mapped addresses. 3923 A false mapped address learned by these attacks will be used as a 3924 server reflexive candidate in the ICE exchange. For this candidate 3925 to actually be used for media, the attacker must also attack the 3926 connectivity checks, and in particular, force a false valid on a 3927 false candidate. This attack is very hard to launch if the false 3928 address identifies a fourth party (neither the offerer, answerer, or 3929 attacker), since it requires attacking the checks generated by each 3930 agent in the session, and is prevented by SRTP if it identifies the 3931 attacker themself. 3933 If the attacker elects not to attack the connectivity checks, the 3934 worst it can do is prevent the server reflexive candidate from being 3935 used. However, if the peer agent has at least one candidate that is 3936 reachable by the agent under attack, the STUN connectivity checks 3937 themselves will provide a peer reflexive candidate that can be used 3938 for the exchange of media. Peer reflexive candidates are generally 3939 preferred over server reflexive candidates. As such, an attack 3940 solely on the STUN address gathering will normally have no impact on 3941 a session at all. 3943 18.3. Attacks on Relayed Candidate Gathering 3945 An attacker might attempt to disrupt the gathering of relayed 3946 candidates, forcing the client to believe it has a false relayed 3947 candidate. Exchanges with the TURN server are authenticated using a 3948 long term credential. Consequently, injection of fake responses or 3949 requests will not work. In addition, unlike Binding requests, 3950 Allocate requests are not susceptible to replay attacks with modified 3951 source IP addresses and ports, since the source IP address and port 3952 is not utilized to provide the client with its relayed candidate. 3954 However, TURN servers are susceptible to DNS attacks, or to viruses 3955 aimed at the TURN server, for purposes of turning it into a zombie or 3956 rogue server. These attacks can be mitigated by DNS-SEC and through 3957 good box and software security on TURN servers. 3959 Even if an attacker has caused the client to believe in a false 3960 relayed candidate, the connectivity checks cause such a candidate to 3961 be used only if they succeed. Thus, an attacker must launch a false 3962 valid on a false candidate, per above, which is a very difficult 3963 attack to coordinate. 3965 18.4. Attacks on the Offer/Answer Exchanges 3967 An attacker that can modify or disrupt the offer/answer exchanges 3968 themselves can readily launch a variety of attacks with ICE. They 3969 could direct media to a target of a DoS attack, they could insert 3970 themselves into the media stream, and so on. These are similar to 3971 the general security considerations for offer/answer exchanges, and 3972 the security considerations in RFC 3264 [RFC3264] apply. These 3973 require techniques for message integrity and encryption for offers 3974 and answers, which are satisfied by the SIPS mechanism [RFC3261] when 3975 SIP is used. As such, the usage of SIPS with ICE is RECOMMENDED. 3977 18.5. Insider Attacks 3979 In addition to attacks where the attacker is a third party trying to 3980 insert fake offers, answers or stun messages, there are several 3981 attacks possible with ICE when the attacker is an authenticated and 3982 valid participant in the ICE exchange. 3984 18.5.1. The Voice Hammer Attack 3986 The voice hammer attack is an amplification attack. In this attack, 3987 the attacker initiates sessions to other agents, and maliciously 3988 includes the IP address and port of a DoS target as the destination 3989 for media traffic signaled in the SDP. This causes substantial 3990 amplification; a single offer/answer exchange can create a continuing 3991 flood of media packets, possibly at high rates (consider video 3992 sources). This attack is not specific to ICE, but ICE can help 3993 provide remediation. 3995 Specifically, if ICE is used, the agent receiving the malicious SDP 3996 will first perform connectivity checks to the target of media before 3997 sending media there. If this target is a third party host, the 3998 checks will not succeed, and media is never sent. 4000 Unfortunately, ICE doesn't help if its not used, in which case an 4001 attacker could simply send the offer without the ICE parameters. 4002 However, in environments where the set of clients are known, and 4003 limited to ones that support ICE, the server can reject any offers or 4004 answers that don't indicate ICE support. 4006 18.5.2. STUN Amplification Attack 4008 The STUN amplification attack is similar to the voice hammer. 4009 However, instead of voice packets being directed to the target, STUN 4010 connectivity checks are directed to the target. The attacker sends 4011 an offer with a large number of candidates, say 50. The answerer 4012 receives the offer, and starts its checks, which are directed at the 4013 target, and consequently, never generate a response. The answerer 4014 will start a new connectivity check every Ta ms (say Ta=20ms). 4015 However, the retransmission timers are set to a large number due to 4016 the large number of candidates. As a consequence, packets will be 4017 sent at an interval of one every Ta milliseconds, and then with 4018 increasing intervals after that. Thus, STUN will not send packets at 4019 a rate faster than media would be sent, and the STUN packets persist 4020 only briefly, until ICE fails for the session. Nonetheless, this is 4021 an amplification mechanism. 4023 It is impossible to eliminate the amplification, but the volume can 4024 be reduced through a variety of heuristics. Agents SHOULD limit the 4025 total number of connectivity checks they perform to 100. 4026 Additionally, agents MAY limit the number of candidates they'll 4027 accept in an offer or answer. 4029 18.6. Interactions with Application Layer Gateways and SIP 4031 Application Layer Gateways (ALGs) are functions present in a NAT 4032 device which inspect the contents of packets and modify them, in 4033 order to facilitate NAT traversal for application protocols. Session 4034 Border Controllers (SBC) are close cousins of ALGs, but are less 4035 transparent since they actually exist as application layer SIP 4036 intermediaries. ICE has interactions with SBCs and ALGs. 4038 If an ALG is SIP aware but not ICE aware, ICE will work through it as 4039 long as the ALG correctly modifies the SDP. A correct ALG 4040 implementation behave as follows: 4042 o The ALG does not modify the m and c lines or the rtcp attribute if 4043 they contain external addresses. 4045 o If the m and c lines contain internal addresses, the modification 4046 depends on the state of the ALG: 4048 If the ALG already has a binding established that maps an 4049 external port to an internal IP address and port matching the 4050 values in the m and c lines or rtcp attribute , the ALG uses 4051 that binding instead of creating a new one. 4053 If the ALG does not already have a binding, it creates a new 4054 one and modifies the SDP, rewriting the m and c lines and rtcp 4055 attribute. 4057 Unfortunately, many ALG are known to work poorly in these corner 4058 cases. ICE does not try to work around broken ALGs, as this is 4059 outside the scope of its functionality. ICE can help diagnose these 4060 conditions, which often show up as a mismatch between the set of 4061 candidates and the m and c lines and rtcp attributes. The ice- 4062 mismatch attribute is used for this purpose. 4064 ICE works best through ALGs when the signaling is run over TLS. This 4065 prevents the ALG from manipulating the SDP messages and interfering 4066 with ICE operation. Implementations which are expected to be 4067 deployed behind ALGs SHOULD provide for TLS transport of the SDP. 4069 If an SBC is SIP aware but not ICE aware, the result depends on the 4070 behavior of the SBC. If it is acting as a proper Back-to-Back User 4071 Agent (B2BUA), the SBC will remove any SDP attributes it doesn't 4072 understand, including the ICE attributes. Consequently, the call 4073 will appear to both endpoints as if the other side doesn't support 4074 ICE. This will result in ICE being disabled, and media flowing 4075 through the SBC, if the SBC has requested it. If, however, the SBC 4076 passes the ICE attributes without modification, yet modifies the 4077 default destination for media (contained in the m and c lines and 4078 rtcp attribute), this will be detected as an ICE mismatch, and ICE 4079 processing is aborted for the call. It is outside of the scope of 4080 ICE for it to act as a tool for "working around" SBCs. If one is 4081 present, ICE will not be used and the SBC techniques take precedence. 4083 19. STUN Extensions 4085 19.1. New Attributes 4087 This specification defines four new attributes, PRIORITY, USE- 4088 CANDIDATE, ICE-CONTROLLED and ICE-CONTROLLING. 4090 The PRIORITY attribute indicates the priority that is to be 4091 associated with a peer reflexive candidate, should one be discovered 4092 by this check. It is a 32 bit unsigned integer, and has an attribute 4093 value of 0x0024. 4095 The USE-CANDIDATE attribute indicates that the candidate pair 4096 resulting from this check should be used for transmission of media. 4097 The attribute has no content (the Length field of the attribute is 4098 zero); it serves as a flag. It has an attribute value of 0x0025. 4100 The ICE-CONTROLLED attribute is present in a Binding Request, and 4101 indicates that the client believes it is currently in the controlled 4102 role. The content of the attribute is a 64 bit unsigned integer in 4103 network byte ordering, which contains a random number used for tie- 4104 breaking of role conflicts. 4106 The ICE-CONTROLLING attribute is present in a Binding Request, and 4107 indicates that the client believes it is currently in the controlling 4108 role. The content of the attribute is a 64 bit unsigned integer in 4109 network byte ordering, which contains a random number used for tie- 4110 breaking of role conflicts. 4112 19.2. New Error Response Codes 4114 This specification defines a single error response code: 4116 487 (Role Conflict): The Binding Request contained either the ICE- 4117 CONTROLLING or ICE-CONTROLLED attribute, indicating a role that 4118 conflicted with the server. The server ran a tie-breaker based on 4119 the tie-breaker value in the request, and determined that the 4120 client needs to switch roles. 4122 20. IANA Considerations 4124 This specification registers new SDP attributes, four new STUN 4125 attributes and one new STUN error response. 4127 20.1. SDP Attributes 4129 This specification defines seven new SDP attributes per the 4130 procedures of Section 8.2.4 of [RFC4566]. The required information 4131 for the registrations are included here. 4133 20.1.1. candidate Attribute 4135 Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. 4137 Attribute Name: candidate 4139 Long Form: candidate 4141 Type of Attribute: media level 4143 Charset Considerations: The attribute is not subject to the charset 4144 attribute. 4146 Purpose: This attribute is used with Interactive Connectivity 4147 Establishment (ICE), and provides one of many possible candidate 4148 addresses for communication. These addresses are validated with 4149 an end-to-end connectivity check using Simple Traversal Underneath 4150 NAT (STUN). 4152 Appropriate Values: See Section 15 of RFC XXXX [Note to RFC-ed: 4153 please replace XXXX with the RFC number of this specification]. 4155 20.1.2. remote-candidates Attribute 4157 Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. 4159 Attribute Name: remote-candidates 4161 Long Form: remote-candidates 4163 Type of Attribute: media level 4165 Charset Considerations: The attribute is not subject to the charset 4166 attribute. 4168 Purpose: This attribute is used with Interactive Connectivity 4169 Establishment (ICE), and provides the identity of the remote 4170 candidates that the offerer wishes the answerer to use in its 4171 answer. 4173 Appropriate Values: See Section 15 of RFC XXXX [Note to RFC-ed: 4174 please replace XXXX with the RFC number of this specification]. 4176 20.1.3. ice-lite Attribute 4178 Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. 4180 Attribute Name: ice-lite 4182 Long Form: ice-lite 4184 Type of Attribute: session level 4186 Charset Considerations: The attribute is not subject to the charset 4187 attribute. 4189 Purpose: This attribute is used with Interactive Connectivity 4190 Establishment (ICE), and indicates that an agent has the minimum 4191 functionality required to support ICE inter-operation with a peer 4192 that has a full implementation. 4194 Appropriate Values: See Section 15 of RFC XXXX [Note to RFC-ed: 4195 please replace XXXX with the RFC number of this specification]. 4197 20.1.4. ice-mismatch Attribute 4199 Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. 4201 Attribute Name: ice-mismatch 4203 Long Form: ice-mismatch 4205 Type of Attribute: session level 4207 Charset Considerations: The attribute is not subject to the charset 4208 attribute. 4210 Purpose: This attribute is used with Interactive Connectivity 4211 Establishment (ICE), and indicates that an agent is ICE capable, 4212 but did not proceed with ICE due to a mismatch of candidates with 4213 the default destination for media signaled in the SDP. 4215 Appropriate Values: See Section 15 of RFC XXXX [Note to RFC-ed: 4216 please replace XXXX with the RFC number of this specification]. 4218 20.1.5. ice-pwd Attribute 4220 Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. 4222 Attribute Name: ice-pwd 4224 Long Form: ice-pwd 4226 Type of Attribute: session or media level 4228 Charset Considerations: The attribute is not subject to the charset 4229 attribute. 4231 Purpose: This attribute is used with Interactive Connectivity 4232 Establishment (ICE), and provides the password used to protect 4233 STUN connectivity checks. 4235 Appropriate Values: See Section 15 of RFC XXXX [Note to RFC-ed: 4236 please replace XXXX with the RFC number of this specification]. 4238 20.1.6. ice-ufrag Attribute 4240 Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. 4242 Attribute Name: ice-ufrag 4244 Long Form: ice-ufrag 4246 Type of Attribute: session or media level 4248 Charset Considerations: The attribute is not subject to the charset 4249 attribute. 4251 Purpose: This attribute is used with Interactive Connectivity 4252 Establishment (ICE), and provides the fragments used to construct 4253 the username in STUN connectivity checks. 4255 Appropriate Values: See Section 15 of RFC XXXX [Note to RFC-ed: 4256 please replace XXXX with the RFC number of this specification]. 4258 20.1.7. ice-options Attribute 4260 Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. 4262 Attribute Name: ice-options 4264 Long Form: ice-options 4266 Type of Attribute: session level 4268 Charset Considerations: The attribute is not subject to the charset 4269 attribute. 4271 Purpose: This attribute is used with Interactive Connectivity 4272 Establishment (ICE), and indicates the ICE options or extensions 4273 used by the agent. 4275 Appropriate Values: See Section 15 of RFC XXXX [Note to RFC-ed: 4276 please replace XXXX with the RFC number of this specification]. 4278 20.2. STUN Attributes 4280 This section registers four new STUN attributes per the procedures in 4281 [I-D.ietf-behave-rfc3489bis]. 4283 0x0024 PRIORITY 4284 0x0025 USE-CANDIDATE 4285 0x8029 ICE-CONTROLLED 4286 0x802a ICE-CONTROLLING 4288 20.3. STUN Error Responses 4290 This section registers one new STUN error response code per the 4291 procedures in [I-D.ietf-behave-rfc3489bis]. 4293 487 Role Conflict: The client asserted an ICE role (controlling or 4294 controlled) that is in conflict with the role of the server. 4296 21. IAB Considerations 4298 The IAB has studied the problem of "Unilateral Self Address Fixing", 4299 which is the general process by which a agent attempts to determine 4300 its address in another realm on the other side of a NAT through a 4301 collaborative protocol reflection mechanism [RFC3424]. ICE is an 4302 example of a protocol that performs this type of function. 4303 Interestingly, the process for ICE is not unilateral, but bilateral, 4304 and the difference has a signficant impact on the issues raised by 4305 IAB. Indeed, ICE can be considered a B-SAF (Bilateral Self-Address 4306 Fixing) protocol, rather than an UNSAF protocol. Regardless, the IAB 4307 has mandated that any protocols developed for this purpose document a 4308 specific set of considerations. This section meets those 4309 requirements. 4311 21.1. Problem Definition 4313 From RFC 3424 any UNSAF proposal must provide: 4315 Precise definition of a specific, limited-scope problem that is to 4316 be solved with the UNSAF proposal. A short term fix should not be 4317 generalized to solve other problems; this is why "short term fixes 4318 usually aren't". 4320 The specific problems being solved by ICE are: 4322 Provide a means for two peers to determine the set of transport 4323 addresses which can be used for communication. 4325 Provide a means for a agent to determine an address that is 4326 reachable by another peer with which it wishes to communicate. 4328 21.2. Exit Strategy 4330 From RFC 3424, any UNSAF proposal must provide: 4332 Description of an exit strategy/transition plan. The better short 4333 term fixes are the ones that will naturally see less and less use 4334 as the appropriate technology is deployed. 4336 ICE itself doesn't easily get phased out. However, it is useful even 4337 in a globally connected Internet, to serve as a means for detecting 4338 whether a router failure has temporarily disrupted connectivity, for 4339 example. ICE also helps prevent certain security attacks which have 4340 nothing to do with NAT. However, what ICE does is help phase out 4341 other UNSAF mechanisms. ICE effectively selects amongst those 4342 mechanisms, prioritizing ones that are better, and deprioritizing 4343 ones that are worse. Local IPv6 addresses can be preferred. As NATs 4344 begin to dissipate as IPv6 is introduced, server reflexive and 4345 relayed candidates (both forms of UNSAF addresses) simply never get 4346 used, because higher priority connectivity exists to the native host 4347 candidates. Therefore, the servers get used less and less, and can 4348 eventually be remove when their usage goes to zero. 4350 Indeed, ICE can assist in the transition from IPv4 to IPv6. It can 4351 be used to determine whether to use IPv6 or IPv4 when two dual-stack 4352 hosts communicate with SIP (IPv6 gets used). It can also allow a 4353 network with both 6to4 and native v6 connectivity to determine which 4354 address to use when communicating with a peer. 4356 21.3. Brittleness Introduced by ICE 4358 From RFC3424, any UNSAF proposal must provide: 4360 Discussion of specific issues that may render systems more 4361 "brittle". For example, approaches that involve using data at 4362 multiple network layers create more dependencies, increase 4363 debugging challenges, and make it harder to transition. 4365 ICE actually removes brittleness from existing UNSAF mechanisms. In 4366 particular, classic STUN (as described in RFC 3489 [RFC3489]) has 4367 several points of brittleness. One of them is the discovery process 4368 which requires a agent to try and classify the type of NAT it is 4369 behind. This process is error-prone. With ICE, that discovery 4370 process is simply not used. Rather than unilaterally assessing the 4371 validity of the address, its validity is dynamically determined by 4372 measuring connectivity to a peer. The process of determining 4373 connectivity is very robust. 4375 Another point of brittleness in classic STUN and any other unilateral 4376 mechanism is its absolute reliance on an additional server. ICE 4377 makes use of a server for allocating unilateral addresses, but allows 4378 agents to directly connect if possible. Therefore, in some cases, 4379 the failure of a STUN server would still allow for a call to progress 4380 when ICE is used. 4382 Another point of brittleness in classic STUN is that it assumes that 4383 the STUN server is on the public Internet. Interestingly, with ICE, 4384 that is not necessary. There can be a multitude of STUN servers in a 4385 variety of address realms. ICE will discover the one that has 4386 provided a usable address. 4388 The most troubling point of brittleness in classic STUN is that it 4389 doesn't work in all network topologies. In cases where there is a 4390 shared NAT between each agent and the STUN server, traditional STUN 4391 may not work. With ICE, that restriction is removed. 4393 Classic STUN also introduces some security considerations. 4394 Fortunately, those security considerations are also mitigated by ICE. 4396 Consequently, ICE serves to repair the brittleness introduced in 4397 classic STUN, and does not introduce any additional brittleness into 4398 the system. 4400 The penalty of these improvements is that ICE increases session 4401 establishment times. 4403 21.4. Requirements for a Long Term Solution 4405 From RFC 3424, any UNSAF proposal must provide: 4407 Identify requirements for longer term, sound technical solutions 4408 -- contribute to the process of finding the right longer term 4409 solution. 4411 Our conclusions from RFC 3489 remain unchanged. However, we feel ICE 4412 actually helps because we believe it can be part of the long term 4413 solution. 4415 21.5. Issues with Existing NAPT Boxes 4417 From RFC 3424, any UNSAF proposal must provide: 4419 Discussion of the impact of the noted practical issues with 4420 existing, deployed NA[P]Ts and experience reports. 4422 A number of NAT boxes are now being deployed into the market which 4423 try and provide "generic" ALG functionality. These generic ALGs hunt 4424 for IP addresses, either in text or binary form within a packet, and 4425 rewrite them if they match a binding. This interferes with classic 4426 STUN. However, the update to STUN [I-D.ietf-behave-rfc3489bis] uses 4427 an encoding which hides these binary addresses from generic ALGs. 4429 Existing NAPT boxes have non-deterministic and typically short 4430 expiration times for UDP-based bindings. This requires 4431 implementations to send periodic keepalives to maintain those 4432 bindings. ICE uses a default of 15s, which is a very conservative 4433 estimate. Eventually, over time, as NAT boxes become compliant to 4434 behave [RFC4787], this minimum keepalive will become deterministic 4435 and well-known, and the ICE timers can be adjusted. Having a way to 4436 discover and control the minimum keepalive interval would be far 4437 better still. 4439 22. Acknowledgements 4441 The authors would like to thank Dan Wing, Eric Rescorla, Flemming 4442 Andreasen, Rohan Mahy, Dean Willis, Eric Cooper, Jason Fischl, 4443 Douglas Otis, Tim Moore, Jean-Francois Mule, Kevin Johns, Jonathan 4444 Lennox and Francois Audet for their comments and input. A special 4445 thanks goes to Bill May, who suggested several of the concepts in 4446 this specification, Philip Matthews, who suggested many of the key 4447 performance optimizations in this specification, Eric Rescorla, who 4448 drafted the text in the introduction, and Magnus Westerlund, for 4449 doing several detailed reviews on the various revisions of this 4450 specification. 4452 23. References 4454 23.1. Normative References 4456 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4457 Requirement Levels", BCP 14, RFC 2119, March 1997. 4459 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 4460 in Session Description Protocol (SDP)", RFC 3605, 4461 October 2003. 4463 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 4464 A., Peterson, J., Sparks, R., Handley, M., and E. 4465 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 4466 June 2002. 4468 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 4469 with Session Description Protocol (SDP)", RFC 3264, 4470 June 2002. 4472 [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth 4473 Modifiers for RTP Control Protocol (RTCP) Bandwidth", 4474 RFC 3556, July 2003. 4476 [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, 4477 "Integration of Resource Management and Session Initiation 4478 Protocol (SIP)", RFC 3312, October 2002. 4480 [RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session 4481 Initiation Protocol (SIP) Preconditions Framework", 4482 RFC 4032, March 2005. 4484 [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 4485 Specifications: ABNF", RFC 4234, October 2005. 4487 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 4488 Provisional Responses in Session Initiation Protocol 4489 (SIP)", RFC 3262, June 2002. 4491 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 4492 Description Protocol", RFC 4566, July 2006. 4494 [RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network 4495 Address Types (ANAT) Semantics for the Session Description 4496 Protocol (SDP) Grouping Framework", RFC 4091, June 2005. 4498 [RFC3484] Draves, R., "Default Address Selection for Internet 4499 Protocol version 6 (IPv6)", RFC 3484, February 2003. 4501 [I-D.ietf-behave-rfc3489bis] 4502 Rosenberg, J., "Session Traversal Utilities for (NAT) 4503 (STUN)", draft-ietf-behave-rfc3489bis-06 (work in 4504 progress), March 2007. 4506 [I-D.ietf-behave-turn] 4507 Rosenberg, J., "Obtaining Relay Addresses from Simple 4508 Traversal Underneath NAT (STUN)", 4509 draft-ietf-behave-turn-03 (work in progress), March 2007. 4511 [I-D.ietf-sip-ice-option-tag] 4512 Rosenberg, J., "Indicating Support for Interactive 4513 Connectivity Establishment (ICE) in the Session 4514 Initiation Protocol (SIP)", 4515 draft-ietf-sip-ice-option-tag-02 (work in progress), 4516 June 2007. 4518 23.2. Informative References 4520 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 4521 "STUN - Simple Traversal of User Datagram Protocol (UDP) 4522 Through Network Address Translators (NATs)", RFC 3489, 4523 March 2003. 4525 [RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly 4526 Application Design Guidelines", RFC 3235, January 2002. 4528 [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and 4529 A. Rayhan, "Middlebox communication architecture and 4530 framework", RFC 3303, August 2002. 4532 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 4533 Camarillo, "Best Current Practices for Third Party Call 4534 Control (3pcc) in the Session Initiation Protocol (SIP)", 4535 BCP 85, RFC 3725, April 2004. 4537 [RFC3102] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro, 4538 "Realm Specific IP: Framework", RFC 3102, October 2001. 4540 [RFC3103] Borella, M., Grabelsky, D., Lo, J., and K. Taniguchi, 4541 "Realm Specific IP: Protocol Specification", RFC 3103, 4542 October 2001. 4544 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 4545 Self-Address Fixing (UNSAF) Across Network Address 4546 Translation", RFC 3424, November 2002. 4548 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 4549 Jacobson, "RTP: A Transport Protocol for Real-Time 4550 Applications", RFC 3550, July 2003. 4552 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 4553 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 4554 RFC 3711, March 2004. 4556 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 4557 via IPv4 Clouds", RFC 3056, February 2001. 4559 [RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for 4560 Comfort Noise (CN)", RFC 3389, September 2002. 4562 [RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing 4563 Tone Generation in the Session Initiation Protocol (SIP)", 4564 RFC 3960, December 2004. 4566 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 4567 and W. Weiss, "An Architecture for Differentiated 4568 Services", RFC 2475, December 1998. 4570 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 4571 E. Lear, "Address Allocation for Private Internets", 4572 BCP 5, RFC 1918, February 1996. 4574 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 4575 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 4576 RFC 4787, January 2007. 4578 [I-D.ietf-mmusic-connectivity-precon] 4579 Andreasen, F., "Connectivity Preconditions for Session 4580 Description Protocol Media Streams", 4581 draft-ietf-mmusic-connectivity-precon-02 (work in 4582 progress), June 2006. 4584 [I-D.ietf-avt-rtp-no-op] 4585 Andreasen, F., "A No-Op Payload Format for RTP", 4586 draft-ietf-avt-rtp-no-op-04 (work in progress), May 2007. 4588 [I-D.ietf-avt-rtp-and-rtcp-mux] 4589 Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 4590 Control Packets on a Single Port", 4591 draft-ietf-avt-rtp-and-rtcp-mux-05 (work in progress), 4592 May 2007. 4594 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 4595 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 4597 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 4598 Conversation", RFC 4103, June 2005. 4600 [I-D.ietf-sip-outbound] 4601 Jennings, C. and R. Mahy, "Managing Client Initiated 4602 Connections in the Session Initiation Protocol (SIP)", 4603 draft-ietf-sip-outbound-09 (work in progress), June 2007. 4605 Appendix A. Lite and Full Implementations 4607 ICE allows for two types of implementations. A full implementation 4608 supports the controlling and controlled roles in a session, and can 4609 also perform address gathering. In contrast, a lite implementation 4610 is a minimalist implementation that does little but respond to STUN 4611 checks. 4613 Because ICE requires both endpoints to support it in order to bring 4614 benefits to either endpoint, incremental deployment of ICE in a 4615 network is more complicated. Many sessions involve an endpoint which 4616 is, by itself, not behind a NAT and not one that would worry about 4617 NAT traversal. A very common case is to have one endpoint that 4618 requires NAT traversal (such as a VoIP hard phone or soft phone) make 4619 a call to one of these devices. Even if the phone supports a full 4620 ICE implementation, ICE won't be used at all if the other device 4621 doesn't support it. The lite implementation allows for a low-cost 4622 entry point for these devices. Once they support the lite 4623 implementation, full implementations can connect to them and get the 4624 full benefits of ICE. 4626 Consequently, a lite implementation is only appropriate for devices 4627 that will *always* be connected to the public Internet and have a 4628 public IP address at which it can receive packets from any 4629 correspondent. ICE will not function when a lite implementation is 4630 placed behind a NAT. 4632 ICE allows a lite implementation to have a single IPv4 host candidate 4633 and several IPv6 addresses. In that case, candidate pairs are 4634 selected by the controlling agent using a static algorithm, such as 4635 the one in RFC 3484, which is recommended by this specification. 4636 However, static mechanisms for address selection are always prone to 4637 error, since they cannot ever reflect the actual topology and can 4638 never provide actual guarantees on connectivity. They are always 4639 heuristics. Consequently, if an agent is implementing ICE just to 4640 select between its IPv4 and IPv6 addresses, and it is none of its 4641 interfaces are behind NAT, usage of full ICE is still RECOMMENDED in 4642 order to provide the most robust form of address selection possible. 4644 It is important to note that the lite implementation was added to 4645 this specification to provide a stepping stone to full 4646 implementation. Even for devices that are always connected to the 4647 public Internet with just a single IPv4 address, a full 4648 implementation is preferable if achievable. A full implementation 4649 will reduce call setup times, since ICE's aggressive mode can be 4650 used. Full implementations also obtain the security benefits of ICE 4651 unrelated to NAT traversal; in particular, the voice hammer attack 4652 described in Section 18 is prevented only for full implementations, 4653 not lite. Finally, it is often the case that a device which finds 4654 itself with a public address today will be placed in a network 4655 tomorrow where it will be behind a NAT. It is difficult to 4656 definitively know, over the lifetime of a device or product, that it 4657 will always be used on the public Internet. Full implementation 4658 provides assurance that communications will always work. 4660 Appendix B. Design Motivations 4662 ICE contains a number of normative behaviors which may themselves be 4663 simple, but derive from complicated or non-obvious thinking or use 4664 cases which merit further discussion. Since these design motivations 4665 are not neccesary to understand for purposes of implementation, they 4666 are discussed here in an appendix to the specification. This section 4667 is non-normative. 4669 B.1. Pacing of STUN Transactions 4671 STUN transactions used to gather candidates and to verify 4672 connectivity are paced out at an approximate rate of one new 4673 transaction every Ta milliseconds. Each transaction, in turn, has a 4674 retransmission timer RTO that is a function of Ta as well. Why are 4675 these transactions paced, and why are these formulas used? 4677 Sending of these STUN requests will often have the effect of creating 4678 bindings on NAT devices between the client and the STUN servers. 4679 Experience has shown that many NAT devices have upper limits on the 4680 rate at which they will create new bindings. Experiments have shown 4681 that once every 20ms is well supported, but not much lower than that. 4682 This is why Ta has a lower bound of 20ms. Furthermore, transmission 4683 of these packets on the network makes use of bandwidth and needs to 4684 be rate limited by the agent. As a consequence, the pacing ensures 4685 that the NAT devices does not get overloaded and that traffic is kept 4686 at a reasonable rate. 4688 The definition of a "reasonable" rate is that STUN should not use 4689 more bandwidth than the RTP itself will use, once media starts 4690 flowing. The formula for Ta is designed so that, if a STUN packet 4691 were sent every Ta seconds, it would consume the same amount of 4692 bandwidth as RTP packets, summed across all media streams. Of 4693 course, STUN has retransmits, and the desire is to pace those as 4694 well. For this reason, RTO is set such that the first retransmit on 4695 the first transaction happens just as the first STUN request on the 4696 last transaction occurs. Pictorially: 4698 First Packets Retransmits 4700 | | 4701 | | 4702 -------+------ -------+------ 4703 / \ / \ 4704 / \ / \ 4706 +--+ +--+ +--+ +--+ +--+ +--+ 4707 |A1| |B1| |C1| |A2| |B2| |C2| 4708 +--+ +--+ +--+ +--+ +--+ +--+ 4710 ---+-------+-------+-------+-------+-------+------------ Time 4711 0 Ta 2Ta 3Ta 4Ta 5Ta 4713 In this picture, there are three transactions that will be sent (for 4714 example, in the case of candidate gathering, there are three host 4715 candidate/STUN server pairs). These are transactions A, B and C. The 4716 retransmit timer is set so that the first retransmission on the first 4717 transaction (packet A2) is sent at time 3Ta. 4719 Subsequent retransmits after the first will occur even less 4720 frequently than Ta milliseconds apart, since STUN uses an exponential 4721 back-off on its retransmissions. 4723 B.2. Candidates with Multiple Bases 4725 Section 4.1.1.3 talks about eliminating candidates that have the same 4726 transport address and base. However, candidates with the same 4727 transport addresses but different bases are not redundant . When can 4728 an agent have two candidates that have the same IP address and port, 4729 but different bases? Consider the topology of Figure 28: 4731 +----------+ 4732 | STUN Srvr| 4733 +----------+ 4734 | 4735 | 4736 ----- 4737 // \\ 4738 | | 4739 | B:net10 | 4740 | | 4741 \\ // 4742 ----- 4743 | 4744 | 4745 +----------+ 4746 | NAT | 4747 +----------+ 4748 | 4749 | 4750 ----- 4751 // \\ 4752 | A | 4753 |192.168/16 | 4754 | | 4755 \\ // 4756 ----- 4757 | 4758 | 4759 |192.168.1.100 ----- 4760 +----------+ // \\ +----------+ 4761 | | | | | | 4762 | Offerer |---------| C:net10 |-----------| Answerer | 4763 | |10.0.1.100| | 10.0.1.101 | | 4764 +----------+ \\ // +----------+ 4765 ----- 4767 Figure 28: Identical Candidates with Different Bases 4769 In this case, the offerer is multi-homed. It has one interface, 4770 10.0.1.100, on network C, which is a net 10 private network. The 4771 Answerer is on this same network. The offerer is also connected to 4772 network A, which is 192.168/16. The offerer has an interface of 4773 192.168.1.100 on this network. There is a NAT on this network, 4774 natting into network B, which is another net 10 private network, but 4775 not connected to network C. There is a STUN server on network B. 4777 The offerer obtains a host candidate on its interface on network C 4778 (10.0.1.100:2498) and a host candidate on its interface on network A 4779 (192.168.1.100:3344). It performs a STUN query to its configured 4780 STUN server from 192.168.1.100:3344. This query passes through the 4781 NAT, which happens to assign the binding 10.0.1.100:2498. The STUN 4782 server reflects this in the STUN Binding Response. Now, the offerer 4783 has obtained a server reflexive candidate with a transport address 4784 that is identical to a host candidate (10.0.1.100:2498). However, 4785 the server reflexive candidate has a base of 192.168.1.100:3344, and 4786 the host candidate has a base of 10.0.1.100:2498. 4788 B.3. Purpose of the and Attributes 4790 The candidate attribute contains two values that are not used at all 4791 by ICE itself - and . Why is it present? 4793 There are two motivations for its inclusion. The first is 4794 diagnostic. It is very useful to know the relationship between the 4795 different types of candidates. By including it, an agent can know 4796 which relayed candidate is associated with which reflexive candidate, 4797 which in turn is associated with a specific host candidate. When 4798 checks for one candidate succeed and not the others, this provides 4799 useful diagnostics on what is going on in the network. 4801 The second reason has to do with off-path Quality of Service (QoS) 4802 mechanisms. When ICE is used in environments such as PacketCable 4803 2.0, proxies will, in addition to performing normal SIP operations, 4804 inspect the SDP in SIP messages, and extract the IP address and port 4805 for media traffic. They can then interact, through policy servers, 4806 with access routers in the network, to establish guaranteed QoS for 4807 the media flows. This QoS is provided by classifying the RTP traffic 4808 based on 5-tuple, and then providing it a guaranteed rate, or marking 4809 its Diffserv codepoints appropriately. When a residential NAT is 4810 present, and a relayed candidate gets selected for media, this 4811 relayed candidate will be a transport address on an actual TURN 4812 server. That address says nothing about the actual transport address 4813 in the access router that would be used to classify packets for QoS 4814 treatment. Rather, the server reflexive candidate towards the TURN 4815 server is needed. By carrying the translation in the SDP, the proxy 4816 can use that transport address to request QoS from the access router. 4818 B.4. Importance of the STUN Username 4820 ICE requires the usage of message integrity with STUN using its short 4821 term credential functionality. The actual short term credential is 4822 formed by exchanging username fragments in the SDP offer/answer 4823 exchange. The need for this mechanism goes beyond just security; it 4824 is actual required for correct operation of ICE in the first place. 4826 Consider agents L, R, and Z. L and R are within private enterprise 1, 4827 which is using 10.0.0.0/8. Z is within private enterprise 2, which 4828 is also using 10.0.0.0/8. As it turns out, R and Z both have IP 4829 address 10.0.1.1. L sends an offer to Z. Z, in its answer, provides 4830 L with its host candidates. In this case, those candidates are 4831 10.0.1.1:8866 and 10.0.1.1:8877. As it turns out, R is in a session 4832 at that same time, and is also using 10.0.1.1:8866 and 10.0.1.1:8877 4833 as host candidates. This means that R is prepared to accept STUN 4834 messages on those ports, just as Z is. L will send a STUN request to 4835 10.0.1.1:8866 and and another to 10.0.1.1:8877. However, these do 4836 not go to Z as expected. Instead, they go to R! If R just replied 4837 to them, L would believe it has connectivity to Z, when in fact it 4838 has connectivity to a completely different user, R. To fix this, the 4839 STUN short term credential mechanisms are used. The username 4840 fragments are sufficiently random that it is highly unlikely that R 4841 would be using the same values as Z. Consequently, R would reject the 4842 STUN request since the credentials were invalid. In essence, the 4843 STUN username fragments provide a form of transient host identifiers, 4844 bound to a particular offer/answer session. 4846 An unfortunate consequence of the non-uniqueness of IP addresses is 4847 that, in the above example, R might not even be an ICE agent. It 4848 could be any host, and the port to which the STUN packet is directed 4849 could be any ephemeral port on that host. If there is an application 4850 listening on this socket for packets, and it is not prepared to 4851 handle malformed packets for whatever protocol is in use, the 4852 operation of that application could be affected. Fortunately, since 4853 the ports exchanged in SDP are ephemeral and usually drawn from the 4854 dynamic or registered range, the odds are good that the port is not 4855 used to run a server on host R, but rather is the agent side of some 4856 protocol. This decreases the probability of hitting an allocated 4857 port, due to the transient nature of port usage in this range. 4858 However, the possibility of a problem does exist, and network 4859 deployers should be prepared for it. Note that this is not a problem 4860 specific to ICE; stray packets can arrive at a port at any time for 4861 any type of protocol, especially ones on the public Internet. As 4862 such, this requirement is just restating a general design guideline 4863 for Internet applications - be prepared for unknown packets on any 4864 port. 4866 B.5. The Candidate Pair Sequence Number Formula 4868 The sequence number for a candidate pair has an odd form. It is: 4870 pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0) 4872 Why is this? When the candidate pairs are sorted based on this 4873 value, the resulting sorting has the MAX/MIN property. This means 4874 that the pairs are first sorted based on decreasing value of the 4875 maximum of the two sequence numbers. For pairs that have the same 4876 value of the maximum sequence number, the minimum sequence number is 4877 used to sort amongst them. If the max and the min sequence numbers 4878 are the same, the offerers priority is used as the tie breaker in the 4879 last part of the expression. The factor of 2*32 is used since the 4880 priority of a single candidate is always less than 2*32, resulting in 4881 the pair priority being a "concatenation" of the two component 4882 priorities. This creates the MAX/MIN sorting. MAX/MIN ensures that, 4883 for a particular agent, a lower priority candidate is never used 4884 until all higher priority candidates have been tried. 4886 B.6. The remote-candidates attribute 4888 The a=remote-candidates attribute exists to eliminate a race 4889 condition between the updated offer and the response to the STUN 4890 Binding Request that moved a candidate into the Valid list. This 4891 race condition is shown in Figure 29. On receipt of message 4, agent 4892 L adds a candidate pair to the valid list. If there was only a 4893 single media stream with a single component, agent L could now send 4894 an updated offer. However, the check from agent R has not yet 4895 generated a response, and agent R receives the updated offer (message 4896 7) before getting the response (message 9). Thus, it does not yet 4897 know that this particular pair is valid. To eliminate this 4898 condition, the actual candidates at R that were selected by the 4899 offerer (the remote candidates) are included in the offer itself, and 4900 the answerer delays its answer until those pairs validate. 4902 Agent A Network Agent B 4903 |(1) Offer | | 4904 |------------------------------------------>| 4905 |(2) Answer | | 4906 |<------------------------------------------| 4907 |(3) STUN Req. | | 4908 |------------------------------------------>| 4909 |(4) STUN Res. | | 4910 |<------------------------------------------| 4911 |(5) STUN Req. | | 4912 |<------------------------------------------| 4913 |(6) STUN Res. | | 4914 |-------------------->| | 4915 | |Lost | 4916 |(7) Offer | | 4917 |------------------------------------------>| 4918 |(8) STUN Req. | | 4919 |<------------------------------------------| 4920 |(9) STUN Res. | | 4921 |------------------------------------------>| 4922 |(10) Answer | | 4923 |<------------------------------------------| 4925 Figure 29: Race Condition Flow 4927 B.7. Why are Keepalives Needed? 4929 Once media begins flowing on a candidate pair, it is still necessary 4930 to keep the bindings alive at intermediate NATs for the duration of 4931 the session. Normally, the media stream packets themselves (e.g., 4932 RTP) meet this objective. However, several cases merit further 4933 discussion. Firstly, in some RTP usages, such as SIP, the media 4934 streams can be "put on hold". This is accomplished by using the SDP 4935 "sendonly" or "inactive" attributes, as defined in RFC 3264 4936 [RFC3264]. RFC 3264 directs implementations to cease transmission of 4937 media in these cases. However, doing so may cause NAT bindings to 4938 timeout, and media won't be able to come off hold. 4940 Secondly, some RTP payload formats, such as the payload format for 4941 text conversation [RFC4103], may send packets so infrequently that 4942 the interval exceeds the NAT binding timeouts. 4944 Thirdly, if silence suppression is in use, long periods of silence 4945 may cause media transmission to cease sufficiently long for NAT 4946 bindings to time out. 4948 For these reasons, the media packets themselves cannot be relied 4949 upon. ICE defines a simple periodic keepalive that operates 4950 independently of media transmission. This makes its bandwidth 4951 requirements highly predictable, and thus amenable to QoS 4952 reservations. 4954 B.8. Why Prefer Peer Reflexive Candidates? 4956 Section 4.1.2 describes procedures for computing the priority of 4957 candidate based on its type and local preferences. That section 4958 requires that the type preference for peer reflexive candidates 4959 always be higher than server reflexive. Why is that? The reason has 4960 to do with the security considerations in Section 18. It is much 4961 easier for an attacker to cause an agent to use a false server 4962 reflexive candidate than it is for an attacker to cause an agent to 4963 use a false peer reflexive candidate. Consequently, attacks against 4964 address gathering with Binding requests are thwarted by ICE by 4965 preferring the peer reflexive candidates. 4967 B.9. Why Send an Updated Offer? 4969 Section 11.1 describes rules for sending media. Both agents can send 4970 media once ICE checks complete, without waiting for an updated offer. 4971 Indeed, the only purpose of the updated offer is to "correct" the SDP 4972 so that the default destination for media matches where media is 4973 being sent based on ICE procedures (which will be the highest 4974 priority nominated candidate pair). 4976 This begs the question - why is the updated offer/answer exchange 4977 needed at all? Indeed, in a pure offer/answer environment, it would 4978 not be. The offerer and answerer will agree on the candidates to use 4979 through ICE, and then can begin using them. As far as the agents 4980 themselves are concerned, the updated offer/answer provides no new 4981 information. However, in practice, numerous components along the 4982 signaling path look at the SDP information. These include entities 4983 performing off-path QoS reservations, NAT traversal components such 4984 as ALGs and Session Border Controllers (SBCs) and diagnostic tools 4985 that passively monitor the network. For these tools to continue to 4986 function without change, the core property of SDP - that the 4987 existing, pre-ICE definitions of the addresses used for media - the m 4988 and c lines and the rtcp attribute - must be retained. For this 4989 reason, an updated offer must be sent. 4991 B.10. Why are Binding Indications Used for Keepalives? 4993 Media keepalives are described in Section 10. These keepalives make 4994 use of STUN when both endpoints are ICE capable. However, rather 4995 than using a Binding Request transaction (which generates a 4996 response), the keepalives use an Indication. Why is that? 4997 The primary reason has to do with network QoS mechanisms. Once media 4998 begins flowing, network elements will assume that the media stream 4999 has a fairly regular structure, making use of periodic packets at 5000 fixed intervals, with the possibility of jitter. If an agent is 5001 sending media packets, and then receives a Binding Request, it would 5002 need to generate a response packet along with its media packets. 5003 This will increase the actual bandwidth requirements for the 5-tuple 5004 carrying the media packets, and introduce jitter in the delivery of 5005 those packets. Analysis has shown that this is a concern in certain 5006 layer 2 access networks that use fairly tight packet schedulers for 5007 media. 5009 Additionally, using a Binding Indication allows integrity to be 5010 disabled, allowing for better performance. This is useful for large 5011 scale endpoints, such as PSTN gateways and SBCs. 5013 B.11. Why is the Conflict Resolution Mechanism Needed? 5015 When ICE runs between two peers, one agent acts as controlled, and 5016 the other as controlling. Rules are defined as a function of 5017 implementation type and offerer/answerer to determine who is 5018 controlling and who is controlled. However, the specification 5019 mentions that, in some cases, both sides might believe they are 5020 controlling, or both sides might believe they are controlled. How 5021 can this happen? 5023 The condition when both agents believe they are controlled shows up 5024 in third party call control cases. Consider the following flow: 5026 A Controller B 5027 |(1) INV() | | 5028 |<-------------| | 5029 |(2) 200(SDP1) | | 5030 |------------->| | 5031 | |(3) INV() | 5032 | |------------->| 5033 | |(4) 200(SDP2) | 5034 | |<-------------| 5035 |(5) ACK(SDP2) | | 5036 |<-------------| | 5037 | |(6) ACK(SDP1) | 5038 | |------------->| 5040 Figure 30: Role Conflict Flow 5042 This flow is a variation on flow III of RFC 3725 [RFC3725]. In fact, 5043 it works better than flow III since it produces fewer messages. In 5044 this flow, the controller sends an offerless INVITE to agent A, which 5045 responds with its offer, SDP1. The agent then sends an offerless 5046 INVITE to agent B, which it responds to with its offer, SDP2. The 5047 controller then uses the offer from each agent to generate the 5048 answers. When this flow is used, ICE will run between agents A and 5049 B, but both will believe they are in the controlling role. With the 5050 role conflict resolution procedures, this flow will function properly 5051 when ICE is used. 5053 At this time, there are no documented flows which can result in the 5054 case where both agents believe they are controlled. However, the 5055 conflict resolution procedures allow for this case, should a flow 5056 arise which would fit into this category. 5058 Author's Address 5060 Jonathan Rosenberg 5061 Cisco 5062 Edison, NJ 5063 US 5065 Phone: +1 973 952-5000 5066 Email: jdrosen@cisco.com 5067 URI: http://www.jdrosen.net 5069 Full Copyright Statement 5071 Copyright (C) The IETF Trust (2007). 5073 This document is subject to the rights, licenses and restrictions 5074 contained in BCP 78, and except as set forth therein, the authors 5075 retain all their rights. 5077 This document and the information contained herein are provided on an 5078 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 5079 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 5080 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 5081 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 5082 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 5083 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 5085 Intellectual Property 5087 The IETF takes no position regarding the validity or scope of any 5088 Intellectual Property Rights or other rights that might be claimed to 5089 pertain to the implementation or use of the technology described in 5090 this document or the extent to which any license under such rights 5091 might or might not be available; nor does it represent that it has 5092 made any independent effort to identify any such rights. Information 5093 on the procedures with respect to rights in RFC documents can be 5094 found in BCP 78 and BCP 79. 5096 Copies of IPR disclosures made to the IETF Secretariat and any 5097 assurances of licenses to be made available, or the result of an 5098 attempt made to obtain a general license or permission for the use of 5099 such proprietary rights by implementers or users of this 5100 specification can be obtained from the IETF on-line IPR repository at 5101 http://www.ietf.org/ipr. 5103 The IETF invites any interested party to bring to its attention any 5104 copyrights, patents or patent applications, or other proprietary 5105 rights that may cover technology that may be required to implement 5106 this standard. Please address the information to the IETF at 5107 ietf-ipr@ietf.org. 5109 Acknowledgment 5111 Funding for the RFC Editor function is provided by the IETF 5112 Administrative Support Activity (IASA).