draft-ietf-mmusic-ice-sip-sdp-00.txt   draft-ietf-mmusic-ice-sip-sdp-01.txt 
MMUSIC M. Petit-Huguenin MMUSIC M. Petit-Huguenin
Internet-Draft Impedance Mismatch Internet-Draft Jive Communications
Updates: 6679 (if approved) A. Keranen Intended status: Standards Track A. Keranen
Intended status: Standards Track Ericsson Expires: July 14, 2014 Ericsson
Expires: January 16, 2014 July 15, 2013 January 10, 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-00 draft-ietf-mmusic-ice-sip-sdp-01
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 January 16, 2014. This Internet-Draft will expire on July 14, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 6 skipping to change at page 3, line 6
7.2.1. Full Implementation Procedures . . . . . . . . . . . 9 7.2.1. Full Implementation Procedures . . . . . . . . . . . 9
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 . . . . . . . . 12
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-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 . . . . . . . . . 14 9.1.2. Procedures for Full Implementations . . . . . . . . . 15
9.1.3. Procedures for Lite Implementations . . . . . . . . . 15 9.1.3. Procedures for Lite Implementations . . . . . . . . . 16
9.2. Receiving the Offer and Generating an Answer . . . . . . 16 9.2. Receiving the Offer and Generating an Answer . . . . . . 17
9.2.1. Procedures for All Implementations . . . . . . . . . 16 9.2.1. Procedures for All Implementations . . . . . . . . . 17
9.2.2. Procedures for Full Implementations . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Sending Media . . . . . . . . . . . . . . . . . . . . . 21 11.1. Sending Media . . . . . . . . . . . . . . . . . . . . . 22
11.1.1. Procedures for All Implementations . . . . . . . . . 21 11.1.1. Procedures for All Implementations . . . . . . . . . 22
11.2. Receiving Media . . . . . . . . . . . . . . . . . . . . 22 11.2. Receiving Media . . . . . . . . . . . . . . . . . . . . 22
12. Usage with SIP . . . . . . . . . . . . . . . . . . . . . . . 22 12. Usage with SIP . . . . . . . . . . . . . . . . . . . . . . . 23
12.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . 22 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 . . . . . . . . . 24 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 . . . . . . . 25 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 . . . . . . . . . . . . . . . . . . . . 28
15.2.1. The Voice Hammer Attack . . . . . . . . . . . . . . 28 15.2.1. The Voice Hammer Attack . . . . . . . . . . . . . . 28
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 . . . . . . . . . . . . 30 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 . . . . . . . . . . . . . . . 31 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 . . . . . . . . . . . . . . . . 32
16.1.7. ice-options Attribute . . . . . . . . . . . . . . . 33 16.1.7. ice-options Attribute . . . . . . . . . . . . . . . 33
16.2. Interactive Connectivity Establishment (ICE) Options 16.2. Interactive Connectivity Establishment (ICE) Options
Registry . . . . . . . . . . . . . . . . . . . . . . . . 33 Registry . . . . . . . . . . . . . . . . . . . . . . . . 33
17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
18.1. Normative References . . . . . . . . . . . . . . . . . . 34 18.1. Normative References . . . . . . . . . . . . . . . . . . 34
18.2. Informative References . . . . . . . . . . . . . . . . . 35 18.2. Informative References . . . . . . . . . . . . . . . . . 36
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 36 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 37
Appendix B. The remote-candidates Attribute . . . . . . . . . . 37 Appendix B. The remote-candidates Attribute . . . . . . . . . . 38
Appendix C. Why Is the Conflict Resolution Mechanism Needed? . . 38 Appendix C. Why Is the Conflict Resolution Mechanism Needed? . . 39
Appendix D. Why Send an Updated Offer? . . . . . . . . . . . . . 39 Appendix D. Why Send an Updated Offer? . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
[NOTE: this version of the document shows merely which parts of the [NOTE: this version of the document shows merely which parts of the
original ICE document could be split to a separate document if 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 split of SDP is accepted by the WG. Later versions will define the
additional procedures needed] 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
skipping to change at page 12, line 48 skipping to change at page 13, line 15
The ice-ufrag and ice-pwd attributes MUST be chosen randomly at the The ice-ufrag and ice-pwd attributes MUST be chosen randomly at the
beginning of a session. The ice-ufrag attribute MUST contain at beginning of a session. The ice-ufrag attribute MUST contain at
least 24 bits of randomness, and the ice-pwd attribute MUST contain least 24 bits of randomness, and the ice-pwd attribute MUST contain
at least 128 bits of randomness. This means that the ice-ufrag at least 128 bits of randomness. This means that the ice-ufrag
attribute will be at least 4 characters long, and the ice-pwd at attribute will be at least 4 characters long, and the ice-pwd at
least 22 characters long, since the grammar for these attributes least 22 characters long, since the grammar for these attributes
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. of randomness to be added over time. For compatibility with the 512
character limitation for the STUN username attribute value and for
bandwidth conservation considerations, the ice-ufrag attribute MUST
NOT be longer than 32 characters when sending, but an implementation
MUST accept up to 256 characters when receiving.
8.5. "ice-options" Attribute 8.5. "ice-options" Attribute
The "ice-options" attribute is a session- and media-level attribute. The "ice-options" attribute is a session-level attribute. It
It contains a series of tokens that identify the options supported by 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
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
skipping to change at page 33, line 13 skipping to change at page 33, line 21
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-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-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.
skipping to change at page 33, line 36 skipping to change at page 34, line 6
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.5; 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.
To permit aggregation between different ICE agents in the same ICE options can now also be defined at the media level. This can be
endpoint, ICE options can now also be defined at the media level. To used when aggregating between different ICE agents in the same
ensure compatibility with legacy implementation, the media-level ICE endpoint, but future options may require to be defined at the media-
options MUST be aggregated into a session-level ICE option. Because level. To ensure compatibility with legacy implementation, the
aggregation rules depend on the specifics of each option, all new ICE media-level ICE options MUST be aggregated into a session-level ICE
options MUST also define in their specification how the media-level option. Because aggregation rules depend on the specifics of each
ICE option values are aggregated to generate the value of the option, all new ICE options MUST also define in their specification
session-level ICE option. how the media-level ICE option values are aggregated to generate the
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 options 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
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
o Organization or individuals having the change control o Organization or individuals having the change control
o Short description of the ICE extension to which the option relates o Short description of the ICE extension to which the option relates
o Reference(s) to the specification defining the ICE option and the o Reference(s) to the specification defining the ICE option and the
related extensions related extensions
17. Acknowledgments 17. Acknowledgments
skipping to change at page 40, line 28 skipping to change at page 41, line 15
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 this
reason, an updated offer must be sent. reason, an updated offer must be sent.
Authors' Addresses Authors' Addresses
Marc Petit-Huguenin Marc Petit-Huguenin
Impedance Mismatch Jive Communications
1275 West 1600 North, Suite 100
Orem, UT 84057
USA
Email: petithug@acm.org Email: marcph@getjive.com
Ari Keranen Ari Keranen
Ericsson Ericsson
Jorvas 02420 Jorvas 02420
Finland Finland
Email: ari.keranen@ericsson.com Email: ari.keranen@ericsson.com
 End of changes. 20 change blocks. 
40 lines changed or deleted 51 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/