draft-ietf-mmusic-ice-sip-sdp-20.txt   draft-ietf-mmusic-ice-sip-sdp-21.txt 
MMUSIC M. Petit-Huguenin MMUSIC M. Petit-Huguenin
Internet-Draft Impedance Mismatch Internet-Draft Impedance Mismatch
Obsoletes: 5245 (if approved) S. Nandakumar Obsoletes: 5245 (if approved) S. Nandakumar
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: October 3, 2018 A. Keranen Expires: January 1, 2019 A. Keranen
Ericsson Ericsson
April 1, 2018 June 30, 2018
Session Description Protocol (SDP) Offer/Answer procedures for Session Description Protocol (SDP) Offer/Answer procedures for
Interactive Connectivity Establishment (ICE) Interactive Connectivity Establishment (ICE)
draft-ietf-mmusic-ice-sip-sdp-20 draft-ietf-mmusic-ice-sip-sdp-21
Abstract Abstract
This document describes Session Description Protocol (SDP) Offer/ This document describes Session Description Protocol (SDP) Offer/
Answer procedures for carrying out Interactive Connectivity Answer procedures for carrying out Interactive Connectivity
Establishment (ICE) between the agents. Establishment (ICE) between the agents.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on October 3, 2018. This Internet-Draft will expire on January 1, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 22 skipping to change at page 2, line 22
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 4 3. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 4
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Generic Procedures . . . . . . . . . . . . . . . . . . . 4 3.2. Generic Procedures . . . . . . . . . . . . . . . . . . . 4
3.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . 4 3.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . 4
3.2.2. RTP/RTCP Considerations . . . . . . . . . . . . . . . 6 3.2.2. RTP/RTCP Considerations . . . . . . . . . . . . . . . 6
3.2.3. Determining Role . . . . . . . . . . . . . . . . . . 6 3.2.3. Determining Role . . . . . . . . . . . . . . . . . . 6
3.2.4. STUN Considerations . . . . . . . . . . . . . . . . . 6 3.2.4. STUN Considerations . . . . . . . . . . . . . . . . . 6
3.2.5. Verifying ICE Support Procedures . . . . . . . . . . 6 3.2.5. Verifying ICE Support Procedures . . . . . . . . . . 6
3.2.6. SDP Example . . . . . . . . . . . . . . . . . . . . . 7 3.2.6. SDP Example . . . . . . . . . . . . . . . . . . . . . 7
3.3. Initial Offer/Answer Exchange . . . . . . . . . . . . . . 7 3.3. Initial Offer/Answer Exchange . . . . . . . . . . . . . . 7
skipping to change at page 3, line 10 skipping to change at page 3, line 10
5. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 21 5. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 21
6. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 21 6. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 21
6.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . 21 6.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . 21
6.1.1. Offer in INVITE . . . . . . . . . . . . . . . . . . . 22 6.1.1. Offer in INVITE . . . . . . . . . . . . . . . . . . . 22
6.1.2. Offer in Response . . . . . . . . . . . . . . . . . . 23 6.1.2. Offer in Response . . . . . . . . . . . . . . . . . . 23
6.2. SIP Option Tags and Media Feature Tags . . . . . . . . . 23 6.2. SIP Option Tags and Media Feature Tags . . . . . . . . . 23
6.3. Interactions with Forking . . . . . . . . . . . . . . . . 24 6.3. Interactions with Forking . . . . . . . . . . . . . . . . 24
6.4. Interactions with Preconditions . . . . . . . . . . . . . 24 6.4. Interactions with Preconditions . . . . . . . . . . . . . 24
6.5. Interactions with Third Party Call Control . . . . . . . 24 6.5. Interactions with Third Party Call Control . . . . . . . 24
7. Relationship with ANAT . . . . . . . . . . . . . . . . . . . 25 7. Relationship with ANAT . . . . . . . . . . . . . . . . . . . 25
8. Setting Ta and RTO for RTP Media Streams . . . . . . . . . . 25 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 8.1. Attacks on the Offer/Answer Exchanges . . . . . . . . . . 25
9.1. Attacks on the Offer/Answer Exchanges . . . . . . . . . . 25 8.2. Insider Attacks . . . . . . . . . . . . . . . . . . . . . 25
9.2. Insider Attacks . . . . . . . . . . . . . . . . . . . . . 25 8.2.1. The Voice Hammer Attack . . . . . . . . . . . . . . . 25
9.2.1. The Voice Hammer Attack . . . . . . . . . . . . . . . 26 8.2.2. Interactions with Application Layer Gateways and SIP 26
9.2.2. Interactions with Application Layer Gateways and SIP 26 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 9.1. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 27
10.1. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 27 9.1.1. candidate Attribute . . . . . . . . . . . . . . . . . 27
10.1.1. candidate Attribute . . . . . . . . . . . . . . . . 28 9.1.2. remote-candidates Attribute . . . . . . . . . . . . . 28
10.1.2. remote-candidates Attribute . . . . . . . . . . . . 28 9.1.3. ice-lite Attribute . . . . . . . . . . . . . . . . . 28
10.1.3. ice-lite Attribute . . . . . . . . . . . . . . . . . 29 9.1.4. ice-mismatch Attribute . . . . . . . . . . . . . . . 29
10.1.4. ice-mismatch Attribute . . . . . . . . . . . . . . . 29 9.1.5. ice-pwd Attribute . . . . . . . . . . . . . . . . . . 29
10.1.5. ice-pwd Attribute . . . . . . . . . . . . . . . . . 30 9.1.6. ice-ufrag Attribute . . . . . . . . . . . . . . . . . 30
10.1.6. ice-ufrag Attribute . . . . . . . . . . . . . . . . 30 9.1.7. ice-options Attribute . . . . . . . . . . . . . . . . 30
10.1.7. ice-options Attribute . . . . . . . . . . . . . . . 31 9.1.8. ice-pacing Attribute . . . . . . . . . . . . . . . . 31
10.1.8. ice-pacing Attribute . . . . . . . . . . . . . . . . 31 9.2. Interactive Connectivity Establishment (ICE) Options
10.2. Interactive Connectivity Establishment (ICE) Options Registry . . . . . . . . . . . . . . . . . . . . . . . . 31
Registry . . . . . . . . . . . . . . . . . . . . . . . . 32 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 11.1. Normative References . . . . . . . . . . . . . . . . . . 32
12.1. Normative References . . . . . . . . . . . . . . . . . . 33 11.2. Informative References . . . . . . . . . . . . . . . . . 34
12.2. Informative References . . . . . . . . . . . . . . . . . 35 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 35
12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 35
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 36 Appendix B. The remote-candidates Attribute . . . . . . . . . . 37
Appendix B. The remote-candidates Attribute . . . . . . . . . . 38 Appendix C. Why Is the Conflict Resolution Mechanism Needed? . . 38
Appendix C. Why Is the Conflict Resolution Mechanism Needed? . . 39 Appendix D. Why Send an Updated Offer? . . . . . . . . . . . . . 39
Appendix D. Why Send an Updated Offer? . . . . . . . . . . . . . 40 Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 40
Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
This document describes how Interactive Connectivity Establishment This document describes how Interactive Connectivity Establishment
(ICE) is used with Session Description Protocol (SDP) offer/answer (ICE) is used with Session Description Protocol (SDP) offer/answer
[RFC3264]. The ICE specification [ICE-BIS] describes procedures that [RFC3264]. The ICE specification [ICE-BIS] describes procedures that
are common to all usages of ICE and this document gives the are common to all usages of ICE and this document gives the
additional details needed to use ICE with SDP offer/answer. additional details needed to use ICE with SDP offer/answer.
2. Terminology 2. Terminology
skipping to change at page 6, line 50 skipping to change at page 6, line 45
and this specification if, for each data stream in the SDP it and this specification if, for each data stream in the SDP it
received, the default destination for each component of that data received, the default destination for each component of that data
stream appears in a candidate attribute. For example, in the case of stream appears in a candidate attribute. For example, in the case of
RTP, the IP address and port in the "c=" and "m=" lines, RTP, the IP address and port in the "c=" and "m=" lines,
respectively, appear in a candidate attribute and the value in the respectively, appear in a candidate attribute and the value in the
rtcp attribute appears in a candidate attribute. rtcp attribute appears in a candidate attribute.
If this condition is not met, the agents MUST process the SDP based If this condition is not met, the agents MUST process the SDP based
on normal [RFC3264] procedures, without using any of the ICE on normal [RFC3264] procedures, without using any of the ICE
mechanisms described in the remainder of this specification with the mechanisms described in the remainder of this specification with the
following exceptions: few exceptions noted below:
1. A controlled/responding agent MUST follow the rules of section 11 1. The presence of certain application layer gateways MAY modify the
of [ICE-BIS], which describe keepalive procedures for all agents. transport address information as described in Section 8.2.2. The
Also, If the default candidates were relayed candidates learned behavior of the responding agent in such a situation is
through a TURN server, the controlled agent MUST create implementation defined. Informally, the responding agent MAY
permissions in the TURN server for the IP addresses learned from consider the mismatched transport address information as a
its peer in the offer SDP it just received. If this is not done, plausible new candidate learnt from the peer and continue its ICE
initial packets in the data stream from the peer may be lost. processing with that transport address included. Alternatively,
the responding agent MAY include an "a=ice-mismatch" attribute in
its answer and MAY also omit a=candidate attributes for such data
streams.
2. On the other hand, If the controlled agent is not proceeding with 2. The transport address from the peer for the default destination
ICE because there were a=candidate attributes, but none that correspond to IP address values "0.0.0.0"/"::" and port value of
matched the default destination of the data stream, the agent "9". This MUST not be considered as a ICE failure by the peer
MUST include an a=ice-mismatch attribute in its answer and MAY agent and the ICE processing MUST continue as usual.
omit a=candidate attributes for such data streams. See
Section 9.2.2 for a discussion of cases where this can happen. Also to note, this specification provides no guidance on how an
This specification provides no guidance on how an controlling/ controlling/initiator agent should proceed in scenarios where the the
initiator agent should proceed in such a failure case. SDP answer includes "a=ice-mismatch" from the peer.
3.2.6. SDP Example 3.2.6. SDP Example
The following is an example SDP message that includes ICE attributes The following is an example SDP message that includes ICE attributes
(lines folded for readability): (lines folded for readability):
v=0 v=0
o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1 o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
s= s=
c=IN IP4 192.0.2.3 c=IN IP4 192.0.2.3
skipping to change at page 9, line 40 skipping to change at page 9, line 36
3.4.1. Sending Subsequent Offer 3.4.1. Sending Subsequent Offer
3.4.1.1. Procedures for All Implementations 3.4.1.1. Procedures for All Implementations
3.4.1.1.1. ICE Restarts 3.4.1.1.1. ICE Restarts
An agent MAY restart ICE processing for an existing data stream An agent MAY restart ICE processing for an existing data stream
[ICE-BIS]. [ICE-BIS].
The rules governing the ICE restart imply that setting the IP address The rules governing the ICE restart imply that setting the IP address
in the "c=" line to 0.0.0.0 will cause an ICE restart. Consequently, in the "c=" line to 0.0.0.0 (for IPv4)/ :: (for IPv6) will cause an
ICE implementations MUST NOT utilize this mechanism for call hold, ICE restart. Consequently, ICE implementations MUST NOT utilize this
and instead MUST use a=inactive and a=sendonly as described in mechanism for call hold, and instead MUST use a=inactive and
[RFC3264]. a=sendonly as described in [RFC3264].
To restart ICE, an agent MUST change both the ice-pwd and the ice- To restart ICE, an agent MUST change both the ice-pwd and the ice-
ufrag for the data stream in an offer. Note that it is permissible ufrag for the data stream in an offer. Note that it is permissible
to use a session-level attribute in one offer, but to provide the to use a session-level attribute in one offer, but to provide the
same ice-pwd or ice-ufrag as a media-level attribute in a subsequent same ice-pwd or ice-ufrag 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, and does not cause an ICE restart. representation, and does not cause an ICE restart.
An agent sets the rest of the ice related fields in the SDP for this An agent sets the rest of the ice related fields in the SDP for this
data stream as it would in an initial offer of this data stream (see data stream as it would in an initial offer of this data stream (see
skipping to change at page 20, line 43 skipping to change at page 20, line 43
0*(SP ice-option-tag) 0*(SP ice-option-tag)
ice-option-tag = 1*ice-char ice-option-tag = 1*ice-char
The existence of an ice-option in an offer indicates that a certain The existence of an ice-option in an offer indicates that a certain
extension is supported by the agent and is willing to use it, if the extension is supported by the agent and is willing to use it, if the
peer agent also includes the same extension in the answer. There peer agent also includes the same extension in the answer. There
might be further extension specific negotiation needed between the might be further extension specific negotiation needed between the
agents that determine how the extensions gets used in a given agents that determine how the extensions gets used in a given
session. The details of the negotiation procedures, if present, MUST session. The details of the negotiation procedures, if present, MUST
be defined by the specification defining the extension (see be defined by the specification defining the extension (see
Section 10.2). Section 9.2).
Example shows 'rtp+ecn' ice-option SDP line from <<RFC6679>>: Example shows 'rtp+ecn' ice-option SDP line from <<RFC6679>>:
a=ice-options:rtp+ecn a=ice-options:rtp+ecn
5. Keepalives 5. Keepalives
All the ICE agents MUST follow the procedures defined in section 11 All the ICE agents MUST follow the procedures defined in section 11
of [ICE-BIS] for sending keepalives. The keepalives MUST be sent of [ICE-BIS] for sending keepalives. The keepalives MUST be sent
regardless of whether the data stream is currently inactive, regardless of whether the data stream is currently inactive,
skipping to change at page 25, line 23 skipping to change at page 25, line 23
a mechanism for indicating that an agent can support both IPv4 and a mechanism for indicating that an agent can support both IPv4 and
IPv6 for a data stream, and it does so by including two "m=" lines, IPv6 for a data stream, and it does so by including two "m=" lines,
one for v4 and one for v6. This is similar to ICE, which allows for one for v4 and one for v6. This is similar to ICE, which allows for
an agent to indicate multiple transport addresses using the candidate an agent to indicate multiple transport addresses using the candidate
attribute. However, ANAT relies on static selection to pick between attribute. However, ANAT relies on static selection to pick between
choices, rather than a dynamic connectivity check used by ICE. choices, rather than a dynamic connectivity check used by ICE.
It is RECOMMENDED that ICE be used in realizing the dual-stack use- It is RECOMMENDED that ICE be used in realizing the dual-stack use-
cases in agents that support ICE. cases in agents that support ICE.
8. Setting Ta and RTO for RTP Media Streams 8. Security Considerations
During the gathering phase of ICE and while ICE is performing
connectivity checks, an agent sends STUN and TURN transactions.
These transactions are paced at a rate of one every Ta milliseconds,
and utilize a specific RTO. See Section 14 of [ICE-BIS] for details
on how the values of Ta and RTO are computed with a real-time media
stream of known maximum bandwidth to rate-control the ICE exchanges.
9. Security Considerations
9.1. Attacks on the Offer/Answer Exchanges 8.1. Attacks on the Offer/Answer Exchanges
An attacker that can modify or disrupt the offer/answer exchanges An attacker that can modify or disrupt the offer/answer exchanges
themselves can readily launch a variety of attacks with ICE. They themselves can readily launch a variety of attacks with ICE. They
could direct media to a target of a DoS attack, they could insert could direct media to a target of a DoS attack, they could insert
themselves into the data stream, and so on. These are similar to the themselves into the data stream, and so on. These are similar to the
general security considerations for offer/answer exchanges, and the general security considerations for offer/answer exchanges, and the
security considerations in [RFC3264] apply. These require techniques security considerations in [RFC3264] apply. These require techniques
for message integrity and encryption for offers and answers, which for message integrity and encryption for offers and answers, which
are satisfied by the TLS mechanism [RFC3261] when SIP is used. As are satisfied by the TLS mechanism [RFC3261] when SIP is used. As
such, the usage of TLS with ICE is RECOMMENDED. such, the usage of TLS with ICE is RECOMMENDED.
9.2. Insider Attacks 8.2. Insider Attacks
In addition to attacks where the attacker is a third party trying to In addition to attacks where the attacker is a third party trying to
insert fake offers, answers, or STUN messages, there are several insert fake offers, answers, or STUN messages, there are several
attacks possible with ICE when the attacker is an authenticated and attacks possible with ICE when the attacker is an authenticated and
valid participant in the ICE exchange. valid participant in the ICE exchange.
9.2.1. The Voice Hammer Attack 8.2.1. The Voice Hammer Attack
The voice hammer attack is an amplification attack. In this attack, The voice hammer attack is an amplification attack. In this attack,
the attacker initiates sessions to other agents, and maliciously the attacker initiates sessions to other agents, and maliciously
includes the IP address and port of a DoS target as the destination includes the IP address and port of a DoS target as the destination
for media traffic signaled in the SDP. This causes substantial for media traffic signaled in the SDP. This causes substantial
amplification; a single offer/answer exchange can create a continuing amplification; a single offer/answer exchange can create a continuing
flood of media packets, possibly at high rates (consider video flood of media packets, possibly at high rates (consider video
sources). This attack is not specific to ICE, but ICE can help sources). This attack is not specific to ICE, but ICE can help
provide remediation. provide remediation.
skipping to change at page 26, line 33 skipping to change at page 26, line 24
However, in environments where the set of clients is known, and is However, in environments where the set of clients is known, and is
limited to ones that support ICE, the server can reject any offers or limited to ones that support ICE, the server can reject any offers or
answers that don't indicate ICE support. answers that don't indicate ICE support.
SIP User Agents (UA) [RFC3261] that are not willing to receive non- SIP User Agents (UA) [RFC3261] that are not willing to receive non-
ICE answers MUST include an "ice" Option Tag in the SIP Require ICE answers MUST include an "ice" Option Tag in the SIP Require
Header Field in their offer. UAs that rejects non-ICE offers SHOULD Header Field in their offer. UAs that rejects non-ICE offers SHOULD
use a 421 response code, together with an Option Tag "ice" in the use a 421 response code, together with an Option Tag "ice" in the
Require Header Field in the response. Require Header Field in the response.
9.2.2. Interactions with Application Layer Gateways and SIP 8.2.2. Interactions with Application Layer Gateways and SIP
Application Layer Gateways (ALGs) are functions present in a Network Application Layer Gateways (ALGs) are functions present in a Network
Address Translation (NAT) device that inspect the contents of packets Address Translation (NAT) device that inspect the contents of packets
and modify them, in order to facilitate NAT traversal for application and modify them, in order to facilitate NAT traversal for application
protocols. Session Border Controllers (SBCs) are close cousins of protocols. Session Border Controllers (SBCs) are close cousins of
ALGs, but are less transparent since they actually exist as ALGs, but are less transparent since they actually exist as
application-layer SIP intermediaries. ICE has interactions with SBCs application-layer SIP intermediaries. ICE has interactions with SBCs
and ALGs. and ALGs.
If an ALG is SIP aware but not ICE aware, ICE will work through it as If an ALG is SIP aware but not ICE aware, ICE will work through it as
skipping to change at page 27, line 40 skipping to change at page 27, line 31
will appear to both endpoints as if the other side doesn't support will appear to both endpoints as if the other side doesn't support
ICE. This will result in ICE being disabled, and media flowing ICE. This will result in ICE being disabled, and media flowing
through the SBC, if the SBC has requested it. If, however, the SBC through the SBC, if the SBC has requested it. If, however, the SBC
passes the ICE attributes without modification, yet modifies the passes the ICE attributes without modification, yet modifies the
default destination for media (contained in the "m=" and "c=" lines default destination for media (contained in the "m=" and "c=" lines
and rtcp attribute), this will be detected as an ICE mismatch, and and rtcp attribute), this will be detected as an ICE mismatch, and
ICE processing is aborted for the call. It is outside of the scope 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 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. present, ICE will not be used and the SBC techniques take precedence.
10. IANA Considerations 9. IANA Considerations
10.1. SDP Attributes 9.1. SDP Attributes
The original ICE specification defined seven new SDP attributes per The original ICE specification defined seven new SDP attributes per
the procedures of Section 8.2.4 of [RFC4566]. The registration the procedures of Section 8.2.4 of [RFC4566]. The registration
information from the original specification is included here with information from the original specification is included here with
modifications to include Mux Category and also defines a new SDP modifications to include Mux Category and also defines a new SDP
attribute 'ice-pacing'. attribute 'ice-pacing'.
10.1.1. candidate Attribute 9.1.1. candidate Attribute
Attribute Name: candidate Attribute Name: candidate
Type of Attribute: media-level Type of Attribute: media-level
Subject to charset: No Subject to charset: No
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
skipping to change at page 28, line 29 skipping to change at page 28, line 17
Appropriate Values: See Section 4 of RFC XXXX. Appropriate Values: See Section 4 of RFC XXXX.
Contact Name: IESG Contact Name: IESG
Contact e-mail: iesg@ietf.org [1] Contact e-mail: iesg@ietf.org [1]
Reference: RFCXXXX Reference: RFCXXXX
Mux Category: TRANSPORT Mux Category: TRANSPORT
10.1.2. remote-candidates Attribute 9.1.2. remote-candidates Attribute
Attribute Name: remote-candidates Attribute Name: remote-candidates
Type of Attribute: media-level Type of Attribute: media-level
Subject to charset: No Subject to charset: No
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
skipping to change at page 29, line 5 skipping to change at page 28, line 40
Appropriate Values: See Section 4 of RFC XXXX. Appropriate Values: See Section 4 of RFC XXXX.
Contact Name: IESG Contact Name: IESG
Contact e-mail: iesg@ietf.org [2] Contact e-mail: iesg@ietf.org [2]
Reference: RFCXXXX Reference: RFCXXXX
Mux Category: TRANSPORT Mux Category: TRANSPORT
10.1.3. ice-lite Attribute 9.1.3. ice-lite Attribute
Attribute Name: ice-lite Attribute Name: ice-lite
Type of Attribute: session-level Type of Attribute: session-level
Subject to charset: No Subject to charset: No
Purpose: This attribute is used with Interactive Connectivity Purpose: This attribute is used with Interactive Connectivity
Establishment (ICE), and indicates that an agent has the minimum Establishment (ICE), and indicates that an agent has the minimum
functionality required to support ICE inter-operation with a peer functionality required to support ICE inter-operation with a peer
skipping to change at page 29, line 28 skipping to change at page 29, line 15
Appropriate Values: See Section 4 of RFC XXXX. Appropriate Values: See Section 4 of RFC XXXX.
Contact Name: IESG Contact Name: IESG
Contact e-mail: iesg@ietf.org [3] Contact e-mail: iesg@ietf.org [3]
Reference: RFCXXXX Reference: RFCXXXX
Mux Category: NORMAL Mux Category: NORMAL
10.1.4. ice-mismatch Attribute 9.1.4. ice-mismatch Attribute
Attribute Name: ice-mismatch Attribute Name: ice-mismatch
Type of Attribute: media-level Type of Attribute: media-level
Subject to charset: No Subject to charset: No
Purpose: This attribute is used with Interactive Connectivity Purpose: This attribute is used with Interactive Connectivity
Establishment (ICE), and indicates that an agent is ICE capable, Establishment (ICE), and indicates that an agent is ICE capable,
but did not proceed with ICE due to a mismatch of candidates with but did not proceed with ICE due to a mismatch of candidates with
skipping to change at page 30, line 5 skipping to change at page 29, line 38
Appropriate Values: See Section 4 of RFC XXXX. Appropriate Values: See Section 4 of RFC XXXX.
Contact Name: IESG Contact Name: IESG
Contact e-mail: iesg@ietf.org [4] Contact e-mail: iesg@ietf.org [4]
Reference: RFCXXXX Reference: RFCXXXX
Mux Category: NORMAL Mux Category: NORMAL
10.1.5. ice-pwd Attribute 9.1.5. ice-pwd Attribute
Attribute Name: ice-pwd Attribute Name: ice-pwd
Type of Attribute: session- or media-level Type of Attribute: session- or media-level
Subject to charset: No Subject to charset: No
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.
skipping to change at page 30, line 20 skipping to change at page 30, line 4
Subject to charset: No Subject to charset: No
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 4 of RFC XXXX. Appropriate Values: See Section 4 of RFC XXXX.
Contact Name: IESG Contact Name: IESG
Contact e-mail: iesg@ietf.org [5] Contact e-mail: iesg@ietf.org [5]
Reference: RFCXXXX Reference: RFCXXXX
Mux Category: TRANSPORT Mux Category: TRANSPORT
10.1.6. ice-ufrag Attribute 9.1.6. ice-ufrag Attribute
Attribute Name: ice-ufrag Attribute Name: ice-ufrag
Type of Attribute: session- or media-level Type of Attribute: session- or media-level
Subject to charset: No Subject to charset: No
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.
skipping to change at page 31, line 5 skipping to change at page 30, line 32
Appropriate Values: See Section 4 of RFC XXXX. Appropriate Values: See Section 4 of RFC XXXX.
Contact Name: IESG Contact Name: IESG
Contact e-mail: iesg@ietf.org [6] Contact e-mail: iesg@ietf.org [6]
Reference: RFCXXXX Reference: RFCXXXX
Mux Category: TRANSPORT Mux Category: TRANSPORT
10.1.7. ice-options Attribute 9.1.7. ice-options Attribute
Attribute Name: ice-options Attribute Name: ice-options
Long Form: ice-options Long Form: ice-options
Type of Attribute: session- or media-level Type of Attribute: session-level
Subject to charset: No Subject to charset: No
Purpose: This attribute is used with Interactive Connectivity Purpose: This attribute is used with Interactive Connectivity
Establishment (ICE), and indicates the ICE options or extensions Establishment (ICE), and indicates the ICE options or extensions
used by the agent. used by the agent.
Appropriate Values: See Section 4 of RFC XXXX. Appropriate Values: See Section 4 of RFC XXXX.
Contact Name: IESG Contact Name: IESG
skipping to change at page 31, line 24 skipping to change at page 31, line 4
Purpose: This attribute is used with Interactive Connectivity Purpose: This attribute is used with Interactive Connectivity
Establishment (ICE), and indicates the ICE options or extensions Establishment (ICE), and indicates the ICE options or extensions
used by the agent. used by the agent.
Appropriate Values: See Section 4 of RFC XXXX. Appropriate Values: See Section 4 of RFC XXXX.
Contact Name: IESG Contact Name: IESG
Contact e-mail: iesg@ietf.org [7] Contact e-mail: iesg@ietf.org [7]
Reference: RFCXXXX Reference: RFCXXXX
Mux Category: NORMAL Mux Category: NORMAL
10.1.8. ice-pacing Attribute 9.1.8. ice-pacing Attribute
This specification also defines a new SDP attribute, "ice-pacing" This specification also defines a new SDP attribute, "ice-pacing"
according to the following data: according to the following data:
Attribute Name: ice-pacing Attribute Name: ice-pacing
Type of Attribute: session-level Type of Attribute: session-level
Subject to charset: No Subject to charset: No
skipping to change at page 32, line 5 skipping to change at page 31, line 33
Appropriate Values: See Section 4 of RFC XXXX. Appropriate Values: See Section 4 of RFC XXXX.
Contact Name: IESG Contact Name: IESG
Contact e-mail: iesg@ietf.org [8] Contact e-mail: iesg@ietf.org [8]
Reference: RFCXXXX Reference: RFCXXXX
Mux Category: NORMAL Mux Category: NORMAL
10.2. Interactive Connectivity Establishment (ICE) Options Registry 9.2. Interactive Connectivity Establishment (ICE) Options Registry
IANA maintains a registry for ice-options identifiers under the IANA maintains a registry for ice-options identifiers under the
Specification Required policy as defined in "Guidelines for Writing Specification Required policy as defined in "Guidelines for Writing
an IANA Considerations Section in RFCs" [RFC5226]. an IANA Considerations Section in RFCs" [RFC5226].
ICE options are of unlimited length according to the syntax in ICE options are of unlimited length according to the syntax in
Section 4.6; however, they are RECOMMENDED to be no longer than 20 Section 4.6; however, they are RECOMMENDED to be no longer than 20
characters. This is to reduce message sizes and allow for efficient characters. This is to reduce message sizes and allow for efficient
parsing. parsing. ICE options are defined at the session leve..
In [RFC5245] ICE options could only be defined at the session level.
ICE options can now also be defined at the media level. This can be
used when aggregating between different ICE agents in the same
endpoint, but future options may require to be defined at the media-
level. To ensure compatibility with legacy implementation, the
media-level ICE options MUST be aggregated into a session-level ICE
option. Because aggregation rules depend on the specifics of each
option, all new ICE options MUST also define in their specification
how the media-level ICE option values are aggregated to generate the
value of the session-level ICE option.
[RFC6679] defines the "rtp+ecn" ICE option. The aggregation rule for
this ICE option is that if all aggregated media using ICE contain a
media-level "rtp+ecn" ICE option then an "rtp+ecn" ICE option MUST be
inserted at the session-level. If one of the media does not contain
the option, then it MUST NOT be inserted at the session-level.
Section 10 of [ICE-BIS] defines "ice2" ICE option. Since "ice2" is a
session level ICE option, no aggregation rules apply.
A registration request MUST include the following information: A registration request MUST include the following information:
o The ICE option identifier to be registered o The ICE option identifier to be registered
o Name, Email, and Address of a contact person for the registration o Name, Email, and Address of a contact person for the registration
o Organization or individuals having the change control o Organization or individuals having the change control
o Short description of the ICE extension to which the option relates o Short description of the ICE extension to which the option relates
o Reference(s) to the specification defining the ICE option and the o Reference(s) to the specification defining the ICE option and the
related extensions related extensions
11. Acknowledgments 10. Acknowledgments
A large part of the text in this document was taken from [RFC5245], A large part of the text in this document was taken from [RFC5245],
authored by Jonathan Rosenberg. authored by Jonathan Rosenberg.
Some of the text in this document was taken from [RFC6336], authored Some of the text in this document was taken from [RFC6336], authored
by Magnus Westerlund and Colin Perkins. by Magnus Westerlund and Colin Perkins.
Many thanks to Christer Holmberg for providing text suggestions in Many thanks to Christer Holmberg for providing text suggestions in
Section 4 that aligns with [ICE-BIS] Section 3 that aligns with [ICE-BIS]
Thanks to Thomas Stach for text help, Roman Shpount for suggesting Thanks to Thomas Stach for text help, Roman Shpount for suggesting
RTCP candidate handling and Simon Perreault for advising on IPV6 RTCP candidate handling and Simon Perreault for advising on IPV6
address selection when candidate-address includes FQDN. address selection when candidate-address includes FQDN.
Many thanks to Flemming Andreasen for shepherd review feedback. Many thanks to Flemming Andreasen for shepherd review feedback.
Thanks to following experts for their reviews and constructive Thanks to following experts for their reviews and constructive
feedback: Christer Holmberg, Adam Roach and the MMUSIC WG. feedback: Christer Holmberg, Adam Roach and the MMUSIC WG.
12. References 11. References
12.1. Normative References 11.1. Normative References
[ICE-BIS] Keranen, A. and J. Rosenberg, "Interactive Connectivity [ICE-BIS] Keranen, A. and J. Rosenberg, "Interactive Connectivity
Establishment (ICE): A Protocol for Network Address Establishment (ICE): A Protocol for Network Address
Translator (NAT) Traversal for Offer/Answer Protocols", Translator (NAT) Traversal for Offer/Answer Protocols",
draft-ietf-ice-rfc5245bis-00 (work in progress), March draft-ietf-ice-rfc5245bis-00 (work in progress), March
2015. 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
skipping to change at page 35, line 26 skipping to change at page 34, line 31
[RFC5768] Rosenberg, J., "Indicating Support for Interactive [RFC5768] Rosenberg, J., "Indicating Support for Interactive
Connectivity Establishment (ICE) in the Session Initiation Connectivity Establishment (ICE) in the Session Initiation
Protocol (SIP)", RFC 5768, DOI 10.17487/RFC5768, April Protocol (SIP)", RFC 5768, DOI 10.17487/RFC5768, April
2010, <http://www.rfc-editor.org/info/rfc5768>. 2010, <http://www.rfc-editor.org/info/rfc5768>.
[RFC6336] Westerlund, M. and C. Perkins, "IANA Registry for [RFC6336] Westerlund, M. and C. Perkins, "IANA Registry for
Interactive Connectivity Establishment (ICE) Options", Interactive Connectivity Establishment (ICE) Options",
RFC 6336, April 2010, RFC 6336, April 2010,
<http://www.rfc-editor.org/info/rfc6336>. <http://www.rfc-editor.org/info/rfc6336>.
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
and K. Carlberg, "Explicit Congestion Notification (ECN)
for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August
2012, <http://www.rfc-editor.org/info/rfc6679>.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012, (IPv6)", RFC 6724, September 2012,
<http://www.rfc-editor.org/info/rfc6724>. <http://www.rfc-editor.org/info/rfc6724>.
12.2. Informative References 11.2. Informative References
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
Camarillo, "Best Current Practices for Third Party Call Camarillo, "Best Current Practices for Third Party Call
Control (3pcc) in the Session Initiation Protocol (SIP)", Control (3pcc) in the Session Initiation Protocol (SIP)",
BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004, BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004,
<http://www.rfc-editor.org/info/rfc3725>. <http://www.rfc-editor.org/info/rfc3725>.
[RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing [RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing
Tone Generation in the Session Initiation Protocol (SIP)", Tone Generation in the Session Initiation Protocol (SIP)",
RFC 3960, DOI 10.17487/RFC3960, December 2004, RFC 3960, DOI 10.17487/RFC3960, December 2004,
skipping to change at page 36, line 17 skipping to change at page 35, line 17
Initiation Protocol (SIP)", RFC 5626, Initiation Protocol (SIP)", RFC 5626,
DOI 10.17487/RFC5626, October 2009, DOI 10.17487/RFC5626, October 2009,
<http://www.rfc-editor.org/info/rfc5626>. <http://www.rfc-editor.org/info/rfc5626>.
[RFC5898] Andreasen, F., Camarillo, G., Oran, D., and D. Wing, [RFC5898] Andreasen, F., Camarillo, G., Oran, D., and D. Wing,
"Connectivity Preconditions for Session Description "Connectivity Preconditions for Session Description
Protocol (SDP) Media Streams", RFC 5898, Protocol (SDP) Media Streams", RFC 5898,
DOI 10.17487/RFC5898, July 2010, DOI 10.17487/RFC5898, July 2010,
<http://www.rfc-editor.org/info/rfc5898>. <http://www.rfc-editor.org/info/rfc5898>.
11.3. URIs
[1] mailto:iesg@ietf.org
[2] mailto:iesg@ietf.org
[3] mailto:iesg@ietf.org
[4] mailto:iesg@ietf.org
[5] mailto:iesg@ietf.org
[6] mailto:iesg@ietf.org
[7] mailto:iesg@ietf.org
[8] mailto:iesg@ietf.org
[9] mailto:christer.holmberg@ericsson.com
[10] mailto:rshpount@turbobridge.com
[11] mailto:thomass.stach@gmail.com
Appendix A. Examples Appendix A. Examples
For the example shown in section 16 of [ICE-BIS] the resulting offer For the example shown in section 16 of [ICE-BIS] the resulting offer
(message 5) encoded in SDP looks like: (message 5) encoded in SDP looks like:
v=0 v=0
o=jdoe 2890844526 2890842807 IN IP6 $L-PRIV-1.IP o=jdoe 2890844526 2890842807 IN IP6 $L-PRIV-1.IP
s= s=
c=IN IP6 $NAT-PUB-1.IP c=IN IP6 $NAT-PUB-1.IP
t=0 0 t=0 0
 End of changes. 39 change blocks. 
115 lines changed or deleted 104 lines changed or added

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