draft-ietf-mmusic-ice-18.txt   draft-ietf-mmusic-ice-19.txt 
MMUSIC J. Rosenberg MMUSIC J. Rosenberg
Internet-Draft Cisco Internet-Draft Cisco
Obsoletes: 4091 (if approved) September 13, 2007 Obsoletes: 4091 (if approved) October 29, 2007
Intended status: Standards Track Intended status: Standards Track
Expires: March 16, 2008 Expires: May 1, 2008
Interactive Connectivity Establishment (ICE): A Protocol 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-18 draft-ietf-mmusic-ice-19
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 March 16, 2008. This Internet-Draft will expire on May 1, 2008.
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 UDP-based multimedia sessions established with
answer model. This protocol is called Interactive Connectivity the offer/answer model. This protocol is called Interactive
Establishment (ICE). ICE makes use of the Session Traversal Connectivity Establishment (ICE). ICE makes use of the Session
Utilities for NAT (STUN) protocol and its extension, Traversal Using Traversal Utilities for NAT (STUN) protocol and its extension,
Relay NAT (TURN). ICE can be used by any protocol utilizing the Traversal Using Relay NAT (TURN). ICE can be used by any protocol
offer/answer model, such as the Session Initiation Protocol (SIP). utilizing the offer/answer model, such as the Session Initiation
Protocol (SIP).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
2. Overview of ICE . . . . . . . . . . . . . . . . . . . . . . . 8 2. Overview of ICE . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Gathering Candidate Addresses . . . . . . . . . . . . . . 10 2.1. Gathering Candidate Addresses . . . . . . . . . . . . . . 10
2.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 12 2.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 12
2.3. Sorting Candidates . . . . . . . . . . . . . . . . . . . 13 2.3. Sorting Candidates . . . . . . . . . . . . . . . . . . . 13
2.4. Frozen Candidates . . . . . . . . . . . . . . . . . . . . 14 2.4. Frozen Candidates . . . . . . . . . . . . . . . . . . . . 14
2.5. Security for Checks . . . . . . . . . . . . . . . . . . . 15 2.5. Security for Checks . . . . . . . . . . . . . . . . . . . 15
skipping to change at page 2, line 39 skipping to change at page 2, line 40
4.1.3. Eliminating Redundant Candidates . . . . . . . . . . 26 4.1.3. Eliminating Redundant Candidates . . . . . . . . . . 26
4.1.4. Choosing Default Candidates . . . . . . . . . . . . . 26 4.1.4. Choosing Default Candidates . . . . . . . . . . . . . 26
4.2. Lite Implementation . . . . . . . . . . . . . . . . . . . 26 4.2. Lite Implementation . . . . . . . . . . . . . . . . . . . 26
4.3. Encoding the SDP . . . . . . . . . . . . . . . . . . . . 27 4.3. Encoding the SDP . . . . . . . . . . . . . . . . . . . . 27
5. Receiving the Initial Offer . . . . . . . . . . . . . . . . . 29 5. Receiving the Initial Offer . . . . . . . . . . . . . . . . . 29
5.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 29 5.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 29
5.2. Determining Role . . . . . . . . . . . . . . . . . . . . 30 5.2. Determining Role . . . . . . . . . . . . . . . . . . . . 30
5.3. Gathering Candidates . . . . . . . . . . . . . . . . . . 31 5.3. Gathering Candidates . . . . . . . . . . . . . . . . . . 31
5.4. Prioritizing Candidates . . . . . . . . . . . . . . . . . 31 5.4. Prioritizing Candidates . . . . . . . . . . . . . . . . . 31
5.5. Choosing Default Candidates . . . . . . . . . . . . . . . 31 5.5. Choosing Default Candidates . . . . . . . . . . . . . . . 31
5.6. Encoding the SDP . . . . . . . . . . . . . . . . . . . . 31 5.6. Encoding the SDP . . . . . . . . . . . . . . . . . . . . 32
5.7. Forming the Check Lists . . . . . . . . . . . . . . . . . 32 5.7. Forming the Check Lists . . . . . . . . . . . . . . . . . 32
5.7.1. Forming Candidate Pairs . . . . . . . . . . . . . . . 32 5.7.1. Forming Candidate Pairs . . . . . . . . . . . . . . . 32
5.7.2. Computing Pair Priority and Ordering Pairs . . . . . 34 5.7.2. Computing Pair Priority and Ordering Pairs . . . . . 35
5.7.3. Pruning the Pairs . . . . . . . . . . . . . . . . . . 34 5.7.3. Pruning the Pairs . . . . . . . . . . . . . . . . . . 35
5.7.4. Computing States . . . . . . . . . . . . . . . . . . 34 5.7.4. Computing States . . . . . . . . . . . . . . . . . . 35
5.8. Scheduling Checks . . . . . . . . . . . . . . . . . . . . 37 5.8. Scheduling Checks . . . . . . . . . . . . . . . . . . . . 38
6. Receipt of the Initial Answer . . . . . . . . . . . . . . . . 39 6. Receipt of the Initial Answer . . . . . . . . . . . . . . . . 40
6.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 39 6.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 40
6.2. Determining Role . . . . . . . . . . . . . . . . . . . . 39 6.2. Determining Role . . . . . . . . . . . . . . . . . . . . 40
6.3. Forming the Check List . . . . . . . . . . . . . . . . . 40 6.3. Forming the Check List . . . . . . . . . . . . . . . . . 41
6.4. Performing Ordinary Checks . . . . . . . . . . . . . . . 40 6.4. Performing Ordinary Checks . . . . . . . . . . . . . . . 41
7. Performing Connectivity Checks . . . . . . . . . . . . . . . 40 7. Performing Connectivity Checks . . . . . . . . . . . . . . . 41
7.1. STUN Client Procedures . . . . . . . . . . . . . . . . . 40 7.1. STUN Client Procedures . . . . . . . . . . . . . . . . . 41
7.1.1. Sending the Request . . . . . . . . . . . . . . . . . 40 7.1.1. Sending the Request . . . . . . . . . . . . . . . . . 41
7.1.1.1. PRIORITY and USE-CANDIDATE . . . . . . . . . . . 41 7.1.1.1. PRIORITY and USE-CANDIDATE . . . . . . . . . . . 42
7.1.1.2. ICE-CONTROLLED and ICE-CONTROLLING . . . . . . . 41 7.1.1.2. ICE-CONTROLLED and ICE-CONTROLLING . . . . . . . 42
7.1.1.3. Forming Credentials . . . . . . . . . . . . . . . 41 7.1.1.3. Forming Credentials . . . . . . . . . . . . . . . 42
7.1.1.4. DiffServ Treatment . . . . . . . . . . . . . . . 41 7.1.1.4. DiffServ Treatment . . . . . . . . . . . . . . . 42
7.1.2. Processing the Response . . . . . . . . . . . . . . . 42 7.1.2. Processing the Response . . . . . . . . . . . . . . . 43
7.1.2.1. Failure Cases . . . . . . . . . . . . . . . . . . 42 7.1.2.1. Failure Cases . . . . . . . . . . . . . . . . . . 43
7.1.2.2. Success Cases . . . . . . . . . . . . . . . . . . 42 7.1.2.2. Success Cases . . . . . . . . . . . . . . . . . . 43
7.1.2.2.1. Discovering Peer Reflexive Candidates . . . . 43 7.1.2.2.1. Discovering Peer Reflexive Candidates . . . . 44
7.1.2.2.2. Constructing a Valid Pair . . . . . . . . . . 43 7.1.2.2.2. Constructing a Valid Pair . . . . . . . . . . 44
7.1.2.2.3. Updating Pair States . . . . . . . . . . . . 44 7.1.2.2.3. Updating Pair States . . . . . . . . . . . . 45
7.1.2.2.4. Updating the Nominated Flag . . . . . . . . . 45 7.1.2.2.4. Updating the Nominated Flag . . . . . . . . . 46
7.1.2.3. Check List and Timer State Updates . . . . . . . 45 7.1.2.3. Check List and Timer State Updates . . . . . . . 46
7.2. STUN Server Procedures . . . . . . . . . . . . . . . . . 46 7.2. STUN Server Procedures . . . . . . . . . . . . . . . . . 47
7.2.1. Additional Procedures for Full Implementations . . . 47 7.2.1. Additional Procedures for Full Implementations . . . 48
7.2.1.1. Detecting and Repairing Role Conflicts . . . . . 47 7.2.1.1. Detecting and Repairing Role Conflicts . . . . . 48
7.2.1.2. Computing Mapped Address . . . . . . . . . . . . 48 7.2.1.2. Computing Mapped Address . . . . . . . . . . . . 49
7.2.1.3. Learning Peer Reflexive Candidates . . . . . . . 48 7.2.1.3. Learning Peer Reflexive Candidates . . . . . . . 49
7.2.1.4. Triggered Checks . . . . . . . . . . . . . . . . 49 7.2.1.4. Triggered Checks . . . . . . . . . . . . . . . . 50
7.2.1.5. Updating the Nominated Flag . . . . . . . . . . . 50 7.2.1.5. Updating the Nominated Flag . . . . . . . . . . . 51
7.2.2. Additional Procedures for Lite Implementations . . . 50 7.2.2. Additional Procedures for Lite Implementations . . . 51
8. Concluding ICE Processing . . . . . . . . . . . . . . . . . . 50 8. Concluding ICE Processing . . . . . . . . . . . . . . . . . . 51
8.1. Procedures for Full Implementations . . . . . . . . . . . 51 8.1. Procedures for Full Implementations . . . . . . . . . . . 52
8.1.1. Nominating Pairs . . . . . . . . . . . . . . . . . . 51 8.1.1. Nominating Pairs . . . . . . . . . . . . . . . . . . 52
8.1.1.1. Regular Nomination . . . . . . . . . . . . . . . 51 8.1.1.1. Regular Nomination . . . . . . . . . . . . . . . 52
8.1.1.2. Aggressive Nomination . . . . . . . . . . . . . . 52 8.1.1.2. Aggressive Nomination . . . . . . . . . . . . . . 53
8.1.2. Updating States . . . . . . . . . . . . . . . . . . . 52 8.1.2. Updating States . . . . . . . . . . . . . . . . . . . 53
8.2. Procedures for Lite Implementations . . . . . . . . . . . 53 8.2. Procedures for Lite Implementations . . . . . . . . . . . 54
8.2.1. Peer is Full . . . . . . . . . . . . . . . . . . . . 54 8.2.1. Peer is Full . . . . . . . . . . . . . . . . . . . . 55
8.2.2. Peer is Lite . . . . . . . . . . . . . . . . . . . . 54 8.2.2. Peer is Lite . . . . . . . . . . . . . . . . . . . . 55
8.3. Freeing Candidates . . . . . . . . . . . . . . . . . . . 55 8.3. Freeing Candidates . . . . . . . . . . . . . . . . . . . 56
8.3.1. Full Implementation Procedures . . . . . . . . . . . 55 8.3.1. Full Implementation Procedures . . . . . . . . . . . 56
8.3.2. Lite Implementations . . . . . . . . . . . . . . . . 55 8.3.2. Lite Implementations . . . . . . . . . . . . . . . . 56
9. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . . . 55 9. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . . . 56
9.1. Generating the Offer . . . . . . . . . . . . . . . . . . 56 9.1. Generating the Offer . . . . . . . . . . . . . . . . . . 57
9.1.1. Procedures for All Implementations . . . . . . . . . 56 9.1.1. Procedures for All Implementations . . . . . . . . . 57
9.1.1.1. ICE Restarts . . . . . . . . . . . . . . . . . . 56 9.1.1.1. ICE Restarts . . . . . . . . . . . . . . . . . . 57
9.1.1.2. Removing a Media Stream . . . . . . . . . . . . . 57 9.1.1.2. Removing a Media Stream . . . . . . . . . . . . . 58
9.1.1.3. Adding a Media Stream . . . . . . . . . . . . . . 57 9.1.1.3. Adding a Media Stream . . . . . . . . . . . . . . 58
9.1.2. Procedures for Full Implementations . . . . . . . . . 57 9.1.2. Procedures for Full Implementations . . . . . . . . . 58
9.1.2.1. Existing Media Streams with ICE Running . . . . . 57 9.1.2.1. Existing Media Streams with ICE Running . . . . . 58
9.1.2.2. Existing Media Streams with ICE Completed . . . . 58 9.1.2.2. Existing Media Streams with ICE Completed . . . . 59
9.1.3. Procedures for Lite Implementations . . . . . . . . . 58 9.1.3. Procedures for Lite Implementations . . . . . . . . . 59
9.1.3.1. Existing Media Streams with ICE Running . . . . . 58 9.1.3.1. Existing Media Streams with ICE Running . . . . . 59
9.1.3.2. Existing Media Streams with ICE Completed . . . . 59 9.1.3.2. Existing Media Streams with ICE Completed . . . . 60
9.2. Receiving the Offer and Generating an Answer . . . . . . 59 9.2. Receiving the Offer and Generating an Answer . . . . . . 60
9.2.1. Procedures for All Implementations . . . . . . . . . 59 9.2.1. Procedures for All Implementations . . . . . . . . . 60
9.2.1.1. Detecting ICE Restart . . . . . . . . . . . . . . 59 9.2.1.1. Detecting ICE Restart . . . . . . . . . . . . . . 60
9.2.1.2. New Media Stream . . . . . . . . . . . . . . . . 60 9.2.1.2. New Media Stream . . . . . . . . . . . . . . . . 61
9.2.1.3. Removed Media Stream . . . . . . . . . . . . . . 60 9.2.1.3. Removed Media Stream . . . . . . . . . . . . . . 61
9.2.2. Procedures for Full Implementations . . . . . . . . . 60 9.2.2. Procedures for Full Implementations . . . . . . . . . 61
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 . . . . . . . . . . . . . . . . 60 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 . . . . . . . . . . . . . . 60 no remote-candidates . . . . . . . . . . . . . . 61
9.2.2.3. Existing Media Streams and remote-candidates . . 60 9.2.2.3. Existing Media Streams and remote-candidates . . 61
9.2.3. Procedures for Lite Implementations . . . . . . . . . 61 9.2.3. Procedures for Lite Implementations . . . . . . . . . 62
9.3. Updating the Check and Valid Lists . . . . . . . . . . . 62 9.3. Updating the Check and Valid Lists . . . . . . . . . . . 63
9.3.1. Procedures for Full Implementations . . . . . . . . . 62 9.3.1. Procedures for Full Implementations . . . . . . . . . 63
9.3.1.1. ICE Restarts . . . . . . . . . . . . . . . . . . 62 9.3.1.1. ICE Restarts . . . . . . . . . . . . . . . . . . 63
9.3.1.2. New Media Stream . . . . . . . . . . . . . . . . 62 9.3.1.2. New Media Stream . . . . . . . . . . . . . . . . 63
9.3.1.3. Removed Media Stream . . . . . . . . . . . . . . 63 9.3.1.3. Removed Media Stream . . . . . . . . . . . . . . 64
9.3.1.4. ICE Continuing for Existing Media Stream . . . . 63 9.3.1.4. ICE Continuing for Existing Media Stream . . . . 64
9.3.2. Procedures for Lite Implementations . . . . . . . . . 63 9.3.2. Procedures for Lite Implementations . . . . . . . . . 64
10. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 64 10. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 65
11. Media Handling . . . . . . . . . . . . . . . . . . . . . . . 65 11. Media Handling . . . . . . . . . . . . . . . . . . . . . . . 66
11.1. Sending Media . . . . . . . . . . . . . . . . . . . . . . 65 11.1. Sending Media . . . . . . . . . . . . . . . . . . . . . . 66
11.1.1. Procedures for Full Implementations . . . . . . . . . 65 11.1.1. Procedures for Full Implementations . . . . . . . . . 66
11.1.2. Procedures for Lite Implementations . . . . . . . . . 66 11.1.2. Procedures for Lite Implementations . . . . . . . . . 67
11.1.3. Procedures for All Implementations . . . . . . . . . 66 11.1.3. Procedures for All Implementations . . . . . . . . . 67
11.2. Receiving Media . . . . . . . . . . . . . . . . . . . . . 66 11.2. Receiving Media . . . . . . . . . . . . . . . . . . . . . 67
12. Usage with SIP . . . . . . . . . . . . . . . . . . . . . . . 67 12. Usage with SIP . . . . . . . . . . . . . . . . . . . . . . . 68
12.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . 67 12.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . 68
12.1.1. Offer in INVITE . . . . . . . . . . . . . . . . . . . 67 12.1.1. Offer in INVITE . . . . . . . . . . . . . . . . . . . 68
12.1.2. Offer in Response . . . . . . . . . . . . . . . . . . 68 12.1.2. Offer in Response . . . . . . . . . . . . . . . . . . 69
12.2. SIP Option Tags and Media Feature Tags . . . . . . . . . 69 12.2. SIP Option Tags and Media Feature Tags . . . . . . . . . 70
12.3. Interactions with Forking . . . . . . . . . . . . . . . . 69 12.3. Interactions with Forking . . . . . . . . . . . . . . . . 70
12.4. Interactions with Preconditions . . . . . . . . . . . . . 69 12.4. Interactions with Preconditions . . . . . . . . . . . . . 70
12.5. Interactions with Third Party Call Control . . . . . . . 70 12.5. Interactions with Third Party Call Control . . . . . . . 71
13. Relationship with ANAT . . . . . . . . . . . . . . . . . . . 70 13. Relationship with ANAT . . . . . . . . . . . . . . . . . . . 71
14. Extensibility Considerations . . . . . . . . . . . . . . . . 71 14. Extensibility Considerations . . . . . . . . . . . . . . . . 72
15. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 15. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
15.1. "candidate" Attribute . . . . . . . . . . . . . . . . . . 72 15.1. "candidate" Attribute . . . . . . . . . . . . . . . . . . 73
15.2. "remote-candidates" Attribute . . . . . . . . . . . . . . 74 15.2. "remote-candidates" Attribute . . . . . . . . . . . . . . 75
15.3. "ice-lite" and "ice-mismatch" Attributes . . . . . . . . 74 15.3. "ice-lite" and "ice-mismatch" Attributes . . . . . . . . 75
15.4. "ice-ufrag" and "ice-pwd" Attributes . . . . . . . . . . 75 15.4. "ice-ufrag" and "ice-pwd" Attributes . . . . . . . . . . 76
15.5. "ice-options" Attribute . . . . . . . . . . . . . . . . . 75 15.5. "ice-options" Attribute . . . . . . . . . . . . . . . . . 76
16. Setting Ta and RTO . . . . . . . . . . . . . . . . . . . . . 76 16. Setting Ta and RTO . . . . . . . . . . . . . . . . . . . . . 77
16.1. RTP Media Streams . . . . . . . . . . . . . . . . . . . . 76 16.1. RTP Media Streams . . . . . . . . . . . . . . . . . . . . 77
16.2. Non-RTP Sessions . . . . . . . . . . . . . . . . . . . . 77 16.2. Non-RTP Sessions . . . . . . . . . . . . . . . . . . . . 78
17. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 17. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
18. Security Considerations . . . . . . . . . . . . . . . . . . . 84 18. Security Considerations . . . . . . . . . . . . . . . . . . . 86
18.1. Attacks on Connectivity Checks . . . . . . . . . . . . . 84 18.1. Attacks on Connectivity Checks . . . . . . . . . . . . . 86
18.2. Attacks on Server Reflexive Address Gathering . . . . . . 87 18.2. Attacks on Server Reflexive Address Gathering . . . . . . 89
18.3. Attacks on Relayed Candidate Gathering . . . . . . . . . 87 18.3. Attacks on Relayed Candidate Gathering . . . . . . . . . 89
18.4. Attacks on the Offer/Answer Exchanges . . . . . . . . . . 88 18.4. Attacks on the Offer/Answer Exchanges . . . . . . . . . . 90
18.5. Insider Attacks . . . . . . . . . . . . . . . . . . . . . 88 18.5. Insider Attacks . . . . . . . . . . . . . . . . . . . . . 90
18.5.1. The Voice Hammer Attack . . . . . . . . . . . . . . . 88 18.5.1. The Voice Hammer Attack . . . . . . . . . . . . . . . 90
18.5.2. STUN Amplification Attack . . . . . . . . . . . . . . 89 18.5.2. STUN Amplification Attack . . . . . . . . . . . . . . 91
18.6. Interactions with Application Layer Gateways and SIP . . 90 18.6. Interactions with Application Layer Gateways and SIP . . 92
19. STUN Extensions . . . . . . . . . . . . . . . . . . . . . . . 91 19. STUN Extensions . . . . . . . . . . . . . . . . . . . . . . . 93
19.1. New Attributes . . . . . . . . . . . . . . . . . . . . . 91 19.1. New Attributes . . . . . . . . . . . . . . . . . . . . . 93
19.2. New Error Response Codes . . . . . . . . . . . . . . . . 91 19.2. New Error Response Codes . . . . . . . . . . . . . . . . 93
20. Operational Considerations . . . . . . . . . . . . . . . . . 92 20. Operational Considerations . . . . . . . . . . . . . . . . . 94
20.1. NAT and Firewall Types . . . . . . . . . . . . . . . . . 92 20.1. NAT and Firewall Types . . . . . . . . . . . . . . . . . 94
20.2. Bandwidth Requirements . . . . . . . . . . . . . . . . . 92 20.2. Bandwidth Requirements . . . . . . . . . . . . . . . . . 94
20.2.1. STUN and TURN Server Capacity Planning . . . . . . . 92 20.2.1. STUN and TURN Server Capacity Planning . . . . . . . 94
20.2.2. Gathering and Connectivity Checks . . . . . . . . . . 93 20.2.2. Gathering and Connectivity Checks . . . . . . . . . . 95
20.2.3. Keepalives . . . . . . . . . . . . . . . . . . . . . 93 20.2.3. Keepalives . . . . . . . . . . . . . . . . . . . . . 95
20.3. ICE and ICE-lite . . . . . . . . . . . . . . . . . . . . 93 20.3. ICE and ICE-lite . . . . . . . . . . . . . . . . . . . . 95
20.4. Troubleshooting and Performance Management . . . . . . . 94 20.4. Troubleshooting and Performance Management . . . . . . . 96
20.5. Endpoint Configuration . . . . . . . . . . . . . . . . . 94 20.5. Endpoint Configuration . . . . . . . . . . . . . . . . . 96
21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 94 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 96
21.1. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 94 21.1. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 96
21.1.1. candidate Attribute . . . . . . . . . . . . . . . . . 95 21.1.1. candidate Attribute . . . . . . . . . . . . . . . . . 97
21.1.2. remote-candidates Attribute . . . . . . . . . . . . . 95 21.1.2. remote-candidates Attribute . . . . . . . . . . . . . 97
21.1.3. ice-lite Attribute . . . . . . . . . . . . . . . . . 95 21.1.3. ice-lite Attribute . . . . . . . . . . . . . . . . . 97
21.1.4. ice-mismatch Attribute . . . . . . . . . . . . . . . 96 21.1.4. ice-mismatch Attribute . . . . . . . . . . . . . . . 98
21.1.5. ice-pwd Attribute . . . . . . . . . . . . . . . . . . 96 21.1.5. ice-pwd Attribute . . . . . . . . . . . . . . . . . . 98
21.1.6. ice-ufrag Attribute . . . . . . . . . . . . . . . . . 97 21.1.6. ice-ufrag Attribute . . . . . . . . . . . . . . . . . 99
21.1.7. ice-options Attribute . . . . . . . . . . . . . . . . 97 21.1.7. ice-options Attribute . . . . . . . . . . . . . . . . 99
21.2. STUN Attributes . . . . . . . . . . . . . . . . . . . . . 98 21.2. STUN Attributes . . . . . . . . . . . . . . . . . . . . . 100
21.3. STUN Error Responses . . . . . . . . . . . . . . . . . . 98 21.3. STUN Error Responses . . . . . . . . . . . . . . . . . . 100
22. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 98 22. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 100
22.1. Problem Definition . . . . . . . . . . . . . . . . . . . 98 22.1. Problem Definition . . . . . . . . . . . . . . . . . . . 100
22.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 99 22.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 101
22.3. Brittleness Introduced by ICE . . . . . . . . . . . . . . 99 22.3. Brittleness Introduced by ICE . . . . . . . . . . . . . . 101
22.4. Requirements for a Long Term Solution . . . . . . . . . . 100 22.4. Requirements for a Long Term Solution . . . . . . . . . . 102
22.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 101 22.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 103
23. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 101 23. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 103
24. References . . . . . . . . . . . . . . . . . . . . . . . . . 102 24. References . . . . . . . . . . . . . . . . . . . . . . . . . 104
24.1. Normative References . . . . . . . . . . . . . . . . . . 102 24.1. Normative References . . . . . . . . . . . . . . . . . . 104
24.2. Informative References . . . . . . . . . . . . . . . . . 103 24.2. Informative References . . . . . . . . . . . . . . . . . 105
Appendix A. Lite and Full Implementations . . . . . . . . . . . 105 Appendix A. Lite and Full Implementations . . . . . . . . . . . 107
Appendix B. Design Motivations . . . . . . . . . . . . . . . . . 106 Appendix B. Design Motivations . . . . . . . . . . . . . . . . . 108
B.1. Pacing of STUN Transactions . . . . . . . . . . . . . . . 106 B.1. Pacing of STUN Transactions . . . . . . . . . . . . . . . 108
B.2. Candidates with Multiple Bases . . . . . . . . . . . . . 108 B.2. Candidates with Multiple Bases . . . . . . . . . . . . . 110
B.3. Purpose of the <rel-addr> and <rel-port> Attributes . . . 109 B.3. Purpose of the <rel-addr> and <rel-port> Attributes . . . 112
B.4. Importance of the STUN Username . . . . . . . . . . . . . 110 B.4. Importance of the STUN Username . . . . . . . . . . . . . 112
B.5. The Candidate Pair Priority Formula . . . . . . . . . . . 111 B.5. The Candidate Pair Priority Formula . . . . . . . . . . . 113
B.6. The remote-candidates attribute . . . . . . . . . . . . . 111 B.6. The remote-candidates attribute . . . . . . . . . . . . . 114
B.7. Why are Keepalives Needed? . . . . . . . . . . . . . . . 112 B.7. Why are Keepalives Needed? . . . . . . . . . . . . . . . 115
B.8. Why Prefer Peer Reflexive Candidates? . . . . . . . . . . 113 B.8. Why Prefer Peer Reflexive Candidates? . . . . . . . . . . 116
B.9. Why Send an Updated Offer? . . . . . . . . . . . . . . . 113 B.9. Why Send an Updated Offer? . . . . . . . . . . . . . . . 116
B.10. Why are Binding Indications Used for Keepalives? . . . . 113 B.10. Why are Binding Indications Used for Keepalives? . . . . 116
B.11. Why is the Conflict Resolution Mechanism Needed? . . . . 114 B.11. Why is the Conflict Resolution Mechanism Needed? . . . . 117
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 115 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 118
Intellectual Property and Copyright Statements . . . . . . . . . 116 Intellectual Property and Copyright Statements . . . . . . . . . 119
1. Introduction 1. Introduction
RFC 3264 [RFC3264] defines a two-phase exchange of Session RFC 3264 [RFC3264] defines a two-phase exchange of Session
Description Protocol (SDP) messages [RFC4566] for the purposes of Description Protocol (SDP) messages [RFC4566] for the purposes of
establishment of multimedia sessions. This offer/answer mechanism is establishment of multimedia sessions. This offer/answer mechanism is
used by protocols such as the Session Initiation Protocol (SIP) used by protocols such as the Session Initiation Protocol (SIP)
[RFC3261]. [RFC3261].
Protocols using offer/answer are difficult to operate through Network Protocols using offer/answer are difficult to operate through Network
skipping to change at page 7, line 42 skipping to change at page 7, line 42
(RTCP) [RFC3605]. Unfortunately, these techniques all have pros and (RTCP) [RFC3605]. Unfortunately, these techniques all have pros and
cons which make each one optimal in some network topologies, but a cons which make each one optimal in some network topologies, but a
poor choice in others. The result is that administrators and poor choice in others. The result is that administrators and
implementors are making assumptions about the topologies of the implementors are making assumptions about the topologies of the
networks in which their solutions will be deployed. This introduces networks in which their solutions will be deployed. This introduces
complexity and brittleness into the system. What is needed is a complexity and brittleness into the system. What is needed is a
single solution which is flexible enough to work well in all single solution which is flexible enough to work well in all
situations. 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 UDP-based media streams
by the offer/answer model. ICE is an extension to the offer/answer (though ICE can be extended to handle other transport protocols, such
model, and works by including a multiplicity of IP addresses and as TCP [I-D.ietf-mmusic-ice-tcp]) established by the offer/answer
ports in SDP offers and answers, which are then tested for model. ICE is an extension to the offer/answer model, and works by
connectivity by peer-to-peer connectivity checks. The IP addresses including a multiplicity of IP addresses and ports in SDP offers and
and ports included in the SDP and the connectivity checks are answers, which are then tested for connectivity by peer-to-peer
performed using the revised STUN specification connectivity checks. The IP addresses and ports included in the SDP
[I-D.ietf-behave-rfc3489bis], now renamed to Session Traversal and the connectivity checks are performed using the revised STUN
Utilities for NAT. The new name and new specification reflect its specification [I-D.ietf-behave-rfc3489bis], now renamed to Session
new role as a tool that is used with other NAT traversal techniques Traversal Utilities for NAT. The new name and new specification
(namely ICE) rather than a standalone NAT traversal solution, as the reflect its new role as a tool that is used with other NAT traversal
original STUN specification was. ICE also makes use of Traversal techniques (namely ICE) rather than a standalone NAT traversal
Using Relay NAT (TURN) [I-D.ietf-behave-turn], an extension to STUN. solution, as the original STUN specification was. ICE also makes use
Because ICE exchanges a multiplicity of IP addresses and ports for of Traversal Using Relay NAT (TURN) [I-D.ietf-behave-turn], an
each media stream, it also allows for address selection for multi- extension to STUN. Because ICE exchanges a multiplicity of IP
homed and dual-stack hosts, and for this reason it deprecates RFC addresses and ports for each media stream, it also allows for address
4091 [RFC4091]. selection for multi-homed and dual-stack hosts, and for this reason
it deprecates RFC 4091 [RFC4091].
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 [RFC3264] which they can perform an offer/answer exchange of SDP [RFC3264]
messages. Note that ICE is not intended for NAT traversal for SIP, messages. Note that ICE is not intended for NAT traversal for SIP,
which is assumed to be provided via another mechanism which is assumed to be provided via another mechanism
[I-D.ietf-sip-outbound]. At the beginning of the ICE process, the [I-D.ietf-sip-outbound]. At the beginning of the ICE process, the
skipping to change at page 23, line 45 skipping to change at page 23, line 45
Binding request, the bindings MUST be kept alive by additional Binding request, the bindings MUST be kept alive by additional
Binding Requests to the server. For relayed candidates learned Binding Requests to the server. For relayed candidates learned
through an Allocate request, the keepalive MUST be new Allocate through an Allocate request, the keepalive MUST be new Allocate
requests. The Allocate requests will also refresh the server requests. The Allocate requests will also refresh the server
reflexive candidate. 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**31 - 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
Section 4.1.2.1 and choose its parameters using the guidelines in Section 4.1.2.1 and choose its parameters using the guidelines in
Section 4.1.2.2. If an agent elects to use a different formula, ICE Section 4.1.2.2. If an agent elects to use a different formula, ICE
will take longer to converge since both agents will not be will take longer to converge since both agents will not be
coordinated in their checks. coordinated in their checks.
4.1.2.1. Recommended Formula 4.1.2.1. Recommended Formula
skipping to change at page 30, line 10 skipping to change at page 30, line 10
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.
3. If the default candidates were relayed candidates learned through
a TURN server, the agent MUST create permissions in the TURN
server for the IP addresses learned from its peer in the SDP it
just received. If this is not done, initial packets in the media
stream from the peer may be lost.
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 the choice of the final candidate pairs used for communications. for the choice of the final candidate pairs used for communications.
For a full agent, this means nominating the candidate pairs that can For a full agent, this means nominating the candidate pairs that can
be used by ICE for each media stream, and for generating the updated be used by ICE for each media stream, and for generating the updated
offer based on ICE's selection, when needed. For a lite offer based on ICE's selection, when needed. For a lite
implementation, being the controlling agent means selecting a implementation, being the controlling agent means selecting a
candidate pair based on the ones in the offer and answer (for IPv4, candidate pair based on the ones in the offer and answer (for IPv4,
skipping to change at page 34, line 16 skipping to change at page 35, line 15
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 G be the priority for the candidate provided by the controlling Let G be the priority for the candidate provided by the controlling
agent. Let D be the priority for the candidate provided by the agent. Let D be the priority for the candidate provided by the
controlled agent. The priority for a pair is computed as: controlled agent. The priority for a pair is computed as:
pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0) pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)
Where G>D?1:0 is an expression whose value is 1 if G is greater than Where G>D?1:0 is an expression whose value is 1 if G is greater than
D, and 0 otherwise. This formula ensures a unique priority for each D, and 0 otherwise. Once the priority is assigned, the agent sorts
pair. Once the priority is assigned, the agent sorts the candidate the candidate pairs in decreasing order of priority. If two pairs
pairs in decreasing order of priority. If two pairs have identical have identical priority, the ordering amongst them is arbitrary.
priority, the ordering amongst them is 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
replaced by its base. Once this has been done, the agent MUST prune replaced by its base. Once this has been done, the agent MUST prune
the list. This is done by removing a pair if its local and remote the list. This is done by removing a pair if its local and remote
candidates are identical to the local and remote candidates of a pair candidates are identical to the local and remote candidates of a pair
higher up on the priority list. The result is a sequence of ordered higher up on the priority list. The result is a sequence of ordered
candidate pairs, called the check list for that media stream. candidate pairs, called the check list for that media stream.
In addition, in order to limit the attacks described in In addition, in order to limit the attacks described in
Section 18.5.2, an agent SHOULD limit the total number of Section 18.5.2, an agent MUST limit the total number of connectivity
connectivity checks they perform across all check lists to a checks they perform across all check lists to a specific value, adn
configurable value. A default of 100 is RECOMMENDED. This limit is this value MUST be configurable. A default of 100 is RECOMMENDED.
enforced by discarding the lower priority candidate pairs until there This limit is enforced by discarding the lower priority candidate
are less than 100. It is RECOMMENDED that a lower value be utilized pairs until there are less than 100. It is RECOMMENDED that a lower
when possible, set to the maximum number of plausible checks that value be utilized when possible, set to the maximum number of
might be seen in an actual deployment configuration. plausible checks that might be seen in an actual deployment
configuration. The requirement for configuration is meant to
provided a tool for fixing this value in the field if, once deployed,
it is found to be problematic.
5.7.4. Computing States 5.7.4. Computing States
Each candidate pair in the check list has a foundation and a state. Each candidate pair in the check list has a foundation and a state.
The foundation is the combination of the foundations of the local and The foundation is the combination of the foundations of the local and
remote candidates in the pair. The state is assigned once the check remote candidates in the pair. The state is assigned once the check
list for each media stream has been computed. There are five list for each media stream has been computed. There are five
potential values that the state can have: potential values that the state can have:
Waiting: A check has not been performed for this pair, and can be Waiting: A check has not been performed for this pair, and can be
skipping to change at page 37, line 8 skipping to change at page 38, line 8
The initial states for each pair in a 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:
* Groups together all of the pairs with the same foundation,
* For each group, sets the state of the pair with the lowest * For all pairs with the same foundation, it sets the state of
component ID to Waiting. If there is more than one such pair, the pair with the lowest component ID to Waiting. If there is
the one with the highest priority is used. more than one such pair, the one with the highest priority is
used.
One of the check lists will have some number of pairs in the Waiting One of the check lists will have some number of pairs in the Waiting
state, and the other check lists will have all of their pairs in the state, and the other check lists will have all of their pairs in the
Frozen state. A check list with at least one pair that is 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 three states: state of ICE checks for that media stream. There are three states:
skipping to change at page 45, line 39 skipping to change at page 46, line 39
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.
If the agent is the controlled agent, the response may result in the If the agent is the controlled agent, the response may be the result
valid pair having its nominated flag set. See Section 7.2.1.5 for of a triggered check which was sent in response to a request which
the procedure. itself had the USE-CANDIDATE attribute. This case is described in
Section 7.2.1.5, and may now result in setting the nominated flag for
the pair learned from the original request.
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: Succeeded state:
skipping to change at page 49, line 22 skipping to change at page 50, line 22
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, a check for * If the state of that pair is Waiting or Frozen, a check for
that pair is enqueued into the triggered check queue. that pair is enqueued into the triggered check queue if not
already present.
* If the state of that pair is In-Progress, the agent cancels the * If the state of that pair is In-Progress, the agent cancels the
in-progress transaction. Cancellation means that the agent in-progress transaction. Cancellation means that the agent
will not retransmit the request, will not treat the lack of will not retransmit the request, will not treat the lack of
response to be a failure, but will wait the duration of the response to be a failure, but will wait the duration of the
transaction timeout for a response. In addition, the agent transaction timeout for a response. In addition, the agent
MUST create a new connectivity check for that pair MUST create a new connectivity check for that pair
(representing a new STUN Binding Request transaction) by (representing a new STUN Binding Request transaction) by
enqueueing the pair in the triggered check queue. The state of enqueueing the pair in the triggered check queue. The state of
the pair is then changed to Waiting. the pair is then changed to Waiting.
skipping to change at page 73, line 42 skipping to change at page 74, line 42
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
component ID of 1, and candidates for RTCP MUST have a component component ID of 1, and candidates for RTCP MUST have a component
ID of 2. Other types of media streams which require multiple ID of 2. Other types of media streams which require multiple
components MUST develop specifications which define the mapping of components MUST develop specifications which define the mapping of
components to component IDs. See Section 14 for additional components to component IDs. See Section 14 for additional
discussion on extending ICE to new media streams. discussion on extending ICE to new media streams.
<priority>: is a positive integer between 1 and (2**32 - 1). <priority>: is a positive integer between 1 and (2**31 - 1).
<cand-type>: encodes the type of candidate. This specification <cand-type>: encodes the type of candidate. This specification
defines the values "host", "srflx", "prflx" and "relay" for host, defines the values "host", "srflx", "prflx" and "relay" for host,
server reflexive, peer reflexive and relayed candidates, server reflexive, peer reflexive and relayed candidates,
respectively. The set of candidate types is extensible for the respectively. The set of candidate types is extensible for the
future. future.
<rel-addr> and <rel-port>: convey transport addresses related to the <rel-addr> and <rel-port>: convey transport addresses related to the
candidate, useful for diagnostics and other purposes. <rel-addr> candidate, useful for diagnostics and other purposes. <rel-addr>
and <rel-port> MUST be present for server reflexive, peer and <rel-port> MUST be present for server reflexive, peer
skipping to change at page 76, line 13 skipping to change at page 77, line 13
ice-option-tag = 1*ice-char ice-option-tag = 1*ice-char
16. Setting Ta and RTO 16. Setting Ta and RTO
During the gathering phase of ICE (Section 4.1.1) and while ICE is During the gathering phase of ICE (Section 4.1.1) and while ICE is
performing connectivity checks (Section 7), an agent sends STUN and performing connectivity checks (Section 7), an agent sends STUN and
TURN transactions. These transcations are paced at a rate of one TURN transactions. These transcations are paced at a rate of one
every Ta milliseconds, and utilize a specific RTO. This section every Ta milliseconds, and utilize a specific RTO. This section
describes how the value of Ta and RTO are computed. This computation describes how the value of Ta and RTO are computed. This computation
depends on whether ICE is being used with a real time media stream depends on whether ICE is being used with a real time media stream
(such as RTP) or something else. (such as RTP) or something else. When ICE is used for a stream with
a known maximum bandwidth, the computation in Section 16.1 MAY be
followed to rate-control the ICE exchanges. For all other streams,
the computation in Section 16.2 MUST be followed.
16.1. RTP Media Streams 16.1. RTP Media Streams
The values of RTP and Ta change during the lifetime of ICE The values of RTP and Ta change during the lifetime of ICE
processing. One set of values applies during the gathering phase, processing. One set of values applies during the gathering phase,
and the other, for connectivity checks. and the other, for connectivity checks.
The value of Ta SHOULD be configurable, and SHOULD have a default of: The value of Ta SHOULD be configurable, and SHOULD have a default of:
For each media stream i: For each media stream i:
skipping to change at page 77, line 29 skipping to change at page 78, line 31
These formulas are aimed at causing STUN transactions to be paced at These formulas are aimed at causing STUN transactions to be paced at
the same rate as media. This ensures that ICE will work properly the same rate as media. This ensures that ICE will work properly
under the same network conditions needed to support the media as under the same network conditions needed to support the media as
well. See Appendix B.1 for additional discussion and motivations. well. See Appendix B.1 for additional discussion and motivations.
Because of this pacing, it will take a certain amount of time to Because of this pacing, it will take a certain amount of time to
obtain all of the server reflexive and relayed candidates. obtain all of the server reflexive and relayed candidates.
Implementations should be aware of the time required to do this, and Implementations should be aware of the time required to do this, and
if the application requires a time budget, limit the number of if the application requires a time budget, limit the number of
candidates which are gathered. candidates which are gathered.
The formulas result in a behavior whereby an agent will send its
first packet for every single connectivity check before performing a
retransmit. This can be seen in the formulas for the RTO (which
represents the retransmit interval). Those formulas scale with N,
the number of checks to be performed. As a result of this, ICE
maintains a nicely constant rate, but becomes more sensitive to
packet loss. The loss of the first single packet for any
connectivity check is likely to cause that pair to take a long time
to be validated, and instead, a lower priority check (but one for
which there was no packet loss) is much more likely to complete
first. This results in ICE performing sub-optimally, choosing lower
priority pairs over higher priority pairs. Implementors should be
aware of this consequence, but still should utilize the timer values
described here.
16.2. Non-RTP Sessions 16.2. Non-RTP Sessions
In cases where ICE is used to establish some kind of session which is In cases where ICE is used to establish some kind of session which is
not real time, and has no fixed rate associated with it that is known not real time, and has no fixed rate associated with it that is known
to work on the network in which ICE is deployed, Ta and RTO revert to to work on the network in which ICE is deployed, Ta and RTO revert to
more conservative values. Ta SHOULD be configurable and SHOULD have more conservative values. Ta SHOULD be configurable, SHOULD have a
a default of 500ms. default of 500ms, and MUST NOT be configurable to be less than 500ms.
In addition, the retransmission timer for the STUN transactions, RTO, In addition, the retransmission timer for the STUN transactions, RTO,
SHOULD be configurable and during the gathering phase, SHOULD have a SHOULD be configurable and during the gathering phase, SHOULD have a
default of: default of:
RTO = MAX (500ms, Ta * (number of pairs)) RTO = MAX (500ms, Ta * (number of pairs))
Where the number of pairs refers to the number of pairs of candidates Where the number of pairs refers to the number of pairs of candidates
with STUN or TURN servers. with STUN or TURN servers.
skipping to change at page 105, line 23 skipping to change at page 107, line 23
[I-D.ietf-behave-tcp] [I-D.ietf-behave-tcp]
Guha, S., "NAT Behavioral Requirements for TCP", Guha, S., "NAT Behavioral Requirements for TCP",
draft-ietf-behave-tcp-07 (work in progress), April 2007. draft-ietf-behave-tcp-07 (work in progress), April 2007.
[I-D.ietf-sipping-config-framework] [I-D.ietf-sipping-config-framework]
Petrie, D. and S. Channabasappa, "A Framework for Session Petrie, D. and S. Channabasappa, "A Framework for Session
Initiation Protocol User Agent Profile Delivery", Initiation Protocol User Agent Profile Delivery",
draft-ietf-sipping-config-framework-12 (work in progress), draft-ietf-sipping-config-framework-12 (work in progress),
June 2007. June 2007.
[I-D.ietf-mmusic-ice-tcp]
Rosenberg, J., "TCP Candidates with Interactive
Connectivity Establishment (ICE",
draft-ietf-mmusic-ice-tcp-04 (work in progress),
July 2007.
Appendix A. Lite and Full Implementations Appendix A. Lite and Full Implementations
ICE allows for two types of implementations. A full implementation ICE allows for two types of implementations. A full implementation
supports the controlling and controlled roles in a session, and can supports the controlling and controlled roles in a session, and can
also perform address gathering. In contrast, a lite implementation also perform address gathering. In contrast, a lite implementation
is a minimalist implementation that does little but respond to STUN is a minimalist implementation that does little but respond to STUN
checks. checks.
Because ICE requires both endpoints to support it in order to bring Because ICE requires both endpoints to support it in order to bring
benefits to either endpoint, incremental deployment of ICE in a benefits to either endpoint, incremental deployment of ICE in a
skipping to change at page 107, line 7 skipping to change at page 109, line 13
retransmission timer RTO that is a function of Ta as well. Why are retransmission timer RTO that is a function of Ta as well. Why are
these transactions paced, and why are these formulas used? 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. Experiments have shown rate at which they will create new bindings. Experiments have shown
that once every 20ms is well supported, but not much lower than that. that once every 20ms is well supported, but not much lower than that.
This is why Ta has a lower bound of 20ms. Furthermore, transmission This is why Ta has a lower bound of 20ms. Furthermore, transmission
of these packets on the network makes use of bandwidth and needs to of these packets on the network makes use of bandwidth and needs to
be rate limited by the agent. As a consequence, the pacing ensures be rate limited by the agent. Deployments based on earlier drafts of
that the NAT devices does not get overloaded and that traffic is kept this document tended to overload rate-constrained access links and
at a reasonable rate. perform poorly overall, in addition to negatively impacting the
network. 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 The definition of a "reasonable" rate is that STUN should not use
more bandwidth than the RTP itself will use, once media starts more bandwidth than the RTP itself will use, once media starts
flowing. The formula for Ta is designed so that, if a STUN packet 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 were sent every Ta seconds, it would consume the same amount of
bandwidth as RTP packets, summed across all media streams. Of bandwidth as RTP packets, summed across all media streams. Of
course, STUN has retransmits, and the desire is to pace those as 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 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 the first transaction happens just as the first STUN request on the
last transaction occurs. Pictorially: last transaction occurs. Pictorially:
 End of changes. 24 change blocks. 
214 lines changed or deleted 253 lines changed or added

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