draft-ietf-mmusic-ice-14.txt   draft-ietf-mmusic-ice-15.txt 
MMUSIC J. Rosenberg MMUSIC J. Rosenberg
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track March 5, 2007 Obsoletes: 4091 (if approved) March 26, 2007
Expires: September 6, 2007 Intended status: Standards Track
Expires: September 27, 2007
Interactive Connectivity Establishment (ICE): A Methodology for Network Interactive Connectivity Establishment (ICE): A Methodology for Network
Address Translator (NAT) Traversal for Offer/Answer Protocols Address Translator (NAT) Traversal for Offer/Answer Protocols
draft-ietf-mmusic-ice-14 draft-ietf-mmusic-ice-15
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 6, 2007. This Internet-Draft will expire on September 27, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes a protocol for Network Address Translator This document describes a protocol for Network Address Translator
(NAT) traversal for multimedia sessions established with the offer/ (NAT) traversal for multimedia sessions established with the offer/
answer model. This protocol is called Interactive Connectivity answer model. This protocol is called Interactive Connectivity
Establishment (ICE). ICE makes use of the Session Traversal Establishment (ICE). ICE makes use of the Session Traversal
Utilities for NAT (STUN) protocol, applying its binding discovery and Utilities for NAT (STUN) protocol, applying its binding discovery and
relay usages, in addition to defining a new usage for checking relay usages, in addition to defining a new usage for checking
connectivity between peers. ICE can be used by any protocol connectivity between peers. ICE can be used by any protocol
utilizing the offer/answer model, such as the Session Initiation utilizing the offer/answer model, such as the Session Initiation
Protocol (SIP). Protocol (SIP).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Overview of ICE . . . . . . . . . . . . . . . . . . . . . . . 7 2. Overview of ICE . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Gathering Candidate Addresses . . . . . . . . . . . . . . 9 2.1. Gathering Candidate Addresses . . . . . . . . . . . . . . 9
2.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 11 2.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 11
2.3. Sorting Candidates . . . . . . . . . . . . . . . . . . . . 12 2.3. Sorting Candidates . . . . . . . . . . . . . . . . . . . 12
2.4. Frozen Candidates . . . . . . . . . . . . . . . . . . . . 13 2.4. Frozen Candidates . . . . . . . . . . . . . . . . . . . . 13
2.5. Security for Checks . . . . . . . . . . . . . . . . . . . 14 2.5. Security for Checks . . . . . . . . . . . . . . . . . . . 14
2.6. Concluding ICE . . . . . . . . . . . . . . . . . . . . . . 14 2.6. Concluding ICE . . . . . . . . . . . . . . . . . . . . . 14
2.7. Lite Implementations . . . . . . . . . . . . . . . . . . . 16 2.7. Lite Implementations . . . . . . . . . . . . . . . . . . 16
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 16 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 16
4. Sending the Initial Offer . . . . . . . . . . . . . . . . . . 19 4. Sending the Initial Offer . . . . . . . . . . . . . . . . . . 19
4.1. Full Implementation Requirements . . . . . . . . . . . . . 19 4.1. Full Implementation Requirements . . . . . . . . . . . . 19
4.1.1. Gathering Candidates . . . . . . . . . . . . . . . . . 19 4.1.1. Gathering Candidates . . . . . . . . . . . . . . . . 19
4.1.1.1. Host Candidates . . . . . . . . . . . . . . . . . 20 4.1.1.1. Host Candidates . . . . . . . . . . . . . . . . . 19
4.1.1.2. Server Reflexive and Relayed Candidates . . . . . 20 4.1.1.2. Server Reflexive and Relayed Candidates . . . . . 20
4.1.1.3. Eliminating Redundant Candidates . . . . . . . . . 21 4.1.1.3. Eliminating Redundant Candidates . . . . . . . . 21
4.1.1.4. Computing Foundations . . . . . . . . . . . . . . 21 4.1.1.4. Computing Foundations . . . . . . . . . . . . . . 21
4.1.1.5. Keeping Candidates Alive . . . . . . . . . . . . . 22 4.1.1.5. Keeping Candidates Alive . . . . . . . . . . . . 22
4.1.2. Prioritizing Candidates . . . . . . . . . . . . . . . 22 4.1.2. Prioritizing Candidates . . . . . . . . . . . . . . . 22
4.1.2.1. Recommended Formula . . . . . . . . . . . . . . . 22 4.1.2.1. Recommended Formula . . . . . . . . . . . . . . . 22
4.1.2.2. Guidelines for Choosing Type and Local 4.1.2.2. Guidelines for Choosing Type and Local
Preferences . . . . . . . . . . . . . . . . . . . 23 Preferences . . . . . . . . . . . . . . . . . . . 23
4.1.3. Choosing Default Candidates . . . . . . . . . . . . . 24 4.1.3. Choosing Default Candidates . . . . . . . . . . . . . 24
4.2. Lite Implementation . . . . . . . . . . . . . . . . . . . 25 4.2. Lite Implementation . . . . . . . . . . . . . . . . . . . 25
4.3. Encoding the SDP . . . . . . . . . . . . . . . . . . . . . 25 4.3. Encoding the SDP . . . . . . . . . . . . . . . . . . . . 25
5. Receiving the Initial Offer . . . . . . . . . . . . . . . . . 27 5. Receiving the Initial Offer . . . . . . . . . . . . . . . . . 27
5.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 27 5.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 27
5.2. Determining Role . . . . . . . . . . . . . . . . . . . . . 27 5.2. Determining Role . . . . . . . . . . . . . . . . . . . . 28
5.3. Gathering Candidates . . . . . . . . . . . . . . . . . . . 28 5.3. Gathering Candidates . . . . . . . . . . . . . . . . . . 28
5.4. Prioritizing Candidates . . . . . . . . . . . . . . . . . 28 5.4. Prioritizing Candidates . . . . . . . . . . . . . . . . . 29
5.5. Choosing Default Candidates . . . . . . . . . . . . . . . 28 5.5. Choosing Default Candidates . . . . . . . . . . . . . . . 29
5.6. Encoding the SDP . . . . . . . . . . . . . . . . . . . . . 28 5.6. Encoding the SDP . . . . . . . . . . . . . . . . . . . . 29
5.7. Forming the Check Lists . . . . . . . . . . . . . . . . . 28 5.7. Forming the Check Lists . . . . . . . . . . . . . . . . . 29
5.7.1. Forming Candidate Pairs . . . . . . . . . . . . . . . 29 5.7.1. Forming Candidate Pairs . . . . . . . . . . . . . . . 29
5.7.2. Computing Pair Priority and Ordering Pairs . . . . . . 31 5.7.2. Computing Pair Priority and Ordering Pairs . . . . . 32
5.7.3. Pruning the Pairs . . . . . . . . . . . . . . . . . . 31 5.7.3. Pruning the Pairs . . . . . . . . . . . . . . . . . . 32
5.7.4. Computing States . . . . . . . . . . . . . . . . . . . 31 5.7.4. Computing States . . . . . . . . . . . . . . . . . . 32
5.8. Performing Periodic Checks . . . . . . . . . . . . . . . . 34 5.8. Performing Periodic Checks . . . . . . . . . . . . . . . 35
6. Receipt of the Initial Answer . . . . . . . . . . . . . . . . 35 6. Receipt of the Initial Answer . . . . . . . . . . . . . . . . 37
6.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 36 6.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 37
6.2. Determining Role . . . . . . . . . . . . . . . . . . . . . 36 6.2. Determining Role . . . . . . . . . . . . . . . . . . . . 37
6.3. Forming the Check List . . . . . . . . . . . . . . . . . . 36 6.3. Forming the Check List . . . . . . . . . . . . . . . . . 37
6.4. Performing Periodic Checks . . . . . . . . . . . . . . . . 36 6.4. Performing Periodic Checks . . . . . . . . . . . . . . . 37
7. Performing Connectivity Checks . . . . . . . . . . . . . . . . 36 7. Performing Connectivity Checks . . . . . . . . . . . . . . . 37
7.1. Client Procedures . . . . . . . . . . . . . . . . . . . . 37 7.1. Client Procedures . . . . . . . . . . . . . . . . . . . . 38
7.1.1. Sending the Request . . . . . . . . . . . . . . . . . 37 7.1.1. Sending the Request . . . . . . . . . . . . . . . . . 38
7.1.1.1. PRIORITY and USE-CANDIDATE . . . . . . . . . . . . 37 7.1.1.1. PRIORITY and USE-CANDIDATE . . . . . . . . . . . 38
7.1.1.2. Forming Credentials . . . . . . . . . . . . . . . 37 7.1.1.2. ICE-CONTROLLED and ICE-CONTROLLING . . . . . . . 38
7.1.1.3. DiffServ Treatment . . . . . . . . . . . . . . . . 38 7.1.1.3. Forming Credentials . . . . . . . . . . . . . . . 39
7.1.2. Processing the Response . . . . . . . . . . . . . . . 38 7.1.1.4. DiffServ Treatment . . . . . . . . . . . . . . . 39
7.1.2.1. Failure Cases . . . . . . . . . . . . . . . . . . 38 7.1.2. Processing the Response . . . . . . . . . . . . . . . 39
7.1.2.2. Success Cases . . . . . . . . . . . . . . . . . . 38 7.1.2.1. Failure Cases . . . . . . . . . . . . . . . . . . 39
7.1.2.2.1. Discovering Peer Reflexive Candidates . . . . 38 7.1.2.2. Success Cases . . . . . . . . . . . . . . . . . . 40
7.1.2.2.2. Updating Pair States . . . . . . . . . . . . . 39 7.1.2.2.1. Discovering Peer Reflexive Candidates . . . . 40
7.1.2.2.3. Constructing a Valid Pair . . . . . . . . . . 40 7.1.2.2.2. Updating Pair States . . . . . . . . . . . . 41
7.1.2.2.4. Updating the Nominated Flag . . . . . . . . . 40 7.1.2.2.3. Constructing a Valid Pair . . . . . . . . . . 42
7.2. Server Procedures . . . . . . . . . . . . . . . . . . . . 41 7.1.2.2.4. Updating the Nominated Flag . . . . . . . . . 42
7.2.1. Additional Procedures for Full Implementations . . . . 41 7.1.2.3. Check List and Timer State Updates . . . . . . . 43
7.2.1.1. Computing Mapped Address . . . . . . . . . . . . . 41 7.2. Server Procedures . . . . . . . . . . . . . . . . . . . . 43
7.2.1.2. Learning Peer Reflexive Candidates . . . . . . . . 42 7.2.1. Additional Procedures for Full Implementations . . . 44
7.2.1.3. Triggered Checks . . . . . . . . . . . . . . . . . 42 7.2.1.1. Detecting and Repairing Role Conflicts . . . . . 44
7.2.1.4. Updating the Nominated Flag . . . . . . . . . . . 43 7.2.1.2. Computing Mapped Address . . . . . . . . . . . . 45
7.2.2. Additional Procedures for Lite Implementations . . . . 43 7.2.1.3. Learning Peer Reflexive Candidates . . . . . . . 45
8. Concluding ICE Processing . . . . . . . . . . . . . . . . . . 43 7.2.1.4. Triggered Checks . . . . . . . . . . . . . . . . 46
8.1. Nominating Pairs . . . . . . . . . . . . . . . . . . . . . 44 7.2.1.5. Updating the Nominated Flag . . . . . . . . . . . 47
8.1.1. Regular Nomination . . . . . . . . . . . . . . . . . . 44 7.2.2. Additional Procedures for Lite Implementations . . . 47
8.1.2. Aggressive Nomination . . . . . . . . . . . . . . . . 45 8. Concluding ICE Processing . . . . . . . . . . . . . . . . . . 47
8.2. Updating States . . . . . . . . . . . . . . . . . . . . . 45 8.1. Nominating Pairs . . . . . . . . . . . . . . . . . . . . 48
9. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . . . 46 8.1.1. Regular Nomination . . . . . . . . . . . . . . . . . 48
9.1. Generating the Offer . . . . . . . . . . . . . . . . . . . 46 8.1.2. Aggressive Nomination . . . . . . . . . . . . . . . . 49
9.1.1. Procedures for All Implementations . . . . . . . . . . 46 8.2. Updating States . . . . . . . . . . . . . . . . . . . . . 49
9.1.1.1. ICE Restarts . . . . . . . . . . . . . . . . . . . 46 9. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . . . 50
9.1.1.2. Removing a Media Stream . . . . . . . . . . . . . 47 9.1. Generating the Offer . . . . . . . . . . . . . . . . . . 51
9.1.1.3. Adding a Media Stream . . . . . . . . . . . . . . 47 9.1.1. Procedures for All Implementations . . . . . . . . . 51
9.1.2. Procedures for Full Implementations . . . . . . . . . 47 9.1.1.1. ICE Restarts . . . . . . . . . . . . . . . . . . 51
9.1.2.1. Existing Media Streams with ICE Running . . . . . 48 9.1.1.2. Removing a Media Stream . . . . . . . . . . . . . 52
9.1.2.2. Existing Media Streams with ICE Completed . . . . 48 9.1.1.3. Adding a Media Stream . . . . . . . . . . . . . . 52
9.1.3. Procedures for Lite Implementations . . . . . . . . . 49 9.1.2. Procedures for Full Implementations . . . . . . . . . 52
9.2. Receiving the Offer and Generating an Answer . . . . . . . 49 9.1.2.1. Existing Media Streams with ICE Running . . . . . 52
9.2.1. Procedures for All Implementations . . . . . . . . . . 49 9.1.2.2. Existing Media Streams with ICE Completed . . . . 53
9.2.1.1. Detecting ICE Restart . . . . . . . . . . . . . . 49 9.1.3. Procedures for Lite Implementations . . . . . . . . . 53
9.2.1.2. New Media Stream . . . . . . . . . . . . . . . . . 50 9.2. Receiving the Offer and Generating an Answer . . . . . . 53
9.2.1.3. Removed Media Stream . . . . . . . . . . . . . . . 50 9.2.1. Procedures for All Implementations . . . . . . . . . 53
9.2.2. Procedures for Full Implementations . . . . . . . . . 50 9.2.1.1. Detecting ICE Restart . . . . . . . . . . . . . . 54
9.2.1.2. New Media Stream . . . . . . . . . . . . . . . . 54
9.2.1.3. Removed Media Stream . . . . . . . . . . . . . . 54
9.2.2. Procedures for Full Implementations . . . . . . . . . 54
9.2.2.1. Existing Media Streams with ICE Running and no 9.2.2.1. Existing Media Streams with ICE Running and no
remote-candidates . . . . . . . . . . . . . . . . 50 remote-candidates . . . . . . . . . . . . . . . . 55
9.2.2.2. Existing Media Streams with ICE Completed and 9.2.2.2. Existing Media Streams with ICE Completed and
no remote-candidates . . . . . . . . . . . . . . . 50 no remote-candidates . . . . . . . . . . . . . . 55
9.2.2.3. Existing Media Streams and remote-candidates . . . 50 9.2.2.3. Existing Media Streams and remote-candidates . . 55
9.2.3. Procedures for Lite Implementations . . . . . . . . . 51 9.2.3. Procedures for Lite Implementations . . . . . . . . . 56
9.3. Updating the Check and Valid Lists . . . . . . . . . . . . 52 9.3. Updating the Check and Valid Lists . . . . . . . . . . . 56
9.3.1. Procedures for Full Implementations . . . . . . . . . 52 9.3.1. Procedures for Full Implementations . . . . . . . . . 56
9.3.1.1. ICE Restarts . . . . . . . . . . . . . . . . . . . 52 9.3.1.1. ICE Restarts . . . . . . . . . . . . . . . . . . 56
9.3.1.2. New Media Stream . . . . . . . . . . . . . . . . . 52 9.3.1.2. New Media Stream . . . . . . . . . . . . . . . . 56
9.3.1.3. Removed Media Stream . . . . . . . . . . . . . . . 52 9.3.1.3. Removed Media Stream . . . . . . . . . . . . . . 56
9.3.1.4. ICE Continuing for Existing Media Stream . . . . . 52 9.3.1.4. ICE Continuing for Existing Media Stream . . . . 57
9.3.2. Procedures for Lite Implementations . . . . . . . . . 53 9.3.2. Procedures for Lite Implementations . . . . . . . . . 57
10. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . . 53 10. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 57
11. Media Handling . . . . . . . . . . . . . . . . . . . . . . . . 54 11. Media Handling . . . . . . . . . . . . . . . . . . . . . . . 58
11.1. Sending Media . . . . . . . . . . . . . . . . . . . . . . 54 11.1. Sending Media . . . . . . . . . . . . . . . . . . . . . . 58
11.1.1. Procedures for Full Implementations . . . . . . . . . 54 11.1.1. Procedures for Full Implementations . . . . . . . . . 59
11.1.2. Procedures for Lite Implementations . . . . . . . . . 55 11.1.2. Procedures for Lite Implementations . . . . . . . . . 59
11.1.3. Procedures for All Implementations . . . . . . . . . . 55 11.1.3. Procedures for All Implementations . . . . . . . . . 60
11.2. Receiving Media . . . . . . . . . . . . . . . . . . . . . 56 11.2. Receiving Media . . . . . . . . . . . . . . . . . . . . . 60
12. Usage with SIP . . . . . . . . . . . . . . . . . . . . . . . . 56 12. Usage with SIP . . . . . . . . . . . . . . . . . . . . . . . 60
12.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . . 56 12.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . 60
12.1.1. Offer in INVITE . . . . . . . . . . . . . . . . . . . 56 12.1.1. Offer in INVITE . . . . . . . . . . . . . . . . . . . 61
12.1.2. Offer in Response . . . . . . . . . . . . . . . . . . 58 12.1.2. Offer in Response . . . . . . . . . . . . . . . . . . 62
12.2. SIP Option Tags and Media Feature Tags . . . . . . . . . . 58 12.2. SIP Option Tags and Media Feature Tags . . . . . . . . . 63
12.3. Interactions with Forking . . . . . . . . . . . . . . . . 58 12.3. Interactions with Forking . . . . . . . . . . . . . . . . 63
12.4. Interactions with Preconditions . . . . . . . . . . . . . 59 12.4. Interactions with Preconditions . . . . . . . . . . . . . 63
12.5. Interactions with Third Party Call Control . . . . . . . . 59 12.5. Interactions with Third Party Call Control . . . . . . . 63
13. Usage with ANAT . . . . . . . . . . . . . . . . . . . . . . . 59 13. Relationship with ANAT . . . . . . . . . . . . . . . . . . . 64
14. Extensibility Considerations . . . . . . . . . . . . . . . . . 60 14. Extensibility Considerations . . . . . . . . . . . . . . . . 64
15. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 15. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
15.1. "candidate" Attribute . . . . . . . . . . . . . . . . . . 61 15.1. "candidate" Attribute . . . . . . . . . . . . . . . . . . 65
15.2. "remote-candidates" Attribute . . . . . . . . . . . . . . 64 15.2. "remote-candidates" Attribute . . . . . . . . . . . . . . 67
15.3. "ice-lite" and "ice-mismatch" Attributes . . . . . . . . . 64 15.3. "ice-lite" and "ice-mismatch" Attributes . . . . . . . . 68
15.4. "ice-ufrag" and "ice-pwd" Attributes . . . . . . . . . . . 64 15.4. "ice-ufrag" and "ice-pwd" Attributes . . . . . . . . . . 68
15.5. "ice-options> Attribute . . . . . . . . . . . . . . . . . 65 15.5. "ice-options> Attribute . . . . . . . . . . . . . . . . . 69
16. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 16. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
17. Security Considerations . . . . . . . . . . . . . . . . . . . 72 17. Security Considerations . . . . . . . . . . . . . . . . . . . 76
17.1. Attacks on Connectivity Checks . . . . . . . . . . . . . . 72 17.1. Attacks on Connectivity Checks . . . . . . . . . . . . . 76
17.2. Attacks on Address Gathering . . . . . . . . . . . . . . . 74 17.2. Attacks on Address Gathering . . . . . . . . . . . . . . 78
17.3. Attacks on the Offer/Answer Exchanges . . . . . . . . . . 75 17.3. Attacks on the Offer/Answer Exchanges . . . . . . . . . . 79
17.4. Insider Attacks . . . . . . . . . . . . . . . . . . . . . 75 17.4. Insider Attacks . . . . . . . . . . . . . . . . . . . . . 79
17.4.1. The Voice Hammer Attack . . . . . . . . . . . . . . . 75 17.4.1. The Voice Hammer Attack . . . . . . . . . . . . . . . 80
17.4.2. STUN Amplification Attack . . . . . . . . . . . . . . 76 17.4.2. STUN Amplification Attack . . . . . . . . . . . . . . 80
17.5. Interactions with Application Layer Gateways and SIP . . . 76 17.5. Interactions with Application Layer Gateways and SIP . . 81
18. Definition of Connectivity Check Usage . . . . . . . . . . . . 77 18. Definition of Connectivity Check Usage . . . . . . . . . . . 81
18.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 77 18.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 82
18.2. Client Discovery of Server . . . . . . . . . . . . . . . . 78 18.2. Client Discovery of Server . . . . . . . . . . . . . . . 82
18.3. Server Determination of Usage . . . . . . . . . . . . . . 78 18.3. Server Determination of Usage . . . . . . . . . . . . . . 82
18.4. New Requests or Indications . . . . . . . . . . . . . . . 78 18.4. New Requests or Indications . . . . . . . . . . . . . . . 82
18.5. New Attributes . . . . . . . . . . . . . . . . . . . . . . 78 18.5. New Attributes . . . . . . . . . . . . . . . . . . . . . 82
18.6. New Error Response Codes . . . . . . . . . . . . . . . . . 78 18.6. New Error Response Codes . . . . . . . . . . . . . . . . 83
18.7. Client Procedures . . . . . . . . . . . . . . . . . . . . 78 18.7. Client Procedures . . . . . . . . . . . . . . . . . . . . 83
18.8. Server Procedures . . . . . . . . . . . . . . . . . . . . 78 18.8. Server Procedures . . . . . . . . . . . . . . . . . . . . 83
18.9. Security Considerations for Connectivity Check . . . . . . 79 18.9. Security Considerations for Connectivity Check . . . . . 83
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 83
19.1. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . 79 19.1. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 84
19.1.1. candidate Attribute . . . . . . . . . . . . . . . . . 79 19.1.1. candidate Attribute . . . . . . . . . . . . . . . . . 84
19.1.2. remote-candidates Attribute . . . . . . . . . . . . . 79 19.1.2. remote-candidates Attribute . . . . . . . . . . . . . 84
19.1.3. ice-lite Attribute . . . . . . . . . . . . . . . . . . 80 19.1.3. ice-lite Attribute . . . . . . . . . . . . . . . . . 85
19.1.4. ice-mismatch Attribute . . . . . . . . . . . . . . . . 80 19.1.4. ice-mismatch Attribute . . . . . . . . . . . . . . . 85
19.1.5. ice-pwd Attribute . . . . . . . . . . . . . . . . . . 81 19.1.5. ice-pwd Attribute . . . . . . . . . . . . . . . . . . 86
19.1.6. ice-ufrag Attribute . . . . . . . . . . . . . . . . . 81 19.1.6. ice-ufrag Attribute . . . . . . . . . . . . . . . . . 86
19.1.7. ice-options Attribute . . . . . . . . . . . . . . . . 82 19.1.7. ice-options Attribute . . . . . . . . . . . . . . . . 86
19.2. STUN Attributes . . . . . . . . . . . . . . . . . . . . . 82 19.2. STUN Attributes . . . . . . . . . . . . . . . . . . . . . 87
20. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 82 19.3. STUN Error Responses . . . . . . . . . . . . . . . . . . 87
20.1. Problem Definition . . . . . . . . . . . . . . . . . . . . 83 20. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 87
20.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 83 20.1. Problem Definition . . . . . . . . . . . . . . . . . . . 88
20.3. Brittleness Introduced by ICE . . . . . . . . . . . . . . 84 20.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 88
20.4. Requirements for a Long Term Solution . . . . . . . . . . 84 20.3. Brittleness Introduced by ICE . . . . . . . . . . . . . . 89
20.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 85 20.4. Requirements for a Long Term Solution . . . . . . . . . . 89
21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 85 20.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 90
22. References . . . . . . . . . . . . . . . . . . . . . . . . . . 86 21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 90
22.1. Normative References . . . . . . . . . . . . . . . . . . . 86 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 91
22.2. Informative References . . . . . . . . . . . . . . . . . . 87 22.1. Normative References . . . . . . . . . . . . . . . . . . 91
Appendix A. Lite and Full Implementations . . . . . . . . . . . . 88 22.2. Informative References . . . . . . . . . . . . . . . . . 92
Appendix B. Design Motivations . . . . . . . . . . . . . . . . . 89 Appendix A. Lite and Full Implementations . . . . . . . . . . . 93
B.1. Pacing of STUN Transactions . . . . . . . . . . . . . . . 90 Appendix B. Design Motivations . . . . . . . . . . . . . . . . . 94
B.2. Candidates with Multiple Bases . . . . . . . . . . . . . . 90 B.1. Pacing of STUN Transactions . . . . . . . . . . . . . . . 94
B.3. Purpose of the <rel-addr> and <rel-port> Attributes . . . 92 B.2. Candidates with Multiple Bases . . . . . . . . . . . . . 95
B.4. Importance of the STUN Username . . . . . . . . . . . . . 92 B.3. Purpose of the <rel-addr> and <rel-port> Attributes . . . 97
B.5. The Candidate Pair Sequence Number Formula . . . . . . . . 93 B.4. Importance of the STUN Username . . . . . . . . . . . . . 97
B.6. The remote-candidates attribute . . . . . . . . . . . . . 94 B.5. The Candidate Pair Sequence Number Formula . . . . . . . 98
B.7. Why are Keepalives Needed? . . . . . . . . . . . . . . . . 95 B.6. The remote-candidates attribute . . . . . . . . . . . . . 99
B.8. Why Prefer Peer Reflexive Candidates? . . . . . . . . . . 96 B.7. Why are Keepalives Needed? . . . . . . . . . . . . . . . 100
B.9. Why Send an Updated Offer? . . . . . . . . . . . . . . . . 96 B.8. Why Prefer Peer Reflexive Candidates? . . . . . . . . . . 101
B.10. Why are Binding Indications Used for Keepalives? . . . . . 96 B.9. Why Send an Updated Offer? . . . . . . . . . . . . . . . 101
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 97 B.10. Why are Binding Indications Used for Keepalives? . . . . 101
Intellectual Property and Copyright Statements . . . . . . . . . . 98 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 102
Intellectual Property and Copyright Statements . . . . . . . . . 103
1. Introduction 1. Introduction
RFC 3264 [4] defines a two-phase exchange of Session Description RFC 3264 [4] defines a two-phase exchange of Session Description
Protocol (SDP) messages [10] for the purposes of establishment of Protocol (SDP) messages [10] for the purposes of establishment of
multimedia sessions. This offer/answer mechanism is used by multimedia sessions. This offer/answer mechanism is used by
protocols such as the Session Initiation Protocol (SIP) [3]. protocols such as the Session Initiation Protocol (SIP) [3].
Protocols using offer/answer are difficult to operate through Network Protocols using offer/answer are difficult to operate through Network
Address Translators (NAT). Because their purpose is to establish a Address Translators (NAT). Because their purpose is to establish a
skipping to change at page 7, line 12 skipping to change at page 7, line 12
acquisition techniques in [12] and relay allocation procedures in acquisition techniques in [12] and relay allocation procedures in
[13]. [13].
2. Overview of ICE 2. Overview of ICE
In a typical ICE deployment, we have two endpoints (known as AGENTS In a typical ICE deployment, we have two endpoints (known as AGENTS
in RFC 3264 terminology) which want to communicate. They are able to in RFC 3264 terminology) which want to communicate. They are able to
communicate indirectly via some signaling protocol (such as SIP), by communicate indirectly via some signaling protocol (such as SIP), by
which they can perform an offer/answer exchange of SDP [4] messages. which they can perform an offer/answer exchange of SDP [4] messages.
Note that ICE is not intended for NAT traversal for SIP, which is Note that ICE is not intended for NAT traversal for SIP, which is
assumed to be provided via another mechanism [35]. At the beginning assumed to be provided via another mechanism [34]. At the beginning
of the ICE process, the agents are ignorant of their own topologies. of the ICE process, the agents are ignorant of their own topologies.
In particular, they might or might not be behind a NAT (or multiple In particular, they might or might not be behind a NAT (or multiple
tiers of NATs). ICE allows the agents to discover enough information tiers of NATs). ICE allows the agents to discover enough information
about their topologies to potentially find one or more paths by which about their topologies to potentially find one or more paths by which
they can communicate. they can communicate.
Figure 1 shows a typical environment for ICE deployment. The two Figure 1 shows a typical environment for ICE deployment. The two
endpoints are labelled L and R (for left and right, which helps endpoints are labelled L and R (for left and right, which helps
visualize call flows). Both L and R are behind their own respective visualize call flows). Both L and R are behind their own respective
NATs though they may not be aware of it. The type of NAT and its NATs though they may not be aware of it. The type of NAT and its
skipping to change at page 14, line 40 skipping to change at page 14, line 40
better results. More fundamentally, however, the prioritization better results. More fundamentally, however, the prioritization
defined by this specification may not yield "optimal" results. As an defined by this specification may not yield "optimal" results. As an
example, if the aim is to select low latency media paths, usage of a example, if the aim is to select low latency media paths, usage of a
relay is a hint that latencies may be higher, but it is nothing more relay is a hint that latencies may be higher, but it is nothing more
than a hint. An actual RTT measurement could be made, and it might than a hint. An actual RTT measurement could be made, and it might
demonstrate that a pair with lower priority is actually better than demonstrate that a pair with lower priority is actually better than
one with higher priority. one with higher priority.
Consequently, ICE assigns one of the agents in the role of the Consequently, ICE assigns one of the agents in the role of the
CONTROLLING AGENT, and the other of the CONTROLLED AGENT. The CONTROLLING AGENT, and the other of the CONTROLLED AGENT. The
controlled agent gets to nominate which candidate pairs will get used controlling agent gets to nominate which candidate pairs will get
for media amongst the ones that are valid. It can do this in one of used for media amongst the ones that are valid. It can do this in
two ways - using REGULAR NOMINATION or AGGRESSIVE NOMINATION. one of two ways - using REGULAR NOMINATION or AGGRESSIVE NOMINATION.
With regular nomination, the controlling agent lets the checks With regular nomination, the controlling agent lets the checks
continue until at least one valid candidate pair for each media continue until at least one valid candidate pair for each media
stream is found. Then, it picks amongst those that are valid, and stream is found. Then, it picks amongst those that are valid, and
sends a second STUN request on its NOMINATED candidate pair, but this sends a second STUN request on its NOMINATED candidate pair, but this
time with a flag set to tell the peer that this pair has been time with a flag set to tell the peer that this pair has been
nominated for use. A This is shown in Figure 4. nominated for use. A This is shown in Figure 4.
L R L R
- - - -
skipping to change at page 16, line 20 skipping to change at page 16, line 20
from any correspondent. To make it easier for these devices to from any correspondent. To make it easier for these devices to
support ICE, ICE defines a special type of implementation called LITE support ICE, ICE defines a special type of implementation called LITE
(in contrast to the normal FULL implementation). A lite (in contrast to the normal FULL implementation). A lite
implementation doesn't gather candidates; it includes only host implementation doesn't gather candidates; it includes only host
candidates for any media stream. When a lite implementation connects candidates for any media stream. When a lite implementation connects
with a full implementation, the full agent takes the role of the with a full implementation, the full agent takes the role of the
controlling agent, and the lite agent takes on the controlled role. controlling agent, and the lite agent takes on the controlled role.
In addition, lite agents do not need to generate connectivity checks, In addition, lite agents do not need to generate connectivity checks,
run the state machines, or compute candidate pairs. Additional run the state machines, or compute candidate pairs. Additional
guidance on when a lite implementation is appropriate, see the guidance on when a lite implementation is appropriate, see the
discussion in Appendix A. For an informational summary of ICE discussion in Appendix A.
processing as seen by a lite agent, see [36].
It is important to note that the lite implementation was added to It is important to note that the lite implementation was added to
this specification to provide a stepping stone to full this specification to provide a stepping stone to full
implementation. Even for devices that are always connected to the implementation. Even for devices that are always connected to the
public Internet, a full implementation is preferable if achievable. public Internet, a full implementation is preferable if achievable.
3. Terminology 3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 20, line 29 skipping to change at page 20, line 23
called the component ID. For RTP-based media streams, the RTP itself called the component ID. For RTP-based media streams, the RTP itself
has a component ID of 1, and RTCP a component ID of 2. If an agent has a component ID of 1, and RTCP a component ID of 2. If an agent
is using RTCP it MUST obtain a candidate for it. If an agent is is using RTCP it MUST obtain a candidate for it. If an agent is
using both RTP and RTCP, it would end up with 2*K host candidates if using both RTP and RTCP, it would end up with 2*K host candidates if
an agent has K interfaces. an agent has K interfaces.
The base for each host candidate is set to the candidate itself. The base for each host candidate is set to the candidate itself.
4.1.1.2. Server Reflexive and Relayed Candidates 4.1.1.2. Server Reflexive and Relayed Candidates
Agents SHOULD obtain relayed candidates and MUST obtain server Agents SHOULD obtain relayed candidates and SHOULD obtain server
reflexive candidates. The requirement to obtain relayed candidates reflexive candidates. These requirements are at SHOULD strength to
is at SHOULD strength to allow for provider variation. Use of relays allow for provider variation. Use of STUN servers may be unnecessary
is expensive, and when ICE is being used, relays will only be in closed networks where agents are never connected to the public
required when both endpoints are behind NATs that perform address and Internet or to endpoints outside of the closed network. In such
port dependent mapping. Consequently, some deployments might cases, a full implementation would be used for agents that are dual-
consider this use case to be marginal, and elect not to use relays. stack or multi-homed, to select a host candidate. Use of relays is
If they are not used, it is RECOMMENDED that it be implemented and expensive, and when ICE is being used, relays will only be utilized
just disabled through configuration, so that it can re-enabled when both endpoints are behind NATs that perform address and port
through configuration if conditions change in the future. dependent mapping. Consequently, some deployments might consider
this use case to be marginal, and elect not to use relays. If an
agent does not gather server reflexive or relayed candidates, it is
RECOMMENDED that the functionality be implemented and just disabled
through configuration, so that it can re-enabled through
configuration if conditions change in the future.
The agent next pairs each host candidate with the STUN server with The agent next pairs each host candidate with the STUN server with
which it is configured or has discovered by some means. This which it is configured or has discovered by some means. This
specification only considers usage of a single STUN server. At that specification only considers usage of a single STUN server. At that
very instance, and then every Ta milliseconds thereafter, the agent very instance, and then every Ta milliseconds thereafter, the agent
chooses another such pair (the order is inconsequential), and sends a chooses another such pair (the order is inconsequential), and sends a
STUN request to the server from that host candidate. If the agent is STUN request to the server from that host candidate. If the agent is
using both relayed and server reflexive candidates, this request MUST using both relayed and server reflexive candidates, this request MUST
be a STUN Allocate request using the relay usage [13]. If the agent be a STUN Allocate request using the relay usage [13]. If the agent
is using only server reflexive candidates, the request MUST be a STUN is using only server reflexive candidates, the request MUST be a STUN
skipping to change at page 21, line 31 skipping to change at page 21, line 31
candidate in the RELAY-ADDRESS attribute. If the Allocate request is candidate in the RELAY-ADDRESS attribute. If the Allocate request is
rejected because the server lacks resources to fulfill it, the agent rejected because the server lacks resources to fulfill it, the agent
SHOULD instead send a Binding Request to obtain a server reflexive SHOULD instead send a Binding Request to obtain a server reflexive
candidate. A Binding Response will provide the agent with only a candidate. A Binding Response will provide the agent with only a
server reflexive candidate (also obtained from the mapped address). server reflexive candidate (also obtained from the mapped address).
The base of the server reflexive candidate is the host candidate from The base of the server reflexive candidate is the host candidate from
which the Allocate or Binding request was sent. The base of a which the Allocate or Binding request was sent. The base of a
relayed candidate is that candidate itself. If a relayed candidate relayed candidate is that candidate itself. If a relayed candidate
is identical to a host candidate (which can happen in rare cases), is identical to a host candidate (which can happen in rare cases),
the relayed candidate MUST be discarded. Proper operation of ICE the relayed candidate MUST be discarded. Proper operation of ICE
depends on each base being unique. depends on candidate having a unique base when their transport
addresses are identical.
4.1.1.3. Eliminating Redundant Candidates 4.1.1.3. Eliminating Redundant Candidates
Next, the agent eliminates redundant candidates. A candidate is Next, the agent eliminates redundant candidates. A candidate is
redundant if its transport address equals another candidate, and its redundant if its transport address equals another candidate, and its
base equals the base of that other candidate. Note that two base equals the base of that other candidate. Note that two
candidates can have the same transport address yet have different candidates can have the same transport address yet have different
bases, and these would not be considered redundant. bases, and these would not be considered redundant.
4.1.1.4. Computing Foundations 4.1.1.4. Computing Foundations
skipping to change at page 26, line 48 skipping to change at page 27, line 13
(lines folded for readability): (lines folded for readability):
v=0 v=0
o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1 o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
s= s=
c=IN IP4 192.0.2.3 c=IN IP4 192.0.2.3
t=0 0 t=0 0
a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY a=ice-ufrag:8hhY
m=audio 45664 RTP/AVP 0 m=audio 45664 RTP/AVP 0
b=RS:0
b=RR:0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=candidate:1 1 UDP 2130706178 10.0.1.1 8998 typ local a=candidate:1 1 UDP 2130706178 10.0.1.1 8998 typ host
a=candidate:2 1 UDP 1694498562 192.0.2.3 45664 typ srflx raddr a=candidate:2 1 UDP 1694498562 192.0.2.3 45664 typ srflx raddr
10.0.1.1 rport 8998 10.0.1.1 rport 8998
Once an agent has sent its offer or sent its answer, that agent MUST Once an agent has sent its offer or sent its answer, that agent MUST
be prepared to receive both STUN and media packets on each candidate. be prepared to receive both STUN and media packets on each candidate.
As discussed in Section 11.1, media packets can be sent to a As discussed in Section 11.1, media packets can be sent to a
candidate prior to its appearance as the default destination for candidate prior to its appearance as the default destination for
media in an offer or answer. media in an offer or answer.
5. Receiving the Initial Offer 5. Receiving the Initial Offer
When an agent receives an initial offer, it will check if the offeror When an agent receives an initial offer, it will check if the offeror
supports ICE, determine its own role, gather candidates, prioritize supports sufficient ICE functionality to proceed (i.e., if both
them, choose default candidates, encode and send an answer, and for offeror and answerer are lite implementations, ICE cannot proceed),
full implementations, form the check lists and begin connectivity determine its own role, gather candidates, prioritize them, choose
checks. default candidates, encode and send an answer, and for full
implementations, form the check lists and begin connectivity checks.
5.1. Verifying ICE Support 5.1. Verifying ICE Support
The answerer will proceed with the ICE procedures defined in this The answerer will proceed with the ICE procedures defined in this
specification if the following are all true: specification if the following are all true:
o For each media stream, the default destination for at least one o For each media stream, the default destination for at least one
component of the media stream appears in a candidate attribute. component of the media stream appears in a candidate attribute.
For example, in the case of RTP, the IP address and port in the c For example, in the case of RTP, the IP address and port in the c
and m line, respectively, appears in a candidate attribute, or the and m line, respectively, appears in a candidate attribute, or the
value in the rtcp attribute appears in a candidate attribute. value in the rtcp attribute appears in a candidate attribute.
o The offer omitted an a=ice-lite attribute or the answerer is a o The offer omitted an a=ice-lite attribute or the answerer is a
full implementation. full implementation. In other words, if both agents are lite
implementations, the agent does not proceed with ICE.
If any of these conditions are not met, the agent MUST process the If any of these conditions are not met, the agent MUST process the
SDP based on normal RFC 3264 procedures, without using any of the ICE SDP based on normal RFC 3264 procedures, without using any of the ICE
mechanisms described in the remainder of this specification with the mechanisms described in the remainder of this specification with the
following exceptions: following exceptions:
1. The agent MUST follow the rules of Section 10, which describe 1. The agent MUST follow the rules of Section 10, which describe
keepalive procedures for all agents. keepalive procedures for all agents.
2. If the agent is not proceeding with ICE because there were 2. If the agent is not proceeding with ICE because there were
skipping to change at page 28, line 15 skipping to change at page 28, line 32
pairs to use for each media stream, and does not generate an updated pairs to use for each media stream, and does not generate an updated
offer to signal this information. offer to signal this information.
If one of the agents is a lite implementation, it MUST assume the If one of the agents is a lite implementation, it MUST assume the
controlled role, and its peer (which will be full; if it was lite, controlled role, and its peer (which will be full; if it was lite,
ICE would have aborted) MUST assume the controlling role. If the ICE would have aborted) MUST assume the controlling role. If the
agent and its peer are both full implementations, the agent which agent and its peer are both full implementations, the agent which
generated the offer which started the ICE processing takes on the generated the offer which started the ICE processing takes on the
controlling role, and the other takes the controlled role. controlling role, and the other takes the controlled role.
Based on this definition, once roles are determined for a session, In unusual cases it is possible for both agents to mistakenly believe
they persist unless ICE is restarted. A ICE restart (Section 9.1 they are controlled or controlling. To deal with such cases, at the
causes a new selection of roles. time an agent determines its role, it MUST select a random number,
called the tie-breaker, uniformly distributed between 0 and (2**64) -
1 (that is, a 64 bit positive integer). This number is used in STUN
checks to detect and repair this case, as described in
Section 7.1.1.2.
Once roles are determined for a session, they persist unless ICE is
restarted. A ICE restart (Section 9.1 causes a new selection of
roles and tie-breakers.
5.3. Gathering Candidates 5.3. Gathering Candidates
The process for gathering candidates at the answerer is identical to The process for gathering candidates at the answerer is identical to
the process for the offerer as described in Section 4.1.1 for full the process for the offerer as described in Section 4.1.1 for full
implementations and Section 4.2 for lite implementations. It is implementations and Section 4.2 for lite implementations. It is
RECOMMENDED that this process begin immediately on receipt of the RECOMMENDED that this process begin immediately on receipt of the
offer, prior to alerting the user. Such gathering MAY begin when an offer, prior to alerting the user. Such gathering MAY begin when an
agent starts. agent starts.
skipping to change at page 28, line 44 skipping to change at page 29, line 21
5.5. Choosing Default Candidates 5.5. Choosing Default Candidates
The process for selecting default candidates at the answerer is The process for selecting default candidates at the answerer is
identical to the process followed by the offerer, as described in identical to the process followed by the offerer, as described in
Section 4.1.3 for full implementations and Section 4.2 for lite Section 4.1.3 for full implementations and Section 4.2 for lite
implementations. implementations.
5.6. Encoding the SDP 5.6. Encoding the SDP
The process for encoding the SDP at the answerer is identical to the The process for encoding the SDP at the answerer is identical to the
process followed by the offerer, as described in Section 4.3. process followed by the offerer for both full and lite
implementations, as described in Section 4.3.
5.7. Forming the Check Lists 5.7. Forming the Check Lists
Forming check lists is done only by full implementations. Lite Forming check lists is done only by full implementations. Lite
implementations MUST skip the steps defined in this section. implementations MUST skip the steps defined in this section.
There is one check list per in-use media stream resulting from the There is one check list per in-use media stream resulting from the
offer/answer exchange. To form the check list for a media stream, offer/answer exchange. To form the check list for a media stream,
the agent forms candidate pairs, computes a candidate pair priority, the agent forms candidate pairs, computes a candidate pair priority,
orders the pairs by priority, prunes them, and sets their states. orders the pairs by priority, prunes them, and sets their states.
skipping to change at page 34, line 5 skipping to change at page 35, line 5
+-----------+ +-----------+ +-----------+ +-----------+
Figure 9: Pair State FSM Figure 9: Pair State FSM
The initial states for each pair in the check list are computed by The initial states for each pair in the check list are computed by
performing the following sequence of steps: performing the following sequence of steps:
1. The agent sets all of the pairs in each check list to the Frozen 1. The agent sets all of the pairs in each check list to the Frozen
state. state.
2. It takes the first pair in the check list for the first media 2. The agent examines the check list for the first media stream (a
stream (a media stream is the first media stream when it is media stream is the first media stream when it is described by
described by the first m-line in the SDP offer and answer), and the first m-line in the SDP offer and answer). For that media
sets its state to Waiting. stream, it:
3. It finds all of the other pairs in that check list with the same * Groups together all of the pairs with the same foundation,
component ID, but different foundations, and sets all of their
states to Waiting as well. * For each group, sets the state of the pair with the lowest
component ID to Waiting. If there is more than one such pair,
the one with the highest priority is used.
One of the check lists will have some number of pairs in the Waiting One of the check lists will have some number of pairs in the Waiting
state, and the other check lists will have all of their pairs in the state, and the other check lists will have all of their pairs in the
Frozen state. A check list with at least one pair that is not Frozen Frozen state. A check list with at least one pair that is Waiting is
is called an active check list. called an active check list, and a check list with all pairs frozen
is called a frozen check list.
The check list itself is associated with a state, which captures the The check list itself is associated with a state, which captures the
state of ICE checks for that media stream. There are two states: state of ICE checks for that media stream. There are two states:
Running: In this state, ICE checks are still in progress for this Running: In this state, ICE checks are still in progress for this
media stream. media stream.
Completed: In this state, ICE checks have completed for this media Completed: In this state, ICE checks have completed successfully for
stream. this media stream.
Failed: In this state, the ICE checks have not completed
successfully for this media stream.
When a check list is first constructed as the consequence of an When a check list is first constructed as the consequence of an
offer/answer exchange, it is placed in the Running state. offer/answer exchange, it is placed in the Running state.
ICE processing across all media streams also has a state associated ICE processing across all media streams also has a state associated
with it. This state is equal to Running while checks are in with it. This state is equal to Running while checks are in
progress. The state is Completed when all checks have been progress. The state is Completed when all checks have been
completed. Rules for transitioning between states are described completed. Rules for transitioning between states are described
below. below.
5.8. Performing Periodic Checks 5.8. Performing Periodic Checks
Checks are generated only by full implementations. Lite Checks are generated only by full implementations. Lite
implementations MUST skip the steps described in this section. implementations MUST skip the steps described in this section.
An agent performs periodic checks and triggered checks. Periodic An agent performs periodic checks and triggered checks. Periodic
checks occur periodically for each media stream, and involve choosing checks occur periodically for each media stream, and involve choosing
the highest priority pair in the Waiting state from each check list, the highest priority pair in the Waiting state from each check list,
and sending a check on it. Triggered checks are performed on receipt and sending a check on it. Triggered checks are performed on receipt
of a connectivity check from the peer (see Section 7.2.1.3). This of a connectivity check from the peer (see Section 7.2.1.4). This
section describes how periodic checks are performed. section describes how periodic checks are performed.
Once the agent has computed the check lists as described in Once the agent has computed the check lists as described in
Section 5.7, it sets a timer for each active check list. The timer Section 5.7, it sets a timer for each active check list. The timer
fires every Ta/N seconds, where N is the number of active check lists fires every Ta*N seconds, where N is the number of active check lists
(initially, there is only one active check list). Implementations (initially, there is only one active check list). Implementations
MAY set the timer to fire less frequently than this. Ta is the same MAY set the timer to fire less frequently than this. Ta is the same
value used to pace the gathering of candidates, as described in value used to pace the gathering of candidates, as described in
Section 4.1.1. Dividing by N allows this aggregate check throughput Section 4.1.1. Multiplying by N allows this aggregate check
to be split between all active check lists. The first timer for each throughput to be split between all active check lists. The first
active check list fires immediately, so that the agent performs a timer for each active check list fires immediately, so that the agent
connectivity check the moment the offer/answer exchange has been performs a connectivity check the moment the offer/answer exchange
done, followed by the next periodic check Ta seconds later. has been done, followed by the next periodic check Ta seconds later.
When the timer fires, the agent MUST: When the timer fires, the agent MUST:
o Find the highest priority pair in that check list that is in the o Find the highest priority pair in that check list that is in the
Waiting state. Waiting state.
o If there is such a pair: o If there is such a pair:
* Send a STUN check from the local candidate of that pair to the * Send a STUN check from the local candidate of that pair to the
remote candidate of that pair. The procedures for forming the remote candidate of that pair. The procedures for forming the
skipping to change at page 35, line 37 skipping to change at page 36, line 43
* If there is such a pair: * If there is such a pair:
+ Unfreeze the pair. + Unfreeze the pair.
+ Perform a check for that pair, causing its state to + Perform a check for that pair, causing its state to
transition to In-Progress. transition to In-Progress.
* If there is no such pair: * If there is no such pair:
+ Set the state of the check list to Completed.
+ Terminate the timer for that check list. + Terminate the timer for that check list.
To compute the message integrity for the check, the agent uses the To compute the message integrity for the check, the agent uses the
remote username fragment and password learned from the SDP from its remote username fragment and password learned from the SDP from its
peer. The local username fragment is known directly by the agent for peer. The local username fragment is known directly by the agent for
its own candidate. its own candidate.
6. Receipt of the Initial Answer 6. Receipt of the Initial Answer
This section describes the procedures that an agent follows when it This section describes the procedures that an agent follows when it
skipping to change at page 37, line 39 skipping to change at page 38, line 44
that the type preference is set to the value for peer derived that the type preference is set to the value for peer derived
candidate types. candidate types.
The controlling agent MAY include the USE-CANDIDATE attribute in the The controlling agent MAY include the USE-CANDIDATE attribute in the
Binding Request. The controlled agent MUST NOT include it in its Binding Request. The controlled agent MUST NOT include it in its
Binding Request. This attribute signals that the controlling agent Binding Request. This attribute signals that the controlling agent
wishes to cease checks for this component, and use the candidate pair wishes to cease checks for this component, and use the candidate pair
resulting from the check for this component. Section 8.1 provides resulting from the check for this component. Section 8.1 provides
guidance on determining when to include it. guidance on determining when to include it.
7.1.1.2. Forming Credentials 7.1.1.2. ICE-CONTROLLED and ICE-CONTROLLING
The agent MUST include the ICE-CONTROLLED attribute in the request if
it is in the controlled role, and MUST include the ICE-CONTROLLING
attribute in the request if it is in the controlling role. The
content of either attribute MUST be the tie breaker that was
determined in Section 5.2.
7.1.1.3. Forming Credentials
A Binding Request serving as a connectivity check MUST utilize a STUN A Binding Request serving as a connectivity check MUST utilize a STUN
short term credential. The agent MUST include the USERNAME and short term credential. The agent MUST include the USERNAME and
MESSAGE-INTEGRITY attributes. An agent MUST NOT wait to be MESSAGE-INTEGRITY attributes. An agent MUST NOT wait to be
challenged for short term credentials. Rather, it MUST provide them challenged for short term credentials. Rather, it MUST provide them
in each Binding Request. in each Binding Request.
Rather than being learned from a Shared Secret request, the short Rather than being learned from a Shared Secret request, the short
term credential is exchanged in the offer/answer procedures. In term credential is exchanged in the offer/answer procedures. In
particular, the username is formed by concatenating the username particular, the username is formed by concatenating the username
skipping to change at page 38, line 12 skipping to change at page 39, line 27
sending the request, separated by a colon (":"). The password is sending the request, separated by a colon (":"). The password is
equal to the password provided by the peer. For example, consider equal to the password provided by the peer. For example, consider
the case where agent L is the offerer, and agent R is the answerer. the case where agent L is the offerer, and agent R is the answerer.
Agent L included a username fragment of LFRAG for its candidates, and Agent L included a username fragment of LFRAG for its candidates, and
a password of LPASS. Agent R provided a username fragment of RFRAG a password of LPASS. Agent R provided a username fragment of RFRAG
and a password of RPASS. A connectivity check from L to R (and its and a password of RPASS. A connectivity check from L to R (and its
response of course) utilize the username RFRAG:LFRAG and a password response of course) utilize the username RFRAG:LFRAG and a password
of RPASS. A connectivity check from R to L (and its response) of RPASS. A connectivity check from R to L (and its response)
utilize the username LFRAG:RFRAG and a password of LPASS. utilize the username LFRAG:RFRAG and a password of LPASS.
7.1.1.3. DiffServ Treatment 7.1.1.4. DiffServ Treatment
If the agent is using Diffserv Codepoint markings [27] in its media If the agent is using Diffserv Codepoint markings [27] in its media
packets, it SHOULD apply those same markings to its connectivity packets, it SHOULD apply those same markings to its connectivity
checks. checks.
7.1.2. Processing the Response 7.1.2. Processing the Response
When a Binding Response is received, it is correlated to its Binding When a Binding Response is received, it is correlated to its Binding
Request using the transaction ID, as defined in [12], which then ties Request using the transaction ID, as defined in [12], which then ties
it to the candidate pair for which the Binding Request was sent. it to the candidate pair for which the Binding Request was sent.
7.1.2.1. Failure Cases 7.1.2.1. Failure Cases
If the STUN transaction generates a 487 (Role Conflict) error
response, the agent checks whether it had included the ICE-CONTROLLED
or ICE-CONTROLLING attribute in the Binding Request. If the request
had contained the ICE-CONTROLLED attribute, the agent MUST switch to
the controlling role if it has not already done so. If the request
had contained the ICE-CONTROLLING attribute, the agent MUST switch to
the controlled role if it has not already done so. Once it has
switched, the agent MUST immediately retry the request with the ICE-
CONTROLLING or ICE-CONTROLLED attribute reflecting its new role.
Note, however, that the tie-breaker value MUST NOT be reselected.
If the STUN transaction generates an ICMP error, or generates a STUN If the STUN transaction generates an ICMP error, or generates a STUN
error response that is unrecoverable (as defined in [12], or times error response that is unrecoverable (as defined in [12], or times
out, the agent sets the state of the pair to Failed. out, the agent sets the state of the pair to Failed.
The agent MUST check that the source IP address and port of the The agent MUST check that the source IP address and port of the
response equals the destination IP address and port that the Binding response equals the destination IP address and port that the Binding
Request was sent to, and that the destination IP address and port of Request was sent to, and that the destination IP address and port of
the response match the source IP address and port that the Binding the response match the source IP address and port that the Binding
Request was sent from. In other words, the source and destination Request was sent from. In other words, the source and destination
transport addresses in the request and responses are the symmetric. transport addresses in the request and responses are the symmetric.
If they are not symmetric, the agent sets the state of the pair to If they are not symmetric, the agent sets the state of the pair to
Failed. Failed.
7.1.2.2. Success Cases 7.1.2.2. Success Cases
If the STUN transaction generated a response between 200 and 299, and A check is considered to be a success if all of the following are
the source IP address and port of the response equals the destination true:
IP address and port that the Binding Request was sent to, and the
destination IP address and port of the response match the source IP o the STUN transaction generated a success response
address and port that the Binding Request was sent from, the check
was a success. o the source IP address and port of the response equals the
destination IP address and port that the Binding Request was sent
to
o the destination IP address and port of the response match the
source IP address and port that the Binding Request was sent from
7.1.2.2.1. Discovering Peer Reflexive Candidates 7.1.2.2.1. Discovering Peer Reflexive Candidates
The agent checks the mapped address from the STUN response. If the The agent checks the mapped address from the STUN response. If the
transport address does not match any of the local candidates that the transport address does not match any of the local candidates that the
agent knows about, the mapped address represents a new candidate - a agent knows about, the mapped address represents a new candidate - a
peer reflexive candidate. Like other candidates, it has a type, peer reflexive candidate. Like other candidates, it has a type,
base, priority and foundation. They are computed as follows: base, priority and foundation. They are computed as follows:
o Its type is equal to peer reflexive. o Its type is equal to peer reflexive.
skipping to change at page 39, line 33 skipping to change at page 41, line 15
from it momentarily based on the procedures in Section 7.1.2.2.3. If from it momentarily based on the procedures in Section 7.1.2.2.3. If
an agent wishes to pair the peer reflexive candidate with other an agent wishes to pair the peer reflexive candidate with other
remote candidates besides the one in the valid pair that will be remote candidates besides the one in the valid pair that will be
generated, the agent MAY generate an updated offer which includes the generated, the agent MAY generate an updated offer which includes the
peer reflexive candidate. This will cause it to be paired with all peer reflexive candidate. This will cause it to be paired with all
other remote candidates. other remote candidates.
7.1.2.2.2. Updating Pair States 7.1.2.2.2. Updating Pair States
The agent sets the state of the pair that generated the check to The agent sets the state of the pair that generated the check to
succeeded. The agent sees if the success for this pair can cause Succeeded. The success of this check might also cause the state of
other pairs to be unfrozen. There are three cases: other checks to change as well. The agent MUST perform the following
two steps:
o If the pair had a component ID of 1, the agent MUST change the 1. The agent changes the states for all other Frozen pairs for the
states for all other Frozen pairs for the same media stream and same media stream and same foundation to Waiting. Typically
same foundation, but different component IDs, to Waiting. these other pairs will have different component IDs but not
always.
o If the pair had a component ID equal to the number of components 2. If there is a pair in the valid list for every component of this
for the media stream (where this is the actual number of media stream (where this is the actual number of components being
components being used, in cases where the number of components used, in cases where the number of components signaled in the SDP
signaled in the SDP differs from offerer to answerer), the agent differs from offerer to answerer), the success of this check may
MUST change the state for all other Frozen pairs for the first unfreeze checks for other media streams. Note that this step is
component of different media streams (and thus in different check followed not just the first time the valid list under
lists) but the same foundation, to Waiting. consideration has a pair for every component, but every
subsequent time a check succeeds and adds yet another pair to
that valid list. The agent examines the check list for each
other media stream in turn:
o If the pair has any other component ID, no other pairs can be * If the check list is active, the agent changes the state of
unfrozen. all Frozen pairs in that check list whose foundation matches a
pair in the valid list under consideration, to Waiting.
* If the check list is frozen, and there is at least one pair in
the check list whose foundation matches a pair in the valid
list under consideration, the state of all pairs in the check
list whose foundation matches a pair in the valid list under
consideration are set to Waiting.
* If the check list is frozen, and there are no pairs in the
check list whose foundation matches a pair in the valid list
under consideration, the agent
+ Groups together all of the pairs with the same foundation,
+ For each group, sets the state of the pair with the lowest
component ID to Waiting. If there is more than one such
pair, the one with the highest priority is used.
7.1.2.2.3. Constructing a Valid Pair 7.1.2.2.3. Constructing a Valid Pair
Next, the agent constructs a candidate pair whose local candidate Next, the agent constructs a candidate pair whose local candidate
equals the mapped address of the response, and whose remote candidate equals the mapped address of the response, and whose remote candidate
equals the destination address to which the request was sent. This equals the destination address to which the request was sent. This
is called a valid pair, since it has been validated by a STUN is called a valid pair, since it has been validated by a STUN
connectivity check. The valid pair may equal the pair that generated connectivity check. The valid pair may equal the pair that generated
the check, may equal a different pair in the check list, or may be a the check, may equal a different pair in the check list, or may be a
pair not currently on any check list. If the pair equals the pair pair not currently on any check list. If the pair equals the pair
skipping to change at page 40, line 47 skipping to change at page 42, line 50
a new remote candidate. In that case, the priority is taken as the a new remote candidate. In that case, the priority is taken as the
value of the PRIORITY attribute in the Binding Request which value of the PRIORITY attribute in the Binding Request which
triggered the check that just completed. The pair is then added to triggered the check that just completed. The pair is then added to
the VALID LIST. the VALID LIST.
7.1.2.2.4. Updating the Nominated Flag 7.1.2.2.4. Updating the Nominated Flag
If the agent was a controlling agent, and it had included a USE- If the agent was a controlling agent, and it had included a USE-
CANDIDATE attribute in the Binding Request, the valid pair generated CANDIDATE attribute in the Binding Request, the valid pair generated
from that check has its nominated flag set to true. This flag from that check has its nominated flag set to true. This flag
indicates that this candidate should be used for media if it is the indicates that this valid pair should be used for media if it is the
highest priority one amongst those whose nominated flag is set. This highest priority one amongst those whose nominated flag is set. This
may conclude ICE processing for this media stream or all media may conclude ICE processing for this media stream or all media
streams; see Section 8. streams; see Section 8.
If the agent is the controlled agent, the response may result in the If the agent is the controlled agent, the response may result in the
valid pair having its nominated flag set. See Section 7.2.1.4 for valid pair having its nominated flag set. See Section 7.2.1.5 for
the procedure. the procedure.
7.1.2.3. Check List and Timer State Updates
Regardless of whether the check was successful or failed, the
completion of the transaction may require updating of check list and
timer states.
If all of the pairs in the check list are now either in the Failed or
Succeeded state, and there is not a pair in the valid list for each
component of the media stream, the state of the check list is set to
Failed. For each frozen check list, the agent:
o Groups together all of the pairs with the same foundation,
o For each group, sets the state of the pair with the lowest
component ID to Waiting. If there is more than one such pair, the
one with the highest priority is used.
If none of the pairs in the check list are in the Waiting or Frozen
state, the check list is no longer considered active, and will not
count towards the value of N in the computation of timers for
periodic checks as described in Section 5.8.
7.2. Server Procedures 7.2. Server Procedures
An agent MUST be prepared to receive a Binding Request on the base of An agent MUST be prepared to receive a Binding Request on the base of
each candidate it included in its most recent offer or answer. each candidate it included in its most recent offer or answer.
Receipt of a Binding Request on a base is an indication that the Receipt of a Binding Request on a base is an indication that the
connectivity check usage applies to the request. connectivity check usage applies to the request.
The agent MUST use a short term credential to authenticate the The agent MUST use a short term credential to authenticate the
request and perform a message integrity check. The agent MUST accept request and perform a message integrity check. The agent MUST accept
a credential if the username consists of two values separated by a a credential if the username consists of two values separated by a
colon, where the first value is equal to the username fragment colon, where the first value is equal to the username fragment
generated by the agent in an offer or answer for a session in- generated by the agent in an offer or answer for a session in-
progress, and the MESSAGE-INTEGRITY is the output of a hash of the progress, and the MESSAGE-INTEGRITY is the output of a hash of the
password and the STUN packet's contents. It is possible (and in fact password and the STUN packet's contents. It is possible (and in fact
very likely) that an offeror will receive a Binding Request prior to very likely) that an offeror will receive a Binding Request prior to
receiving the answer from its peer. However, the request can be receiving the answer from its peer. If this happens, the agent MUST
processed without receiving this answer, and a response generated. generate a response (including computation of the mapped address as
By doing this, ICE processing completes faster. described in Section 7.2.1.2. Once the answer is received, it MUST
proceed with the remaining steps required, namely Section 7.2.1.3,
Section 7.2.1.4, and Section 7.2.1.5 for full implementations. In
cases where multiple STUN requests are received before the answer,
this may cause several triggered notifications to all be sent at the
same time,
If the agent is using Diffserv Codepoint markings [27] in its media If the agent is using Diffserv Codepoint markings [27] in its media
packets, it SHOULD apply those same markings to its responses to packets, it SHOULD apply those same markings to its responses to
Binding Requests. Binding Requests. The same would apply to any layer 2 markings the
endpoint might be applying to media packets.
7.2.1. Additional Procedures for Full Implementations 7.2.1. Additional Procedures for Full Implementations
This subsection defines the additional server procedures applicable This subsection defines the additional server procedures applicable
to full implementations when generating a successful response to a to full implementations.
Binding Request.
7.2.1.1. Computing Mapped Address 7.2.1.1. Detecting and Repairing Role Conflicts
Normally, the rules for selection of a role in Section 5.2 will
result in each agent selecting a different role - one controlling,
and one controlled. However, in unusual call flows, typically
utilizing third party call control, it is possible for both agents to
select the same role. This section describes procedures for checking
for this case and repairing it.
An agent MUST examine the Binding Request for either the ICE-
CONTROLLING or ICE-CONTROLLED attribute. It MUST follow these
procedures:
o If neither ICE-CONTROLLING or ICE-CONTROLLED are present in the
request, there is no conflict.
o If the agent is in the controlling role, and the ICE-CONTROLLING
attribute is present in the request:
* If the agent's tie-breaker is larger than or equal to the
contents of the ICE-CONTROLLING attribute, the agent generates
a Binding Error Response and includes an ERROR-CODE attribute
with a value of 487 (Role Conflict) but retains its role.
* If the agent's tie-breaker is less than the contents of the
ICE-CONTROLLING attribute, the agent switches to the controlled
role.
o If the agent is in the controlled role, and the ICE-CONTROLLED
attribute is present in the request:
* If the agent's tie-breaker is larger than or equal to the
contents of the ICE-CONTROLLED attribute, the agent switches to
the controlling role.
* If the agent's tie-breaker is less than the contents of the
ICE-CONTROLLED attribute, the agent generates a Binding Error
Response and includes an ERROR-CODE attribute with a value of
487 (Role Conflict) but retains its role.
o If the agent is in the controlled role and the ICE-CONTROLLING
attribute was present in the request, or the agent was in the
controlling role and the ICE-CONTROLLED attribute was present in
the request, there is no conflict.
The remaining sections in Section 7.2.1 are followed if the server
generated a successful response to the Binding Request, even if the
agent changed roles.
7.2.1.2. Computing Mapped Address
For requests being received on a relayed candidate, the source For requests being received on a relayed candidate, the source
transport address used for STUN processing (namely, generation of the transport address used for STUN processing (namely, generation of the
XOR-MAPPED-ADDRESS attribute) is the transport address as seen by the XOR-MAPPED-ADDRESS attribute) is the transport address as seen by the
relay. That source transport address will be present in the REMOTE- relay. That source transport address will be present in the REMOTE-
ADDRESS attribute of a STUN Data Indication message, if the Binding ADDRESS attribute of a STUN Data Indication message, if the Binding
Request was delivered through a Data Indication (a STUN relay Request was delivered through a Data Indication (a STUN relay
delivers packets encapsulated in a Data Indication when no active delivers packets encapsulated in a Data Indication when no active
destination is set). If the Binding Request was not encapsulated in destination is set). If the Binding Request was not encapsulated in
a Data Indication, that source address is equal to the current active a Data Indication, that source address is equal to the current active
destination for the STUN relay session. destination for the STUN relay session.
7.2.1.2. Learning Peer Reflexive Candidates 7.2.1.3. Learning Peer Reflexive Candidates
If the source transport address of the request does not match any If the source transport address of the request does not match any
existing remote candidates, it represents a new peer reflexive remote existing remote candidates, it represents a new peer reflexive remote
candidate. The full-mode agent gives the candidate a priority equal candidate. This candidate is constructed as follows:
to the PRIORITY attribute from the request. The type of the
candidate is equal to peer reflexive. Its foundation is set to an
arbitrary value, different from the foundation for all other remote
candidates. If any subsequent offer/answer exchanges contain this
peer reflexive candidate in the SDP, it will signal the actual
foundation for the candidate. This candidate is then added to the
list of remote candidates. However, the agent does not pair this
candidate with any local candidates.
7.2.1.3. Triggered Checks o The priority of the candidate is set to the PRIORITY attribute
from the request.
o The type of the candidate is set to peer reflexive.
o The foundation of the candidate is set to an arbitrary value,
different from the foundation for all other remote candidates. If
any subsequent offer/answer exchanges contain this peer reflexive
candidate in the SDP, it will signal the actual foundation for the
candidate.
o The component ID of this candidate is set to the component ID for
the local candidate to which the request was sent.
This candidate is added to the list of remote candidates. However,
the agent does not pair this candidate with any local candidates.
7.2.1.4. Triggered Checks
Next, the agent constructs a pair whose local candidate is equal to Next, the agent constructs a pair whose local candidate is equal to
the transport address on which the STUN request was received, and a the transport address on which the STUN request was received, and a
remote candidate equal to the source transport address where the remote candidate equal to the source transport address where the
request came from (which may be peer-reflexive remote candidate that request came from (which may be peer-reflexive remote candidate that
was just learned). Since both candidates are known to the agent, it was just learned). Since both candidates are known to the agent, it
can obtain their priorities and compute the candidate pair priority. can obtain their priorities and compute the candidate pair priority.
This pair is then looked up in the check list. There can be one of This pair is then looked up in the check list. There can be one of
several outcomes: several outcomes:
o If the pair is already on the check list: o If the pair is already on the check list:
* If the state of that pair is Waiting or Frozen, its state is * If the state of that pair is Waiting or Frozen, its state is
changed to In-Progress and a check for that pair is performed changed to In-Progress and a check for that pair is performed
immediately. This is called a triggered check. immediately. This is called a triggered check.
* If the state of that pair is In-Progress, the agent SHOULD * If the state of that pair is In-Progress, the agent SHOULD
generate an immediate retransmit of the Binding Request for the generate an immediate retransmit of the Binding Request for the
check in progress. This is to facilitate rapid completion of check in progress. This is to facilitate rapid completion of
ICE when both agents are behind NAT. ICE when both agents are behind NAT. It is RECOMMENDED that,
after the immediate retransmit, the next retransmission occur T
milliseconds later, where T is the current STUN retransmit
interval. If the immediate retransmit causes the total number
of requests transmitted to equal the maximum value defined in
[12], the agent SHOULD NOT send any further retransmits.
* If the state of that pair is Failed or Succeeded, no triggered * If the state of that pair is Failed or Succeeded, no triggered
check is sent. check is sent.
o If the pair is not already on the check list: o If the pair is not already on the check list:
* The pair is inserted into the check list based on its priority * The pair is inserted into the check list based on its priority
* Its state is set to In-Progress * Its state is set to In-Progress
skipping to change at page 43, line 17 skipping to change at page 47, line 11
candidate is equal to the part after the colon of the USERNAME in the candidate is equal to the part after the colon of the USERNAME in the
Binding Request that was just received. Using that username Binding Request that was just received. Using that username
fragment, the agent can check the SDP messages received from its peer fragment, the agent can check the SDP messages received from its peer
(there may be more than one in cases of forking), and find this (there may be more than one in cases of forking), and find this
username fragment. The corresponding password is then selected. If username fragment. The corresponding password is then selected. If
agent has not yet received the username in an SDP (a likely case for agent has not yet received the username in an SDP (a likely case for
the offerer in the initial offer/answer exchange), it MUST wait for the offerer in the initial offer/answer exchange), it MUST wait for
the SDP to be received (since it won't have its peer's ICE password the SDP to be received (since it won't have its peer's ICE password
without it), and then proceed with the triggered check. without it), and then proceed with the triggered check.
7.2.1.4. Updating the Nominated Flag 7.2.1.5. Updating the Nominated Flag
If the Binding Request received by the agent had the USE-CANDIDATE If the Binding Request received by the agent had the USE-CANDIDATE
attribute set, and the agent is in the controlled role, the agent attribute set, and the agent is in the controlled role, the agent
looks at the state of the pair computed in Section 7.2.1.3: looks at the state of the pair computed in Section 7.2.1.4:
o If the state of this pair is succeeded, it means that the check o If the state of this pair is succeeded, it means that the check
generated by this pair produced a successful response. This would generated by this pair produced a successful response. This would
have caused the agent to construct a valid pair when that success have caused the agent to construct a valid pair when that success
response was received (see Section 7.1.2.2.3). The agent now sets response was received (see Section 7.1.2.2.3). The agent now sets
the nominated flag in the valid pair to true. This may end ICE the nominated flag in the valid pair to true. This may end ICE
processing for this media stream; see Section 8. processing for this media stream; see Section 8.
o If the state of this pair is In-Progress, if its check produces a o If the state of this pair is In-Progress, if its check produces a
successful result, the resulting valid pair has its nominated flag successful result, the resulting valid pair has its nominated flag
skipping to change at page 44, line 45 skipping to change at page 48, line 43
the nominated flag of that and only that pair to be set. the nominated flag of that and only that pair to be set.
Consequently, there will be only a single nominated pair in the valid Consequently, there will be only a single nominated pair in the valid
list, and when the state of the check list moves to completed, that list, and when the state of the check list moves to completed, that
exact pair is selected by ICE for sending and receiving media. exact pair is selected by ICE for sending and receiving media.
Regular nomination provides the most flexibility, since the agent has Regular nomination provides the most flexibility, since the agent has
control over the stopping and selection criteria for checks. The control over the stopping and selection criteria for checks. The
only requirement is that the agent MUST eventually pick one and only only requirement is that the agent MUST eventually pick one and only
one candidate pair and generate a check for that pair with the USE- one candidate pair and generate a check for that pair with the USE-
CANDIDATE attribute present. Regular nomination also improves ICE's CANDIDATE attribute present. Regular nomination also improves ICE's
resilience to variations in implementation (see Section 14. Regular resilience to variations in implementation (see Section 14). Regular
nomination is also more stable, allowing both agents to converge on a nomination is also more stable, allowing both agents to converge on a
single pair for media without any transient selections, which can single pair for media without any transient selections, which can
happen with the aggressive algorithm. The drawback of regular happen with the aggressive algorithm. The drawback of regular
nomination is that it is guaranteed to increase latencies because it nomination is that it is guaranteed to increase latencies because it
requires an additional check to be done. requires an additional check to be done.
8.1.2. Aggressive Nomination 8.1.2. Aggressive Nomination
With aggressive nomination, the controlling agent includes the USE- With aggressive nomination, the controlling agent includes the USE-
CANDIDATE attribute in every check it sends. Once the first check CANDIDATE attribute in every check it sends. Once the first check
skipping to change at page 45, line 23 skipping to change at page 49, line 23
complete, causing another valid pair to have its nominated flag set. complete, causing another valid pair to have its nominated flag set.
ICE always selects the highest priority nominated candidate pair from ICE always selects the highest priority nominated candidate pair from
the valid list as the one used for media. Consequently, the selected the valid list as the one used for media. Consequently, the selected
pair may actually change briefly as ICE checks complete, resulting in pair may actually change briefly as ICE checks complete, resulting in
a set of transient selections until it stabilizes. a set of transient selections until it stabilizes.
8.2. Updating States 8.2. Updating States
For both controlling and controlled agents, the state of ICE For both controlling and controlled agents, the state of ICE
processing depends on the presence of nominated candidate pairs in processing depends on the presence of nominated candidate pairs in
the valid list: the valid list and on the state of the check list:
o If there are no nominated pairs in the valid list for a media o If there are no nominated pairs in the valid list for a media
stream, ICE processing continues. stream and the state of the check list is Running, ICE processing
continues.
o If there is at least one nominated pair in the valid list: o If there is at least one nominated pair in the valid list for a
media stream and the state of the check list is Running:
* The agent MUST remove all Waiting and Frozen pairs in the check * The agent MUST remove all Waiting and Frozen pairs in the check
list for the same component as the nominated pairs for that list for the same component as the nominated pairs for that
media stream media stream
* If an In-Progress pair in the check list is for the same * If an In-Progress pair in the check list is for the same
component as a nominated pair, the agent SHOULD cease component as a nominated pair, the agent SHOULD cease
retransmissions for its check if its pair priority is lower retransmissions for its check if its pair priority is lower
than the lowest priority nominated pair for that component than the lowest priority nominated pair for that component
o Once there is at least one nominated pair in the valid list for o Once there is at least one nominated pair in the valid list for
every component of at least one media stream: every component of at least one media stream and the state of the
check list is Running:
* The agent MUST change the state of processing for its check * The agent MUST change the state of processing for its check
list for that media stream to Completed. list for that media stream to Completed.
* The agent MUST continue to respond to any checks it may still * The agent MUST continue to respond to any checks it may still
receive for that media stream, and MUST perform triggered receive for that media stream, and MUST perform triggered
checks if required by the processing of Section 7.2. checks if required by the processing of Section 7.2.
* The agent MAY begin transmitting media for this media stream as * The agent MAY begin transmitting media for this media stream as
described in Section 11.1 described in Section 11.1
o Once there is at least one nominated pair in the valid list for
each component of each media stream: o Once the state of each check list is Completed:
* The agent sets the state of ICE processing overall to * The agent sets the state of ICE processing overall to
Completed. Completed.
* If an agent is controlling, it examines the highest priority * If an agent is controlling, it examines the highest priority
nominated candidate pair for each component of each media nominated candidate pair for each component of each media
stream. If any of those candidate pairs differ from the stream. If any of those candidate pairs differ from the
default candidate pairs in the most recent offer/answer default candidate pairs in the most recent offer/answer
exchange, the controlling agent MUST generate an updated offer exchange, the controlling agent MUST generate an updated offer
as described in Section 9. If the controlling agent is using as described in Section 9. If the controlling agent is using
an aggressive nomination algorithm, this may result in several an aggressive nomination algorithm, this may result in several
updated offers as the pairs selected for media change. An updated offers as the pairs selected for media change. An
agent MAY delay sending the offer for a brief interval (one agent MAY delay sending the offer for a brief interval (one
second is RECOMMENDED) in order to allow the selected pairs to second is RECOMMENDED) in order to allow the selected pairs to
stabilize. stabilize.
o If the state of the check list is Failed, ICE has not been able to
complete for this media stream. The correct behavior depends on
the state of the check lists for other media streams:
* If all check lists are Failed, the agent SHOULD consider the
session a failure, SHOULD NOT restart ICE, and the controlling
agent SHOULD terminate the entire session.
* If at least one of the check lists for other media streams is
Completed, the controlling agent SHOULD remove the failed media
stream from the session in its updated offer.
* If none of the check lists for other media streams are
Completed, but at least one is Running, the agent SHOULD let
ICE continue.
9. Subsequent Offer/Answer Exchanges 9. Subsequent Offer/Answer Exchanges
Either agent MAY generate a subsequent offer at any time allowed by Either agent MAY generate a subsequent offer at any time allowed by
RFC 3264 [4]. The rules in Section 8 will cause the controlling RFC 3264 [4]. The rules in Section 8 will cause the controlling
agent to send an updated offer at the conclusion of ICE processing agent to send an updated offer at the conclusion of ICE processing
when ICE has selected different candidate pairs from the default when ICE has selected different candidate pairs from the default
pairs. This section defines rules for construction of subsequent pairs. This section defines rules for construction of subsequent
offers and answers. offers and answers.
9.1. Generating the Offer 9.1. Generating the Offer
skipping to change at page 59, line 44 skipping to change at page 64, line 16
never generate a re-INVITE. never generate a re-INVITE.
The flows for continued operation, as described in Section 7 of RFC The flows for continued operation, as described in Section 7 of RFC
3725, require additional behavior of ICE implementations to support. 3725, require additional behavior of ICE implementations to support.
In particular, if an agent receives a mid-dialog re-INVITE that In particular, if an agent receives a mid-dialog re-INVITE that
contains no offer, it MUST restart ICE for each media stream and go contains no offer, it MUST restart ICE for each media stream and go
through the process of gathering new candidates. Furthermore, that through the process of gathering new candidates. Furthermore, that
list of candidates SHOULD include the ones currently being used for list of candidates SHOULD include the ones currently being used for
media. media.
13. Usage with ANAT 13. Relationship with ANAT
RFC 4091 [11] defines a mechanism for indicating that an agent can RFC 4091 [11] defines a mechanism for indicating that an agent can
support both IPv4 and IPv6 for a media stream, and it does so by support both IPv4 and IPv6 for a media stream, and it does so by
including two m-lines, one for v4, and one for v6. This is similar including two m-lines, one for v4, and one for v6. This is similar
to ICE, which allows for an agent to indicate multiple transport to ICE, which allows for an agent to indicate multiple transport
addresses using the candidate attribute. addresses using the candidate attribute. However, ANAT relies on
static selection to pick between choices, rather than a dynamic
However, ICE is not a replacement for ANAT. When an agent has a v4 connectivity check used by ICE.
and v6 interface and requires just a static choice of address - use
v6 if both support v6, else v4 - ANAT alone is used. If an agent
wishes the choice of v4 or v6 to be dynamic and depend on actual
verification of connectivity, an agent would use ANAT in concert with
ICE. To do that, The agent MUST include two media stream alternates,
one for v4 and one for v6, as defined in RFC 4091. In addition, the
agent MUST include a v4 candidate as a session attribute for the v4
stream alternate, and a v6 candidate as a session attribute of the v6
stream alternate. ICE will then perform its checks for each stream
alternate. The agent MUST order the ICE selected pairs for each
stream alternate based on their mid preference, and choose the
highest one. This means that if ICE doesn't select any pair for a
stream alternate (because, for example, no checks succeeded), the
agent will choose the next highest preference pair which was
selected. This allows v6 to be used if a v6 path can be verified,
but to fallback to v4 if it cannot be verified.
This extends naturally to multiple candidates for each alternate. An
agent MAY include multiple v4 candidates for the v4 stream alternate
and multiple v6 candidates for the v6 stream alternate. All of the
candidates for a v4 stream alternate MUST be v4, and all of the
candidates for a v6 stream alternate MUST be v6. This will cause ICE
to choose a v6 pair as long as one of the pairs works, else it will
fall back to v4.
Of course, an agent can use ICE with v4 and v6 candidates without This specification deprecates RFC 4091. Instead, agents wishing to
ANAT. In that mode, it would have just a single media stream, with a support dual-stack will utilize ICE. Because a dual-stack agent will
default destination that is either v4 or v6. The candidates can require at least two candidates, one for IPv4 and one for IPv6, dual-
include both v4 and v6 candidates. This brings an agent the stack agents MUST be full implementations. However, agents that are
flexibility of choosing a v4 candidate even if a v6 candidate implementing dual-stack and are running on closed networks where it
validates, perhaps due to differing path characteristics measured is known that there are no NAT, MAY include only host candidates in
dynamically by the agent. That kind of flexibility is not possible their offers, skipping server reflexive and relayed candidates.
when ANAT is used.
14. Extensibility Considerations 14. Extensibility Considerations
This specification makes very specific choices about how both agents This specification makes very specific choices about how both agents
in a session coordinate to arrive at the set of candidate pairs that in a session coordinate to arrive at the set of candidate pairs that
are selected for media. It is anticipated that future specifications are selected for media. It is anticipated that future specifications
will want to alter these algorithms, whether they are simple changes will want to alter these algorithms, whether they are simple changes
like timer tweaks, or larger changes like a revamp of the priority like timer tweaks, or larger changes like a revamp of the priority
algorithm. When such a change is made, providing interoperability algorithm. When such a change is made, providing interoperability
between the two agents in a session is critical. between the two agents in a session is critical.
skipping to change at page 61, line 34 skipping to change at page 65, line 30
regular nomination algorithm. When regular nomination is used, ICE regular nomination algorithm. When regular nomination is used, ICE
will converge perfectly even when both agents use different pair will converge perfectly even when both agents use different pair
prioritization algorithms. One of the keys to such convergence are prioritization algorithms. One of the keys to such convergence are
triggered checks, which ensure that the nominated pair is validated triggered checks, which ensure that the nominated pair is validated
by both agents. Consequently, any future ICE enhancements MUST by both agents. Consequently, any future ICE enhancements MUST
preserve triggered checks. preserve triggered checks.
ICE is also extensible to other media streams beyond RTP, and for ICE is also extensible to other media streams beyond RTP, and for
transport protocols beyond UDP. Extensions to ICE for non-RTP media transport protocols beyond UDP. Extensions to ICE for non-RTP media
streams need to specify how many components they utilize, and assign streams need to specify how many components they utilize, and assign
component IDS to them, starting at 1 for the most important component component IDs to them, starting at 1 for the most important component
ID. Specifications for new transport protocols must define how, if ID. Specifications for new transport protocols must define how, if
at all, various steps in the ICE processing differ from UDP. at all, various steps in the ICE processing differ from UDP.
15. Grammar 15. Grammar
This specification defines seven new SDP attributes - the This specification defines seven new SDP attributes - the
"candidate", "remote-candidates", "ice-lite", "ice-mismatch", "ice- "candidate", "remote-candidates", "ice-lite", "ice-mismatch", "ice-
ufrag", "ice-pwd" and "ice-options" attributes. ufrag", "ice-pwd" and "ice-options" attributes.
15.1. "candidate" Attribute 15.1. "candidate" Attribute
skipping to change at page 62, line 35 skipping to change at page 66, line 34
rel-port = "rport" SP port rel-port = "rport" SP port
extension-att-name = byte-string ;from RFC 4566 extension-att-name = byte-string ;from RFC 4566
extension-att-value = byte-string extension-att-value = byte-string
ice-char = ALPHA / DIGIT / "+" / "/" ice-char = ALPHA / DIGIT / "+" / "/"
This grammar encodes the primary information about a candidate: its This grammar encodes the primary information about a candidate: its
IP address, port and transport protocol, and its properties: the IP address, port and transport protocol, and its properties: the
foundation, component ID, priority, type, and related transport foundation, component ID, priority, type, and related transport
address: address:
<connect-address>: is taken from RFC 4566 [10]. It is the IP <connection-address>: is taken from RFC 4566 [10]. It is the IP
address of the candidate, allowing for IPv4 addresses, IPv6 address of the candidate, allowing for IPv4 addresses, IPv6
addresses and FQDNs. An IP address SHOULD be used, but an FQDN addresses and FQDNs. An IP address SHOULD be used, but an FQDN
MAY be used in place of an IP address. In that case, when MAY be used in place of an IP address. In that case, when
receiving an offer or answer containing an FQDN in an a=candidate receiving an offer or answer containing an FQDN in an a=candidate
attribute, the FQDN is looked up in the DNS using an A or AAAA attribute, the FQDN is looked up in the DNS using an A or AAAA
record, and the resulting IP address is used for the remainder of record, and the resulting IP address is used for the remainder of
ICE processing. ICE processing.
<port>: is also taken from RFC 4566 [10]. It is the port of the <port>: is also taken from RFC 4566 [10]. It is the port of the
candidate. candidate.
skipping to change at page 69, line 34 skipping to change at page 73, line 34
offer (message 5) looks like (lines folded for clarity): offer (message 5) looks like (lines folded for clarity):
v=0 v=0
o=jdoe 2890844526 2890842807 IN IP4 $L-PRIV-1.IP o=jdoe 2890844526 2890842807 IN IP4 $L-PRIV-1.IP
s= s=
c=IN IP4 $NAT-PUB-1.IP c=IN IP4 $NAT-PUB-1.IP
t=0 0 t=0 0
a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY a=ice-ufrag:8hhY
m=audio $NAT-PUB-1.PORT RTP/AVP 0 m=audio $NAT-PUB-1.PORT RTP/AVP 0
b=RS:0
b=RR:0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=candidate:1 1 UDP 2130706178 $L-PRIV-1.IP $L-PRIV-1.PORT typ local a=candidate:1 1 UDP 2130706178 $L-PRIV-1.IP $L-PRIV-1.PORT typ host
a=candidate:2 1 UDP 1694498562 $NAT-PUB-1.IP $NAT-PUB-1.PORT typ srflx raddr a=candidate:2 1 UDP 1694498562 $NAT-PUB-1.IP $NAT-PUB-1.PORT typ srflx raddr
$L-PRIV-1.IP rport $L-PRIV-1.PORT $L-PRIV-1.IP rport $L-PRIV-1.PORT
The offer, with the variables replaced with their values, will look The offer, with the variables replaced with their values, will look
like (lines folded for clarity): like (lines folded for clarity):
v=0 v=0
o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1 o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
s= s=
c=IN IP4 192.0.2.3 c=IN IP4 192.0.2.3
t=0 0 t=0 0
a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY a=ice-ufrag:8hhY
m=audio 45664 RTP/AVP 0 m=audio 45664 RTP/AVP 0
b=RS:0
b=RR:0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=candidate:1 1 UDP 2130706178 10.0.1.1 8998 typ local a=candidate:1 1 UDP 2130706178 10.0.1.1 8998 typ host
a=candidate:2 1 UDP 1694498562 192.0.2.3 45664 typ srflx raddr a=candidate:2 1 UDP 1694498562 192.0.2.3 45664 typ srflx raddr
10.0.1.1 rport 8998 10.0.1.1 rport 8998
This offer is received at agent R. Agent R will obtain a host This offer is received at agent R. Agent R will obtain a host
candidate, and from it, obtain a server reflexive candidate (messages candidate, and from it, obtain a server reflexive candidate (messages
6-7). Since R is not behind a NAT, this candidate is identical to 6-7). Since R is not behind a NAT, this candidate is identical to
its host candidate, and they share the same base. It therefore its host candidate, and they share the same base. It therefore
discards this redundant candidate and ends up with a single host discards this redundant candidate and ends up with a single host
candidate. With identical type and local preferences as L, the candidate. With identical type and local preferences as L, the
priority for this candidate is 2130706178. It chooses a foundation priority for this candidate is 2130706178. It chooses a foundation
of 1 for its single candidate. Its resulting answer looks like: of 1 for its single candidate. Its resulting answer looks like:
v=0 v=0
o=bob 2808844564 2808844564 IN IP4 $R-PUB-1.IP o=bob 2808844564 2808844564 IN IP4 $R-PUB-1.IP
s= s=
c=IN IP4 $R-PUB-1.IP c=IN IP4 $R-PUB-1.IP
t=0 0 t=0 0
a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh
a=ice-ufrag:9uB6 a=ice-ufrag:9uB6
m=audio $R-PUB-1.PORT RTP/AVP 0 m=audio $R-PUB-1.PORT RTP/AVP 0
b=RS:0
b=RR:0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=candidate:1 1 UDP 2130706178 $R-PUB-1.IP $R-PUB-1.PORT typ local a=candidate:1 1 UDP 2130706178 $R-PUB-1.IP $R-PUB-1.PORT typ host
With the variables filled in: With the variables filled in:
v=0 v=0
o=bob 2808844564 2808844564 IN IP4 192.0.2.1 o=bob 2808844564 2808844564 IN IP4 192.0.2.1
s= s=
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
t=0 0 t=0 0
a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh
a=ice-ufrag:9uB6 a=ice-ufrag:9uB6
m=audio 3478 RTP/AVP 0 m=audio 3478 RTP/AVP 0
b=RS:0
b=RR:0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=candidate:1 1 UDP 2130706178 192.0.2.1 3478 typ local a=candidate:1 1 UDP 2130706178 192.0.2.1 3478 typ host
Since neither side indicated that they are lite, the agent which sent Since neither side indicated that they are lite, the agent which sent
the offer that began ICE processing (agent L) becomes the controlling the offer that began ICE processing (agent L) becomes the controlling
agent. agent.
Agents L and R both pair up the candidates. They both initially have Agents L and R both pair up the candidates. They both initially have
two pairs. However, agent L will prune the pair containing its two pairs. However, agent L will prune the pair containing its
server reflexive candidate, resulting in just one. At agent L, this server reflexive candidate, resulting in just one. At agent L, this
pair has a local candidate of $L_PRIV_1 and remote candidate of pair has a local candidate of $L_PRIV_1 and remote candidate of
$R_PUB_1, and has a candidate pair priority of 4.57566E+18 (note that $R_PUB_1, and has a candidate pair priority of 4.57566E+18 (note that
an implementation would represent this as a 64 bit integer so as not an implementation would represent this as a 64 bit integer so as not
skipping to change at page 78, line 28 skipping to change at page 82, line 43
addresses in its candidates on which it expects to receive STUN addresses in its candidates on which it expects to receive STUN
packets. Consequently, any STUN packets received on the base of a packets. Consequently, any STUN packets received on the base of a
candidate offered in SDP will be for the connectivity check usage. candidate offered in SDP will be for the connectivity check usage.
18.4. New Requests or Indications 18.4. New Requests or Indications
This usage does not define any new message types. This usage does not define any new message types.
18.5. New Attributes 18.5. New Attributes
This usage defines two new attributes, PRIORITY and USE-CANDIDATE. This usage defines four new attributes, PRIORITY, USE-CANDIDATE, ICE-
CONTROLLED and ICE-CONTROLLING.
The PRIORITY attribute indicates the priority that is to be The PRIORITY attribute indicates the priority that is to be
associated with a peer reflexive candidate, should one be discovered associated with a peer reflexive candidate, should one be discovered
by this check. It is a 32 bit unsigned integer, and has an attribute by this check. It is a 32 bit unsigned integer, and has an attribute
value of 0x0024. value of 0x0024.
The USE-CANDIDATE attribute indicates that the candidate pair The USE-CANDIDATE attribute indicates that the candidate pair
resulting from this check should be used for transmission of media. resulting from this check should be used for transmission of media.
The attribute has no content (the Length field of the attribute is The attribute has no content (the Length field of the attribute is
zero); it serves as a flag. It has an attribute value of 0x0025. zero); it serves as a flag. It has an attribute value of 0x0025.
The ICE-CONTROLLED attribute is present in a Binding Request, and
indicates that the client believes it is currently in the controlled
role. The content of the attribute is a 64 bit unsigned integer in
network byte ordering, which contains a random number used for tie-
breaking of role conflicts.
The ICE-CONTROLLING attribute is present in a Binding Request, and
indicates that the client believes it is currently in the controlling
role. The content of the attribute is a 64 bit unsigned integer in
network byte ordering, which contains a random number used for tie-
breaking of role conflicts.
18.6. New Error Response Codes 18.6. New Error Response Codes
This usage does not define any new error response codes. This usage defines a single error response code:
487 (Role Conflict): The Binding Request contained either the ICE-
CONTROLLING or ICE-CONTROLLED attribute, indicating a role that
conflicted with the server. The server ran a tie-breaker based on
the tie-breaker value in the request, and determined that the
client needs to switch roles.
18.7. Client Procedures 18.7. Client Procedures
Client procedures are defined in Section 7.1. Client procedures are defined in Section 7.1.
18.8. Server Procedures 18.8. Server Procedures
Server procedures are defined in Section 7.2. Server procedures are defined in Section 7.2.
18.9. Security Considerations for Connectivity Check 18.9. Security Considerations for Connectivity Check
skipping to change at page 82, line 30 skipping to change at page 87, line 20
Purpose: This attribute is used with Interactive Connectivity Purpose: This attribute is used with Interactive Connectivity
Establishment (ICE), and indicates the ICE options or extensions Establishment (ICE), and indicates the ICE options or extensions
used by the agent. used by the agent.
Appropriate Values: See Section 15 of RFC XXXX [Note to RFC-ed: Appropriate Values: See Section 15 of RFC XXXX [Note to RFC-ed:
please replace XXXX with the RFC number of this specification]. please replace XXXX with the RFC number of this specification].
19.2. STUN Attributes 19.2. STUN Attributes
This section registers two new STUN attributes per the procedures in This section registers four new STUN attributes per the procedures in
[12]. [12].
0x0024 PRIORITY 0x0024 PRIORITY
0x0025 USE-CANDIDATE 0x0025 USE-CANDIDATE
0x8029 ICE-CONTROLLED
0x802a ICE-CONTROLLING
19.3. STUN Error Responses
This section registers one new STUN error response code per the
procedures in [12].
487 Role Conflict
20. IAB Considerations 20. IAB Considerations
The IAB has studied the problem of "Unilateral Self Address Fixing", The IAB has studied the problem of "Unilateral Self Address Fixing",
which is the general process by which a agent attempts to determine which is the general process by which a agent attempts to determine
its address in another realm on the other side of a NAT through a its address in another realm on the other side of a NAT through a
collaborative protocol reflection mechanism [21]. ICE is an example collaborative protocol reflection mechanism [21]. ICE is an example
of a protocol that performs this type of function. Interestingly, of a protocol that performs this type of function. Interestingly,
the process for ICE is not unilateral, but bilateral, and the the process for ICE is not unilateral, but bilateral, and the
difference has a signficant impact on the issues raised by IAB. difference has a signficant impact on the issues raised by IAB.
skipping to change at page 85, line 32 skipping to change at page 90, line 32
for IP addresses, either in text or binary form within a packet, and for IP addresses, either in text or binary form within a packet, and
rewrite them if they match a binding. This interferes with rewrite them if they match a binding. This interferes with
traditional STUN. However, the update to STUN [12] uses an encoding traditional STUN. However, the update to STUN [12] uses an encoding
which hides these binary addresses from generic ALGs. which hides these binary addresses from generic ALGs.
Existing NAPT boxes have non-deterministic and typically short Existing NAPT boxes have non-deterministic and typically short
expiration times for UDP-based bindings. This requires expiration times for UDP-based bindings. This requires
implementations to send periodic keepalives to maintain those implementations to send periodic keepalives to maintain those
bindings. ICE uses a default of 15s, which is a very conservative bindings. ICE uses a default of 15s, which is a very conservative
estimate. Eventually, over time, as NAT boxes become compliant to estimate. Eventually, over time, as NAT boxes become compliant to
behave [34], this minimum keepalive will become deterministic and behave [29], this minimum keepalive will become deterministic and
well-known, and the ICE timers can be adjusted. Having a way to well-known, and the ICE timers can be adjusted. Having a way to
discover and control the minimum keepalive interval would be far discover and control the minimum keepalive interval would be far
better still. better still.
21. Acknowledgements 21. Acknowledgements
The authors would like to thank Dan Wing, Eric Rescorla, Flemming The authors would like to thank Dan Wing, Eric Rescorla, Flemming
Andreasen, Rohan Mahy, Dean Willis, Eric Cooper, Jason Fischl, Andreasen, Rohan Mahy, Dean Willis, Eric Cooper, Jason Fischl,
Douglas Otis, Tim Moore, Jean-Francois Mule, and Francois Audet for Douglas Otis, Tim Moore, Jean-Francois Mule, Jonathan Lennox and
their comments and input. A special thanks goes to Bill May, who Francois Audet for their comments and input. A special thanks goes
suggested several of the concepts in this specification, Philip to Bill May, who suggested several of the concepts in this
Matthews, who suggested many of the key performance optimizations in specification, Philip Matthews, who suggested many of the key
this specification, Eric Rescorla, who drafted the text in the performance optimizations in this specification, Eric Rescorla, who
introduction, and Magnus Westerlund, for doing several detailed drafted the text in the introduction, and Magnus Westerlund, for
reviews on the various revisions of this specification. doing several detailed reviews on the various revisions of this
specification.
22. References 22. References
22.1. Normative References 22.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Huitema, C., "Real Time Control Protocol (RTCP) attribute in [2] Huitema, C., "Real Time Control Protocol (RTCP) attribute in
Session Description Protocol (SDP)", RFC 3605, October 2003. Session Description Protocol (SDP)", RFC 3605, October 2003.
skipping to change at page 88, line 33 skipping to change at page 93, line 33
[31] Andreasen, F., "A No-Op Payload Format for RTP", [31] Andreasen, F., "A No-Op Payload Format for RTP",
draft-ietf-avt-rtp-no-op-00 (work in progress), May 2005. draft-ietf-avt-rtp-no-op-00 (work in progress), May 2005.
[32] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion [32] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion
Control Protocol (DCCP)", RFC 4340, March 2006. Control Protocol (DCCP)", RFC 4340, March 2006.
[33] Hellstrom, G. and P. Jones, "RTP Payload for Text [33] Hellstrom, G. and P. Jones, "RTP Payload for Text
Conversation", RFC 4103, June 2005. Conversation", RFC 4103, June 2005.
[34] Audet, F. and C. Jennings, "NAT Behavioral Requirements for [34] Jennings, C. and R. Mahy, "Managing Client Initiated
Unicast UDP", draft-ietf-behave-nat-udp-08 (work in progress),
October 2006.
[35] Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)", Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-07 (work in progress), January 2007. draft-ietf-sip-outbound-07 (work in progress), January 2007.
[36] Rescorla, E., "Overview of the Lite Implementation of
Interactive Connectivity Establishment (ICE)",
draft-ietf-mmusic-ice-lite-00.txt (work in progress),
January 2007.
Appendix A. Lite and Full Implementations Appendix A. Lite and Full Implementations
ICE allows for two types of implementations. A full implementation ICE allows for two types of implementations. A full implementation
supports the controlling and controlled roles in a session, and can supports the controlling and controlled roles in a session, and can
also perform address gathering. In contrast, a lite implementation also perform address gathering. In contrast, a lite implementation
is a minimalist implementation that does little but respond to STUN is a minimalist implementation that does little but respond to STUN
checks. checks.
Because ICE requires both endpoints to support it in order to bring Because ICE requires both endpoints to support it in order to bring
benefits to either endpoint, incremental deployment of ICE in a benefits to either endpoint, incremental deployment of ICE in a
skipping to change at page 90, line 26 skipping to change at page 95, line 15
transmission of these packets on the network makes use of bandwidth transmission of these packets on the network makes use of bandwidth
and needs to be rate limited by the agent. As a consequence, the and needs to be rate limited by the agent. As a consequence, the
pacing ensures that the NAT devices does not get overloaded and that pacing ensures that the NAT devices does not get overloaded and that
traffic is kept at a reasonable rate. traffic is kept at a reasonable rate.
B.2. Candidates with Multiple Bases B.2. Candidates with Multiple Bases
Section 4.1.1 talks about merging together candidates that are Section 4.1.1 talks about merging together candidates that are
identical but have different bases. When can an agent have two identical but have different bases. When can an agent have two
candidates that have the same IP address and port, but different candidates that have the same IP address and port, but different
bases? Consider the topology of Figure 22: bases? Consider the topology of Figure 23:
+----------+ +----------+
| STUN Srvr| | STUN Srvr|
+----------+ +----------+
| |
| |
----- -----
// \\ // \\
| | | |
| B:net10 | | B:net10 |
skipping to change at page 91, line 41 skipping to change at page 96, line 41
| |
| |
|192.168.1.1 ----- |192.168.1.1 -----
+----------+ // \\ +----------+ +----------+ // \\ +----------+
| | | | | | | | | | | |
| Offerer |---------| C:net10 |---------| Answerer | | Offerer |---------| C:net10 |---------| Answerer |
| |10.0.1.1 | | 10.0.1.2 | | | |10.0.1.1 | | 10.0.1.2 | |
+----------+ \\ // +----------+ +----------+ \\ // +----------+
----- -----
Figure 22: Identical Candidates with Different Bases Figure 23: Identical Candidates with Different Bases
In this case, the offerer is multi-homed. It has one interface, In this case, the offerer is multi-homed. It has one interface,
10.0.1.1, on network C, which is a net 10 private network. The 10.0.1.1, on network C, which is a net 10 private network. The
Answerer is on this same network. The offerer is also connected to Answerer is on this same network. The offerer is also connected to
network A, which is 192.168/16. The offerer has an interface of network A, which is 192.168/16. The offerer has an interface of
192.168.1.1 on this network. There is a NAT on this network, natting 192.168.1.1 on this network. There is a NAT on this network, natting
into network B, which is another net 10 private network, but not into network B, which is another net 10 private network, but not
connected to network C. There is a STUN server on network B. connected to network C. There is a STUN server on network B.
The offerer obtains a host candidate on its interface on network C The offerer obtains a host candidate on its interface on network C
skipping to change at page 94, line 19 skipping to change at page 99, line 19
last part of the expression. The factor of 2*32 is used since the last part of the expression. The factor of 2*32 is used since the
priority of a single candidate is always less than 2*32, resulting in priority of a single candidate is always less than 2*32, resulting in
the pair priority being a "concatenation" of the two component the pair priority being a "concatenation" of the two component
priorities. This creates the desired sorting property. priorities. This creates the desired sorting property.
B.6. The remote-candidates attribute B.6. The remote-candidates attribute
The a=remote-candidates attribute exists to eliminate a race The a=remote-candidates attribute exists to eliminate a race
condition between the updated offer and the response to the STUN condition between the updated offer and the response to the STUN
Binding Request that moved a candidate into the Valid list. This Binding Request that moved a candidate into the Valid list. This
race condition is shown in Figure 23. On receipt of message 4, agent race condition is shown in Figure 24. On receipt of message 4, agent
L adds a candidate pair to the valid list. If there was only a L adds a candidate pair to the valid list. If there was only a
single media stream with a single component, agent L could now send single media stream with a single component, agent L could now send
an updated offer. However, the check from agent R has not yet an updated offer. However, the check from agent R has not yet
generated a response, and agent R receives the updated offer (message generated a response, and agent R receives the updated offer (message
7) before getting the response (message 10). Thus, it does not yet 7) before getting the response (message 9). Thus, it does not yet
know that this particular pair is valid. To eliminate this know that this particular pair is valid. To eliminate this
condition, the actual candidates at R that were selected by the condition, the actual candidates at R that were selected by the
offerer (the remote candidates) are included in the offer itself. offerer (the remote candidates) are included in the offer itself, and
Note, however, that agent R will not send media until it has received the answerer delays its answer until those pairs validate.
this STUN response.
Agent L Network Agent R Agent A Network Agent B
|(1) Offer | | |(1) Offer | |
|------------------------------------------>| |------------------------------------------>|
|(2) Answer | | |(2) Answer | |
|<------------------------------------------| |<------------------------------------------|
|(3) STUN Req. | | |(3) STUN Req. | |
|------------------------------------------>| |------------------------------------------>|
|(4) STUN Res. | | |(4) STUN Res. | |
|<------------------------------------------| |<------------------------------------------|
|(5) STUN Req. | | |(5) STUN Req. | |
|<------------------------------------------| |<------------------------------------------|
|(6) STUN Res. | | |(6) STUN Res. | |
|-------------------->| | |-------------------->| |
| |Lost | | |Lost |
|(7) Offer | | |(7) Offer | |
|------------------------------------------>| |------------------------------------------>|
|(8) Answer | | |(8) STUN Req. | |
|<------------------------------------------|
|(9) STUN Req. | |
|<------------------------------------------| |<------------------------------------------|
|(10) STUN Res. | | |(9) STUN Res. | |
|------------------------------------------>| |------------------------------------------>|
|(10) Answer | |
|<------------------------------------------|
Figure 23: Race Condition Flow Figure 24: Race Condition Flow
B.7. Why are Keepalives Needed? B.7. Why are Keepalives Needed?
Once media begins flowing on a candidate pair, it is still necessary Once media begins flowing on a candidate pair, it is still necessary
to keep the bindings alive at intermediate NATs for the duration of to keep the bindings alive at intermediate NATs for the duration of
the session. Normally, the media stream packets themselves (e.g., the session. Normally, the media stream packets themselves (e.g.,
RTP) meet this objective. However, several cases merit further RTP) meet this objective. However, several cases merit further
discussion. Firstly, in some RTP usages, such as SIP, the media discussion. Firstly, in some RTP usages, such as SIP, the media
streams can be "put on hold". This is accomplished by using the SDP streams can be "put on hold". This is accomplished by using the SDP
"sendonly" or "inactive" attributes, as defined in RFC 3264 [4]. RFC "sendonly" or "inactive" attributes, as defined in RFC 3264 [4]. RFC
 End of changes. 94 change blocks. 
332 lines changed or deleted 517 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/