draft-ietf-mmusic-ice-12.txt | draft-ietf-mmusic-ice-13.txt | |||
---|---|---|---|---|
MMUSIC J. Rosenberg | MMUSIC J. Rosenberg | |||
Internet-Draft Cisco Systems | Internet-Draft Cisco Systems | |||
Expires: April 26, 2007 October 23, 2006 | Expires: July 20, 2007 January 16, 2007 | |||
Interactive Connectivity Establishment (ICE): A Methodology for Network | Interactive Connectivity Establishment (ICE): A Methodology for Network | |||
Address Translator (NAT) Traversal for Offer/Answer Protocols | Address Translator (NAT) Traversal for Offer/Answer Protocols | |||
draft-ietf-mmusic-ice-12 | draft-ietf-mmusic-ice-13 | |||
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 34 | skipping to change at page 1, line 34 | |||
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 April 26, 2007. | This Internet-Draft will expire on July 20, 2007. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2006). | Copyright (C) The Internet Society (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 session signaling protocols based on | (NAT) traversal for multimedia session signaling protocols based on | |||
the offer/answer model, such as the Session Initiation Protocol | the offer/answer model, such as the Session Initiation Protocol | |||
(SIP). This protocol is called Interactive Connectivity | (SIP). This protocol is called Interactive Connectivity | |||
Establishment (ICE). ICE makes use of the Simple Traversal | Establishment (ICE). ICE makes use of the Session Traversal | |||
Underneath 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. | connectivity between peers. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
2. Overview of ICE . . . . . . . . . . . . . . . . . . . . . . . 5 | 2. Overview of ICE . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
2.1. Gathering Candidate Addresses . . . . . . . . . . . . . . 7 | 2.1. Gathering Candidate Addresses . . . . . . . . . . . . . . 7 | |||
2.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 9 | 2.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 9 | |||
2.3. Sorting Candidates . . . . . . . . . . . . . . . . . . . . 10 | 2.3. Sorting Candidates . . . . . . . . . . . . . . . . . . . . 10 | |||
2.4. Frozen Candidates . . . . . . . . . . . . . . . . . . . . 11 | 2.4. Frozen Candidates . . . . . . . . . . . . . . . . . . . . 11 | |||
2.5. Security for Checks . . . . . . . . . . . . . . . . . . . 11 | 2.5. Security for Checks . . . . . . . . . . . . . . . . . . . 11 | |||
2.6. Concluding ICE . . . . . . . . . . . . . . . . . . . . . . 11 | 2.6. Concluding ICE . . . . . . . . . . . . . . . . . . . . . . 12 | |||
2.7. Passive-Only Agents . . . . . . . . . . . . . . . . . . . 12 | 2.7. Lite Implementations . . . . . . . . . . . . . . . . . . . 13 | |||
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
4. Choosing a Mode . . . . . . . . . . . . . . . . . . . . . . . 15 | 4. Sending the Initial Offer . . . . . . . . . . . . . . . . . . 16 | |||
5. Sending the Initial Offer . . . . . . . . . . . . . . . . . . 15 | 4.1. Full Implementation Requirements . . . . . . . . . . . . . 16 | |||
5.1. Gathering Candidates . . . . . . . . . . . . . . . . . . . 16 | 4.1.1. Gathering Candidates . . . . . . . . . . . . . . . . . 16 | |||
5.2. Prioritizing Candidates . . . . . . . . . . . . . . . . . 18 | 4.1.2. Prioritizing Candidates . . . . . . . . . . . . . . . 18 | |||
5.3. Choosing In-Use Candidates . . . . . . . . . . . . . . . . 20 | 4.1.3. Choosing In-Use Candidates . . . . . . . . . . . . . . 20 | |||
5.4. Encoding the SDP . . . . . . . . . . . . . . . . . . . . . 20 | 4.2. Lite Implementation . . . . . . . . . . . . . . . . . . . 20 | |||
6. Receiving the Initial Offer . . . . . . . . . . . . . . . . . 22 | 4.3. Encoding the SDP . . . . . . . . . . . . . . . . . . . . . 21 | |||
6.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 22 | 5. Receiving the Initial Offer . . . . . . . . . . . . . . . . . 22 | |||
6.2. Determining Role . . . . . . . . . . . . . . . . . . . . . 23 | 5.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 23 | |||
6.3. Gathering Candidates . . . . . . . . . . . . . . . . . . . 23 | 5.2. Determining Role . . . . . . . . . . . . . . . . . . . . . 23 | |||
6.4. Prioritizing Candidates . . . . . . . . . . . . . . . . . 23 | 5.3. Gathering Candidates . . . . . . . . . . . . . . . . . . . 24 | |||
6.5. Choosing In Use Candidates . . . . . . . . . . . . . . . . 23 | 5.4. Prioritizing Candidates . . . . . . . . . . . . . . . . . 24 | |||
6.6. Encoding the SDP . . . . . . . . . . . . . . . . . . . . . 23 | 5.5. Choosing In Use Candidates . . . . . . . . . . . . . . . . 24 | |||
6.7. Forming the Check Lists . . . . . . . . . . . . . . . . . 23 | 5.6. Encoding the SDP . . . . . . . . . . . . . . . . . . . . . 24 | |||
6.8. Performing Periodic Checks . . . . . . . . . . . . . . . . 26 | 5.7. Forming the Check Lists . . . . . . . . . . . . . . . . . 24 | |||
7. Receipt of the Initial Answer . . . . . . . . . . . . . . . . 27 | 5.8. Performing Periodic Checks . . . . . . . . . . . . . . . . 27 | |||
7.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 27 | 6. Receipt of the Initial Answer . . . . . . . . . . . . . . . . 28 | |||
7.2. Determining Role . . . . . . . . . . . . . . . . . . . . . 27 | 6.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 28 | |||
7.3. Forming the Check List . . . . . . . . . . . . . . . . . . 27 | 6.2. Determining Role . . . . . . . . . . . . . . . . . . . . . 28 | |||
7.4. Performing Periodic Checks . . . . . . . . . . . . . . . . 27 | 6.3. Forming the Check List . . . . . . . . . . . . . . . . . . 28 | |||
8. Connectivity Checks . . . . . . . . . . . . . . . . . . . . . 27 | 6.4. Performing Periodic Checks . . . . . . . . . . . . . . . . 28 | |||
8.1. Client Procedures . . . . . . . . . . . . . . . . . . . . 28 | 7. Connectivity Checks . . . . . . . . . . . . . . . . . . . . . 28 | |||
8.1.1. Sending the Request . . . . . . . . . . . . . . . . . 28 | 7.1. Client Procedures . . . . . . . . . . . . . . . . . . . . 29 | |||
8.1.2. Processing the Response . . . . . . . . . . . . . . . 29 | 7.1.1. Sending the Request . . . . . . . . . . . . . . . . . 29 | |||
8.2. Server Procedures . . . . . . . . . . . . . . . . . . . . 30 | 7.1.2. Processing the Response . . . . . . . . . . . . . . . 30 | |||
9. Concluding ICE . . . . . . . . . . . . . . . . . . . . . . . . 32 | 7.2. Server Procedures . . . . . . . . . . . . . . . . . . . . 31 | |||
10. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . . . 33 | 7.2.1. Additional Procedures for Full Implementations . . . . 32 | |||
10.1. Generating the Offer . . . . . . . . . . . . . . . . . . . 33 | 7.2.2. Additional Procedures for Lite Implementations . . . . 34 | |||
10.2. Receiving the Offer and Generating an Answer . . . . . . . 34 | 8. Concluding ICE . . . . . . . . . . . . . . . . . . . . . . . . 34 | |||
10.3. Updating the Check and Valid Lists . . . . . . . . . . . . 35 | 9. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . . . 35 | |||
11. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . . 37 | 9.1. Generating the Offer . . . . . . . . . . . . . . . . . . . 35 | |||
12. Media Handling . . . . . . . . . . . . . . . . . . . . . . . . 38 | 9.1.1. Additional Procedures for Full Implementations . . . . 36 | |||
12.1. Sending Media . . . . . . . . . . . . . . . . . . . . . . 38 | 9.1.2. Additional Procedures for Lite Implementations . . . . 37 | |||
12.2. Receiving Media . . . . . . . . . . . . . . . . . . . . . 39 | 9.2. Receiving the Offer and Generating an Answer . . . . . . . 37 | |||
13. Usage with SIP . . . . . . . . . . . . . . . . . . . . . . . . 39 | 9.2.1. Additional Procedures for Full Implementations . . . . 38 | |||
13.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . . 39 | 9.3. Updating the Check and Valid Lists . . . . . . . . . . . . 38 | |||
13.2. Interactions with Forking . . . . . . . . . . . . . . . . 40 | 9.3.1. Additional Procedures for Full Implementations . . . . 38 | |||
13.3. Interactions with Preconditions . . . . . . . . . . . . . 41 | 10. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . . 40 | |||
13.4. Interactions with Third Party Call Control . . . . . . . . 41 | 11. Media Handling . . . . . . . . . . . . . . . . . . . . . . . . 41 | |||
14. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 | 11.1. Sending Media . . . . . . . . . . . . . . . . . . . . . . 41 | |||
15. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 | 11.1.1. Procedures for Full Implementations . . . . . . . . . 41 | |||
16. Security Considerations . . . . . . . . . . . . . . . . . . . 49 | 11.1.2. Procedures for Lite Implementations . . . . . . . . . 42 | |||
16.1. Attacks on Connectivity Checks . . . . . . . . . . . . . . 49 | 11.2. Receiving Media . . . . . . . . . . . . . . . . . . . . . 42 | |||
16.2. Attacks on Address Gathering . . . . . . . . . . . . . . . 52 | 12. Usage with SIP . . . . . . . . . . . . . . . . . . . . . . . . 42 | |||
16.3. Attacks on the Offer/Answer Exchanges . . . . . . . . . . 52 | 12.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . . 42 | |||
16.4. Insider Attacks . . . . . . . . . . . . . . . . . . . . . 52 | 12.2. SIP Option Tags and Media Feature Tags . . . . . . . . . . 44 | |||
16.4.1. The Voice Hammer Attack . . . . . . . . . . . . . . . 53 | 12.3. Interactions with Forking . . . . . . . . . . . . . . . . 44 | |||
16.4.2. STUN Amplification Attack . . . . . . . . . . . . . . 53 | 12.4. Interactions with Preconditions . . . . . . . . . . . . . 45 | |||
17. Definition of Connectivity Check Usage . . . . . . . . . . . . 54 | 12.5. Interactions with Third Party Call Control . . . . . . . . 45 | |||
17.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 54 | 13. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 | |||
17.2. Client Discovery of Server . . . . . . . . . . . . . . . . 54 | 14. Extensibility Considerations . . . . . . . . . . . . . . . . . 48 | |||
17.3. Server Determination of Usage . . . . . . . . . . . . . . 54 | 15. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 | |||
17.4. New Requests or Indications . . . . . . . . . . . . . . . 54 | 16. Security Considerations . . . . . . . . . . . . . . . . . . . 54 | |||
17.5. New Attributes . . . . . . . . . . . . . . . . . . . . . . 54 | 16.1. Attacks on Connectivity Checks . . . . . . . . . . . . . . 54 | |||
17.6. New Error Response Codes . . . . . . . . . . . . . . . . . 55 | 16.2. Attacks on Address Gathering . . . . . . . . . . . . . . . 57 | |||
17.7. Client Procedures . . . . . . . . . . . . . . . . . . . . 55 | 16.3. Attacks on the Offer/Answer Exchanges . . . . . . . . . . 57 | |||
17.8. Server Procedures . . . . . . . . . . . . . . . . . . . . 55 | 16.4. Insider Attacks . . . . . . . . . . . . . . . . . . . . . 57 | |||
17.9. Security Considerations for Connectivity Check . . . . . . 55 | 16.4.1. The Voice Hammer Attack . . . . . . . . . . . . . . . 58 | |||
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 | 16.4.2. STUN Amplification Attack . . . . . . . . . . . . . . 58 | |||
18.1. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . 55 | 16.5. Interactions with Application Layer Gateways and SIP . . . 59 | |||
18.1.1. candidate Attribute . . . . . . . . . . . . . . . . . 55 | 17. Definition of Connectivity Check Usage . . . . . . . . . . . . 59 | |||
18.1.2. remote-candidates Attribute . . . . . . . . . . . . . 56 | 17.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 60 | |||
18.1.3. ice-passive Attribute . . . . . . . . . . . . . . . . 56 | 17.2. Client Discovery of Server . . . . . . . . . . . . . . . . 60 | |||
18.1.4. ice-pwd Attribute . . . . . . . . . . . . . . . . . . 57 | 17.3. Server Determination of Usage . . . . . . . . . . . . . . 60 | |||
18.1.5. ice-ufrag Attribute . . . . . . . . . . . . . . . . . 57 | 17.4. New Requests or Indications . . . . . . . . . . . . . . . 60 | |||
18.2. STUN Attributes . . . . . . . . . . . . . . . . . . . . . 58 | 17.5. New Attributes . . . . . . . . . . . . . . . . . . . . . . 60 | |||
19. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 58 | 17.6. New Error Response Codes . . . . . . . . . . . . . . . . . 61 | |||
19.1. Problem Definition . . . . . . . . . . . . . . . . . . . . 58 | 17.7. Client Procedures . . . . . . . . . . . . . . . . . . . . 61 | |||
19.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 59 | 17.8. Server Procedures . . . . . . . . . . . . . . . . . . . . 61 | |||
19.3. Brittleness Introduced by ICE . . . . . . . . . . . . . . 59 | 17.9. Security Considerations for Connectivity Check . . . . . . 61 | |||
19.4. Requirements for a Long Term Solution . . . . . . . . . . 60 | 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61 | |||
19.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 60 | 18.1. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . 61 | |||
20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 61 | 18.1.1. candidate Attribute . . . . . . . . . . . . . . . . . 61 | |||
21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61 | 18.1.2. remote-candidates Attribute . . . . . . . . . . . . . 62 | |||
21.1. Normative References . . . . . . . . . . . . . . . . . . . 61 | 18.1.3. ice-lite Attribute . . . . . . . . . . . . . . . . . . 62 | |||
21.2. Informative References . . . . . . . . . . . . . . . . . . 62 | 18.1.4. ice-mismatch Attribute . . . . . . . . . . . . . . . . 63 | |||
Appendix A. Passive-Only ICE . . . . . . . . . . . . . . . . . . 64 | 18.1.5. ice-pwd Attribute . . . . . . . . . . . . . . . . . . 63 | |||
Appendix B. Design Motivations . . . . . . . . . . . . . . . . . 66 | 18.1.6. ice-ufrag Attribute . . . . . . . . . . . . . . . . . 63 | |||
B.1. Pacing of STUN Transactions . . . . . . . . . . . . . . . 66 | 18.1.7. ice-options Attribute . . . . . . . . . . . . . . . . 64 | |||
B.2. Candidates with Multiple Bases . . . . . . . . . . . . . . 67 | 18.2. STUN Attributes . . . . . . . . . . . . . . . . . . . . . 64 | |||
B.3. Purpose of the Translation . . . . . . . . . . . . . . . . 69 | 19. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 65 | |||
B.4. Importance of the STUN Username . . . . . . . . . . . . . 69 | 19.1. Problem Definition . . . . . . . . . . . . . . . . . . . . 65 | |||
B.5. The Candidate Pair Sequence Number Formula . . . . . . . . 70 | 19.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 65 | |||
B.6. The Frozen State . . . . . . . . . . . . . . . . . . . . . 71 | 19.3. Brittleness Introduced by ICE . . . . . . . . . . . . . . 66 | |||
B.7. The remote-candidates attribute . . . . . . . . . . . . . 71 | 19.4. Requirements for a Long Term Solution . . . . . . . . . . 67 | |||
B.8. Why are Keepalives Needed? . . . . . . . . . . . . . . . . 72 | 19.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 67 | |||
B.9. Why Prefer Peer Reflexive Candidates? . . . . . . . . . . 73 | 20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 68 | |||
B.10. Why Send an Updated Offer? . . . . . . . . . . . . . . . . 73 | 21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 68 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 74 | 21.1. Normative References . . . . . . . . . . . . . . . . . . . 68 | |||
Intellectual Property and Copyright Statements . . . . . . . . . . 75 | 21.2. Informative References . . . . . . . . . . . . . . . . . . 69 | |||
Appendix A. Lite and Full Implementations . . . . . . . . . . . . 71 | ||||
Appendix B. Design Motivations . . . . . . . . . . . . . . . . . 71 | ||||
B.1. Pacing of STUN Transactions . . . . . . . . . . . . . . . 72 | ||||
B.2. Candidates with Multiple Bases . . . . . . . . . . . . . . 72 | ||||
B.3. Purpose of the Translation . . . . . . . . . . . . . . . . 74 | ||||
B.4. Importance of the STUN Username . . . . . . . . . . . . . 74 | ||||
B.5. The Candidate Pair Sequence Number Formula . . . . . . . . 75 | ||||
B.6. The Frozen State . . . . . . . . . . . . . . . . . . . . . 76 | ||||
B.7. The remote-candidates attribute . . . . . . . . . . . . . 76 | ||||
B.8. Why are Keepalives Needed? . . . . . . . . . . . . . . . . 77 | ||||
B.9. Why Prefer Peer Reflexive Candidates? . . . . . . . . . . 78 | ||||
B.10. Why Send an Updated Offer? . . . . . . . . . . . . . . . . 78 | ||||
B.11. Why are Binding Indications Used for Keepalives? . . . . . 78 | ||||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 80 | ||||
Intellectual Property and Copyright Statements . . . . . . . . . . 81 | ||||
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 IP addresses within their | flow of media packets, they tend to carry IP addresses within their | |||
messages, which is known to be problematic through NAT [14]. The | messages, which is known to be problematic through NAT [15]. The | |||
protocols also seek to create a media flow directly between | protocols also seek to create a media flow directly between | |||
participants, so that there is no application layer intermediary | participants, so that there is no application layer intermediary | |||
between them. This is done to reduce media latency, decrease packet | between them. This is done to reduce media latency, decrease packet | |||
loss, and reduce the operational costs of deploying the application. | loss, and reduce the operational costs of deploying the application. | |||
However, this is difficult to accomplish through NAT. A full | However, this is difficult to accomplish through NAT. A full | |||
treatment of the reasons for this is beyond the scope of this | treatment of the reasons for this is beyond the scope of this | |||
specification. | 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 [15], Simple Traversal | (ALGs), the Middlebox Control Protocol [16], Simple Traversal | |||
Underneath NAT (STUN) [13] and its revision [11], the STUN Relay | Underneath NAT (STUN) [14] and its revision, retitled Session | |||
Usage [12], and Realm Specific IP [17] [18] along with session | Traversal Utilities for NAT [11], the STUN Relay Usage [12], and | |||
description extensions needed to make them work, such as the Session | Realm Specific IP [18] [19] along with session description extensions | |||
Description Protocol (SDP) [10] attribute for the Real Time Control | needed to make them work, such as the Session Description Protocol | |||
Protocol (RTCP) [2]. Unfortunately, these techniques all have pros | (SDP) [10] attribute for the Real Time Control Protocol (RTCP) [2]. | |||
and cons which make each one optimal in some network topologies, but | Unfortunately, these techniques all have pros and cons which make | |||
a poor choice in others. The result is that administrators and | each one optimal in some network topologies, but a poor choice in | |||
implementors are making assumptions about the topologies of the | others. The result is that administrators and implementors are | |||
networks in which their solutions will be deployed. This introduces | making assumptions about the topologies of the networks in which | |||
complexity and brittleness into the system. What is needed is a | their solutions will be deployed. This introduces complexity and | |||
single solution which is flexible enough to work well in all | brittleness into the system. What is needed is a single solution | |||
situations. | which is flexible enough to work well in all situations. | |||
This specification provides that solution for media streams | This specification provides that solution for media streams | |||
established by signaling protocols based on the offer-answer model. | established by signaling protocols based on the offer-answer model. | |||
It is called Interactive Connectivity Establishment, or ICE. ICE | It is called Interactive Connectivity Establishment, or ICE. ICE | |||
makes use of STUN and its relay extension, commonly called TURN, but | makes use of STUN and its relay extension, commonly called TURN, but | |||
uses them in a specific methodology which avoids many of the pitfalls | uses them in a specific methodology which avoids many of the pitfalls | |||
of using any one alone. | of using any one alone. | |||
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 system such as SIP, by | communicate indirectly via some signaling system 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 some other mechanism [31]. At the | assumed to be provided via some other mechanism [32]. At the | |||
beginning of the ICE process, the agents are ignorant of their own | beginning of the ICE process, the agents are ignorant of their own | |||
topologies. In particular, they might or might not be behind a NAT | topologies. In particular, they might or might not be behind a NAT | |||
(or multiple tiers of NATs). ICE allows the agents to discover | (or multiple tiers of NATs). ICE allows the agents to discover | |||
enough information about their topologies to find a path or paths by | enough information about their topologies to find a path or paths by | |||
which they can communicate. | which they can communicate. | |||
Figure Figure 1 shows a typical environment for ICE deployment. The | Figure Figure 1 shows a typical environment for ICE deployment. The | |||
two endpoints are labelled L and R (for left and right, which helps | two endpoints are labelled L and R (for left and right, which helps | |||
visualize call flows). Both L and R are behind NATs -- though as | visualize call flows). Both L and R are behind NATs -- though as | |||
mentioned before, they don't know that. The type of NAT and its | mentioned before, they don't know that. The type of NAT and its | |||
skipping to change at page 7, line 21 | skipping to change at page 7, line 21 | |||
o It's directly attached network interface (or interfaces in the | o It's directly attached network interface (or interfaces in the | |||
case of a multihomed machine | case of a multihomed machine | |||
o A translated address on the public side of a NAT (a "server | o A translated address on the public side of a NAT (a "server | |||
reflexive" address) | reflexive" address) | |||
o The address of a media relay the agent is using. | o The 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 transport addresses. In practice, | communicate with any of R's candidate transport addresses. In | |||
however, many combinations will not work. For instance, if L and R | practice, however, many combinations will not work. For instance, if | |||
are both behind NATs then their directly interface addresses are | L and R are both behind NATs then their directly interface addresses | |||
unlikely to be able to communicate directly (this is why ICE is | are unlikely to be able to communicate directly (this is why ICE is | |||
needed, after all!). The purpose of ICE is to discover which pairs | needed, after all!). The purpose of ICE is to discover which pairs | |||
of addresses will work. The way that ICE does this is to | of addresses will work. The way that ICE does this is to | |||
systematically try all possible pairs (in a carefully sorted order) | systematically try all possible pairs (in a carefully sorted order) | |||
until it finds one or more that works. | until it finds one or more that works. | |||
2.1. Gathering Candidate Addresses | 2.1. Gathering Candidate Addresses | |||
In order to execute ICE, an agent has to identify all of its address | In order to execute ICE, an agent has to identify all of its address | |||
candidates. Naturally, one viable candidate is one obtained directly | candidates. Naturally, one viable candidate is one obtained directly | |||
from a local interface the client has towards the network. Such a | from a local interface the client has towards the network. Such a | |||
skipping to change at page 10, line 22 | skipping to change at page 10, line 22 | |||
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 | |||
Figure 3 | Figure 3 | |||
As an optimization, as soon as R gets L's check message he | As an optimization, as soon as R gets L's check message he | |||
immediately sends his own check message to L on the same candidate | immediately sends his own check message to L on the same candidate | |||
pair. This accelerates the process of finding a valid candidate. | pair. This accelerates the process of finding a valid candidate, and | |||
is called a triggered check. | ||||
At the end of this handshake, both L and R know that they can send | At the end of this handshake, both L and R know that they can send | |||
(and receive) messages end-to-end in both directions. | (and receive) messages end-to-end in both directions. | |||
2.3. Sorting Candidates | 2.3. Sorting Candidates | |||
Because the algorithm above searches all candidate pairs, if a | Because the algorithm above searches all candidate pairs, if a | |||
working pair exists it will eventually find it no matter what order | working pair exists it will eventually find it no matter what order | |||
the candidates are tried in. In order to produce faster (and better) | the candidates are tried in. In order to produce faster (and better) | |||
results, the candidates are sorted in a specified order. The | results, the candidates are sorted in a specified order. The | |||
algorithm is described in Section 5.2 but follows two general | algorithm is described in Section 4.1.2 but follows two general | |||
principles: | principles: | |||
o Each agent gives its candidates a numeric priority which is sent | o Each agent gives its candidates a numeric priority which is sent | |||
along with the candidate to the peer | along with the candidate to the peer | |||
o The local and remote priorities are combined so that each agent | o The local and remote priorities are combined so that each agent | |||
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 A and B. Frequently, NATs will not allow packets | are NATs in front of A and B. 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. | |||
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 | |||
are favored over indirect ones. Within those guidelines, however, | are preferred over indirect ones. Within those guidelines, however, | |||
agents have a fair amount of discretion about how to tune their | agents have a fair amount of discretion about how to tune their | |||
algorithms. | algorithms. | |||
2.4. Frozen Candidates | 2.4. Frozen Candidates | |||
The previous description only addresses the case where the agents | The previous description only addresses the case where the agents | |||
wish to establish a single media component--i.e., a single flow with | wish to establish a single media component--i.e., a single flow with | |||
a single host-port quartet. However, in many cases (in particular | a single host-port quartet. However, in many cases (in particular | |||
RTP and RTCP) the agents actually need to establish connectivity for | RTP and RTCP) the agents actually need to establish connectivity for | |||
more than one flow. | more than one flow. | |||
skipping to change at page 12, line 20 | skipping to change at page 12, line 24 | |||
run a little longer might produce better results. More | run a little longer might produce better results. More | |||
fundamentally, however, the prioritization defined by this | fundamentally, however, the prioritization defined by this | |||
specification may not yield "optimal" results. As an example, if the | specification may not yield "optimal" results. As an example, if the | |||
aim is to select low latency media paths, usage of a relay is a hint | aim is to select low latency media paths, usage of a relay is a hint | |||
that latencies may be higher, but it is nothing more than a hint. An | that latencies may be higher, but it is nothing more than a hint. An | |||
actual RTT measurement could be made, and it might demonstrate that a | actual RTT measurement could be made, and it might demonstrate that a | |||
pair with lower priority is actually better than one with higher | pair with lower priority is actually better than one with higher | |||
priority. | priority. | |||
Consequently, ICE assigns one of the agents in the role of the | Consequently, ICE assigns one of the agents in the role of the | |||
controlling agent, and the other as passive. The controlling agent | controlling agent, and the other of the controlled agent. The | |||
runs a selection algorithm, through which it can decide when to | controlling agent runs a selection algorithm, through which it can | |||
conclude ICE checks, and which pairs get selected. When a | decide when to conclude ICE checks, and which pairs get selected. | |||
controlling agent selects a pair for a particular component of a | The one that is selected is called the favored candidate pair. When | |||
a controlling agent selects a pair for a particular component of a | ||||
media stream, it generates a check for that pair and includes a flag | media stream, it generates a check for that pair and includes a flag | |||
in the check indicating that the pair has been selected. This will | in the check indicating that the pair has been selected. If the | |||
cause the passive agent to cease any other checks it has lined up for | controlled agent has already performed in a check in the reverse | |||
that component, and mark the pair validated by that check as | direction that succeeded, the controlled agent considers ICE | |||
"selected". Once there is a selected pair for each component of a | processing to be concluded for that component. Once there is a | |||
media stream, the ICE checks for that media stream are considered to | selected pair for each component of a media stream, the ICE checks | |||
be completed, and media can flow in each direction for that stream, | for that media stream are considered to be completed. At this point, | |||
as shown in Figure 4. Once all of the media streams are completed, | further checks stop for that media stream - ICE is considered to be | |||
the controlling endpoint sends an updated offer if the currently in- | done. Consequently, media can flow in each direction for that | |||
use candidates don't match the ones it selected. | stream, as shown in Figure 4. Once all of the media streams are | |||
completed, the controlling endpoint sends an updated offer if the | ||||
currently in-use candidates don't match the ones it selected. | ||||
L R | L R | |||
- - | - - | |||
STUN request + flag -> \ L's | STUN request + flag -> \ L's | |||
<- STUN response / check | <- STUN response / check | |||
-> RTP Data | -> RTP Data | |||
<- RTP Data | <- RTP Data | |||
Figure 4 | Figure 4 | |||
Once ICE is concluded, it can be restarted at any time for one or all | ||||
of the media streams by each agent. This is done by sending an | ||||
updated offer indicating a restart. | ||||
2.7. Passive-Only Agents | 2.7. Lite Implementations | |||
ICE requires both sides of a call to support it. However, certain | In order for ICE to be used in a call, both agents need to support | |||
agents, such as those in gateways to the PSTN, media servers, | it. However, certain agents, such as those in gateways to the PSTN, | |||
conferencing servers, and voicemail servers, are known to not be | media servers, conferencing servers, and voicemail servers, are known | |||
behind a NAT or firewall. To make it easier for these devices to | to not be behind a NAT or firewall. To make it easier for these | |||
support ICE, they can operate in a "passive-only" mode (in contrast | devices to support ICE, ICE defines a special type of implementation | |||
to a "full" mode). In passive-only mode, they don't need to gather | called "lite" (in contrast to the normal "full" implementation). A | |||
candidates and don't act as the controlling agent. They only need to | lite implementation doesn't gather candidates; it includes only its | |||
respond to checks, generate triggered checks, and follow the rules | host candidate for any media stream. When a lite implementation | |||
for sending media and keepalives. | connects with a full implementation, the full agent takes the role of | |||
the controlling agent, and the lite agent takes on the controlled | ||||
role. In addition, lite agents do not need to generate connectivity | ||||
checks, run the state machines, or compute candidate pairs. For an | ||||
informational summary of ICE processing as seen by a lite agent, see | ||||
[33]. | ||||
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]. | |||
This specification makes use of the following terminology: | This specification makes use of the following terminology: | |||
Agent: As defined in RFC 3264, an agent is the protocol | Agent: As defined in RFC 3264, an agent is the protocol | |||
skipping to change at page 13, line 40 | skipping to change at page 14, line 12 | |||
in order to determine its suitability for usage for receipt of | in order to determine its suitability for usage for receipt of | |||
media. | media. | |||
Component: A component is a single transport address that is used to | Component: A component is a single transport address that is used to | |||
support a media stream. For media streams based on RTP, there are | support a media stream. For media streams based on RTP, there are | |||
two components per media stream - one for RTP, and one for RTCP. | two 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) [17] (which | Private Networks (VPNs) and Realm Specific IP (RSIP) [18] (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, whose address is configured or learned by the client prior | peer, whose address is configured or learned by the client prior | |||
to an offer/answer exchange. | 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 15, line 18 | skipping to change at page 15, line 33 | |||
Periodic Check: A connectivity check generated by an agent as a | Periodic 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 that | Valid List: An ordered set of candidate pairs for a media stream that | |||
have been validated by a successful STUN transaction. | have been validated by a successful STUN transaction. | |||
Full: An ICE implementation that performs the complete set of | ||||
functionality defined by this specification. | ||||
Lite: An ICE implementation that omits certain functions, | ||||
implementing only as much as is necessary for a peer | ||||
implementation that is full to gain the benefits of ICE. Lite | ||||
implementations can only act as the controlled agent in a session, | ||||
and do not gather candidates. | ||||
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. | STUN and an updated offer, if needed. In any session, one agent | |||
is always controlling. The other is the controlled agent. | ||||
Passive Agent: The 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. | |||
4. Choosing a Mode | 4. Sending the Initial Offer | |||
The first step in ICE processing is selection of a mode. An ICE | ||||
agent can operate in either full mode or passive-only mode. An agent | ||||
MUST NOT act in passive-only mode unless the following are all true: | ||||
1. The device definitively knows that it has a public IP address. | ||||
Usage of tests and heuristics like those defined in RFC 3489 [13] | ||||
are not sufficient to make this determination. Rather, knowledge | ||||
comes from explicit configuration due to known location in the | ||||
network. Typically, this limits passive-only mode to devices | ||||
like PSTN gateways, conferencing servers, voicemail servers and | ||||
so on. | ||||
2. The device will only provide one candidate for each component of | ||||
each media stream, matching the values in the m/c-line for each | ||||
media stream. | ||||
Full mode is meant for general purpose endpoints, such as softphones, | ||||
hard-phones, and other devices that may or may not be placed in | ||||
networks with public addresses. | ||||
5. Sending the Initial Offer | ||||
In order to send the initial offer in an offer/answer exchange, an | In order to send the initial offer in an offer/answer exchange, an | |||
agent must gather candidates, priorize them, choose ones for | agent must gather candidates, priorize them, choose ones for | |||
inclusion in the m/c-line, and then formulate and send the SDP. Each | inclusion in the m/c-line, and then formulate and send the SDP. The | |||
of these steps is described in the subsections below. | first of these three steps differ for full and lite implementations. | |||
5.1. Gathering Candidates | 4.1. Full Implementation Requirements | |||
4.1.1. Gathering Candidates | ||||
An agent gathers candidates when it believes that communications is | An agent gathers candidates when it believes that communications is | |||
imminent. An offerer can do this based on a user interface cue, or | imminent. An offerer can do this based on a user interface cue, or | |||
based on an explicit request to initiate a session. Every candidate | based on an explicit request to initiate a session. Every candidate | |||
is a transport address. It also has a type and a base. Three types | is a transport address. It also has a type and a base. Three types | |||
are defined and gathered by this specification - host candidates, | are defined and gathered by this specification - host candidates, | |||
server reflexive candidates, and relayed candidates. The base of a | server reflexive candidates, and relayed candidates. The base of a | |||
candidate is the candidate that an agent must send from when using | candidate is the candidate that an agent must send from when using | |||
that candidate. | that candidate. | |||
skipping to change at page 16, line 38 | skipping to change at page 16, line 45 | |||
every candidate) is always associated with a specific component for | every candidate) is always associated with a specific component for | |||
which it is a candidate. Each component has an ID assigned to it, | which it is a candidate. Each component has an ID assigned to it, | |||
called the component ID. For RTP-based media streams, the RTP itself | called the component ID. For RTP-based media streams, the RTP itself | |||
has a component ID of 1, and RTCP a component ID of 2. If an agent | has a component ID of 1, and RTCP a component ID of 2. If an agent | |||
is using RTCP it MUST obtain a candidate for it. If an agent is | is using RTCP it MUST obtain a candidate for it. If an agent is | |||
using both RTP and RTCP, it would end up with 2*K host candidates if | using both RTP and RTCP, it would end up with 2*K host candidates if | |||
an agent has K interfaces. | an agent has K interfaces. | |||
The base for each host candidate is set to the candidate itself. | The base for each host candidate is set to the candidate itself. | |||
Agents implementing passive-only mode MUST NOT gather server | Agents SHOULD obtain relayed candidates and MUST obtain server | |||
reflexive or relayed candidates. Agents implementing full mode | reflexive candidates. The requirement to obtain relayed candidates | |||
SHOULD obtain relayed candidates and MUST obtain server reflexive | is at SHOULD strength to allow for provider variation. If they are | |||
candidates. The requirement to obtain relayed candidates is at | not used, it is RECOMMENDED that it be implemented and just disabled | |||
SHOULD strength to allow for provider variation. If they are not | ||||
used, it is RECOMMENDED that it 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 full-mode agent next pairs each host candidate with the STUN | The agent next pairs each host candidate with the STUN server with | |||
server with which it is configured or has discovered by some means. | which it is configured or has discovered by some means. This | |||
This specification only considers usage of a single STUN server. | specification only considers usage of a single STUN server. Every Ta | |||
Every Ta seconds, the full-mode agent chooses another such pair (the | seconds, the agent chooses another such pair (the order is | |||
order is inconsequential), and sends a STUN request to the server | inconsequential), and sends a STUN request to the server from that | |||
from that host candidate. If the full-mode agent is using both | host candidate. If the agent is using both relayed and server | |||
relayed and server reflexive candidates, this request MUST be a STUN | reflexive candidates, this request MUST be a STUN Allocate request | |||
Allocate request from the relay usage [12]. If the full-mode agent | from the relay usage [12]. If the agent is using only server | |||
is using only server reflexive candidates, the request MUST be a STUN | reflexive candidates, the request MUST be a STUN Binding request | |||
Binding request using the binding discovery usage [11]. | using the binding discovery usage [11]. | |||
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 | |||
20ms. Note that this pacing applies only to starting STUN | 20ms. Note that this pacing applies only to starting STUN | |||
transactions with source and destination transport addresses (i.e., | transactions with source and destination transport addresses (i.e., | |||
the host candidate and STUN server respectively) for which a STUN | the host candidate and STUN server respectively) for which a STUN | |||
transaction has not previously been sent. Consequently, | transaction has not previously been sent. Consequently, | |||
retransmissions of a STUN request are governed entirely by the | retransmissions of a STUN request are governed entirely by the | |||
retransmission rules defined in [11]. Similarly, retries of a | retransmission rules defined in [11]. Similarly, retries of a | |||
request due to recoverable errors (such as an authentication | request due to recoverable errors (such as an authentication | |||
challenge) happen immediately and are not paced by timer Ta. Because | challenge) happen immediately and are not paced by timer Ta. Because | |||
of this pacing, it will take a certain amount of time to obtain all | of this pacing, it will take a certain amount of time to obtain all | |||
of the server reflexive and relayed candidates. Implementations | of the server reflexive and relayed candidates. Implementations | |||
should be aware of the time required to do this, and if the | should be aware of the time required to do this, and if the | |||
application requires a time budget, limit the amount of candidates | application requires a time budget, limit the amount of candidates | |||
which are gathered. | which are gathered. | |||
An Allocate Response will provide the client with a server reflexive | An Allocate Response will provide the agent with a server reflexive | |||
candidate (obtained from the mapped address) and a relayed candidate | candidate (obtained from the mapped address) and a relayed candidate | |||
in the RELAY-ADDRESS attribute. A Binding Response will provide the | in the RELAY-ADDRESS attribute. A Binding Response will provide the | |||
client with a only server reflexive candidate (also obtained from the | agent with only a server reflexive candidate (also obtained from the | |||
mapped address). The base of the server reflexive candidate is the | mapped address). The base of the server reflexive candidate is the | |||
host candidate from which the Allocate or Binding request was sent. | host candidate from which the Allocate or Binding request was sent. | |||
The base of a relayed candidate is that candidate itself. A server | The base of a relayed candidate is that candidate itself. A server | |||
reflexive candidate obtained from an Allocate response is the called | reflexive candidate obtained from an Allocate response is the called | |||
the "translation" of the relayed candidate obtained from the same | the "translation" of the relayed candidate obtained from the same | |||
response. The agent will need to remember the translation for the | response. The agent will need to remember the translation for the | |||
relayed candidate, since it is placed into the SDP. If a relayed | relayed candidate, since it is placed into the SDP. If a relayed | |||
candidate is identical to a host candidate (which can happen in rare | candidate is identical to a host candidate (which can happen in rare | |||
cases), the relayed candidate MUST be discarded. Proper operation of | cases), the relayed candidate MUST be discarded. Proper operation of | |||
ICE depends on each base being unique. | ICE depends on each base being unique. | |||
Next, a full-mode agent eliminates redundant candidates. A candidate | Next, the agent eliminates redundant candidates. A candidate is | |||
is redundant if its transport address equals another candidate, and | redundant if its transport address equals another candidate, and its | |||
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. | |||
Finally, all agents assign 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 they are of the same type | MUST have the same foundation ID when they are of the same type | |||
(host, relayed, server reflexive, peer reflexive or relayed), their | (host, relayed, server reflexive, peer reflexive or relayed), their | |||
bases have the same IP address (the ports can be different), and, for | bases have the same IP address (the ports can be different), and, for | |||
reflexive and relayed candidates, the STUN servers used to obtain | reflexive and relayed candidates, the STUN servers used to obtain | |||
them have the same IP address. Similarly, two candidates MUST have | them have the same IP address. Similarly, two candidates MUST have | |||
different foundations if their types are different, their bases have | different foundations if their types are different, their bases have | |||
different IP addresses, or the STUN servers used to obtain them have | different IP addresses, or the STUN servers used to obtain them have | |||
different IP addresses. | different IP addresses. | |||
5.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. An agent does this by determining a preference for | each candidate. Each candidate for a media stream MUST have a unique | |||
each type of candidate (server reflexive, peer reflexive, relayed and | priority. An agent SHOULD compute the priority by determining a | |||
host), and, when the agent is multihomed, choosing a preference for | preference for each type of candidate (server reflexive, peer | |||
its interfaces. These two preferences are then combined to compute | reflexive, relayed and host), and, when the agent is multihomed, | |||
the priority for a candidate. That priority MUST be computed using | choosing a preference for its interfaces. These two preferences are | |||
the following formula: | then combined to compute the priority for a candidate. That priority | |||
SHOULD be computed using the following formula: | ||||
priority = (2^24)*(type preference) + | priority = (2^24)*(type preference) + | |||
(2^8)*(local preference) + | (2^8)*(local preference) + | |||
(2^0)*(256 - component ID) | (2^0)*(256 - component ID) | |||
The type preference MUST be an integer from 0 to 126 inclusive, and | The type preference MUST be an integer from 0 to 126 inclusive, and | |||
represents the preference for the type of the candidate (where the | represents the preference for the type of the candidate (where the | |||
types are local, server reflexive, peer reflexive and relayed). A | types are local, server reflexive, peer reflexive and relayed). A | |||
126 is the highest preference, and a 0 is the lowest. Setting the | 126 is the highest preference, and a 0 is the lowest. Setting the | |||
value to a 0 means that candidates of this type will only be used as | value to a 0 means that candidates of this type will only be used as | |||
a last resort. The type preference MUST be identical for all | a last resort. The type preference MUST be identical for all | |||
candidates of the same type and MUST be different for candidates of | candidates of the same type and MUST be different for candidates of | |||
different types. The type preference for peer reflexive candidates | different types. The type preference for peer reflexive candidates | |||
MUST be higher than that of server reflexive candidates. Note that | MUST be higher than that of server reflexive candidates. Note that | |||
candidates gathered based on the procedures of Section 5.1 will never | candidates gathered based on the procedures of Section 4.1.1 will | |||
be peer reflexive candidates; candidates of these type are learned | never be peer reflexive candidates; candidates of these type are | |||
from the STUN connectivity checks performed by ICE. The component ID | learned from the STUN connectivity checks performed by ICE. The | |||
is the component ID for the candidate, and MUST be between 1 and 256 | component ID is the component ID for the candidate, and MUST be | |||
inclusive. The local preference MUST be an integer from 0 to 65535 | between 1 and 256 inclusive. The local preference MUST be an integer | |||
inclusive. It represents a preference for the particular interface | from 0 to 65535 inclusive. It represents a preference for the | |||
from which the candidate was obtained, in cases where an agent is | particular interface from which the candidate was obtained, in cases | |||
multihomed. 65535 represents the highest preference, and a zero, the | where an agent is multihomed. 65535 represents the highest | |||
lowest. When there is only a single interface, this value SHOULD be | preference, and a zero, the lowest. When there is only a single | |||
set to 65535. Generally speaking, if there are multiple candidates | interface, this value SHOULD be set to 65535. Generally speaking, if | |||
for a particular component for a particular media stream which have | there are multiple candidates for a particular component for a | |||
the same type, the local preference MUST be unique for each one. In | particular media stream which have the same type, the local | |||
this specification, this only happens for multi-homed hosts. | preference MUST be unique for each one. In this specification, this | |||
only happens for multi-homed hosts. | ||||
These rules guarantee that there is a unique priority for each | These rules guarantee that there is a unique priority for each | |||
candidate. This priority will be used by ICE to determine the order | candidate. This priority will be used by ICE to determine the order | |||
of the connectivity checks and the relative preference for | of the connectivity checks and the relative preference for | |||
candidates. Consequently, what follows are some guidelines for | candidates. Consequently, what follows are some guidelines for | |||
selection of these values. | selection of these values. | |||
One criteria for selection of the type and local preference values is | One criteria for selection of the type and local preference values is | |||
the use of an intermediary. That is, if media is sent to that | the use of an intermediary. That is, if media is sent to that | |||
candidate, will the media first transit an intermediate server before | candidate, will the media first transit an intermediate server before | |||
being received. Relayed candidates are clearly one type of | being received? Relayed candidates are clearly one type of | |||
candidates that involve an intermediary. Another are host candidates | candidates that involve an intermediary. Another are host candidates | |||
obtained from a VPN interface. When media is transited through an | obtained from a VPN interface. When media is transited through an | |||
intermediary, it can increase the latency between transmission and | intermediary, it can increase the latency between transmission and | |||
reception. It can increase the packet losses, because of the | reception. It can increase the packet losses, because of the | |||
additional router hops that may be taken. It may increase the cost | additional router hops that may be taken. It may increase the cost | |||
of providing service, since media will be routed in and right back | of providing service, since media will be routed in and right back | |||
out of an intermediary run by the provider. If these concerns are | out of an intermediary run by the provider. If these concerns are | |||
important, the type preference for relayed candidates can be set | important, the type preference for relayed candidates can be set | |||
lower than the type preference for reflexive and host candidates. | lower than the type preference for reflexive and host candidates. | |||
Indeed, it is RECOMMENDED that in this case, host candidates have a | Indeed, it is RECOMMENDED that in this case, host candidates have a | |||
skipping to change at page 19, line 32 | skipping to change at page 19, line 38 | |||
relayed candidates have a type preference of zero. Furthermore, if | relayed candidates have a type preference of zero. Furthermore, if | |||
an agent is multi-homed and has multiple interfaces, the local | an agent is multi-homed and has multiple interfaces, the local | |||
preference for host candidates from a VPN interface SHOULD have a | preference for host candidates from a VPN interface SHOULD have a | |||
priority of 0. | 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) [22]. It can also help with hosts that have both a native | relay) [23]. It can also help with hosts that have both a native | |||
IPv6 address and a 6to4 address. In such a case, lower local | IPv6 address and a 6to4 address. In such a case, lower 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 | |||
routed over the VPN in order to keep it on the corporate network when | routed over the VPN in order to keep it on the corporate network when | |||
communicating within the enterprise, but use the local network when | communicating within the enterprise, but use the local network when | |||
communicating with users outside of the enterprise. In such a case, | communicating with users outside of the enterprise. In such a case, | |||
a VPN interface would have a higher local preference than any other | a VPN interface would have a higher local preference than any other | |||
interfaces. | interface. | |||
Another criteria for selecting preferences is topological awareness. | Another criteria for selecting preferences is topological awareness. | |||
This is most useful for candidates that make use of relays. In those | This is most useful for candidates that make use of relays. In those | |||
cases, if an agent has preconfigured or dynamically discovered | cases, if an agent has preconfigured or dynamically discovered | |||
knowledge of the topological proximity of the relays to itself, it | knowledge of the topological proximity of the relays to itself, it | |||
can use that to assign higher local preferences to candidates | can use that to assign higher local preferences to candidates | |||
obtained from closer relays. | obtained from closer relays. | |||
5.3. Choosing In-Use Candidates | 4.1.3. Choosing In-Use Candidates | |||
A candidate is said to be "in-use" if it appears in the m/c-line of | A candidate is said to be "in-use" if it appears in the m/c-line of | |||
an offer or answer. When communicating with an ICE peer, being in- | an offer or answer. When communicating with an ICE peer, being in- | |||
use implies that, should these candidates be selected by the ICE | use implies that, should these candidates be selected by the ICE | |||
algorithm, bidirectional media can flow and the candidates can be | algorithm, a re-INVITE will not be required after ICE processing | |||
used. If a candidate is selected by ICE but is not in-use, only | completes. When communicating with a peer that is not ICE-aware, the | |||
unidirectional media can flow and only for a brief time; the | ||||
candidate must be made in-use through an updated offer/answer | ||||
exchange. When communicating with a peer that is not ICE-aware, the | ||||
in-use candidates will be used exclusively for the exchange of media, | in-use candidates will be used exclusively for the exchange of media, | |||
as defined in normal offer/answer procedures. | as defined in normal offer/answer procedures. | |||
An agent MUST choose a set of candidates, one for each component of | An agent MUST choose a set of candidates, one for each component of | |||
each active media stream, to be in-use. A media stream is active if | each active media stream, to be in-use. A media stream is active if | |||
it does not contain the a=inactive SDP attribute. | it does not contain the a=inactive SDP attribute. | |||
It is RECOMMENDED that in-use candidates be chosen based on the | It is RECOMMENDED that in-use 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. Unfortunately, it is difficult to ascertain which | contacted. Unfortunately, it is difficult to ascertain which | |||
skipping to change at page 20, line 39 | skipping to change at page 20, line 42 | |||
enterprise. To reach non-ICE capable agents within the enterprise, | enterprise. To reach non-ICE capable agents within the enterprise, | |||
host candidates have to be used, since the enterprise policies may | host candidates have to be used, since the enterprise policies may | |||
prevent communication between elements using a relay on the public | prevent communication between elements using a relay on the public | |||
network. However, when communicating to peers outside of the | network. However, when communicating to peers outside of the | |||
enterprise, relayed candidates from a publically accessible STUN | enterprise, relayed candidates from a publically accessible STUN | |||
server are needed. | server are needed. | |||
Indeed, the difficulty in picking just one transport address that | Indeed, the difficulty in picking just one transport address that | |||
will work is the whole problem that motivated the development of this | will work is the whole problem that motivated the development of this | |||
specification in the first place. As such, it is RECOMMENDED that | specification in the first place. As such, it is RECOMMENDED that | |||
full mode agents select relayed candidates to be in-use. Passive- | agents select relayed candidates to be in-use. | |||
only agents will, naturally, select their only candidates - the host | ||||
candidates - to be in use. | ||||
5.4. Encoding the SDP | 4.2. Lite Implementation | |||
For each media stream, the agent allocates a single candidate for | ||||
each component of the media stream from one of its interfaces. If an | ||||
agent is multi-homed, it MUST choose one of its interfaces for a | ||||
particular media stream; ICE cannot be used to dynamically choose | ||||
one. 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 a candidate for it. | ||||
Each candidate is assigned a foundation. The foundation MUST be | ||||
different for two candidates from different interfaces (which can | ||||
occur if media streams are on different interfaces), and MUST be the | ||||
same otherwise. A simple integer that increments for each interface | ||||
will suffice. In addition, each candidate MUST be assigned a unique | ||||
priority amongst all candidates for the same media stream. This | ||||
priority SHOULD be equal to 2^24*(126) + 2^8*(65535) + 256 minus the | ||||
component ID, which is 2130706432 minus the component ID. Each of | ||||
these candidates is also considered to be "in-use", since they will | ||||
be included in the m/c-line of an offer or answer. | ||||
4.3. Encoding the SDP | ||||
The process of encoding the SDP is identical between full and lite | ||||
implementations. | ||||
The agent includes a single a=candidate media level attribute in the | The agent includes a single a=candidate media level attribute in the | |||
SDP for each candidate for that media stream. The a=candidate | SDP for each candidate for that media stream. The a=candidate | |||
attribute contains the IP address, port and transport protocol for | attribute contains the IP address, port and transport protocol for | |||
that candidate. A Fully Qualified Domain Name (FQDN) for a host MAY | that candidate. A Fully Qualified Domain Name (FQDN) for a host MAY | |||
be used in place of a unicast address. In that case, when receiving | be used in place of a unicast address. In that case, when receiving | |||
an offer or answer containing an FQDN in an a=candidate attribute, | 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 record, and the | the FQDN is looked up in the DNS using an A or AAAA record, and the | |||
resulting IP address is used for the remainder of ICE processing. | resulting IP address is used for the remainder of ICE processing. | |||
The candidate attribute also includes the component ID for that | The candidate attribute also includes the component ID for that | |||
candidate. For media streams based on RTP, candidates for the actual | candidate. For media streams based on RTP, candidates for the actual | |||
RTP media MUST have a component ID of 1, and candidates for RTCP MUST | RTP media MUST have a component ID of 1, and candidates for RTCP MUST | |||
have a component ID of 2. Other types of media streams which require | have a component ID of 2. Other types of media streams which require | |||
multiple components MUST develop specifications which define the | multiple components MUST develop specifications which define the | |||
mapping of components to component IDs, and these component IDs MUST | mapping of components to component IDs, and these component IDs MUST | |||
be between 1 and 256. | be between 1 and 256. | |||
The candidate attribute also includes the priority, which is the | The candidate attribute also includes the priority and the | |||
value determined for the candidate as described in Section 5.2, and | foundation. The agent SHOULD include a type for each candidate by | |||
the foundation, which is the value determined for the candidate as | populating the candidate-types production with the appropriate value | |||
described in Section 5.1. The agent SHOULD include a type for each | - "host" for host candidates, "srflx" for server reflexive | |||
candidate by populating the candidate-types production with the | candidates, "prflx" for peer reflexive candidates (though these never | |||
appropriate value - "host" for host candidates, "srflx" for server | appear in an initial offer/answer exchange), and "relay" for relayed | |||
reflexive candidates, "prflx" for peer reflexive candidates (though | candidates. The related address MUST NOT be included if a type was | |||
these never appear in an initial offer/answer exchange), and "relay" | not included. If a type was included, the related address SHOULD be | |||
for relayed candidates. The related address MUST NOT be included if | present for server reflexive, peer reflexive and relayed candidates. | |||
a type was not included. If a type was included, the related address | If a candidate is server or peer reflexive, the related address is | |||
SHOULD be present for server reflexive, peer reflexive and relayed | equal to the base for that server or peer reflexive candidate. If | |||
candidates. If a candidate is server or peer reflexive, the related | the candidate is relayed, the related address is equal to the | |||
address is equal to the base for that server or peer reflexive | translation of the relayed address. If the candidiate is a host | |||
candidate. If the candidate is relayed, the related address is equal | candidate, there is no related address and the rel-addr production | |||
to the translation of the relayed address. If the candidiate is a | MUST be omitted. | |||
host candidate, there is no related address and the rel-addr | ||||
production MUST be omitted. | ||||
STUN connectivity checks between agents make use of a short term | STUN connectivity checks between agents make use of a short term | |||
credential that is exchanged in the offer/answer process. The | credential that is exchanged in the offer/answer process. The | |||
username part of this credential is formed by concatenating a | username part of this credential is formed by concatenating a | |||
username fragment from each agent, separated by a colon. Each agent | username fragment from each agent, separated by a colon. Each agent | |||
also provides a password, used to compute the message integrity for | also provides a password, used to compute the message integrity for | |||
requests it receives. As such, an SDP MUST contain the ice-ufrag and | requests it receives. As such, an SDP MUST contain the ice-ufrag and | |||
ice-pwd attributes, containing the username fragment and password | ice-pwd attributes, containing the username fragment and password | |||
respectively. These can be either session or media level attributes, | respectively. These can be either session or media level attributes, | |||
and thus common across all candidates for all media streams, or all | and thus common across all candidates for all media streams, or all | |||
candidates for a particular media stream, respectively. However, if | candidates for a particular media stream, respectively. However, if | |||
two media streams have identical ice-ufrag's, they MUST have | two media streams have identical ice-ufrag's, they MUST have | |||
identical ice-pwd's. The ice-ufrag and ice-pwd attributes MUST be | identical ice-pwd's. The ice-ufrag and ice-pwd attributes MUST be | |||
chosen randomly at the beginning of a session. The ice-ufrag | chosen randomly at the beginning of a session. The ice-ufrag | |||
attribute MUST contain at least 24 bits of randomness, and the ice- | attribute MUST contain at least 24 bits of randomness, and the ice- | |||
pwd attribute MUST contain at least 128 bits of randomness. This | pwd attribute MUST contain at least 128 bits of randomness. This | |||
means that the ice-ufrag attribute will be at least 4 characters | means that the ice-ufrag attribute will be at least 4 characters | |||
long, and the ice-pwd at least 22 characters long, since the grammar | long, and the ice-pwd at least 22 characters long, since the grammar | |||
for these attributes allows for 6 bits of randomness per character. | for these attributes allows for 6 bits of randomness per character. | |||
The attributes MAY be longer than 4 and 21 characters respectively, | The attributes MAY be longer than 4 and 22 characters respectively, | |||
of course. | of course. | |||
If an agent is operating in passive-only mode, it MUST include the | If an agent is a lite implementation, it MUST include an "a=ice-lite" | |||
"a=ice-passive" session level attribute in its offer. If an agent is | session level attribute in its SDP. If an agent is a full | |||
in full mode, it MUST NOT include this attribute. | implementation, it MUST NOT include this attribute. | |||
The m/c-line is populated with the candidates that are in-use. For | The m/c-line is populated with the candidates that are in-use. For | |||
streams based on RTP, this is done by placing the RTP candidate into | streams based on RTP, this is done by placing the RTP candidate into | |||
the m and c lines respectively. If the agent is utilizing RTCP, it | the m and c lines respectively. If the agent is utilizing RTCP, it | |||
MUST encode the RTCP candidate into the m/c-line using the a=rtcp | MUST encode the RTCP candidate into the m/c-line using the a=rtcp | |||
attribute as defined in RFC 3605 [2]. If RTCP is not in use, the | attribute as defined in RFC 3605 [2]. If RTCP is not in use, the | |||
agent MUST signal that using b=RS:0 and b=RR:0 as defined in RFC 3556 | agent MUST signal that using b=RS:0 and b=RR:0 as defined in RFC 3556 | |||
[5]. | [5]. | |||
There MUST be a candidate attribute for each component of the media | There MUST be a candidate attribute for each component of the media | |||
stream in the m/c-line. | stream in the m/c-line. | |||
Once an offer or answer are sent, an agent MUST be prepared to | Once an offer or answer are sent, an agent MUST be prepared to | |||
receive both STUN and media packets on each candidate. As discussed | receive both STUN and media packets on each candidate. As discussed | |||
in Section 12.1, media packets can be sent to a candidate prior to | in Section 11.1, media packets can be sent to a candidate prior to | |||
its appearence in the m/c-line. | its appearence in the m/c-line. | |||
6. Receiving the Initial Offer | 5. Receiving the Initial Offer | |||
When an agent receives an initial offer, it will check if the offeror | When an agent receives an initial offer, it will check if the offeror | |||
supports ICE, determine its role, gather candidates, prioritize them, | supports ICE, determine its role, gather candidates, prioritize them, | |||
choose one for in-use, encode and send an answer, and then form the | choose one for in-use, encode and send an answer, and for full | |||
check lists and begin connectivity checks. | implementations, form the check lists and begin connectivity checks. | |||
6.1. Verifying ICE Support | 5.1. Verifying ICE Support | |||
The answerer will proceed with the ICE procedures defined in this | The answerer will proceed with the ICE procedures defined in this | |||
specification if the following are true: | specification if the following are true: | |||
o There is at least one a=candidate attribute for each media stream | o There is at least one a=candidate attribute for each media stream | |||
in the offer it just received. | in the offer it just received. | |||
o For each media stream, at least one of the candidates is a match | o For each media stream, at least one of the candidates is a match | |||
for its respective in-use component in the m/c-line. | for its respective in-use component in the m/c-line. | |||
If both of these conditions are not met, the agent MUST process the | If both of these conditions are not met, the agent MUST process the | |||
SDP based on normal RFC 3264 procedures, without using any of the ICE | SDP based on normal RFC 3264 procedures, without using any of the ICE | |||
mechanisms described in the remainder of this specification, with the | mechanisms described in the remainder of this specification with two | |||
exception of Section 11, which describes keepalive procedures. | exceptions. First, in all cases, the agent MUST follow the rules of | |||
Section 10, which describe keepalive procedures for all agents. | ||||
Secondly, if the agent is not proceeding with ICE because there were | ||||
a=candidate attributes, but none that matched the m/c-line of the | ||||
media stream, the agent MUST include an a=ice-mismatch attribute in | ||||
its answer. This mismatch occurs in cases where intermediary | ||||
elements modify the m/c-line, but don't modify candidate attributes. | ||||
By including this attribute in the response, diagnostic information | ||||
on the ICE failure is provided to the offeror and any intermediate | ||||
signaling entities. | ||||
In addition, if the offer contains the "a=ice-passive" attribute, and | In addition, if the offer contains the "a=ice-lite" attribute, and | |||
the answerer is also passive-only, the agent MUST process the SDP | the answerer is also lite, the agent MUST process the SDP based on | |||
based on normal RFC 3264 procedures, as if it didn't support ICE, | normal RFC 3264 procedures, as if it didn't support ICE, with the | |||
with the exception of Section 11, which describes keepalive | exception of Section 10, which describes keepalive procedures. | |||
procedures. | ||||
6.2. Determining Role | 5.2. Determining Role | |||
If the agent is in passive-only mode, it assumes the passive role for | For each session, each agent takes on a role. There are two roles - | |||
this session. If the agent is in full-mode, but its peer is in | controlling, and controlled. The controlling agent is responsible | |||
passive-only mode (as indicated by the a=ice-passive attribute in the | for selecting the candidate pairs to be used for each media stream, | |||
SDP), the agent assumes the controlling role for this session. If | and for generating the updated offer based on that selection, when | |||
the agent and its peer are both in full-mode, the agent which | needed. The controlled agent is told which candidate pairs to use | |||
generated the offer which started the ICE processing takes on the | for each media stream, and does not generate an updated offer to | |||
controlling role, and the other takes the passive role. | signal this information in SIP. | |||
If one of the agents is a lite implementation, it MUST assume the | ||||
controlled role, and its peer (which will be full) 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. | ||||
Based on this definition, once roles are determined for a session, | Based on this definition, once roles are determined for a session, | |||
they persist unless ICE is restarted, as discussed below. A restart | they persist unless ICE is restarted, as discussed below. A restart | |||
causes a new selection of roles. | causes a new selection of roles. | |||
6.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 5.1. It is | the process for the offerer as described in Section 4.1.1 for full | |||
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 user acceptance of a session. Such gathering MAY | offer, prior to user acceptance of a session. Such gathering MAY | |||
even be done pre-emptively when an agent starts. | even be done pre-emptively when an agent starts. | |||
6.4. Prioritizing Candidates | 5.4. Prioritizing Candidates | |||
The process for prioritizing candidates at the answerer is identical | The process for prioritizing candidates at the answerer is identical | |||
to the process followed by the offerer, as described in Section 5.2. | to the process followed by the offerer, as described in Section 4.1.2 | |||
for full implementations and Section 4.2 for lite implementations. | ||||
6.5. Choosing In Use Candidates | 5.5. Choosing In Use Candidates | |||
The process for selecting in-use candidates at the answerer is | The process for selecting in-use candidates at the answerer is | |||
identical to the process followed by the offerer, as described in | identical to the process followed by the offerer, as described in | |||
Section 5.3. | Section 4.1.3 for full implementations and Section 4.2 for lite | |||
implementations. | ||||
6.6. Encoding the SDP | 5.6. Encoding the SDP | |||
The process for encoding the SDP at the answerer is identical to the | The process for encoding the SDP at the answerer is identical to the | |||
process followed by the offerer, as described in Section 5.4. | process followed by the offerer, as described in Section 4.3. | |||
6.7. Forming the Check Lists | 5.7. Forming the Check Lists | |||
A full-mode agent MUST form the check lists as described in this | Forming check lists is done only by full implementations. Lite | |||
section. A passive-only agent MAY do so, but there is no need. | implementations MUST skip the steps defined in this section. | |||
There is one check list per in-use media stream resulting from the | There is one check list per in-use media stream resulting from the | |||
offer/answer exchange. A media stream is in-use as long as its port | offer/answer exchange. A media stream is in-use as long as its port | |||
is non-zero (which is used in RFC 3264 to reject a media stream). | is non-zero (which is used in RFC 3264 to reject a media stream). | |||
Consequently, a media stream is in-use even if it is marked as | Consequently, a media stream is in-use even if it is marked as | |||
a=inactive or has a bandwidth value of zero. Each check list is a | a=inactive or has a bandwidth value of zero. Each check list is a | |||
sequence of STUN connectivity checks that are performed by the agent. | sequence of STUN connectivity checks that are performed by the agent. | |||
To form the check list for a media stream, the agent forms candidate | To form the check list for a media stream, the agent forms candidate | |||
pairs, computes a candidate pair priority, orders the pairs by | pairs, computes a candidate pair priority, orders the pairs by | |||
priority, prunes them, and sets their states. These steps are | priority, prunes them, and sets their states. These steps are | |||
described in this section. | described in this section. | |||
First, the agent takes each of its candidates for a media stream | First, the agent takes each of its candidates for a media stream | |||
(called local candidates) and pairs them with the candidates it | (called local candidates) and pairs them with the candidates it | |||
skipping to change at page 24, line 34 | skipping to change at page 25, line 27 | |||
other did not. If this happens, the number of components for that | other did not. If this happens, the number of components for that | |||
media stream is effectively reduced, and considered to be equal to | media stream is effectively reduced, and considered to be equal to | |||
the minimum across both agents of the maximum component ID provided | the minimum across both agents of the maximum component ID provided | |||
by each agent across all components for the media stream. | by each agent across all components for the media stream. | |||
Once the pairs are formed, a candidate pair priority is computed. | Once the pairs are formed, a candidate pair priority is computed. | |||
Let O-P be the priority for the candidate provided by the offerer. | Let O-P be the priority for the candidate provided by the offerer. | |||
Let A-P be the priority for the candidate provided by the answerer. | Let A-P be the priority for the candidate provided by the answerer. | |||
The priority for a pair is computed as: | The priority for a pair is computed as: | |||
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(O-P,A-P) + 2*MAX(O-P,A-P) + (O-P>A-P?1:0) | |||
Where O-P>A-P:1?0 is an expression whose value is 1 if O-P is greater | Where O-P>A-P?1:0 is an expression whose value is 1 if O-P is greater | |||
than A-P, and 0 otherwise. This formula ensures a unique priority | than A-P, and 0 otherwise. This formula ensures a unique priority | |||
for each pair in most cases. One the priority is assigned, the agent | for each pair in most cases. One the priority is assigned, the agent | |||
sorts the candidate pairs in decreasing order of priority. If two | sorts the candidate pairs in decreasing order of priority. If two | |||
pairs have identical priority, the ordering amongst them is | pairs have identical priority, the ordering amongst them is | |||
arbitrary. | arbitrary. | |||
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 | |||
skipping to change at page 26, line 18 | skipping to change at page 27, line 8 | |||
Completed: In this state, the controlling agent has signaled that a | Completed: In this state, the controlling agent has signaled that a | |||
candidate pair has been selected for each component. | candidate pair has been selected for each component. | |||
Consequently, no further ICE checks are performed. | Consequently, no further ICE checks are performed. | |||
When a check list is first constructed as the consequence of an | When a check list is first constructed as the consequence of an | |||
offer/answer exchange, it is placed in the Running state. | offer/answer exchange, it is placed in the Running state. | |||
ICE processing across all media streams also has a state associated | ICE processing across all media streams also has a state associated | |||
with it. This state is equal to Running while checks are in | with it. This state is equal to Running while checks are in | |||
progress. The state is Completed when all checks have been | progress. The state is Completed when all checks have been | |||
completed, Rules for transitioning between states are described | completed. Rules for transitioning between states are described | |||
below. | below. | |||
6.8. Performing Periodic Checks | 5.8. Performing Periodic Checks | |||
Checks are generated only by full implementations. Lite | ||||
implementations MUST skip the steps described in this section. | ||||
An agent performs two types of checks. The first type are periodic | An agent performs two types of checks. The first type are periodic | |||
checks. These checks occur periodically for each media stream, and | checks. These checks occur periodically for each media stream, and | |||
involve choosing the highest priority check in the Waiting state from | involve choosing the highest priority check in the Waiting state from | |||
each check list, and performing it. The other type of check is | each check list, and performing it. The other type of check is | |||
called a triggered check. This is a check that is performed on | called a triggered check. This is a check that is performed on | |||
receipt of a connectivity check from the peer. Full mode agents MUST | receipt of a connectivity check from the peer. This section | |||
generate periodic checks, and all agents MUST generate triggered | describes how periodic checks are performed. | |||
checks. This section describes how periodic checks are performed, | ||||
and thus applies only to full mode agents. | ||||
Once the full-mode agent has computed the check lists as described in | Once the agent has computed the check lists as described in | |||
Section 6.7, it sets a timer for each active check list. The timer | Section 5.7, it sets a timer for each active check list. The timer | |||
fires every Ta/N seconds, where N is the number of active check lists | fires every Ta/N seconds, where N is the number of active check lists | |||
(initially, there is only one active check list). Implementations | (initially, there is only one active check list). Implementations | |||
MAY set the timer to fire less frequently than this. Ta is the same | MAY set the timer to fire less frequently than this. Ta is the same | |||
value used to pace the gathering of candidates, as described in | value used to pace the gathering of candidates, as described in | |||
Section 5.1. The first timer for each active check list fires | Section 4.1.1. The first timer for each active check list fires | |||
immediately, so that the agent performs a connectivity check the | immediately, so that the agent performs a connectivity check the | |||
moment the offer/answer exchange has been done, followed by the next | moment the offer/answer exchange has been done, followed by the next | |||
periodic check Ta seconds later. | periodic check Ta seconds later. | |||
When the timer fires, the full-mode agent MUST find the highest | When the timer fires, the agent MUST find the highest priority check | |||
priority check in that check list that is in the Waiting state. The | in that check list that is in the Waiting state. The agent then | |||
agent then sends a STUN check from the local candidate of that check | sends a STUN check from the local candidate of that check to the | |||
to the remote candidate of that check. The procedures for forming | remote candidate of that check. The procedures for forming the STUN | |||
the STUN request for this purpose are described in Section 8.1.1. If | request for this purpose are described in Section 7.1.1. If none of | |||
none of the checks in that check list are in the Waiting state, but | the checks in that check list are in the Waiting state, but there are | |||
there are checks in the Frozen state, the highest priority check in | checks in the Frozen state, the highest priority check in the Frozen | |||
the Frozen state is moved into the Waiting state, and that check is | state is moved into the Waiting state, and that check is performed. | |||
performed. When a check is performed, its state is set to In- | When a check is performed, its state is set to In-Progress. If there | |||
Progress. If there are no checks in either the Waiting or Frozen | are no checks in either the Waiting or Frozen state, then the timer | |||
state, then the timer for that check list is stopped. | for that check list is stopped. | |||
Performing the connectivity check requires the agent to know the | Performing the connectivity check requires the agent to know the | |||
username fragment for the local and remote candidates, and the | username fragment for the local and remote candidates, and the | |||
password for the remote candidate. For periodic checks, the remote | password for the remote candidate. For periodic checks, the remote | |||
username fragment and password are learned directly from the SDP | username fragment and password are learned directly from the SDP | |||
received from the peer, and the local username fragment is known by | received from the peer, and the local username fragment is known by | |||
the agent. | the agent. | |||
7. 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, forms the check list and begins | supports ICE, determines its role, and for full implementations, | |||
performing periodic checks. | forms the check list and begins performing periodic checks. | |||
7.1. Verifying ICE Support | 6.1. Verifying ICE Support | |||
The answerer will proceed with the ICE procedures defined in this | The answerer will proceed with the ICE procedures defined in this | |||
specification if there is at least one a=candidate attribute for each | specification if there is at least one a=candidate attribute for each | |||
media stream in the answer it just received. If this condition is | media stream in the answer it just received. If this condition is | |||
not met, the agent MUST process the SDP based on normal RFC 3264 | not met, the agent MUST process the SDP based on normal RFC 3264 | |||
procedures, without using any of the ICE mechanisms described in the | procedures, without using any of the ICE mechanisms described in the | |||
remainder of this specification, with the exception of Section 11, | remainder of this specification, with the exception of Section 10, | |||
which describes keepalive procedures. | which describes keepalive procedures. | |||
7.2. Determining Role | In some cases, the answer may omit a=candidate attributes for the | |||
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 | ||||
offerer that the answerer supports ICE, but that ICE processing was | ||||
not used for the session because an intermediary modified the m/c- | ||||
lines without modifying the candidate attributes. See Section 16 for | ||||
a discussion of cases where this can happen. This specification | ||||
provides no guidance on how an agent should proceed in such a failure | ||||
case. | ||||
6.2. Determining Role | ||||
The offerer follows the same procedures described for the answerer in | The offerer follows the same procedures described for the answerer in | |||
Section 6.2. | Section 5.2. | |||
7.3. Forming the Check List | 6.3. Forming the Check List | |||
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 6.7. | Section 5.7. | |||
7.4. Performing Periodic Checks | 6.4. Performing Periodic Checks | |||
The offerer follows the same procedures described for the answerer in | Periodic checks are performed only by full implementations. The | |||
Section 6.8. | offerer follows the same procedures described for the answerer in | |||
Section 5.8. | ||||
8. Connectivity Checks | 7. 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 [11], as opposed | ICE implementations are required to be compliant to [11], as opposed | |||
to the older [13]. | to the older [14]. However, whereas a full implementation will both | |||
generate checks (acting as a STUN client) and receive them (acting as | ||||
a STUN server), a lite implementation will only ever receive checks, | ||||
and thus will only act as a STUN server. | ||||
8.1. Client Procedures | 7.1. Client Procedures | |||
8.1.1. Sending the Request | These procedures define how an agent sends a connectivity check, | |||
whether it is a periodic or a triggered check. These procedures are | ||||
only applicable to full implementations. | ||||
7.1.1. Sending the Request | ||||
The agent acting as the client generates a connectivity check either | The agent acting as the client generates a connectivity check either | |||
periodically, or triggered. In either case, the check is generated | periodically, or triggered. In either case, the check is generated | |||
by sending a Binding Request from a local candidate, to a remote | by sending a Binding Request from a local candidate, to a remote | |||
candidate. The agent must know the username fragment for both | candidate. The agent must know the username fragment for both | |||
candidates and the password for the remote candidate. | candidates and the password for the remote candidate. | |||
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. Rather than being learned from a Shared | short term credential. Rather than being learned from a Shared | |||
Secret request, the short term credential is exchanged in the offer/ | Secret request, the short term credential is exchanged in the offer/ | |||
skipping to change at page 28, line 32 | skipping to change at page 29, line 40 | |||
colon (":"). The password is equal to the password provided by the | colon (":"). The password is equal to the password provided by the | |||
peer. For example, consider the case where agent A is the offerer, | peer. For example, consider the case where agent A is the offerer, | |||
and agent B is the answerer. Agent A included a username fragment of | and agent B is the answerer. Agent A included a username fragment of | |||
AFRAG for its candidates, and a password of APASS. Agent B provided | AFRAG for its candidates, and a password of APASS. Agent B provided | |||
a username fragment of BFRAG and a password of BPASS. A connectivity | a username fragment of BFRAG and a password of BPASS. A connectivity | |||
check from A to B (and its response of course) utilize the username | check from A to B (and its response of course) utilize the username | |||
BFRAG:AFRAG and a password of BPASS. A connectivity check from B to | BFRAG:AFRAG and a password of BPASS. A connectivity check from B to | |||
A (and its response) utilize the username AFRAG:BFRAG and a password | A (and its response) utilize the username AFRAG:BFRAG and a password | |||
of APASS. | of APASS. | |||
A full-mode agent MUST include the PRIORITY attribute in its Binding | An agent MUST include the PRIORITY attribute in its Binding Request. | |||
Request. This attribute MAY be omitted for passive-only agents. The | The attribute MUST be set equal to the priority that would be | |||
attribute MUST be set equal to the priority that would be assigned, | assigned, based on the algorithm in Section 4.1.2, to a peer | |||
based on the algorithm in Section 5.2, to a peer reflexive candidate | reflexive candidate learned from this check. Such a peer reflexive | |||
learned from this check. Such a peer reflexive candidate has a | candidate has a stream ID, component ID and local preference that are | |||
stream ID, component ID and local preference that are equal to the | equal to the host candidate from which the check is being sent, but a | |||
host candidate from which the check is being sent, but a type | type preference equal to the value associated with peer reflexive | |||
preference equal to the value associated with peer reflexive | ||||
candidates. | candidates. | |||
The Binding Request by an agent MUST include the USERNAME and | The Binding Request sent by an agent MUST include the USERNAME and | |||
MESSAGE-INTEGRITY attributes. That is, an agent MUST NOT wait to be | MESSAGE-INTEGRITY attributes. That is, 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 the Binding Request right away. | in the Binding Request right away. | |||
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 passive 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 9 provides | resulting from the check for this component. Section 8 provides | |||
guidance on determining when to include it. | guidance on determining when to include it. | |||
If the agent is using Diffserv Codepoint markings [25] in its media | If the agent is using Diffserv Codepoint markings [26] 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. | |||
8.1.2. Processing the Response | 7.1.2. Processing the Response | |||
If the STUN transaction generates an unrecoverable failure response | If the STUN transaction generates an unrecoverable failure response | |||
or times out, a full-mode agent sets the state of the check to Failed | or times out, the agent sets the state of the check to Failed. The | |||
(passive-only agents do not maintain the state machinery). The | ||||
remainder of this section applies to processing of successful | remainder of this section applies to processing of successful | |||
responses (any response from 200 to 299). | responses (any response from 200 to 299). | |||
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. If these do not match, the processing | Request was sent from. If these do not match, the processing | |||
described in the remainder of this section MUST NOT be performed. In | described in the remainder of this section MUST NOT be performed. In | |||
addition, a full-mode agent sets the state of the check to Failed. | addition, an agent sets the state of the check to Failed. | |||
If the check succeeds, processing continues. The agent creates a | If the check succeeds, processing continues. The agent creates a | |||
candidate pair whose local candidate equals the mapped address of the | candidate pair whose local candidate equals the mapped address of the | |||
response, and whose remote candidate equals the destination address | response, and whose remote candidate equals the destination address | |||
to which the request was sent. This is called a validated pair, | to which the request was sent. This is called a validated pair, | |||
since it has been validated by a STUN connectivity check. It is very | since it has been validated by a STUN connectivity check. It is very | |||
important to note that this validated pair will often not be | important to note that this validated pair will often not be | |||
identical to the check itself; in many cases, the local candidate | identical to the check itself; in many cases, the local candidate | |||
(learned through the mapped address in the response) will be | (learned through the mapped address in the response) will be | |||
different than the local candidate the request was sent from. | different than the local candidate the request was sent from. | |||
Next, the agent computes the priority for the pair based on the | Next, the agent computes the priority for the pair based on the | |||
priority of each candidate, using the algorithm in Section 6.7. For | priority of each candidate, using the algorithm in Section 5.7. The | |||
a passive-only agent, the priority of the local candidate is the one | priority of the local candidate depends on its type. If it is not | |||
it signaled for the candidate in its SDP, and the priority of the | peer reflexive, it is equal to the priority signaled for that | |||
remote candidate is known either from the SDP, or if not there, from | candidate in the SDP. If it is peer reflexive, it is equal to the | |||
the value of the PRIORITY attribute in the Binding Request which | PRIORITY attribute the agent placed in the Binding Request which just | |||
triggered the check that just completed. For a full-mode agent, if | completed. The priority of the remote candidate is taken from the | |||
the local candidate was not one it signaled in its SDP, the priority | SDP of the peer. If the candidate does not appear there, then the | |||
of the local candidate might additionally be equal to the PRIORITY | check must have been a triggered check to a new remote candidate. In | |||
attribute the agent placed in the Binding Request which just | that case, the priority is taken as the value of the PRIORITY | |||
attribute in the Binding Request which triggered the check that just | ||||
completed. | completed. | |||
Once the priority of the candidate pair has been computed, the pair | Once the priority of the candidate pair has been computed, the pair | |||
is added to the valid list for that media stream. If the response is | is added to the valid list for that media stream. If the agent was a | |||
a consequence of a triggered check, and the request which caused the | controlling agent, and the check had included a USE-CANDIDATE | |||
triggered check included the USE-CANDIDATE attribute, the candidate | attribute, the candidate pair is marked as "favored". If the agent | |||
pair is additionally marked as selected. If a full-mode agent had | was a controlled agent, and the check was a triggered check, and the | |||
included the USE-CANDIDATE attribute in the request that produced the | request which caused the triggered check included the USE-CANDIDATE | |||
success response, the agent marks the candidate pair as selected. | attribute, the candidate pair is marked as "favored". | |||
Next, a full-mode agent updates its ICE states. The full-mode agent | Next, the agent updates its ICE states. The agent checks the mapped | |||
checks the mapped address from the STUN response. If the transport | address from the STUN response. If the transport address does not | |||
address does not match any of the local candidates that the agent | match any of the local candidates that the agent knows about, the | |||
knows about, the mapped address representes a new peer reflexive | mapped address represents a new peer reflexive candidate. Its type | |||
candidate. Its type is equal to peer reflexive. Its base is set | is equal to peer reflexive. Its base is set equal to the candidate | |||
equal to the candidate from which the STUN check was sent. Its | from which the STUN check was sent. Its username fragment and | |||
username fragment and password are identical to the candidate from | password are identical to the candidate from which the check was | |||
which the check was sent. It is assigned the priority value that was | sent. It is assigned the priority value that was placed in the | |||
placed in the PRIORITY attribute of the request. Its foundation is | PRIORITY attribute of the request. Its foundation is selected as | |||
selected as described in Section 5.1. The peer reflexive candidate | described in Section 4.1.1. The peer reflexive candidate is then | |||
is then added to the list of local candidates known by the agent | added to the list of local candidates known by the agent (though it | |||
(though it is not paired with other remote candidates at this time). | is not paired with other remote candidates at this time). | |||
Next, the full-mode agent changes the state for this check to | Next, the agent changes the state for this check to Succeeded. The | |||
Succeeded. The full-mode agent sees if the success of this check can | agent sees if the success of this check can cause other checks to be | |||
cause other checks to be unfrozen. If the check had a component ID | unfrozen. If the check had a component ID of one, the agent MUST | |||
of one, the full-mode agent MUST change the states for all other | change the states for all other Frozen checks for the same media | |||
Frozen checks for the same media stream and same foundation, but | stream and same foundation, but different component IDs, to Waiting. | |||
different component IDs, to Waiting. If the component ID for the | If the component ID for the check was equal to the number of | |||
check was equal to the number of components for the media stream, the | components for the media stream (where this is the actual number of | |||
full-mode agent MUST change the state for all other Frozen checks for | components being used, in cases where the number of components | |||
the first component of different media streams (and thus in different | signaled in the SDP differs from offerer to answerer), the agent MUST | |||
check lists) but the same foundation, to Waiting. | change the state for all other Frozen checks for the first component | |||
of different media streams (and thus in different check lists) but | ||||
the same foundation, to Waiting. | ||||
8.2. Server Procedures | 7.2. Server Procedures | |||
An agent MUST be prepared to receive a Binding Request on the base of | An agent MUST be prepared to receive a Binding Request on the base of | |||
each candidate it included in its most recent offer or answer. | each candidate it included in its most recent offer or answer. | |||
Receipt of a Binding Request on a transport address that the agent | Receipt of a Binding Request on a transport address that the agent | |||
had included in a candidate attribute is an indication that the | had included in a candidate attribute is an indication that the | |||
connectivity check usage applies to the request. | connectivity check usage applies to the request. | |||
The agent MUST use a short term credential to authenticate the | The agent MUST use a short term credential to authenticate the | |||
request and perform a message integrity check. The agent MUST accept | request and perform a message integrity check. The agent MUST accept | |||
a credential if the username consists of two values separated by a | a credential if the username consists of two values separated by a | |||
colon, where the first value is equal to the username fragment | colon, where the first value is equal to the username fragment | |||
generated by the agent in an offer or answer for a session in- | generated by the agent in an offer or answer for a session in- | |||
progress, and the password is equal to the password for that username | progress, and the password is equal to the password for that username | |||
fragment. It is possible (and in fact very likely) that an offeror | fragment. It is possible (and in fact very likely) that an offeror | |||
will receive a Binding Request prior to receiving the answer from its | will receive a Binding Request prior to receiving the answer from its | |||
peer. However, the request can be processed without receiving this | peer. However, the request can be processed without receiving this | |||
answer, and a response generated. | answer, and a response generated. | |||
If the agent is using Diffserv Codepoint markings [26] in its media | ||||
packets, it SHOULD apply those same markings to its responses to | ||||
Binding Requests. | ||||
7.2.1. Additional Procedures for Full Implementations | ||||
This subsection defines the additional server procedures applicable | ||||
to full implementations. | ||||
For requests being received on a relayed candidate, the source | For requests being received on a relayed candidate, the source | |||
transport address used for STUN processing (namely, generation of the | transport address used for STUN processing (namely, generation of the | |||
XOR-MAPPED-ADDRESS attribute) is the transport address as seen by the | XOR-MAPPED-ADDRESS attribute) is the transport address as seen by the | |||
relay. That source transport address will be present in the REMOTE- | relay. That source transport address will be present in the REMOTE- | |||
ADDRESS attribute of a STUN Data Indication message, if the Binding | ADDRESS attribute of a STUN Data Indication message, if the Binding | |||
Request was delivered through a Data Indication. If the Binding | Request was delivered through a Data Indication. If the Binding | |||
Request was not encapsulated in a Data Indication, that source | Request was not encapsulated in a Data Indication, that source | |||
address is equal to the current active destination for the STUN relay | address is equal to the current active destination for the STUN relay | |||
session. | session. | |||
If the agent is using Diffserv Codepoint markings [25] in its media | ||||
packets, it SHOULD apply those same markings to its responses to | ||||
Binding Requests. | ||||
If the STUN request resulted in an error response, no further | If the STUN request resulted in an error response, no further | |||
processing is performed. | processing is performed. | |||
Otherwise, the agent MUST generate a triggered check in the reverse | Assuming a success response, if the source transport address of the | |||
directon if it has not already sent such a check. The triggered | request does not match any existing remote candidates, it represents | |||
check has a local candidate equal to the candidate on which the STUN | a new peer reflexive remote candidate. The full-mode agent gives the | |||
request was received, and a remote candidate equal to the source | candidate a priority equal to the PRIORITY attribute from the | |||
transport address where the request came from (which may not be | request. The type of the candidate is equal to peer reflexive. Its | |||
amongst the candidates signaled previously from the peer in its SDP). | foundation is set to an arbitrary value, different from the | |||
The username fragment and password of the peer are readily determined | foundation for all other remote candidates. Note that any subsequent | |||
from the SDP and from the check that was just received. The username | offer/answer exchanges will contain this new peer reflexive candidate | |||
fragment for this candidate is equal to the bottom half (the part | in the SDP, and will signal the actual foundation for the candidate. | |||
after the colon) of the USERNAME in the Binding Request that was just | This candidate is then added to the list of remote candidates. | |||
received. Using that username fragment, the agent can check the SDP | However, the agent does not pair this candidate with any local | |||
messages received from its peer (there may be more than one in cases | candidates. | |||
of forking), and find this username fragment. The corresponding | ||||
password is then selected. If agent has not yet received this SDP (a | ||||
likely case for the offerer in the initial offer/answer exchange), it | ||||
MUST wait for the SDP to be received, and then proceed with the | ||||
triggered check and the rest of the processing described in the | ||||
remainder of this section. | ||||
The remainder of the processing in this section applies to state | Next, the agent constructs a tentative check in the reverse | |||
updates performed by full-mode agents. | direction, called a triggered check. The triggered check has a local | |||
candidate equal to the candidate on which the STUN request was | ||||
received, and a remote candidate equal to the source transport | ||||
address where the request came from (which may be a new peer- | ||||
reflexive remote candidate). Since both candidates are known to the | ||||
agent, it can obtain their priorities and compute the candidate pair | ||||
priority. This tentative check is then looked up in the check list. | ||||
There can be one of several outcomes: | ||||
If the source transport address of the request does not match any | o If there is already a check on the check list with this same local | |||
existing remote candidates, it represents a new peer reflexive remote | and remote candidates, and the state of that check is Waiting or | |||
candidate. The full-mode agent gives the candidate a priority equal | Frozen, its state is changed to In-Progress and the tentative | |||
to the PRIORITY attribute from the request. The type of the | check is performed. | |||
candidate is equal to peer reflexive. Its foundation is set to an | ||||
arbitrary value, different from the foundation for all other remote | ||||
candidates. This candidate is then added to the list of remote | ||||
candidates. However, the full-mode agent does not pair this | ||||
candidate with any local candidates. | ||||
A full-mode agent knows the priorities for the local and remote | o If there is already a check on the check list with this same local | |||
candidates of the triggered check described above, and so can compute | and remote candidates, and its state was In-Progress, the agent | |||
the priority for the check itself. If there is already a check on | SHOULD abandon the new tentative check and instead generate an | |||
the check list with this same local and remote candidates, and the | immediate retransmit of the Binding Request for the check in | |||
state of that check is Waiting or Frozen, its state is changed to In- | progress. This is to facilitate rapid completion of ICE when both | |||
Progress. If there was already a check on the check list with this | agents are behind NAT. | |||
same local and remote candidates, and its state was In-Progress, the | ||||
agent SHOULD generate an immediate retransmit of the Binding Request. | ||||
This is to facilitate rapid completion of ICE when both agents are | ||||
behind NAT. If there was a check in the list already and its state | ||||
was Succeeded, and the Binding Request just received contained the | ||||
USE-CANDIDATE attribute, it means that the pair resulting from that | ||||
previous check has been selected. The agent MUST take the candidate | ||||
pair in the valid list that was learned from that previous successful | ||||
check, and mark it as selected. If there was a check on the check | ||||
list with this same local and remote candidates, and its state was | ||||
Failed, nothing further is done. If there was no matching check on | ||||
the check list, it is inserted into the check list based on its | ||||
priority, and its state is set to In-Progress. | ||||
9. Concluding ICE | o If there is already a check on the check list with this same local | |||
and remote candidates, and its state was Succeeded, the new | ||||
tentative check is abandoned. If the Binding Request just | ||||
received contained the USE-CANDIDATE attribute, it means that the | ||||
pair resulting from that previous check is favored by the peer | ||||
controlling agent. The agent MUST take the candidate pair in the | ||||
valid list that was learned from that previous successful check, | ||||
and mark it as favored. | ||||
o If there is already a check on the check list with this same local | ||||
and remote candidates, and its state was Failed, the new tentative | ||||
check is abandoned. | ||||
o If there is no matching check on the check list, the new tentative | ||||
check is inserted into the check list based on its priority, and | ||||
its state is set to In-Progress. | ||||
If the tentative check is to be performed, it is constructed and | ||||
processed as described in Section 7.1.1. These procedures require | ||||
the agent to know the username fragment and password for the peer. | ||||
They are readily determined from the SDP and from the check that was | ||||
just received. The username fragment for the remote candidate is | ||||
equal to the bottom half (the part after the colon) of the USERNAME | ||||
in the Binding Request that was just received. Using that username | ||||
fragment, the agent can check the SDP messages received from its peer | ||||
(there may be more than one in cases of forking), and find this | ||||
username fragment. The corresponding password is then selected. If | ||||
agent has not yet received this SDP (a likely case for the offerer in | ||||
the initial offer/answer exchange), it MUST wait for the SDP to be | ||||
received, and then proceed with the triggered check. | ||||
7.2.2. Additional Procedures for Lite Implementations | ||||
If the check that was just received contained a USE-CANDIDATE | ||||
attribute, the agent constructs a candidate pair whose local | ||||
candidate is equal to the transport address on which the request was | ||||
received, and whose remote candidate is equal to the source transport | ||||
address of the request that was received. This candidate pair is | ||||
assigned an arbitrary priority, and placed into a list of valid | ||||
candidates for that component of that media stream called the valid | ||||
list. In addition, it is marked as favored, since the peer agent has | ||||
indicated that it is to be used. ICE processing is considered | ||||
complete for a media stream if the valid list contains a candidate | ||||
pair for each component. | ||||
8. Concluding ICE | ||||
The processing rules in this section apply only to full | ||||
implementations. | ||||
Concluding ICE involves selection of pairs by the controlling agent, | Concluding ICE involves selection of pairs by the controlling agent, | |||
updating of state machinery by full-mode agents, and possibly the | updating of state machinery, and possibly the generation of an | |||
generation of an updated offer by the controlling agent. Since a | updated offer by the controlling agent. | |||
passive-only agent can never be in the controlling role, the | ||||
processing in this section only applies to full-mode agents. | ||||
The controlling agent can use any algorithm it likes for deciding | The controlling agent can use any algorithm it likes for deciding | |||
when to select a candidate pair. However, it MUST eventually include | when to select a candidate pair, called the favored pair, as the one | |||
a USE-CANDIDATE attribute in a check for each component of each media | that will be used for media. However, it MUST eventually include a | |||
stream. The following trivial algorithm chooses the first candidate | USE-CANDIDATE attribute in at least one successful check for each | |||
pair that validates for each media stream: the controlling agent | component of each media stream. | |||
includes the USE-CANDIDATE attribute in every check it sends. | ||||
Once a candidate pair in the Valid list is marked as selected, a | The most apparent way to utilize the USE-CANDIDATE attribute is to | |||
full-mode agent MUST NOT generate any further periodic checks for | run through a series of checks, each of which omit the flag. Once | |||
that component of that media stream, and SHOULD cease any | one or more checks complete successfully for a component of a media | |||
retransmissions in progress for checks for that component of that | stream, the agent evaluates the choices based on some criteria, and | |||
media stream. Once there is at least one candidate pair for each | picks a candidate pair. The criteria for evaluation is a matter of | |||
component of a media stream that is marked as selected, a full-mode | implementation and it allows for localized optimizations. The check | |||
agent MUST change the state of processing for its check list to | that yielded this pair is then repeated, this time with the USE- | |||
Completed. Once all of the media streams enter the Completed state, | CANDIDATE flag. This approach provides the most flexibility in terms | |||
the controlling agent takes the highest priority candidate pair for | of algorithms, and also improves ICE's resilience to variations in | |||
each component of each media stream which has been marked as | implementation (see Section 14. This approach is called | |||
selected. If any of those candidate pairs differ from the in-use | "introspective selection". The drawback of introspective selection | |||
candidates in m/c-lines of the most recent offer/answer exchange, the | is that it is guaranteed to increase latencies because it requires an | |||
controlling agent MUST generate an updated offer as described in | additional check to be done. | |||
Section 10. | ||||
10. Subsequent Offer/Answer Exchanges | An alternative is called "proactive selection". In this approach, | |||
the controlling agent includes the USE-CANDIDATE attribute in every | ||||
check it sends. Once the first check for a component succeeds, it is | ||||
used by ICE. In this mode, the agent will end up using the candidate | ||||
pair which is highest priority based on ICE's prioritization | ||||
algorithm, instead of some other local optimization. It is possible | ||||
with proactive selection that multiple checks might succeed with the | ||||
flag set; this is why ICE still applies its prioritization algorithm | ||||
to pick amongst those pairs that have been favored. | ||||
If an agent is controlling and its peer has a lite implementation, an | ||||
agent MUST use an introspective selection algorithm. Of course, it | ||||
MAY select a favored pair based on ICE's prioritization. The key | ||||
requirement is that the agent must complete a successful check before | ||||
redoing it with the USE-CANDIDATE attribute. | ||||
For both controlling and controlled agents, once a candidate pair in | ||||
the Valid list is marked as favored, an agent MUST NOT generate any | ||||
further periodic checks for that component of that media stream, and | ||||
SHOULD cease any retransmissions in progress for checks for that | ||||
component of that media stream. Once there is at least one candidate | ||||
pair for each component of a media stream that is favored, a full- | ||||
mode agent MUST change the state of processing for its check list to | ||||
Completed. Once all of the check lists for the media streams enter | ||||
the Completed state, the controlling agent takes the highest priority | ||||
favored candidate pair for each component of each media stream. If | ||||
any of those candidate pairs differ from the in-use candidates in | ||||
m/c-lines of the most recent offer/answer exchange, the controlling | ||||
agent MUST generate an updated offer as described in Section 9. | ||||
9. Subsequent Offer/Answer Exchanges | ||||
An agent MAY generate a subsequent offer at any time. However, the | An agent MAY generate a subsequent offer at any time. However, the | |||
rules in Section 9 will cause the controlling agent to send an | rules in Section 8 will cause the controlling agent to send an | |||
updated offer at the conclusion of ICE processing when ICE has | updated offer at the conclusion of ICE processing when ICE has | |||
selected different candidate pairs from the in-use pairs. | selected different candidate pairs from the in-use pairs. This | |||
section defines rules for construction of subsequent offers and | ||||
answers. | ||||
10.1. Generating the Offer | 9.1. Generating the Offer | |||
An agent MAY change the ice-pwd and/or ice-ufrag for a media stream | An agent MAY change the ice-pwd and/or ice-ufrag for a media stream | |||
in an offer. Doing so is a signal to restart ICE processing for that | in an offer. Doing so is a signal to restart ICE processing for that | |||
media stream. When an agent restarts ICE for a media stream, it MUST | media stream. When an agent restarts ICE for a media stream, it MUST | |||
NOT include the a=remote-candidates attribute, since the state of the | NOT include the a=remote-candidates attribute, since the state of the | |||
media stream would not be Completed at this point. Note that it is | media stream would not be Completed at this point. Note that it is | |||
permissible to use a session-level attribute in one offer, but to | permissible to use a session-level attribute in one offer, but to | |||
provide the same password as a media-level attribute in a subsequent | provide the same password as a media-level attribute in a subsequent | |||
offer. This is not a change in password, just a change in its | offer. This is not a change in password, just a change in its | |||
representation. | representation. | |||
skipping to change at page 33, line 39 | skipping to change at page 36, line 18 | |||
had ICE not been in use, would result in a new value for the | had ICE not been in use, would result in a new value for the | |||
transport address in the m/c-line, the agent MUST restart ICE for | transport address in the m/c-line, the agent MUST restart ICE for | |||
that media stream. This implies that setting the IP address in the c | that media stream. This implies that setting the IP address in the c | |||
line to 0.0.0.0 will cause an ICE restart. Consequently, ICE | line to 0.0.0.0 will cause an ICE restart. Consequently, ICE | |||
implementations SHOULD NOT utilize this mechanism for call hold, and | implementations SHOULD NOT utilize this mechanism for call hold, and | |||
instead use a=inactive as described in [4] | instead use a=inactive as described in [4] | |||
If an agent removes a media stream by setting its port to zero, it | If an agent removes a media stream by setting its port to zero, it | |||
MUST NOT include any candidate attributes for that media stream. | MUST NOT include any candidate attributes for that media stream. | |||
When a full-mode agent generates an updated offer, the set of | An agent MUST NOT signal a change in its implementation level (full | |||
candidate attributes to include for each media stream depend on the | or lite) by adding or removing the a=ice-lite attribute from an | |||
state of ICE processing for that media stream. If the processing for | updated offer, unless ICE processing is being restarted for all media | |||
that media stream is in the Completed state, a full-mode agent MUST | streams in the offer. Of course, in normal cases the implementation | |||
level is not dynamic and there would be no need to signal a change. | ||||
However, in applications like third party call control, which involve | ||||
a mid-session change in remote correspondent, this can happen and it | ||||
is permitted by ICE with a restart. | ||||
Note that an agent can add a new media stream at any time, even if | ||||
ICE has long finished for the existing media streams. Based on the | ||||
rules described here, checks will begin for this new stream as if it | ||||
was in an initial offer. | ||||
9.1.1. Additional Procedures for Full Implementations | ||||
This section describes additional procedures for full | ||||
implementations. | ||||
When an agent generates an updated offer, the set of candidate | ||||
attributes to include for each media stream depend on the state of | ||||
ICE processing for that media stream. If the processing for that | ||||
media stream is in the Completed state, a full-mode agent MUST | ||||
include a candidate attribute for the local candidate of each pair | include a candidate attribute for the local candidate of each pair | |||
that has been chosen for use by ICE for that media stream. A pair is | that has been chosen for use by ICE for that media stream. A pair is | |||
chosen if it is the highest priority selected pair in the valid list | chosen if it is the highest priority favored pair in the valid list | |||
for a component of that media stream. A full-mode agent SHOULD NOT | for a component of that media stream. An agent SHOULD NOT include | |||
include any other candidate attributes for that media stream. If ICE | any other candidate attributes for that media stream. If ICE | |||
processing for a media stream is in the Running state, the agent MUST | processing for a media stream is in the Running state, the agent MUST | |||
include all current candidates (including peer reflexive candidates | include all current candidates (including peer reflexive candidates | |||
learned through ICE processing) for that media stream. It MAY | learned through ICE processing) for that media stream. It MAY | |||
include candidates it did not offer previously, but which it has | include candidates it did not offer previously, but which it has | |||
gathered since the last offer/answer exchange. If a media stream is | gathered since the last offer/answer exchange. If a media stream is | |||
new or ICE checks are restarting for that stream, a full-mode agent | new or ICE checks are restarting for that stream, an agent includes | |||
includes the set of candidates it wishes to utilize. This MAY | the set of candidates it wishes to utilize. This MAY include some, | |||
include some, none, or all of the previous candidates for that stream | none, or all of the previous candidates for that stream in the case | |||
in the case of a restart, and MAY include a totally new set of | of a restart, and MAY include a totally new set of candidates | |||
candidates gathered as described in Section 5.1. | gathered as described in Section 4.1.1. | |||
A passive-only agent includes its one and only candidate for each | ||||
component of each media stream in an a=candidate attribute in any | ||||
subsequent offer. | ||||
If a candidate was sent in a previous offer/answer exchange, it | If a candidate was sent in a previous offer/answer exchange, it | |||
SHOULD have the same priority. For a peer reflexive candidate, the | SHOULD have the same priority. For a peer reflexive candidate, the | |||
priority SHOULD be the same as determined by the processing in | priority SHOULD be the same as determined by the processing in | |||
Section 8.1.2. The foundation SHOULD be the same. The username | Section 7.1.2. The foundation SHOULD be the same. The username | |||
fragments and passwords for a media stream SHOULD remain the same as | fragments and passwords for a media stream SHOULD remain the same as | |||
the previous offer or answer. | the previous offer or answer. | |||
Population of the m/c-lines for full-mode agents also depends on the | Population of the m/c-lines also depends on the state of ICE | |||
state of ICE processing. If ICE processing for a media stream is in | processing. If ICE processing for a media stream is in the Completed | |||
the Completed state, the m/c-line MUST use the local candidate from | state, the m/c-line MUST use the local candidate from the highest | |||
the highest priority selected pair in the valid list for each | priority favored pair in the valid list for each component of that | |||
component of that media stream. If ICE processing is in the Running | media stream. If ICE processing is in the Running state, a full-mode | |||
state, a full-mode agent SHOULD populate the m/c-line for that media | agent SHOULD populate the m/c-line for that media stream based on the | |||
stream based on the considerations in Section 5.3. | considerations in Section 4.1.3. | |||
A passive agent populates the m/c-lines with its one and only one | ||||
candidate for each component of each media stream. | ||||
In addition, the controlling agent MUST include the a=remote- | In addition, if the agent is controlling, it MUST include the | |||
candidates attribute for each media stream that is in the Completed | a=remote-candidates attribute for each media stream that is in the | |||
state. The attribute contains the remote candidates from the highest | Completed state. The attribute contains the remote candidates from | |||
priority selected pair in the valid list for each component of that | the highest priority favored pair in the valid list for each | |||
media stream. | component of that media stream. | |||
An agent MUST NOT change its mode (passive-only or full) by adding or | 9.1.2. Additional Procedures for Lite Implementations | |||
removing the a=ice-passive attribute from an updated offer, unless | ||||
ICE processing is being restarted for all media streams in the offer. | ||||
Note that an agent can add a new media stream at any time, even if | A passive-only agent includes its one and only candidate for each | |||
ICE has long finished for the existing media streams. Based on the | component of each media stream in an a=candidate attribute in any | |||
rules described here, checks will begin for this new stream as if it | subsequent offer. This candidate is formed identically to the | |||
was in an initial offer. | procedures for initial offers, as described in Section 4.2. | |||
10.2. Receiving the Offer and Generating an Answer | 9.2. Receiving the Offer and Generating an Answer | |||
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 6.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. | |||
If the offer contained a change in the a=ice-ufrag or a=ice-pwd | ||||
attributes compared to the previous SDP from the peer, it is a signal | ||||
that ICE is restarting for this media stream. If all media streams | ||||
are restarting, than ICE is restarting overall. Procedures for ICE | ||||
restarts are discussed below. Unless ICE is restarting for that | ||||
media stream, an agent MUST NOT change the a=ice-ufrag or a=ice-pwd | ||||
attributes in an answer relative to the last SDP it provided. Such a | ||||
change can only take place in an offer. If ICE is restarting, the | ||||
a=ice-ufrag and a=ice-pwd attributes MUST be changed. | ||||
An agent MUST NOT change its implementation level from its previous | ||||
SDP unless, based on the offer, ICE procedures are being restarted | ||||
for all media streams in the offer. In that case, it MAY change its | ||||
level. | ||||
An agent MUST NOT include the a=remote-candidates attribute in an | ||||
answer. | ||||
When the answerer generates its answer, it must decide what | When the answerer generates its answer, it must decide what | |||
candidates to include in the answer, how to populate the m/c-line, | candidates to include in the answer, how to populate the m/c-line, | |||
and how to adjust the states of ICE processing. | and how to adjust the states of ICE processing. The rules for | |||
inclusion of candidate attributes in an answer are identical to the | ||||
rules followed by the offerer as described in Section 9.1 for both | ||||
full and lite implementations. For lite implementations, those rules | ||||
also apply for setting the m/c-line. However, additional | ||||
considerations apply to full implementations. | ||||
The rules for inclusion of candidate attributes in an answer are | 9.2.1. Additional Procedures for Full Implementations | |||
identical to the rules followed by the offerer as described in | ||||
Section 10.1. | ||||
However, the rules for setting the contents of the m/c-line are | The computation of the m/c-line additionally depends on the presence | |||
different. For a full-mode agent, processing of the offer depends on | or absence of the a=remote-candidates attribute in a media stream. | |||
the presence or absence of the a=remote-candidates attribute in a | If present, it means that the offerer (acting as the controlling | |||
media stream. If present, it means that the offerer (acting as the | agent) believed that ICE processing has completed for that media | |||
controlling agent) believed that ICE processing has completed for | stream. In this case, the remote-candidates attribute contains the | |||
that media stream. In this case, the remote-candidates attribute | candidates that the answerer is supposed to use. It is possible that | |||
contains the candidates that the answerer is supposed to use. It is | the agent doesn't even know of these candidates yet; they will be | |||
possible that the agent doesn't even know of these candidates yet; | discovered shortly through a response to an in-progress check. The | |||
they will be discovered shortly through a response to an in-progress | full-mode agent MUST populate the m/c-line with the candidates from | |||
check. The full-mode agent MUST populate the m/c-line with the | the a=remote-candidates attribute. | |||
candidates from the a=remote-candidates attribute. | ||||
If the offer did not contain the a=remote-candidates attribute, or | If the offer did not contain the a=remote-candidates attribute, the | |||
the agent is a passive-only agent, the agent follows the same | agent follows the same procedures for populating the m/c-line as | |||
procedures for populating the m/c-line as described for the offerer | described for the offerer in Section 9.1. | |||
in Section 10.1. | ||||
An agent MUST NOT include the a=remote-candidates attribute in an | 9.3. Updating the Check and Valid Lists | |||
answer. An agent MUST NOT change the a=ice-ufrag or a=ice-pwd | ||||
attributes in an answer relative to the last SDP it provided. Such a | ||||
change can only take place in an offer. However, if the offer | ||||
contained a change in the a=ice-ufrag or a=ice-pwd attributes | ||||
compared to the previous SDP from the peer, it is a signal that ICE | ||||
is restarting for this media stream. | ||||
An agent MUST NOT change its mode from a previous answer unless, | If ICE is restarting for a media stream, the agent MUST start a new | |||
based on the offer, ICE procedures are being restarted for all media | Valid list for that media stream. However, it retains the old Valid | |||
streams in the offer. In that case, it MAY change its mode. | list for the purposes of sending media until ICE processing | |||
completes, at which point the old Valid list is discarded and the new | ||||
one is utilized to determine media and keepalive targets. | ||||
10.3. Updating the Check and Valid Lists | 9.3.1. Additional Procedures for Full Implementations | |||
The procedures in this section are applicable only to full | ||||
implementations. | ||||
Once the subsequent offer/answer exchange has completed, each agent | Once the subsequent offer/answer exchange has completed, each agent | |||
needs to determine the impact, if any, on the Check and Valid lists. | needs to determine the impact, if any, on the Check and Valid lists. | |||
Unless there is an ICE restart, an offer/answer exchange has no | Unless there is an ICE restart, an offer/answer exchange has no | |||
impact on the state of ICE processing for each media stream; that is | impact on the state of ICE processing for each media stream; that is | |||
determined entirely by the checks themselves. An updated offer/ | determined entirely by the checks themselves. | |||
answer exchange can impact the transmission rules for media, as | ||||
described in Section 12.1. | ||||
If the offer had a change in the ice-ufrag and/or ice-pwd for a media | When ICE restarts, an agent MUST flush the check list for the | |||
stream, the agent MUST start a new Valid list for that media stream. | affected media streams, and then recompute the check list and its | |||
However, it retains the old Valid list for the purposes of sending | states as described in Section 5.7. | |||
media until ICE processing completes, at which point the old Valid | ||||
list is discarded and the new one is utilized to determine media and | ||||
keepalive targets. A full-mode agent MUST also flush the check list | ||||
for the affected media streams, and then recompute the check list and | ||||
its states as described in Section 6.7. | ||||
If the subsequent offer added a new media stream, a full-mode agent | The remainder of this section describes processing when ICE is not | |||
MUST create a new check list for it (and an empty Valid list to start | restarting. | |||
of course), as described in Section 6.7. | ||||
If the subsequent offer removed a media stream, or an answer rejected | If the offer/answer exchange added a new media stream, the agent MUST | |||
an offered media stream, an agent MUST flush the Valid list for that | create a new check list for it (and an empty Valid list to start of | |||
media stream. It MUST terminate any STUN transactions in progress | course), as described in Section 5.7. | |||
for that media stream. A full-mode agent MUST remove the check list | ||||
If the offer/answer exchange removed a media stream, or an answer | ||||
rejected an offered media stream, an agent MUST flush the Valid list | ||||
for that media stream. It MUST terminate any STUN transactions in | ||||
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 periodic checks for it. | |||
If a media stream existed previously, and remains after the offer/ | If a media stream existed previously, and remains after the offer/ | |||
answer exchange, the agent MUST NOT modify the Valid list for that | answer exchange, the agent MUST NOT modify the Valid list for that | |||
media stream. However, if a full-mode agent is in the Running state | media stream. However, if an agent is in the Running state for that | |||
for that media stream, the check list is updated. To do that, the | media stream, the check list is updated. To do that, the agent | |||
full-mode agent recomputes the check lists using the procedures | recomputes the check lists using the procedures described in | |||
described in Section 6.7. If a check on the new check lists was also | Section 5.7. If a check on the new check lists was also on the | |||
on the previous check lists, and its state was Waiting, In-Progress, | previous check lists, and its state was Waiting, In-Progress, | |||
Succeeded or Failed, its state is copied over. If a check on the new | Succeeded or Failed, its state is copied over. If a check on the new | |||
check lists does not have a state (because its a new check on an | check lists does not have a state (because it's a new check on an | |||
existing check list, or a check on a new check list, or the check was | existing check list, or a check on a new check list, or the check was | |||
on an old check list but its state was not copied over) its state is | on an old check list but its state was not copied over) its state is | |||
set to Frozen. | set to Frozen. | |||
If none of the check lists are active (meaning that the checks in | If none of the check lists are active (meaning that the checks in | |||
each check list are Frozen), the full-mode agent sets the first check | each check list are Frozen), the full-mode agent sets the first check | |||
in the check list for the first media stream to Waiting, and then | in the check list for the first media stream to Waiting, and then | |||
sets the state of all other checks in that check list for the same | sets the state of all other checks in that check list for the same | |||
component ID and with the same foundation to Waiting as well. | component ID and with the same foundation to Waiting as well. | |||
Next, the full-mode agent goes through each check list, starting with | Next, the agent goes through each check list, starting with the | |||
the highest priority check. If a check has a state of Succeeded, and | highest priority check. If a check has a state of Succeeded, and it | |||
it has a component ID of 1, then all Frozen checks in the same check | has a component ID of 1, then all Frozen checks in the same check | |||
list with the same foundation whose component IDs are not one, have | list with the same foundation whose component IDs are not one, have | |||
their state set to Waiting. If, for a particular check list, there | their state set to Waiting. If, for a particular check list, there | |||
are checks for each component of that media stream in the Succeeded | are checks for each component of that media stream in the Succeeded | |||
state, the agent moves the state of all Frozen checks for the first | state, the agent moves the state of all Frozen checks for the first | |||
component of all other media streams (and thus in different check | component of all other media streams (and thus in different check | |||
lists) with the same foundation to Waiting. | lists) with the same foundation to Waiting. | |||
11. Keepalives | 10. Keepalives | |||
STUN connectivity checks are also used to keep NAT bindings open once | ||||
ICE processing has completed. This is accomplished by periodically | ||||
generating a check on the candidate pair currently being used for | ||||
media. | ||||
Specifically, once ICE processing allows media to begin flowing, as | ||||
described in Section 12.1, the agent sets a timer to fire in Tr | ||||
seconds. Tr SHOULD be configurable and SHOULD have a default of 15 | ||||
seconds. When Tr fires, the agent creates a connectivity check for | ||||
each component of that media stream. This check is sent on the | ||||
candidate pair currently being used to send media, as described in | ||||
Section 12.1. | ||||
This specification makes no recommendations on the behaviors should | ||||
the keepalive itself fail. However, an agent SHOULD NOT blindly | ||||
restart ICE processing for that stream; if the keepalive was lost due | ||||
to congestion, the ICE restart will only aggravate the problem. | ||||
When an ICE agent is communicating with an agent that is not ICE- | ||||
aware, keepalives still need to be utilized. Indeed, these | ||||
keepalives are essential even if neither endpoint implements ICE. As | ||||
such, this specification defines keepalive behavior generally, for | ||||
endpoints that support ICE, and those that do not. | ||||
All endpoints MUST send keepalives for each media session. These | All endpoints MUST send keepalives for each media session. These | |||
keepalives MUST be sent regardless of whether the media stream is | keepalives serve the purpose of keeping NAT bindings active for the | |||
currently inactive, sendonly, recvonly or sendrecv, and regardless of | media session. These keepalives MUST be sent regardless of whether | |||
the presence or value of the bandwidth attribute. The keepalive | the media stream is currently inactive, sendonly, recvonly or | |||
SHOULD be sent using a format which is supported by its peer. ICE | sendrecv, and regardless of the presence or value of the bandwidth | |||
endpoints allow for STUN-based keepalives for UDP streams, and as | attribute. These keepalives MUST be sent even if ICE is not being | |||
such, STUN keepalives MUST be used when an agent is communicating | utilized for the session at all. The keepalive SHOULD be sent using | |||
with a peer that supports ICE. An agent can determine that its peer | a format which is supported by its peer. ICE endpoints allow for | |||
supports ICE by the presence of a=candidate attributes for each media | STUN-based keepalives for UDP streams, and as such, STUN keepalives | |||
session. If the peer does not support ICE, the choice of a packet | MUST be used when an agent is communicating with a peer that supports | |||
format for keepalives is a matter of local implementation. A format | ICE. An agent can determine that its peer supports ICE by the | |||
which allows packets to easily be sent in the absence of actual media | presence of a=candidate attributes for each media session. If the | |||
peer does not support ICE, the choice of a packet format for | ||||
keepalives is a matter of local implementation. A format which | ||||
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 [27] and RTP comfort noise [23]. If the peer | goal are RTP No-Op [28] and RTP comfort noise [24]. If the peer | |||
doesn't support any formats that are particularly well suited for | doesn't support any formats that are particularly well suited for | |||
keepalives, an agent SHOULD send RTP packets with an incorrect | keepalives, an agent SHOULD send RTP packets with an incorrect | |||
version number, or some other form of error which would cause them to | version number, or some other form of error which would cause them to | |||
be discarded by the peer. | be discarded by the peer. | |||
STUN-based keepalives will be sent periodically every Tr seconds as | If there has been no packet sent on a candidate pair being used for | |||
described above. If STUN keepalives are not in use (because the peer | media for Tr seconds (where packets include media and previous | |||
does not support ICE), an agent SHOULD ensure that a media packet is | keepalives), an agent MUST generate a keepalive on that pair. Tr | |||
sent every Tr seconds. If one is not sent as a consequence of normal | SHOULD be configurable and SHOULD have a default of 15 seconds. | |||
media communications, a keepalive packet using one of the formats | ||||
discussed above SHOULD be sent. | ||||
12. Media Handling | If STUN is being used for keepalives, a STUN Binding Indication is | |||
used [11]. The Binding Indication SHOULD NOT contain integrity | ||||
checks; since the messages are simply discarded on receipt regardless | ||||
of contents. The Indication SHOULD NOT contain the PRIORITY or USE- | ||||
CANDIDATE attributes defined here. The Binding Indication is sent | ||||
using the same local and remote candidates that are being used for | ||||
media. An agent receipt a Binding Indication MUST discard it | ||||
silently. Though Binding Indications are used for keepalives, an | ||||
agent MUST be prepared to receive Binding Requests as well. If a | ||||
Binding Request is received, a response is generated as discussed in | ||||
[11], but there is no impact on ICE processing otherwise. | ||||
12.1. Sending Media | An agent MUST begin the keepalive processing once ICE has selected | |||
candidates for usage with media, or media begins to flow, whichever | ||||
happens first. Keepalives end once the session terminates or the | ||||
media stream is removed. | ||||
11. Media Handling | ||||
11.1. Sending Media | ||||
Procedures for sending media differ for full and lite | ||||
implementations. | ||||
11.1.1. Procedures for Full Implementations | ||||
Agents always send media using a candidate pair. An agent will send | Agents always send media using a candidate pair. An agent will send | |||
media to the remote candidate in the pair (setting the destination | media to the remote candidate in the pair (setting the destination | |||
address and port of the packet equal to that remote candidate), and | address and port of the packet equal to that remote candidate), and | |||
will send it from the local candidate. When the local candidate is | will send it from the local candidate. 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 through that relay, using | sent from a relayed candidate is sent through that relay, using | |||
procedures defined in [12]. | procedures defined in [12]. | |||
If the state of a media stream is Running, there is no old Valid list | If the state of a media stream is Running, there is no old Valid list | |||
for that media stream (which would be due to an ICE restart), a full- | for that media stream (which would be due to an ICE restart), an | |||
mode agent MUST NOT send media. For passive-only agents, which do | agent MUST NOT send media. | |||
not retain states about ICE processing, it MUST NOT send media until | ||||
there is a selected candidate pair in either the old or new Valid | ||||
list for each component of the media stream. | ||||
When an agent sends media, it MUST send it using the highest priority | When an agent sends media, it MUST send it using the highest priority | |||
selected pair for each component in either the old Valid list for a | selected pair for each component in either the old Valid list for a | |||
media stream (if it exists), else the new Valid list for that media | media stream (if it exists), else the new Valid list for that media | |||
stream. In several cases, this will not be the same candidate pairs | stream. In several cases, this will not be the same candidate pairs | |||
present in the m/c-line. When ICE first completes, if the selected | present in the m/c-line. When ICE first completes, if the selected | |||
pairs aren't a match for the m/c-line, an updated offer/answer | pairs aren't a match for the m/c-line, an updated offer/answer | |||
exchange will take place to remedy this disparity. However, until | exchange will take place to remedy this disparity. However, until | |||
that update offer arrives, there will not be a match. Furthermore, | that update offer arrives, there will not be a match. Furthermore, | |||
in very unusual cases, the m/c-lines in the updated offer/answer will | in very unusual cases, the m/c-lines in the updated offer/answer will | |||
skipping to change at page 39, line 9 | skipping to change at page 42, line 6 | |||
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. Furthermore, many audio codecs use | source or destination address. Furthermore, many audio codecs use | |||
the marker bit to signal the beginning of a talkspurt, for the | the marker bit to signal the beginning of a talkspurt, for the | |||
purposes of jitter buffer adaptation. For such codecs, it is | purposes of jitter buffer adaptation. For such codecs, it is | |||
RECOMMENDED that the sender change the marker bit when an agent | RECOMMENDED that the sender change the marker bit when an agent | |||
switches transmission of media from one candidate pair to another. | switches transmission of media from one candidate pair to another. | |||
12.2. Receiving Media | 11.1.2. Procedures for Lite Implementations | |||
A lite implementation MUST NOT send media until it has a Valid list | ||||
that contains a candidate pair for each component of that media | ||||
stream. Once that happens, the agent MAY begin sending media | ||||
packets. To do that, it sends media to the remote candidate in the | ||||
pair (setting the destination address and port of the packet equal to | ||||
that remote candidate), and will send it from the local candidate. | ||||
In cases where there has been an ICE restart, there will be an old | ||||
and a new Valid list. The old Valid list MUST be used by the agent | ||||
for sending media until the new one is complete, at which point the | ||||
new one MUST be used, and the old one discarded. | ||||
11.2. Receiving Media | ||||
ICE implementations MUST be prepared to receive media on any | ICE implementations MUST be prepared to receive media on any | |||
candidates provided in the most recent offer/answer exchange. | candidates provided in the most recent offer/answer exchange. | |||
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 [20] describes an algorithm in Section 8.2 for detecting | RFC 3550 [21] 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. | |||
13. Usage with SIP | 12. Usage with SIP | |||
13.1. Latency Guidelines | 12.1. Latency Guidelines | |||
ICE requires a series of STUN-based connectivity checks to take place | ICE requires a series of STUN-based connectivity checks to take place | |||
between endpoints. These checks start from the answerer on | between endpoints. These checks start from the answerer on | |||
generation of its answer, and start from the offerer when it receives | generation of its answer, and start from the offerer when it receives | |||
the answer. These checks can take time to complete, and as such, the | the answer. These checks can take time to complete, and as such, the | |||
selection of messages to use with offers and answers can effect | selection of messages to use with offers and answers can effect | |||
perceived user latency. Two latency figures are of particular | perceived user latency. Two latency figures are of particular | |||
interest. These are the post-pickup delay and the post-dial delay. | interest. These are the post-pickup delay and the post-dial delay. | |||
The post-pickup delay refers to the time between when a user "answers | The post-pickup delay refers to the time between when a user "answers | |||
the phone" and when any speech they utter can be delivered to the | the phone" and when any speech they utter can be delivered to the | |||
caller. The post-dial delay refers to the time between when a user | caller. The post-dial delay refers to the time between when a user | |||
enters the destination address for the user, and ringback begins as a | enters the destination address for the user, and ringback begins as a | |||
consequence of having succesfully started ringing the phone of the | consequence of having succesfully started ringing the phone of the | |||
called party. | called party. | |||
To reduce post-dial delays, it is RECOMMENDED that the caller begin | To reduce post-dial delays, it is RECOMMENDED that the caller begin | |||
gathering candidates prior to actually sending its initial INVITE. | gathering candidates prior to actually sending its initial INVITE. | |||
This can be started upon user interface cues that a call is pending, | This can be started upon user interface cues that a call is pending, | |||
skipping to change at page 40, line 7 | skipping to change at page 43, line 19 | |||
consequence of having succesfully started ringing the phone of the | consequence of having succesfully started ringing the phone of the | |||
called party. | called party. | |||
To reduce post-dial delays, it is RECOMMENDED that the caller begin | To reduce post-dial delays, it is RECOMMENDED that the caller begin | |||
gathering candidates prior to actually sending its initial INVITE. | gathering candidates prior to actually sending its initial INVITE. | |||
This can be started upon user interface cues that a call is pending, | This can be started upon user interface cues that a call is pending, | |||
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 callee SHOULD | If an offer is received in an INVITE request, the callee SHOULD | |||
immediately gather its candidates and then generate an answer in a | immediately gather its candidates and then generate an answer in a | |||
provisional response. When reliable provisional responses are not | provisional response. ICE requires that a provisional response with | |||
used, the SDP in the provisional response is the answer, and that | an SDP be transmitted reliably. This can be done through the | |||
exact same answer reappears in the 200 OK. To deal with possible | existing PRACK mechanism [9], or through an optimization that is | |||
losses of the provisional response, it SHOULD be retransmitted until | specific to ICE. With this optimization, provisional responses | |||
some indication of receipt. This indication can either be through | containing an SDP answer that begins ICE processing for one or more | |||
PRACK [9], or through the receipt of a successful STUN Binding | media streams can be sent reliably without RFC 3264. To do this, the | |||
Request. Even if PRACK is not used, the provisional response SHOULD | agent retransmits the provisional response with th exponential | |||
be retransmitted using the exponential backoff and timers described | backoff timers described in RFC 3262. Retransmits MUST cease on | |||
in [9]. Note, however, that if PRACK is not used, the rules for when | receipt of a STUN Binding Request for one of the media streams | |||
signaled in that SDP or on transmission of a 2xx response. If no | ||||
Binding Request is received prior to the last retransmit, the agent | ||||
does not consider the session terminated. Despite the fact that the | ||||
provisional response will be delivered reliably, the rules for when | ||||
an agent can send an updated offer or answer do not change from those | an agent can send an updated offer or answer do not change from those | |||
specified in RFC 3262, even though the provisional response has been | specified in RFC 3262. Specifically, if the INVITE contained an | |||
delivered "reliably". Specifically, if the offer contained an | offer, the same answer appears in all of the 1xx and in the 2xx | |||
INVITE, 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 | response to the INVITE. Only after that 2xx has been sent can an | |||
updated offer/answer exchange occur. | 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, | ||||
however this results in a poor user experience and is NOT | ||||
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 callee can begin sending media | media stream enter the valid list, the callee can begin sending media | |||
on that media stream. | 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 [24] cannot be transmitted. For | the caller (such as SIP early media [25] cannot be transmitted. For | |||
this reason, implementations SHOULD delay alerting the called party | this reason, implementations SHOULD delay alerting the called party | |||
until candidates for each component of each media stream have entered | until candidates for each component of each media stream have entered | |||
the valid list. In the case of a PSTN gateway, this would mean that | the valid list. In the case of a PSTN gateway, this would mean that | |||
the setup message into the PSTN is delayed until this point. Doing | the setup message into the PSTN is delayed until this point. Doing | |||
this increases the post-dial delay, but has the effect of eliminating | this increases the post-dial delay, but has the effect of eliminating | |||
'ghost rings'. Ghost rings are cases where the called party hears | 'ghost rings'. Ghost rings are cases where the called party hears | |||
the phone ring, picks up, but hears nothing and cannot be heard. | the phone ring, picks up, but hears nothing and cannot be heard. | |||
This technique works without requiring support for, or usage of, | This technique works without requiring support for, or usage of, | |||
preconditions [6], since its a localized decision. It also has the | preconditions [6], since its a localized decision. It also has the | |||
benefit of guaranteeing that not a single packet of media will get | benefit of guaranteeing that not a single packet of media will get | |||
clipped, so that post-pickup delay is zero. If an agent chooses to | clipped, so that post-pickup delay is zero. If an agent chooses to | |||
delay local alerting in this way, it SHOULD generate a 180 response | delay local alerting in this way, it SHOULD generate a 180 response | |||
once alerting begins. | once alerting begins. | |||
In addition to uses where the offer is in an INVITE, and the answer | ||||
is in the provisional and/or 200 OK, ICE works with cases where the | ||||
offer appears in the response. In such cases, which are common in | ||||
third party call control, ICE agents SHOULD generate their offers in | ||||
a reliable provisional response (which MUST utilize RFC 3262). In | ||||
that case, the answer will arrive in a PRACK. This allows for ICE | ||||
processing to take place prior to alerting. Once ICE completes, the | ||||
agent can alert the user and then generate a 200 OK. The 200 OK | ||||
would contain no SDP, since the offer/answer exchange has completed. | ||||
Agents MAY place the offer in a 2xx instead (in which case the answer | ||||
comes in the ACK). This flow is simpler but results in a poorer user | ||||
experience. | ||||
As discussed in Section 16, offer/answer exchanges SHOULD be secured | As discussed in Section 16, offer/answer exchanges SHOULD be secured | |||
against eavesdropping and man-in-the-middle attacks. To do that, the | against eavesdropping and man-in-the-middle attacks. To do that, the | |||
usage of SIPS [3] is RECOMMENDED when used in concert with ICE. | usage of SIPS [3] is RECOMMENDED when used in concert with ICE. | |||
13.2. Interactions with Forking | 12.2. SIP Option Tags and Media Feature Tags | |||
[13] specifies a SIP option tag and media feature tag for usage with | ||||
ICE. ICE implementations using SIP SHOULD support this | ||||
specification, which uses a feature tag in registrations to | ||||
facilitate interoperability through gateways. | ||||
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. | |||
With ICE, this problem is resolved. The connectivity checks which | With ICE, this problem is resolved. The connectivity checks which | |||
occur prior to transmission of media carry username fragments, which | occur prior to transmission of media carry username fragments, which | |||
in turn are correlated to a specific callee. Subsequent media | in turn are correlated to a specific callee. Subsequent media | |||
packets which arrive on the same 5-tuple as the connectivity check | packets which arrive on the same 5-tuple as the connectivity check | |||
will be associated with that same callee. Thus, the caller can | will be associated with that same callee. Thus, the caller can | |||
perform this correlation as long as it has received an answer. | perform this correlation as long as it has received an answer. | |||
13.3. Interactions with Preconditions | 12.4. Interactions with Preconditions | |||
Quality of Service (QoS) preconditions, which are defined in RFC 3312 | Quality of Service (QoS) preconditions, which are defined in RFC 3312 | |||
[6] and RFC 4032 [7], apply only to the transport addresses listed in | [6] and RFC 4032 [7], apply only to the transport addresses listed in | |||
the m/c lines in an offer/answer. If ICE changes the transport | the m/c lines in an offer/answer. If ICE changes the transport | |||
address where media is received, this change is reflected in the m/c | address where media is received, this change is reflected in the m/c | |||
lines of a new offer/answer. As such, it appears like any other re- | lines of a new offer/answer. 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 m/c lines are changing due to ICE | without regard to the fact that the m/c lines are changing due to ICE | |||
negotiations ocurring "in the background". | negotiations ocurring "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 ICE checks have completed and selected the candidate | met until the ICE checks have completed and selected the candidate | |||
pairs to be used for media. | pairs to be used for media. | |||
ICE also has (purposeful) interactions with connectivity | ICE also has (purposeful) interactions with connectivity | |||
preconditions [26]. Those interactions are described there. Note | preconditions [27]. Those interactions are described there. Note | |||
that the procedures described in Section 13.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 [26]. | provided by the explicit preconditions in [27]. | |||
13.4. 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 [16]. Flow I | ICE works with Flows I, III and IV as described in [17]. 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 | |||
through the process of gathering new candidates. Furthermore, that | through the process of gathering new candidates. Furthermore, that | |||
list of candidates SHOULD include the ones currently in-use. | list of candidates SHOULD include the ones currently in-use. | |||
14. Grammar | 13. Grammar | |||
This specification defines five new SDP attributes - the "candidate", | This specification defines seven new SDP attributes - the | |||
"remote-candidates", "ice-passive", "ice-ufrag" and "ice-pwd" | "candidate", "remote-candidates", "ice-lite", "ice-ufrag", "ice-pwd" | |||
attributes. | "ice-options" and "ice-mismatch" attributes. | |||
The candidate attribute is a media-level attribute only. It contains | The candidate attribute is a media-level attribute only. It contains | |||
a transport address for a candidate that can be used for connectivity | a transport address for a candidate that can be used for connectivity | |||
checks. | checks. | |||
The syntax of this attribute is defined using Augmented BNF as | The syntax of this attribute is defined using Augmented BNF as | |||
defined in RFC 4234 [8]: | defined in RFC 4234 [8]: | |||
candidate-attribute = "candidate" ":" foundation SP component-id SP | candidate-attribute = "candidate" ":" foundation SP component-id SP | |||
transport SP | transport SP | |||
skipping to change at page 43, line 4 | skipping to change at page 46, line 43 | |||
The foundation is composed of one or more ice-char. The component-id | The foundation is composed of one or more ice-char. The component-id | |||
is a positive integer, which identifies the specific component for | is a positive integer, which identifies the specific component for | |||
which the transport address is a candidate. It MUST start at 1 and | which the transport address is a candidate. It MUST start at 1 and | |||
MUST increment by 1 for each component of a particular candidate. | MUST increment by 1 for each component of a particular candidate. | |||
The connect-address production is taken from RFC 4566 [10], allowing | The connect-address production is taken from RFC 4566 [10], allowing | |||
for IPv4 addresses, IPv6 addresses and FQDNs. The port production is | for IPv4 addresses, IPv6 addresses and FQDNs. The port production is | |||
also taken from RFC 4566 [10]. The token production is taken from | also taken from RFC 4566 [10]. The token production is taken from | |||
RFC 3261 [3]. The transport production indicates the transport | RFC 3261 [3]. The transport production indicates the transport | |||
protocol for the candidate. This specification only defines UDP. | protocol for the candidate. This specification only defines UDP. | |||
However, extensibility is provided to allow for future transport | However, extensibility is provided to allow for future transport | |||
protocols to be used with ICE, such as TCP or the Datagram Congestion | protocols to be used with ICE, such as TCP or the Datagram Congestion | |||
Control Protocol (DCCP) [28]. | Control Protocol (DCCP) [29]. | |||
The cand-type production encodes the type of candidate. This | The cand-type production encodes the type of candidate. This | |||
specification defines the values "host", "srflx", "prflx" and "relay" | specification defines the values "host", "srflx", "prflx" and "relay" | |||
for host, server reflexive, peer reflexive and relayed candidates, | for host, 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. Inclusion of the candidate type is optional. The rel-addr | future. Inclusion of the candidate type is optional. The rel-addr | |||
and rel-port productions convey information the related transport | and rel-port productions convey information the related transport | |||
addresses. Rules for inclusion of these values is described in | addresses. Rules for inclusion of these values is described in | |||
Section 5.4. | Section 4.3. | |||
The a=candidate attribute can itself be extended. The grammar allows | The a=candidate attribute can itself be extended. The grammar allows | |||
for new name/value pairs to be added at the end of the attribute. An | for new name/value pairs to be added at the end of the attribute. An | |||
implementation MUST ignore any name/value pairs it doesn't | implementation MUST ignore any name/value pairs it doesn't | |||
understand. | understand. | |||
The syntax of the "remote-candidates" attribute is defined using | The syntax of the "remote-candidates" attribute is defined using | |||
Augmented BNF as defined in RFC 4234 [8]. The remote-candidates | Augmented BNF as defined in RFC 4234 [8]. The remote-candidates | |||
attribute is a media level attribute only. | attribute is a media level attribute only. | |||
remote-candidate-att = "remote-candidates" ":" remote-candidate | remote-candidate-att = "remote-candidates" ":" remote-candidate | |||
0*(SP remote-candidate) | 0*(SP remote-candidate) | |||
remote-candidate = component-ID SP connection-address SP port | remote-candidate = component-ID SP connection-address SP port | |||
The attribute contains a connection-address and port for each | The attribute contains a connection-address and port for each | |||
component. The ordering of components is irrelevant. However, a | component. The ordering of components is irrelevant. However, a | |||
value MUST be present for each component of a media stream. | value MUST be present for each component of a media stream. | |||
The syntax of the "ice-passive" candidate is: | The syntax of the "ice-lite" and "ice-mismatch", both of which are | |||
flags, is: | ||||
ice-passive = "ice-passive" | ice-lite = "ice-lite" | |||
ice-mismatch = "ice-mismatch" | ||||
The syntax of the "ice-pwd" and "ice-ufrag" attributes are defined | "ice-lite" is a session level attribute only, and "ice-mismatch" is a | |||
as: | media level attribute only. The syntax of the "ice-pwd" and "ice- | |||
ufrag" attributes are defined as: | ||||
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*ice-char | |||
ufrag = 4*ice-char | ufrag = 4*ice-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. | overriden by a media-level value. | |||
The "ice-options" attribute is a session level attribute. It | ||||
contains a series of tokens which identify the options supported by | ||||
the agent. Its grammar is: | ||||
ice-options = "ice-options" ":" ice-option-tag | ||||
0*(SP ice-option-tag) | ||||
ice-option-tag = 1*ice-char | ||||
14. Extensibility Considerations | ||||
This specification makes very specific choices about how both agents | ||||
in a session coordinate to arrive at the set of candidate pairs that | ||||
are selected for media. It is anticipated that future specifications | ||||
will want to alter these algorithms, whether they are simple changes | ||||
like timer tweaks, or larger changes like a revamp of the priority | ||||
algorithm. When such a change is made, providing interoperability | ||||
between the two agents in a session is critical. | ||||
Firstly, ICE provides the a=ice-options SDP attribute. Each | ||||
extension or change to ICE is associated with a token. When an agent | ||||
supporting such an extension or change generates an offer or an | ||||
answer, it MUST include the token for that extension in this | ||||
attribute. This allows each side to know what the other side is | ||||
doing. This attribute MUST NOT be present if the agent doesn't | ||||
support any ICE extensions or changes. | ||||
At this time, no IANA registry or registration procedures are defined | ||||
for these option tags. At time of writing, it is unclear whether ICE | ||||
changes and extensions will be sufficiently common to warrrant a | ||||
registry. | ||||
One of the complications in achieving interoperability is that ICE | ||||
relies on a distributed algorithm running on both agents to converge | ||||
on an agreed set of candidate pairs. If the two agents run different | ||||
algorithms, it can be difficult to guarantee convergence on the same | ||||
candidate pairs. The introspective selection procedure described in | ||||
Section 8 eliminates some of the tight coordination by delegating the | ||||
selection algorithm completely to the controlling agent. | ||||
Consequently, when a controlling agent is communicating with a peer | ||||
that supports options it doesn't know about, the agent MUST run an | ||||
introspective selection algorithm. When introspective selection is | ||||
used, ICE will converge perfectly even when both agents use different | ||||
pair prioritization algorithms. One of the keys to such convergence | ||||
are triggered checks, which ensure that the favored pair is validated | ||||
by both agents. Consequently, any future ICE enhancements MUST | ||||
preserve triggered checks. | ||||
15. Example | 15. Example | |||
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, and for agent R, 192.0.2.1. Both are | agent L, it is 10.0.1.1, and for agent R, 192.0.2.1. Both are | |||
configured with a single STUN server each (indeed, the same one for | configured with a single STUN server each (indeed, the same one for | |||
each), which is listening for STUN requests at an IP address of | each), which is listening for STUN requests at an IP address of | |||
192.0.2.2 and port 3478. This STUN server supports only the Binding | 192.0.2.2 and port 3478. This STUN server supports only the Binding | |||
Discovery usage; relays are not used in this example. Agent L is | Discovery usage; 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 | behind a NAT, and agent R is on the public Internet. The NAT has an | |||
skipping to change at page 44, line 41 | skipping to change at page 49, line 39 | |||
variable. | variable. | |||
The STUN server has advertised transport address STUN-PUB-1 (which is | The STUN server has advertised transport address STUN-PUB-1 (which is | |||
192.0.2.2:3478) for the binding discovery usage. | 192.0.2.2:3478) for the binding discovery usage. | |||
In the call flow itself, STUN messages are annotated with several | In the call flow itself, STUN messages are annotated with several | |||
attributes. The "S=" attribute indicates the source transport | attributes. The "S=" attribute indicates the source transport | |||
address of the message. The "D=" attribute indicates the destination | address of the message. The "D=" attribute indicates the destination | |||
transport address of the message. The "MA=" attribute is used in | transport address of the message. The "MA=" attribute is used in | |||
STUN Binding Response messages and refers to the mapped address. | STUN Binding Response messages and refers to the mapped address. | |||
"USE-CAND" implies the presence of the USE-CANDIDATE attribute. | ||||
The call flow examples omit STUN authentication operations and RTCP, | The call flow examples omit STUN authentication operations and RTCP, | |||
and focus on RTP for a single media stream. | and focus on RTP for a single media stream between two full | |||
implementations. | ||||
L NAT STUN R | L NAT STUN R | |||
|RTP STUN alloc. | | | |RTP STUN alloc. | | | |||
|(1) STUN Req | | | | |(1) STUN Req | | | | |||
|S=$L-PRIV-1 | | | | |S=$L-PRIV-1 | | | | |||
|D=$STUN-PUB-1 | | | | |D=$STUN-PUB-1 | | | | |||
|------------->| | | | |------------->| | | | |||
| |(2) STUN Req | | | | |(2) STUN Req | | | |||
| |S=$NAT-PUB-1 | | | | |S=$NAT-PUB-1 | | | |||
| |D=$STUN-PUB-1 | | | | |D=$STUN-PUB-1 | | | |||
skipping to change at page 45, line 41 | skipping to change at page 50, line 39 | |||
|(8) answer | | | | |(8) answer | | | | |||
|<-------------------------------------------| | |<-------------------------------------------| | |||
| |(9) Bind Req | | | | |(9) Bind Req | | | |||
| |S=$R-PUB-1 | | | | |S=$R-PUB-1 | | | |||
| |D=L-PRIV-1 | | | | |D=L-PRIV-1 | | | |||
| |<----------------------------| | | |<----------------------------| | |||
| |Dropped | | | | |Dropped | | | |||
|(10) Bind Req | | | | |(10) Bind Req | | | | |||
|S=$L-PRIV-1 | | | | |S=$L-PRIV-1 | | | | |||
|D=$R-PUB-1 | | | | |D=$R-PUB-1 | | | | |||
|USE-CAND | | | | ||||
|------------->| | | | |------------->| | | | |||
| |(11) Bind Req | | | | |(11) Bind Req | | | |||
| |S=$NAT-PUB-1 | | | | |S=$NAT-PUB-1 | | | |||
| |D=$R-PUB-1 | | | | |D=$R-PUB-1 | | | |||
| |USE-CAND | | | ||||
| |---------------------------->| | | |---------------------------->| | |||
| |(12) Bind Res | | | | |(12) Bind Res | | | |||
| |S=$R-PUB-1 | | | | |S=$R-PUB-1 | | | |||
| |D=$NAT-PUB-1 | | | | |D=$NAT-PUB-1 | | | |||
| |MA=$NAT-PUB-1 | | | | |MA=$NAT-PUB-1 | | | |||
| |<----------------------------| | | |<----------------------------| | |||
|(13) Bind Res | | | | |(13) Bind Res | | | | |||
|S=$R-PUB-1 | | | | |S=$R-PUB-1 | | | | |||
|D=$L-PRIV-1 | | | | |D=$L-PRIV-1 | | | | |||
|MA=$NAT-PUB-1 | | | | |MA=$NAT-PUB-1 | | | | |||
skipping to change at page 46, line 29 | skipping to change at page 51, line 29 | |||
|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 10 | Figure 11 | |||
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 | |||
skipping to change at page 51, line 42 | skipping to change at page 56, line 42 | |||
This attack is very hard to launch unless the attacker themself is | This attack is very hard to launch unless the attacker themself is | |||
identified by the fake candidate. This is because it requires the | identified by the fake candidate. This is because it requires the | |||
attacker to intercept and replay packets sent by two different hosts. | attacker to intercept and replay packets sent by two different hosts. | |||
If both agents are on different networks (for example, across the | If both agents are on different networks (for example, across the | |||
public Internet), this attack can be hard to coordinate, since it | public Internet), this attack can be hard to coordinate, since it | |||
needs to occur against two different endpoints on different parts of | needs to occur against two different endpoints on different parts of | |||
the network at the same time. | the 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 [21], the | attack is easier to coordinate. However, if SRTP is used [22], 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. | |||
16.2. Attacks on Address Gathering | 16.2. Attacks on Address Gathering | |||
skipping to change at page 53, line 38 | skipping to change at page 58, line 38 | |||
16.4.2. STUN Amplification Attack | 16.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. This attack is | connectivity checks are directed to the target. This attack is | |||
accomplished by having the offerer send an offer with a large number | accomplished by having the offerer send an offer with a large number | |||
of candidates, say 50. The answerer receives the offer, and starts | of candidates, say 50. The answerer receives the offer, and starts | |||
its checks, which are directed at the target, and consequently, never | its checks, which are directed at the target, and consequently, never | |||
generate a response. The answerer will start a new connectivity | generate a response. The answerer will start a new connectivity | |||
check every 50ms, and each check is a STUN transaction consisting of | check every 20ms, and each check is a STUN transaction consisting of | |||
9 retransmits of a message 65 bytes in length (plus 28 bytes for the | 7 transmissions of a message 65 bytes in length (plus 28 bytes for | |||
IP/UDP header) that runs for 7.9 seconds, for a total of 105 bytes/ | the IP/UDP header) that runs for 7.9 seconds, for a total of 58 | |||
second per transaction on average. In the worst case, there can be | bytes/second per transaction on average. In the worst case, there | |||
158 transactions in progress at once (7.9 seconds divided by 50ms), | can be 395 transactions in progress at once (7.9 seconds divided by | |||
for a total of 132 kbps, just for STUN requests. | 20ms), for a total of 182 kbps, just for STUN requests. | |||
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. For example, agents can | be reduced through a variety of heuristics. Agents SHOULD limit the | |||
limit the number of candidates they'll accept in an offer or answer, | total number of connectivity checks they perform to 100. | |||
they can increase the value of Ta, or exponentially increase Ta as | Additionally, agents MAY limit the number of candidates they'll | |||
time goes on. All of these ultimately trade off the time for the ICE | accept in an offer or answer. | |||
exchanges to complete, with the amount of traffic that gets sent. | ||||
OPEN ISSUE: Need better remediation for this. | 16.5. Interactions with Application Layer Gateways and SIP | |||
Application Layer Gateways (ALGs) are functions present in a NAT | ||||
device which inspect the contents of packets and modify them, in | ||||
order to facilitate NAT traversal for application protocols. Session | ||||
Border Controllers (SBC) are close cousins of ALGs, but are less | ||||
transparent since they actually exist as application layer SIP | ||||
intermediaries. ICE has interactions with SBCs and ALGs. | ||||
If an ALG is SIP aware but not ICE aware, ICE will work through it as | ||||
long as the ALG correctly modifies the m/c-lines of SDP. In this | ||||
case, correctly means that the ALG does not modify m/c-lines with | ||||
external addresses. If the m/c-line contains internal addresses, but | ||||
ones for which a public binding exists, the ALG replaces the internal | ||||
address in the m/c-line with the public binding. Unfortunately, many | ||||
ALG are known to work poorly in these corner cases. ICE does not try | ||||
to work around broken ALGs, as this is outside the scope of its | ||||
functionality. ICE can help diagnose these conditions, which often | ||||
show up as a mismatch between the set of candidates and the m/c-line. | ||||
The a=ice-mismatch parameter is used for this purpose. | ||||
ICE works best through ALGs when the signaling is run over TLS. This | ||||
prevents the ALG from manipulating the SDP messages and interfering | ||||
with ICE operation. Implementations which are expected to be | ||||
deployed behind ALGs SHOULD provide for TLS transport of the SDP. | ||||
If an SBC is SIP aware but not ICE aware, the result depends on the | ||||
behavior of the SBC. If it is acting as a proper Back-to-Back User | ||||
Agent (B2BUA), the SBC will remove any SDP attributes it doesn't | ||||
understand, including the ICE attributes. Consequently, the call | ||||
will appear to both endpoints as if the other side doesn't support | ||||
ICE. This will result in ICE being disabled, and media flowing | ||||
through the SBC, if they SBC has requested it. If, however, the SBC | ||||
passes the ICE attributes without modification, yet modifies the m/c- | ||||
lines, this will be detected as an ICE mismatch, and ICE 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 present, ICE will | ||||
not be used and the SBC techniques take precedence. | ||||
17. Definition of Connectivity Check Usage | 17. Definition of Connectivity Check Usage | |||
STUN [11] requires that new usages provide a specific set of | STUN [11] 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. | |||
17.1. Applicability | 17.1. Applicability | |||
This STUN usage provides a connectivity check between two peers | This STUN usage provides a connectivity check between two peers | |||
skipping to change at page 55, line 18 | skipping to change at page 61, line 11 | |||
resulting from this check should be used for transmission of media. | resulting from this check should be used for transmission of media. | |||
The attribute has no content (the Length field of the attribute is | The attribute has no content (the Length field of the attribute is | |||
zero); it serves as a flag. It has an attribute type of 0x0025. | zero); it serves as a flag. It has an attribute type of 0x0025. | |||
17.6. New Error Response Codes | 17.6. New Error Response Codes | |||
This usage does not define any new error response codes. | This usage does not define any new error response codes. | |||
17.7. Client Procedures | 17.7. Client Procedures | |||
Client procedures are defined in Section 8.1. | Client procedures are defined in Section 7.1. | |||
17.8. Server Procedures | 17.8. Server Procedures | |||
Server procedures are defined in Section 8.2. | Server procedures are defined in Section 7.2. | |||
17.9. Security Considerations for Connectivity Check | 17.9. Security Considerations for Connectivity Check | |||
Security considerations for the connectivity check are discussed in | Security considerations for the connectivity check are discussed in | |||
Section 16. | Section 16. | |||
18. IANA Considerations | 18. IANA Considerations | |||
This specification registers new SDP attributes and new STUN | This specification registers new SDP attributes and new STUN | |||
attributes. | attributes. | |||
18.1. SDP Attributes | 18.1. SDP Attributes | |||
This specification defines five new SDP attributes per the procedures | This specification defines seven new SDP attributes per the | |||
of Section 8.2.4 of [10]. The required information for the | procedures of Section 8.2.4 of [10]. The required information for | |||
registrations are included here. | the registrations are included here. | |||
18.1.1. candidate Attribute | 18.1.1. candidate Attribute | |||
Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. | Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. | |||
Attribute Name: candidate | Attribute Name: candidate | |||
Long Form: candidate | Long Form: candidate | |||
Type of Attribute: media level | Type of Attribute: media level | |||
Charset Considerations: The attribute is not subject to the charset | Charset Considerations: The attribute is not subject to the charset | |||
attribute. | attribute. | |||
Purpose: This attribute is used with Interactive Connectivity | Purpose: This attribute is used with Interactive Connectivity | |||
Establishment (ICE), and provides one of many possible candidate | Establishment (ICE), and provides one of many possible candidate | |||
addresses for communication. These addresses are validated with | addresses for communication. These addresses are validated with | |||
an end-to-end connectivity check using Simple Traversal Underneath | an end-to-end connectivity check using Simple Traversal Underneath | |||
NAT (STUN). | NAT (STUN). | |||
skipping to change at page 56, line 15 | skipping to change at page 62, line 5 | |||
Charset Considerations: The attribute is not subject to the charset | Charset Considerations: The attribute is not subject to the charset | |||
attribute. | attribute. | |||
Purpose: This attribute is used with Interactive Connectivity | Purpose: This attribute is used with Interactive Connectivity | |||
Establishment (ICE), and provides one of many possible candidate | Establishment (ICE), and provides one of many possible candidate | |||
addresses for communication. These addresses are validated with | addresses for communication. These addresses are validated with | |||
an end-to-end connectivity check using Simple Traversal Underneath | an end-to-end connectivity check using Simple Traversal Underneath | |||
NAT (STUN). | NAT (STUN). | |||
Appropriate Values: See Section 14 of RFC XXXX [Note to RFC-ed: | Appropriate Values: See Section 13 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]. | |||
18.1.2. remote-candidates Attribute | 18.1.2. remote-candidates Attribute | |||
Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. | Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. | |||
Attribute Name: remote-candidates | Attribute Name: remote-candidates | |||
Long Form: remote-candidates | Long Form: remote-candidates | |||
Type of Attribute: media level | Type of Attribute: media level | |||
Charset Considerations: The attribute is not subject to the charset | Charset Considerations: The attribute is not subject to the charset | |||
attribute. | attribute. | |||
Purpose: This attribute is used with Interactive Connectivity | Purpose: This attribute is used with Interactive Connectivity | |||
Establishment (ICE), and provides the identity of the remote | Establishment (ICE), and provides the identity of the remote | |||
candidates that the offerer wishes the answerer to use in its | candidates that the offerer wishes the answerer to use in its | |||
answer. | answer. | |||
Appropriate Values: See Section 14 of RFC XXXX [Note to RFC-ed: | Appropriate Values: See Section 13 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]. | |||
18.1.3. ice-passive Attribute | 18.1.3. ice-lite Attribute | |||
Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. | Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. | |||
Attribute Name: ice-passive | Attribute Name: ice-lite | |||
Long Form: ice-passive | Long Form: ice-lite | |||
Type of Attribute: session level | Type of Attribute: session level | |||
Charset Considerations: The attribute is not subject to the charset | Charset Considerations: The attribute is not subject to the charset | |||
attribute. | attribute. | |||
Purpose: This attribute is used with Interactive Connectivity | Purpose: This attribute is used with Interactive Connectivity | |||
Establishment (ICE), and indicates that an agent can only operate | Establishment (ICE), and indicates that an agent has the minimum | |||
in ICE's passive mode. | functionality required to support ICE inter-operation with a peer | |||
that has a full implementation. | ||||
Appropriate Values: See Section 14 of RFC XXXX [Note to RFC-ed: | Appropriate Values: See Section 13 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]. | |||
18.1.4. ice-pwd Attribute | 18.1.4. ice-mismatch Attribute | |||
Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. | ||||
Attribute Name: ice-mismatch | ||||
Long Form: ice-mismatch | ||||
Type of Attribute: session level | ||||
Charset Considerations: The attribute is not subject to the charset | ||||
attribute. | ||||
Purpose: This attribute is used with Interactive Connectivity | ||||
Establishment (ICE), and indicates that an agent is ICE capable, | ||||
but did not proceed with ICE due to a mismatch of candidates with | ||||
the values in the m/c-line. | ||||
Appropriate Values: See Section 13 of RFC XXXX [Note to RFC-ed: | ||||
please replace XXXX with the RFC number of this specification]. | ||||
18.1.5. ice-pwd Attribute | ||||
Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. | Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. | |||
Attribute Name: ice-pwd | Attribute Name: ice-pwd | |||
Long Form: ice-pwd | Long Form: ice-pwd | |||
Type of Attribute: session or media level | Type of Attribute: session or media level | |||
Charset Considerations: The attribute is not subject to the charset | Charset Considerations: The attribute is not subject to the charset | |||
attribute. | attribute. | |||
Purpose: This attribute is used with Interactive Connectivity | Purpose: This attribute is used with Interactive Connectivity | |||
Establishment (ICE), and provides the password used to protect | Establishment (ICE), and provides the password used to protect | |||
STUN connectivity checks. | STUN connectivity checks. | |||
Appropriate Values: See Section 14 of RFC XXXX [Note to RFC-ed: | Appropriate Values: See Section 13 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]. | |||
18.1.5. ice-ufrag Attribute | 18.1.6. ice-ufrag Attribute | |||
Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. | Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. | |||
Attribute Name: ice-ufrag | Attribute Name: ice-ufrag | |||
Long Form: ice-ufrag | Long Form: ice-ufrag | |||
Type of Attribute: session or media level | Type of Attribute: session or media level | |||
Charset Considerations: The attribute is not subject to the charset | Charset Considerations: The attribute is not subject to the charset | |||
attribute. | attribute. | |||
Purpose: This attribute is used with Interactive Connectivity | Purpose: This attribute is used with Interactive Connectivity | |||
Establishment (ICE), and provides the fragments used to construct | Establishment (ICE), and provides the fragments used to construct | |||
the username in STUN connectivity checks. | the username in STUN connectivity checks. | |||
Appropriate Values: See Section 14 of RFC XXXX [Note to RFC-ed: | Appropriate Values: See Section 13 of RFC XXXX [Note to RFC-ed: | |||
please replace XXXX with the RFC number of this specification]. | ||||
18.1.7. ice-options Attribute | ||||
Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. | ||||
Attribute Name: ice-options | ||||
Long Form: ice-options | ||||
Type of Attribute: session level | ||||
Charset Considerations: The attribute is not subject to the charset | ||||
attribute. | ||||
Purpose: This attribute is used with Interactive Connectivity | ||||
Establishment (ICE), and indicates the ICE options or extensions | ||||
used by the agent. | ||||
Appropriate Values: See Section 13 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]. | |||
18.2. STUN Attributes | 18.2. STUN Attributes | |||
This section registers two new STUN attributes per the procedures in | This section registers two new STUN attributes per the procedures in | |||
[11]. | [11]. | |||
0x0024 PRIORITY | 0x0024 PRIORITY | |||
0x0025 USE-CANDIDATE | 0x0025 USE-CANDIDATE | |||
19. IAB Considerations | 19. 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 [19]. ICE is an example | collaborative protocol reflection mechanism [20]. 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. | |||
19.1. Problem Definition | 19.1. Problem Definition | |||
skipping to change at page 59, line 46 | skipping to change at page 66, line 30 | |||
19.3. Brittleness Introduced by ICE | 19.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 [13]) has | particular, traditional STUN (as described in RFC 3489 [14]) 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 61, line 16 | skipping to change at page 67, line 50 | |||
traditional STUN. However, the update to STUN [11] uses an encoding | traditional STUN. However, the update to STUN [11] uses an encoding | |||
which hides these binary addresses from generic ALGs. Since [11] is | which hides these binary addresses from generic ALGs. Since [11] is | |||
required for all ICE implementations, this NAPT problem does not | required for all ICE implementations, this NAPT problem does not | |||
impact ICE. | impact ICE. | |||
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 [30], this minimum keepalive will become deterministic and | behave [31], 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. | |||
20. Acknowledgements | 20. Acknowledgements | |||
The authors would like to thank Flemming Andreasen, Rohan Mahy, Dean | The authors would like to thank Flemming Andreasen, Rohan Mahy, Dean | |||
Willis, Eric Cooper, Dan Wing, Douglas Otis, Tim Moore, and Francois | Willis, Eric Cooper, Dan Wing, Douglas Otis, Tim Moore, and Francois | |||
Audet for their comments and input. A special thanks goes to Bill | Audet for their comments and input. A special thanks goes to Bill | |||
May, who suggested several of the concepts in this specification, | May, who suggested several of the concepts in this specification, | |||
skipping to change at page 62, line 25 | skipping to change at page 69, line 10 | |||
Specifications: ABNF", RFC 4234, October 2005. | Specifications: ABNF", RFC 4234, October 2005. | |||
[9] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional | [9] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional | |||
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] Rosenberg, J., "Simple Traversal Underneath Network Address | [11] Rosenberg, J., "Simple Traversal Underneath Network Address | |||
Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-04 | Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-05 | |||
(work in progress), July 2006. | (work in progress), October 2006. | |||
[12] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal | [12] 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. | |||
[13] Rosenberg, J., "Indicating Support for Interactive Connectivity | ||||
Establishment (ICE) in the Session Initiation Protocol (SIP)", | ||||
draft-ietf-sip-ice-option-tag-00 (work in progress), | ||||
January 2007. | ||||
21.2. Informative References | 21.2. Informative References | |||
[13] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN | [14] 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. | |||
[14] Senie, D., "Network Address Translator (NAT)-Friendly | [15] Senie, D., "Network Address Translator (NAT)-Friendly | |||
Application Design Guidelines", RFC 3235, January 2002. | Application Design Guidelines", RFC 3235, January 2002. | |||
[15] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. | [16] 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. | |||
[16] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, | [17] 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. | |||
[17] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro, "Realm | [18] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro, "Realm | |||
Specific IP: Framework", RFC 3102, October 2001. | Specific IP: Framework", RFC 3102, October 2001. | |||
[18] Borella, M., Grabelsky, D., Lo, J., and K. Taniguchi, "Realm | [19] 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. | |||
[19] Daigle, L. and IAB, "IAB Considerations for UNilateral Self- | [20] 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. | |||
[20] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, | [21] 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. | |||
[21] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. | [22] 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. | |||
[22] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via | [23] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via | |||
IPv4 Clouds", RFC 3056, February 2001. | IPv4 Clouds", RFC 3056, February 2001. | |||
[23] Zopf, R., "Real-time Transport Protocol (RTP) Payload for | [24] Zopf, R., "Real-time Transport Protocol (RTP) Payload for | |||
Comfort Noise (CN)", RFC 3389, September 2002. | Comfort Noise (CN)", RFC 3389, September 2002. | |||
[24] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone | [25] 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. | |||
[25] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. | [26] 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. | |||
[26] Andreasen, F., "Connectivity Preconditions for Session | [27] 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. | |||
[27] Andreasen, F., "A No-Op Payload Format for RTP", | [28] 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. | |||
[28] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion | [29] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion | |||
Control Protocol (DCCP)", RFC 4340, March 2006. | Control Protocol (DCCP)", RFC 4340, March 2006. | |||
[29] Hellstrom, G. and P. Jones, "RTP Payload for Text | [30] Hellstrom, G. and P. Jones, "RTP Payload for Text | |||
Conversation", RFC 4103, June 2005. | Conversation", RFC 4103, June 2005. | |||
[30] Audet, F. and C. Jennings, "NAT Behavioral Requirements for | [31] Audet, F. and C. Jennings, "NAT Behavioral Requirements for | |||
Unicast UDP", draft-ietf-behave-nat-udp-08 (work in progress), | Unicast UDP", draft-ietf-behave-nat-udp-08 (work in progress), | |||
October 2006. | October 2006. | |||
[31] Jennings, C. and R. Mahy, "Managing Client Initiated | [32] 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-04 (work in progress), June 2006. | draft-ietf-sip-outbound-07 (work in progress), January 2007. | |||
Appendix A. Passive-Only ICE | ||||
ICE allows for two modes of operation in an agent - passive-only and | ||||
full. Passive-only mode is applicable to entities like PSTN | ||||
gateways, media servers and conferencing servers that are always | ||||
publicly connected and are not behind a firewall or NAT. | ||||
This leads to an important question - why would such an endpoint even | ||||
bother with ICE? If it has a public IP address, what additional | ||||
value do the ICE procedures bring? There are many, actually. | ||||
First, doing so greatly facilitates NAT traversal for clients that | ||||
connect to it. Consider a PC softphone behind a NAT whose mapping | ||||
policy is address and port dependent. The softphone initiates a call | ||||
through a gateway that implements ICE. The gateway doesn't obtain | ||||
any server reflexive or relayed candidates, but it implements ICE, | ||||
and consequently, is prepared to receive STUN connectivity checks on | ||||
its host candidates. The softphone will send a STUN connectivity | ||||
check to the gateway, which passes through the intervending NAT. | ||||
This causes the NAT to allocate a new binding for the softphone. The | ||||
connectivity is received by the gateway, and will cause it gateway to | ||||
send a check back to the softphone, at this newly created candidate. | ||||
A successful response confirms that this candidate is usable, and the | ||||
gateway can send media immediately to the softphone. This allows | ||||
direct media transmission between the gateway and softphone, without | ||||
the need for relays, even though the softphone was behind a 'bad' | ||||
NAT. | ||||
Second, implementation of the STUN connectivity checks allows for NAT | ||||
bindings along the way to be kept open. Keeping these bindings open | ||||
is essential for continued communications between the gateway and | ||||
softphone. | ||||
Third, ICE prevents a fairly destructive attack in multimedia | ||||
systems, called the voice hammer. The STUN connectivity check used | ||||
by an ICE endpoint allows it to be certain that the target of media | ||||
packets is, in fact, the same entity that requested the packets | ||||
through the offer/answer exchange. See Section 16 for a more | ||||
complete discussion on this attack. | ||||
Because of the benefits of implementing ICE in endpoints that don't | ||||
themselves require NAT traversal, ICE reduces the cost of | ||||
implementation by allowing them to run in passive-only mode. The | ||||
rules for passive-only endpoints are described throughout the | ||||
specification. What follows is an informative summary to give | ||||
implementors a good sense of what is required: | ||||
o A passive-only agent obtains candidates just from its host | ||||
interfaces, just like it would do without ICE. It doesn't need to | ||||
implement the STUN Binding Discovery usage [11] or the relay usage | ||||
[12] to gather server reflexive or relayed candidates. It needs | ||||
to assign its candidates a foundation ID; however it can use the | ||||
IP address itself as the foundation ID. | ||||
o The prioritization in Section 5.2 is trivially accomplished for | ||||
passive-only agents utilizing RTP. The type preference is set to | ||||
126 and the local preference to 65535, resulting in a priority of | ||||
2130706431 for RTP and 2130706430 for RTCP. | ||||
o In use candidates Section 5.3 are trivially selected - they are | ||||
equal to the host candidates. | ||||
o A passive-only agent will need to select a username and password | ||||
for each session. An SDP offer (and answer) constructed by an | ||||
RTP-based audio-only agent will contain two a=candidate lines, | ||||
which mirror the RTP and RTCP transport addresses in the m/c-line. | ||||
Each a=candidate line contains the priority and foundation | ||||
computed above, and indicates that it is a host candidate | ||||
Section 5.4. | ||||
o A passive-only agent doesn't need to construct check lists or | [33] Rescorla, E., "Overview of the Lite Implementation of | |||
maintain the states of ICE processing Section 6.7. It only needs | Interactive Connectivity Establishment (ICE)", | |||
to maintain the valid list, which are the list of checks it has | draft-ietf-mmusic-ice-lite-00.txt (work in progress), | |||
completed. Once it places its candidate lines into an offer or | January 2007. | |||
answer, it waits for the receipt of checks. | ||||
o A passive-only agent doesn't generate periodic checks. It only | Appendix A. Lite and Full Implementations | |||
generates triggered checks, which are checks that are created as a | ||||
consequence of receiving a check. A passive-only agent does need | ||||
to be able to respond to a STUN check it receives. | ||||
o A passive-only agent does not add the PRIORITY or USE-CANDIDATE | ICE allows for two types of implementations. A full implementation | |||
attributes to its STUN requests. Its STUN requests only contain | supports the controlling and controlled roles in a session, and can | |||
the USERNAME and MESSAGE-INTEGRITY attributes, set based on the | also perform address gathering. In contrast, a lite implementation | |||
username fragments and passwords exchanged in the offer and | is a minimalist implementation that does little but respond to STUN | |||
answer. | checks. | |||
o Handling of subsequent offer/answer exchanges is done trivially - | Because ICE requires both endpoints to support it in order to bring | |||
the passive-only agent includes its one and only candidate for | benefits to either endpoint, incremental deployment of ICE in a | |||
each component of each media stream in an a=candidate attribute | network is more complicated. Many sessions involve an endpoint which | |||
and in the m/c-line, just like an initial offer or answer. | is, by itself, not behind a NAT and not one that would worry about | |||
NAT traversal. Examples include gateways to the PSTN, media servers, | ||||
conference bridges, and application servers. A very common case is | ||||
to have one endpoint that requires NAT traversal (such as a VoIP hard | ||||
phone or soft phone) make a call through one of these devices. Even | ||||
if the phone supports a full ICE implementation, ICE won't be used at | ||||
all if the other device doesn't support it. The lite implementation | ||||
allows for a low-cost entry point for these devices. Once they | ||||
support the lite implementation, full implementations can connect to | ||||
them and get the full benefits of ICE. | ||||
o A passive-only agent never needs to compute or include the | Consequently, a lite implementation is only appropriate for devices | |||
a=remote-candidates attribute in any offer it sends. It never | that will always be connected to the public Internet and have a | |||
needs to generate an updated offer as a consequence of ICE | public IP address at which it can receive packets from any | |||
processing. | correspondent. ICE will not function when a lite implementation is | |||
placed behind a NAT. | ||||
o A passive-only agent sends media once a selected candidate pair | It is important to note that the lite implementation was added to | |||
appears in its Valid list for that media stream. | this specification to provide a stepping stone to full | |||
implementation. Even for devices that are always connected to the | ||||
public Internet, a full implementation is preferable if achievable. | ||||
A full implementation will reduce call setup times. Full | ||||
implementations also obtain the security benefits of ICE unrelated to | ||||
NAT traversal; in particular, the voice hammer attack described in | ||||
Section 16 is prevented only for full implementations, not lite. | ||||
Finally, it is often the case that a device which finds itself with a | ||||
public address today will be placed in a network tomorrow where it | ||||
will be behind a NAT. It is difficult to definitively know, over the | ||||
lifetime of a device or product, that it 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 seconds, where Ta has a default of 50ms. Why | transaction every Ta seconds, where Ta has a default of 20ms. Why | |||
are these transactions paced, and why was 50ms chosen as default? | are these transactions paced, and why was 20ms chosen as default? | |||
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. Furthermore, | |||
transmission of these packets on the network makes use of bandwidth | transmission of these packets on the network makes use of bandwidth | |||
and needs to be rate limited by the agent. As a consequence, the | and needs to be rate limited by the agent. As a consequence, the | |||
pacing ensures that the NAT devices does not get overloaded and that | pacing ensures that the NAT devices does not get overloaded and that | |||
traffic is kept at a reasonable rate. | traffic is kept at a reasonable rate. | |||
Another aspect of the STUN requests is their bandwidth usage. In | ||||
ICE, each STUN request contains the STUN 20 byte header, in addition | ||||
to the USERNAME, MESSAGE-INTEGRITY and PRIORITY attributes. The | ||||
USERNAME attribute contains a 4-byte attribute overhead, plus the | ||||
username value itself. This username is the concatenation of the two | ||||
fragments, plus a colon. Each fragment is supposed to be at least 4 | ||||
bytes long, making the total length of the USERNAME attribute (4*2 + | ||||
1 + 4) = 13 bytes. The MESSAGE-INTEGRITY attribute is 4 bytes of | ||||
overhead plus 20 bytes value, for 24 bytes. The PRIORITY attribute | ||||
is 4 bytes of overhead plus 4 bytes of value, for 8 bytes. Thus, the | ||||
total length of the STUN Binding Request is (20 + 13 + 24 + 8) = 65 | ||||
bytes, with 28 bytes of overhead for IP and UDP for a total of 93 | ||||
bytes. The response contains the STUN 20 byte header, the XOR- | ||||
MAPPED-ADDRESS, and MESSAGE-INTEGRITY attributes. XOR-MAPPED-ADDRESS | ||||
has 4 bytes overhead plus an 8 byte value, for a total of 12 bytes. | ||||
Thus, each STUN response is (20 + 12 + 24) = 56 bytes plus 28 bytes | ||||
of UDP/IP overhead for a total of 84 bytes. Checks typically fall | ||||
into one of two cases. If a check works, each transaction has a | ||||
single request and a single response, for a total of 2 packets and | ||||
177 bytes over one RTT interval. Assuming a fairly agressive RTT of | ||||
70ms, this produces 20.23 kbps, but only briefly. If a check fails | ||||
because the pair is invalid, there will be nine requests and no | ||||
responses. This produces 837 bytes over 7.9s, for a total of 105.9 | ||||
bps, but over a long period of time. | ||||
OPEN ISSUE: The bandwidth computations are pretty complex because | ||||
ICE is not a CBR stream, and its bandwidth utilization depends on | ||||
how many transactions it ends up generating before it finishes. | ||||
Need to work this model more. | ||||
Given that these numbers are close to, if not greater than, the | ||||
bandwidths utilized by many voice codecs, this seems a reasonable | ||||
value to use. | ||||
OPEN ISSUE: There is some debate about whether to reduce this | ||||
pacing interval smaller, say 20ms, to speed up ICE, or perhaps | ||||
make it equal to the bandwidth that would be utilized by the media | ||||
streams themselves. | ||||
B.2. Candidates with Multiple Bases | B.2. Candidates with Multiple Bases | |||
Section 5.1 talks about merging together candidates that are | Section 4.1.1 talks about merging together candidates that are | |||
identical but have different bases. When can an agent have two | identical but have different bases. When can an agent have two | |||
candidates that have the same IP address and port, but different | candidates that have the same IP address and port, but different | |||
bases? Consider the topology of Figure 16: | bases? Consider the topology of Figure 17: | |||
+----------+ | +----------+ | |||
| STUN Srvr| | | STUN Srvr| | |||
+----------+ | +----------+ | |||
| | | | |||
| | | | |||
----- | ----- | |||
// \\ | // \\ | |||
| | | | | | |||
| B:net10 | | | B:net10 | | |||
skipping to change at page 68, line 41 | skipping to change at page 73, line 41 | |||
| | | | |||
| | | | |||
|192.168.1.1 ----- | |192.168.1.1 ----- | |||
+----------+ // \\ +----------+ | +----------+ // \\ +----------+ | |||
| | | | | | | | | | | | | | |||
| Offerer |---------| C:net10 |---------| Answerer | | | Offerer |---------| C:net10 |---------| Answerer | | |||
| |10.0.1.1 | | 10.0.1.2 | | | | |10.0.1.1 | | 10.0.1.2 | | | |||
+----------+ \\ // +----------+ | +----------+ \\ // +----------+ | |||
----- | ----- | |||
Figure 16 | Figure 17 | |||
In this case, the offerer is multi-homed. It has one interface, | In this case, the offerer is multi-homed. It has one interface, | |||
10.0.1.1, on network C, which is a net 10 private network. The | 10.0.1.1, on network C, which is a net 10 private network. The | |||
Answerer is on this same network. The offerer is also connected to | Answerer is on this same network. The offerer is also connected to | |||
network A, which is 192.168/16. The offerer has an interface of | network A, which is 192.168/16. The offerer has an interface of | |||
192.168.1.1 on this network. There is a NAT on this network, natting | 192.168.1.1 on this network. There is a NAT on this network, natting | |||
into network B, which is another net10 private network, but not | into network B, which is another net10 private network, but not | |||
connected to network C. There is a STUN server on network B. | connected to network C. There is a STUN server on network B. | |||
The offerer obtains a host candidate on its interface on network C | The offerer obtains a host candidate on its interface on network C | |||
skipping to change at page 69, line 29 | skipping to change at page 74, line 29 | |||
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 the translation, an | different types of candidates. By including the translation, an | |||
agent can know which relayed candidate is associated with which | agent can know which relayed candidate is associated with which | |||
reflexive candidate, which in turn is associated with a specific host | reflexive candidate, which in turn is associated with a specific host | |||
candidate. When checks for one candidate succeed and not the others, | candidate. When checks for one candidate succeed and not the others, | |||
this provides useful diagnostics on what is going on in the network. | this provides useful diagnostics on what is going on in the network. | |||
The second reason has to do with off-path Quality of Service (QoS) | The second reason has to do with off-path Quality of Service (QoS) | |||
mechanisms. When ICE is used in environments such as PacketCable 2.0 | mechanisms. When ICE is used in environments such as PacketCable | |||
[[TODO: need PC2.0 reference]], proxies will, in addition to | 2.0, proxies will, in addition to performing normal SIP operations, | |||
performing normal SIP operations, inspect the SDP in SIP messages, | inspect the SDP in SIP messages, and extract the IP address and port | |||
and extract the IP address and port for media traffic. They can then | for media traffic. They can then interact, through policy servers, | |||
interact, through policy servers, with access routers in the network, | with access routers in the network, to establish guaranteed QoS for | |||
to establish guaranteed QoS for the media flows. This QoS is | the media flows. This QoS is provided by classifying the RTP traffic | |||
provided by classifying the RTP traffic based on 5-tuple, and then | based on 5-tuple, and then providing it a guaranteed rate, or marking | |||
providing it a guaranteed rate, or marking its Diffserv codepoints | its Diffserv codepoints appropriately. When a residential NAT is | |||
appropriately. When a residential NAT is present, and a relayed | present, and a relayed candidate gets selected for media, this | |||
candidate gets selected for media, this relayed candidate will be a | relayed candidate will be a transport address on an actual STUN | |||
transport address on an actual STUN relay. That address says nothing | relay. That address says nothing about the actual transport address | |||
about the actual transport address in the access router that would be | in the access router that would be used to classify packets for QoS | |||
used to classify packets for QoS treatment. Rather, the translation | treatment. Rather, the translation of that relayed address is | |||
of that relayed address is needed. By carrying the translation in | needed. By carrying the translation in the SDP, the proxy can use | |||
the SDP, the proxy can use that transport address to request QoS from | that transport address to request QoS from the access router. | |||
the access router. | ||||
B.4. Importance of the STUN Username | B.4. Importance of the STUN Username | |||
ICE requires the usage of message integrity with STUN using its short | ICE requires the usage of message integrity with STUN using its short | |||
term credential functionality. The actual short term credential is | term credential functionality. The actual short term credential is | |||
formed by exchanging username fragments in the SDP offer/answer | formed by exchanging username fragments in the SDP offer/answer | |||
exchange. The need for this mechanism goes beyond just security; it | exchange. The need for this mechanism goes beyond just security; it | |||
is actual required for correct operation of ICE in the first place. | is actual required for correct operation of ICE in the first place. | |||
Consider agents A, B, and C. A and B are within private enterprise 1, | Consider agents A, B, and C. A and B are within private enterprise 1, | |||
skipping to change at page 70, line 49 | skipping to change at page 75, line 48 | |||
be prepared for it. Note that this is not a problem specific to ICE; | be prepared for it. Note that this is not a problem specific to ICE; | |||
stray packets can arrive at a port at any time for any type of | stray packets can arrive at a port at any time for any type of | |||
protocol, especially ones on the public Internet. As such, this | protocol, especially ones on the public Internet. As such, this | |||
requirement is just restating a general design guideline for Internet | requirement is just restating a general design guideline for Internet | |||
applications - be prepared for unknown packets on any port. | applications - be prepared for unknown packets on any 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(O-P,A-P) + 2*MAX(O-P,A-P) + (O-P>A-P?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 | |||
skipping to change at page 71, line 35 | skipping to change at page 76, line 33 | |||
results of a check for one media stream, and applies them to another. | results of a check for one media stream, and applies them to another. | |||
For example, if only the relayed candidates for audio (which were the | For example, if only the relayed candidates for audio (which were the | |||
last resort candidates) succeed, ICE will check the relayed | last resort candidates) succeed, ICE will check the relayed | |||
candidates for video first. | candidates for video first. | |||
B.7. The remote-candidates attribute | B.7. 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 17. On receipt of message 4, agent | race condition is shown in Figure 18. On receipt of message 4, agent | |||
A adds a candidate pair to the valid list. If there was only a | A adds a candidate pair to the valid list. If there was only a | |||
single media stream with a single component, agent A could now send | single media stream with a single component, agent A could now send | |||
an updated offer. However, the check from agent B has not yet | an updated offer. However, the check from agent B has not yet | |||
generated a response, and agent B receives the updated offer (message | generated a response, and agent B receives the updated offer (message | |||
7) before getting the response (message 10). Thus, it does not yet | 7) before getting the response (message 10). 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 B that were selected by the | condition, the actual candidates at B that were selected by the | |||
offerer (the remote candidates) are included in the offer itself. | offerer (the remote candidates) are included in the offer itself. | |||
Note, however, that agent B will not send media until it has received | Note, however, that agent B will not send media until it has received | |||
this STUN response. | this STUN response. | |||
skipping to change at page 72, line 28 | skipping to change at page 77, line 28 | |||
| |Lost | | | |Lost | | |||
|(7) Offer | | | |(7) Offer | | | |||
|------------------------------------------>| | |------------------------------------------>| | |||
|(8) Answer | | | |(8) Answer | | | |||
|<------------------------------------------| | |<------------------------------------------| | |||
|(9) STUN Req. | | | |(9) STUN Req. | | | |||
|<------------------------------------------| | |<------------------------------------------| | |||
|(10) STUN Res. | | | |(10) STUN Res. | | | |||
|------------------------------------------>| | |------------------------------------------>| | |||
Figure 17 | Figure 18 | |||
B.8. Why are Keepalives Needed? | B.8. 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 [29], may send packets so infrequently that the | text conversation [30], 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 | |||
indpendently 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.9. Why Prefer Peer Reflexive Candidates? | B.9. Why Prefer Peer Reflexive Candidates? | |||
Section 5.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 lower than server reflexive. Why is that? The reason has | |||
to do with the security considerations in Section 16. It is much | to do with the security considerations in Section 16. 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.10. Why Send an Updated Offer? | B.10. Why Send an Updated Offer? | |||
Section 12.1 describes rules for sending media. Both agents can send | Section 11.1 describes rules for sending media. Both agents can send | |||
media once ICE checks complete, without waiting for an updated offer. | media once ICE checks complete, without waiting for an updated offer. | |||
Indeed, the only purpose of the updated offer is to "correct" the | Indeed, the only purpose of the updated offer is to "correct" the | |||
m/c-line so that it matches where media is being sent, based on ICE | m/c-line so that it matches where media is being sent, based on ICE | |||
procedures. | procedures. | |||
This begs the question - why is the updated offer/answer exchange | This begs the question - why is the updated offer/answer exchange | |||
needed at all? Indeed, in a pure offer/answer environment, it would | needed at all? Indeed, in a pure offer/answer environment, it would | |||
not be. The offerer and answerer will agree on the candidates to use | not be. The offerer and answerer will agree on the candidates to use | |||
through ICE, and then can begin using them. As far as the agents | through ICE, and then can begin using them. As far as the agents | |||
themselves are concerned, the updated offer/answer provides no new | themselves are concerned, the updated offer/answer provides no new | |||
information. However, in practice, numerous components along the | information. However, in practice, numerous components along the | |||
signaling path look at the SDP information. These include entities | signaling path look at the SDP information. These include entities | |||
performing off-path QoS reservations, NAT traversal components such | performing off-path QoS reservations, NAT traversal components such | |||
as ALGs and Session Border Controllers (SBCs) and diagnostic tools | as ALGs and Session Border Controllers (SBCs) and diagnostic tools | |||
that passively monitor the network. For these tools to continue to | that passively monitor the network. For these tools to continue to | |||
function without change, the core property of SDP - that the m/c- | function without change, the core property of SDP - that the m/c- | |||
lines represent the addresses used for media - must be retained. For | lines represent the addresses used for media - must be retained. For | |||
this reason, an updated offer must be sent. | this reason, an updated offer must be sent. | |||
B.11. Why are Binding Indications Used for Keepalives? | ||||
Media keepalives are described in Section 10. These keepalives make | ||||
use of STUN when both endpoints are ICE capable. However, rather | ||||
than using a Binding Request transaction (which generates a | ||||
response), the keepalives use an Indication. Why is that? | ||||
The primary reason has to do with network QoS mechanisms. Once media | ||||
begins flowing, network elements will assume that the media stream | ||||
has a fairly regular structure, making use of periodic packets at | ||||
fixed intervals, with the possibility of jitter. If an agent is | ||||
sending media packets, and then receives a Binding Request, it would | ||||
need to generate a response packet along with its media packets. | ||||
This will increase the actual bandwidth requirements for the 5-tuple | ||||
carrying the media packets, and introduce jitter in the delivery of | ||||
those packets. Analysis has shown that this is a concern in certain | ||||
layer 2 access networks that use fairly tight packet schedulers for | ||||
media. | ||||
Additionally, using a Binding Indication allows integrity to be | ||||
disabled, allowing for better performance. This is useful for large | ||||
scale endpoints, such as PSTN gateways. | ||||
Author's Address | Author's Address | |||
Jonathan Rosenberg | Jonathan Rosenberg | |||
Cisco Systems | Cisco Systems | |||
600 Lanidex Plaza | 600 Lanidex Plaza | |||
Parsippany, NJ 07054 | Parsippany, NJ 07054 | |||
US | US | |||
Phone: +1 973 952-5000 | Phone: +1 973 952-5000 | |||
Email: jdrosen@cisco.com | Email: jdrosen@cisco.com | |||
skipping to change at page 75, line 41 | skipping to change at page 81, line 41 | |||
This document and the information contained herein are provided on an | This document and the information contained herein are provided on an | |||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | |||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | |||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | |||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | |||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | |||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |||
Copyright Statement | Copyright Statement | |||
Copyright (C) The Internet Society (2006). This document is subject | Copyright (C) The Internet Society (2007). This document is subject | |||
to the rights, licenses and restrictions contained in BCP 78, and | to the rights, licenses and restrictions contained in BCP 78, and | |||
except as set forth therein, the authors retain all their rights. | except as set forth therein, the authors retain all their rights. | |||
Acknowledgment | Acknowledgment | |||
Funding for the RFC Editor function is currently provided by the | Funding for the RFC Editor function is currently provided by the | |||
Internet Society. | Internet Society. | |||
End of changes. 242 change blocks. | ||||
855 lines changed or deleted | 1126 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/ |