draft-ietf-mmusic-ice-sip-sdp-02.txt   draft-ietf-mmusic-ice-sip-sdp-03.txt 
MMUSIC M. Petit-Huguenin MMUSIC M. Petit-Huguenin
Internet-Draft Jive Communications Internet-Draft Jive Communications
Intended status: Standards Track A. Keranen Intended status: Standards Track A. Keranen
Expires: July 14, 2014 Ericsson Expires: January 5, 2015 Ericsson
January 10, 2014 July 4, 2014
Using Interactive Connectivity Establishment (ICE) with Using Interactive Connectivity Establishment (ICE) with
Session Description Protocol (SDP) offer/answer and Session Description Protocol (SDP) offer/answer and
Session Initiation Protocol (SIP) Session Initiation Protocol (SIP)
draft-ietf-mmusic-ice-sip-sdp-02 draft-ietf-mmusic-ice-sip-sdp-03
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 35
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 July 14, 2014. This Internet-Draft will expire on January 5, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 36 skipping to change at page 2, line 28
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Sending the Initial Offer . . . . . . . . . . . . . . . . . . 4 3. Sending the Initial Offer . . . . . . . . . . . . . . . . . . 4
3.1. Choosing Default Candidates . . . . . . . . . . . . . . . 4 3.1. Choosing Default Candidates . . . . . . . . . . . . . . . 4
3.2. Encoding the SDP . . . . . . . . . . . . . . . . . . . . 5 3.2. Encoding the SDP . . . . . . . . . . . . . . . . . . . . 5
4. Receiving the Initial Offer . . . . . . . . . . . . . . . . . 6 4. Receiving the Initial Offer . . . . . . . . . . . . . . . . . 6
4.1. Choosing Default Candidates . . . . . . . . . . . . . . . 6 4.1. Choosing Default Candidates . . . . . . . . . . . . . . . 6
4.2. Verifying ICE Support . . . . . . . . . . . . . . . . . . 7 4.2. Verifying ICE Support . . . . . . . . . . . . . . . . . . 6
4.3. Determining Role . . . . . . . . . . . . . . . . . . . . 7 4.3. Determining Role . . . . . . . . . . . . . . . . . . . . 7
5. Receipt of the Initial Answer . . . . . . . . . . . . . . . . 7 5. Receipt of the Initial Answer . . . . . . . . . . . . . . . . 7
5.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 8 5.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 7
6. Performing Connectivity Checks . . . . . . . . . . . . . . . 8 6. Performing Connectivity Checks . . . . . . . . . . . . . . . 8
7. Concluding ICE . . . . . . . . . . . . . . . . . . . . . . . 8 7. Concluding ICE . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Procedures for Full Implementations . . . . . . . . . . . 8 7.1. Procedures for Full Implementations . . . . . . . . . . . 8
7.1.1. Updating states . . . . . . . . . . . . . . . . . . . 8 7.1.1. Updating states . . . . . . . . . . . . . . . . . . . 8
7.2. Freeing Candidates . . . . . . . . . . . . . . . . . . . 9 7.2. Freeing Candidates . . . . . . . . . . . . . . . . . . . 8
7.2.1. Full Implementation Procedures . . . . . . . . . . . 9 7.2.1. Full Implementation Procedures . . . . . . . . . . . 8
8. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. "candidate" Attribute . . . . . . . . . . . . . . . . . . 9 8.1. "candidate" Attribute . . . . . . . . . . . . . . . . . . 9
8.2. "remote-candidates" Attribute . . . . . . . . . . . . . . 11 8.2. "remote-candidates" Attribute . . . . . . . . . . . . . . 11
8.3. "ice-lite" and "ice-mismatch" Attributes . . . . . . . . 12 8.3. "ice-lite" and "ice-mismatch" Attributes . . . . . . . . 11
8.4. "ice-ufrag" and "ice-pwd" Attributes . . . . . . . . . . 12 8.4. "ice-ufrag" and "ice-pwd" Attributes . . . . . . . . . . 12
8.5. "ice-options" Attribute . . . . . . . . . . . . . . . . . 13 8.5. "ice-pacing" Attribute . . . . . . . . . . . . . . . . . 12
8.6. "ice-options" Attribute . . . . . . . . . . . . . . . . . 13
9. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . . . 13 9. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . . . 13
9.1. Generating the Offer . . . . . . . . . . . . . . . . . . 13 9.1. Generating the Offer . . . . . . . . . . . . . . . . . . 13
9.1.1. Procedures for All Implementations . . . . . . . . . 13 9.1.1. Procedures for All Implementations . . . . . . . . . 13
9.1.2. Procedures for Full Implementations . . . . . . . . . 15 9.1.2. Procedures for Full Implementations . . . . . . . . . 14
9.1.3. Procedures for Lite Implementations . . . . . . . . . 16 9.1.3. Procedures for Lite Implementations . . . . . . . . . 16
9.2. Receiving the Offer and Generating an Answer . . . . . . 17 9.2. Receiving the Offer and Generating an Answer . . . . . . 17
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. Updating the Check and Valid Lists . . . . . . . . . . . 20 9.3. Updating the Check and Valid Lists . . . . . . . . . . . 20
9.3.1. Procedures for Full Implementations . . . . . . . . . 20 9.3.1. Procedures for Full Implementations . . . . . . . . . 20
9.3.2. Procedures for Lite Implementations . . . . . . . . . 21 9.3.2. Procedures for Lite Implementations . . . . . . . . . 21
10. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 21 10. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 21
11. Media Handling . . . . . . . . . . . . . . . . . . . . . . . 21 11. Media Handling . . . . . . . . . . . . . . . . . . . . . . . 22
11.1. Sending Media . . . . . . . . . . . . . . . . . . . . . 22 11.1. Sending Media . . . . . . . . . . . . . . . . . . . . . 22
11.1.1. Procedures for All Implementations . . . . . . . . . 22 11.1.1. Procedures for All Implementations . . . . . . . . . 22
11.2. Receiving Media . . . . . . . . . . . . . . . . . . . . 22 11.2. Receiving Media . . . . . . . . . . . . . . . . . . . . 22
12. Usage with SIP . . . . . . . . . . . . . . . . . . . . . . . 23 12. Usage with SIP . . . . . . . . . . . . . . . . . . . . . . . 23
12.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . 23 12.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . 23
12.1.1. Offer in INVITE . . . . . . . . . . . . . . . . . . 23 12.1.1. Offer in INVITE . . . . . . . . . . . . . . . . . . 23
12.1.2. Offer in Response . . . . . . . . . . . . . . . . . 24 12.1.2. Offer in Response . . . . . . . . . . . . . . . . . 24
12.2. SIP Option Tags and Media Feature Tags . . . . . . . . . 25 12.2. SIP Option Tags and Media Feature Tags . . . . . . . . . 25
12.3. Interactions with Forking . . . . . . . . . . . . . . . 25 12.3. Interactions with Forking . . . . . . . . . . . . . . . 25
12.4. Interactions with Preconditions . . . . . . . . . . . . 25 12.4. Interactions with Preconditions . . . . . . . . . . . . 25
12.5. Interactions with Third Party Call Control . . . . . . . 26 12.5. Interactions with Third Party Call Control . . . . . . . 26
13. Relationship with ANAT . . . . . . . . . . . . . . . . . . . 26 13. Relationship with ANAT . . . . . . . . . . . . . . . . . . . 26
14. Setting Ta and RTO for RTP Media Streams . . . . . . . . . . 26 14. Setting Ta and RTO for RTP Media Streams . . . . . . . . . . 26
15. Security Considerations . . . . . . . . . . . . . . . . . . . 28 15. Security Considerations . . . . . . . . . . . . . . . . . . . 28
15.1. Attacks on the Offer/Answer Exchanges . . . . . . . . . 28 15.1. Attacks on the Offer/Answer Exchanges . . . . . . . . . 28
15.2. Insider Attacks . . . . . . . . . . . . . . . . . . . . 28 15.2. Insider Attacks . . . . . . . . . . . . . . . . . . . . 29
15.2.1. The Voice Hammer Attack . . . . . . . . . . . . . . 28 15.2.1. The Voice Hammer Attack . . . . . . . . . . . . . . 29
15.2.2. Interactions with Application Layer Gateways and SIP 29 15.2.2. Interactions with Application Layer Gateways and SIP 29
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
16.1. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 30 16.1. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 30
16.1.1. candidate Attribute . . . . . . . . . . . . . . . . 30 16.1.1. candidate Attribute . . . . . . . . . . . . . . . . 30
16.1.2. remote-candidates Attribute . . . . . . . . . . . . 31 16.1.2. remote-candidates Attribute . . . . . . . . . . . . 31
16.1.3. ice-lite Attribute . . . . . . . . . . . . . . . . . 31 16.1.3. ice-lite Attribute . . . . . . . . . . . . . . . . . 31
16.1.4. ice-mismatch Attribute . . . . . . . . . . . . . . . 32 16.1.4. ice-mismatch Attribute . . . . . . . . . . . . . . . 32
16.1.5. ice-pwd Attribute . . . . . . . . . . . . . . . . . 32 16.1.5. ice-pwd Attribute . . . . . . . . . . . . . . . . . 32
16.1.6. ice-ufrag Attribute . . . . . . . . . . . . . . . . 32 16.1.6. ice-ufrag Attribute . . . . . . . . . . . . . . . . 33
16.1.7. ice-options Attribute . . . . . . . . . . . . . . . 33 16.1.7. ice-pacing Attribute . . . . . . . . . . . . . . . . 33
16.1.8. ice-options Attribute . . . . . . . . . . . . . . . 33
16.2. Interactive Connectivity Establishment (ICE) Options 16.2. Interactive Connectivity Establishment (ICE) Options
Registry . . . . . . . . . . . . . . . . . . . . . . . . 33 Registry . . . . . . . . . . . . . . . . . . . . . . . . 34
17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
18.1. Normative References . . . . . . . . . . . . . . . . . . 34 18.1. Normative References . . . . . . . . . . . . . . . . . . 35
18.2. Informative References . . . . . . . . . . . . . . . . . 36 18.2. Informative References . . . . . . . . . . . . . . . . . 36
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 37 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 37
Appendix B. The remote-candidates Attribute . . . . . . . . . . 38 Appendix B. The remote-candidates Attribute . . . . . . . . . . 39
Appendix C. Why Is the Conflict Resolution Mechanism Needed? . . 39 Appendix C. Why Is the Conflict Resolution Mechanism Needed? . . 39
Appendix D. Why Send an Updated Offer? . . . . . . . . . . . . . 40 Appendix D. Why Send an Updated Offer? . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
[NOTE: this version of the document shows merely which parts of the
original ICE document could be split to a separate document if the
split of SDP is accepted by the WG. Later versions will define the
additional procedures needed]
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 and Session Initiation Protocol (SIP). The ICE specification
[ICE-BIS] describes procedures that are common to all usages of ICE [ICE-BIS] describes procedures that are common to all usages of ICE
and this document gives the additional details needed to use ICE with and this document gives the additional details needed to use ICE with
SIP and SDP offer/answer. SIP and SDP offer/answer.
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].
skipping to change at page 9, line 23 skipping to change at page 9, line 9
those candidates, the agent SHOULD wait an additional three seconds, those candidates, the agent SHOULD wait an additional three seconds,
and then it MAY cease responding to checks or generating triggered and then it MAY cease responding to checks or generating triggered
checks on that candidate. It MAY free the candidate at that time. checks on that candidate. It MAY free the candidate at that time.
Freeing of server reflexive candidates is never explicit; it happens Freeing of server reflexive candidates is never explicit; it happens
by lack of a keepalive. The three-second delay handles cases when by lack of a keepalive. The three-second delay handles cases when
aggressive nomination is used, and the selected pairs can quickly aggressive nomination is used, and the selected pairs can quickly
change after ICE has completed. change after ICE has completed.
8. Grammar 8. Grammar
This specification defines seven new SDP attributes -- the This specification defines eight new SDP attributes -- the
"candidate", "remote-candidates", "ice-lite", "ice-mismatch", "ice- "candidate", "remote-candidates", "ice-lite", "ice-mismatch", "ice-
ufrag", "ice-pwd", and "ice-options" attributes. ufrag", "ice-pwd", "ice-pacing", and "ice-options" attributes.
8.1. "candidate" Attribute 8.1. "candidate" Attribute
The candidate attribute is a media-level attribute only. It contains The candidate attribute is a media-level attribute only. It contains
a transport address for a candidate that can be used for connectivity a transport address for a candidate that can be used for connectivity
checks. checks.
The syntax of this attribute is defined using Augmented BNF as The syntax of this attribute is defined using Augmented BNF as
defined in [RFC5234]: defined in [RFC5234]:
skipping to change at page 10, line 25 skipping to change at page 9, line 42
foundation = 1*32ice-char foundation = 1*32ice-char
component-id = 1*5DIGIT component-id = 1*5DIGIT
transport = "UDP" / transport-extension transport = "UDP" / transport-extension
transport-extension = token ; from RFC 3261 transport-extension = token ; from RFC 3261
priority = 1*10DIGIT priority = 1*10DIGIT
cand-type = "typ" SP candidate-types cand-type = "typ" SP candidate-types
candidate-types = "host" / "srflx" / "prflx" / "relay" / token candidate-types = "host" / "srflx" / "prflx" / "relay" / token
rel-addr = "raddr" SP connection-address rel-addr = "raddr" SP connection-address
rel-port = "rport" SP port rel-port = "rport" SP port
extension-att-name = byte-string ;from RFC 4566 extension-att-name = token
extension-att-value = byte-string extension-att-value = *VCHAR
ice-char = ALPHA / DIGIT / "+" / "/" ice-char = ALPHA / DIGIT / "+" / "/"
This grammar encodes the primary information about a candidate: its This grammar encodes the primary information about a candidate: its
IP address, port and transport protocol, and its properties: the IP address, port and transport protocol, and its properties: the
foundation, component ID, priority, type, and related transport foundation, component ID, priority, type, and related transport
address: address:
<connection-address>: is taken from RFC 4566 [RFC4566]. It is the <connection-address>: is taken from RFC 4566 [RFC4566]. It is the
IP address of the candidate, allowing for IPv4 addresses, IPv6 IP address of the candidate, allowing for IPv4 addresses, IPv6
addresses, and fully qualified domain names (FQDNs). When parsing addresses, and fully qualified domain names (FQDNs). When parsing
skipping to change at page 11, line 46 skipping to change at page 11, line 17
and <rel-port> MUST be present for server reflexive, peer and <rel-port> MUST be present for server reflexive, peer
reflexive, and relayed candidates. If a candidate is server or reflexive, and relayed candidates. If a candidate is server or
peer reflexive, <rel-addr> and <rel-port> are equal to the base peer reflexive, <rel-addr> and <rel-port> are equal to the base
for that server or peer reflexive candidate. If the candidate is for that server or peer reflexive candidate. If the candidate is
relayed, <rel-addr> and <rel-port> is equal to the mapped address relayed, <rel-addr> and <rel-port> is equal to the mapped address
in the Allocate response that provided the client with that in the Allocate response that provided the client with that
relayed candidate (see section Appendix B.3 of [ICE-BIS] for a relayed candidate (see section Appendix B.3 of [ICE-BIS] for a
discussion of its purpose). If the candidate is a host candidate, discussion of its purpose). If the candidate is a host candidate,
<rel-addr> and <rel-port> MUST be omitted. <rel-addr> and <rel-port> MUST be omitted.
In some cases, e.g., for privacy reasons, an agent may not want to
reveal the related address and port. In this case the address
MUST be set to "0.0.0.0" (for IPv4 candidates) or "::" (for IPv6
candidates) and the port to zero.
The candidate attribute can itself be extended. The grammar allows The candidate attribute can itself be extended. The grammar allows
for new name/value pairs to be added at the end of the attribute. An for new name/value pairs to be added at the end of the attribute. An
implementation MUST ignore any name/value pairs it doesn't implementation MUST ignore any name/value pairs it doesn't
understand. understand.
8.2. "remote-candidates" Attribute 8.2. "remote-candidates" Attribute
The syntax of the "remote-candidates" attribute is defined using The syntax of the "remote-candidates" attribute is defined using
Augmented BNF as defined in RFC 5234 [RFC5234]. The remote- Augmented BNF as defined in RFC 5234 [RFC5234]. The remote-
candidates attribute is a media-level attribute only. candidates attribute is a media-level attribute only.
remote-candidate-att = "remote-candidates" ":" remote-candidate remote-candidate-att = "remote-candidates" ":" remote-candidate
0*(SP remote-candidate) 0*(SP remote-candidate)
remote-candidate = component-ID SP connection-address SP port remote-candidate = component-ID SP connection-address SP port
The attribute contains a connection-address and port for each The attribute contains a connection-address and port for each
component. The ordering of components is irrelevant. However, a component. The ordering of components is irrelevant. However, a
skipping to change at page 13, line 21 skipping to change at page 12, line 45
allows for 6 bits of randomness per character. The attributes MAY be allows for 6 bits of randomness per character. The attributes MAY be
longer than 4 and 22 characters, respectively, of course, up to 256 longer than 4 and 22 characters, respectively, of course, up to 256
characters. The upper limit allows for buffer sizing in characters. The upper limit allows for buffer sizing in
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-options" Attribute 8.5. "ice-pacing" Attribute
The "ice-pacing" attribute indicates the desired connectivity check
pacing, in milliseconds, for this agent (see Section 12.2 of
[ICE-BIS]). The syntax is:
ice-pacing-att = "ice-pacing" ":" pacing-value
pacing-value = 1*10DIGIT
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:
ice-options = "ice-options" ":" ice-option-tag ice-options = "ice-options" ":" ice-option-tag
0*(SP ice-option-tag) 0*(SP ice-option-tag)
ice-option-tag = 1*ice-char ice-option-tag = 1*ice-char
The existence of an ice-option can indicate that a certain extension
is supported by the agent and will be used or that the extension is
used only if the other agent is willing to use it too. In order to
avoid ambiguity, documents defining new options must indicate which
case applies to the defined extensions.
9. Subsequent Offer/Answer Exchanges 9. Subsequent Offer/Answer Exchanges
Either agent MAY generate a subsequent offer at any time allowed by Either agent MAY generate a subsequent offer at any time allowed by
RFC 3264 [RFC3264]. The rules in Section 7 will cause the RFC 3264 [RFC3264]. The rules in Section 7 will cause the
controlling agent to send an updated offer at the conclusion of ICE controlling agent to send an updated offer at the conclusion of ICE
processing when ICE has selected different candidate pairs from the processing when ICE has selected different candidate pairs from the
default pairs. This section defines rules for construction of default pairs. This section defines rules for construction of
subsequent offers and answers. subsequent offers and answers.
Should a subsequent offer be rejected, ICE processing continues as if Should a subsequent offer be rejected, ICE processing continues as if
skipping to change at page 16, line 9 skipping to change at page 15, line 50
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 stream)
MUST be the local candidate from the highest-priority nominated pair MUST be the local candidate from the highest-priority nominated pair
in the valid list for each component. This "fixes" the default in the valid list for each component. This "fixes" the default
destination for media to equal the destination ICE has selected for destination for media to equal the destination ICE has selected for
media. 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 a In addition, if the agent is controlling, it MUST include the
=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
race condition whereby the controlling agent chooses its pairs, but race condition whereby the controlling agent chooses its pairs, but
the updated offer beats the connectivity checks to the controlled the updated offer beats the connectivity checks to the controlled
agent, which doesn't even know these pairs are valid, let alone agent, which doesn't even know these pairs are valid, let alone
selected. See Appendix B for elaboration on this race condition. selected. See Appendix B for elaboration on this race condition.
9.1.3. Procedures for Lite Implementations 9.1.3. Procedures for Lite Implementations
skipping to change at page 33, line 4 skipping to change at page 33, line 14
16.1.6. ice-ufrag Attribute 16.1.6. ice-ufrag Attribute
Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net.
Attribute Name: ice-ufrag Attribute Name: ice-ufrag
Long Form: ice-ufrag Long Form: ice-ufrag
Type of Attribute: session- or media-level Type of Attribute: session- or media-level
Charset Considerations: The attribute is not subject to the charset Charset Considerations: The attribute is not subject to the charset
attribute. attribute.
Purpose: This attribute is used with Interactive Connectivity Purpose: This attribute is used with Interactive Connectivity
Establishment (ICE), and provides the fragments used to construct Establishment (ICE), and provides the fragments used to construct
the username in STUN connectivity checks. the username in STUN connectivity checks.
Appropriate Values: See Section 8 of RFC XXXX. Appropriate Values: See Section 8 of RFC XXXX.
16.1.7. ice-options Attribute 16.1.7. ice-pacing Attribute
Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net.
Attribute Name: ice-pacing
Long Form: ice-pacing
Type of Attribute: session-level
Charset Considerations: The attribute is not subject to the charset
attribute.
Purpose: This attribute is used with Interactive Connectivity
Establishment (ICE) to indicate desired connectivity check pacing
values.
Appropriate Values: See Section 8 of RFC XXXX.
16.1.8. ice-options Attribute
Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net.
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- or media-level
Charset Considerations: The attribute is not subject to the charset Charset Considerations: The attribute is not subject to the charset
attribute. attribute.
Purpose: This attribute is used with Interactive Connectivity Purpose: This attribute is used with Interactive Connectivity
Establishment (ICE), and 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 8 of RFC XXXX. Appropriate Values: See Section 8 of RFC XXXX.
16.2. Interactive Connectivity Establishment (ICE) Options Registry 16.2. Interactive Connectivity Establishment (ICE) Options Registry
skipping to change at page 33, line 39 skipping to change at page 34, line 20
Appropriate Values: See Section 8 of RFC XXXX. Appropriate Values: See Section 8 of RFC XXXX.
16.2. Interactive Connectivity Establishment (ICE) Options Registry 16.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 8.5; however, they are RECOMMENDED to be no longer than 20 Section 8.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.
In RFC 5245 ICE options could only be defined at the session level. In RFC 5245 ICE options could only be defined at the session level.
ICE options can now also be defined at the media level. This can be ICE options can now also be defined at the media level. This can be
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
skipping to change at page 36, line 23 skipping to change at page 36, line 43
Connectivity Establishment (ICE) in the Session Initiation Connectivity Establishment (ICE) in the Session Initiation
Protocol (SIP)", RFC 5768, April 2010. Protocol (SIP)", RFC 5768, April 2010.
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
and K. Carlberg, "Explicit Congestion Notification (ECN) and K. Carlberg, "Explicit Congestion Notification (ECN)
for RTP over UDP", RFC 6679, August 2012. for RTP over UDP", RFC 6679, August 2012.
[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-keranen-mmusic-rfc5245bis-01 (work in progress), draft-keranen-mmusic-rfc5245bis-02 (work in progress),
February 2013. July 2014.
18.2. Informative References 18.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, April 2004. BCP 85, RFC 3725, April 2004.
[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)",
 End of changes. 28 change blocks. 
38 lines changed or deleted 75 lines changed or added

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