idnits 2.17.1 draft-ietf-mmusic-ice-sip-sdp-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 are 6 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? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 18, 2016) is 2951 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) == Unused Reference: 'RFC3550' is defined on line 1649, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4091 (Obsoleted by RFC 5245) ** Obsolete normative reference: RFC 4092 (Obsoleted by RFC 5245) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Downref: Normative reference to an Informational RFC: RFC 7092 == Outdated reference: A later version (-20) exists of draft-ietf-ice-rfc5245bis-00 Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC M. Petit-Huguenin 3 Internet-Draft Impedance Mismatch 4 Intended status: Standards Track A. Keranen 5 Expires: September 19, 2016 Ericsson 6 S. Nandakumar 7 Cisco Systems 8 March 18, 2016 10 Using Interactive Connectivity Establishment (ICE) with 11 Session Description Protocol (SDP) offer/answer and Session Initiation 12 Protocol (SIP) 13 draft-ietf-mmusic-ice-sip-sdp-08 15 Abstract 17 This document describes how Interactive Connectivity Establishment 18 (ICE) is used with Session Description Protocol (SDP) offer/answer 19 and Session Initiation Protocol (SIP). 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 19, 2016. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. ICE Candidate Exchange and Offer/Answer Mapping . . . . . . . 4 70 4. Sending the Initial Offer . . . . . . . . . . . . . . . . . . 5 71 4.1. Choosing Default Candidates . . . . . . . . . . . . . . . 5 72 4.2. Encoding the SDP . . . . . . . . . . . . . . . . . . . . 5 73 5. Receiving the Initial Offer . . . . . . . . . . . . . . . . . 7 74 5.1. Choosing Default Candidates . . . . . . . . . . . . . . . 7 75 5.2. Verifying ICE Support . . . . . . . . . . . . . . . . . . 7 76 5.3. Determining Role . . . . . . . . . . . . . . . . . . . . 8 77 6. Receipt of the Initial Answer . . . . . . . . . . . . . . . . 8 78 6.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 8 79 7. Performing Connectivity Checks . . . . . . . . . . . . . . . 9 80 8. Concluding ICE . . . . . . . . . . . . . . . . . . . . . . . 9 81 8.1. Procedures for Full Implementations . . . . . . . . . . . 9 82 8.1.1. Updating states . . . . . . . . . . . . . . . . . . . 9 83 8.2. Freeing Candidates . . . . . . . . . . . . . . . . . . . 9 84 8.2.1. Full Implementation Procedures . . . . . . . . . . . 9 85 9. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 86 9.1. "candidate" Attribute . . . . . . . . . . . . . . . . . . 10 87 9.2. "remote-candidates" Attribute . . . . . . . . . . . . . . 12 88 9.3. "ice-lite" and "ice-mismatch" Attributes . . . . . . . . 12 89 9.4. "ice-ufrag" and "ice-pwd" Attributes . . . . . . . . . . 13 90 9.5. "ice-pacing" Attribute . . . . . . . . . . . . . . . . . 13 91 9.6. "ice-options" Attribute . . . . . . . . . . . . . . . . . 14 92 10. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . . . 14 93 10.1. Generating the Offer . . . . . . . . . . . . . . . . . . 14 94 10.1.1. Procedures for All Implementations . . . . . . . . . 14 95 10.1.2. Procedures for Full Implementations . . . . . . . . 15 96 10.1.3. Procedures for Lite Implementations . . . . . . . . 17 98 10.2. Receiving the Offer and Generating an Answer . . . . . . 17 99 10.2.1. Procedures for All Implementations . . . . . . . . . 17 100 10.2.2. Procedures for Full Implementations . . . . . . . . 18 101 10.2.3. Procedures for Lite Implementations . . . . . . . . 20 102 10.3. Receiving the Answer for a Subsequent Offer . . . . . . 21 103 10.3.1. Procedures for All Implementations . . . . . . . . . 21 104 10.4. Updating the Check and Valid Lists . . . . . . . . . . . 22 105 10.4.1. Procedures for Full Implementations . . . . . . . . 22 106 10.4.2. Procedures for Lite Implementations . . . . . . . . 23 107 11. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 23 108 12. Media Handling . . . . . . . . . . . . . . . . . . . . . . . 24 109 12.1. Sending Media . . . . . . . . . . . . . . . . . . . . . 24 110 12.1.1. Procedures for All Implementations . . . . . . . . . 24 111 12.2. Receiving Media . . . . . . . . . . . . . . . . . . . . 24 112 13. Usage with SIP . . . . . . . . . . . . . . . . . . . . . . . 24 113 13.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . 24 114 13.1.1. Offer in INVITE . . . . . . . . . . . . . . . . . . 25 115 13.1.2. Offer in Response . . . . . . . . . . . . . . . . . 26 116 13.2. SIP Option Tags and Media Feature Tags . . . . . . . . . 26 117 13.3. Interactions with Forking . . . . . . . . . . . . . . . 27 118 13.4. Interactions with Preconditions . . . . . . . . . . . . 27 119 13.5. Interactions with Third Party Call Control . . . . . . . 27 120 14. Relationship with ANAT . . . . . . . . . . . . . . . . . . . 28 121 15. Setting Ta and RTO for RTP Media Streams . . . . . . . . . . 28 122 16. Security Considerations . . . . . . . . . . . . . . . . . . . 28 123 16.1. Attacks on the Offer/Answer Exchanges . . . . . . . . . 28 124 16.2. Insider Attacks . . . . . . . . . . . . . . . . . . . . 29 125 16.2.1. The Voice Hammer Attack . . . . . . . . . . . . . . 29 126 16.2.2. Interactions with Application Layer Gateways and SIP 29 127 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 128 17.1. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 30 129 17.1.1. candidate Attribute . . . . . . . . . . . . . . . . 30 130 17.1.2. remote-candidates Attribute . . . . . . . . . . . . 31 131 17.1.3. ice-lite Attribute . . . . . . . . . . . . . . . . . 31 132 17.1.4. ice-mismatch Attribute . . . . . . . . . . . . . . . 32 133 17.1.5. ice-pwd Attribute . . . . . . . . . . . . . . . . . 32 134 17.1.6. ice-ufrag Attribute . . . . . . . . . . . . . . . . 33 135 17.1.7. ice-pacing Attribute . . . . . . . . . . . . . . . . 33 136 17.1.8. ice-options Attribute . . . . . . . . . . . . . . . 33 137 17.2. Interactive Connectivity Establishment (ICE) Options 138 Registry . . . . . . . . . . . . . . . . . . . . . . . . 34 139 18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 140 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 141 19.1. Normative References . . . . . . . . . . . . . . . . . . 35 142 19.2. Informative References . . . . . . . . . . . . . . . . . 37 143 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 38 144 Appendix B. The remote-candidates Attribute . . . . . . . . . . 39 145 Appendix C. Why Is the Conflict Resolution Mechanism Needed? . . 40 146 Appendix D. Why Send an Updated Offer? . . . . . . . . . . . . . 41 147 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 149 1. Introduction 151 This document describes how Interactive Connectivity Establishment 152 (ICE) is used with Session Description Protocol (SDP) offer/answer 153 [RFC3264] and Session Initiation Protocol (SIP). The ICE 154 specification [ICE-BIS] describes procedures that are common to all 155 usages of ICE and this document gives the additional details needed 156 to use ICE with SDP offer/answer and SIP. 158 Note that ICE is not intended for NAT traversal for SIP, which is 159 assumed to be provided via another mechanism [RFC5626]. 161 2. Terminology 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 165 "OPTIONAL" in this document are to be interpreted as described in RFC 166 2119 [RFC2119]. 168 Readers should be familiar with the terminology defined in [RFC3264], 169 in [ICE-BIS] and the following: 171 Default Destination/Candidate: The default destination for a 172 component of a media stream is the transport address that would be 173 used by an agent that is not ICE aware. A default candidate for a 174 component is one whose transport address matches the default 175 destination for that component. For the RTP component, the 176 default IP address is in the "c=" line of the SDP, and the port is 177 in the "m=" line. For the RTCP component, it is in the rtcp 178 attribute when present, and when not present, the IP address is in 179 the "c=" line and 1 plus the port is in the "m=" line. 181 3. ICE Candidate Exchange and Offer/Answer Mapping 183 [ICE-BIS] defines ICE candidate exchange as the process for the ICE 184 agents (Initiator and Responder) to exchange their candidate 185 information required for ICE processing at the agents. For the 186 purposes of this specification, the candidate exchange process 187 corresponds to the [RFC3264] Offer/Answer protocol and the 188 terminologies offerer and answerer correspond to the initiator and 189 responder terminologies from the [ICE-BIS] respectively. 191 4. Sending the Initial Offer 193 The offerer shall follow the procedures defined in section 4 of 194 [ICE-BIS] to gather, prioritize and eliminate the redundant 195 candidates. It then chooses the default candidates and encodes them 196 in SDP to be sent to its peer, the answerer. 198 4.1. Choosing Default Candidates 200 A candidate is said to be default if it would be the target of media 201 from a non-ICE peer; that target is called the DEFAULT DESTINATION. 202 If the default candidates are not selected by the ICE algorithm when 203 communicating with an ICE-aware peer, an updated offer/answer will be 204 required after ICE processing completes in order to "fix up" the SDP 205 so that the default destination for media matches the candidates 206 selected by ICE. If ICE happens to select the default candidates, no 207 updated offer/answer is required. 209 An agent MUST choose a set of candidates, one for each component of 210 each in-use media stream, to be default. A media stream is in-use if 211 it does not have a port of zero (which is used in RFC 3264 to reject 212 a media stream). Consequently, a media stream is in-use even if it 213 is marked as a=inactive [RFC4566] or has a bandwidth value of zero. 215 It is RECOMMENDED that default candidates be chosen based on the 216 likelihood of those candidates to work with the peer that is being 217 contacted if ICE is not being used. It is RECOMMENDED that the 218 default candidates are the relayed candidates (if relayed candidates 219 are available), server reflexive candidates (if server reflexive 220 candidates are available), and finally host candidates. 222 4.2. Encoding the SDP 224 The process of encoding the SDP is identical between full and lite 225 implementations. 227 The agent will include an "m=" line for each media stream it wishes 228 to use. The ordering of media streams in the SDP is relevant for 229 ICE. ICE will perform its connectivity checks for the first "m=" 230 line first, and consequently media will be able to flow for that 231 stream first. Agents SHOULD place their most important media stream, 232 if there is one, first in the SDP. 234 There will be a candidate attribute for each candidate for a 235 particular media stream. Section 9 provides detailed rules for 236 constructing this attribute. 238 STUN connectivity checks between agents are authenticated using the 239 short-term credential mechanism defined for STUN [RFC5389]. This 240 mechanism relies on a username and password that are exchanged 241 through protocol machinery between the client and server. The 242 username fragment and password are exchanged in the ice-ufrag and 243 ice-pwd attributes, respectively. 245 If an agent is a lite implementation, it MUST include an "a=ice-lite" 246 session-level attribute in its SDP to indicate this. If an agent is 247 a full implementation, it MUST NOT include this attribute. 249 The default candidates are added to the SDP as the default 250 destination for media. For streams based on RTP, this is done by 251 placing the IP address and port of the RTP candidate into the "c=" 252 and "m=" lines, respectively. If the agent is utilizing RTCP and if 253 RTCP candidate is present and is not equal to the same address and 254 the next higher port number of the RTP candidate, the agent MUST 255 encode the RTCP candidate using the a=rtcp attribute as defined in 256 RFC 3605 [RFC3605]. If RTCP is not in use, the agent MUST signal 257 that using b=RS:0 and b=RR:0 as defined in RFC 3556 [RFC3556]. 259 The transport addresses that will be the default destination for 260 media when communicating with non-ICE peers MUST also be present as 261 candidates in one or more a=candidate lines. 263 ICE provides for extensibility by allowing an offer or answer to 264 contain a series of tokens that identify the ICE extensions used by 265 that agent. If an agent supports an ICE extension, it MUST include 266 the token defined for that extension in the ice-options attribute. 268 The following is an example SDP message that includes ICE attributes 269 (lines folded for readability): 271 v=0 272 o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1 273 s= 274 c=IN IP4 192.0.2.3 275 t=0 0 276 a=ice-pwd:asd88fgpdd777uzjYhagZg 277 a=ice-ufrag:8hhY 278 m=audio 45664 RTP/AVP 0 279 b=RS:0 280 b=RR:0 281 a=rtpmap:0 PCMU/8000 282 a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host 283 a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 284 10.0.1.1 rport 8998 286 Once an agent has sent its offer or its answer, that agent MUST be 287 prepared to receive both STUN and media packets on each candidate. 288 As discussed in Section 10.1 of [ICE-BIS], media packets can be sent 289 to a candidate prior to its appearance as the default destination for 290 media in an offer or answer. 292 5. Receiving the Initial Offer 294 On receiving the offer, the answerer verifies the support for ICE 295 (section 5.1.1 of [ICE-BIS]), determines its role (section 5.1.2 of 296 [ICE-BIS]), gathers candidates (section 4 of [ICE-BIS]), encodes the 297 candidates in an SDP answer and sends it to its peer, the offerer. 298 The answerer shall then follow the steps defined in sections 5.1.3 299 and 5.1.4 of [ICE-BIS] to schedule the ICE connectivity checks. 301 The below sub-sections provide additional requirements associated 302 with the processing of the offerer's SDP pertaining to this 303 specification. 305 5.1. Choosing Default Candidates 307 The process for selecting default candidates at the answerer is 308 identical to the process followed by the offerer, as described in 309 Section 4.1 for full implementations in this specification and 310 section 4.2 of [ICE-BIS] for lite implementations. 312 5.2. Verifying ICE Support 314 The agent will proceed with the ICE procedures defined in [ICE-BIS] 315 and this specification if, for each media stream in the SDP it 316 received, the default destination for each component of that media 317 stream appears in a candidate attribute. For example, in the case of 318 RTP, the IP address and port in the "c=" and "m=" lines, 319 respectively, appear in a candidate attribute and the value in the 320 rtcp attribute appears in a candidate attribute. 322 If this condition is not met, the agent MUST process the SDP based on 323 normal RFC 3264 procedures, without using any of the ICE mechanisms 324 described in the remainder of this specification with the following 325 exceptions: 327 1. The agent MUST follow the rules of section 9 of [ICE-BIS], which 328 describe keepalive procedures for all agents. 330 2. If the agent is not proceeding with ICE because there were 331 a=candidate attributes, but none that matched the default 332 destination of the media stream, the agent MUST include an a=ice- 333 mismatch attribute in its answer. 335 3. If the default candidates were relayed candidates learned through 336 a TURN server, the agent MUST create permissions in the TURN 337 server for the IP addresses learned from its peer in the SDP it 338 just received. If this is not done, initial packets in the media 339 stream from the peer may be lost. 341 5.3. Determining Role 343 In unusual cases, described in Appendix C, it is possible for both 344 agents to mistakenly believe they are controlled or controlling. To 345 resolve this, each agent MUST select a random number, called the tie- 346 breaker, uniformly distributed between 0 and (2**64) - 1 (that is, a 347 64-bit positive integer). This number is used in connectivity checks 348 to detect and repair this case, as described in Section 6.1.2.2 of 349 [ICE-BIS]. 351 6. Receipt of the Initial Answer 353 When ICE is used with SIP, forking may result in a single offer 354 generating a multiplicity of answers. In that case, ICE proceeds 355 completely in parallel and independently for each answer, treating 356 the combination of its offer and each answer as an independent offer/ 357 answer exchange, with its own set of pairs, check lists, states, and 358 so on. The only case in which processing of one pair impacts another 359 is freeing of candidates, discussed below in Section 8.2. 361 On receiving the SDP answer , the offerer performs steps similar to 362 answerer's processing of the offer. The offerer verifies the 363 answerer's ICE support, determines its role and processes the 364 answerer's candidates to schedule the connectivity checks as defined 365 in section 5 of [ICE-BIS]. 367 6.1. Verifying ICE Support 369 The logic at the offerer is identical to that of the answerer as 370 described in section 5.1.1 of [ICE-BIS], with the exception that an 371 offerer would not ever generate a=ice-mismatch attributes in an SDP. 373 In some cases, the answer may omit a=candidate attributes for the 374 media streams, and instead include an a=ice-mismatch attribute for 375 one or more of the media streams in the SDP. This signals to the 376 offerer that the answerer supports ICE, but that ICE processing was 377 not used for the session because a signaling intermediary modified 378 the default destination for media components without modifying the 379 corresponding candidate attributes. See Section 16.2.2 for a 380 discussion of cases where this can happen. This specification 381 provides no guidance on how an agent should proceed in such a failure 382 case. 384 7. Performing Connectivity Checks 386 The possibility for role conflicts described in Section 6.2.1.1 of 387 [ICE-BIS] applies to this usage and hence all full agents MUST 388 implement the role conflict repairing mechanism. Also both full and 389 lite agents MUST utilize the ICE-CONTROLLED and ICE-CONTROLLING 390 attributes as described in Section 6.1.2.2 of [ICE-BIS]. 392 8. Concluding ICE 394 Once all of the media streams are completed, the controlling endpoint 395 sends an updated offer if the transport destination in the "m=" and 396 "c=" lines for the media stream (called the DEFAULT CANDIDATES) don't 397 match ICE's SELECTED CANDIDATES. 399 8.1. Procedures for Full Implementations 401 8.1.1. Updating states 403 Once the state of each check list is Completed, If an agent is 404 controlling, it examines the highest-priority nominated candidate 405 pair for each component of each media stream. If any of those 406 candidate pairs differ from the default candidate pairs in the most 407 recent offer/answer exchange, the controlling agent MUST generate an 408 updated offer as described in Section 10. 410 8.2. Freeing Candidates 412 8.2.1. Full Implementation Procedures 414 When ICE is used with SIP, and an offer is forked to multiple 415 recipients, ICE proceeds in parallel and independently with each 416 answerer, all using the same local candidates. Once ICE processing 417 has reached the Completed state for all peers for media streams using 418 those candidates, the agent SHOULD wait an additional three seconds, 419 and then it MAY cease responding to checks or generating triggered 420 checks on that candidate. It MAY free the candidate at that time. 421 Freeing of server reflexive candidates is never explicit; it happens 422 by lack of a keepalive. The three-second delay handles cases when 423 aggressive nomination is used, and the selected pairs can quickly 424 change after ICE has completed. 426 9. Grammar 428 This specification defines eight new SDP attributes -- the 429 "candidate", "remote-candidates", "ice-lite", "ice-mismatch", "ice- 430 ufrag", "ice-pwd", "ice-pacing", and "ice-options" attributes. 432 9.1. "candidate" Attribute 434 The candidate attribute is a media-level attribute only. It contains 435 a transport address for a candidate that can be used for connectivity 436 checks. 438 The syntax of this attribute is defined using Augmented BNF as 439 defined in [RFC5234]: 441 candidate-attribute = "candidate" ":" foundation SP component-id SP 442 transport SP 443 priority SP 444 connection-address SP ;from RFC 4566 445 port ;port from RFC 4566 446 SP cand-type 447 [SP rel-addr] 448 [SP rel-port] 449 *(SP extension-att-name SP 450 extension-att-value) 452 foundation = 1*32ice-char 453 component-id = 1*5DIGIT 454 transport = "UDP" / transport-extension 455 transport-extension = token ; from RFC 3261 456 priority = 1*10DIGIT 457 cand-type = "typ" SP candidate-types 458 candidate-types = "host" / "srflx" / "prflx" / "relay" / token 459 rel-addr = "raddr" SP connection-address 460 rel-port = "rport" SP port 461 extension-att-name = token 462 extension-att-value = *VCHAR 463 ice-char = ALPHA / DIGIT / "+" / "/" 465 This grammar encodes the primary information about a candidate: its 466 IP address, port and transport protocol, and its properties: the 467 foundation, component ID, priority, type, and related transport 468 address: 470 : is taken from RFC 4566 [RFC4566]. It is the 471 IP address of the candidate, allowing for IPv4 addresses, IPv6 472 addresses, and fully qualified domain names (FQDNs). When parsing 473 this field, an agent can differentiate an IPv4 address and an IPv6 474 address by presence of a colon in its value -- the presence of a 475 colon indicates IPv6. An agent MUST ignore candidate lines that 476 include candidates with IP address versions that are not supported 477 or recognized. An IP address SHOULD be used, but an FQDN MAY be 478 used in place of an IP address. In that case, when receiving an 479 offer or answer containing an FQDN in an a=candidate attribute, 480 the FQDN is looked up in the DNS first using an AAAA record 481 (assuming the agent supports IPv6), and if no result is found or 482 the agent only supports IPv4, using an A. If the DNS query 483 returns more than one IP address, one is chosen, and then used for 484 the remainder of ICE processing. 486 : is also taken from RFC 4566 [RFC4566]. It is the port of 487 the candidate. 489 : indicates the transport protocol for the candidate. 490 This specification only defines UDP. However, extensibility is 491 provided to allow for future transport protocols to be used with 492 ICE, such as TCP or the Datagram Congestion Control Protocol 493 (DCCP) [RFC4340]. 495 : is composed of 1 to 32 s. It is an 496 identifier that is equivalent for two candidates that are of the 497 same type, share the same base, and come from the same STUN 498 server. The foundation is used to optimize ICE performance in the 499 Frozen algorithm. 501 : is a positive integer between 1 and 256 that 502 identifies the specific component of the media stream for which 503 this is a candidate. It MUST start at 1 and MUST increment by 1 504 for each component of a particular candidate. For media streams 505 based on RTP, candidates for the actual RTP media MUST have a 506 component ID of 1, and candidates for RTCP MUST have a component 507 ID of 2. See section 11 in [ICE-BIS] for additional discussion on 508 extending ICE to new media streams. 510 : is a positive integer between 1 and (2**31 - 1). 512 : encodes the type of candidate. This specification 513 defines the values "host", "srflx", "prflx", and "relay" for host, 514 server reflexive, peer reflexive, and relayed candidates, 515 respectively. The set of candidate types is extensible for the 516 future. 518 and : convey transport addresses related to the 519 candidate, useful for diagnostics and other purposes. 520 and MUST be present for server reflexive, peer 521 reflexive, and relayed candidates. If a candidate is server or 522 peer reflexive, and are equal to the base 523 for that server or peer reflexive candidate. If the candidate is 524 relayed, and is equal to the mapped address 525 in the Allocate response that provided the client with that 526 relayed candidate (see section Appendix B.3 of [ICE-BIS] for a 527 discussion of its purpose). If the candidate is a host candidate, 528 and MUST be omitted. 530 In some cases, e.g., for privacy reasons, an agent may not want to 531 reveal the related address and port. In this case the address 532 MUST be set to "0.0.0.0" (for IPv4 candidates) or "::" (for IPv6 533 candidates) and the port to zero. 535 The candidate attribute can itself be extended. The grammar allows 536 for new name/value pairs to be added at the end of the attribute. An 537 implementation MUST ignore any name/value pairs it doesn't 538 understand. 540 9.2. "remote-candidates" Attribute 542 The syntax of the "remote-candidates" attribute is defined using 543 Augmented BNF as defined in RFC 5234 [RFC5234]. The remote- 544 candidates attribute is a media-level attribute only. 546 remote-candidate-att = "remote-candidates" ":" remote-candidate 547 0*(SP remote-candidate) 548 remote-candidate = component-ID SP connection-address SP port 550 The attribute contains a connection-address and port for each 551 component. The ordering of components is irrelevant. However, a 552 value MUST be present for each component of a media stream. This 553 attribute MUST be included in an offer by a controlling agent for a 554 media stream that is Completed, and MUST NOT be included in any other 555 case. 557 9.3. "ice-lite" and "ice-mismatch" Attributes 559 The syntax of the "ice-lite" and "ice-mismatch" attributes, both of 560 which are flags, is: 562 ice-lite = "ice-lite" 563 ice-mismatch = "ice-mismatch" 565 "ice-lite" is a session-level attribute only, and indicates that an 566 agent is a lite implementation. "ice-mismatch" is a media-level 567 attribute only, and when present in an answer, indicates that the 568 offer arrived with a default destination for a media component that 569 didn't have a corresponding candidate attribute. 571 9.4. "ice-ufrag" and "ice-pwd" Attributes 573 The "ice-ufrag" and "ice-pwd" attributes convey the username fragment 574 and password used by ICE for message integrity. Their syntax is: 576 ice-pwd-att = "ice-pwd" ":" password 577 ice-ufrag-att = "ice-ufrag" ":" ufrag 578 password = 22*256ice-char 579 ufrag = 4*256ice-char 581 The "ice-pwd" and "ice-ufrag" attributes can appear at either the 582 session-level or media-level. When present in both, the value in the 583 media-level takes precedence. Thus, the value at the session-level 584 is effectively a default that applies to all media streams, unless 585 overridden by a media-level value. Whether present at the session or 586 media-level, there MUST be an ice-pwd and ice-ufrag attribute for 587 each media stream. If two media streams have identical ice-ufrag's, 588 they MUST have identical ice-pwd's. 590 The ice-ufrag and ice-pwd attributes MUST be chosen randomly at the 591 beginning of a session. The ice-ufrag attribute MUST contain at 592 least 24 bits of randomness, and the ice-pwd attribute MUST contain 593 at least 128 bits of randomness. This means that the ice-ufrag 594 attribute will be at least 4 characters long, and the ice-pwd at 595 least 22 characters long, since the grammar for these attributes 596 allows for 6 bits of randomness per character. The attributes MAY be 597 longer than 4 and 22 characters, respectively, of course, up to 256 598 characters. The upper limit allows for buffer sizing in 599 implementations. Its large upper limit allows for increased amounts 600 of randomness to be added over time. For compatibility with the 512 601 character limitation for the STUN username attribute value and for 602 bandwidth conservation considerations, the ice-ufrag attribute MUST 603 NOT be longer than 32 characters when sending, but an implementation 604 MUST accept up to 256 characters when receiving. 606 9.5. "ice-pacing" Attribute 608 The "ice-pacing" attribute indicates the desired connectivity check 609 pacing, in milliseconds, for this agent (see Section 12 of 610 [ICE-BIS]). The syntax is: 612 ice-pacing-att = "ice-pacing" ":" pacing-value 613 pacing-value = 1*10DIGIT 615 9.6. "ice-options" Attribute 617 The "ice-options" attribute is a session- and media-level attribute. 618 It contains a series of tokens that identify the options supported by 619 the agent. Its grammar is: 621 ice-options = "ice-options" ":" ice-option-tag 622 0*(SP ice-option-tag) 623 ice-option-tag = 1*ice-char 625 The existence of an ice-option can indicate that a certain extension 626 is supported by the agent and will be used or that the extension is 627 used only if the other agent is willing to use it too. In order to 628 avoid ambiguity, documents defining new options must indicate which 629 case applies to the defined extensions. 631 10. Subsequent Offer/Answer Exchanges 633 Either agent MAY generate a subsequent offer at any time allowed by 634 RFC 3264 [RFC3264]. The rules in Section 8 will cause the 635 controlling agent to send an updated offer at the conclusion of ICE 636 processing when ICE has selected different candidate pairs from the 637 default pairs. This section defines rules for construction of 638 subsequent offers and answers. 640 Should a subsequent offer be rejected, ICE processing continues as if 641 the subsequent offer had never been made. 643 10.1. Generating the Offer 645 10.1.1. Procedures for All Implementations 647 10.1.1.1. ICE Restarts 649 An agent MAY restart ICE processing for an existing media stream. An 650 ICE restart, as the name implies, will cause all previous states of 651 ICE processing to be flushed and checks to start anew. The only 652 difference between an ICE restart and a brand new media session is 653 that, during the restart, media can continue to be sent to the 654 previously validated pair. 656 An agent MUST restart ICE for a media stream if: 658 o The offer is being generated for the purposes of changing the 659 target of the media stream. In other words, if an agent wants to 660 generate an updated offer that, had ICE not been in use, would 661 result in a new value for the destination of a media component. 663 o An agent is changing its implementation level. This typically 664 only happens in third party call control use cases, where the 665 entity performing the signaling is not the entity receiving the 666 media, and it has changed the target of media mid-session to 667 another entity that has a different ICE implementation. 669 These rules imply that setting the IP address in the "c=" line to 670 0.0.0.0 will cause an ICE restart. Consequently, ICE implementations 671 MUST NOT utilize this mechanism for call hold, and instead MUST use 672 a=inactive and a=sendonly as described in [RFC3264]. 674 To restart ICE, an agent MUST change both the ice-pwd and the ice- 675 ufrag for the media stream in an offer. Note that it is permissible 676 to use a session-level attribute in one offer, but to provide the 677 same ice-pwd or ice-ufrag as a media-level attribute in a subsequent 678 offer. This is not a change in password, just a change in its 679 representation, and does not cause an ICE restart. 681 An agent sets the rest of the fields in the SDP for this media stream 682 as it would in an initial offer of this media stream (see 683 Section 4.2). Consequently, the set of candidates MAY include some, 684 none, or all of the previous candidates for that stream and MAY 685 include a totally new set of candidates. 687 10.1.1.2. Removing a Media Stream 689 If an agent removes a media stream by setting its port to zero, it 690 MUST NOT include any candidate attributes for that media stream and 691 SHOULD NOT include any other ICE-related attributes defined in 692 Section 9 for that media stream. 694 10.1.1.3. Adding a Media Stream 696 If an agent wishes to add a new media stream, it sets the fields in 697 the SDP for this media stream as if this was an initial offer for 698 that media stream (see Section 4.2). This will cause ICE processing 699 to begin for this media stream. 701 10.1.2. Procedures for Full Implementations 703 This section describes additional procedures for full 704 implementations, covering existing media streams. 706 The username fragments, password, and implementation level MUST 707 remain the same as used previously. If an agent needs to change one 708 of these, it MUST restart ICE for that media stream. 710 Additional behavior depends on the state ICE processing for that 711 media stream. 713 10.1.2.1. Existing Media Streams with ICE Running 715 If an agent generates an updated offer including a media stream that 716 was previously established, and for which ICE checks are in the 717 Running state, the agent follows the procedures defined here. 719 An agent MUST include candidate attributes for all local candidates 720 it had signaled previously for that media stream. The properties of 721 that candidate as signaled in SDP -- the priority, foundation, type, 722 and related transport address -- SHOULD remain the same. The IP 723 address, port, and transport protocol, which fundamentally identify 724 that candidate, MUST remain the same (if they change, it would be a 725 new candidate). The component ID MUST remain the same. The agent 726 MAY include additional candidates it did not offer previously, but 727 which it has gathered since the last offer/answer exchange, including 728 peer reflexive candidates. 730 The agent MAY change the default destination for media. As with 731 initial offers, there MUST be a set of candidate attributes in the 732 offer matching this default destination. 734 10.1.2.2. Existing Media Streams with ICE Completed 736 If an agent generates an updated offer including a media stream that 737 was previously established, and for which ICE checks are in the 738 Completed state, the agent follows the procedures defined here. 740 The default destination for media (i.e., the values of the IP 741 addresses and ports in the "m=" and "c=" lines used for that media 742 stream) MUST be the local candidate from the highest-priority 743 nominated pair in the valid list for each component. This "fixes" 744 the default destination for media to equal the destination ICE has 745 selected for media. 747 The agent MUST include candidate attributes for candidates matching 748 the default destination for each component of the media stream, and 749 MUST NOT include any other candidates. 751 In addition, if the agent is controlling, it MUST include the 752 a=remote-candidates attribute for each media stream whose check list 753 is in the Completed state. The attribute contains the remote 754 candidates from the highest-priority nominated pair in the valid list 755 for each component of that media stream. It is needed to avoid a 756 race condition whereby the controlling agent chooses its pairs, but 757 the updated offer beats the connectivity checks to the controlled 758 agent, which doesn't even know these pairs are valid, let alone 759 selected. See Appendix B for elaboration on this race condition. 761 10.1.3. Procedures for Lite Implementations 763 10.1.3.1. Existing Media Streams with ICE Running 765 This section describes procedures for lite implementations for 766 existing streams for which ICE is running. 768 A lite implementation MUST include all of its candidates for each 769 component of each media stream in an a=candidate attribute in any 770 subsequent offer. These candidates are formed identically to the 771 procedures for initial offers, as described in section 4.2 of 772 [ICE-BIS]. 774 A lite implementation MUST NOT add additional host candidates in a 775 subsequent offer. If an agent needs to offer additional candidates, 776 it MUST restart ICE. 778 The username fragments, password, and implementation level MUST 779 remain the same as used previously. If an agent needs to change one 780 of these, it MUST restart ICE for that media stream. 782 10.1.3.2. Existing Media Streams with ICE Completed 784 If ICE has completed for a media stream, the default destination for 785 that media stream MUST be set to the remote candidate of the 786 candidate pair for that component in the valid list. For a lite 787 implementation, there is always just a single candidate pair in the 788 valid list for each component of a media stream. Additionally, the 789 agent MUST include a candidate attribute for each default 790 destination. 792 Additionally, if the agent is controlling (which only happens when 793 both agents are lite), the agent MUST include the a=remote-candidates 794 attribute for each media stream. The attribute contains the remote 795 candidates from the candidate pairs in the valid list (one pair for 796 each component of each media stream). 798 10.2. Receiving the Offer and Generating an Answer 800 10.2.1. Procedures for All Implementations 802 When receiving a subsequent offer within an existing session, an 803 agent MUST reapply the verification procedures in Section 5.2 without 804 regard to the results of verification from any previous offer/answer 805 exchanges. Indeed, it is possible that a previous offer/answer 806 exchange resulted in ICE not being used, but it is used as a 807 consequence of a subsequent exchange. 809 10.2.1.1. Detecting ICE Restart 811 If the offer contained a change in the a=ice-ufrag or a=ice-pwd 812 attributes compared to the previous SDP from the peer, it indicates 813 that ICE is restarting for this media stream. If all media streams 814 are restarting, then ICE is restarting overall. 816 If ICE is restarting for a media stream: 818 o The agent MUST change the a=ice-ufrag and a=ice-pwd attributes in 819 the answer. 821 o The agent MAY change its implementation level in the answer. 823 An agent sets the rest of the fields in the SDP for this media stream 824 as it would in an initial answer to this media stream (see 825 Section 4.2). Consequently, the set of candidates MAY include some, 826 none, or all of the previous candidates for that stream and MAY 827 include a totally new set of candidates. 829 10.2.1.2. New Media Stream 831 If the offer contains a new media stream, the agent sets the fields 832 in the answer as if it had received an initial offer containing that 833 media stream (see Section 4.2). This will cause ICE processing to 834 begin for this media stream. 836 10.2.1.3. Removed Media Stream 838 If an offer contains a media stream whose port is zero, the agent 839 MUST NOT include any candidate attributes for that media stream in 840 its answer and SHOULD NOT include any other ICE-related attributes 841 defined in Section 9 for that media stream. 843 10.2.2. Procedures for Full Implementations 845 Unless the agent has detected an ICE restart from the offer, the 846 username fragments, password, and implementation level MUST remain 847 the same as used previously. If an agent needs to change one of 848 these it MUST restart ICE for that media stream by generating an 849 offer; ICE cannot be restarted in an answer. 851 Additional behaviors depend on the state of ICE processing for that 852 media stream. 854 10.2.2.1. Existing Media Streams with ICE Running and no remote- 855 candidates 857 If ICE is running for a media stream, and the offer for that media 858 stream lacked the remote-candidates attribute, the rules for 859 construction of the answer are identical to those for the offerer as 860 described in Section 10.1.2.1. 862 10.2.2.2. Existing Media Streams with ICE Completed and no remote- 863 candidates 865 If ICE is Completed for a media stream, and the offer for that media 866 stream lacked the remote-candidates attribute, the rules for 867 construction of the answer are identical to those for the offerer as 868 described in Section 10.1.2.2, except that the answerer MUST NOT 869 include the a=remote-candidates attribute in the answer. 871 10.2.2.3. Existing Media Streams and remote-candidates 873 A controlled agent will receive an offer with the a=remote-candidates 874 attribute for a media stream when its peer has concluded ICE 875 processing for that media stream. This attribute is present in the 876 offer to deal with a race condition between the receipt of the offer, 877 and the receipt of the Binding response that tells the answerer the 878 candidate that will be selected by ICE. See Appendix B for an 879 explanation of this race condition. Consequently, processing of an 880 offer with this attribute depends on the winner of the race. 882 The agent forms a candidate pair for each component of the media 883 stream by: 885 o Setting the remote candidate equal to the offerer's default 886 destination for that component (e.g., the contents of the "m=" and 887 "c=" lines for RTP, and the a=rtcp attribute for RTCP) 889 o Setting the local candidate equal to the transport address for 890 that same component in the a=remote-candidates attribute in the 891 offer. 893 The agent then sees if each of these candidate pairs is present in 894 the valid list. If a particular pair is not in the valid list, the 895 check has "lost" the race. Call such a pair a "losing pair". 897 The agent finds all the pairs in the check list whose remote 898 candidates equal the remote candidate in the losing pair: 900 o If none of the pairs are In-Progress, and at least one is Failed, 901 it is most likely that a network failure, such as a network 902 partition or serious packet loss, has occurred. The agent SHOULD 903 generate an answer for this media stream as if the remote- 904 candidates attribute had not been present, and then restart ICE 905 for this stream. 907 o If at least one of the pairs is In-Progress, the agent SHOULD wait 908 for those checks to complete, and as each completes, redo the 909 processing in this section until there are no losing pairs. 911 Once there are no losing pairs, the agent can generate the answer. 912 It MUST set the default destination for media to the candidates in 913 the remote-candidates attribute from the offer (each of which will 914 now be the local candidate of a candidate pair in the valid list). 915 It MUST include a candidate attribute in the answer for each 916 candidate in the remote-candidates attribute in the offer. 918 10.2.3. Procedures for Lite Implementations 920 If the received offer contains the remote-candidates attribute for a 921 media stream, the agent forms a candidate pair for each component of 922 the media stream by: 924 o Setting the remote candidate equal to the offerer's default 925 destination for that component (e.g., the contents of the "m=" and 926 "c=" lines for RTP, and the a=rtcp attribute for RTCP). 928 o Setting the local candidate equal to the transport address for 929 that same component in the a=remote-candidates attribute in the 930 offer. 932 It then places those candidates into the Valid list for the media 933 stream. The state of ICE processing for that media stream is set to 934 Completed. 936 Furthermore, if the agent believed it was controlling, but the offer 937 contained the remote-candidates attribute, both agents believe they 938 are controlling. In this case, both would have sent updated offers 939 around the same time. However, the signaling protocol carrying the 940 offer/answer exchanges will have resolved this glare condition, so 941 that one agent is always the 'winner' by having its offer received 942 before its peer has sent an offer. The winner takes the role of 943 controlled, so that the loser (the answerer under consideration in 944 this section) MUST change its role to controlled. Consequently, if 945 the agent was going to send an updated offer since, based on the 946 rules in section 7.2 of [ICE-BIS], it was controlling, it no longer 947 needs to. 949 Besides the potential role change, change in the Valid list, and 950 state changes, the construction of the answer is performed 951 identically to the construction of an offer as described in 952 Section 10.1.3. 954 10.3. Receiving the Answer for a Subsequent Offer 956 Some deployments of ICE include e.g. SDP-Modifying Signaling-only 957 Back-to-Back User Agents (B2BUAs) [RFC7092] that modify the SDP body 958 during the subsequent offer/answer exchange. With the B2BUA being 959 ICE-unaware a subsequent answer might be manipulated and might not 960 include ICE candidates although the initial answer did. 962 An example of a situation where such an "unexpected" answer might be 963 experienced appears when such a B2BUA introduces a media server 964 during call hold using 3rd party call-control procedures. Omitting 965 further details how this is done this could result in an answer being 966 received at the holding UA that was constructed by the B2BUA. With 967 the B2BUA being ICE-unaware that answer would not include ICE 968 candidates. 970 Receiving an answer without ICE attributes in this situation might be 971 unexpected, but would not necessarily impair the user experience. 973 In addition to procedures for the expected answer, the following 974 sections advice on how to recover from the unexpected situation. 976 10.3.1. Procedures for All Implementations 978 When receiving an answer within an existing session for a subsequent 979 offer as specified in Section 10.1.2.2, an agent MUST verify ICE 980 support as specified in Section 6.1. 982 10.3.1.1. ICE Restarts 984 If ICE support is indicated in the SDP answer, the agent MUST perform 985 ICE restart procedures as specified in Section 10.4. 987 If ICE support is no longer indicated in the SDP answer, the agent 988 MUST fall-back to RFC 3264 procedures and SHOULD NOT drop the dialog 989 just because of missing ICE support. If the agent sends a new offer 990 later on it SHOULD perform an ICE restart as specified in 991 Section 10.1.1.1. 993 10.3.1.2. Existing Media Streams with ICE Running 995 If ICE support is indicated in the SDP answer, the agent MUST 996 continue ICE procedures as specified in Section 10.4.1.4. 998 If ICE support is no longer indicated in the SDP answer, the agent 999 MUST abort the ongoing ICE processing and fall-back to RFC 3264 1000 procedures. The agent SHOULD NOT drop the dialog just because of 1001 missing ICE support. If the agent sends a new offer later on, it 1002 SHOULD perform an ICE restart as specified in Section 10.1.1.1. 1004 10.3.1.3. Existing Media Streams with ICE Completed 1006 If ICE support is indicated in the SDP answer and if the answer 1007 conforms to Section 10.2.2.3, the agent MUST remain in the ICE 1008 Completed state. 1010 If ICE support is no longer indicated in the SDP answer, the agent 1011 MUST fall-back to RFC 3264 procedures and SHOULD NOT drop the dialog 1012 just because of this unexpected answer. Once the agent sends a new 1013 offer later on it MUST perform an ICE restart. 1015 10.4. Updating the Check and Valid Lists 1017 10.4.1. Procedures for Full Implementations 1019 10.4.1.1. ICE Restarts 1021 The agent MUST remember the highest-priority nominated pairs in the 1022 Valid list for each component of the media stream, called the 1023 previous selected pairs, prior to the restart. The agent will 1024 continue to send media using these pairs, as described in 1025 Section 12.1. Once these destinations are noted, the agent MUST 1026 flush the valid and check lists, and then recompute the check list 1027 and its states as described in section 5.1.3 of [ICE-BIS]. 1029 10.4.1.2. New Media Stream 1031 If the offer/answer exchange added a new media stream, the agent MUST 1032 create a new check list for it (and an empty Valid list to start of 1033 course), as described in section 5.1.3 of [ICE-BIS]. 1035 10.4.1.3. Removed Media Stream 1037 If the offer/answer exchange removed a media stream, or an answer 1038 rejected an offered media stream, an agent MUST flush the Valid list 1039 for that media stream. It MUST terminate any STUN transactions in 1040 progress for that media stream. An agent MUST remove the check list 1041 for that media stream and cancel any pending ordinary checks for it. 1043 10.4.1.4. ICE Continuing for Existing Media Stream 1045 The valid list is not affected by an updated offer/answer exchange 1046 unless ICE is restarting. 1048 If an agent is in the Running state for that media stream, the check 1049 list is updated (the check list is irrelevant if the state is 1050 completed). To do that, the agent recomputes the check list using 1051 the procedures described in section 5.1.3 of [ICE-BIS]. If a pair on 1052 the new check list was also on the previous check list, and its state 1053 was Waiting, In-Progress, Succeeded, or Failed, its state is copied 1054 over. Otherwise, its state is set to Frozen. 1056 If none of the check lists are active (meaning that the pairs in each 1057 check list are Frozen), the full-mode agent sets the first pair in 1058 the check list for the first media stream to Waiting, and then sets 1059 the state of all other pairs in that check list for the same 1060 component ID and with the same foundation to Waiting as well. 1062 Next, the agent goes through each check list, starting with the 1063 highest-priority pair. If a pair has a state of Succeeded, and it 1064 has a component ID of 1, then all Frozen pairs in the same check list 1065 with the same foundation whose component IDs are not 1 have their 1066 state set to Waiting. If, for a particular check list, there are 1067 pairs for each component of that media stream in the Succeeded state, 1068 the agent moves the state of all Frozen pairs for the first component 1069 of all other media streams (and thus in different check lists) with 1070 the same foundation to Waiting. 1072 10.4.2. Procedures for Lite Implementations 1074 If ICE is restarting for a media stream, the agent MUST start a new 1075 Valid list for that media stream. It MUST remember the pairs in the 1076 previous Valid list for each component of the media stream, called 1077 the previous selected pairs, and continue to send media there as 1078 described in Section 12.1. The state of ICE processing for each 1079 media stream MUST change to Running, and the state of ICE processing 1080 MUST change to Running. 1082 11. Keepalives 1084 The procedures defined in Section 9 of [ICE-BIS] MUST be followed. 1085 The keepalives MUST be sent regardless of whether the media stream is 1086 currently inactive, sendonly, recvonly, or sendrecv, and regardless 1087 of the presence or value of the bandwidth attribute. An agent can 1088 determine that its peer supports ICE by the presence of a=candidate 1089 attributes for each media session. 1091 12. Media Handling 1093 12.1. Sending Media 1095 Note that the selected pair for a component of a media stream may not 1096 equal the default pair for that same component from the most recent 1097 offer/answer exchange. When this happens, the selected pair is used 1098 for media, not the default pair. When ICE first completes, if the 1099 selected pairs aren't a match for the default pairs, the controlling 1100 agent sends an updated offer/answer exchange to remedy this 1101 disparity. However, until that updated offer arrives, there will not 1102 be a match. Furthermore, in very unusual cases, the default 1103 candidates in the updated offer/answer will not be a match. 1105 12.1.1. Procedures for All Implementations 1107 Section 10.1.3 of [ICE-BIS] defines procedures for sending media 1108 common across Full and Lite implementations. 1110 12.2. Receiving Media 1112 See Section 10.2 of [ICE-BIS] for procedures on receiving media. 1114 13. Usage with SIP 1116 13.1. Latency Guidelines 1118 ICE requires a series of STUN-based connectivity checks to take place 1119 between endpoints. These checks start from the answerer on 1120 generation of its answer, and start from the offerer when it receives 1121 the answer. These checks can take time to complete, and as such, the 1122 selection of messages to use with offers and answers can affect 1123 perceived user latency. Two latency figures are of particular 1124 interest. These are the post-pickup delay and the post-dial delay. 1125 The post-pickup delay refers to the time between when a user "answers 1126 the phone" and when any speech they utter can be delivered to the 1127 caller. The post-dial delay refers to the time between when a user 1128 enters the destination address for the user and ringback begins as a 1129 consequence of having successfully started ringing the phone of the 1130 called party. 1132 Two cases can be considered -- one where the offer is present in the 1133 initial INVITE and one where it is in a response. 1135 13.1.1. Offer in INVITE 1137 To reduce post-dial delays, it is RECOMMENDED that the caller begin 1138 gathering candidates prior to actually sending its initial INVITE. 1139 This can be started upon user interface cues that a call is pending, 1140 such as activity on a keypad or the phone going off-hook. 1142 If an offer is received in an INVITE request, the answerer SHOULD 1143 begin to gather its candidates on receipt of the offer and then 1144 generate an answer in a provisional response once it has completed 1145 that process. ICE requires that a provisional response with an SDP 1146 be transmitted reliably. This can be done through the existing 1147 Provisional Response Acknowledgment (PRACK) mechanism [RFC3262] or 1148 through an optimization that is specific to ICE. With this 1149 optimization, provisional responses containing an SDP answer that 1150 begins ICE processing for one or more media streams can be sent 1151 reliably without RFC 3262. To do this, the agent retransmits the 1152 provisional response with the exponential backoff timers described in 1153 RFC 3262. Retransmits MUST cease on receipt of a STUN Binding 1154 request for one of the media streams signaled in that SDP (because 1155 receipt of a Binding request indicates the offerer has received the 1156 answer) or on transmission of the answer in a 2xx response. If the 1157 peer agent is lite, there will never be a STUN Binding request. In 1158 such a case, the agent MUST cease retransmitting the 18x after 1159 sending it four times (ICE will actually work even if the peer never 1160 receives the 18x; however, experience has shown that sending it is 1161 important for middleboxes and firewall traversal). If no Binding 1162 request is received prior to the last retransmit, the agent does not 1163 consider the session terminated. Despite the fact that the 1164 provisional response will be delivered reliably, the rules for when 1165 an agent can send an updated offer or answer do not change from those 1166 specified in RFC 3262. Specifically, if the INVITE contained an 1167 offer, the same answer appears in all of the 1xx and in the 2xx 1168 response to the INVITE. Only after that 2xx has been sent can an 1169 updated offer/answer exchange occur. This optimization SHOULD NOT be 1170 used if both agents support PRACK. Note that the optimization is 1171 very specific to provisional response carrying answers that start ICE 1172 processing; it is not a general technique for 1xx reliability. 1174 Alternatively, an agent MAY delay sending an answer until the 200 OK; 1175 however, this results in a poor user experience and is NOT 1176 RECOMMENDED. 1178 Once the answer has been sent, the agent SHOULD begin its 1179 connectivity checks. Once candidate pairs for each component of a 1180 media stream enter the valid list, the answerer can begin sending 1181 media on that media stream. 1183 However, prior to this point, any media that needs to be sent towards 1184 the caller (such as SIP early media [RFC3960]) MUST NOT be 1185 transmitted. For this reason, implementations SHOULD delay alerting 1186 the called party until candidates for each component of each media 1187 stream have entered the valid list. In the case of a PSTN gateway, 1188 this would mean that the setup message into the PSTN is delayed until 1189 this point. Doing this increases the post-dial delay, but has the 1190 effect of eliminating 'ghost rings'. Ghost rings are cases where the 1191 called party hears the phone ring, picks up, but hears nothing and 1192 cannot be heard. This technique works without requiring support for, 1193 or usage of, preconditions [RFC3312], since it's a localized 1194 decision. It also has the benefit of guaranteeing that not a single 1195 packet of media will get clipped, so that post-pickup delay is zero. 1196 If an agent chooses to delay local alerting in this way, it SHOULD 1197 generate a 180 response once alerting begins. 1199 13.1.2. Offer in Response 1201 In addition to uses where the offer is in an INVITE, and the answer 1202 is in the provisional and/or 200 OK response, ICE works with cases 1203 where the offer appears in the response. In such cases, which are 1204 common in third party call control [RFC3725], ICE agents SHOULD 1205 generate their offers in a reliable provisional response (which MUST 1206 utilize RFC 3262), and not alert the user on receipt of the INVITE. 1207 The answer will arrive in a PRACK. This allows for ICE processing to 1208 take place prior to alerting, so that there is no post-pickup delay, 1209 at the expense of increased call setup delays. Once ICE completes, 1210 the callee can alert the user and then generate a 200 OK when they 1211 answer. The 200 OK would contain no SDP, since the offer/answer 1212 exchange has completed. 1214 Alternatively, agents MAY place the offer in a 2xx instead (in which 1215 case the answer comes in the ACK). When this happens, the callee 1216 will alert the user on receipt of the INVITE, and the ICE exchanges 1217 will take place only after the user answers. This has the effect of 1218 reducing call setup delay, but can cause substantial post-pickup 1219 delays and media clipping. 1221 13.2. SIP Option Tags and Media Feature Tags 1223 [RFC5768] specifies a SIP option tag and media feature tag for usage 1224 with ICE. ICE implementations using SIP SHOULD support this 1225 specification, which uses a feature tag in registrations to 1226 facilitate interoperability through signaling intermediaries. 1228 13.3. Interactions with Forking 1230 ICE interacts very well with forking. Indeed, ICE fixes some of the 1231 problems associated with forking. Without ICE, when a call forks and 1232 the caller receives multiple incoming media streams, it cannot 1233 determine which media stream corresponds to which callee. 1235 With ICE, this problem is resolved. The connectivity checks which 1236 occur prior to transmission of media carry username fragments, which 1237 in turn are correlated to a specific callee. Subsequent media 1238 packets that arrive on the same candidate pair as the connectivity 1239 check will be associated with that same callee. Thus, the caller can 1240 perform this correlation as long as it has received an answer. 1242 13.4. Interactions with Preconditions 1244 Quality of Service (QoS) preconditions, which are defined in RFC 3312 1245 [RFC3312] and RFC 4032 [RFC4032], apply only to the transport 1246 addresses listed as the default targets for media in an offer/answer. 1247 If ICE changes the transport address where media is received, this 1248 change is reflected in an updated offer that changes the default 1249 destination for media to match ICE's selection. As such, it appears 1250 like any other re-INVITE would, and is fully treated in RFCs 3312 and 1251 4032, which apply without regard to the fact that the destination for 1252 media is changing due to ICE negotiations occurring "in the 1253 background". 1255 Indeed, an agent SHOULD NOT indicate that QoS preconditions have been 1256 met until the checks have completed and selected the candidate pairs 1257 to be used for media. 1259 ICE also has (purposeful) interactions with connectivity 1260 preconditions [RFC5898]. Those interactions are described there. 1261 Note that the procedures described in Section 13.1 describe their own 1262 type of "preconditions", albeit with less functionality than those 1263 provided by the explicit preconditions in [RFC5898]. 1265 13.5. Interactions with Third Party Call Control 1267 ICE works with Flows I, III, and IV as described in [RFC3725]. Flow 1268 I works without the controller supporting or being aware of ICE. 1269 Flow IV will work as long as the controller passes along the ICE 1270 attributes without alteration. Flow II is fundamentally incompatible 1271 with ICE; each agent will believe itself to be the answerer and thus 1272 never generate a re-INVITE. 1274 The flows for continued operation, as described in Section 7 of RFC 1275 3725, require additional behavior of ICE implementations to support. 1277 In particular, if an agent receives a mid-dialog re-INVITE that 1278 contains no offer, it MUST restart ICE for each media stream and go 1279 through the process of gathering new candidates. Furthermore, that 1280 list of candidates SHOULD include the ones currently being used for 1281 media. 1283 14. Relationship with ANAT 1285 RFC 4091 [RFC4091], the Alternative Network Address Types (ANAT) 1286 Semantics for the SDP grouping framework, and RFC 4092 [RFC4092], its 1287 usage with SIP, define a mechanism for indicating that an agent can 1288 support both IPv4 and IPv6 for a media stream, and it does so by 1289 including two "m=" lines, one for v4 and one for v6. This is similar 1290 to ICE, which allows for an agent to indicate multiple transport 1291 addresses using the candidate attribute. However, ANAT relies on 1292 static selection to pick between choices, rather than a dynamic 1293 connectivity check used by ICE. 1295 This specification deprecates RFC 4091 and RFC 4092. Instead, agents 1296 wishing to support dual-stack will utilize ICE. 1298 15. Setting Ta and RTO for RTP Media Streams 1300 During the gathering phase of ICE (section 4.1.1 [ICE-BIS]) and while 1301 ICE is performing connectivity checks (section 6 [ICE-BIS]), an agent 1302 sends STUN and TURN transactions. These transactions are paced at a 1303 rate of one every Ta milliseconds, and utilize a specific RTO. See 1304 Section 12.1 of [ICE-BIS] for details on how the values of Ta and RTO 1305 are computed with a real-time media stream of known maximum bandwidth 1306 to rate-control the ICE exchanges. 1308 16. Security Considerations 1310 16.1. Attacks on the Offer/Answer Exchanges 1312 An attacker that can modify or disrupt the offer/answer exchanges 1313 themselves can readily launch a variety of attacks with ICE. They 1314 could direct media to a target of a DoS attack, they could insert 1315 themselves into the media stream, and so on. These are similar to 1316 the general security considerations for offer/answer exchanges, and 1317 the security considerations in RFC 3264 [RFC3264] apply. These 1318 require techniques for message integrity and encryption for offers 1319 and answers, which are satisfied by the SIPS mechanism [RFC3261] when 1320 SIP is used. As such, the usage of SIPS with ICE is RECOMMENDED. 1322 16.2. Insider Attacks 1324 In addition to attacks where the attacker is a third party trying to 1325 insert fake offers, answers, or stun messages, there are several 1326 attacks possible with ICE when the attacker is an authenticated and 1327 valid participant in the ICE exchange. 1329 16.2.1. The Voice Hammer Attack 1331 The voice hammer attack is an amplification attack. In this attack, 1332 the attacker initiates sessions to other agents, and maliciously 1333 includes the IP address and port of a DoS target as the destination 1334 for media traffic signaled in the SDP. This causes substantial 1335 amplification; a single offer/answer exchange can create a continuing 1336 flood of media packets, possibly at high rates (consider video 1337 sources). This attack is not specific to ICE, but ICE can help 1338 provide remediation. 1340 Specifically, if ICE is used, the agent receiving the malicious SDP 1341 will first perform connectivity checks to the target of media before 1342 sending media there. If this target is a third-party host, the 1343 checks will not succeed, and media is never sent. 1345 Unfortunately, ICE doesn't help if its not used, in which case an 1346 attacker could simply send the offer without the ICE parameters. 1347 However, in environments where the set of clients is known, and is 1348 limited to ones that support ICE, the server can reject any offers or 1349 answers that don't indicate ICE support. 1351 16.2.2. Interactions with Application Layer Gateways and SIP 1353 Application Layer Gateways (ALGs) are functions present in a NAT 1354 device that inspect the contents of packets and modify them, in order 1355 to facilitate NAT traversal for application protocols. Session 1356 Border Controllers (SBCs) are close cousins of ALGs, but are less 1357 transparent since they actually exist as application layer SIP 1358 intermediaries. ICE has interactions with SBCs and ALGs. 1360 If an ALG is SIP aware but not ICE aware, ICE will work through it as 1361 long as the ALG correctly modifies the SDP. A correct ALG 1362 implementation behaves as follows: 1364 o The ALG does not modify the "m=" and "c=" lines or the rtcp 1365 attribute if they contain external addresses. 1367 o If the "m=" and "c=" lines contain internal addresses, the 1368 modification depends on the state of the ALG: 1370 If the ALG already has a binding established that maps an 1371 external port to an internal IP address and port matching the 1372 values in the "m=" and "c=" lines or rtcp attribute, the ALG 1373 uses that binding instead of creating a new one. 1375 If the ALG does not already have a binding, it creates a new 1376 one and modifies the SDP, rewriting the "m=" and "c=" lines and 1377 rtcp attribute. 1379 Unfortunately, many ALGs are known to work poorly in these corner 1380 cases. ICE does not try to work around broken ALGs, as this is 1381 outside the scope of its functionality. ICE can help diagnose these 1382 conditions, which often show up as a mismatch between the set of 1383 candidates and the "m=" and "c=" lines and rtcp attributes. The ice- 1384 mismatch attribute is used for this purpose. 1386 ICE works best through ALGs when the signaling is run over TLS. This 1387 prevents the ALG from manipulating the SDP messages and interfering 1388 with ICE operation. Implementations that are expected to be deployed 1389 behind ALGs SHOULD provide for TLS transport of the SDP. 1391 If an SBC is SIP aware but not ICE aware, the result depends on the 1392 behavior of the SBC. If it is acting as a proper Back-to-Back User 1393 Agent (B2BUA), the SBC will remove any SDP attributes it doesn't 1394 understand, including the ICE attributes. Consequently, the call 1395 will appear to both endpoints as if the other side doesn't support 1396 ICE. This will result in ICE being disabled, and media flowing 1397 through the SBC, if the SBC has requested it. If, however, the SBC 1398 passes the ICE attributes without modification, yet modifies the 1399 default destination for media (contained in the "m=" and "c=" lines 1400 and rtcp attribute), this will be detected as an ICE mismatch, and 1401 ICE processing is aborted for the call. It is outside of the scope 1402 of ICE for it to act as a tool for "working around" SBCs. If one is 1403 present, ICE will not be used and the SBC techniques take precedence. 1405 17. IANA Considerations 1407 17.1. SDP Attributes 1409 Original ICE specification defined seven new SDP attributes per the 1410 procedures of Section 8.2.4 of [RFC4566]. The registration 1411 information is reproduced here. 1413 17.1.1. candidate Attribute 1415 Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. 1417 Attribute Name: candidate 1418 Long Form: candidate 1420 Type of Attribute: media-level 1422 Charset Considerations: The attribute is not subject to the charset 1423 attribute. 1425 Purpose: This attribute is used with Interactive Connectivity 1426 Establishment (ICE), and provides one of many possible candidate 1427 addresses for communication. These addresses are validated with 1428 an end-to-end connectivity check using Session Traversal Utilities 1429 for NAT (STUN). 1431 Appropriate Values: See Section 9 of RFC XXXX. 1433 17.1.2. remote-candidates Attribute 1435 Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. 1437 Attribute Name: remote-candidates 1439 Long Form: remote-candidates 1441 Type of Attribute: media-level 1443 Charset Considerations: The attribute is not subject to the charset 1444 attribute. 1446 Purpose: This attribute is used with Interactive Connectivity 1447 Establishment (ICE), and provides the identity of the remote 1448 candidates that the offerer wishes the answerer to use in its 1449 answer. 1451 Appropriate Values: See Section 9 of RFC XXXX. 1453 17.1.3. ice-lite Attribute 1455 Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. 1457 Attribute Name: ice-lite 1459 Long Form: ice-lite 1461 Type of Attribute: session-level 1463 Charset Considerations: The attribute is not subject to the charset 1464 attribute. 1466 Purpose: This attribute is used with Interactive Connectivity 1467 Establishment (ICE), and indicates that an agent has the minimum 1468 functionality required to support ICE inter-operation with a peer 1469 that has a full implementation. 1471 Appropriate Values: See Section 9 of RFC XXXX. 1473 17.1.4. ice-mismatch Attribute 1475 Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. 1477 Attribute Name: ice-mismatch 1479 Long Form: ice-mismatch 1481 Type of Attribute: session-level 1483 Charset Considerations: The attribute is not subject to the charset 1484 attribute. 1486 Purpose: This attribute is used with Interactive Connectivity 1487 Establishment (ICE), and indicates that an agent is ICE capable, 1488 but did not proceed with ICE due to a mismatch of candidates with 1489 the default destination for media signaled in the SDP. 1491 Appropriate Values: See Section 9 of RFC XXXX. 1493 17.1.5. ice-pwd Attribute 1495 Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. 1497 Attribute Name: ice-pwd 1499 Long Form: ice-pwd 1501 Type of Attribute: session- or media-level 1503 Charset Considerations: The attribute is not subject to the charset 1504 attribute. 1506 Purpose: This attribute is used with Interactive Connectivity 1507 Establishment (ICE), and provides the password used to protect 1508 STUN connectivity checks. 1510 Appropriate Values: See Section 9 of RFC XXXX. 1512 17.1.6. ice-ufrag Attribute 1514 Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. 1516 Attribute Name: ice-ufrag 1518 Long Form: ice-ufrag 1520 Type of Attribute: session- or media-level 1522 Charset Considerations: The attribute is not subject to the charset 1523 attribute. 1525 Purpose: This attribute is used with Interactive Connectivity 1526 Establishment (ICE), and provides the fragments used to construct 1527 the username in STUN connectivity checks. 1529 Appropriate Values: See Section 9 of RFC XXXX. 1531 17.1.7. ice-pacing Attribute 1533 Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. 1535 Attribute Name: ice-pacing 1537 Long Form: ice-pacing 1539 Type of Attribute: session-level 1541 Charset Considerations: The attribute is not subject to the charset 1542 attribute. 1544 Purpose: This attribute is used with Interactive Connectivity 1545 Establishment (ICE) to indicate desired connectivity check pacing 1546 values. 1548 Appropriate Values: See Section 9 of RFC XXXX. 1550 17.1.8. ice-options Attribute 1552 Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. 1554 Attribute Name: ice-options 1556 Long Form: ice-options 1558 Type of Attribute: session- or media-level 1559 Charset Considerations: The attribute is not subject to the charset 1560 attribute. 1562 Purpose: This attribute is used with Interactive Connectivity 1563 Establishment (ICE), and indicates the ICE options or extensions 1564 used by the agent. 1566 Appropriate Values: See Section 9 of RFC XXXX. 1568 17.2. Interactive Connectivity Establishment (ICE) Options Registry 1570 IANA maintains a registry for ice-options identifiers under the 1571 Specification Required policy as defined in "Guidelines for Writing 1572 an IANA Considerations Section in RFCs" [RFC5226]. 1574 ICE options are of unlimited length according to the syntax in 1575 Section 9.6; however, they are RECOMMENDED to be no longer than 20 1576 characters. This is to reduce message sizes and allow for efficient 1577 parsing. 1579 In RFC 5245 ICE options could only be defined at the session level. 1580 ICE options can now also be defined at the media level. This can be 1581 used when aggregating between different ICE agents in the same 1582 endpoint, but future options may require to be defined at the media- 1583 level. To ensure compatibility with legacy implementation, the 1584 media-level ICE options MUST be aggregated into a session-level ICE 1585 option. Because aggregation rules depend on the specifics of each 1586 option, all new ICE options MUST also define in their specification 1587 how the media-level ICE option values are aggregated to generate the 1588 value of the session-level ICE option. 1590 The only ICE option defined at the time of publication is "rtp+ecn" 1591 [RFC6679]. The aggregation rule for this ICE option is that if all 1592 aggregated media using ICE contain a media-level "rtp+ecn" ICE option 1593 then an "rtp+ecn" ICE option MUST be inserted at the session-level. 1594 If one of the media does not contain the option, then it MUST NOT be 1595 inserted at the session-level. 1597 A registration request MUST include the following information: 1599 o The ICE option identifier to be registered 1601 o Name, Email, and Address of a contact person for the registration 1603 o Organization or individuals having the change control 1605 o Short description of the ICE extension to which the option relates 1606 o Reference(s) to the specification defining the ICE option and the 1607 related extensions 1609 18. Acknowledgments 1611 A large part of the text in this document was taken from RFC 5245, 1612 authored by Jonathan Rosenberg. 1614 Some of the text in this document was taken from RFC 6336, authored 1615 by Magnus Westerlund and Colin Perkins. 1617 Thanks to Thomas Stach for the text in Section 10.3 1619 19. References 1621 19.1. Normative References 1623 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1624 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1625 RFC2119, March 1997, 1626 . 1628 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1629 A., Peterson, J., Sparks, R., Handley, M., and E. 1630 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1631 DOI 10.17487/RFC3261, June 2002, 1632 . 1634 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 1635 Provisional Responses in Session Initiation Protocol 1636 (SIP)", RFC 3262, DOI 10.17487/RFC3262, June 2002, 1637 . 1639 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1640 with Session Description Protocol (SDP)", RFC 3264, DOI 1641 10.17487/RFC3264, June 2002, 1642 . 1644 [RFC3312] Camarillo, G., Ed., Marshall, W., Ed., and J. Rosenberg, 1645 "Integration of Resource Management and Session Initiation 1646 Protocol (SIP)", RFC 3312, DOI 10.17487/RFC3312, October 1647 2002, . 1649 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1650 Jacobson, "RTP: A Transport Protocol for Real-Time 1651 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1652 July 2003, . 1654 [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth 1655 Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 1656 3556, DOI 10.17487/RFC3556, July 2003, 1657 . 1659 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 1660 in Session Description Protocol (SDP)", RFC 3605, DOI 1661 10.17487/RFC3605, October 2003, 1662 . 1664 [RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session 1665 Initiation Protocol (SIP) Preconditions Framework", RFC 1666 4032, DOI 10.17487/RFC4032, March 2005, 1667 . 1669 [RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network 1670 Address Types (ANAT) Semantics for the Session Description 1671 Protocol (SDP) Grouping Framework", RFC 4091, DOI 1672 10.17487/RFC4091, June 2005, 1673 . 1675 [RFC4092] Camarillo, G. and J. Rosenberg, "Usage of the Session 1676 Description Protocol (SDP) Alternative Network Address 1677 Types (ANAT) Semantics in the Session Initiation Protocol 1678 (SIP)", RFC 4092, DOI 10.17487/RFC4092, June 2005, 1679 . 1681 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1682 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1683 July 2006, . 1685 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1686 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1687 DOI 10.17487/RFC5226, May 2008, 1688 . 1690 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1691 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 1692 RFC5234, January 2008, 1693 . 1695 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1696 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1697 DOI 10.17487/RFC5389, October 2008, 1698 . 1700 [RFC5768] Rosenberg, J., "Indicating Support for Interactive 1701 Connectivity Establishment (ICE) in the Session Initiation 1702 Protocol (SIP)", RFC 5768, DOI 10.17487/RFC5768, April 1703 2010, . 1705 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 1706 and K. Carlberg, "Explicit Congestion Notification (ECN) 1707 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 1708 2012, . 1710 [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session 1711 Initiation Protocol (SIP) Back-to-Back User Agents", RFC 1712 7092, DOI 10.17487/RFC7092, December 2013, 1713 . 1715 [ICE-BIS] Keranen, A. and J. Rosenberg, "Interactive Connectivity 1716 Establishment (ICE): A Protocol for Network Address 1717 Translator (NAT) Traversal for Offer/Answer Protocols", 1718 draft-ietf-ice-rfc5245bis-00 (work in progress), March 1719 2015. 1721 19.2. Informative References 1723 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 1724 Camarillo, "Best Current Practices for Third Party Call 1725 Control (3pcc) in the Session Initiation Protocol (SIP)", 1726 BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004, 1727 . 1729 [RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing 1730 Tone Generation in the Session Initiation Protocol (SIP)", 1731 RFC 3960, DOI 10.17487/RFC3960, December 2004, 1732 . 1734 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1735 Congestion Control Protocol (DCCP)", RFC 4340, DOI 1736 10.17487/RFC4340, March 2006, 1737 . 1739 [RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., 1740 "Managing Client-Initiated Connections in the Session 1741 Initiation Protocol (SIP)", RFC 5626, DOI 10.17487/ 1742 RFC5626, October 2009, 1743 . 1745 [RFC5898] Andreasen, F., Camarillo, G., Oran, D., and D. Wing, 1746 "Connectivity Preconditions for Session Description 1747 Protocol (SDP) Media Streams", RFC 5898, DOI 10.17487/ 1748 RFC5898, July 2010, 1749 . 1751 Appendix A. Examples 1753 For the example shown in Section 13 of [ICE-BIS] the resulting offer 1754 (message 5) encoded in SDP looks like: 1756 v=0 1757 o=jdoe 2890844526 2890842807 IN IP4 $L-PRIV-1.IP 1758 s= 1759 c=IN IP4 $NAT-PUB-1.IP 1760 t=0 0 1761 a=ice-pwd:asd88fgpdd777uzjYhagZg 1762 a=ice-ufrag:8hhY 1763 m=audio $NAT-PUB-1.PORT RTP/AVP 0 1764 b=RS:0 1765 b=RR:0 1766 a=rtpmap:0 PCMU/8000 1767 a=candidate:1 1 UDP 2130706431 $L-PRIV-1.IP $L-PRIV-1.PORT typ host 1768 a=candidate:2 1 UDP 1694498815 $NAT-PUB-1.IP $NAT-PUB-1.PORT typ 1769 srflx raddr $L-PRIV-1.IP rport $L-PRIV-1.PORT 1771 The offer, with the variables replaced with their values, will look 1772 like (lines folded for clarity): 1774 v=0 1775 o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1 1776 s= 1777 c=IN IP4 192.0.2.3 1778 t=0 0 1779 a=ice-pwd:asd88fgpdd777uzjYhagZg 1780 a=ice-ufrag:8hhY 1781 m=audio 45664 RTP/AVP 0 1782 b=RS:0 1783 b=RR:0 1784 a=rtpmap:0 PCMU/8000 1785 a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host 1786 a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 1787 10.0.1.1 rport 8998 1789 The resulting answer looks like: 1791 v=0 1792 o=bob 2808844564 2808844564 IN IP4 $R-PUB-1.IP 1793 s= 1794 c=IN IP4 $R-PUB-1.IP 1795 t=0 0 1796 a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh 1797 a=ice-ufrag:9uB6 1798 m=audio $R-PUB-1.PORT RTP/AVP 0 1799 b=RS:0 1800 b=RR:0 1801 a=rtpmap:0 PCMU/8000 1802 a=candidate:1 1 UDP 2130706431 $R-PUB-1.IP $R-PUB-1.PORT typ host 1804 With the variables filled in: 1806 v=0 1807 o=bob 2808844564 2808844564 IN IP4 192.0.2.1 1808 s= 1809 c=IN IP4 192.0.2.1 1810 t=0 0 1811 a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh 1812 a=ice-ufrag:9uB6 1813 m=audio 3478 RTP/AVP 0 1814 b=RS:0 1815 b=RR:0 1816 a=rtpmap:0 PCMU/8000 1817 a=candidate:1 1 UDP 2130706431 192.0.2.1 3478 typ host 1819 Appendix B. The remote-candidates Attribute 1821 The a=remote-candidates attribute exists to eliminate a race 1822 condition between the updated offer and the response to the STUN 1823 Binding request that moved a candidate into the Valid list. This 1824 race condition is shown in Figure 1. On receipt of message 4, agent 1825 L adds a candidate pair to the valid list. If there was only a 1826 single media stream with a single component, agent L could now send 1827 an updated offer. However, the check from agent R has not yet 1828 generated a response, and agent R receives the updated offer (message 1829 7) before getting the response (message 9). Thus, it does not yet 1830 know that this particular pair is valid. To eliminate this 1831 condition, the actual candidates at R that were selected by the 1832 offerer (the remote candidates) are included in the offer itself, and 1833 the answerer delays its answer until those pairs validate. 1835 Agent L Network Agent R 1836 |(1) Offer | | 1837 |------------------------------------------>| 1838 |(2) Answer | | 1839 |<------------------------------------------| 1840 |(3) STUN Req. | | 1841 |------------------------------------------>| 1842 |(4) STUN Res. | | 1843 |<------------------------------------------| 1844 |(5) STUN Req. | | 1845 |<------------------------------------------| 1846 |(6) STUN Res. | | 1847 |-------------------->| | 1848 | |Lost | 1849 |(7) Offer | | 1850 |------------------------------------------>| 1851 |(8) STUN Req. | | 1852 |<------------------------------------------| 1853 |(9) STUN Res. | | 1854 |------------------------------------------>| 1855 |(10) Answer | | 1856 |<------------------------------------------| 1858 Figure 1: Race Condition Flow 1860 Appendix C. Why Is the Conflict Resolution Mechanism Needed? 1862 When ICE runs between two peers, one agent acts as controlled, and 1863 the other as controlling. Rules are defined as a function of 1864 implementation type and offerer/answerer to determine who is 1865 controlling and who is controlled. However, the specification 1866 mentions that, in some cases, both sides might believe they are 1867 controlling, or both sides might believe they are controlled. How 1868 can this happen? 1870 The condition when both agents believe they are controlled shows up 1871 in third party call control cases. Consider the following flow: 1873 A Controller B 1874 |(1) INV() | | 1875 |<-------------| | 1876 |(2) 200(SDP1) | | 1877 |------------->| | 1878 | |(3) INV() | 1879 | |------------->| 1880 | |(4) 200(SDP2) | 1881 | |<-------------| 1882 |(5) ACK(SDP2) | | 1883 |<-------------| | 1884 | |(6) ACK(SDP1) | 1885 | |------------->| 1887 Figure 2: Role Conflict Flow 1889 This flow is a variation on flow III of RFC 3725 [RFC3725]. In fact, 1890 it works better than flow III since it produces fewer messages. In 1891 this flow, the controller sends an offerless INVITE to agent A, which 1892 responds with its offer, SDP1. The agent then sends an offerless 1893 INVITE to agent B, which it responds to with its offer, SDP2. The 1894 controller then uses the offer from each agent to generate the 1895 answers. When this flow is used, ICE will run between agents A and 1896 B, but both will believe they are in the controlling role. With the 1897 role conflict resolution procedures, this flow will function properly 1898 when ICE is used. 1900 At this time, there are no documented flows that can result in the 1901 case where both agents believe they are controlled. However, the 1902 conflict resolution procedures allow for this case, should a flow 1903 arise that would fit into this category. 1905 Appendix D. Why Send an Updated Offer? 1907 Section 11.1 describes rules for sending media. Both agents can send 1908 media once ICE checks complete, without waiting for an updated offer. 1909 Indeed, the only purpose of the updated offer is to "correct" the SDP 1910 so that the default destination for media matches where media is 1911 being sent based on ICE procedures (which will be the highest- 1912 priority nominated candidate pair). 1914 This begs the question -- why is the updated offer/answer exchange 1915 needed at all? Indeed, in a pure offer/answer environment, it would 1916 not be. The offerer and answerer will agree on the candidates to use 1917 through ICE, and then can begin using them. As far as the agents 1918 themselves are concerned, the updated offer/answer provides no new 1919 information. However, in practice, numerous components along the 1920 signaling path look at the SDP information. These include entities 1921 performing off-path QoS reservations, NAT traversal components such 1922 as ALGs and Session Border Controllers (SBCs), and diagnostic tools 1923 that passively monitor the network. For these tools to continue to 1924 function without change, the core property of SDP -- that the 1925 existing, pre-ICE definitions of the addresses used for media -- the 1926 "m=" and "c=" lines and the rtcp attribute -- must be retained. For 1927 this reason, an updated offer must be sent. 1929 Authors' Addresses 1931 Marc Petit-Huguenin 1932 Impedance Mismatch 1934 Email: marc@petit-huguenin.org 1936 Ari Keranen 1937 Ericsson 1938 Jorvas 02420 1939 Finland 1941 Email: ari.keranen@ericsson.com 1943 Suhas Nandakumar 1944 Cisco Systems 1945 707 Tasman Dr 1946 Milpitas 95035 1947 USA 1949 Email: snandaku@cisco.com