draft-ietf-mmusic-ice-15.txt   draft-ietf-mmusic-ice-16.txt 
MMUSIC J. Rosenberg MMUSIC J. Rosenberg
Internet-Draft Cisco Internet-Draft Cisco
Obsoletes: 4091 (if approved) March 26, 2007 Obsoletes: 4091 (if approved) June 12, 2007
Intended status: Standards Track Intended status: Standards Track
Expires: September 27, 2007 Expires: December 14, 2007
Interactive Connectivity Establishment (ICE): A Methodology for Network Interactive Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal for Offer/Answer Protocols Address Translator (NAT) Traversal for Offer/Answer Protocols
draft-ietf-mmusic-ice-15 draft-ietf-mmusic-ice-16
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 36 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 27, 2007. This Internet-Draft will expire on December 14, 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 . . . . . . . . . . . . . . . . . . . . . . . . 7
2. Overview of ICE . . . . . . . . . . . . . . . . . . . . . . . 7 2. Overview of ICE . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Gathering Candidate Addresses . . . . . . . . . . . . . . 9 2.1. Gathering Candidate Addresses . . . . . . . . . . . . . . 10
2.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 11 2.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 12
2.3. Sorting Candidates . . . . . . . . . . . . . . . . . . . 12 2.3. Sorting Candidates . . . . . . . . . . . . . . . . . . . 13
2.4. Frozen Candidates . . . . . . . . . . . . . . . . . . . . 13 2.4. Frozen Candidates . . . . . . . . . . . . . . . . . . . . 14
2.5. Security for Checks . . . . . . . . . . . . . . . . . . . 14 2.5. Security for Checks . . . . . . . . . . . . . . . . . . . 15
2.6. Concluding ICE . . . . . . . . . . . . . . . . . . . . . 14 2.6. Concluding ICE . . . . . . . . . . . . . . . . . . . . . 15
2.7. Lite Implementations . . . . . . . . . . . . . . . . . . 16 2.7. Lite Implementations . . . . . . . . . . . . . . . . . . 17
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 16 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 17
4. Sending the Initial Offer . . . . . . . . . . . . . . . . . . 19 4. Sending the Initial Offer . . . . . . . . . . . . . . . . . . 20
4.1. Full Implementation Requirements . . . . . . . . . . . . 19 4.1. Full Implementation Requirements . . . . . . . . . . . . 20
4.1.1. Gathering Candidates . . . . . . . . . . . . . . . . 19 4.1.1. Gathering Candidates . . . . . . . . . . . . . . . . 20
4.1.1.1. Host Candidates . . . . . . . . . . . . . . . . . 19 4.1.1.1. Host Candidates . . . . . . . . . . . . . . . . . 21
4.1.1.2. Server Reflexive and Relayed Candidates . . . . . 20 4.1.1.2. Server Reflexive and Relayed Candidates . . . . . 21
4.1.1.3. Eliminating Redundant Candidates . . . . . . . . 21 4.1.1.3. Eliminating Redundant Candidates . . . . . . . . 23
4.1.1.4. Computing Foundations . . . . . . . . . . . . . . 21 4.1.1.4. Computing Foundations . . . . . . . . . . . . . . 23
4.1.1.5. Keeping Candidates Alive . . . . . . . . . . . . 22 4.1.1.5. Keeping Candidates Alive . . . . . . . . . . . . 23
4.1.2. Prioritizing Candidates . . . . . . . . . . . . . . . 22 4.1.2. Prioritizing Candidates . . . . . . . . . . . . . . . 24
4.1.2.1. Recommended Formula . . . . . . . . . . . . . . . 22 4.1.2.1. Recommended Formula . . . . . . . . . . . . . . . 24
4.1.2.2. Guidelines for Choosing Type and Local 4.1.2.2. Guidelines for Choosing Type and Local
Preferences . . . . . . . . . . . . . . . . . . . 23 Preferences . . . . . . . . . . . . . . . . . . . 25
4.1.3. Choosing Default Candidates . . . . . . . . . . . . . 24 4.1.3. Choosing Default Candidates . . . . . . . . . . . . . 26
4.2. Lite Implementation . . . . . . . . . . . . . . . . . . . 25 4.2. Lite Implementation . . . . . . . . . . . . . . . . . . . 26
4.3. Encoding the SDP . . . . . . . . . . . . . . . . . . . . 25 4.3. Encoding the SDP . . . . . . . . . . . . . . . . . . . . 27
5. Receiving the Initial Offer . . . . . . . . . . . . . . . . . 27 5. Receiving the Initial Offer . . . . . . . . . . . . . . . . . 29
5.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 27 5.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 29
5.2. Determining Role . . . . . . . . . . . . . . . . . . . . 28 5.2. Determining Role . . . . . . . . . . . . . . . . . . . . 30
5.3. Gathering Candidates . . . . . . . . . . . . . . . . . . 28 5.3. Gathering Candidates . . . . . . . . . . . . . . . . . . 31
5.4. Prioritizing Candidates . . . . . . . . . . . . . . . . . 29 5.4. Prioritizing Candidates . . . . . . . . . . . . . . . . . 31
5.5. Choosing Default Candidates . . . . . . . . . . . . . . . 29 5.5. Choosing Default Candidates . . . . . . . . . . . . . . . 31
5.6. Encoding the SDP . . . . . . . . . . . . . . . . . . . . 29 5.6. Encoding the SDP . . . . . . . . . . . . . . . . . . . . 31
5.7. Forming the Check Lists . . . . . . . . . . . . . . . . . 29 5.7. Forming the Check Lists . . . . . . . . . . . . . . . . . 32
5.7.1. Forming Candidate Pairs . . . . . . . . . . . . . . . 29 5.7.1. Forming Candidate Pairs . . . . . . . . . . . . . . . 32
5.7.2. Computing Pair Priority and Ordering Pairs . . . . . 32 5.7.2. Computing Pair Priority and Ordering Pairs . . . . . 34
5.7.3. Pruning the Pairs . . . . . . . . . . . . . . . . . . 32 5.7.3. Pruning the Pairs . . . . . . . . . . . . . . . . . . 34
5.7.4. Computing States . . . . . . . . . . . . . . . . . . 32 5.7.4. Computing States . . . . . . . . . . . . . . . . . . 34
5.8. Performing Periodic Checks . . . . . . . . . . . . . . . 35 5.8. Scheduling Checks . . . . . . . . . . . . . . . . . . . . 37
6. Receipt of the Initial Answer . . . . . . . . . . . . . . . . 37 6. Receipt of the Initial Answer . . . . . . . . . . . . . . . . 39
6.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 37 6.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 39
6.2. Determining Role . . . . . . . . . . . . . . . . . . . . 37 6.2. Determining Role . . . . . . . . . . . . . . . . . . . . 40
6.3. Forming the Check List . . . . . . . . . . . . . . . . . 37 6.3. Forming the Check List . . . . . . . . . . . . . . . . . 40
6.4. Performing Periodic Checks . . . . . . . . . . . . . . . 37 6.4. Performing Ordinary Checks . . . . . . . . . . . . . . . 40
7. Performing Connectivity Checks . . . . . . . . . . . . . . . 37 7. Performing Connectivity Checks . . . . . . . . . . . . . . . 40
7.1. Client Procedures . . . . . . . . . . . . . . . . . . . . 38 7.1. STUN Client Procedures . . . . . . . . . . . . . . . . . 40
7.1.1. Sending the Request . . . . . . . . . . . . . . . . . 38 7.1.1. Sending the Request . . . . . . . . . . . . . . . . . 40
7.1.1.1. PRIORITY and USE-CANDIDATE . . . . . . . . . . . 38 7.1.1.1. PRIORITY and USE-CANDIDATE . . . . . . . . . . . 41
7.1.1.2. ICE-CONTROLLED and ICE-CONTROLLING . . . . . . . 38 7.1.1.2. ICE-CONTROLLED and ICE-CONTROLLING . . . . . . . 41
7.1.1.3. Forming Credentials . . . . . . . . . . . . . . . 39 7.1.1.3. FINGERPRINT . . . . . . . . . . . . . . . . . . . 41
7.1.1.4. DiffServ Treatment . . . . . . . . . . . . . . . 39 7.1.1.4. Forming Credentials . . . . . . . . . . . . . . . 41
7.1.2. Processing the Response . . . . . . . . . . . . . . . 39 7.1.1.5. DiffServ Treatment . . . . . . . . . . . . . . . 42
7.1.2.1. Failure Cases . . . . . . . . . . . . . . . . . . 39 7.1.2. Processing the Response . . . . . . . . . . . . . . . 42
7.1.2.2. Success Cases . . . . . . . . . . . . . . . . . . 40 7.1.2.1. Failure Cases . . . . . . . . . . . . . . . . . . 42
7.1.2.2.1. Discovering Peer Reflexive Candidates . . . . 40 7.1.2.2. Success Cases . . . . . . . . . . . . . . . . . . 43
7.1.2.2.2. Updating Pair States . . . . . . . . . . . . 41 7.1.2.2.1. Discovering Peer Reflexive Candidates . . . . 43
7.1.2.2.3. Constructing a Valid Pair . . . . . . . . . . 42 7.1.2.2.2. Constructing a Valid Pair . . . . . . . . . . 44
7.1.2.2.4. Updating the Nominated Flag . . . . . . . . . 42 7.1.2.2.3. Updating Pair States . . . . . . . . . . . . 44
7.1.2.3. Check List and Timer State Updates . . . . . . . 43 7.1.2.2.4. Updating the Nominated Flag . . . . . . . . . 45
7.2. Server Procedures . . . . . . . . . . . . . . . . . . . . 43 7.1.2.3. Check List and Timer State Updates . . . . . . . 46
7.2.1. Additional Procedures for Full Implementations . . . 44 7.2. STUN Server Procedures . . . . . . . . . . . . . . . . . 46
7.2.1.1. Detecting and Repairing Role Conflicts . . . . . 44 7.2.1. Additional Procedures for Full Implementations . . . 47
7.2.1.2. Computing Mapped Address . . . . . . . . . . . . 45 7.2.1.1. Detecting and Repairing Role Conflicts . . . . . 47
7.2.1.3. Learning Peer Reflexive Candidates . . . . . . . 45 7.2.1.2. Computing Mapped Address . . . . . . . . . . . . 48
7.2.1.4. Triggered Checks . . . . . . . . . . . . . . . . 46 7.2.1.3. Learning Peer Reflexive Candidates . . . . . . . 48
7.2.1.5. Updating the Nominated Flag . . . . . . . . . . . 47 7.2.1.4. Triggered Checks . . . . . . . . . . . . . . . . 49
7.2.2. Additional Procedures for Lite Implementations . . . 47 7.2.1.5. Updating the Nominated Flag . . . . . . . . . . . 50
8. Concluding ICE Processing . . . . . . . . . . . . . . . . . . 47 7.2.2. Additional Procedures for Lite Implementations . . . 51
8.1. Nominating Pairs . . . . . . . . . . . . . . . . . . . . 48 8. Concluding ICE Processing . . . . . . . . . . . . . . . . . . 51
8.1.1. Regular Nomination . . . . . . . . . . . . . . . . . 48 8.1. Procedures for Full Implementations . . . . . . . . . . . 51
8.1.2. Aggressive Nomination . . . . . . . . . . . . . . . . 49 8.1.1. Nominating Pairs . . . . . . . . . . . . . . . . . . 51
8.2. Updating States . . . . . . . . . . . . . . . . . . . . . 49 8.1.1.1. Regular Nomination . . . . . . . . . . . . . . . 51
9. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . . . 50 8.1.1.2. Aggressive Nomination . . . . . . . . . . . . . . 52
9.1. Generating the Offer . . . . . . . . . . . . . . . . . . 51 8.1.2. Updating States . . . . . . . . . . . . . . . . . . . 52
9.1.1. Procedures for All Implementations . . . . . . . . . 51 8.2. Procedures for Lite Implementations . . . . . . . . . . . 54
9.1.1.1. ICE Restarts . . . . . . . . . . . . . . . . . . 51 8.2.1. Peer is Full . . . . . . . . . . . . . . . . . . . . 54
9.1.1.2. Removing a Media Stream . . . . . . . . . . . . . 52 8.2.2. Peer is Lite . . . . . . . . . . . . . . . . . . . . 54
9.1.1.3. Adding a Media Stream . . . . . . . . . . . . . . 52 8.3. Freeing Candidates . . . . . . . . . . . . . . . . . . . 55
9.1.2. Procedures for Full Implementations . . . . . . . . . 52 8.3.1. Full Implementation Procedures . . . . . . . . . . . 55
9.1.2.1. Existing Media Streams with ICE Running . . . . . 52 8.3.2. Lite Implementations . . . . . . . . . . . . . . . . 56
9.1.2.2. Existing Media Streams with ICE Completed . . . . 53 9. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . . . 56
9.1.3. Procedures for Lite Implementations . . . . . . . . . 53 9.1. Generating the Offer . . . . . . . . . . . . . . . . . . 56
9.2. Receiving the Offer and Generating an Answer . . . . . . 53 9.1.1. Procedures for All Implementations . . . . . . . . . 56
9.2.1. Procedures for All Implementations . . . . . . . . . 53 9.1.1.1. ICE Restarts . . . . . . . . . . . . . . . . . . 56
9.2.1.1. Detecting ICE Restart . . . . . . . . . . . . . . 54 9.1.1.2. Removing a Media Stream . . . . . . . . . . . . . 57
9.2.1.2. New Media Stream . . . . . . . . . . . . . . . . 54 9.1.1.3. Adding a Media Stream . . . . . . . . . . . . . . 57
9.2.1.3. Removed Media Stream . . . . . . . . . . . . . . 54 9.1.2. Procedures for Full Implementations . . . . . . . . . 57
9.2.2. Procedures for Full Implementations . . . . . . . . . 54 9.1.2.1. Existing Media Streams with ICE Running . . . . . 57
9.1.2.2. Existing Media Streams with ICE Completed . . . . 58
9.1.3. Procedures for Lite Implementations . . . . . . . . . 58
9.1.3.1. Existing Media Streams with ICE Running . . . . . 59
9.1.3.2. Existing Media Streams with ICE Completed . . . . 59
9.2. Receiving the Offer and Generating an Answer . . . . . . 59
9.2.1. Procedures for All Implementations . . . . . . . . . 59
9.2.1.1. Detecting ICE Restart . . . . . . . . . . . . . . 60
9.2.1.2. New Media Stream . . . . . . . . . . . . . . . . 60
9.2.1.3. Removed Media Stream . . . . . . . . . . . . . . 60
9.2.2. Procedures for Full Implementations . . . . . . . . . 60
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 . . . . . . . . . . . . . . . . 55 remote-candidates . . . . . . . . . . . . . . . . 61
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 . . . . . . . . . . . . . . 55 no remote-candidates . . . . . . . . . . . . . . 61
9.2.2.3. Existing Media Streams and remote-candidates . . 55 9.2.2.3. Existing Media Streams and remote-candidates . . 61
9.2.3. Procedures for Lite Implementations . . . . . . . . . 56 9.2.3. Procedures for Lite Implementations . . . . . . . . . 62
9.3. Updating the Check and Valid Lists . . . . . . . . . . . 56 9.3. Updating the Check and Valid Lists . . . . . . . . . . . 63
9.3.1. Procedures for Full Implementations . . . . . . . . . 56 9.3.1. Procedures for Full Implementations . . . . . . . . . 63
9.3.1.1. ICE Restarts . . . . . . . . . . . . . . . . . . 56 9.3.1.1. ICE Restarts . . . . . . . . . . . . . . . . . . 63
9.3.1.2. New Media Stream . . . . . . . . . . . . . . . . 56 9.3.1.2. New Media Stream . . . . . . . . . . . . . . . . 63
9.3.1.3. Removed Media Stream . . . . . . . . . . . . . . 56 9.3.1.3. Removed Media Stream . . . . . . . . . . . . . . 63
9.3.1.4. ICE Continuing for Existing Media Stream . . . . 57 9.3.1.4. ICE Continuing for Existing Media Stream . . . . 63
9.3.2. Procedures for Lite Implementations . . . . . . . . . 57 9.3.2. Procedures for Lite Implementations . . . . . . . . . 64
10. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 57 10. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 64
11. Media Handling . . . . . . . . . . . . . . . . . . . . . . . 58 11. Media Handling . . . . . . . . . . . . . . . . . . . . . . . 65
11.1. Sending Media . . . . . . . . . . . . . . . . . . . . . . 58 11.1. Sending Media . . . . . . . . . . . . . . . . . . . . . . 65
11.1.1. Procedures for Full Implementations . . . . . . . . . 59 11.1.1. Procedures for Full Implementations . . . . . . . . . 65
11.1.2. Procedures for Lite Implementations . . . . . . . . . 59 11.1.2. Procedures for Lite Implementations . . . . . . . . . 66
11.1.3. Procedures for All Implementations . . . . . . . . . 60 11.1.3. Procedures for All Implementations . . . . . . . . . 66
11.2. Receiving Media . . . . . . . . . . . . . . . . . . . . . 60 11.2. Receiving Media . . . . . . . . . . . . . . . . . . . . . 67
12. Usage with SIP . . . . . . . . . . . . . . . . . . . . . . . 60 12. Usage with SIP . . . . . . . . . . . . . . . . . . . . . . . 67
12.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . 60 12.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . 67
12.1.1. Offer in INVITE . . . . . . . . . . . . . . . . . . . 61 12.1.1. Offer in INVITE . . . . . . . . . . . . . . . . . . . 67
12.1.2. Offer in Response . . . . . . . . . . . . . . . . . . 62 12.1.2. Offer in Response . . . . . . . . . . . . . . . . . . 69
12.2. SIP Option Tags and Media Feature Tags . . . . . . . . . 63 12.2. SIP Option Tags and Media Feature Tags . . . . . . . . . 69
12.3. Interactions with Forking . . . . . . . . . . . . . . . . 63 12.3. Interactions with Forking . . . . . . . . . . . . . . . . 69
12.4. Interactions with Preconditions . . . . . . . . . . . . . 63 12.4. Interactions with Preconditions . . . . . . . . . . . . . 70
12.5. Interactions with Third Party Call Control . . . . . . . 63 12.5. Interactions with Third Party Call Control . . . . . . . 70
13. Relationship with ANAT . . . . . . . . . . . . . . . . . . . 64 13. Relationship with ANAT . . . . . . . . . . . . . . . . . . . 71
14. Extensibility Considerations . . . . . . . . . . . . . . . . 64 14. Extensibility Considerations . . . . . . . . . . . . . . . . 71
15. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 15. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
15.1. "candidate" Attribute . . . . . . . . . . . . . . . . . . 65 15.1. "candidate" Attribute . . . . . . . . . . . . . . . . . . 72
15.2. "remote-candidates" Attribute . . . . . . . . . . . . . . 67 15.2. "remote-candidates" Attribute . . . . . . . . . . . . . . 74
15.3. "ice-lite" and "ice-mismatch" Attributes . . . . . . . . 68 15.3. "ice-lite" and "ice-mismatch" Attributes . . . . . . . . 75
15.4. "ice-ufrag" and "ice-pwd" Attributes . . . . . . . . . . 68 15.4. "ice-ufrag" and "ice-pwd" Attributes . . . . . . . . . . 75
15.5. "ice-options> Attribute . . . . . . . . . . . . . . . . . 69 15.5. "ice-options" Attribute . . . . . . . . . . . . . . . . . 76
16. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 16. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
17. Security Considerations . . . . . . . . . . . . . . . . . . . 76 17. Security Considerations . . . . . . . . . . . . . . . . . . . 83
17.1. Attacks on Connectivity Checks . . . . . . . . . . . . . 76 17.1. Attacks on Connectivity Checks . . . . . . . . . . . . . 83
17.2. Attacks on Address Gathering . . . . . . . . . . . . . . 78 17.2. Attacks on Address Gathering . . . . . . . . . . . . . . 85
17.3. Attacks on the Offer/Answer Exchanges . . . . . . . . . . 79 17.3. Attacks on the Offer/Answer Exchanges . . . . . . . . . . 86
17.4. Insider Attacks . . . . . . . . . . . . . . . . . . . . . 79 17.4. Insider Attacks . . . . . . . . . . . . . . . . . . . . . 86
17.4.1. The Voice Hammer Attack . . . . . . . . . . . . . . . 80 17.4.1. The Voice Hammer Attack . . . . . . . . . . . . . . . 87
17.4.2. STUN Amplification Attack . . . . . . . . . . . . . . 80 17.4.2. STUN Amplification Attack . . . . . . . . . . . . . . 87
17.5. Interactions with Application Layer Gateways and SIP . . 81 17.5. Interactions with Application Layer Gateways and SIP . . 88
18. Definition of Connectivity Check Usage . . . . . . . . . . . 81 18. Definition of Connectivity Check Usage . . . . . . . . . . . 89
18.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 82 18.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 89
18.2. Client Discovery of Server . . . . . . . . . . . . . . . 82 18.2. Client Discovery of Server . . . . . . . . . . . . . . . 89
18.3. Server Determination of Usage . . . . . . . . . . . . . . 82 18.3. Server Determination of Usage . . . . . . . . . . . . . . 89
18.4. New Requests or Indications . . . . . . . . . . . . . . . 82 18.4. New Requests or Indications . . . . . . . . . . . . . . . 89
18.5. New Attributes . . . . . . . . . . . . . . . . . . . . . 82 18.5. New Attributes . . . . . . . . . . . . . . . . . . . . . 90
18.6. New Error Response Codes . . . . . . . . . . . . . . . . 83 18.6. New Error Response Codes . . . . . . . . . . . . . . . . 90
18.7. Client Procedures . . . . . . . . . . . . . . . . . . . . 83 18.7. Client Procedures . . . . . . . . . . . . . . . . . . . . 90
18.8. Server Procedures . . . . . . . . . . . . . . . . . . . . 83 18.8. Server Procedures . . . . . . . . . . . . . . . . . . . . 90
18.9. Security Considerations for Connectivity Check . . . . . 83 18.9. Security Considerations for Connectivity Check . . . . . 91
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 83 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 91
19.1. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 84 19.1. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 91
19.1.1. candidate Attribute . . . . . . . . . . . . . . . . . 84 19.1.1. candidate Attribute . . . . . . . . . . . . . . . . . 91
19.1.2. remote-candidates Attribute . . . . . . . . . . . . . 84 19.1.2. remote-candidates Attribute . . . . . . . . . . . . . 91
19.1.3. ice-lite Attribute . . . . . . . . . . . . . . . . . 85 19.1.3. ice-lite Attribute . . . . . . . . . . . . . . . . . 92
19.1.4. ice-mismatch Attribute . . . . . . . . . . . . . . . 85 19.1.4. ice-mismatch Attribute . . . . . . . . . . . . . . . 92
19.1.5. ice-pwd Attribute . . . . . . . . . . . . . . . . . . 86 19.1.5. ice-pwd Attribute . . . . . . . . . . . . . . . . . . 93
19.1.6. ice-ufrag Attribute . . . . . . . . . . . . . . . . . 86 19.1.6. ice-ufrag Attribute . . . . . . . . . . . . . . . . . 93
19.1.7. ice-options Attribute . . . . . . . . . . . . . . . . 86 19.1.7. ice-options Attribute . . . . . . . . . . . . . . . . 94
19.2. STUN Attributes . . . . . . . . . . . . . . . . . . . . . 87 19.2. STUN Attributes . . . . . . . . . . . . . . . . . . . . . 94
19.3. STUN Error Responses . . . . . . . . . . . . . . . . . . 87 19.3. STUN Error Responses . . . . . . . . . . . . . . . . . . 94
20. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 87 20. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 94
20.1. Problem Definition . . . . . . . . . . . . . . . . . . . 88 20.1. Problem Definition . . . . . . . . . . . . . . . . . . . 95
20.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 88 20.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 95
20.3. Brittleness Introduced by ICE . . . . . . . . . . . . . . 89 20.3. Brittleness Introduced by ICE . . . . . . . . . . . . . . 96
20.4. Requirements for a Long Term Solution . . . . . . . . . . 89 20.4. Requirements for a Long Term Solution . . . . . . . . . . 97
20.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 90 20.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 97
21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 90 21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 98
22. References . . . . . . . . . . . . . . . . . . . . . . . . . 91 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 98
22.1. Normative References . . . . . . . . . . . . . . . . . . 91 22.1. Normative References . . . . . . . . . . . . . . . . . . 98
22.2. Informative References . . . . . . . . . . . . . . . . . 92 22.2. Informative References . . . . . . . . . . . . . . . . . 99
Appendix A. Lite and Full Implementations . . . . . . . . . . . 93 Appendix A. Lite and Full Implementations . . . . . . . . . . . 101
Appendix B. Design Motivations . . . . . . . . . . . . . . . . . 94 Appendix B. Design Motivations . . . . . . . . . . . . . . . . . 102
B.1. Pacing of STUN Transactions . . . . . . . . . . . . . . . 94 B.1. Pacing of STUN Transactions . . . . . . . . . . . . . . . 102
B.2. Candidates with Multiple Bases . . . . . . . . . . . . . 95 B.2. Candidates with Multiple Bases . . . . . . . . . . . . . 103
B.3. Purpose of the <rel-addr> and <rel-port> Attributes . . . 97 B.3. Purpose of the <rel-addr> and <rel-port> Attributes . . . 105
B.4. Importance of the STUN Username . . . . . . . . . . . . . 97 B.4. Importance of the STUN Username . . . . . . . . . . . . . 105
B.5. The Candidate Pair Sequence Number Formula . . . . . . . 98 B.5. The Candidate Pair Sequence Number Formula . . . . . . . 106
B.6. The remote-candidates attribute . . . . . . . . . . . . . 99 B.6. The remote-candidates attribute . . . . . . . . . . . . . 107
B.7. Why are Keepalives Needed? . . . . . . . . . . . . . . . 100 B.7. Why are Keepalives Needed? . . . . . . . . . . . . . . . 108
B.8. Why Prefer Peer Reflexive Candidates? . . . . . . . . . . 101 B.8. Why Prefer Peer Reflexive Candidates? . . . . . . . . . . 109
B.9. Why Send an Updated Offer? . . . . . . . . . . . . . . . 101 B.9. Why Send an Updated Offer? . . . . . . . . . . . . . . . 109
B.10. Why are Binding Indications Used for Keepalives? . . . . 101 B.10. Why are Binding Indications Used for Keepalives? . . . . 109
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 102 B.11. Why is the Conflict Resolution Mechanism Needed? . . . . 110
Intellectual Property and Copyright Statements . . . . . . . . . 103 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 111
Intellectual Property and Copyright Statements . . . . . . . . . 112
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
flow of media packets, they tend to carry the IP of media sources and flow of media packets, they tend to carry the IP addresses and ports
sinks within their messages, which is known to be problematic through of media sources and sinks within their messages, which is known to
NAT [16]. The protocols also seek to create a media flow directly be problematic through NAT [17]. The protocols also seek to create a
between participants, so that there is no application layer media flow directly between participants, so that there is no
intermediary between them. This is done to reduce media latency, application layer intermediary between them. This is done to reduce
decrease packet loss, and reduce the operational costs of deploying media latency, decrease packet loss, and reduce the operational costs
the application. However, this is difficult to accomplish through of deploying the application. However, this is difficult to
NAT. A full treatment of the reasons for this is beyond the scope of accomplish through NAT. A full treatment of the reasons for this is
this specification. beyond the scope of this specification.
Numerous solutions have been proposed for allowing these protocols to Numerous solutions have been proposed for allowing these protocols to
operate through NAT. These include Application Layer Gateways operate through NAT. These include Application Layer Gateways
(ALGs), the Middlebox Control Protocol [17], Simple Traversal (ALGs), the Middlebox Control Protocol [18], Simple Traversal
Underneath NAT (STUN) [15] and its revision, retitled Session Underneath NAT (STUN) [16] and its revision, retitled Session
Traversal Utilities for NAT [12], the STUN Relay Usage [13], and Traversal Utilities for NAT [13], the STUN Relay Usage [14], and
Realm Specific IP [19] [20] along with session description extensions Realm Specific IP [20] [21] along with session description extensions
needed to make them work, such as the Session Description Protocol needed to make them work, such as the Session Description Protocol
(SDP) [10] attribute for the Real Time Control Protocol (RTCP) [2]. (SDP) [10] attribute for the Real Time Control Protocol (RTCP) [2].
Unfortunately, these techniques all have pros and cons which make Unfortunately, these techniques all have pros and cons which make
each one optimal in some network topologies, but a poor choice in each one optimal in some network topologies, but a poor choice in
others. The result is that administrators and implementors are others. The result is that administrators and implementors are
making assumptions about the topologies of the networks in which making assumptions about the topologies of the networks in which
their solutions will be deployed. This introduces complexity and their solutions will be deployed. This introduces complexity and
brittleness into the system. What is needed is a single solution brittleness into the system. What is needed is a single solution
which is flexible enough to work well in all situations. which is flexible enough to work well in all situations.
This specification defines Interactive Connectivity Establishment This specification defines Interactive Connectivity Establishment
(ICE) as a technique for NAT traversal for media streams established (ICE) as a technique for NAT traversal for media streams established
by the offer/answer model. ICE is an extension to the offer/answer by the offer/answer model. ICE is an extension to the offer/answer
model, and works by including a multiplicity of IP addresses and model, and works by including a multiplicity of IP addresses and
ports in SDP offers and answers, which are then tested for ports in SDP offers and answers, which are then tested for
connectivity by peer-to-peer STUN exchanges. The IP addresses and connectivity by peer-to-peer STUN exchanges. The IP addresses and
ports included in the SDP are gathered using the STUN binding ports included in the SDP are gathered using the STUN binding
acquisition techniques in [12] and relay allocation procedures in acquisition techniques in [13] and relay allocation procedures in
[13]. [14] Because ICE exchanges a multiplicity of IP addresses and ports
for each media stream, it also allows for address selection for
multi-homed and dual-stack hosts, and for this reason it deprecates
RFC 4091 [11].
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 [34]. At the beginning assumed to be provided via another mechanism [36]. 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 8, line 37 skipping to change at page 9, line 37
| L | | R | | L | | R |
| | | | | | | |
+-------+ +-------+ +-------+ +-------+
Figure 1: ICE Deployment Scenario Figure 1: ICE Deployment Scenario
The basic idea behind ICE is as follows: each agent has a variety of The basic idea behind ICE is as follows: each agent has a variety of
candidate TRANSPORT ADDRESSES (combination of IP address and port) it candidate TRANSPORT ADDRESSES (combination of IP address and port) it
could use to communicate with the other agent. These might include: could use to communicate with the other agent. These might include:
o A transport address on a directly attached network interface or o A transport address on a directly attached network interface
interfaces
o A translated transport address on the public side of a NAT (a o A translated transport address on the public side of a NAT (a
"server reflexive" address) "server reflexive" address)
o The transport address of a media relay the agent is using. o The transport address of a media relay the agent is using.
Potentially, any of L's candidate transport addresses can be used to Potentially, any of L's candidate transport addresses can be used to
communicate with any of R's candidate transport addresses. In communicate with any of R's candidate transport addresses. In
practice, however, many combinations will not work. For instance, if practice, however, many combinations will not work. For instance, if
L and R are both behind NATs, their directly attached interface L and R are both behind NATs, their directly attached interface
skipping to change at page 9, line 39 skipping to change at page 10, line 38
candidate from I2 will be directly reachable when communicating with candidate from I2 will be directly reachable when communicating with
a peer on the public Internet. Rather than trying to guess which a peer on the public Internet. Rather than trying to guess which
interface will work prior to sending an offer, the offering agent interface will work prior to sending an offer, the offering agent
includes both candidates in its offer. includes both candidates in its offer.
Next, the agent uses STUN to obtain additional candidates. These Next, the agent uses STUN to obtain additional candidates. These
come in two flavors: translated addresses on the public side of a NAT come in two flavors: translated addresses on the public side of a NAT
(SERVER REFLEXIVE CANDIDATES) and addresses of media relays (RELAYED (SERVER REFLEXIVE CANDIDATES) and addresses of media relays (RELAYED
CANDIDATES). The relationship of these candidates to the host CANDIDATES). The relationship of these candidates to the host
candidate is shown in Figure 2. Both types of candidates are candidate is shown in Figure 2. Both types of candidates are
discovered using STUN. discovered using STUN. In the figure, the notation X:x means IP
address X and port x.
To Internet To Internet
| |
| |
| /------------ Relayed | /------------ Relayed
Y:y | / Address Y:y | / Address
+--------+ +--------+
| | | |
| STUN | | STUN |
skipping to change at page 10, line 36 skipping to change at page 11, line 36
X:x |/ Address X:x |/ Address
+--------+ +--------+
| | | |
| Agent | | Agent |
| | | |
+--------+ +--------+
Figure 2: Candidate Relationships Figure 2: Candidate Relationships
To find a server reflexive candidate, the agent sends a STUN Binding To find a server reflexive candidate, the agent sends a STUN Binding
Request, using the Binding Discovery Usage [12] from each host Request, using the Binding Discovery Usage [13] from each host
candidate, to its STUN server. It is assumed that the address of the candidate, to its STUN server. It is assumed that the address of the
STUN server is manually configured or learned in some unspecified STUN server is manually configured or learned in some unspecified
way. It is RECOMMENDED that when an agent has a choice of STUN way.
servers (when, for example, they are learned through DNS records and
multiple results are returned), an agent uses a single STUN server
(based on its IP address) for all candidates for a particular
session. This improves the performance of ICE.
When the agent sends the Binding Request from IP address and port When the agent sends the Binding Request from IP address and port
X:x, the NAT (assuming there is one) will allocate a binding X1':x1', X:x, the NAT (assuming there is one) will allocate a binding X1':x1',
mapping this server reflexive candidate to the host candidate X:x. mapping this server reflexive candidate to the host candidate X:x.
Outgoing packets sent from the host candidate will be translated by Outgoing packets sent from the host candidate will be translated by
the NAT to the server reflexive candidate. Incoming packets sent to the NAT to the server reflexive candidate. Incoming packets sent to
the server relexive candidate will be translated by the NAT to the the server relexive candidate will be translated by the NAT to the
host candidate and forwarded to the agent. We call the host host candidate and forwarded to the agent. We call the host
candidate associated with a given server reflexive candidate the candidate associated with a given server reflexive candidate the
BASE. BASE.
NOTE: "Base" refers to the address an agent sends from for a NOTE: "Base" refers to the address an agent sends from for a
particular candidate. Thus, as a degenerate case host candidates particular candidate. Thus, as a degenerate case host candidates
also have a base, but it's the same as the host candidate. also have a base, but it's the same as the host candidate.
When there are multiple NATs between the agent and the STUN server, When there are multiple NATs between the agent and the STUN server,
the STUN request will create a binding on each NAT, but only the the STUN request will create a binding on each NAT, but only the
outermost server reflexive candidate will be discovered by the agent. outermost server reflexive candidate (the one nearest the STUN
If the agent is not behind a NAT, then the base candidate will be the server) will be discovered by the agent. If the agent is not behind
same as the server reflexive candidate and the server reflexive a NAT, then the base candidate will be the same as the server
candidate is redundant and will be eliminated. reflexive candidate and the server reflexive candidate is redundant
and will be eliminated.
The final type of candidate is a RELAYED CANDIDATE. The STUN Relay The final type of candidate is a RELAYED CANDIDATE. The STUN Relay
Usage [13] allows a STUN server to act as a media relay, forwarding Usage [14] allows a STUN server to act as a media relay, forwarding
traffic between L and R. In order to send traffic to L, R sends traffic between L and R. In order to send traffic to L, R sends
traffic to the media relay at Y:y, and the relay forwards that to traffic to the media relay at Y:y, and the relay forwards that to
X1':x1', which passes through the NAT where it is mapped to X:x and X1':x1', which passes through the NAT where it is mapped to X:x and
delivered to L. delivered to L.
2.2. Connectivity Checks 2.2. Connectivity Checks
Once L has gathered all of its candidates, it orders them in highest Once L has gathered all of its candidates, it orders them in highest
to lowest priority and sends them to R over the signalling channel. to lowest priority and sends them to R over the signalling channel.
The candidates are carried in attributes in the SDP offer. When R The candidates are carried in attributes in the SDP offer. When R
skipping to change at page 13, line 13 skipping to change at page 14, line 13
has the same ordering for the candidate pairs. has the same ordering for the candidate pairs.
The second property is important for getting ICE to work when there The second property is important for getting ICE to work when there
are NATs in front of L and R. Frequently, NATs will not allow packets are NATs in front of L and R. Frequently, NATs will not allow packets
in from a host until the agent behind the NAT has sent a packet in from a host until the agent behind the NAT has sent a packet
towards that host. Consequently, ICE checks in each direction will towards that host. Consequently, ICE checks in each direction will
not succeed until both sides have sent a check through their not succeed until both sides have sent a check through their
respective NATs. respective NATs.
The agent works through this check list by sending a STUN request for The agent works through this check list by sending a STUN request for
the next candidate pair on the list every 20ms. These are called the next candidate pair on the list periodically. These are called
PERIODIC CHECKS. ORDINARY CHECKS.
In general the priority algorithm is designed so that candidates of In general the priority algorithm is designed so that candidates of
similar type get similar priorities and so that more direct routes similar type get similar priorities and so that more direct routes
(that is, through fewer media relays and through fewer NATs) are (that is, through fewer media relays and through fewer NATs) are
preferred over indirect ones (ones with more media relays and more preferred over indirect ones (ones with more media relays and more
NATs). Within those guidelines, however, agents have a fair amount NATs). Within those guidelines, however, agents have a fair amount
of discretion about how to tune their algorithms. of discretion about how to tune their algorithms.
2.4. Frozen Candidates 2.4. Frozen Candidates
skipping to change at page 13, line 42 skipping to change at page 14, line 42
The network properties are likely to be very similar for each The network properties are likely to be very similar for each
component (especially because RTP and RTCP are sent and received from component (especially because RTP and RTCP are sent and received from
the same IP address). It is usually possible to leverage information the same IP address). It is usually possible to leverage information
from one media component in order to determine the best candidates from one media component in order to determine the best candidates
for another. ICE does this with a mechanism called "frozen for another. ICE does this with a mechanism called "frozen
candidates." candidates."
Each candidate is associated with a property called its FOUNDATION. Each candidate is associated with a property called its FOUNDATION.
Two candidates have the same foundation when they are "similar" - of Two candidates have the same foundation when they are "similar" - of
the same type and obtained from the same interfaces and STUN servers. the same type and obtained from the same interface and STUN server.
Otherwise, their foundation is different. A candidate pair has a Otherwise, their foundation is different. A candidate pair has a
foundation too, which is just the concatenation of the foundations of foundation too, which is just the concatenation of the foundations of
its two candidates. Initially, only the candidate pairs with unique its two candidates. Initially, only the candidate pairs with unique
foundations are tested. The other candidate pairs are marked foundations are tested. The other candidate pairs are marked
"frozen". When the connectivity checks for a candidate pair succeed, "frozen". When the connectivity checks for a candidate pair succeed,
the candidate pairs with the same foundation are unfrozen. This the other candidate pairs with the same foundation are unfrozen.
avoids repeated checking of components which are superficially more This avoids repeated checking of components which are superficially
attractive but in fact are likely to fail. more attractive but in fact are likely to fail.
While we've described "frozen" here as a separate mechanism for While we've described "frozen" here as a separate mechanism for
expository purposes, in fact it is an integral part of ICE and the expository purposes, in fact it is an integral part of ICE and the
the ICE prioritization algorithm automatically ensures that the right the ICE prioritization algorithm automatically ensures that the right
candidates are unfrozen and checked in the right order. candidates are unfrozen and checked in the right order.
2.5. Security for Checks 2.5. Security for Checks
Because ICE is used to discover which addresses can be used to send Because ICE is used to discover which addresses can be used to send
media between two agents, it is important to ensure that the process media between two agents, it is important to ensure that the process
skipping to change at page 14, line 49 skipping to change at page 15, line 49
CONTROLLING AGENT, and the other of the CONTROLLED AGENT. The CONTROLLING AGENT, and the other of the CONTROLLED AGENT. The
controlling agent gets to nominate which candidate pairs will get controlling agent gets to nominate which candidate pairs will get
used for media amongst the ones that are valid. It can do this in used for media amongst the ones that are valid. It can do this in
one of 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. This is shown in Figure 4.
L R L R
- - - -
STUN request \ L's STUN request -> \ L's
<- STUN response / check <- STUN response / check
<- STUN request \ R's <- STUN request \ R's
STUN response -> / check STUN response -> / check
STUN request + flag \ L's STUN request + flag -> \ L's
<- STUN response / check <- STUN response / check
Figure 4: Regular Nomination Figure 4: Regular Nomination
Once the STUN transaction with the flag completes, both sides cancel Once the STUN transaction with the flag completes, both sides cancel
any future checks for that media stream. ICE will now send media any future checks for that media stream. ICE will now send media
using this pair. The pair an ICE agent is using for media is called using this pair. The pair an ICE agent is using for media is called
the SELECTED PAIR. the SELECTED PAIR.
In aggressive nomination, the controlling agent puts the flag in In aggressive nomination, the controlling agent puts the flag in
every STUN request it sends. This way, once the first check every STUN request it sends. This way, once the first check
succeeds, ICE processing is complete for that media stream and the succeeds, ICE processing is complete for that media stream and the
controlling agent doesn't have to send a second STUN request. The controlling agent doesn't have to send a second STUN request. The
selected pair will be the highest priority valid pair. Aggressive selected pair will be the highest priority valid pair whose check
nomination is faster than regular nomination, but gives less succeeeded. Aggressive nomination is faster than regular nomination,
flexibility. Aggressive nomination is shown in Figure 5. but gives less flexibility. Aggressive nomination is shown in
Figure 5.
L R L R
- - - -
STUN request + flag \ L's STUN request + flag -> \ L's
<- STUN response / check <- STUN response / check
<- STUN request \ R's <- STUN request \ R's
STUN response -> / check STUN response -> / check
Figure 5: Aggressive Nomination Figure 5: Aggressive Nomination
Once all of the media streams are completed, the controlling endpoint Once all of the media streams are completed, the controlling endpoint
sends an updated offer if the candidates in the m and c lines for the sends an updated offer if the candidates in the m and c lines for the
media stream (called the DEFAULT CANDIDATES) don't match ICE's media stream (called the DEFAULT CANDIDATES) don't match ICE's
skipping to change at page 16, line 14 skipping to change at page 17, line 14
2.7. Lite Implementations 2.7. Lite Implementations
In order for ICE to be used in a call, both agents need to support In order for ICE to be used in a call, both agents need to support
it. However, certain agents will always be connected to the public it. However, certain agents will always be connected to the public
Internet and have a public IP address at which it can receive packets Internet and have a public IP address at which it can receive packets
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. Lite agents do not generate
with a full implementation, the full agent takes the role of the connectivity checks or run the state machines, though they need to be
controlling agent, and the lite agent takes on the controlled role. able to respond to connectivity checks. When a lite implementation
In addition, lite agents do not need to generate connectivity checks, connects with a full implementation, the full agent takes the role of
run the state machines, or compute candidate pairs. Additional the controlling agent, and the lite agent takes on the controlled
guidance on when a lite implementation is appropriate, see the role. When two lite implementations connect, no checks are sent.
For guidance on when a lite implementation is appropriate, see the
discussion in Appendix A. discussion in Appendix A.
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
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [1].
Readers should be familiar with the terminology defined in the offer/ Readers should be familiar with the terminology defined in the offer/
answer model [4], STUN [12] and NAT Behavioral requirements for UDP answer model [4], STUN [13] and NAT Behavioral requirements for UDP
[29] [30]
This specification makes use of the following additional terminology: This specification makes use of the following additional terminology:
Agent: As defined in RFC 3264, an agent is the protocol Agent: As defined in RFC 3264, an agent is the protocol
implementation involved in the offer/answer exchange. There are implementation involved in the offer/answer exchange. There are
two agents involved in an offer/answer exchange. two agents involved in an offer/answer exchange.
Peer: From the perspective of one of the agents in a session, its Peer: From the perspective of one of the agents in a session, its
peer is the other agent. Specifically, from the perspective of peer is the other agent. Specifically, from the perspective of
the offerer, the peer is the answerer. From the perspective of the offerer, the peer is the answerer. From the perspective of
the answerer, the peer is the offerer. the answerer, the peer is the offerer.
Transport Address: The combination of an IP address and transport Transport Address: The combination of an IP address and transport
protocol (such as UDP or TCP) port. protocol (such as UDP or TCP) port.
Candidate: A transport address that is to be tested by ICE Candidate: A transport address that is a potential point of contact
procedures in order to determine its suitability for usage for for receipt of media. Candidates also have properties - their
receipt of media. Candidates also have properties - their type type (server reflexive, relayed or host), priority, foundation,
(server reflexive, relayed or host), priority, foundation, and and base.
base.
Component: A component is a piece of a media stream requiring a Component: A component is a piece of a media stream requiring a
single transport address; a media stream may require multiple single transport address; a media stream may require multiple
components, each of which has to work for the media stream as a components, each of which has to work for the media stream as a
whole to work. For media streams based on RTP, there are two whole to work. For media streams based on RTP, there are two
components per media stream - one for RTP, and one for RTCP. components per media stream - one for RTP, and one for RTCP.
Host Candidate: A candidate obtained by binding to a specific port Host Candidate: A candidate obtained by binding to a specific port
from an interface on the host. This includes both physical from an interface on the host. This includes both physical
interfaces and logical ones, such as ones obtained through Virtual interfaces and logical ones, such as ones obtained through Virtual
Private Networks (VPNs) and Realm Specific IP (RSIP) [19] (which Private Networks (VPNs) and Realm Specific IP (RSIP) [20] (which
lives at the operating system level). lives at the operating system level).
Server Reflexive Candidate: A candidate obtained by sending a STUN Server Reflexive Candidate: A candidate obtained by sending a STUN
request from a host candidate to a STUN server, distinct from the request from a host candidate to a STUN server, distinct from the
peer. The STUN server's address is configured or learned by the peer. The STUN server's address is configured or learned by the
client prior to an offer/answer exchange. client prior to an offer/answer exchange.
Peer Reflexive Candidate: A candidate obtained by sending a STUN Peer Reflexive Candidate: A candidate obtained by sending a STUN
request from a host candidate to the STUN server running on a request from a host candidate to the STUN server running on a
peer's candidate. peer's candidate.
skipping to change at page 18, line 29 skipping to change at page 19, line 32
candidate. candidate.
Check, Connectivity Check, STUN Check: A STUN Binding Request Check, Connectivity Check, STUN Check: A STUN Binding Request
transaction for the purposes of verifying connectivity. A check transaction for the purposes of verifying connectivity. A check
is sent from the local candidate to the remote candidate of a is sent from the local candidate to the remote candidate of a
candidate pair. candidate pair.
Check List: An ordered set of candidate pairs that an agent will use Check List: An ordered set of candidate pairs that an agent will use
to generate checks. to generate checks.
Periodic Check: A connectivity check generated by an agent as a Ordinary Check: A connectivity check generated by an agent as a
consequence of a timer that fires periodically, instructing it to consequence of a timer that fires periodically, instructing it to
send a check. send a check.
Triggered Check: A connectivity check generated as a consequence of Triggered Check: A connectivity check generated as a consequence of
the receipt of a connectivity check from the peer. the receipt of a connectivity check from the peer.
Valid List: An ordered set of candidate pairs for a media stream Valid List: An ordered set of candidate pairs for a media stream
that have been validated by a successful STUN transaction. that have been validated by a successful STUN transaction.
Full: An ICE implementation that performs the complete set of Full: An ICE implementation that performs the complete set of
functionality defined by this specification. functionality defined by this specification.
Lite: An ICE implementation that omits certain functions, Lite: An ICE implementation that omits certain functions,
implementing only as much as is necessary for a peer implementing only as much as is necessary for a peer
implementation that is full to gain the benefits of ICE. Lite implementation that is full to gain the benefits of ICE. Lite
implementations can only act as the controlled agent in a session, implementations do not maintain any of the state machines and do
and do not gather candidates. not generate connectivity checks.
Controlling Agent: The STUN agent which is responsible for selecting Controlling Agent: The STUN agent which is responsible for selecting
the final choice of candidate pairs and signaling them through the final choice of candidate pairs and signaling them through
STUN and an updated offer, if needed. In any session, one agent STUN and an updated offer, if needed. In any session, one agent
is always controlling. The other is the controlled agent. is always controlling. The other is the controlled agent.
Controlled Agent: A STUN agent which waits for the controlling agent Controlled Agent: A STUN agent which waits for the controlling agent
to select the final choice of candidate pairs. to select the final choice of candidate pairs.
Regular Nomination: The process of picking a valid candidate pair Regular Nomination: The process of picking a valid candidate pair
skipping to change at page 20, line 41 skipping to change at page 21, line 47
when both endpoints are behind NATs that perform address and port when both endpoints are behind NATs that perform address and port
dependent mapping. Consequently, some deployments might consider dependent mapping. Consequently, some deployments might consider
this use case to be marginal, and elect not to use relays. If an 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 agent does not gather server reflexive or relayed candidates, it is
RECOMMENDED that the functionality be implemented and just disabled RECOMMENDED that the functionality be implemented and just disabled
through configuration, so that it can re-enabled through through configuration, so that it can re-enabled through
configuration if conditions change in the future. 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. When
very instance, and then every Ta milliseconds thereafter, the agent there are multiple choices for that single STUN server (when, for
chooses another such pair (the order is inconsequential), and sends a example, they are learned through DNS records and multiple results
STUN request to the server from that host candidate. If the agent is are returned), an agent SHOULD use a single STUN server (based on its
using both relayed and server reflexive candidates, this request MUST IP address) for all candidates for a particular session. This
be a STUN Allocate request using the relay usage [13]. If the agent improves the performance of ICE. The result is a set of host
is using only server reflexive candidates, the request MUST be a STUN candidate/STUN server pairs. The agent then chooses one pair, and
Binding request using the binding discovery usage [12]. sends a STUN request to the server from that host candidate. If the
agent is using both relayed and server reflexive candidates, this
request MUST be a STUN Allocate request using the relay usage [14].
If the agent is using only server reflexive candidates, the request
MUST be a STUN Binding request using the binding discovery usage
[13].
The value of Ta SHOULD be configurable, and SHOULD have a default of Every Ta milliseconds thereafter, the agent can generate another new
20ms (see Appendix B.1 for a discussion on the selection of this STUN transaction. This transaction can either be a retry of a
value). Note that this pacing applies only to starting STUN previous transaction which failed with a recoverable error (such as
transactions with source and destination transport addresses (i.e., authentication failure), or a transaction for a new candidate/STUN
the host candidate and STUN server respectively) for which a STUN server pair. The agent SHOULD NOT generate transactions more
transaction has not previously been sent. Consequently, frequently than one every Ta milliseconds.
retransmissions of a STUN request are governed entirely by the
retransmission rules defined in [12]. Similarly, retries of a The value of Ta SHOULD be configurable, and SHOULD have a default of:
request due to recoverable errors (such as an authentication
challenge) happen immediately and are not paced by timer Ta. Because For each media stream i:
of this pacing, it will take a certain amount of time to obtain all Ta_i = (stun_packet_size / rtp_packet_size) * rtp_ptime
of the server reflexive and relayed candidates. Implementations
should be aware of the time required to do this, and if the 1
application requires a time budget, limit the number of candidates Ta = MAX (20ms, ------------------- )
which are gathered. k
----
\ 1
> ------
/ Ta_i
----
i=1
Where k is the number of media streams. In addition, the
retransmission timer for the STUN transactions, RTO, defined in [13],
SHOULD be configurable and SHOULD have a default of:
RTO = MAX (100ms, Ta * (number of candidate/STUN server pairs))
See Appendix B.1 for a discussion on this formula and its
implications. Because of this pacing, it will take a certain amount
of time to obtain all of the server reflexive and relayed candidates.
Implementations should be aware of the time required to do this, and
if the application requires a time budget, limit the number of
candidates which are gathered.
The agent will receive a STUN Binding or Allocate response. A The agent will receive a STUN Binding or Allocate response. A
successful Allocate Response will provide the agent with a server successful Allocate Response will provide the agent with a server
reflexive candidate (obtained from the mapped address) and a relayed reflexive candidate (obtained from the mapped address) and a relayed
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.
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. Frequently, a
server reflexive candidate and a host candidate will be redundant
when the agent is not behind a NAT.
4.1.1.4. Computing Foundations 4.1.1.4. Computing Foundations
Finally, the agent assigns each candidate a foundation. The Finally, the agent assigns each candidate a foundation. The
foundation is an identifier, scoped within a session. Two candidates foundation is an identifier, scoped within a session. Two candidates
MUST have the same foundation ID when all of the following are true: MUST have the same foundation ID when all of the following are true:
o they are of the same type (host, relayed, server reflexive, peer o they are of the same type (host, relayed, server reflexive, or
reflexive or relayed) peer reflexive)
o their bases have the same IP address (the ports can be different) o their bases have the same IP address (the ports can be different)
o for reflexive and relayed candidates, the STUN servers used to o for reflexive and relayed candidates, the STUN servers used to
obtain them have the same IP address. obtain them have the same IP address.
Similarly, two candidates MUST have different foundations if their Similarly, two candidates MUST have different foundations if their
types are different, their bases have different IP addresses, or the types are different, their bases have different IP addresses, or the
STUN servers used to obtain them have different IP addresses. STUN servers used to obtain them have different IP addresses.
4.1.1.5. Keeping Candidates Alive 4.1.1.5. Keeping Candidates Alive
Once server reflexive and relayed candidates are allocated, they MUST Once server reflexive and relayed candidates are allocated, they MUST
be kept alive until ICE processing has completed. For server be kept alive until ICE processing has completed, as described in
reflexive candidates learned through the Binding Discovery usage, Section 8.3. For server reflexive candidates learned through the
this MUST be another Binding Request from the Binding Discovery Binding Discovery usage, the bindings MUST be kept alive by another
usage. For relayed candidates learned through the Relay Usage, this Binding Request from the Binding Discovery usage. For relayed
MUST be a new Allocate request. The Allocate request will also candidates learned through the Relay Usage, the keepalive MUST be a
refresh the server reflexive candidate. new Allocate request. The Allocate request will also refresh the
server reflexive candidate.
4.1.2. Prioritizing Candidates 4.1.2. Prioritizing Candidates
The prioritization process results in the assignment of a priority to The prioritization process results in the assignment of a priority to
each candidate. Each candidate for a media stream MUST have a unique each candidate. Each candidate for a media stream MUST have a unique
priority that MUST be a positive integer between 1 and (2**32 - 1). priority that MUST be a positive integer between 1 and (2**32 - 1).
This priority will be used by ICE to determine the order of the This priority will be used by ICE to determine the order of the
connectivity checks and the relative preference for candidates. connectivity checks and the relative preference for candidates.
An agent SHOULD compute this priority using the formula in An agent SHOULD compute this priority using the formula in
skipping to change at page 24, line 4 skipping to change at page 25, line 37
routed in and right back out of a media relay run by the provider. routed in and right back out of a media relay run by the provider.
If these concerns are important, the type preference for relayed If these concerns are important, the type preference for relayed
candidates SHOULD be lower than host candidates. The RECOMMENDED candidates SHOULD be lower than host candidates. The RECOMMENDED
values are 126 for host candidates, 100 for server reflexive values are 126 for host candidates, 100 for server reflexive
candidates, 110 for peer reflexive candidates, and 0 for relayed candidates, 110 for peer reflexive candidates, and 0 for relayed
candidates. Furthermore, if an agent is multi-homed and has multiple candidates. Furthermore, if an agent is multi-homed and has multiple
interfaces, the local preference for host candidates from a VPN interfaces, the local preference for host candidates from a VPN
interface SHOULD have a priority of 0. interface SHOULD have a priority of 0.
Another criteria for selection of preferences is IP address family. Another criteria for selection of preferences is IP address family.
ICE works with both IPv4 and IPv6. It therefore provides a ICE works with both IPv4 and IPv6. It therefore provides a
transition mechanism that allows dual-stack hosts to prefer transition mechanism that allows dual-stack hosts to prefer
connectivity over IPv6, but to fall back to IPv4 in case the v6 connectivity over IPv6, but to fall back to IPv4 in case the v6
networks are disconnected (due, for example, to a failure in a 6to4 networks are disconnected (due, for example, to a failure in a 6to4
relay) [24]. It can also help with hosts that have both a native relay) [25]. It can also help with hosts that have both a native
IPv6 address and a 6to4 address. In such a case, higher local IPv6 address and a 6to4 address. In such a case, higher local
preferences could be assigned to the v6 interface, followed by the preferences could be assigned to the v6 interface, followed by the
6to4 interfaces, followed by the v4 interfaces. This allows a site 6to4 interfaces, followed by the v4 interfaces. This allows a site
to obtain and begin using native v6 addresses immediately, yet still to obtain and begin using native v6 addresses immediately, yet still
fallback to 6to4 addresses when communicating with agents in other fallback to 6to4 addresses when communicating with agents in other
sites that do not yet have native v6 connectivity. sites that do not yet have native v6 connectivity.
Another criteria for selecting preferences is security. If a user is Another criteria for selecting preferences is security. If a user is
a telecommuter, and therefore connected to their corporate network a telecommuter, and therefore connected to their corporate network
and a local home network, they may prefer their voice traffic to be and a local home network, they may prefer their voice traffic to be
skipping to change at page 25, line 10 skipping to change at page 26, line 43
It is RECOMMENDED that default candidates be chosen based on the It is RECOMMENDED that default candidates be chosen based on the
likelihood of those candidates to work with the peer that is being likelihood of those candidates to work with the peer that is being
contacted. It is RECOMMENDED that the default candidates are the contacted. It is RECOMMENDED that the default candidates are the
relayed candidates (if relayed candidates are available), server relayed candidates (if relayed candidates are available), server
reflexive candidates (if server reflexive candidates are available), reflexive candidates (if server reflexive candidates are available),
and finally host candidates. and finally host candidates.
4.2. Lite Implementation 4.2. Lite Implementation
For each media stream, the agent allocates a single candidate for Lite implementations only utilize host candidates. A lite
each component of the media stream from one of its interfaces. If an implementation MUST, for each component of each media stream,
agent has multiple interfaces, it MUST choose one for each component allocate zero or one IPv4 candidates. It MAY allocate zero or more
of a particular media stream. With the lite implementation, ICE IPv6 candidates, but no more than one per each IPv6 address utilized
cannot be used to dynamically choose amongst candidates. Each by the host. Since there can be no more than one IPv4 candidate per
component has an ID assigned to it, called the component ID. For component of each media stream, if an agent has multiple IPv4
RTP-based media streams the RTP itself has a component ID of 1, and interfaces, it MUST choose one for allocating the candidate. If a
RTCP a component ID of 2. If an agent is using RTCP it MUST obtain a host is dual-stack, it is RECOMMENDED that it allocate one IPv4
candidate for it. candidate, one link local and one global IPv6 address. With the lite
implementation, ICE cannot be used to dynamically choose amongst
candidates. Therefore, including more than one candidate from a
particular scope is NOT RECOMMENDED, since only a connectivity check
can truly determine whether to use one address or the other.
Each component has an ID assigned to it, 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 is using RTCP it MUST
obtain candidates for it.
Each candidate is assigned a foundation. The foundation MUST be Each candidate is assigned a foundation. The foundation MUST be
different for two candidates from different interfaces, and MUST be different for two candidates allocated from different IP addresses,
the same otherwise. A simple integer that increments for each and MUST be the same otherwise. A simple integer that increments for
interface will suffice. In addition, each candidate MUST be assigned each IP address will suffice. In addition, each candidate MUST be
a unique priority amongst all candidates for the same media stream. assigned a unique priority amongst all candidates for the same media
This priority SHOULD be equal to 2^24*(126) + 2^8*(65535) + 256 minus stream. This priority SHOULD be equal to:
the component ID, which is 2130706432 minus the component ID.
If an agent has included two candidates for a component, the v4 priority = (2^24)*(126) +
candidate SHOULD be selected as the default. Since a lite (2^8)*(IP precedence) +
implementation has a single candidate for a component, each of these (2^0)*(256 - component ID)
candidates is considered to be default.
If a host is v4-only, it SHOULD set the IP precedence to 65535. If a
host is v6 or dual-stack, the IP precedence is the precedence value
for IP addresses described in RFC 3484 [12].
Next, an agent chooses a default candidate for each component of each
media stream. If a host is IPv4 only, there would only be one
candidate for each component of each media stream, and therefore that
candidate is the default. If a host is IPv6 or dual stack, the
selection of default is a matter of local policy. This default
SHOULD be chosen, such that, it is the candidate most likely to be
used with a peer. For IPv6-only hosts, this would typically by a
globally scoped IPv6 address. For dual-stack hosts, the IPv4 address
is RECOMMENDED.
4.3. Encoding the SDP 4.3. Encoding the SDP
The process of encoding the SDP is identical between full and lite The process of encoding the SDP is identical between full and lite
implementations. implementations.
The agent will include an m-line for each media stream it wishes to The agent will include an m-line for each media stream it wishes to
use. The ordering of media streams in the SDP is relevant for ICE. use. The ordering of media streams in the SDP is relevant for ICE.
ICE will perform its connectivity checks for the first m-line first, ICE will perform its connectivity checks for the first m-line first,
and consequently media will be able to flow for that stream first. and consequently media will be able to flow for that stream first.
skipping to change at page 27, line 16 skipping to change at page 29, line 16
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=RS:0
b=RR: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 host a=candidate:1 1 UDP 2130706431 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 1694498815 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 offerer
supports sufficient ICE functionality to proceed (i.e., if both supports ICE, determine its own role, gather candidates, prioritize
offeror and answerer are lite implementations, ICE cannot proceed), them, choose default candidates, encode and send an answer, and for
determine its own role, gather candidates, prioritize them, choose full implementations, form the check lists and begin connectivity
default candidates, encode and send an answer, and for full checks.
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 agent will proceed with the ICE procedures defined in this
specification if the following are all true: specification if, for each media stream in the SDP it received, the
default destination for each component of that media stream appears
o For each media stream, the default destination for at least one in a candidate attribute. For example, in the case of RTP, the IP
component of the media stream appears in a candidate attribute. address and port in the c and m line, respectively, appears in a
For example, in the case of RTP, the IP address and port in the c candidate attribute and the value in the rtcp attribute appears in a
and m line, respectively, appears in a candidate attribute, or the 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
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 this condition is not met, the agent MUST process the SDP based on
SDP based on normal RFC 3264 procedures, without using any of the ICE normal RFC 3264 procedures, without using any of the ICE mechanisms
mechanisms described in the remainder of this specification with the described in the remainder of this specification with the following
following exceptions: 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
a=candidate attributes, but none that matched the default a=candidate attributes, but none that matched the default
destination of the media stream, the agent MUST include an a=ice- destination of the media stream, the agent MUST include an a=ice-
mismatch attribute in its answer. mismatch attribute in its answer.
5.2. Determining Role 5.2. Determining Role
For each session, each agent takes on a role. There are two roles - For each session, each agent takes on a role. There are two roles -
controlling, and controlled. The controlling agent is responsible controlling, and controlled. The controlling agent is responsible
for nominating the candidate pairs that can be used by ICE for each for the choice of the final candidate pairs used for communications.
media stream, and for generating the updated offer based on ICE's For a full agent, this means nominating the candidate pairs that can
selection, when needed. The controlled agent is told which candidate be used by ICE for each media stream, and for generating the updated
pairs to use for each media stream, and does not generate an updated offer based on ICE's selection, when needed. For a lite
offer to signal this information. implementation, being the controlling agent means selecting a
candidate pair based on the ones in the offer and answer (for IPv4,
there is only ever one pair), and then generating an updated offer
reflecting that selection, when needed (it is never needed for an
IPv4 only host). The controlled agent is told which candidate pairs
to use for each media stream, and does not generate an updated offer
to signal this information. The sections below describe in detail
the actual procedures following by controlling and controlled nodes.
If one of the agents is a lite implementation, it MUST assume the The rules for determining the role and the impact on behavior are as
controlled role, and its peer (which will be full; if it was lite, follows:
ICE would have aborted) MUST assume the controlling role. If the
agent and its peer are both full implementations, the agent which
generated the offer which started the ICE processing takes on the
controlling role, and the other takes the controlled role.
In unusual cases it is possible for both agents to mistakenly believe Both agents are full: The agent which generated the offer which
they are controlled or controlling. To deal with such cases, at the started the ICE processing MUST take the controlling role, and the
time an agent determines its role, it MUST select a random number, other MUST take the controlled role. Both agents will form check
called the tie-breaker, uniformly distributed between 0 and (2**64) - lists, run the ICE state machines, and generate connectivity
1 (that is, a 64 bit positive integer). This number is used in STUN checks. The controlling agent will execute the logic in
Section 8.1 to nominate pairs that will be selected by ICE, and
then both agents end ICE as described in Section 8.1.2. In
unusual cases, described in Appendix B.11, it is possible for both
agents to mistakenly believe they are controlled or controlling.
To resolve this, each agent 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 checks to detect and repair this case, as described in
Section 7.1.1.2. Section 7.1.1.2.
One agent Full, one Lite: The full agent MUST take the controlling
role, and the lite agent MUST take the controlled role. The full
agent will form check lists, run the ICE state machines, and
generate connectivity checks. That agent will execute the logic
in Section 8.1 to nominate pairs that will be selected by ICE, and
use the logic in Section 8.1.2 to end ICE. The lite
implementation will just listen for connectivity checks, receive
them and respond to them, and then conclude ICE as described in
Section 8.2. For the lite implementation, the state of ICE
processing for each media stream is considered to be Running, and
the state of ICE overall is Running.
Both Lite: The agent which generated the offer which started the ICE
processing MUST take the controlling role, and the other MUST take
the controlled role. In this case, no connectivity checks are
ever sent. Rather, once the offer/answer exchange completes, each
agent performs the processing described in Section 8 without
connectivity checks. It is possible that both agents will believe
they are controlled or controlling. In the latter case, the
conflict is resolved through glare detection capabilities in the
signaling protocol carrying the offer/answer exchange. The state
of ICE processing for each media stream is considered to be
Running, and the state of ICE overall is Running.
Once roles are determined for a session, they persist unless ICE is Once roles are determined for a session, they persist unless ICE is
restarted. A ICE restart (Section 9.1 causes a new selection of restarted. A ICE restart (Section 9.1) causes a new selection of
roles and tie-breakers. 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 30, line 8 skipping to change at page 32, line 38
happen if one agent didn't include candidates for the all of the happen if one agent didn't include candidates for the all of the
components for a media stream. If this happens, the number of components for a media stream. If this happens, the number of
components for that media stream is effectively reduced, and components for that media stream is effectively reduced, and
considered to be equal to the minimum across both agents of the considered to be equal to the minimum across both agents of the
maximum component ID provided by each agent across all components for maximum component ID provided by each agent across all components for
the media stream. the media stream.
In the case of RTP, this would happen when one agent provided In the case of RTP, this would happen when one agent provided
candidates for RTCP, and the other did not. As another example, the candidates for RTCP, and the other did not. As another example, the
offerer can multiplex RTP and RTCP on the same port and signals it offerer can multiplex RTP and RTCP on the same port and signals it
can do that in the SDP through some new attribute. However, since can do that in the SDP through an SDP attribute [33]. However, since
the offerer doesn't know if the answerer can perform such the offerer doesn't know if the answerer can perform such
multiplexing, the offerer includes candidates for RTP and RTCP on multiplexing, the offerer includes candidates for RTP and RTCP on
separate ports, so that the offer has two components per media separate ports, so that the offer has two components per media
stream. If the answerer can perform such multiplexing, it would stream. If the answerer can perform such multiplexing, it would
include just a single component for each candidate - for the combined include just a single component for each candidate - for the combined
RTP/RTCP mux. ICE would end up acting as if there was just a single RTP/RTCP mux. ICE would end up acting as if there was just a single
component for this candidate. component for this candidate.
The candidate pairs whose local and remote candidates were both the The candidate pairs whose local and remote candidates were both the
default candidates for a particular component is called, default candidates for a particular component is called,
unsurprisingly, the default candidate pair for that component. This unsurprisingly, the default candidate pair for that component. This
is the pair that would be used to transmit media if both agents had is the pair that would be used to transmit media if both agents had
not been ICE aware. not been ICE aware.
In order to aid understanding, Figure 8 shows the relationships In order to aid understanding, Figure 11 shows the relationships
between several key concepts - transport addresses, candidates, between several key concepts - transport addresses, candidates,
candidate pairs, and check lists, in addition to indicating the main candidate pairs, and check lists, in addition to indicating the main
properties of candidates and candidate pairs. properties of candidates and candidate pairs.
+------------------------------------------+ +------------------------------------------+
| | | |
| +---------------------+ | | +---------------------+ |
| |+----+ +----+ +----+ | +Type | | |+----+ +----+ +----+ | +Type |
| || IP | |Port| |Tran| | +Priority | | || IP | |Port| |Tran| | +Priority |
| ||Addr| | | | | | +Foundation | | ||Addr| | | | | | +Foundation |
skipping to change at page 31, line 46 skipping to change at page 34, line 4
+------------------+ +------------------+
+------------------+ +------------------+
| Candidate Pair | | Candidate Pair |
+------------------+ +------------------+
+------------------+ +------------------+
| Candidate Pair | | Candidate Pair |
+------------------+ +------------------+
Check Check
List List
Figure 11: Conceptual Diagram of a Check List
Figure 8: Conceptual Diagram of a Check List
5.7.2. Computing Pair Priority and Ordering Pairs 5.7.2. Computing Pair Priority and Ordering Pairs
Once the pairs are formed, a candidate pair priority is computed. Once the pairs are formed, a candidate pair priority is computed.
Let O be the priority for the candidate provided by the offerer. Let Let G be the priority for the candidate provided by the controlling
A be the priority for the candidate provided by the answerer. The agent. Let D be the priority for the candidate provided by the
priority for a pair is computed as: controlled agent. The priority for a pair is computed as:
pair priority = 2^32*MIN(O,A) + 2*MAX(O,A) + (O>A?1:0) pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)
Where O-P>A-P?1:0 is an expression whose value is 1 if O-P is greater Where G>D?1:0 is an expression whose value is 1 if G is greater than
than A-P, and 0 otherwise. This formula ensures a unique priority D, and 0 otherwise. This formula ensures a unique priority for each
for each pair in most cases. Once the priority is assigned, the pair. Once the priority is assigned, the agent sorts the candidate
agent sorts the candidate pairs in decreasing order of priority. If pairs in decreasing order of priority. If two pairs have identical
two pairs have identical priority, the ordering amongst them is priority, the ordering amongst them is arbitrary.
arbitrary.
5.7.3. Pruning the Pairs 5.7.3. Pruning the Pairs
This sorted list of candidate pairs is used to determine a sequence This sorted list of candidate pairs is used to determine a sequence
of connectivity checks that will be performed. Each check involves of connectivity checks that will be performed. Each check involves
sending a request from a local candidate to a remote candidate. sending a request from a local candidate to a remote candidate.
Since an agent cannot send requests directly from a reflexive Since an agent cannot send requests directly from a reflexive
candidate, but only from its base, the agent next goes through the candidate, but only from its base, the agent next goes through the
sorted list of candidate pairs. For each pair where the local sorted list of candidate pairs. For each pair where the local
candidate is server reflexive, the server reflexive candidate MUST be candidate is server reflexive, the server reflexive candidate MUST be
skipping to change at page 33, line 23 skipping to change at page 35, line 23
successful result. successful result.
Failed: A check for this pair was already done and failed, either Failed: A check for this pair was already done and failed, either
never producing any response or producing an unrecoverable failure never producing any response or producing an unrecoverable failure
response. response.
Frozen: A check for this pair hasn't been performed, and it can't Frozen: A check for this pair hasn't been performed, and it can't
yet be performed until some other check succeeds, allowing this yet be performed until some other check succeeds, allowing this
pair to unfreeze and move into the Waiting state. pair to unfreeze and move into the Waiting state.
As ICE runs, the pairs will move between states as shown in Figure 9. As ICE runs, the pairs will move between states as shown in
Figure 12.
+-----------+ +-----------+
| | | |
| | | |
| Frozen | | Frozen |
| | | |
| | | |
+-----------+ +-----------+
| |
|unfreeze |unfreeze
skipping to change at page 34, line 44 skipping to change at page 36, line 44
// | // |
V V V V
+-----------+ +-----------+ +-----------+ +-----------+
| | | | | | | |
| | | | | | | |
| Failed | | Succeeded | | Failed | | Succeeded |
| | | | | | | |
| | | | | | | |
+-----------+ +-----------+ +-----------+ +-----------+
Figure 9: Pair State FSM Figure 12: Pair State FSM
The initial states for each pair in the check list are computed by The initial states for each pair in a 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. The agent examines the check list for the first media stream (a 2. The agent examines the check list for the first media stream (a
media stream is the first media stream when it is described by media stream is the first media stream when it is described by
the first m-line in the SDP offer and answer). For that media the first m-line in the SDP offer and answer). For that media
stream, it: stream, it:
skipping to change at page 35, line 23 skipping to change at page 37, line 23
component ID to Waiting. If there is more than one such pair, component ID to Waiting. If there is more than one such pair,
the one with the highest priority is used. 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 Waiting is Frozen state. A check list with at least one pair that is Waiting is
called an active check list, and a check list with all pairs frozen called an active check list, and a check list with all pairs frozen
is called a frozen check list. 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 three 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 successfully for Completed: In this state, ICE checks have produced nominated pairs
this media stream. for each component of the media stream. Consequently, ICE has
succeeded and media can be sent.
Failed: In this state, the ICE checks have not completed Failed: In this state, the ICE checks have not completed
successfully for this media stream. 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 ICE processing is
progress. The state is Completed when all checks have been underway. The state is Completed when ICE processing is complete and
completed. Rules for transitioning between states are described Failed if it failed without success. Rules for transitioning between
below. states are described below.
5.8. Performing Periodic Checks 5.8. Scheduling 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 ordinary checks and triggered checks. The
checks occur periodically for each media stream, and involve choosing generation of both checks is governed by a timer which fires
the highest priority pair in the Waiting state from each check list, periodically for each media stream. The agent maintains a FIFO
and sending a check on it. Triggered checks are performed on receipt queue, called the triggered check queue, which contains candidate
of a connectivity check from the peer (see Section 7.2.1.4). This pairs for which checks are to be sent at the next available
section describes how periodic checks are performed. opportunity. When the timer fires, the agent removes the top pair
from triggered check queue, performs a connectivity check on that
pair, and sets the state of the candidate pair to In-Progress. If
there are no pairs in the triggered check queue, an ordinary check is
sent.
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. Implementations
value used to pace the gathering of candidates, as described in SHOULD take care to spread out these timers so that they do not fire
Section 4.1.1. Multiplying by N allows this aggregate check at the same time for each media stream. Ta is the same value used to
throughput to be split between all active check lists. The first pace the gathering of candidates, as described in Section 4.1.1.
timer for each active check list fires immediately, so that the agent Multiplying by N allows this aggregate check throughput to be split
performs a connectivity check the moment the offer/answer exchange between all active check lists. The first timer fires immediately,
has been done, followed by the next periodic check Ta seconds later. so that the agent performs a connectivity check the moment the offer/
answer exchange has been done, followed by the next check Ta seconds
later.
When the timer fires, the agent MUST: When a connectivity check begins, its retransmission timer RTO SHOULD
be configurable and SHOULD have a default of:
RTO = MAX (100ms, Ta*N * (Num-Waiting))
Where Num-Waiting are the number of checks in the check list in the
Waiting state. Note that the RTO will be different for each
transaction as the number of checks in the Waiting state changes.
When the timer fires, and there is no triggered check to be sent, the
agent MUST choose an ordinary check as follows:
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
STUN request for this purpose are described in Section 7.1.1. STUN request for this purpose are described in Section 7.1.1.
* Set the state of the candidate pair to In-Progress.
o If there is no such pair: o If there is no such pair:
* Find the highest priority pair in that check list that is in * Find the highest priority pair in that check list that is in
the Frozen state. the Frozen state.
* 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
skipping to change at page 37, line 10 skipping to change at page 39, line 29
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
receives the answer from the peer. It verifies that its peer receives the answer from the peer. It verifies that its peer
supports ICE, determines its role, and for full implementations, supports ICE, determines its role, and for full implementations,
forms the check list and begins performing periodic checks. forms the check list and begins performing ordinary checks.
When ICE is used with SIP, forking may result in a single offer
generating a multiplicity of answers. In that each, ICE proceeds
completely in parallel and independently for each answer, treating
the combination of its offer and each answer as an independent offer/
answer exchange, with its own set of pairs, check lists, states, and
so on. The only case in which processing of one pair impacts another
is freeing of candidates, discussed below in Section 8.3.
6.1. Verifying ICE Support 6.1. Verifying ICE Support
The offerer will proceed with the ICE procedures defined in this The logic at the offerer is identical to that of the answerer as
specification if there is at least one a=candidate attribute for each described in Section 5.1, with the exception that an offerer would
media stream in the answer it just received. If this condition is not ever generate a=ice-mismatch attributes in an SDP.
not met, the agent MUST process the SDP based on normal RFC 3264
procedures, without using any of the ICE mechanisms described in the
remainder of this specification, with the exception of Section 10,
which describes keepalive procedures.
In some cases, the answer may omit a=candidate attributes for the In some cases, the answer may omit a=candidate attributes for the
media streams, and instead include an a=ice-mismatch attribute for media streams, and instead include an a=ice-mismatch attribute for
one or more of the media streams in the SDP. This signals to the one or more of the media streams in the SDP. This signals to the
offerer that the answerer supports ICE, but that ICE processing was offerer that the answerer supports ICE, but that ICE processing was
not used for the session because an intermediary modified the default not used for the session because an intermediary modified the default
destination for media components without modifying the corresponding destination for media components without modifying the corresponding
candidate attributes. See Section 17 for a discussion of cases where candidate attributes. See Section 17 for a discussion of cases where
this can happen. This specification provides no guidance on how an this can happen. This specification provides no guidance on how an
agent should proceed in such a failure case. agent should proceed in such a failure case.
skipping to change at page 37, line 43 skipping to change at page 40, line 18
The offerer follows the same procedures described for the answerer in The offerer follows the same procedures described for the answerer in
Section 5.2. Section 5.2.
6.3. Forming the Check List 6.3. Forming the Check List
Formation of check lists is performed only by full implementations. Formation of check lists is performed only by full implementations.
The offerer follows the same procedures described for the answerer in The offerer follows the same procedures described for the answerer in
Section 5.7. Section 5.7.
6.4. Performing Periodic Checks 6.4. Performing Ordinary Checks
Periodic checks are performed only by full implementations. The Ordinary checks are performed only by full implementations. The
offerer follows the same procedures described for the answerer in offerer follows the same procedures described for the answerer in
Section 5.8. Section 5.8.
7. Performing Connectivity Checks 7. Performing Connectivity Checks
This section describes how connectivity checks are performed. All This section describes how connectivity checks are performed. All
ICE implementations are required to be compliant to [12], as opposed ICE implementations are required to be compliant to [13], as opposed
to the older [15]. However, whereas a full implementation will both to the older [16]. However, whereas a full implementation will both
generate checks (acting as a STUN client) and receive them (acting as generate checks (acting as a STUN client) and receive them (acting as
a STUN server), a lite implementation will only ever receive checks, a STUN server), a lite implementation will only ever receive checks,
and thus will only act as a STUN server. and thus will only act as a STUN server.
7.1. Client Procedures 7.1. STUN Client Procedures
These procedures define how an agent sends a connectivity check, These procedures define how an agent sends a connectivity check,
whether it is a periodic or a triggered check. These procedures are whether it is an ordinary or a triggered check. These procedures are
only applicable to full implementations. only applicable to full implementations.
7.1.1. Sending the Request 7.1.1. Sending the Request
The check is generated by sending a Binding Request from a local The check is generated by sending a Binding Request from a local
candidate, to a remote candidate. [12] describes how Binding Requests candidate, to a remote candidate. [13] describes how Binding Requests
are constructed and generated. This section defines additional are constructed and generated. This section defines additional
procedures involving the PRIORITY and USE-CANDIDATE attributes, procedures involving the PRIORITY and USE-CANDIDATE attributes,
defined for the connectivity check usage, and details how credentials defined for the connectivity check usage in Section 18.5, and details
for message integrity and diffserv markings are computed. how credentials for message integrity and diffserv markings are
computed.
7.1.1.1. PRIORITY and USE-CANDIDATE 7.1.1.1. PRIORITY and USE-CANDIDATE
An agent MUST include the PRIORITY attribute in its Binding Request. An agent MUST include the PRIORITY attribute in its Binding Request.
The attribute MUST be set equal to the priority that would be The attribute MUST be set equal to the priority that would be
assigned, based on the algorithm in Section 4.1.2, to a peer assigned, based on the algorithm in Section 4.1.2, to a peer
reflexive candidate, should one be learned as a consequence of this reflexive candidate, should one be learned as a consequence of this
check (see Section 7.1.2.2.1 for how peer reflexive candidates are check (see Section 7.1.2.2.1 for how peer reflexive candidates are
learned). This priority value will be computed identically to how learned). This priority value will be computed identically to how
the priority for the local candidate of the pair was computed, except the priority for the local candidate of the pair was computed, except
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.1 provides
guidance on determining when to include it. guidance on determining when to include it.
7.1.1.2. ICE-CONTROLLED and ICE-CONTROLLING 7.1.1.2. ICE-CONTROLLED and ICE-CONTROLLING
The agent MUST include the ICE-CONTROLLED attribute in the request if The agent MUST include the ICE-CONTROLLED attribute in the request if
it is in the controlled role, and MUST include the ICE-CONTROLLING it is in the controlled role, and MUST include the ICE-CONTROLLING
attribute in the request if it is in the controlling role. The attribute in the request if it is in the controlling role. The
content of either attribute MUST be the tie breaker that was content of either attribute MUST be the tie breaker that was
determined in Section 5.2. determined in Section 5.2. These attributes are defined fully in
Section 18.5.
7.1.1.3. Forming Credentials 7.1.1.3. FINGERPRINT
The agent MUST include the FINGERPRINT attribute in its connectivity
checks.
7.1.1.4. 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 39, line 20 skipping to change at page 42, line 4
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
fragment provided by the peer with the username fragment of the agent fragment provided by the peer with the username fragment of the agent
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.4. DiffServ Treatment 7.1.1.5. DiffServ Treatment
If the agent is using Diffserv Codepoint markings [27] in its media If the agent is using Diffserv Codepoint markings [28] 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 [13], 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 If the STUN transaction generates a 487 (Role Conflict) error
response, the agent checks whether it had included the ICE-CONTROLLED response, the agent checks whether it had included the ICE-CONTROLLED
or ICE-CONTROLLING attribute in the Binding Request. If the request or ICE-CONTROLLING attribute in the Binding Request. If the request
had contained the ICE-CONTROLLED attribute, the agent MUST switch to had contained the ICE-CONTROLLED attribute, the agent MUST switch to
the controlling role if it has not already done so. If the request the controlling role if it has not already done so. If the request
had contained the ICE-CONTROLLING attribute, the agent MUST switch to had contained the ICE-CONTROLLING attribute, the agent MUST switch to
the controlled role if it has not already done so. Once it has the controlled role if it has not already done so. Once it has
switched, the agent MUST immediately retry the request with the ICE- switched, the agent MUST enqueue the candidate pair whose check
CONTROLLING or ICE-CONTROLLED attribute reflecting its new role. generated the 487 into the triggered check queue. The state of that
Note, however, that the tie-breaker value MUST NOT be reselected. pair is set to Waiting. When the triggered check is sent, it will
contain an 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 Agents MAY support receipt of ICMP errors for connectivity checks.
error response that is unrecoverable (as defined in [12], or times If the STUN transaction generates an ICMP error, the agent sets the
out, the agent sets the state of the pair to Failed. state of the pair to Failed. If the STUN transaction generates a
STUN error response that is unrecoverable (as defined in [13]), or
times 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.
skipping to change at page 41, line 5 skipping to change at page 43, line 43
o Its priority is set equal to the value of the PRIORITY attribute o Its priority is set equal to the value of the PRIORITY attribute
in the Binding Request. in the Binding Request.
o Its foundation is selected as described in Section 4.1.1. o Its foundation is selected as described in Section 4.1.1.
This peer reflexive candidate is then added to the list of local This peer reflexive candidate is then added to the list of local
candidates for the media stream. Its username fragment and password candidates for the media stream. Its username fragment and password
are the same as all other local candidates for that media stream. are the same as all other local candidates for that media stream.
However, the peer reflexive candidate is not paired with other remote However, the peer reflexive candidate is not paired with other remote
candidates. This is not necessary; a valid pair will be generated candidates. This is not necessary; a valid pair will be generated
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.2. 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. Constructing a Valid Pair
The agent constructs a candidate pair whose local candidate equals
the mapped address of the response, and whose remote candidate equals
the destination address to which the request was sent. This is
called a valid pair, since it has been validated by a STUN
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
pair not currently on any check list. If the pair equals the pair
that generated the check or is on a check list currently, it is also
added to the VALID LIST, which is maintained by the agent for each
media stream. This list is empty at the start of ICE processing, and
fills as checks are performed, resulting in valid candidate pairs.
It will be very common that the pair will not be on any check list.
Recall that the check list has pairs whose local candidates are never
server reflexive; those pairs had their local candidates converted to
the base of the server reflexive candidates, and then pruned if they
were redundant. When the response to the STUN check arrives, the
mapped address will be reflexive if there is a NAT between the two.
In that case, the valid pair will have a local candidate that doesn't
match any of the pairs in the check list.
If the pair is not on any check list, the agent computes the priority
for the pair based on the priority of each candidate, using the
algorithm in Section 5.7. The priority of the local candidate
depends on its type. If it is not peer reflexive, it is equal to the
priority signaled for that candidate in the SDP. If it is peer
reflexive, it is equal to the PRIORITY attribute the agent placed in
the Binding Request which just completed. The priority of the remote
candidate is taken from the SDP of the peer. If the candidate does
not appear there, then the check must have been a triggered check to
a new remote candidate. In that case, the priority is taken as the
value of the PRIORITY attribute in the Binding Request which
triggered the check that just completed. The pair is then added to
the VALID LIST.
7.1.2.2.3. 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 success of this check might also cause the state of Succeeded. The success of this check might also cause the state of
other checks to change as well. The agent MUST perform the following other checks to change as well. The agent MUST perform the following
two steps: two steps:
1. The agent changes the states for all other Frozen pairs for the 1. The agent changes the states for all other Frozen pairs for the
same media stream and same foundation to Waiting. Typically same media stream and same foundation to Waiting. Typically
these other pairs will have different component IDs but not these other pairs will have different component IDs but not
always. always.
skipping to change at page 41, line 43 skipping to change at page 45, line 24
other media stream in turn: other media stream in turn:
* If the check list is active, the agent changes the state of * If the check list is active, the agent changes the state of
all Frozen pairs in that check list whose foundation matches a all Frozen pairs in that check list whose foundation matches a
pair in the valid list under consideration, to Waiting. pair in the valid list under consideration, to Waiting.
* If the check list is frozen, and there is at least one pair in * 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 the check list whose foundation matches a pair in the valid
list under consideration, the state of all pairs in the check list under consideration, the state of all pairs in the check
list whose foundation matches a pair in the valid list under list whose foundation matches a pair in the valid list under
consideration are set to Waiting. consideration are set to Waiting. This will cause the check
list to become active, and ordinary checks will begin for it,
as described in Section 5.8.
* If the check list is frozen, and there are no pairs in the * If the check list is frozen, and there are no pairs in the
check list whose foundation matches a pair in the valid list check list whose foundation matches a pair in the valid list
under consideration, the agent under consideration, the agent
+ Groups together all of the pairs with the same foundation, + Groups together all of the pairs with the same foundation,
+ For each group, sets the state of the pair with the lowest + For each group, sets the state of the pair with the lowest
component ID to Waiting. If there is more than one such component ID to Waiting. If there is more than one such
pair, the one with the highest priority is used. pair, the one with the highest priority is used.
7.1.2.2.3. Constructing a Valid Pair
Next, the agent constructs a candidate pair whose local candidate
equals the mapped address of the response, and whose remote candidate
equals the destination address to which the request was sent. This
is called a valid pair, since it has been validated by a STUN
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
pair not currently on any check list. If the pair equals the pair
that generated the check or is on a check list currently, it is also
added to the VALID LIST, which is maintained by the agent for each
media stream. This list is empty at the start of ICE processing, and
fills as checks are performed, resulting in valid candidate pairs.
It will be very common that the pair will not be on any check list.
Recall that the check list has pairs whose local candidates are never
server reflexive; those pairs had their local candidates converted to
the base of the server reflexive candidates, and then pruned if they
were redundant. When the response to the STUN check arrives, the
mapped address will be reflexive if there is a NAT between the two.
In that case, the valid pair will have a local candidate that doesn't
match any of the pairs in the check list.
If the pair is not on any check list, the agent computes the priority
for the pair based on the priority of each candidate, using the
algorithm in Section 5.7. The priority of the local candidate
depends on its type. If it is not peer reflexive, it is equal to the
priority signaled for that candidate in the SDP. If it is peer
reflexive, it is equal to the PRIORITY attribute the agent placed in
the Binding Request which just completed. The priority of the remote
candidate is taken from the SDP of the peer. If the candidate does
not appear there, then the check must have been a triggered check to
a new remote candidate. In that case, the priority is taken as the
value of the PRIORITY attribute in the Binding Request which
triggered the check that just completed. The pair is then added to
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 valid pair 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.
skipping to change at page 43, line 18 skipping to change at page 46, line 12
valid pair having its nominated flag set. See Section 7.2.1.5 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 7.1.2.3. Check List and Timer State Updates
Regardless of whether the check was successful or failed, the Regardless of whether the check was successful or failed, the
completion of the transaction may require updating of check list and completion of the transaction may require updating of check list and
timer states. timer states.
If all of the pairs in the check list are now either in the Failed or 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 Succeeded state:
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 If 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.
o For each group, sets the state of the pair with the lowest o For each frozen check list, the agent:
component ID to Waiting. If there is more than one such pair, the
one with the highest priority is used. * 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.
If none of the pairs in the check list are in the Waiting or Frozen 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 state, the check list is no longer considered active, and will not
count towards the value of N in the computation of timers for count towards the value of N in the computation of timers for
periodic checks as described in Section 5.8. ordinary checks as described in Section 5.8.
7.2. Server Procedures 7.2. STUN 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. This
Receipt of a Binding Request on a base is an indication that the requirement holds even if the peer is a lite implementation. Receipt
connectivity check usage applies to the request. of a Binding Request on a base is an indication that the 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 offerer will receive a Binding Request prior to
receiving the answer from its peer. If this happens, the agent MUST receiving the answer from its peer. If this happens, the agent MUST
generate a response (including computation of the mapped address as generate a response (including computation of the mapped address as
described in Section 7.2.1.2. Once the answer is received, it MUST 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, 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 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, cases where multiple STUN requests are received before the answer,
this may cause several triggered notifications to all be sent at the this may cause several pairs to be queued up in the triggered check
same time, queue.
If the agent is using Diffserv Codepoint markings [27] in its media An agent MUST NOT generate a Binding Error Response with an ERROR-
CODE attribute of 300 (Try Alternate). That code is not meaningful
for connectivity checks.
An agent MUST NOT include a NONCE attribute in any response. Though
permitted by STUN for authentication using short term credentials,
with ICE it significantly increases delays.
The agent MUST include the FINGERPRINT attribute in its responses to
connectivity checks.
If the agent is using Diffserv Codepoint markings [28] 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. The same would apply to any layer 2 markings the Binding Requests. The same would apply to any layer 2 markings the
endpoint might be applying to media packets. 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. to full implementations.
7.2.1.1. Detecting and Repairing Role Conflicts 7.2.1.1. Detecting and Repairing Role Conflicts
skipping to change at page 44, line 33 skipping to change at page 47, line 41
and one controlled. However, in unusual call flows, typically and one controlled. However, in unusual call flows, typically
utilizing third party call control, it is possible for both agents to utilizing third party call control, it is possible for both agents to
select the same role. This section describes procedures for checking select the same role. This section describes procedures for checking
for this case and repairing it. for this case and repairing it.
An agent MUST examine the Binding Request for either the ICE- An agent MUST examine the Binding Request for either the ICE-
CONTROLLING or ICE-CONTROLLED attribute. It MUST follow these CONTROLLING or ICE-CONTROLLED attribute. It MUST follow these
procedures: procedures:
o If neither ICE-CONTROLLING or ICE-CONTROLLED are present in the o If neither ICE-CONTROLLING or ICE-CONTROLLED are present in the
request, there is no conflict. request, the peer agent may have implemented a previous version of
this specification. There may be a conflict, but it cannot be
detected.
o If the agent is in the controlling role, and the ICE-CONTROLLING o If the agent is in the controlling role, and the ICE-CONTROLLING
attribute is present in the request: attribute is present in the request:
* If the agent's tie-breaker is larger than or equal to the * If the agent's tie-breaker is larger than or equal to the
contents of the ICE-CONTROLLING attribute, the agent generates contents of the ICE-CONTROLLING attribute, the agent generates
a Binding Error Response and includes an ERROR-CODE attribute a Binding Error Response and includes an ERROR-CODE attribute
with a value of 487 (Role Conflict) but retains its role. with a value of 487 (Role Conflict) but retains its role.
* If the agent's tie-breaker is less than the contents of the * If the agent's tie-breaker is less than the contents of the
skipping to change at page 45, line 16 skipping to change at page 48, line 26
* If the agent's tie-breaker is less than the contents of the * If the agent's tie-breaker is less than the contents of the
ICE-CONTROLLED attribute, the agent generates a Binding Error ICE-CONTROLLED attribute, the agent generates a Binding Error
Response and includes an ERROR-CODE attribute with a value of Response and includes an ERROR-CODE attribute with a value of
487 (Role Conflict) but retains its role. 487 (Role Conflict) but retains its role.
o If the agent is in the controlled role and the ICE-CONTROLLING 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 attribute was present in the request, or the agent was in the
controlling role and the ICE-CONTROLLED attribute was present in controlling role and the ICE-CONTROLLED attribute was present in
the request, there is no conflict. the request, there is no conflict.
A change in roles will require an agent to recompute pair priorities
Section 5.7.2, since those priorities are a function of controlling
and controlled role. The change in role will also impact whether the
agent is responsible for selecting nominated pairs and generated
updated offers upon conclusion of ICE.
The remaining sections in Section 7.2.1 are followed if the server The remaining sections in Section 7.2.1 are followed if the server
generated a successful response to the Binding Request, even if the generated a successful response to the Binding Request, even if the
agent changed roles. agent changed roles.
7.2.1.2. Computing Mapped Address 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-
skipping to change at page 46, line 21 skipping to change at page 49, line 36
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, a check for
changed to In-Progress and a check for that pair is performed that pair is enqueued into the triggered check queue.
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 cancels the
generate an immediate retransmit of the Binding Request for the in-progress transaction. Cancellation means that the agent
check in progress. This is to facilitate rapid completion of will not retransmit the request, will not treat the lack of
ICE when both agents are behind NAT. It is RECOMMENDED that, response to be a failure, but will wait the duration of the
after the immediate retransmit, the next retransmission occur T transaction timeout for a response. In addition, the agent
milliseconds later, where T is the current STUN retransmit MUST create a new connectivity check for that pair
interval. If the immediate retransmit causes the total number (representing a new STUN Binding Request transaction) by
of requests transmitted to equal the maximum value defined in enqueueing the pair in the triggered check queue. The state of
[12], the agent SHOULD NOT send any further retransmits. the pair is then changed to Waiting.
* If the state of that pair is Failed or Succeeded, no triggered * If the state of the pair is Failed, it is changed to Waiting
check is sent. and the agent MUST create a new connectivity check for that
pair (representing a new STUN Binding Request transaction), by
enqueueing the pair in the triggered check queue.
* If the state of that pair is Succeeded, nothing further is
done.
o These steps are done to facilitate rapid completion of ICE when
both agents are behind NAT.
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 Waiting
* A triggered check for that pair is performed immediately. * The pair is enqueued into the triggered check queue.
If a triggered check is to be generated, it is constructed and When a triggered check is to be sent, it is constructed and processed
processed as described in Section 7.1.1. These procedures require as described in Section 7.1.1. These procedures require the agent to
the agent to know the transport address, username fragment and know the transport address, username fragment and password for the
password for the peer. The username fragment for the remote peer. The username fragment for the remote candidate is equal to the
candidate is equal to the part after the colon of the USERNAME in the part after the colon of the USERNAME in the Binding Request that was
Binding Request that was just received. Using that username just received. Using that username fragment, the agent can check the
fragment, the agent can check the SDP messages received from its peer SDP messages received from its peer (there may be more than one in
(there may be more than one in cases of forking), and find this cases of forking), and find this username fragment. The
username fragment. The corresponding password is then selected. If corresponding password is then selected.
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 SDP to be received (since it won't have its peer's ICE password
without it), and then proceed with the triggered check.
7.2.1.5. 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.4: 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.2). 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
set when the response arrives. This may end ICE processing for set when the response arrives. This may end ICE processing for
this media stream when it arrives; see Section 8. this media stream when it arrives; see Section 8.
7.2.2. Additional Procedures for Lite Implementations 7.2.2. Additional Procedures for Lite Implementations
If the check that was just received contained a USE-CANDIDATE If the check that was just received contained a USE-CANDIDATE
attribute, the agent constructs a candidate pair whose local attribute, the agent constructs a candidate pair whose local
candidate is equal to the transport address on which the request was candidate is equal to the transport address on which the request was
received, and whose remote candidate is equal to the source transport received, and whose remote candidate is equal to the source transport
address of the request that was received. This candidate pair is address of the request that was received. This candidate pair is
assigned an arbitrary priority, and placed into a list of valid assigned an arbitrary priority, and placed into a list of valid
candidates pair for that component of that media stream, called the candidates called the valid list. The agent sets the nominated flag
valid list. The agent sets the nominated flag for that pair to true. for that pair to true. ICE processing is considered complete for a
ICE processing is considered complete for a media stream if the valid media stream if the valid list contains a candidate pair for each
list contains a candidate pair for each component. component.
8. Concluding ICE Processing 8. Concluding ICE Processing
The processing rules in this section apply only to full This section describes how an agent completes ICE.
implementations. Concluding ICE involves nominating pairs by the
controlling agent and updating of state machinery
8.1. Nominating Pairs 8.1. Procedures for Full Implementations
Concluding ICE involves nominating pairs by the controlling agent and
updating of state machinery.
8.1.1. Nominating Pairs
The controlling agent nominates pairs to be selected by ICE by using The controlling agent nominates pairs to be selected by ICE by using
one of two techniques: regular nomination or aggressive nomination. one of two techniques: regular nomination or aggressive nomination.
If its peer has a lite implementation, an agent MUST use a regular If its peer has a lite implementation, an agent MUST use a regular
nomination algorithm. If its peer is using ICE options (present in nomination algorithm. If its peer is using ICE options (present in
an ice-options attribute from the peer) that the agent does not an ice-options attribute from the peer) that the agent does not
understand, the agent MUST use a regular nomination algorithm. If understand, the agent MUST use a regular nomination algorithm. If
its peer is a full implementation and isn't using any ICE options or its peer is a full implementation and isn't using any ICE options or
is using ICE options understood by the agent, the agent MAY use is using ICE options understood by the agent, the agent MAY use
either the aggressive or the regular nomination algorithm. However, either the aggressive or the regular nomination algorithm. However,
the regular algorithm is RECOMMENDED since it provides greater the regular algorithm is RECOMMENDED since it provides greater
stability. stability.
8.1.1. Regular Nomination 8.1.1.1. Regular Nomination
With regular nomination, the agent lets some number of checks With regular nomination, the agent lets some number of checks
complete, each of which omit the USE-CANDIDATE attribute. Once one complete, each of which omit the USE-CANDIDATE attribute. Once one
or more checks complete successfully for a component of a media or more checks complete successfully for a component of a media
stream, valid pairs are generated and added to the valid list. The stream, valid pairs are generated and added to the valid list. The
agent lets the checks continue until some stopping criteria is met, agent lets the checks continue until some stopping criteria is met,
and then picks amongst the valid pairs based on an evaluation and then picks amongst the valid pairs based on an evaluation
criteria. The criteria for stopping the checks and for evaluating criteria. The criteria for stopping the checks and for evaluating
the valid pairs is entirely a matter of local optimization. the valid pairs is entirely a matter of local optimization.
When the controlling agent selects the valid pair, it repeats the When the controlling agent selects the valid pair, it repeats the
check that produced this valid pair, this time with the USE-CANDIDATE check that produced this valid pair (by enqueuing the pair that
attribute. This check will succeed (since the previous did), causing generated the check into the triggered check queue), this time with
the nominated flag of that and only that pair to be set. the USE-CANDIDATE attribute. This check should succeed (since the
Consequently, there will be only a single nominated pair in the valid previous did), causing the nominated flag of that and only that pair
list, and when the state of the check list moves to completed, that to be set. Consequently, there will be only a single nominated pair
exact pair is selected by ICE for sending and receiving media. in the valid list for each component, and when the state of the check
list moves to completed, that exact pair is selected by ICE for
sending and receiving media for that component.
Regular nomination provides the most flexibility, since the agent has 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.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
for a component succeeds, it will be added to the valid list, have for a component succeeds, it will be added to the valid list, and
its nominated flag set, and then cause ICE processing to cease for have its nominated flag set. When all components have a nominated
pair in the valid list, it will cause ICE processing to cease for
this check list. However, because the agent included the USE- this check list. However, because the agent included the USE-
CANDIDATE attribute in all of its checks, another check may yet CANDIDATE attribute in all of its checks, another check may yet
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.1.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 and on the state of the check list: the valid list and on the state of the check list. Note that, at any
time, more than one of the following cases can apply:
o If there are no nominated pairs in the valid list for a media o If there are no nominated pairs in the valid list for a media
stream and the state of the check list is Running, ICE processing stream and the state of the check list is Running, ICE processing
continues. continues.
o If there is at least one nominated pair in the valid list for a 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: 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 and triggered check queue for the same component as the
media stream nominated pairs for that 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 and the state of the every component of at least one media stream and the state of the
check list is Running: check list is Running:
skipping to change at page 50, line 29 skipping to change at page 54, line 5
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 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 complete for this media stream. The correct behavior depends on
the state of the check lists for other media streams: the state of the check lists for other media streams:
* If all check lists are Failed, the agent SHOULD consider the * If all check lists are Failed, ICE processing overall is
session a failure, SHOULD NOT restart ICE, and the controlling considered to be in the Failed state, and the agent SHOULD
agent SHOULD terminate the entire session. 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 * If at least one of the check lists for other media streams is
Completed, the controlling agent SHOULD remove the failed media Completed, the controlling agent SHOULD remove the failed media
stream from the session in its updated offer. stream from the session in its updated offer.
* If none of the check lists for other media streams are * If none of the check lists for other media streams are
Completed, but at least one is Running, the agent SHOULD let Completed, but at least one is Running, the agent SHOULD let
ICE continue. ICE continue.
8.2. Procedures for Lite Implementations
Concluding ICE for a lite implementation is relatively
straightforward. There are two cases to consider:
The implementation is lite, and its peer is full.
The implementation is lite, and its peer is lite.
The effect of ICE concluding is that the agent can free any allocated
host candidates that were not utilized by ICE, as described in
Section 8.3.
8.2.1. Peer is Full
In this case, the agent will receive connectivity checks from its
peer. When an agent has received a connectivity check that includes
the USE-CANDIDATE attribute for each component of a media stream, the
state of ICE processing for that media stream moves from Running to
Completed. When the state of ICE processing for all media streams is
Completed, the state of ICE processing overall is Completed.
The lite implementation will never itself determine that ICE
processing has failed for a media stream; rather, the full peer will
make that determination and then remove or restart the failed media
stream in a subsequent offer.
8.2.2. Peer is Lite
Once the offer/answer exchange has completed, the controlling agent
examines its own candidate pairs and those of its peer. For each
media stream, it pairs up its own candidates with the candidates of
its peer for that media stream. Two candidates are paired up when
they are for the same component, utilize the same transport protocol
(UDP in this specification), and are from the same IP address family
(IPv4 or IPv6). If an implementation is IPv4 only, this will always
produce a single pair per component. That pair is added to the Valid
list and the state of ICE processing is set to Completed for each
media stream and for ICE overall.
If there is more than one pair per component:
o The agent MUST select a pair based on local policy. Since this
case only arises for IPv6, it is RECOMMENDED that an agent follow
the procedures of RFC 3484 [12] to select a single pair.
o The agent adds the selected pair for each component to the valid
list. As described in Section 11.1, this will permit media to
begin flowing. However, it is possible (and in fact likely) that
both agents have chosen different pairs.
o To reconcile this, the controlling agent MUST send an updated
offer as described in Section 9.1.3, which will include the
remote-candidates attribute.
o The agent MUST NOT update the state of ICE processing when the
offer is sent. If this subsequent offer completes, the
controlling agent MUST change the state of ICE processing to
Completed for all media streams, and the state of ICE processing
overall to Completed. The states for the controlled agent are set
based on the logic in Section 9.2.3.
8.3. Freeing Candidates
8.3.1. Full Implementation Procedures
The procedures in Section 8 require that an agent continue to listen
for STUN requests and continue to generate triggered checks for a
media stream, even once processing for that stream completes. The
rules in this section describe when it is safe for an agent to cease
sending or receiving checks on a candidate that was not selected by
ICE, and then free the candidate.
When ICE is used with SIP, and an offer is forked to multiple
recipients, ICE proceeds in parallel and independently with each
answerer, all using the same local candidates. Once ICE processing
has reached the Completed state for all peers for media streams using
those candidates, the agent SHOULD wait an additional three seconds,
and then it MAY cease responding to checks or generating triggered
checks on that candidate. It MAY free the candidate at that time.
Freeing of server reflexive candidates is never explicit; it happens
by lack of a keepalive. The three second delay handles cases when
aggressive nomination is used, and the selected pairs can quickly
change after ICE has completed.
8.3.2. Lite Implementations
A lite implementation MAY free candidates not selected by ICE as soon
as ICE processing has reached the completed state for all peers for
all media streams using those candidates.
9. Subsequent Offer/Answer Exchanges 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.
Should a subsequent offer be rejected, ICE processing continues as if
the subsequent offer had never been made.
9.1. Generating the Offer 9.1. Generating the Offer
9.1.1. Procedures for All Implementations 9.1.1. Procedures for All Implementations
9.1.1.1. ICE Restarts 9.1.1.1. ICE Restarts
An agent MAY restart ICE processing for an existing media stream. An An agent MAY restart ICE processing for an existing media stream. An
ICE restart, as the name implies, will cause all previous state of ICE restart, as the name implies, will cause all previous state of
ICE processing to be flushed and checks to start anew. The only ICE processing to be flushed and checks to start anew. The only
difference between an ICE restart and a brand new media session is difference between an ICE restart and a brand new media session is
skipping to change at page 53, line 34 skipping to change at page 59, line 5
is in the Completed state. The attribute contains the remote is in the Completed state. The attribute contains the remote
candidates from the highest priority nominated pair in the valid list candidates from the highest priority nominated pair in the valid list
for each component of that media stream. It is needed to avoid a for each component of that media stream. It is needed to avoid a
race condition whereby the controlling agent chooses its pairs, but race condition whereby the controlling agent chooses its pairs, but
the updated offer beats the connectivity checks to the controlled the updated offer beats the connectivity checks to the controlled
agent, which doesn't even know these pairs are valid, let alone agent, which doesn't even know these pairs are valid, let alone
selected. See Appendix B.6 for elaboration on this race condition. selected. See Appendix B.6 for elaboration on this race condition.
9.1.3. Procedures for Lite Implementations 9.1.3. Procedures for Lite Implementations
9.1.3.1. Existing Media Streams with ICE Running
This section describes procedures for lite implementations for This section describes procedures for lite implementations for
existing streams for which ICE is running. existing streams for which ICE is running.
A lite implementation MUST include its one and only candidate for A lite implementation MUST include all of its candidates for each
each component of each media stream in an a=candidate attribute in component of each media stream in an a=candidate attribute in any
any subsequent offer. This candidate is formed identically to the subsequent offer. These candidates are formed identically to the
procedures for initial offers, as described in Section 4.2. procedures for initial offers, as described in Section 4.2.
A lite implementation MUST NOT add additional host candidates in a
subsequent offer. If an agent needs to offer additional candidates,
it MUST restart ICE.
The username fragments, password, and implementation level MUST The username fragments, password, and implementation level MUST
remain the same as used previously. If an agent needs to change one remain the same as used previously. If an agent needs to change one
of these it MUST restart ICE for that media stream. of these it MUST restart ICE for that media stream.
9.1.3.2. Existing Media Streams with ICE Completed
If ICE has completed for a media stream, the default destination for
that media stream MUST be set to the remote candidate of the
candidate pair for that component in the valid list. For a lite
implementation, there is always just a single candidate pair in the
valid list for each component of a media stream. Additionally, the
agent MUST include a candidate attribute for each default
destination.
Additionally, if the agent is controlling (which only happens when
both agents are lite), the agent MUST include the a=remote-candidates
attribute for each media stream. The attribute contains the remote
candidates from the candidate pairs in the valid list (one pair for
each component of each media stream).
9.2. Receiving the Offer and Generating an Answer 9.2. Receiving the Offer and Generating an Answer
9.2.1. Procedures for All Implementations 9.2.1. Procedures for All Implementations
When receiving a subsequent offer within an existing session, an When receiving a subsequent offer within an existing session, an
agent MUST re-apply the verification procedures in Section 5.1 agent MUST re-apply the verification procedures in Section 5.1
without regard to the results of verification from any previous without regard to the results of verification from any previous
offer/answer exchanges. Indeed, it is possible that a previous offer/answer exchanges. Indeed, it is possible that a previous
offer/answer exchange resulted in ICE not being used, but it is used offer/answer exchange resulted in ICE not being used, but it is used
as a consequence of a subsequent exchange. as a consequence of a subsequent exchange.
skipping to change at page 54, line 45 skipping to change at page 60, line 42
9.2.1.3. Removed Media Stream 9.2.1.3. Removed Media Stream
If an offer contains a media stream whose port is zero, the agent If an offer contains a media stream whose port is zero, the agent
MUST NOT include any candidate attributes for that media stream in MUST NOT include any candidate attributes for that media stream in
its answer and SHOULD NOT include any other ICE-related attributes its answer and SHOULD NOT include any other ICE-related attributes
defined in Section 15 for that media stream. defined in Section 15 for that media stream.
9.2.2. Procedures for Full Implementations 9.2.2. Procedures for Full Implementations
The username fragments, password, and implementation level MUST Unless the agent has detected an ICE restart from the offer, the
remain the same as used previously. If an agent needs to change one username fragments, password, and implementation level MUST remain
of these it MUST restart ICE for that media stream by generating an the same as used previously. If an agent needs to change one of
these it MUST restart ICE for that media stream by generating an
offer; ICE cannot be restarted in an answer. offer; ICE cannot be restarted in an answer.
Additional behaviors depend on the state of ICE processing for that Additional behaviors depend on the state of ICE processing for that
media stream. media stream.
9.2.2.1. Existing Media Streams with ICE Running and no remote- 9.2.2.1. Existing Media Streams with ICE Running and no remote-
candidates candidates
If ICE is running for a media stream, and the offer for that media If ICE is running for a media stream, and the offer for that media
stream lacked the remote-candidates attribute, the rules for stream lacked the remote-candidates attribute, the rules for
skipping to change at page 56, line 22 skipping to change at page 62, line 22
Once there are no losing pairs, the agent can generate the answer. Once there are no losing pairs, the agent can generate the answer.
It MUST set the default destination for media to the candidates in It MUST set the default destination for media to the candidates in
the remote-candidates attribute from the offer (each of which will the remote-candidates attribute from the offer (each of which will
now be the local candidate of a candidate pair in the valid list). now be the local candidate of a candidate pair in the valid list).
It MUST include a candidate attribute in the answer for each It MUST include a candidate attribute in the answer for each
candidate in the remote-candidates attribute in the offer. candidate in the remote-candidates attribute in the offer.
9.2.3. Procedures for Lite Implementations 9.2.3. Procedures for Lite Implementations
A lite implementation constructs its answer in the same way it does a If the received offer contains the remote-candidates attribute for a
subsequent offer as described in Section 9.1.3 media stream, the agent forms a candidate pair for each component of
the media stream by:
o Setting the remote candidate equal to the offerers default
destination for that component (e.g., the contents of the m and
c-lines for RTP, and the a=rtcp attribute for RTCP)
o Setting the local candidate equal to the transport address for
that same component in the a=remote-candidates attribute in the
offer.
It then places those candidates into the Valid list for the media
stream. The state of ICE processing for that media stream is set to
Completed.
Furthermore, if the agent believed it was controlling, but the offer
contained the remote-candidates attribute, both agents believe they
are controlling. In this case, both would have sent updated offers
around the same time. However, the signaling protocol carrying the
offer/answer exchanges will have resolved this glare condition, so
that one agent is always the 'winner' by having its offer received
before its peer has sent an offer. The winner takes the role of
controlled, so that the loser (the answerer under consideration in
this section MUST change its role to controlled. Consequently, if
the agent was going to send an updated offer since, based on the
rules in Section 8.2.2, it was controlling, it no longer needs to.
Besides the potential role change, change in the Valid list, and
state changes, the construction of the answer is performed
identically to the construction of an offer as described in
Section 9.1.3.
9.3. Updating the Check and Valid Lists 9.3. Updating the Check and Valid Lists
9.3.1. Procedures for Full Implementations 9.3.1. Procedures for Full Implementations
9.3.1.1. ICE Restarts 9.3.1.1. ICE Restarts
The agent MUST remember the highest priority nominated pairs in the The agent MUST remember the highest priority nominated pairs in the
Valid list for each component of the media stream, called the Valid list for each component of the media stream, called the
previous selected pairs, prior to the restart. The agent will previous selected pairs, prior to the restart. The agent will
skipping to change at page 56, line 51 skipping to change at page 63, line 33
If the offer/answer exchange added a new media stream, the agent MUST If the offer/answer exchange added a new media stream, the agent MUST
create a new check list for it (and an empty Valid list to start of create a new check list for it (and an empty Valid list to start of
course), as described in Section 5.7. course), as described in Section 5.7.
9.3.1.3. Removed Media Stream 9.3.1.3. Removed Media Stream
If the offer/answer exchange removed a media stream, or an answer If the offer/answer exchange removed a media stream, or an answer
rejected an offered media stream, an agent MUST flush the Valid list rejected an offered media stream, an agent MUST flush the Valid list
for that media stream. It MUST terminate any STUN transactions in for that media stream. It MUST terminate any STUN transactions in
progress for that media stream. An agent MUST remove the check list progress for that media stream. An agent MUST remove the check list
for that media stream and cancel any pending periodic checks for it. for that media stream and cancel any pending ordinary checks for it.
9.3.1.4. ICE Continuing for Existing Media Stream 9.3.1.4. ICE Continuing for Existing Media Stream
The valid list is not affected by an updated offer/answer exchange The valid list is not affected by an updated offer/answer exchange
unless ICE is restarting. unless ICE is restarting.
If an agent is in the Running state for that media stream, the check If an agent is in the Running state for that media stream, the check
list is updated (the check list is irrelevant if the state is list is updated (the check list is irrelevant if the state is
completed). To do that, the agent recomputes the check list using completed). To do that, the agent recomputes the check list using
the procedures described in Section 5.7. If a pair on the new check the procedures described in Section 5.7. If a pair on the new check
skipping to change at page 57, line 40 skipping to change at page 64, line 22
the agent moves the state of all Frozen pairs for the first component the agent moves the state of all Frozen pairs for the first component
of all other media streams (and thus in different check lists) with of all other media streams (and thus in different check lists) with
the same foundation to Waiting. the same foundation to Waiting.
9.3.2. Procedures for Lite Implementations 9.3.2. Procedures for Lite Implementations
If ICE is restarting for a media stream, the agent MUST start a new If ICE is restarting for a media stream, the agent MUST start a new
Valid list for that media stream. It MUST remember the pairs in the Valid list for that media stream. It MUST remember the pairs in the
previous Valid list for each component of the media stream, called previous Valid list for each component of the media stream, called
the previous selected pairs, and continue to send media there as the previous selected pairs, and continue to send media there as
described in Section 11.1. described in Section 11.1. The state of ICE processing for each
media stream MUST change to Running, and the state of ICE processing
MUST change to running.
10. Keepalives 10. Keepalives
All endpoints MUST send keepalives for each media session. These All endpoints MUST send keepalives for each media session. These
keepalives serve the purpose of keeping NAT bindings alive for the keepalives serve the purpose of keeping NAT bindings alive for the
media session. These keepalives MUST be sent regardless of whether media session. These keepalives MUST be sent regardless of whether
the media stream is currently inactive, sendonly, recvonly or the media stream is currently inactive, sendonly, recvonly or
sendrecv, and regardless of the presence or value of the bandwidth sendrecv, and regardless of the presence or value of the bandwidth
attribute. These keepalives MUST be sent even if ICE is not being attribute. These keepalives MUST be sent even if ICE is not being
utilized for the session at all. The keepalive SHOULD be sent using utilized for the session at all. The keepalive SHOULD be sent using
a format which is supported by its peer. ICE endpoints allow for a format which is supported by its peer. ICE endpoints allow for
STUN-based keepalives for UDP streams, and as such, STUN keepalives STUN-based keepalives for UDP streams, and as such, STUN keepalives
MUST be used when an agent is communicating with a peer that supports MUST be used when an agent is communicating with a peer that supports
ICE. An agent can determine that its peer supports ICE by the ICE. An agent can determine that its peer supports ICE by the
presence of a=candidate attributes for each media session. If the presence of a=candidate attributes for each media session. If the
peer does not support ICE, the choice of a packet format for peer does not support ICE, the choice of a packet format for
keepalives is a matter of local implementation. A format which keepalives is a matter of local implementation. A format which
allows packets to easily be sent in the absence of actual media allows packets to easily be sent in the absence of actual media
content is RECOMMENDED. Examples of formats which readily meet this content is RECOMMENDED. Examples of formats which readily meet this
goal are RTP No-Op [31] and RTP comfort noise [25]. If the peer goal are RTP No-Op [32], and in cases where both sides support it,
doesn't support any formats that are particularly well suited for RTP comfort noise [26]. If the peer doesn't support any formats that
keepalives, an agent SHOULD send RTP packets with an incorrect are particularly well suited for keepalives, an agent SHOULD send RTP
version number, or some other form of error which would cause them to packets with an incorrect version number, or some other form of error
be discarded by the peer. which would cause them to be discarded by the peer.
If there has been no packet sent on the candidate pair ICE is using If there has been no packet sent on the candidate pair ICE is using
for a media component for Tr seconds (where packets include those for a media component for Tr seconds (where packets include those
defined for the component (RTP or RTCP) and previous keepalives), an defined for the component (RTP or RTCP) and previous keepalives), an
agent MUST generate a keepalive on that pair. Tr SHOULD be agent MUST generate a keepalive on that pair. Tr SHOULD be
configurable and SHOULD have a default of 15 seconds. Alternatively, configurable and SHOULD have a default of 15 seconds. Alternatively,
if an agent has a dynamic way to discover the binding lifetimes of if an agent has a dynamic way to discover the binding lifetimes of
the intervening NATs, it can use that value to determine Tr. the intervening NATs, it can use that value to determine Tr.
If STUN is being used for keepalives, a STUN Binding Indication is If STUN is being used for keepalives, a STUN Binding Indication using
used [12]. The Binding Indication SHOULD NOT contain integrity the Indication Keepalive usage is used [13]. The Indication SHOULD
checks as the messages are simply discarded on receipt regardless of NOT contain the ICE-CONTROLLING, ICE-CONTROLLED, PRIORITY or USE-
contents. The Indication SHOULD NOT contain the PRIORITY or USE- CANDIDATE attributes defined in this document, as they are part of
CANDIDATE attributes defined in this document. The Binding the connectivity check usage, not the Indication Keepalive usage.
Indication is sent using the same local and remote candidates that The Binding Indication is sent using the same local and remote
are being used for media. An agent receiving a Binding Indication candidates that are being used for media. Though Binding Indications
MUST discard it silently. Though Binding Indications are used for are used for keepalives, an agent MUST be prepared to receive a
keepalives, an agent MUST be prepared to receive Binding Requests as connectivity check as well. If a connectivity check is received, a
well. If a Binding Request is received, a response is generated as response is generated as discussed in [13], but there is no impact on
discussed in [12], but there is no impact on ICE processing ICE processing otherwise.
otherwise.
An agent MUST begin the keepalive processing once ICE has selected An agent MUST begin the keepalive processing once ICE has selected
candidates for usage with media, or media begins to flow, whichever candidates for usage with media, or media begins to flow, whichever
happens first. Keepalives end once the session terminates or the happens first. Keepalives end once the session terminates or the
media stream is removed. media stream is removed.
11. Media Handling 11. Media Handling
11.1. Sending Media 11.1. Sending Media
skipping to change at page 59, line 14 skipping to change at page 65, line 44
11.1.1. Procedures for Full Implementations 11.1.1. Procedures for Full Implementations
Agents always send media using a candidate pair, called the selected Agents always send media using a candidate pair, called the selected
candidate pair. An agent will send media to the remote candidate in candidate pair. An agent will send media to the remote candidate in
the selected pair (setting the destination address and port of the the selected pair (setting the destination address and port of the
packet equal to that remote candidate), and will send it from the packet equal to that remote candidate), and will send it from the
local candidate of the selected pair. When the local candidate is local candidate of the selected pair. When the local candidate is
server or peer reflexive, media is originated from the base. Media server or peer reflexive, media is originated from the base. Media
sent from a relayed candidate is sent from the base through that sent from a relayed candidate is sent from the base through that
relay, using procedures defined in [13]. relay, using procedures defined in [14].
The selected pair for a component of a media stream is: The selected pair for a component of a media stream is:
o empty if the state of the check list for that media stream is o empty if the state of the check list for that media stream is
Running, and there is no previous selected pair for that component Running, and there is no previous selected pair for that component
due to an ICE restart due to an ICE restart
o equal to the previous selected pair for a component of a media o equal to the previous selected pair for a component of a media
stream if the state of the check list for that media stream is stream if the state of the check list for that media stream is
Running, and there was a previous selected pair for that component Running, and there was a previous selected pair for that component
due to an ICE restart due to an ICE restart
o equal to the highest priority nominated pair for that component in o equal to the highest priority nominated pair for that component in
the valid list if the state of the check list is Completed the valid list if the state of the check list is Completed
If the selected pair for at least one component of a media stream is If the selected pair for at least one component of a media stream is
empty, an agent MUST NOT send media for any component of that media empty, an agent MUST NOT send media for any component of that media
skipping to change at page 60, line 17 skipping to change at page 66, line 48
ICE has interactions with jitter buffer adaptation mechanisms. An ICE has interactions with jitter buffer adaptation mechanisms. An
RTP stream can begin using one candidate, and switch to another one, RTP stream can begin using one candidate, and switch to another one,
though this happens rarely with ICE. The newer candidate may result though this happens rarely with ICE. The newer candidate may result
in RTP packets taking a different path through the network - one with in RTP packets taking a different path through the network - one with
different delay characteristics. As discussed below, agents are different delay characteristics. As discussed below, agents are
encouraged to re-adjust jitter buffers when there are changes in encouraged to re-adjust jitter buffers when there are changes in
source or destination address of media packets. Furthermore, many source or destination address of media packets. Furthermore, many
audio codecs use the marker bit to signal the beginning of a audio codecs use the marker bit to signal the beginning of a
talkspurt, for the purposes of jitter buffer adaptation. For such talkspurt, for the purposes of jitter buffer adaptation. For such
codecs, it is RECOMMENDED that the sender set the marker bit [22] codecs, it is RECOMMENDED that the sender set the marker bit [23]
when an agent switches transmission of media from one candidate pair when an agent switches transmission of media from one candidate pair
to another. to another.
11.2. Receiving Media 11.2. Receiving Media
ICE implementations MUST be prepared to receive media on each ICE implementations MUST be prepared to receive media on each
component on any candidates provided for that component in the most component on any candidates provided for that component in the most
recent offer/answer exchange (in the case of RTP, this would include recent offer/answer exchange (in the case of RTP, this would include
both RTP and RTCP if candidates were provided for both). both RTP and RTCP if candidates were provided for both).
It is RECOMMENDED that, when an agent receives an RTP packet with a It is RECOMMENDED that, when an agent receives an RTP packet with a
new source or destination IP address for a particular media stream, new source or destination IP address for a particular media stream,
that the agent re-adjust its jitter buffers. that the agent re-adjust its jitter buffers.
RFC 3550 [22] describes an algorithm in Section 8.2 for detecting RFC 3550 [23] describes an algorithm in Section 8.2 for detecting
SSRC collisions and loops. These algorithms are based, in part, on SSRC collisions and loops. These algorithms are based, in part, on
seeing different source transport addresses with the same SSRC. seeing different source transport addresses with the same SSRC.
However, when ICE is used, such changes will sometimes occur as the However, when ICE is used, such changes will sometimes occur as the
media streams switch between candidates. An agent will be able to media streams switch between candidates. An agent will be able to
determine that a media stream is from the same peer as a consequence determine that a media stream is from the same peer as a consequence
of the STUN exchange that proceeds media transmission. Thus, if of the STUN exchange that proceeds media transmission. Thus, if
there is a change in source transport address, but the media packets there is a change in source transport address, but the media packets
come from the same peer agent, this SHOULD NOT be treated as an SSRC come from the same peer agent, this SHOULD NOT be treated as an SSRC
collision. collision.
skipping to change at page 61, line 32 skipping to change at page 68, line 16
such as activity on a keypad or the phone going offhook. such as activity on a keypad or the phone going offhook.
If an offer is received in an INVITE request, the answerer SHOULD If an offer is received in an INVITE request, the answerer SHOULD
begin to gather its candidates on receipt of the offer and then begin to gather its candidates on receipt of the offer and then
generate an answer in a provisional response once it has completed generate an answer in a provisional response once it has completed
that process. ICE requires that a provisional response with an SDP that process. ICE requires that a provisional response with an SDP
be transmitted reliably. This can be done through the existing PRACK be transmitted reliably. This can be done through the existing PRACK
mechanism [9], or through an optimization that is specific to ICE. mechanism [9], or through an optimization that is specific to ICE.
With this optimization, provisional responses containing an SDP With this optimization, provisional responses containing an SDP
answer that begins ICE processing for one or more media streams can answer that begins ICE processing for one or more media streams can
be sent reliably without RFC 3264. To do this, the agent retransmits be sent reliably without RFC 3262. To do this, the agent retransmits
the provisional response with th exponential backoff timers described the provisional response with the exponential backoff timers
in RFC 3262. Retransmits MUST cease on receipt of a STUN Binding described in RFC 3262. Retransmits MUST cease on receipt of a STUN
Request for one of the media streams signaled in that SDP (because Binding Request for one of the media streams signaled in that SDP
receipt of a binding request indicates the offerer has received the (because receipt of a binding request indicates the offerer has
answer) or on transmission of a 2xx response. If no Binding Request received the answer) or on transmission of the answer in a 2xx
is received prior to the last retransmit, the agent does not consider response. If the peer agent is lite, there will never be a STUN
the session terminated. Despite the fact that the provisional Binding Request. In such a case, the agent MUST cease retransmitting
response will be delivered reliably, the rules for when an agent can the 18x after sending it four times (ICE will actually work even if
send an updated offer or answer do not change from those specified in the peer never receives the 18x; however, experience has shown that
RFC 3262. Specifically, if the INVITE contained an offer, the same sending it is important for middleboxes and firewall traversal). If
answer appears in all of the 1xx and in the 2xx response to the no Binding Request is received prior to the last retransmit, the
INVITE. Only after that 2xx has been sent can an updated offer/ agent does not consider the session terminated. Despite the fact
answer exchange occur. This optimization SHOULD NOT be used if both that the provisional response will be delivered reliably, the rules
agents support PRACK. Note that the optimization is very specific to for when an agent can send an updated offer or answer do not change
provisional response carrying answers that start ICE processing; it from those specified in RFC 3262. Specifically, if the INVITE
is not a general technique for 1xx reliability. contained an offer, the same answer appears in all of the 1xx and in
the 2xx response to the INVITE. Only after that 2xx has been sent
can an updated offer/answer exchange occur. This optimization SHOULD
NOT be used if both agents support PRACK. Note that the optimization
is very specific to provisional response carrying answers that start
ICE processing; it is not a general technique for 1xx reliability.
Alternatively, an agent MAY delay sending an answer until the 200 OK, Alternatively, an agent MAY delay sending an answer until the 200 OK,
however this results in a poor user experience and is NOT however this results in a poor user experience and is NOT
RECOMMENDED. RECOMMENDED.
Once the answer has been sent, the agent SHOULD begin its Once the answer has been sent, the agent SHOULD begin its
connectivity checks. Once candidate pairs for each component of a connectivity checks. Once candidate pairs for each component of a
media stream enter the valid list, the answerer can begin sending media stream enter the valid list, the answerer can begin sending
media on that media stream. media on that media stream.
However, prior to this point, any media that needs to be sent towards However, prior to this point, any media that needs to be sent towards
the caller (such as SIP early media [26] MUST NOT be transmitted. the caller (such as SIP early media [27] MUST NOT be transmitted.
For this reason, implementations SHOULD delay alerting the called For this reason, implementations SHOULD delay alerting the called
party until candidates for each component of each media stream have party until candidates for each component of each media stream have
entered the valid list. In the case of a PSTN gateway, this would entered the valid list. In the case of a PSTN gateway, this would
mean that the setup message into the PSTN is delayed until this mean that the setup message into the PSTN is delayed until this
point. Doing this increases the post-dial delay, but has the effect point. Doing this increases the post-dial delay, but has the effect
of eliminating 'ghost rings'. Ghost rings are cases where the called of eliminating 'ghost rings'. Ghost rings are cases where the called
party hears the phone ring, picks up, but hears nothing and cannot be party hears the phone ring, picks up, but hears nothing and cannot be
heard. This technique works without requiring support for, or usage heard. This technique works without requiring support for, or usage
of, preconditions [6], since its a localized decision. It also has of, preconditions [6], since its a localized decision. It also has
the benefit of guaranteeing that not a single packet of media will the benefit of guaranteeing that not a single packet of media will
get clipped, so that post-pickup delay is zero. If an agent chooses get clipped, so that post-pickup delay is zero. If an agent chooses
to delay local alerting in this way, it SHOULD generate a 180 to delay local alerting in this way, it SHOULD generate a 180
response once alerting begins. response once alerting begins.
12.1.2. Offer in Response 12.1.2. Offer in Response
In addition to uses where the offer is in an INVITE, and the answer In addition to uses where the offer is in an INVITE, and the answer
is in the provisional and/or 200 OK response, ICE works with cases is in the provisional and/or 200 OK response, ICE works with cases
where the offer appears in the response. In such cases, which are where the offer appears in the response. In such cases, which are
common in third party call control [18], ICE agents SHOULD generate common in third party call control [19], ICE agents SHOULD generate
their offers in a reliable provisional response (which MUST utilize their offers in a reliable provisional response (which MUST utilize
RFC 3262), and not alert the user on receipt of the INVITE. The RFC 3262), and not alert the user on receipt of the INVITE. The
answer will arrive in a PRACK. This allows for ICE processing to answer will arrive in a PRACK. This allows for ICE processing to
take place prior to alerting, so that there is no post-pickup delay, take place prior to alerting, so that there is no post-pickup delay,
at the expense of increased call setup delays. Once ICE completes, at the expense of increased call setup delays. Once ICE completes,
the callee can alert the user and then generate a 200 OK when they the callee can alert the user and then generate a 200 OK when they
answer. The 200 OK would contain no SDP, since the offer/answer answer. The 200 OK would contain no SDP, since the offer/answer
exchange has completed. exchange has completed.
Alternatively, agents MAY place the offer in a 2xx instead (in which Alternatively, agents MAY place the offer in a 2xx instead (in which
case the answer comes in the ACK). When this happens, the callee case the answer comes in the ACK). When this happens, the callee
will alert the user on receipt of the INVITE, and the ICE exchanges will alert the user on receipt of the INVITE, and the ICE exchanges
will take place only after the user answers. This has the effect of will take place only after the user answers. This has the effect of
reducing call setup delay, but can cause substantial post-pickup reducing call setup delay, but can cause substantial post-pickup
delays and media clipping. delays and media clipping.
12.2. SIP Option Tags and Media Feature Tags 12.2. SIP Option Tags and Media Feature Tags
[14] specifies a SIP option tag and media feature tag for usage with [15] specifies a SIP option tag and media feature tag for usage with
ICE. ICE implementations using SIP SHOULD support this ICE. ICE implementations using SIP SHOULD support this
specification, which uses a feature tag in registrations to specification, which uses a feature tag in registrations to
facilitate interoperability through intermediaries. facilitate interoperability through intermediaries.
12.3. Interactions with Forking 12.3. Interactions with Forking
ICE interacts very well with forking. Indeed, ICE fixes some of the ICE interacts very well with forking. Indeed, ICE fixes some of the
problems associated with forking. Without ICE, when a call forks and problems associated with forking. Without ICE, when a call forks and
the caller receives multiple incoming media streams, it cannot the caller receives multiple incoming media streams, it cannot
determine which media stream corresponds to which callee. determine which media stream corresponds to which callee.
skipping to change at page 63, line 43 skipping to change at page 70, line 27
to match ICE's selection. As such, it appears like any other re- to match ICE's selection. As such, it appears like any other re-
INVITE would, and is fully treated in RFC 3312 and 4032, which apply INVITE would, and is fully treated in RFC 3312 and 4032, which apply
without regard to the fact that the destination for media is changing without regard to the fact that the destination for media is changing
due to ICE negotiations occurring "in the background". due to ICE negotiations occurring "in the background".
Indeed, an agent SHOULD NOT indicate that Qos preconditions have been Indeed, an agent SHOULD NOT indicate that Qos preconditions have been
met until the checks have completed and selected the candidate pairs met until the checks have completed and selected the candidate pairs
to be used for media. to be used for media.
ICE also has (purposeful) interactions with connectivity ICE also has (purposeful) interactions with connectivity
preconditions [30]. Those interactions are described there. Note preconditions [31]. Those interactions are described there. Note
that the procedures described in Section 12.1 describe their own type that the procedures described in Section 12.1 describe their own type
of "preconditions", albeit with less functionality than those of "preconditions", albeit with less functionality than those
provided by the explicit preconditions in [30]. provided by the explicit preconditions in [31].
12.5. Interactions with Third Party Call Control 12.5. Interactions with Third Party Call Control
ICE works with Flows I, III and IV as described in [18]. Flow I ICE works with Flows I, III and IV as described in [19]. Flow I
works without the controller supporting or being aware of ICE. Flow works without the controller supporting or being aware of ICE. Flow
IV will work as long as the controller passes along the ICE IV will work as long as the controller passes along the ICE
attributes without alteration. Flow II is fundamentally incompatible attributes without alteration. Flow II is fundamentally incompatible
with ICE; each agent will believe itself to be the answerer and thus with ICE; each agent will believe itself to be the answerer and thus
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
skipping to change at page 66, line 16 skipping to change at page 73, line 16
transport SP transport SP
priority SP priority SP
connection-address SP ;from RFC 4566 connection-address SP ;from RFC 4566
port ;port from RFC 4566 port ;port from RFC 4566
SP cand-type SP cand-type
[SP rel-addr] [SP rel-addr]
[SP rel-port] [SP rel-port]
*(SP extension-att-name SP *(SP extension-att-name SP
extension-att-value) extension-att-value)
foundation = 1*ice-char foundation = 1*32ice-char
component-id = 1*DIGIT component-id = 1*5DIGIT
transport = "UDP" / transport-extension transport = "UDP" / transport-extension
transport-extension = token ; from RFC 3261 transport-extension = token ; from RFC 3261
priority = 1*DIGIT priority = 1*10DIGIT
cand-type = "typ" SP candidate-types cand-type = "typ" SP candidate-types
candidate-types = "host" / "srflx" / "prflx" / "relay" / token candidate-types = "host" / "srflx" / "prflx" / "relay" / token
rel-addr = "raddr" SP connection-address rel-addr = "raddr" SP connection-address
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:
<connection-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 first using an AAAA
record, and the resulting IP address is used for the remainder of record (assuming the agent supports IPv6), and if no result is
ICE processing. found or the agent only supports IPv4, using an A. If the DNS
query returns more than one IP address, one is chosen, and then
used for the remainder of ICE processing.
<port>: is also taken from RFC 4566 [10]. It is the port of the <port>: is also taken from RFC 4566 [10]. It is the port of the
candidate. candidate.
<transport>: indicates the transport protocol for the candidate. <transport>: indicates the transport protocol for the candidate.
This specification only defines UDP. However, extensibility is This specification only defines UDP. However, extensibility is
provided to allow for future transport protocols to be used with provided to allow for future transport protocols to be used with
ICE, such as TCP or the Datagram Congestion Control Protocol ICE, such as TCP or the Datagram Congestion Control Protocol
(DCCP) [32]. (DCCP) [34].
<foundation>: is composed of one or more <ice-char>. It is an <foundation>: is composed of one to thirty two <ice-char>. It is an
identifier that is equivalent for two candidates that are of the identifier that is equivalent for two candidates that are of the
same type, share the same base, and come from the same STUN same type, share the same base, and come from the same STUN
server. The foundation is used to optimize ICE performance in the server. The foundation is used to optimize ICE performance in the
Frozen algorithm. Frozen algorithm.
<component-id>: is a positive integer between 1 and 256 which <component-id>: is a positive integer between 1 and 256 which
identifies the specific component of the media stream for which identifies the specific component of the media stream for which
this is a candidate. It MUST start at 1 and MUST increment by 1 this is a candidate. It MUST start at 1 and MUST increment by 1
for each component of a particular candidate. For media streams for each component of a particular candidate. For media streams
based on RTP, candidates for the actual RTP media MUST have a based on RTP, candidates for the actual RTP media MUST have a
skipping to change at page 68, line 37 skipping to change at page 75, line 38
offer arrived with a default destination for a media component that offer arrived with a default destination for a media component that
didn't have a corresponding candidate attribute. didn't have a corresponding candidate attribute.
15.4. "ice-ufrag" and "ice-pwd" Attributes 15.4. "ice-ufrag" and "ice-pwd" Attributes
The "ice-ufrag" and "ice-pwd" attributes convey the username fragment The "ice-ufrag" and "ice-pwd" attributes convey the username fragment
and password used by ICE for message integrity. Their syntax is: and password used by ICE for message integrity. Their syntax is:
ice-pwd-att = "ice-pwd" ":" password ice-pwd-att = "ice-pwd" ":" password
ice-ufrag-att = "ice-ufrag" ":" ufrag ice-ufrag-att = "ice-ufrag" ":" ufrag
password = 22*ice-char password = 22*1024ice-char
ufrag = 4*ice-char ufrag = 4*1024ice-char
The "ice-pwd" and "ice-ufrag" attributes can appear at either the The "ice-pwd" and "ice-ufrag" attributes can appear at either the
session-level or media-level. When present in both, the value in the session-level or media-level. When present in both, the value in the
media-level takes precedence. Thus, the value at the session level media-level takes precedence. Thus, the value at the session level
is effectively a default that applies to all media streams, unless is effectively a default that applies to all media streams, unless
overriden by a media-level value. Whether present at the session or overriden by a media-level value. Whether present at the session or
media level, there MUST be an ice-pwd and ice-ufrag attribute for media level, there MUST be an ice-pwd and ice-ufrag attribute for
each media stream. If two media streams have identical ice-ufrag's, each media stream. If two media streams have identical ice-ufrag's,
they MUST have identical ice-pwd's. they MUST have identical ice-pwd's.
The ice-ufrag and ice-pwd attributes MUST be chosen randomly at the The ice-ufrag and ice-pwd attributes MUST be chosen randomly at the
beginning of a session. The ice-ufrag attribute MUST contain at beginning of a session. The ice-ufrag attribute MUST contain at
least 24 bits of randomness, and the ice-pwd attribute MUST contain least 24 bits of randomness, and the ice-pwd attribute MUST contain
at least 128 bits of randomness. This means that the ice-ufrag at least 128 bits of randomness. This means that the ice-ufrag
attribute will be at least 4 characters long, and the ice-pwd at attribute will be at least 4 characters long, and the ice-pwd at
least 22 characters long, since the grammar for these attributes least 22 characters long, since the grammar for these attributes
allows for 6 bits of randomness per character. The attributes MAY be allows for 6 bits of randomness per character. The attributes MAY be
longer than 4 and 22 characters respectively, of course. longer than 4 and 22 characters respectively, of course, up to 1024
characters. The upper limit allows for buffer sizing in
implementations. Its large upper limit allows for increased amounts
of randomness to be added over time.
15.5. "ice-options> Attribute 15.5. "ice-options" Attribute
The "ice-options" attribute is a session level attribute. It The "ice-options" attribute is a session level attribute. It
contains a series of tokens which identify the options supported by contains a series of tokens which identify the options supported by
the agent. Its grammar is: the agent. Its grammar is:
ice-options = "ice-options" ":" ice-option-tag ice-options = "ice-options" ":" ice-option-tag
0*(SP ice-option-tag) 0*(SP ice-option-tag)
ice-option-tag = 1*ice-char ice-option-tag = 1*ice-char
16. Example 16. Example
The example is based on the simplified topology of Figure 15. The example is based on the simplified topology of Figure 19.
+-----+ +-----+
| | | |
|STUN | |STUN |
| Srvr| | Srvr|
+-----+ +-----+
| |
+---------------------+ +---------------------+
| | | |
| Internet | | Internet |
skipping to change at page 70, line 31 skipping to change at page 77, line 31
+---------+ | +---------+ |
| | | |
| | | |
| | | |
+-----+ +-----+ +-----+ +-----+
| | | | | | | |
| L | | R | | L | | R |
| | | | | | | |
+-----+ +-----+ +-----+ +-----+
Figure 15: Example Topology Figure 19: Example Topology
Two agents, L and R, are using ICE. Both are full-mode ICE Two agents, L and R, are using ICE. Both are full-mode ICE
implementations. Both agents have a single IPv4 interface. For implementations. Both agents have a single IPv4 interface. For
agent L, it is 10.0.1.1 in private address space [28], and for agent agent L, it is 10.0.1.1 in private address space [29], and for agent
R, 192.0.2.1 on the public Internet. Both are configured with the R, 192.0.2.1 on the public Internet. Both are configured with the
same STUN server (shown in this example for simplicity, although in same STUN server (shown in this example for simplicity, although in
practice the agents do not need to use the same STUN server), which practice the agents do not need to use the same STUN server), which
is listening for STUN requests at an IP address of 192.0.2.2 and port is listening for STUN requests at an IP address of 192.0.2.2 and port
3478. This STUN server supports only the Binding Discovery usage; 3478. This STUN server supports only the Binding Discovery usage;
relays are not used in this example. Agent L is behind a NAT, and relays are not used in this example. Agent L is behind a NAT, and
agent R is on the public Internet. The NAT has an endpoint agent R is on the public Internet. The NAT has an endpoint
independent mapping property and an address dependent filtering independent mapping property and an address dependent filtering
property. The public side of the NAT has an IP address of 192.0.2.3. property. The public side of the NAT has an IP address of 192.0.2.3.
skipping to change at page 73, line 8 skipping to change at page 80, line 8
|D=$R-PUB-1 | | | |D=$R-PUB-1 | | |
|MA=$R-PUB-1 | | | |MA=$R-PUB-1 | | |
|------------->| | | |------------->| | |
| |(17) Bind Res | | | |(17) Bind Res | |
| |S=$NAT-PUB-1 | | | |S=$NAT-PUB-1 | |
| |D=$R-PUB-1 | | | |D=$R-PUB-1 | |
| |MA=$R-PUB-1 | | | |MA=$R-PUB-1 | |
| |---------------------------->| | |---------------------------->|
| | | |RTP flows | | | |RTP flows
Figure 16: Example Flow Figure 20: Example Flow
First, agent L obtains a host candidate from its local interface (not First, agent L obtains a host candidate from its local interface (not
shown), and from that, sends a STUN Binding Request to the STUN shown), and from that, sends a STUN Binding Request to the STUN
server to get a server reflexive candidate (messages 1-4). Recall server to get a server reflexive candidate (messages 1-4). Recall
that the NAT has the address and port independent mapping property. that the NAT has the address and port independent mapping property.
Here, it creates a binding of NAT-PUB-1 for this UDP request, and Here, it creates a binding of NAT-PUB-1 for this UDP request, and
this becomes the server reflexive candidate for RTP. this becomes the server reflexive candidate for RTP.
Agent L sets a type preference of 126 for the host candidate and 100 Agent L sets a type preference of 126 for the host candidate and 100
for the server reflexive. The local preference is 65535. Based on for the server reflexive. The local preference is 65535. Based on
this, the priority of the host candidate is 2130706178 and for the this, the priority of the host candidate is 2130706431 and for the
server reflexive candidate is 1694498562. The host candidate is server reflexive candidate is 1694498815. The host candidate is
assigned a foundation of 1, and the server reflexive, a foundation of assigned a foundation of 1, and the server reflexive, a foundation of
2. It chooses its server reflexive candidate as the default 2. It chooses its server reflexive candidate as the default
candidate, and encodes it into the m and c lines. The resulting candidate, and encodes it into the m and c lines. The resulting
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=RS:0
b=RR: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 host a=candidate:1 1 UDP 2130706431 $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 1694498815 $NAT-PUB-1.IP $NAT-PUB-1.PORT typ
$L-PRIV-1.IP rport $L-PRIV-1.PORT srflx raddr $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=RS:0
b=RR: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 host a=candidate:1 1 UDP 2130706431 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 1694498815 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 2130706431. 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=RS:0
b=RR: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 host a=candidate:1 1 UDP 2130706431 $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=RS:0
b=RR: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 host a=candidate:1 1 UDP 2130706431 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
skipping to change at page 76, line 5 skipping to change at page 83, line 5
this check. Since the check succeeds, agent L creates a new pair, this check. Since the check succeeds, agent L creates a new pair,
whose local candidate is from the mapped address in the binding whose local candidate is from the mapped address in the binding
response (NAT-PUB-1 from message 13) and whose remote candidate is response (NAT-PUB-1 from message 13) and whose remote candidate is
the destination of the request (R-PUB-1 from message 10). This is the destination of the request (R-PUB-1 from message 10). This is
added to the valid list. In addition, it is marked as selected since added to the valid list. In addition, it is marked as selected since
the Binding Request contained the USE-CANDIDATE attribute. Since the Binding Request contained the USE-CANDIDATE attribute. Since
there is a selected candidate in the Valid list for the one component there is a selected candidate in the Valid list for the one component
of this media stream, ICE processing for this stream moves into the of this media stream, ICE processing for this stream moves into the
Completed state. Agent L can now send media if it so chooses. Completed state. Agent L can now send media if it so chooses.
Upon receipt of the STUN Binding Request from agent L (message 11), Soon after receipt of the STUN Binding Request from agent L (message
agent R will generate its triggered check. This check happens to 11), agent R will generate its triggered check. This check happens
match the next one on its check list - from its host candidate to to match the next one on its check list - from its host candidate to
agent L's server reflexive candidate. This check (messages 14-17) agent L's server reflexive candidate. This check (messages 14-17)
will succeed. Consequently, agent R constructs a new candidate pair will succeed. Consequently, agent R constructs a new candidate pair
using the mapped address from the response as the local candidate using the mapped address from the response as the local candidate
(R-PUB-1) and the destination of the request (NAT-PUB-1) as the (R-PUB-1) and the destination of the request (NAT-PUB-1) as the
remote candidate. This pair is added to the Valid list for that remote candidate. This pair is added to the Valid list for that
media stream. Since the check was generated in the reverse direction media stream. Since the check was generated in the reverse direction
of a check that contained the USE-CANDIDATE attribute, the candidate of a check that contained the USE-CANDIDATE attribute, the candidate
pair is marked as selected. Consequently, processing for this stream pair is marked as selected. Consequently, processing for this stream
moves into the Completed state, and agent R can also send media. moves into the Completed state, and agent R can also send media.
skipping to change at page 77, line 6 skipping to change at page 84, line 6
the attacker, for eavesdropping or other purposes. the attacker, for eavesdropping or other purposes.
False Valid on False Candidate: An attacker has already convinced an False Valid on False Candidate: An attacker has already convinced an
agent that there is a candidate with an address that doesn't agent that there is a candidate with an address that doesn't
actually route to that agent (for example, by injecting a false actually route to that agent (for example, by injecting a false
peer reflexive candidate or false server reflexive candidate). It peer reflexive candidate or false server reflexive candidate). It
must then launch an attack that forces the agents to believe that must then launch an attack that forces the agents to believe that
this candidate is valid. this candidate is valid.
Of the various techniques for creating faked STUN messages described Of the various techniques for creating faked STUN messages described
in [12], many are not applicable for the connectivity checks. in [13], many are not applicable for the connectivity checks.
Compromises of STUN servers are not much of a concern, since the STUN Compromises of STUN servers are not much of a concern, since the STUN
servers are embedded in endpoints and distributed throughout the servers are embedded in endpoints and distributed throughout the
network. Thus, compromising the peer's embedded STUN server is network. Thus, compromising the peer's embedded STUN server is
equivalent to comprimising the endpoint, and if that happens, far equivalent to comprimising the endpoint, and if that happens, far
more problematic attacks are possible than those against ICE. more problematic attacks are possible than those against ICE.
Similarly, DNS attacks are usually irrelevant since STUN servers are Similarly, DNS attacks are usually irrelevant since STUN servers are
not typically discovered via DNS, they are normally signaled via IP not typically discovered via DNS, they are normally signaled via IP
addresses embedded in SDP. If the SDP does contain an FQDN for a addresses embedded in SDP. If the SDP does contain an FQDN for a
host, then connectivity checks would be susceptible to the DNS host, then connectivity checks would be susceptible to the DNS
vulnerabilities described in [12]; however it is far more common to vulnerabilities described in [13]; however it is far more common to
use IP addresses. Injection of fake responses and relaying modified use IP addresses. Injection of fake responses and relaying modified
requests all can be handled in ICE with the countermeasures discussed requests all can be handled in ICE with the countermeasures discussed
below. below.
To force the false invalid result, the attacker has to wait for the To force the false invalid result, the attacker has to wait for the
connectivity check from one of the agents to be sent. When it is, connectivity check from one of the agents to be sent. When it is,
the attacker needs to inject a fake response with an unrecoverable the attacker needs to inject a fake response with an unrecoverable
error response, such as a 600. However, since the candidate is, in error response, such as a 600. However, since the candidate is, in
fact, valid, the original request may reach the peer agent, and fact, valid, the original request may reach the peer agent, and
result in a success response. The attacker needs to force this result in a success response. The attacker needs to force this
skipping to change at page 78, line 39 skipping to change at page 85, line 39
This attack is very hard to launch unless the attacker is identified This attack is very hard to launch unless the attacker is identified
by the fake candidate. This is because it requires the attacker to by the fake candidate. This is because it requires the attacker to
intercept and replay packets sent by two different hosts. If both intercept and replay packets sent by two different hosts. If both
agents are on different networks (for example, across the public agents are on different networks (for example, across the public
Internet), this attack can be hard to coordinate, since it needs to Internet), this attack can be hard to coordinate, since it needs to
occur against two different endpoints on different parts of the occur against two different endpoints on different parts of the
network at the same time. network at the same time.
If the attacker themself is identified by the fake candidate the If the attacker themself is identified by the fake candidate the
attack is easier to coordinate. However, if SRTP is used [23], the attack is easier to coordinate. However, if SRTP is used [24], the
attacker will not be able to play the media packets, they will only attacker will not be able to play the media packets, they will only
be able to discard them, effectively disabling the media stream for be able to discard them, effectively disabling the media stream for
the call. However, this attack requires the agent to disrupt packets the call. However, this attack requires the agent to disrupt packets
in order to block the connectivity check from reaching the target. in order to block the connectivity check from reaching the target.
In that case, if the goal is to disrupt the media stream, its much In that case, if the goal is to disrupt the media stream, its much
easier to just disrupt it with the same mechanism, rather than attack easier to just disrupt it with the same mechanism, rather than attack
ICE. ICE.
17.2. Attacks on Address Gathering 17.2. Attacks on Address Gathering
ICE endpoints make use of STUN for gathering candidates from a STUN ICE endpoints make use of STUN for gathering candidates from a STUN
server in the network. This is corresponds to the Binding Discovery server in the network. This is corresponds to the Binding Discovery
usage of STUN described in [12]. As a consequence, the attacks usage of STUN described in [13]. As a consequence, the attacks
against STUN itself that are described in that specification can against STUN itself that are described in that specification can
still be used against the binding discovery usage when utilized with still be used against the binding discovery usage when utilized with
ICE. ICE.
However, the additional mechanisms provided by ICE actually However, the additional mechanisms provided by ICE actually
counteract such attacks, making binding discovery with STUN more counteract such attacks, making binding discovery with STUN more
secure when combined with ICE than without ICE. secure when combined with ICE than without ICE.
Consider an attacker which is able to provide an agent with a faked Consider an attacker which is able to provide an agent with a faked
mapped address in a STUN Binding Request that is used for address mapped address in a STUN Binding Request that is used for address
gathering. This is the primary attack primitive described in [12]. gathering. This is the primary attack primitive described in [13].
This address will be used as a server reflexive candidate in the ICE This address will be used as a server reflexive candidate in the ICE
exchange. For this candidate to actually be used for media, the exchange. For this candidate to actually be used for media, the
attacker must also attack the connectivity checks, and in particular, attacker must also attack the connectivity checks, and in particular,
force a false valid on a false candidate. This attack is very hard force a false valid on a false candidate. This attack is very hard
to launch if the false address identifies a fourth party (neither the to launch if the false address identifies a fourth party (neither the
offerer, answerer, or attacker), since it requires attacking the offerer, answerer, or attacker), since it requires attacking the
checks generated by each agent in the session, and is prevented by checks generated by each agent in the session, and is prevented by
SRTP if it identifies the attacker themself. SRTP if it identifies the attacker themself.
If the attacker elects not to attack the connectivity checks, the If the attacker elects not to attack the connectivity checks, the
skipping to change at page 80, line 36 skipping to change at page 87, line 36
answers that don't indicate ICE support. answers that don't indicate ICE support.
17.4.2. STUN Amplification Attack 17.4.2. STUN Amplification Attack
The STUN amplification attack is similar to the voice hammer. The STUN amplification attack is similar to the voice hammer.
However, instead of voice packets being directed to the target, STUN However, instead of voice packets being directed to the target, STUN
connectivity checks are directed to the target. The attacker sends connectivity checks are directed to the target. The attacker sends
an offer with a large number of candidates, say 50. The answerer an offer with a large number of candidates, say 50. The answerer
receives the offer, and starts its checks, which are directed at the receives the offer, and starts its checks, which are directed at the
target, and consequently, never generate a response. The answerer target, and consequently, never generate a response. The answerer
will start a new connectivity check every 20ms, and each check is a will start a new connectivity check every Ta ms (say Ta=20ms).
STUN transaction consisting of 7 transmissions of a message 65 bytes However, the retransmission timers are set to a large number due to
in length (plus 28 bytes for the IP/UDP header) that runs for 7.9 the large number of candidates. As a consequence, packets will be
seconds, for a total of 58 bytes/second per transaction on average. sent at an interval of one every Ta milliseconds, and then with
In the worst case, there can be 395 transactions in progress at once increasing intervals after that. Thus, STUN will not send packets at
(7.9 seconds divided by 20ms), for a total of 182 kbps, just for STUN a rate faster than media would be sent, and the STUN packets persist
requests. only briefly, until ICE fails for the session. Nonetheless, this is
an amplification mechanism.
It is impossible to eliminate the amplification, but the volume can It is impossible to eliminate the amplification, but the volume can
be reduced through a variety of heuristics. Agents SHOULD limit the be reduced through a variety of heuristics. Agents SHOULD limit the
total number of connectivity checks they perform to 100. total number of connectivity checks they perform to 100.
Additionally, agents MAY limit the number of candidates they'll Additionally, agents MAY limit the number of candidates they'll
accept in an offer or answer. accept in an offer or answer.
17.5. Interactions with Application Layer Gateways and SIP 17.5. Interactions with Application Layer Gateways and SIP
Application Layer Gateways (ALGs) are functions present in a NAT Application Layer Gateways (ALGs) are functions present in a NAT
device which inspect the contents of packets and modify them, in device which inspect the contents of packets and modify them, in
order to facilitate NAT traversal for application protocols. Session order to facilitate NAT traversal for application protocols. Session
Border Controllers (SBC) are close cousins of ALGs, but are less Border Controllers (SBC) are close cousins of ALGs, but are less
transparent since they actually exist as application layer SIP transparent since they actually exist as application layer SIP
intermediaries. ICE has interactions with SBCs and ALGs. intermediaries. ICE has interactions with SBCs and ALGs.
If an ALG is SIP aware but not ICE aware, ICE will work through it as If an ALG is SIP aware but not ICE aware, ICE will work through it as
long as the ALG correctly modifies the SDP. In this case, correctly long as the ALG correctly modifies the SDP. A correct ALG
means that the ALG does not modify the m and c lines or the rtcp implementation behave as follows:
attribute if they contain external addresses. If they contain
internal addresses, the modification depends on the state of the ALG. o The ALG does not modify the m and c lines or the rtcp attribute if
If the ALG already has a binding established that maps an external they contain external addresses.
port to an internal IP address and port in m and c lines or rtcp
attribute , the ALG uses that binding instead of creating a new one. o If the m and c lines contain internal addresses, the modification
depends on the state of the ALG:
If the ALG already has a binding established that maps an
external port to an internal IP address and port matching the
values in the m and c lines or rtcp attribute , the ALG uses
that binding instead of creating a new one.
If the ALG does not already have a binding, it creates a new
one and modifies the SDP, rewriting the m and c lines and rtcp
attribute.
Unfortunately, many ALG are known to work poorly in these corner Unfortunately, many ALG are known to work poorly in these corner
cases. ICE does not try to work around broken ALGs, as this is cases. ICE does not try to work around broken ALGs, as this is
outside the scope of its functionality. ICE can help diagnose these outside the scope of its functionality. ICE can help diagnose these
conditions, which often show up as a mismatch between the set of conditions, which often show up as a mismatch between the set of
candidates and the m and c lines and rtcp attributes. The ice- candidates and the m and c lines and rtcp attributes. The ice-
mismatch attribute is used for this purpose. mismatch attribute is used for this purpose.
ICE works best through ALGs when the signaling is run over TLS. This ICE works best through ALGs when the signaling is run over TLS. This
prevents the ALG from manipulating the SDP messages and interfering prevents the ALG from manipulating the SDP messages and interfering
with ICE operation. Implementations which are expected to be with ICE operation. Implementations which are expected to be
skipping to change at page 81, line 50 skipping to change at page 89, line 12
through the SBC, if the SBC has requested it. If, however, the SBC through the SBC, if the SBC has requested it. If, however, the SBC
passes the ICE attributes without modification, yet modifies the passes the ICE attributes without modification, yet modifies the
default destination for media (contained in the m and c lines and default destination for media (contained in the m and c lines and
rtcp attribute), this will be detected as an ICE mismatch, and ICE rtcp attribute), this will be detected as an ICE mismatch, and ICE
processing is aborted for the call. It is outside of the scope of processing is aborted for the call. It is outside of the scope of
ICE for it to act as a tool for "working around" SBCs. If one is ICE for it to act as a tool for "working around" SBCs. If one is
present, ICE will not be used and the SBC techniques take precedence. present, ICE will not be used and the SBC techniques take precedence.
18. Definition of Connectivity Check Usage 18. Definition of Connectivity Check Usage
STUN [12] requires that new usages provide a specific set of STUN [13] requires that new usages provide a specific set of
information as part of their formal definition. This section meets information as part of their formal definition. This section meets
the requirements spelled out there. the requirements spelled out there.
18.1. Applicability 18.1. Applicability
This STUN usage provides a connectivity check between two peers This STUN usage provides a connectivity check between two peers
participating in an offer/answer exchange. This check serves to participating in an offer/answer exchange. This check serves to
validate a pair of candidates for usage of exchange of media. validate a pair of candidates for usage of exchange of media.
Connectivity checks also allow agents to discover reflexive Connectivity checks also allow agents to discover reflexive
candidates towards their peers, called peer reflexive candidates. candidates towards their peers, called peer reflexive candidates.
Finally, this usage allows a Binding Indication to be used to keep Finally, this usage allows a Binding Indication to be used to keep
NAT bindings alive. NAT bindings alive.
It is fundamental to this STUN usage that the addresses and ports It is fundamental to this STUN usage that the addresses and ports
used for media are the same ones used for the Binding Requests and used for media are the same ones used for the Binding Requests and
responses. Consequently, it will be necessary to demultiplex STUN responses. Consequently, it will be necessary to demultiplex STUN
traffic from applications on that same port (e.g., RTP or RTCP). traffic from applications on that same port (e.g., RTP or RTCP).
This demultiplexing is done using the techniques described in [12]. This demultiplexing is done using the techniques described in [13].
18.2. Client Discovery of Server 18.2. Client Discovery of Server
The client does not follow the DNS-based procedures defined in [12]. The client does not follow the DNS-based procedures defined in [13].
Rather, the remote candidate of the check to be performed is used as Rather, the remote candidate of the check to be performed is used as
the transport address of the STUN server. Note that the STUN server the transport address of the STUN server. Note that the STUN server
is a logical entity, and is not a physically distinct server in this is a logical entity, and is not a physically distinct server in this
usage. usage.
18.3. Server Determination of Usage 18.3. Server Determination of Usage
The server is aware of this usage because it signaled transport The server is aware of this usage because it signaled transport
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
skipping to change at page 87, line 21 skipping to change at page 94, line 31
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 four new STUN attributes per the procedures in This section registers four new STUN attributes per the procedures in
[12]. [13].
0x0024 PRIORITY 0x0024 PRIORITY
0x0025 USE-CANDIDATE 0x0025 USE-CANDIDATE
0x8029 ICE-CONTROLLED 0x8029 ICE-CONTROLLED
0x802a ICE-CONTROLLING 0x802a ICE-CONTROLLING
19.3. STUN Error Responses 19.3. STUN Error Responses
This section registers one new STUN error response code per the This section registers one new STUN error response code per the
procedures in [12]. procedures in [13].
487 Role Conflict 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 [22]. 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.
Indeed, ICE can be considered a B-SAF (Bilateral Self-Address Fixing) Indeed, ICE can be considered a B-SAF (Bilateral Self-Address Fixing)
protocol, rather than an UNSAF protocol. Regardless, the IAB has protocol, rather than an UNSAF protocol. Regardless, the IAB has
mandated that any protocols developed for this purpose document a mandated that any protocols developed for this purpose document a
specific set of considerations. This section meets those specific set of considerations. This section meets those
requirements. requirements.
20.1. Problem Definition 20.1. Problem Definition
skipping to change at page 89, line 15 skipping to change at page 96, line 25
20.3. Brittleness Introduced by ICE 20.3. Brittleness Introduced by ICE
From RFC3424, any UNSAF proposal must provide: From RFC3424, any UNSAF proposal must provide:
Discussion of specific issues that may render systems more Discussion of specific issues that may render systems more
"brittle". For example, approaches that involve using data at "brittle". For example, approaches that involve using data at
multiple network layers create more dependencies, increase multiple network layers create more dependencies, increase
debugging challenges, and make it harder to transition. debugging challenges, and make it harder to transition.
ICE actually removes brittleness from existing UNSAF mechanisms. In ICE actually removes brittleness from existing UNSAF mechanisms. In
particular, traditional STUN (as described in RFC 3489 [15]) has particular, traditional STUN (as described in RFC 3489 [16]) has
several points of brittleness. One of them is the discovery process several points of brittleness. One of them is the discovery process
which requires a agent to try and classify the type of NAT it is which requires a agent to try and classify the type of NAT it is
behind. This process is error-prone. With ICE, that discovery behind. This process is error-prone. With ICE, that discovery
process is simply not used. Rather than unilaterally assessing the process is simply not used. Rather than unilaterally assessing the
validity of the address, its validity is dynamically determined by validity of the address, its validity is dynamically determined by
measuring connectivity to a peer. The process of determining measuring connectivity to a peer. The process of determining
connectivity is very robust. connectivity is very robust.
Another point of brittleness in traditional STUN and any other Another point of brittleness in traditional STUN and any other
unilateral mechanism is its absolute reliance on an additional unilateral mechanism is its absolute reliance on an additional
skipping to change at page 89, line 49 skipping to change at page 97, line 12
shared NAT between each agent and the STUN server, traditional STUN shared NAT between each agent and the STUN server, traditional STUN
may not work. With ICE, that restriction is removed. may not work. With ICE, that restriction is removed.
Traditional STUN also introduces some security considerations. Traditional STUN also introduces some security considerations.
Fortunately, those security considerations are also mitigated by ICE. Fortunately, those security considerations are also mitigated by ICE.
Consequently, ICE serves to repair the brittleness introduced in Consequently, ICE serves to repair the brittleness introduced in
other UNSAF mechanisms, and does not introduce any additional other UNSAF mechanisms, and does not introduce any additional
brittleness into the system. brittleness into the system.
The penalty of these improvements is that ICE increases session
establishment times.
20.4. Requirements for a Long Term Solution 20.4. Requirements for a Long Term Solution
From RFC 3424, any UNSAF proposal must provide: From RFC 3424, any UNSAF proposal must provide:
Identify requirements for longer term, sound technical solutions Identify requirements for longer term, sound technical solutions
-- contribute to the process of finding the right longer term -- contribute to the process of finding the right longer term
solution. solution.
Our conclusions from STUN remain unchanged. However, we feel ICE Our conclusions from STUN remain unchanged. However, we feel ICE
actually helps because we believe it can be part of the long term actually helps because we believe it can be part of the long term
skipping to change at page 90, line 24 skipping to change at page 97, line 38
From RFC 3424, any UNSAF proposal must provide: From RFC 3424, any UNSAF proposal must provide:
Discussion of the impact of the noted practical issues with Discussion of the impact of the noted practical issues with
existing, deployed NA[P]Ts and experience reports. existing, deployed NA[P]Ts and experience reports.
A number of NAT boxes are now being deployed into the market which A number of NAT boxes are now being deployed into the market which
try and provide "generic" ALG functionality. These generic ALGs hunt try and provide "generic" ALG functionality. These generic ALGs hunt
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 [13] 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 [29], this minimum keepalive will become deterministic and behave [30], 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, Jonathan Lennox and Douglas Otis, Tim Moore, Jean-Francois Mule, Kevin Johns, Jonathan
Francois Audet for their comments and input. A special thanks goes Lennox and Francois Audet for their comments and input. A special
to Bill May, who suggested several of the concepts in this thanks goes to Bill May, who suggested several of the concepts in
specification, Philip Matthews, who suggested many of the key this specification, Philip Matthews, who suggested many of the key
performance optimizations in this specification, Eric Rescorla, who performance optimizations in this specification, Eric Rescorla, who
drafted the text in the introduction, and Magnus Westerlund, for drafted the text in the introduction, and Magnus Westerlund, for
doing several detailed reviews on the various revisions of this doing several detailed reviews on the various revisions of this
specification. 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
skipping to change at page 91, line 45 skipping to change at page 99, line 12
Responses in Session Initiation Protocol (SIP)", RFC 3262, Responses in Session Initiation Protocol (SIP)", RFC 3262,
June 2002. June 2002.
[10] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [10] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[11] Camarillo, G. and J. Rosenberg, "The Alternative Network [11] Camarillo, G. and J. Rosenberg, "The Alternative Network
Address Types (ANAT) Semantics for the Session Description Address Types (ANAT) Semantics for the Session Description
Protocol (SDP) Grouping Framework", RFC 4091, June 2005. Protocol (SDP) Grouping Framework", RFC 4091, June 2005.
[12] Rosenberg, J., "Simple Traversal Underneath Network Address [12] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003.
[13] Rosenberg, J., "Simple Traversal Underneath Network Address
Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-05 Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-05
(work in progress), October 2006. (work in progress), October 2006.
[13] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal [14] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal
Underneath NAT (STUN)", draft-ietf-behave-turn-02 (work in Underneath NAT (STUN)", draft-ietf-behave-turn-02 (work in
progress), October 2006. progress), October 2006.
[14] Rosenberg, J., "Indicating Support for Interactive Connectivity [15] Rosenberg, J., "Indicating Support for Interactive Connectivity
Establishment (ICE) in the Session Initiation Protocol (SIP)", Establishment (ICE) in the Session Initiation Protocol (SIP)",
draft-ietf-sip-ice-option-tag-00 (work in progress), draft-ietf-sip-ice-option-tag-00 (work in progress),
January 2007. January 2007.
22.2. Informative References 22.2. Informative References
[15] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN [16] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN
- Simple Traversal of User Datagram Protocol (UDP) Through - Simple Traversal of User Datagram Protocol (UDP) Through
Network Address Translators (NATs)", RFC 3489, March 2003. Network Address Translators (NATs)", RFC 3489, March 2003.
[16] Senie, D., "Network Address Translator (NAT)-Friendly [17] Senie, D., "Network Address Translator (NAT)-Friendly
Application Design Guidelines", RFC 3235, January 2002. Application Design Guidelines", RFC 3235, January 2002.
[17] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. [18] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A.
Rayhan, "Middlebox communication architecture and framework", Rayhan, "Middlebox communication architecture and framework",
RFC 3303, August 2002. RFC 3303, August 2002.
[18] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, [19] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo,
"Best Current Practices for Third Party Call Control (3pcc) in "Best Current Practices for Third Party Call Control (3pcc) in
the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, the Session Initiation Protocol (SIP)", BCP 85, RFC 3725,
April 2004. April 2004.
[19] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro, "Realm [20] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro, "Realm
Specific IP: Framework", RFC 3102, October 2001. Specific IP: Framework", RFC 3102, October 2001.
[20] Borella, M., Grabelsky, D., Lo, J., and K. Taniguchi, "Realm [21] Borella, M., Grabelsky, D., Lo, J., and K. Taniguchi, "Realm
Specific IP: Protocol Specification", RFC 3103, October 2001. Specific IP: Protocol Specification", RFC 3103, October 2001.
[21] Daigle, L. and IAB, "IAB Considerations for UNilateral Self- [22] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-
Address Fixing (UNSAF) Across Network Address Translation", Address Fixing (UNSAF) Across Network Address Translation",
RFC 3424, November 2002. RFC 3424, November 2002.
[22] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, [23] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", "RTP: A Transport Protocol for Real-Time Applications",
RFC 3550, July 2003. RFC 3550, July 2003.
[23] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [24] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[24] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via [25] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via
IPv4 Clouds", RFC 3056, February 2001. IPv4 Clouds", RFC 3056, February 2001.
[25] Zopf, R., "Real-time Transport Protocol (RTP) Payload for [26] Zopf, R., "Real-time Transport Protocol (RTP) Payload for
Comfort Noise (CN)", RFC 3389, September 2002. Comfort Noise (CN)", RFC 3389, September 2002.
[26] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone [27] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone
Generation in the Session Initiation Protocol (SIP)", RFC 3960, Generation in the Session Initiation Protocol (SIP)", RFC 3960,
December 2004. December 2004.
[27] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. [28] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W.
Weiss, "An Architecture for Differentiated Services", RFC 2475, Weiss, "An Architecture for Differentiated Services", RFC 2475,
December 1998. December 1998.
[28] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. [29] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E.
Lear, "Address Allocation for Private Internets", BCP 5, Lear, "Address Allocation for Private Internets", BCP 5,
RFC 1918, February 1996. RFC 1918, February 1996.
[29] Audet, F. and C. Jennings, "Network Address Translation (NAT) [30] Audet, F. and C. Jennings, "Network Address Translation (NAT)
Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787,
January 2007. January 2007.
[30] Andreasen, F., "Connectivity Preconditions for Session [31] Andreasen, F., "Connectivity Preconditions for Session
Description Protocol Media Streams", Description Protocol Media Streams",
draft-ietf-mmusic-connectivity-precon-02 (work in progress), draft-ietf-mmusic-connectivity-precon-02 (work in progress),
June 2006. June 2006.
[31] Andreasen, F., "A No-Op Payload Format for RTP", [32] 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 [33] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port",
draft-ietf-avt-rtp-and-rtcp-mux-03 (work in progress),
December 2006.
[34] 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 [35] Hellstrom, G. and P. Jones, "RTP Payload for Text
Conversation", RFC 4103, June 2005. Conversation", RFC 4103, June 2005.
[34] Jennings, C. and R. Mahy, "Managing Client Initiated [36] 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.
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.
skipping to change at page 94, line 17 skipping to change at page 101, line 39
entry point for these devices. Once they support the lite entry point for these devices. Once they support the lite
implementation, full implementations can connect to them and get the implementation, full implementations can connect to them and get the
full benefits of ICE. full benefits of ICE.
Consequently, a lite implementation is only appropriate for devices Consequently, a lite implementation is only appropriate for devices
that will *always* be connected to the public Internet and have a that will *always* be connected to the public Internet and have a
public IP address at which it can receive packets from any public IP address at which it can receive packets from any
correspondent. ICE will not function when a lite implementation is correspondent. ICE will not function when a lite implementation is
placed behind a NAT. placed behind a NAT.
ICE allows a lite implementation to have a single IPv4 host candidate
and several IPv6 addresses. In that case, candidate pairs are
selected by the controlling agent using a static algorithm, such as
the one in RFC 3484, which is recommended by this specification.
However, static mechanisms for address selection are always prone to
error, since they cannot ever reflect the actual topology and can
never provide actual guarantees on connectivity. They are always
heuristics. Consequently, if an agent is implementing ICE just to
select between its IPv4 and IPv6 addresses, and it is none of its
interfaces are behind NAT, usage of full ICE is still RECOMMENDED in
order to provide the most robust form of address selection possible.
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 with just a single IPv4 address, a full
A full implementation will reduce call setup times. Full implementation is preferable if achievable. A full implementation
implementations also obtain the security benefits of ICE unrelated to will reduce call setup times, since ICE's aggressive mode can be
NAT traversal; in particular, the voice hammer attack described in used. Full implementations also obtain the security benefits of ICE
Section 17 is prevented only for full implementations, not lite. unrelated to NAT traversal; in particular, the voice hammer attack
Finally, it is often the case that a device which finds itself with a described in Section 17 is prevented only for full implementations,
public address today will be placed in a network tomorrow where it not lite. Finally, it is often the case that a device which finds
will be behind a NAT. It is difficult to definitively know, over the itself with a public address today will be placed in a network
lifetime of a device or product, that it will always be used on the tomorrow where it will be behind a NAT. It is difficult to
public Internet. Full implementation provides assurance that definitively know, over the lifetime of a device or product, that it
communications will always work. will always be used on the public Internet. Full implementation
provides assurance that communications will always work.
Appendix B. Design Motivations Appendix B. Design Motivations
ICE contains a number of normative behaviors which may themselves be ICE contains a number of normative behaviors which may themselves be
simple, but derive from complicated or non-obvious thinking or use simple, but derive from complicated or non-obvious thinking or use
cases which merit further discussion. Since these design motivations cases which merit further discussion. Since these design motivations
are not neccesary to understand for purposes of implementation, they are not neccesary to understand for purposes of implementation, they
are discussed here in an appendix to the specification. This section are discussed here in an appendix to the specification. This section
is non-normative. is non-normative.
B.1. Pacing of STUN Transactions B.1. Pacing of STUN Transactions
STUN transactions used to gather candidates and to verify STUN transactions used to gather candidates and to verify
connectivity are paced out at an approximate rate of one new connectivity are paced out at an approximate rate of one new
transaction every Ta milliseconds, where Ta has a default of 20ms. transaction every Ta milliseconds. Each transaction, in turn, has a
Why are these transactions paced, and why was 20ms chosen as default? retransmission timer RTO that is a function of Ta as well. Why are
these transactions paced, and why are these formulas used?
Sending of these STUN requests will often have the effect of creating Sending of these STUN requests will often have the effect of creating
bindings on NAT devices between the client and the STUN servers. bindings on NAT devices between the client and the STUN servers.
Experience has shown that many NAT devices have upper limits on the Experience has shown that many NAT devices have upper limits on the
rate at which they will create new bindings. Furthermore, rate at which they will create new bindings. Experiments have shown
transmission of these packets on the network makes use of bandwidth that once every 20ms is well supported, but not much lower than that.
and needs to be rate limited by the agent. As a consequence, the This is why Ta has a lower bound of 20ms. Furthermore, transmission
pacing ensures that the NAT devices does not get overloaded and that of these packets on the network makes use of bandwidth and needs to
traffic is kept at a reasonable rate. be rate limited by the agent. As a consequence, the pacing ensures
that the NAT devices does not get overloaded and that traffic is kept
at a reasonable rate.
The definition of a "reasonable" rate is that STUN should not use
more bandwidth than the RTP itself will use, once media starts
flowing. The formula for Ta is designed so that, if a STUN packet
were sent every Ta seconds, it would consume the same amount of
bandwidth as RTP packets, summed across all media streams. Of
course, STUN has retransmits, and the desire is to pace those as
well. For this reason, RTO is set such that the first retransmit on
the first transaction happens just as the first STUN request on the
last transaction occurs. Pictorially:
First Packets Retransmits
| |
| |
-------+------ -------+------
/ \ / \
/ \ / \
+--+ +--+ +--+ +--+ +--+ +--+
|A1| |B1| |C1| |A2| |B2| |C2|
+--+ +--+ +--+ +--+ +--+ +--+
---+-------+-------+-------+-------+-------+------------ Time
0 Ta 2Ta 3Ta 4Ta 5Ta
In this picture, there are three transactions that will be sent (for
example, in the case of candidate gathering, there are three host
candidate/STUN server pairs). These are transactions A, B and C. The
retransmit timer is set so that the first retransmission on the first
transaction (packet A2) is sent at time 3Ta.
Subsequent retransmits after the first will occur even less
frequently than Ta milliseconds apart, since STUN uses an exponential
back-off on its retransmissions.
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.3 talks about eliminating candidates that have the same
identical but have different bases. When can an agent have two transport address and base. However, candidates with the same
candidates that have the same IP address and port, but different transport addresses but different bases are not redundant . When can
bases? Consider the topology of Figure 23: an agent have two candidates that have the same IP address and port,
but different bases? Consider the topology of Figure 28:
+----------+ +----------+
| STUN Srvr| | STUN Srvr|
+----------+ +----------+
| |
| |
----- -----
// \\ // \\
| | | |
| B:net10 | | B:net10 |
skipping to change at page 96, line 33 skipping to change at page 104, line 33
| |
----- -----
// \\ // \\
| A | | A |
|192.168/16 | |192.168/16 |
| | | |
\\ // \\ //
----- -----
| |
| |
|192.168.1.1 ----- |192.168.1.100 -----
+----------+ // \\ +----------+ +----------+ // \\ +----------+
| | | | | | | | | | | |
| Offerer |---------| C:net10 |---------| Answerer | | Offerer |---------| C:net10 |-----------| Answerer |
| |10.0.1.1 | | 10.0.1.2 | | | |10.0.1.100| | 10.0.1.101 | |
+----------+ \\ // +----------+ +----------+ \\ // +----------+
----- -----
Figure 23: Identical Candidates with Different Bases Figure 28: 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.100, 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.100 on this network. There is a NAT on this network,
into network B, which is another net 10 private network, but not natting into network B, which is another net 10 private network, but
connected to network C. There is a STUN server on network B. not 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
(10.0.1.1:2498) and a host candidate on its interface on network A (10.0.1.100:2498) and a host candidate on its interface on network A
(192.168.1.1:3344). It performs a STUN query to its configured STUN (192.168.1.100:3344). It performs a STUN query to its configured
server from 192.168.1.1:3344. This query passes through the NAT, STUN server from 192.168.1.100:3344. This query passes through the
which happens to assign the binding 10.0.1.1:2498. The STUN server NAT, which happens to assign the binding 10.0.1.100:2498. The STUN
reflects this in the STUN Binding Response. Now, the offerer has server reflects this in the STUN Binding Response. Now, the offerer
obtained a server reflexive candidate with a transport address that has obtained a server reflexive candidate with a transport address
is identical to a host candidate (10.0.1.1:2498). However, the that is identical to a host candidate (10.0.1.100:2498). However,
server reflexive candidate has a base of 192.168.1.1:3344, and the the server reflexive candidate has a base of 192.168.1.100:3344, and
host candidate has a base of 10.0.1.1:2498. the host candidate has a base of 10.0.1.100:2498.
B.3. Purpose of the <rel-addr> and <rel-port> Attributes B.3. Purpose of the <rel-addr> and <rel-port> Attributes
The candidate attribute contains two values that are not used at all The candidate attribute contains two values that are not used at all
by ICE itself - <rel-addr> and <rel-port>. Why is it present? by ICE itself - <rel-addr> and <rel-port>. Why is it present?
There are two motivations for its inclusion. The first is There are two motivations for its inclusion. The first is
diagnostic. It is very useful to know the relationship between the diagnostic. It is very useful to know the relationship between the
different types of candidates. By including it, an agent can know different types of candidates. By including it, an agent can know
which relayed candidate is associated with which reflexive candidate, which relayed candidate is associated with which reflexive candidate,
skipping to change at page 98, line 49 skipping to change at page 106, line 49
specific to ICE; stray packets can arrive at a port at any time for specific to ICE; stray packets can arrive at a port at any time for
any type of protocol, especially ones on the public Internet. As any type of protocol, especially ones on the public Internet. As
such, this requirement is just restating a general design guideline such, this requirement is just restating a general design guideline
for Internet applications - be prepared for unknown packets on any for Internet applications - be prepared for unknown packets on any
port. port.
B.5. The Candidate Pair Sequence Number Formula B.5. The Candidate Pair Sequence Number Formula
The sequence number for a candidate pair has an odd form. It is: The sequence number for a candidate pair has an odd form. It is:
pair priority = 2^32*MIN(O-P,A-P) + 2*MAX(O-P,A-P) + (O-P>A-P?1:0) pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)
Why is this? When the candidate pairs are sorted based on this Why is this? When the candidate pairs are sorted based on this
value, the resulting sorting has the MAX/MIN property. This means value, the resulting sorting has the MAX/MIN property. This means
that the pairs are first sorted based on decreasing value of the that the pairs are first sorted based on decreasing value of the
maximum of the two sequence numbers. For pairs that have the same maximum of the two sequence numbers. For pairs that have the same
value of the maximum sequence number, the minimum sequence number is value of the maximum sequence number, the minimum sequence number is
used to sort amongst them. If the max and the min sequence numbers used to sort amongst them. If the max and the min sequence numbers
are the same, the offerers priority is used as the tie breaker in the are the same, the offerers priority is used as the tie breaker in the
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 MAX/MIN sorting. MAX/MIN ensures that,
for a particular agent, a lower priority candidate is never used
until all higher priority candidates have been tried.
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 24. On receipt of message 4, agent race condition is shown in Figure 29. 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 9). 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, and offerer (the remote candidates) are included in the offer itself, and
the answerer delays its answer until those pairs validate. the answerer delays its answer until those pairs validate.
skipping to change at page 100, line 28 skipping to change at page 108, line 28
| |Lost | | |Lost |
|(7) Offer | | |(7) Offer | |
|------------------------------------------>| |------------------------------------------>|
|(8) STUN Req. | | |(8) STUN Req. | |
|<------------------------------------------| |<------------------------------------------|
|(9) STUN Res. | | |(9) STUN Res. | |
|------------------------------------------>| |------------------------------------------>|
|(10) Answer | | |(10) Answer | |
|<------------------------------------------| |<------------------------------------------|
Figure 24: Race Condition Flow Figure 29: 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
3264 directs implementations to cease transmission of media in these 3264 directs implementations to cease transmission of media in these
cases. However, doing so may cause NAT bindings to timeout, and cases. However, doing so may cause NAT bindings to timeout, and
media won't be able to come off hold. media won't be able to come off hold.
Secondly, some RTP payload formats, such as the payload format for Secondly, some RTP payload formats, such as the payload format for
text conversation [33], may send packets so infrequently that the text conversation [35], may send packets so infrequently that the
interval exceeds the NAT binding timeouts. interval exceeds the NAT binding timeouts.
Thirdly, if silence suppression is in use, long periods of silence Thirdly, if silence suppression is in use, long periods of silence
may cause media transmission to cease sufficiently long for NAT may cause media transmission to cease sufficiently long for NAT
bindings to time out. bindings to time out.
For these reasons, the media packets themselves cannot be relied For these reasons, the media packets themselves cannot be relied
upon. ICE defines a simple periodic keepalive that operates upon. ICE defines a simple periodic keepalive that operates
independently of media transmission. This makes its bandwidth independently of media transmission. This makes its bandwidth
requirements highly predictable, and thus amenable to QoS requirements highly predictable, and thus amenable to QoS
reservations. reservations.
B.8. Why Prefer Peer Reflexive Candidates? B.8. Why Prefer Peer Reflexive Candidates?
Section 4.1.2 describes procedures for computing the priority of Section 4.1.2 describes procedures for computing the priority of
candidate based on its type and local preferences. That section candidate based on its type and local preferences. That section
requires that the type preference for peer reflexive candidates requires that the type preference for peer reflexive candidates
always be lower than server reflexive. Why is that? The reason has always be higher than server reflexive. Why is that? The reason has
to do with the security considerations in Section 17. It is much to do with the security considerations in Section 17. It is much
easier for an attacker to cause an agent to use a false server easier for an attacker to cause an agent to use a false server
reflexive candidate than it is for an attacker to cause an agent to reflexive candidate than it is for an attacker to cause an agent to
use a false peer reflexive candidate. Consequently, attacks against use a false peer reflexive candidate. Consequently, attacks against
the STUN binding discovery usage are thwarted by ICE by preferring the STUN binding discovery usage are thwarted by ICE by preferring
the peer reflexive candidates. the peer reflexive candidates.
B.9. Why Send an Updated Offer? B.9. Why Send an Updated Offer?
Section 11.1 describes rules for sending media. Both agents can send Section 11.1 describes rules for sending media. Both agents can send
skipping to change at page 102, line 20 skipping to change at page 110, line 20
This will increase the actual bandwidth requirements for the 5-tuple This will increase the actual bandwidth requirements for the 5-tuple
carrying the media packets, and introduce jitter in the delivery of carrying the media packets, and introduce jitter in the delivery of
those packets. Analysis has shown that this is a concern in certain those packets. Analysis has shown that this is a concern in certain
layer 2 access networks that use fairly tight packet schedulers for layer 2 access networks that use fairly tight packet schedulers for
media. media.
Additionally, using a Binding Indication allows integrity to be Additionally, using a Binding Indication allows integrity to be
disabled, allowing for better performance. This is useful for large disabled, allowing for better performance. This is useful for large
scale endpoints, such as PSTN gateways and SBCs. scale endpoints, such as PSTN gateways and SBCs.
B.11. Why is the Conflict Resolution Mechanism Needed?
When ICE runs between two peers, one agent acts as controlled, and
the other as controlling. Rules are defined as a function of
implementation type and offerer/answerer to determine who is
controlling and who is controlled. However, the specification
mentions that, in some cases, both sides might believe they are
controlling, or both sides might believe they are controlled. How
can this happen?
The condition when both agents believe they are controlled shows up
in third party call control cases. Consider the following flow:
A Controller B
|(1) INV() | |
|<-------------| |
|(2) 200(SDP1) | |
|------------->| |
| |(3) INV() |
| |------------->|
| |(4) 200(SDP2) |
| |<-------------|
|(5) ACK(SDP2) | |
|<-------------| |
| |(6) ACK(SDP1) |
| |------------->|
Figure 30: Role Conflict Flow
This flow is a variation on flow III of RFC 3725 [19]. In fact, it
works better than flow III since it produces fewer messages. In this
flow, the controller sends an offerless INVITE to agent A, which
responds with its offer, SDP1. The agent then sends an offerless
INVITE to agent B, which it responds to with its offer, SDP2. The
controller then uses the offer from each agent to generate the
answers. When this flow is used, ICE will run between agents A and
B, but both will believe they are in the controlling role. With the
role conflict resolution procedures, this flow will function properly
when ICE is used.
At this time, there are no documented flows which can result in the
case where both agents believe they are controlled. However, the
conflict resolution procedures allow for this case, should a flow
arise which would fit into this category.
Author's Address Author's Address
Jonathan Rosenberg Jonathan Rosenberg
Cisco Cisco
Edison, NJ Edison, NJ
US US
Phone: +1 973 952-5000 Phone: +1 973 952-5000
Email: jdrosen@cisco.com Email: jdrosen@cisco.com
URI: http://www.jdrosen.net URI: http://www.jdrosen.net
 End of changes. 224 change blocks. 
700 lines changed or deleted 1138 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/