draft-ietf-mmusic-ice-sip-sdp-05.txt   draft-ietf-mmusic-ice-sip-sdp-06.txt 
MMUSIC M. Petit-Huguenin MMUSIC M. Petit-Huguenin
Internet-Draft Impedance Mismatch Internet-Draft Impedance Mismatch
Intended status: Standards Track A. Keranen Intended status: Standards Track A. Keranen
Expires: September 10, 2015 Ericsson Expires: March 13, 2016 Ericsson
March 9, 2015 S. Nandakumar
Cisco Systems
September 10, 2015
Using Interactive Connectivity Establishment (ICE) with Using Interactive Connectivity Establishment (ICE) with
Session Description Protocol (SDP) offer/answer and Session Initiation Session Description Protocol (SDP) offer/answer and Session Initiation
Protocol (SIP) Protocol (SIP)
draft-ietf-mmusic-ice-sip-sdp-05 draft-ietf-mmusic-ice-sip-sdp-06
Abstract Abstract
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
and Session Initiation Protocol (SIP). and Session Initiation Protocol (SIP).
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 35 skipping to change at page 1, line 37
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 September 10, 2015. This Internet-Draft will expire on March 13, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 3, line 13 skipping to change at page 3, line 14
9.2.1. Procedures for All Implementations . . . . . . . . . 17 9.2.1. Procedures for All Implementations . . . . . . . . . 17
9.2.2. Procedures for Full Implementations . . . . . . . . . 18 9.2.2. Procedures for Full Implementations . . . . . . . . . 18
9.2.3. Procedures for Lite Implementations . . . . . . . . . 19 9.2.3. Procedures for Lite Implementations . . . . . . . . . 19
9.3. Receiving the Answer for a Subsequent Offer . . . . . . . 20 9.3. Receiving the Answer for a Subsequent Offer . . . . . . . 20
9.3.1. Procedures for All Implementations . . . . . . . . . 20 9.3.1. Procedures for All Implementations . . . . . . . . . 20
9.4. Updating the Check and Valid Lists . . . . . . . . . . . 21 9.4. Updating the Check and Valid Lists . . . . . . . . . . . 21
9.4.1. Procedures for Full Implementations . . . . . . . . . 21 9.4.1. Procedures for Full Implementations . . . . . . . . . 21
9.4.2. Procedures for Lite Implementations . . . . . . . . . 22 9.4.2. Procedures for Lite Implementations . . . . . . . . . 22
10. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 23
11. Media Handling . . . . . . . . . . . . . . . . . . . . . . . 23 11. Media Handling . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. Sending Media . . . . . . . . . . . . . . . . . . . . . 23 12. Usage with SIP . . . . . . . . . . . . . . . . . . . . . . . 23
11.1.1. Procedures for All Implementations . . . . . . . . . 23 12.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . 23
11.2. Receiving Media . . . . . . . . . . . . . . . . . . . . 23
12. Usage with SIP . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . 24
12.1.1. Offer in INVITE . . . . . . . . . . . . . . . . . . 24 12.1.1. Offer in INVITE . . . . . . . . . . . . . . . . . . 24
12.1.2. Offer in Response . . . . . . . . . . . . . . . . . 26 12.1.2. Offer in Response . . . . . . . . . . . . . . . . . 25
12.2. SIP Option Tags and Media Feature Tags . . . . . . . . . 26 12.2. SIP Option Tags and Media Feature Tags . . . . . . . . . 25
12.3. Interactions with Forking . . . . . . . . . . . . . . . 26 12.3. Interactions with Forking . . . . . . . . . . . . . . . 26
12.4. Interactions with Preconditions . . . . . . . . . . . . 27 12.4. Interactions with Preconditions . . . . . . . . . . . . 26
12.5. Interactions with Third Party Call Control . . . . . . . 27 12.5. Interactions with Third Party Call Control . . . . . . . 26
13. Relationship with ANAT . . . . . . . . . . . . . . . . . . . 27 13. Relationship with ANAT . . . . . . . . . . . . . . . . . . . 27
14. Setting Ta and RTO for RTP Media Streams . . . . . . . . . . 28 14. Setting Ta and RTO for RTP Media Streams . . . . . . . . . . 27
15. Security Considerations . . . . . . . . . . . . . . . . . . . 30 15. Security Considerations . . . . . . . . . . . . . . . . . . . 27
15.1. Attacks on the Offer/Answer Exchanges . . . . . . . . . 30 15.1. Attacks on the Offer/Answer Exchanges . . . . . . . . . 27
15.2. Insider Attacks . . . . . . . . . . . . . . . . . . . . 30 15.2. Insider Attacks . . . . . . . . . . . . . . . . . . . . 28
15.2.1. The Voice Hammer Attack . . . . . . . . . . . . . . 30 15.2.1. The Voice Hammer Attack . . . . . . . . . . . . . . 28
15.2.2. Interactions with Application Layer Gateways and SIP 30 15.2.2. Interactions with Application Layer Gateways and SIP 28
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
16.1. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 32 16.1. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 29
16.1.1. candidate Attribute . . . . . . . . . . . . . . . . 32 16.1.1. candidate Attribute . . . . . . . . . . . . . . . . 29
16.1.2. remote-candidates Attribute . . . . . . . . . . . . 32 16.1.2. remote-candidates Attribute . . . . . . . . . . . . 30
16.1.3. ice-lite Attribute . . . . . . . . . . . . . . . . . 33 16.1.3. ice-lite Attribute . . . . . . . . . . . . . . . . . 30
16.1.4. ice-mismatch Attribute . . . . . . . . . . . . . . . 33 16.1.4. ice-mismatch Attribute . . . . . . . . . . . . . . . 31
16.1.5. ice-pwd Attribute . . . . . . . . . . . . . . . . . 33 16.1.5. ice-pwd Attribute . . . . . . . . . . . . . . . . . 31
16.1.6. ice-ufrag Attribute . . . . . . . . . . . . . . . . 34 16.1.6. ice-ufrag Attribute . . . . . . . . . . . . . . . . 32
16.1.7. ice-pacing Attribute . . . . . . . . . . . . . . . . 34 16.1.7. ice-pacing Attribute . . . . . . . . . . . . . . . . 32
16.1.8. ice-options Attribute . . . . . . . . . . . . . . . 35 16.1.8. ice-options Attribute . . . . . . . . . . . . . . . 32
16.2. Interactive Connectivity Establishment (ICE) Options 16.2. Interactive Connectivity Establishment (ICE) Options
Registry . . . . . . . . . . . . . . . . . . . . . . . . 35 Registry . . . . . . . . . . . . . . . . . . . . . . . . 33
17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
18.1. Normative References . . . . . . . . . . . . . . . . . . 36 18.1. Normative References . . . . . . . . . . . . . . . . . . 34
18.2. Informative References . . . . . . . . . . . . . . . . . 38 18.2. Informative References . . . . . . . . . . . . . . . . . 36
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 38 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 36
Appendix B. The remote-candidates Attribute . . . . . . . . . . 40 Appendix B. The remote-candidates Attribute . . . . . . . . . . 38
Appendix C. Why Is the Conflict Resolution Mechanism Needed? . . 41 Appendix C. Why Is the Conflict Resolution Mechanism Needed? . . 38
Appendix D. Why Send an Updated Offer? . . . . . . . . . . . . . 42 Appendix D. Why Send an Updated Offer? . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
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
and Session Initiation Protocol (SIP). The ICE specification [RFC3264] and Session Initiation Protocol (SIP). The ICE
[ICE-BIS] describes procedures that are common to all usages of ICE specification [ICE-BIS] describes procedures that are common to all
and this document gives the additional details needed to use ICE with usages of ICE and this document gives the additional details needed
SIP and SDP offer/answer. to use ICE with SDP offer/answer and SIP.
Note that ICE is not intended for NAT traversal for SIP, which is Note that ICE is not intended for NAT traversal for SIP, which is
assumed to be provided via another mechanism [RFC5626]. assumed to be provided via another mechanism [RFC5626].
2. Terminology 2. 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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119]. 2119 [RFC2119].
This document uses the terms defined in [ICE-BIS] and the following: Readers should be familiar with the terminology defined in [RFC3264],
in [ICE-BIS] and the following:
Default Destination/Candidate: The default destination for a Default Destination/Candidate: The default destination for a
component of a media stream is the transport address that would be component of a media stream is the transport address that would be
used by an agent that is not ICE aware. A default candidate for a used by an agent that is not ICE aware. A default candidate for a
component is one whose transport address matches the default component is one whose transport address matches the default
destination for that component. For the RTP component, the destination for that component. For the RTP component, the
default IP address is in the c line of the SDP, and the port is in default IP address is in the "c=" line of the SDP, and the port is
the m line. For the RTCP component, it is in the rtcp attribute in the "m=" line. For the RTCP component, it is in the rtcp
when present, and when not present, the IP address is in the c attribute when present, and when not present, the IP address is in
line and 1 plus the port is in the m line. the "c=" line and 1 plus the port is in the "m=" line.
3. Sending the Initial Offer 3. Sending the Initial Offer
3.1. Choosing Default Candidates 3.1. Choosing Default Candidates
A candidate is said to be default if it would be the target of media A candidate is said to be default if it would be the target of media
from a non-ICE peer; that target is called the DEFAULT DESTINATION. from a non-ICE peer; that target is called the DEFAULT DESTINATION.
If the default candidates are not selected by the ICE algorithm when If the default candidates are not selected by the ICE algorithm when
communicating with an ICE-aware peer, an updated offer/answer will be communicating with an ICE-aware peer, an updated offer/answer will be
required after ICE processing completes in order to "fix up" the SDP required after ICE processing completes in order to "fix up" the SDP
skipping to change at page 5, line 19 skipping to change at page 5, line 19
contacted if ICE is not being used. It is RECOMMENDED that the contacted if ICE is not being used. It is RECOMMENDED that the
default candidates are the relayed candidates (if relayed candidates default candidates are the relayed candidates (if relayed candidates
are available), server reflexive candidates (if server reflexive are available), server reflexive candidates (if server reflexive
candidates are available), and finally host candidates. candidates are available), and finally host candidates.
3.2. Encoding the SDP 3.2. Encoding the SDP
The process of encoding the SDP is identical between full and lite The process of encoding the SDP is identical between full and lite
implementations. implementations.
The agent will include an m line for each media stream it wishes to The agent will include an "m=" line for each media stream it wishes
use. The ordering of media streams in the SDP is relevant for ICE. to use. The ordering of media streams in the SDP is relevant for
ICE will perform its connectivity checks for the first m line first, ICE. ICE will perform its connectivity checks for the first "m="
and consequently media will be able to flow for that stream first. line first, and consequently media will be able to flow for that
Agents SHOULD place their most important media stream, if there is stream first. Agents SHOULD place their most important media stream,
one, first in the SDP. if there is one, first in the SDP.
There will be a candidate attribute for each candidate for a There will be a candidate attribute for each candidate for a
particular media stream. Section 8 provides detailed rules for particular media stream. Section 8 provides detailed rules for
constructing this attribute. constructing this attribute.
STUN connectivity checks between agents are authenticated using the STUN connectivity checks between agents are authenticated using the
short-term credential mechanism defined for STUN [RFC5389]. This short-term credential mechanism defined for STUN [RFC5389]. This
mechanism relies on a username and password that are exchanged mechanism relies on a username and password that are exchanged
through protocol machinery between the client and server. The through protocol machinery between the client and server. The
username fragment and password are exchanged in the ice-ufrag and username fragment and password are exchanged in the ice-ufrag and
ice-pwd attributes, respectively. ice-pwd attributes, respectively.
If an agent is a lite implementation, it MUST include an "a=ice-lite" If an agent is a lite implementation, it MUST include an "a=ice-lite"
session-level attribute in its SDP to indicate this. If an agent is session-level attribute in its SDP to indicate this. If an agent is
a full implementation, it MUST NOT include this attribute. a full implementation, it MUST NOT include this attribute.
The default candidates are added to the SDP as the default The default candidates are added to the SDP as the default
destination for media. For streams based on RTP, this is done by destination for media. For streams based on RTP, this is done by
placing the IP address and port of the RTP candidate into the c and m placing the IP address and port of the RTP candidate into the "c="
lines, respectively. If the agent is utilizing RTCP, it MUST encode and "m=" lines, respectively. If the agent is utilizing RTCP, it
the RTCP candidate using the a=rtcp attribute as defined in RFC 3605 MUST encode the RTCP candidate using the a=rtcp attribute as defined
[RFC3605]. If RTCP is not in use, the agent MUST signal that using in RFC 3605 [RFC3605]. If RTCP is not in use, the agent MUST signal
b=RS:0 and b=RR:0 as defined in RFC 3556 [RFC3556]. that using b=RS:0 and b=RR:0 as defined in RFC 3556 [RFC3556].
The transport addresses that will be the default destination for The transport addresses that will be the default destination for
media when communicating with non-ICE peers MUST also be present as media when communicating with non-ICE peers MUST also be present as
candidates in one or more a=candidate lines. candidates in one or more a=candidate lines.
ICE provides for extensibility by allowing an offer or answer to ICE provides for extensibility by allowing an offer or answer to
contain a series of tokens that identify the ICE extensions used by contain a series of tokens that identify the ICE extensions used by
that agent. If an agent supports an ICE extension, it MUST include that agent. If an agent supports an ICE extension, it MUST include
the token defined for that extension in the ice-options attribute. the token defined for that extension in the ice-options attribute.
skipping to change at page 6, line 49 skipping to change at page 6, line 49
identical to the process followed by the offerer, as described in identical to the process followed by the offerer, as described in
Section 3.1 for full implementations and 4.2 of [ICE-BIS] for lite Section 3.1 for full implementations and 4.2 of [ICE-BIS] for lite
implementations. implementations.
4.2. Verifying ICE Support 4.2. Verifying ICE Support
The agent will proceed with the ICE procedures defined in [ICE-BIS] The agent will proceed with the ICE procedures defined in [ICE-BIS]
and this specification if, for each media stream in the SDP it and this specification if, for each media stream in the SDP it
received, the default destination for each component of that media received, the default destination for each component of that media
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, respectively, RTP, the IP address and port in the "c=" and "m=" lines,
appear in a candidate attribute and the value in the rtcp attribute respectively, appear in a candidate attribute and the value in the
appears in a candidate attribute. rtcp attribute appears in a candidate attribute.
If this condition is not met, the agent MUST process the SDP based on If this condition is not met, the agent MUST process the SDP based on
normal RFC 3264 procedures, without using any of the ICE mechanisms normal RFC 3264 procedures, without using any of the ICE mechanisms
described in the remainder of this specification with the following described in the remainder of this specification with the following
exceptions: exceptions:
1. The agent MUST follow the rules of section 9 of [ICE-BIS], which 1. The agent MUST follow the rules of section 10 of [ICE-BIS], which
describe keepalive procedures for all agents. describe keepalive procedures for all agents.
2. If the agent is not proceeding with ICE because there were 2. If the agent is not proceeding with ICE because there were
a=candidate attributes, but none that matched the default a=candidate attributes, but none that matched the default
destination of the media stream, the agent MUST include an a=ice- destination of the media stream, the agent MUST include an a=ice-
mismatch attribute in its answer. mismatch attribute in its answer.
3. If the default candidates were relayed candidates learned through 3. If the default candidates were relayed candidates learned through
a TURN server, the agent MUST create permissions in the TURN a TURN server, the agent MUST create permissions in the TURN
server for the IP addresses learned from its peer in the SDP it server for the IP addresses learned from its peer in the SDP it
skipping to change at page 8, line 23 skipping to change at page 8, line 23
The possibility for role conflicts described in Section 7.2.1.1 of The possibility for role conflicts described in Section 7.2.1.1 of
[ICE-BIS] applies to this usage and hence all full agents MUST [ICE-BIS] applies to this usage and hence all full agents MUST
implement the role conflict repairing mechanism. Also both full and implement the role conflict repairing mechanism. Also both full and
lite agents MUST utilize the ICE-CONTROLLED and ICE-CONTROLLING lite agents MUST utilize the ICE-CONTROLLED and ICE-CONTROLLING
attributes as described in Section 7.1.2.2 of [ICE-BIS]. attributes as described in Section 7.1.2.2 of [ICE-BIS].
7. Concluding ICE 7. Concluding ICE
Once all of the media streams are completed, the controlling endpoint Once all of the media streams are completed, the controlling endpoint
sends an updated offer if the candidates in the m and c lines for the sends an updated offer if the transport destination in the "m=" and
media stream (called the DEFAULT CANDIDATES) don't match ICE's "c=" lines for the media stream (called the DEFAULT CANDIDATES) don't
SELECTED CANDIDATES. match ICE's SELECTED CANDIDATES.
7.1. Procedures for Full Implementations 7.1. Procedures for Full Implementations
7.1.1. Updating states 7.1.1. Updating states
Once the state of each check list is Completed, If an agent is Once the state of each check list is Completed, If an agent is
controlling, it examines the highest-priority nominated candidate controlling, it examines the highest-priority nominated candidate
pair for each component of each media stream. If any of those pair for each component of each media stream. If any of those
candidate pairs differ from the default candidate pairs in the most candidate pairs differ from the default candidate pairs in the most
recent offer/answer exchange, the controlling agent MUST generate an recent offer/answer exchange, the controlling agent MUST generate an
skipping to change at page 10, line 42 skipping to change at page 10, line 42
same type, share the same base, and come from the same STUN same type, share the same base, and come from the same STUN
server. The foundation is used to optimize ICE performance in the server. The foundation is used to optimize ICE performance in the
Frozen algorithm. Frozen algorithm.
<component-id>: is a positive integer between 1 and 256 that <component-id>: is a positive integer between 1 and 256 that
identifies the specific component of the media stream for which identifies the specific component of the media stream for which
this is a candidate. It MUST start at 1 and MUST increment by 1 this is a candidate. It MUST start at 1 and MUST increment by 1
for each component of a particular candidate. For media streams for each component of a particular candidate. For media streams
based on RTP, candidates for the actual RTP media MUST have a based on RTP, candidates for the actual RTP media MUST have a
component ID of 1, and candidates for RTCP MUST have a component component ID of 1, and candidates for RTCP MUST have a component
ID of 2. See section 11 in [ICE-BIS] for additional discussion on ID of 2. See section 12 in [ICE-BIS] for additional discussion on
extending ICE to new media streams. extending ICE to new media streams.
<priority>: is a positive integer between 1 and (2**31 - 1). <priority>: is a positive integer between 1 and (2**31 - 1).
<cand-type>: encodes the type of candidate. This specification <cand-type>: encodes the type of candidate. This specification
defines the values "host", "srflx", "prflx", and "relay" for host, defines the values "host", "srflx", "prflx", and "relay" for host,
server reflexive, peer reflexive, and relayed candidates, server reflexive, peer reflexive, and relayed candidates,
respectively. The set of candidate types is extensible for the respectively. The set of candidate types is extensible for the
future. future.
skipping to change at page 12, line 48 skipping to change at page 12, line 48
implementations. Its large upper limit allows for increased amounts implementations. Its large upper limit allows for increased amounts
of randomness to be added over time. For compatibility with the 512 of randomness to be added over time. For compatibility with the 512
character limitation for the STUN username attribute value and for character limitation for the STUN username attribute value and for
bandwidth conservation considerations, the ice-ufrag attribute MUST bandwidth conservation considerations, the ice-ufrag attribute MUST
NOT be longer than 32 characters when sending, but an implementation NOT be longer than 32 characters when sending, but an implementation
MUST accept up to 256 characters when receiving. MUST accept up to 256 characters when receiving.
8.5. "ice-pacing" Attribute 8.5. "ice-pacing" Attribute
The "ice-pacing" attribute indicates the desired connectivity check The "ice-pacing" attribute indicates the desired connectivity check
pacing, in milliseconds, for this agent (see Section 12.2 of pacing, in milliseconds, for this agent (see Section 13 of
[ICE-BIS]). The syntax is: [ICE-BIS]). The syntax is:
ice-pacing-att = "ice-pacing" ":" pacing-value ice-pacing-att = "ice-pacing" ":" pacing-value
pacing-value = 1*10DIGIT pacing-value = 1*10DIGIT
8.6. "ice-options" Attribute 8.6. "ice-options" Attribute
The "ice-options" attribute is a session- and media-level attribute. The "ice-options" attribute is a session- and media-level attribute.
It contains a series of tokens that identify the options supported by It contains a series of tokens that identify the options supported by
the agent. Its grammar is: the agent. Its grammar is:
skipping to change at page 14, line 13 skipping to change at page 14, line 13
target of the media stream. In other words, if an agent wants to target of the media stream. In other words, if an agent wants to
generate an updated offer that, had ICE not been in use, would generate an updated offer that, had ICE not been in use, would
result in a new value for the destination of a media component. result in a new value for the destination of a media component.
o An agent is changing its implementation level. This typically o An agent is changing its implementation level. This typically
only happens in third party call control use cases, where the only happens in third party call control use cases, where the
entity performing the signaling is not the entity receiving the entity performing the signaling is not the entity receiving the
media, and it has changed the target of media mid-session to media, and it has changed the target of media mid-session to
another entity that has a different ICE implementation. another entity that has a different ICE implementation.
These rules imply that setting the IP address in the c line to These rules imply that setting the IP address in the "c=" line to
0.0.0.0 will cause an ICE restart. Consequently, ICE implementations 0.0.0.0 will cause an ICE restart. Consequently, ICE implementations
MUST NOT utilize this mechanism for call hold, and instead MUST use MUST NOT utilize this mechanism for call hold, and instead MUST use
a=inactive and a=sendonly as described in [RFC3264]. a=inactive and 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 media stream in an offer. Note that it is permissible ufrag for the media 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.
skipping to change at page 15, line 40 skipping to change at page 15, line 40
initial offers, there MUST be a set of candidate attributes in the initial offers, there MUST be a set of candidate attributes in the
offer matching this default destination. offer matching this default destination.
9.1.2.2. Existing Media Streams with ICE Completed 9.1.2.2. Existing Media Streams with ICE Completed
If an agent generates an updated offer including a media stream that If an agent generates an updated offer including a media stream that
was previously established, and for which ICE checks are in the was previously established, and for which ICE checks are in the
Completed state, the agent follows the procedures defined here. Completed state, the agent follows the procedures defined here.
The default destination for media (i.e., the values of the IP The default destination for media (i.e., the values of the IP
addresses and ports in the m and c lines used for that media stream) addresses and ports in the "m=" and "c=" lines used for that media
MUST be the local candidate from the highest-priority nominated pair stream) MUST be the local candidate from the highest-priority
in the valid list for each component. This "fixes" the default nominated pair in the valid list for each component. This "fixes"
destination for media to equal the destination ICE has selected for the default destination for media to equal the destination ICE has
media. selected for media.
The agent MUST include candidate attributes for candidates matching The agent MUST include candidate attributes for candidates matching
the default destination for each component of the media stream, and the default destination for each component of the media stream, and
MUST NOT include any other candidates. MUST NOT include any other candidates.
In addition, if the agent is controlling, it MUST include the In addition, if the agent is controlling, it MUST include the
a=remote-candidates attribute for each media stream whose check list a=remote-candidates attribute for each media stream whose check list
is in the Completed state. The attribute contains the remote is in the Completed state. The attribute contains the remote
candidates from the highest-priority nominated pair in the valid list candidates from the highest-priority nominated pair in the valid list
for each component of that media stream. It is needed to avoid a for each component of that media stream. It is needed to avoid a
skipping to change at page 18, line 48 skipping to change at page 18, line 48
offer to deal with a race condition between the receipt of the offer, offer to deal with a race condition between the receipt of the offer,
and the receipt of the Binding response that tells the answerer the and the receipt of the Binding response that tells the answerer the
candidate that will be selected by ICE. See Appendix B for an candidate that will be selected by ICE. See Appendix B for an
explanation of this race condition. Consequently, processing of an explanation of this race condition. Consequently, processing of an
offer with this attribute depends on the winner of the race. offer with this attribute depends on the winner of the race.
The agent forms a candidate pair for each component of the media The agent forms a candidate pair for each component of the media
stream by: stream by:
o Setting the remote candidate equal to the offerer's default o Setting the remote candidate equal to the offerer's default
destination for that component (e.g., the contents of the m and c destination for that component (e.g., the contents of the "m=" and
lines for RTP, and the a=rtcp attribute for RTCP) "c=" lines for RTP, and the a=rtcp attribute for RTCP)
o Setting the local candidate equal to the transport address for o Setting the local candidate equal to the transport address for
that same component in the a=remote-candidates attribute in the that same component in the a=remote-candidates attribute in the
offer. offer.
The agent then sees if each of these candidate pairs is present in The agent then sees if each of these candidate pairs is present in
the valid list. If a particular pair is not in the valid list, the the valid list. If a particular pair is not in the valid list, the
check has "lost" the race. Call such a pair a "losing pair". check has "lost" the race. Call such a pair a "losing pair".
The agent finds all the pairs in the check list whose remote The agent finds all the pairs in the check list whose remote
skipping to change at page 19, line 41 skipping to change at page 19, line 41
It MUST include a candidate attribute in the answer for each It MUST include a candidate attribute in the answer for each
candidate in the remote-candidates attribute in the offer. candidate in the remote-candidates attribute in the offer.
9.2.3. Procedures for Lite Implementations 9.2.3. Procedures for Lite Implementations
If the received offer contains the remote-candidates attribute for a If the received offer contains the remote-candidates attribute for a
media stream, the agent forms a candidate pair for each component of media stream, the agent forms a candidate pair for each component of
the media stream by: the media stream by:
o Setting the remote candidate equal to the offerer's default o Setting the remote candidate equal to the offerer's default
destination for that component (e.g., the contents of the m and c destination for that component (e.g., the contents of the "m=" and
lines for RTP, and the a=rtcp attribute for RTCP). "c=" lines for RTP, and the a=rtcp attribute for RTCP).
o Setting the local candidate equal to the transport address for o Setting the local candidate equal to the transport address for
that same component in the a=remote-candidates attribute in the that same component in the a=remote-candidates attribute in the
offer. offer.
It then places those candidates into the Valid list for the media It then places those candidates into the Valid list for the media
stream. The state of ICE processing for that media stream is set to stream. The state of ICE processing for that media stream is set to
Completed. Completed.
Furthermore, if the agent believed it was controlling, but the offer Furthermore, if the agent believed it was controlling, but the offer
skipping to change at page 21, line 47 skipping to change at page 21, line 47
9.4. Updating the Check and Valid Lists 9.4. Updating the Check and Valid Lists
9.4.1. Procedures for Full Implementations 9.4.1. Procedures for Full Implementations
9.4.1.1. ICE Restarts 9.4.1.1. ICE Restarts
The agent MUST remember the highest-priority nominated pairs in the The agent MUST remember the highest-priority nominated pairs in the
Valid list for each component of the media stream, called the Valid list for each component of the media stream, called the
previous selected pairs, prior to the restart. The agent will previous selected pairs, prior to the restart. The agent will
continue to send media using these pairs, as described in continue to send media using these pairs, as described in Section 11.
Section 11.1. Once these destinations are noted, the agent MUST Once these destinations are noted, the agent MUST flush the valid and
flush the valid and check lists, and then recompute the check list check lists, and then recompute the check list and its states as
and its states as described in section 6.3 of [ICE-BIS]. described in section 6.3 of [ICE-BIS].
9.4.1.2. New Media Stream 9.4.1.2. New Media Stream
If the offer/answer exchange added a new media stream, the agent MUST If the offer/answer exchange added a new media stream, the agent MUST
create a new check list for it (and an empty Valid list to start of create a new check list for it (and an empty Valid list to start of
course), as described in section 6.3 of [ICE-BIS]. course), as described in section 6.3 of [ICE-BIS].
9.4.1.3. Removed Media Stream 9.4.1.3. Removed Media Stream
If the offer/answer exchange removed a media stream, or an answer If the offer/answer exchange removed a media stream, or an answer
skipping to change at page 23, line 5 skipping to change at page 23, line 5
the agent moves the state of all Frozen pairs for the first component the agent moves the state of all Frozen pairs for the first component
of all other media streams (and thus in different check lists) with of all other media streams (and thus in different check lists) with
the same foundation to Waiting. the same foundation to Waiting.
9.4.2. Procedures for Lite Implementations 9.4.2. Procedures for Lite Implementations
If ICE is restarting for a media stream, the agent MUST start a new If ICE is restarting for a media stream, the agent MUST start a new
Valid list for that media stream. It MUST remember the pairs in the Valid list for that media stream. It MUST remember the pairs in the
previous Valid list for each component of the media stream, called previous Valid list for each component of the media stream, called
the previous selected pairs, and continue to send media there as the previous selected pairs, and continue to send media there as
described in Section 11.1. The state of ICE processing for each described in Section 11. The state of ICE processing for each media
media stream MUST change to Running, and the state of ICE processing stream MUST change to Running, and the state of ICE processing MUST
MUST change to Running. change to Running.
10. Keepalives 10. Keepalives
The procedures defined in Section 10 of [ICE-BIS] MUST be followed.
The keepalives MUST be sent regardless of whether the media stream is The keepalives MUST be sent regardless of whether the media stream is
currently inactive, sendonly, recvonly, or sendrecv, and regardless currently inactive, sendonly, recvonly, or sendrecv, and regardless
of the presence or value of the bandwidth attribute. An agent can of the presence or value of the bandwidth attribute. An agent can
determine that its peer supports ICE by the presence of a=candidate determine that its peer supports ICE by the presence of a=candidate
attributes for each media session. attributes for each media session.
11. Media Handling 11. Media Handling
11.1. Sending Media Section 11.1.3 of [ICE-BIS] defines procedures common for sending
media across Full and Lite implementations.
Note that the selected pair for a component of a media stream may not
equal the default pair for that same component from the most recent
offer/answer exchange. When this happens, the selected pair is used
for media, not the default pair. When ICE first completes, if the
selected pairs aren't a match for the default pairs, the controlling
agent sends an updated offer/answer exchange to remedy this
disparity. However, until that updated offer arrives, there will not
be a match. Furthermore, in very unusual cases, the default
candidates in the updated offer/answer will not be a match.
11.1.1. Procedures for All Implementations
ICE has interactions with jitter buffer adaptation mechanisms. An
RTP stream can begin using one candidate, and switch to another one,
though this happens rarely with ICE. The newer candidate may result
in RTP packets taking a different path through the network -- one
with different delay characteristics. As discussed below, agents are
encouraged to re-adjust jitter buffers when there are changes in
source or destination address of media packets. Furthermore, many
audio codecs use the marker bit to signal the beginning of a
talkspurt, for the purposes of jitter buffer adaptation. For such
codecs, it is RECOMMENDED that the sender set the marker bit
[RFC3550] when an agent switches transmission of media from one
candidate pair to another.
11.2. Receiving Media
ICE implementations MUST be prepared to receive media on each
component on any candidates provided for that component in the most
recent offer/answer exchange (in the case of RTP, this would include
both RTP and RTCP if candidates were provided for both).
It is RECOMMENDED that, when an agent receives an RTP packet with a Section 11.2 of [ICE-BIS] defines procedures on receiving media.
new source or destination IP address for a particular media stream,
that the agent re-adjust its jitter buffers.
RFC 3550 [RFC3550] describes an algorithm in Section 8.2 for When sending media, note that the selected pair for a component of a
detecting synchronization source (SSRC) collisions and loops. These media stream may not equal the default pair for that same component
algorithms are based, in part, on seeing different source transport from the most recen offer/answer exchange. When this happens, the
addresses with the same SSRC. However, when ICE is used, such selected pair is used for media, not the default pair. When ICE
changes will sometimes occur as the media streams switch between first completes, if the selected pairs aren't a match for the default
candidates. An agent will be able to determine that a media stream pairs, the controlling agent sends an updated offer/answer exchange
is from the same peer as a consequence of the STUN exchange that to remedy this disparity. However, until that updated offer arrives,
proceeds media transmission. Thus, if there is a change in source there will not be a match. Furthermore, in very unusual cases, the
transport address, but the media packets come from the same peer default candidates in the updated offer/answer will not be a match.
agent, this SHOULD NOT be treated as an SSRC collision.
12. Usage with SIP 12. Usage with SIP
12.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 affect selection of messages to use with offers and answers can affect
skipping to change at page 27, line 51 skipping to change at page 27, line 17
through the process of gathering new candidates. Furthermore, that through the process of gathering new candidates. Furthermore, that
list of candidates SHOULD include the ones currently being used for list of candidates SHOULD include the ones currently being used for
media. media.
13. Relationship with ANAT 13. Relationship with ANAT
RFC 4091 [RFC4091], the Alternative Network Address Types (ANAT) RFC 4091 [RFC4091], the Alternative Network Address Types (ANAT)
Semantics for the SDP grouping framework, and RFC 4092 [RFC4092], its Semantics for the SDP grouping framework, and RFC 4092 [RFC4092], its
usage with SIP, define a mechanism for indicating that an agent can usage with SIP, define a mechanism for indicating that an agent can
support both IPv4 and IPv6 for a media stream, and it does so by support both IPv4 and IPv6 for a media stream, and it does so by
including two m lines, one for v4 and one for v6. This is similar to including two "m=" lines, one for v4 and one for v6. This is similar
ICE, which allows for an agent to indicate multiple transport to ICE, which allows for an agent to indicate multiple transport
addresses using the candidate attribute. However, ANAT relies on addresses using the candidate attribute. However, ANAT relies on
static selection to pick between choices, rather than a dynamic static selection to pick between choices, rather than a dynamic
connectivity check used by ICE. connectivity check used by ICE.
This specification deprecates RFC 4091 and RFC 4092. Instead, agents This specification deprecates RFC 4091 and RFC 4092. Instead, agents
wishing to support dual-stack will utilize ICE. wishing to support dual-stack will utilize ICE.
14. Setting Ta and RTO for RTP Media Streams 14. Setting Ta and RTO for RTP Media Streams
During the gathering phase of ICE (section 4.1.1 [ICE-BIS]) and while During the gathering phase of ICE (section 4.1.1 [ICE-BIS]) and while
ICE is performing connectivity checks (section 7 [ICE-BIS]), an agent ICE is performing connectivity checks (section 7 [ICE-BIS]), an agent
sends STUN and TURN transactions. These transactions are paced at a sends STUN and TURN transactions. These transactions are paced at a
rate of one every Ta milliseconds, and utilize a specific RTO. This rate of one every Ta milliseconds, and utilize a specific RTO. See
section describes how the values of Ta and RTO are computed with a Section 13.1 of [ICE-BIS] for details on how the valies of Ta and RTO
real-time media stream (such as RTP). When ICE is used for a stream are computed with a real-time media stream of known maximum bandwith
with a known maximum bandwidth, the following computation MAY be to rate-control the ICE exchanges.
followed to rate-control the ICE exchanges.
The values of RTO and Ta change during the lifetime of ICE
processing. One set of values applies during the gathering phase,
and the other, for connectivity checks.
The value of Ta SHOULD be configurable, and SHOULD have a default of:
For each media stream i:
Ta_i = (stun_packet_size / rtp_packet_size) * rtp_ptime
1
Ta = MAX (20ms, ------------------- )
k
----
\ 1
> ------
/ Ta_i
----
i=1
where k is the number of media streams. During the gathering phase,
Ta is computed based on the number of media streams the agent has
indicated in its offer or answer, and the RTP packet size and RTP
ptime are those of the most preferred codec for each media stream.
Once an offer and answer have been exchanged, the agent recomputes Ta
to pace the connectivity checks. In that case, the value of Ta is
based on the number of media streams that will actually be used in
the session, and the RTP packet size and RTP ptime are those of the
most preferred codec with which the agent will send.
In addition, the retransmission timer for the STUN transactions, RTO,
defined in [RFC5389], SHOULD be configurable and during the gathering
phase, SHOULD have a default of:
RTO = MAX (100ms, Ta * (number of pairs))
where the number of pairs refers to the number of pairs of candidates
with STUN or TURN servers.
For connectivity checks, RTO SHOULD be configurable and SHOULD have a
default of:
RTO = MAX (100ms, Ta*N * (Num-Waiting + Num-In-Progress))
where Num-Waiting is the number of checks in the check list in the
Waiting state, and Num-In-Progress is the number of checks in the In-
Progress state. Note that the RTO will be different for each
transaction as the number of checks in the Waiting and In-Progress
states change.
These formulas are aimed at causing STUN transactions to be paced at
the same rate as media. This ensures that ICE will work properly
under the same network conditions needed to support the media as
well. See section B.1 of [ICE-BIS] for additional discussion and
motivations. Because of this pacing, it will take a certain amount
of time to obtain all of the server reflexive and relayed candidates.
Implementations should be aware of the time required to do this, and
if the application requires a time budget, limit the number of
candidates that are gathered.
The formulas result in a behavior whereby an agent will send its
first packet for every single connectivity check before performing a
retransmit. This can be seen in the formulas for the RTO (which
represents the retransmit interval). Those formulas scale with N,
the number of checks to be performed. As a result of this, ICE
maintains a nicely constant rate, but becomes more sensitive to
packet loss. The loss of the first single packet for any
connectivity check is likely to cause that pair to take a long time
to be validated, and instead, a lower-priority check (but one for
which there was no packet loss) is much more likely to complete
first. This results in ICE performing sub-optimally, choosing lower-
priority pairs over higher-priority pairs. Implementors should be
aware of this consequence, but still should utilize the timer values
described here.
15. Security Considerations 15. Security Considerations
15.1. Attacks on the Offer/Answer Exchanges 15.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 media stream, and so on. These are similar to themselves into the media 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
skipping to change at page 31, line 12 skipping to change at page 28, line 47
device that inspect the contents of packets and modify them, in order device that inspect the contents of packets and modify them, in order
to facilitate NAT traversal for application protocols. Session to facilitate NAT traversal for application protocols. Session
Border Controllers (SBCs) are close cousins of ALGs, but are less Border Controllers (SBCs) are close cousins of ALGs, but are less
transparent since they actually exist as application layer SIP transparent since they actually exist as application layer SIP
intermediaries. ICE has interactions with SBCs and ALGs. intermediaries. ICE has interactions with SBCs and ALGs.
If an ALG is SIP aware but not ICE aware, ICE will work through it as If an ALG is SIP aware but not ICE aware, ICE will work through it as
long as the ALG correctly modifies the SDP. A correct ALG long as the ALG correctly modifies the SDP. A correct ALG
implementation behaves as follows: implementation behaves as follows:
o The ALG does not modify the m and c lines or the rtcp attribute if o The ALG does not modify the "m=" and "c=" lines or the rtcp
they contain external addresses. attribute if they contain external addresses.
o If the m and c lines contain internal addresses, the modification o If the "m=" and "c=" lines contain internal addresses, the
depends on the state of the ALG: modification depends on the state of the ALG:
If the ALG already has a binding established that maps an If the ALG already has a binding established that maps an
external port to an internal IP address and port matching the external port to an internal IP address and port matching the
values in the m and c lines or rtcp attribute, the ALG uses values in the "m=" and "c=" lines or rtcp attribute, the ALG
that binding instead of creating a new one. uses that binding instead of creating a new one.
If the ALG does not already have a binding, it creates a new If the ALG does not already have a binding, it creates a new
one and modifies the SDP, rewriting the m and c lines and rtcp one and modifies the SDP, rewriting the "m=" and "c=" lines and
attribute. rtcp attribute.
Unfortunately, many ALGs are known to work poorly in these corner Unfortunately, many ALGs are known to work poorly in these corner
cases. ICE does not try to work around broken ALGs, as this is cases. ICE does not try to work around broken ALGs, as this is
outside the scope of its functionality. ICE can help diagnose these outside the scope of its functionality. ICE can help diagnose these
conditions, which often show up as a mismatch between the set of conditions, which often show up as a mismatch between the set of
candidates and the m and c lines and rtcp attributes. The ice- candidates and the "m=" and "c=" lines and rtcp attributes. The ice-
mismatch attribute is used for this purpose. mismatch attribute is used for this purpose.
ICE works best through ALGs when the signaling is run over TLS. This ICE works best through ALGs when the signaling is run over TLS. This
prevents the ALG from manipulating the SDP messages and interfering prevents the ALG from manipulating the SDP messages and interfering
with ICE operation. Implementations that are expected to be deployed with ICE operation. Implementations that are expected to be deployed
behind ALGs SHOULD provide for TLS transport of the SDP. 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 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 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 Agent (B2BUA), the SBC will remove any SDP attributes it doesn't
understand, including the ICE attributes. Consequently, the call understand, including the ICE attributes. Consequently, the call
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 and default destination for media (contained in the "m=" and "c=" lines
rtcp attribute), this will be detected as an ICE mismatch, and ICE and rtcp attribute), this will be detected as an ICE mismatch, and
processing is aborted for the call. It is outside of the scope of ICE processing is aborted for the call. It is outside of the scope
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.
16. IANA Considerations 16. IANA Considerations
16.1. SDP Attributes 16.1. SDP Attributes
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 procedures of Section 8.2.4 of [RFC4566]. The registration
information is reproduced here. information is reproduced here.
skipping to change at page 35, line 47 skipping to change at page 33, line 36
used when aggregating between different ICE agents in the same used when aggregating between different ICE agents in the same
endpoint, but future options may require to be defined at the media- endpoint, but future options may require to be defined at the media-
level. To ensure compatibility with legacy implementation, the level. To ensure compatibility with legacy implementation, the
media-level ICE options MUST be aggregated into a session-level ICE media-level ICE options MUST be aggregated into a session-level ICE
option. Because aggregation rules depend on the specifics of each option. Because aggregation rules depend on the specifics of each
option, all new ICE options MUST also define in their specification option, all new ICE options MUST also define in their specification
how the media-level ICE option values are aggregated to generate the how the media-level ICE option values are aggregated to generate the
value of the session-level ICE option. value of the session-level ICE option.
The only ICE option defined at the time of publication is "rtp+ecn" The only ICE option defined at the time of publication is "rtp+ecn"
[RFC6679]. The aggregation rule for this ICE options is that if all [RFC6679]. The aggregation rule for this ICE option is that if all
aggregated media using ICE contain a media-level "rtp+ecn" ICE option 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. 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 If one of the media does not contain the option, then it MUST NOT be
inserted at the session-level. inserted at the session-level.
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
skipping to change at page 38, line 39 skipping to change at page 36, line 29
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
Initiated Connections in the Session Initiation Protocol Initiated Connections in the Session Initiation Protocol
(SIP)", RFC 5626, October 2009. (SIP)", RFC 5626, October 2009.
[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, July 2010. Protocol (SDP) Media Streams", RFC 5898, July 2010.
Appendix A. Examples Appendix A. Examples
For the example shown in Section 13 of [ICE-BIS] the resulting offer For the example shown in Section 14 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 IP4 $L-PRIV-1.IP o=jdoe 2890844526 2890842807 IN IP4 $L-PRIV-1.IP
s= s=
c=IN IP4 $NAT-PUB-1.IP c=IN IP4 $NAT-PUB-1.IP
t=0 0 t=0 0
a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY a=ice-ufrag:8hhY
m=audio $NAT-PUB-1.PORT RTP/AVP 0 m=audio $NAT-PUB-1.PORT RTP/AVP 0
skipping to change at page 41, line 5 skipping to change at page 38, line 21
L adds a candidate pair to the valid list. If there was only a L adds a candidate pair to the valid list. If there was only a
single media stream with a single component, agent L could now send single media stream with a single component, agent L could now send
an updated offer. However, the check from agent R has not yet an updated offer. However, the check from agent R has not yet
generated a response, and agent R receives the updated offer (message generated a response, and agent R receives the updated offer (message
7) before getting the response (message 9). Thus, it does not yet 7) before getting the response (message 9). Thus, it does not yet
know that this particular pair is valid. To eliminate this know that this particular pair is valid. To eliminate this
condition, the actual candidates at R that were selected by the condition, the actual candidates at R that were selected by the
offerer (the remote candidates) are included in the offer itself, and offerer (the remote candidates) are included in the offer itself, and
the answerer delays its answer until those pairs validate. the answerer delays its answer until those pairs validate.
Agent A Network Agent B Agent L Network Agent R
|(1) Offer | | |(1) Offer | |
|------------------------------------------>| |------------------------------------------>|
|(2) Answer | | |(2) Answer | |
|<------------------------------------------| |<------------------------------------------|
|(3) STUN Req. | | |(3) STUN Req. | |
|------------------------------------------>| |------------------------------------------>|
|(4) STUN Res. | | |(4) STUN Res. | |
|<------------------------------------------| |<------------------------------------------|
|(5) STUN Req. | | |(5) STUN Req. | |
|<------------------------------------------| |<------------------------------------------|
skipping to change at page 43, line 9 skipping to change at page 40, line 17
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 function without change, the core property of SDP -- that the
existing, pre-ICE definitions of the addresses used for media -- the existing, pre-ICE definitions of the addresses used for media -- the
m and c lines and the rtcp attribute -- must be retained. For this "m=" and "c=" lines and the rtcp attribute -- must be retained. For
reason, an updated offer must be sent. this reason, an updated offer must be sent.
Authors' Addresses Authors' Addresses
Marc Petit-Huguenin Marc Petit-Huguenin
Impedance Mismatch Impedance Mismatch
Email: marc@petit-huguenin.org Email: marc@petit-huguenin.org
Ari Keranen Ari Keranen
Ericsson Ericsson
Jorvas 02420 Jorvas 02420
Finland Finland
Email: ari.keranen@ericsson.com Email: ari.keranen@ericsson.com
Suhas Nandakumar
Cisco Systems
707 Tasman Dr
Milpitas 95035
USA
Email: snandaku@cisco.com
 End of changes. 41 change blocks. 
230 lines changed or deleted 122 lines changed or added

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