draft-ietf-mmusic-ice-sip-sdp-19.txt   draft-ietf-mmusic-ice-sip-sdp-20.txt 
skipping to change at page 1, line 13 skipping to change at page 1, line 13
MMUSIC M. Petit-Huguenin MMUSIC M. Petit-Huguenin
Internet-Draft Impedance Mismatch Internet-Draft Impedance Mismatch
Obsoletes: 5245 (if approved) S. Nandakumar Obsoletes: 5245 (if approved) S. Nandakumar
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: October 3, 2018 A. Keranen Expires: October 3, 2018 A. Keranen
Ericsson Ericsson
April 1, 2018 April 1, 2018
Session Description Protocol (SDP) Offer/Answer procedures for Session Description Protocol (SDP) Offer/Answer procedures for
Interactive Connectivity Establishment (ICE) Interactive Connectivity Establishment (ICE)
draft-ietf-mmusic-ice-sip-sdp-19 draft-ietf-mmusic-ice-sip-sdp-20
Abstract Abstract
This document describes Session Description Protocol (SDP) Offer/ This document describes Session Description Protocol (SDP) Offer/
Answer procedures for carrying out Interactive Connectivity Answer procedures for carrying out Interactive Connectivity
Establishment (ICE) between the agents. Establishment (ICE) between the agents.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 2, line 30 skipping to change at page 2, line 30
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 4 3. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 4
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Generic Procedures . . . . . . . . . . . . . . . . . . . 4 3.2. Generic Procedures . . . . . . . . . . . . . . . . . . . 4
3.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . 4 3.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . 4
3.2.2. RTP/RTCP Considerations . . . . . . . . . . . . . . . 6 3.2.2. RTP/RTCP Considerations . . . . . . . . . . . . . . . 6
3.2.3. Determining Role . . . . . . . . . . . . . . . . . . 6 3.2.3. Determining Role . . . . . . . . . . . . . . . . . . 6
3.2.4. STUN Considerations . . . . . . . . . . . . . . . . . 6 3.2.4. STUN Considerations . . . . . . . . . . . . . . . . . 6
3.2.5. ICE Mismatch . . . . . . . . . . . . . . . . . . . . 6 3.2.5. Verifying ICE Support Procedures . . . . . . . . . . 6
3.2.6. SDP Example . . . . . . . . . . . . . . . . . . . . . 7 3.2.6. SDP Example . . . . . . . . . . . . . . . . . . . . . 7
3.3. Initial Offer/Answer Exchange . . . . . . . . . . . . . . 7 3.3. Initial Offer/Answer Exchange . . . . . . . . . . . . . . 7
3.3.1. Sending the Initial Offer . . . . . . . . . . . . . . 7 3.3.1. Sending the Initial Offer . . . . . . . . . . . . . . 7
3.3.2. Sending the Initial Answer . . . . . . . . . . . . . 8 3.3.2. Sending the Initial Answer . . . . . . . . . . . . . 8
3.3.3. Receiving the Initial Answer . . . . . . . . . . . . 8 3.3.3. Receiving the Initial Answer . . . . . . . . . . . . 8
3.3.4. Concluding ICE . . . . . . . . . . . . . . . . . . . 8 3.3.4. Concluding ICE . . . . . . . . . . . . . . . . . . . 8
3.4. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . 9 3.4. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . 9
3.4.1. Sending Subsequent Offer . . . . . . . . . . . . . . 9 3.4.1. Sending Subsequent Offer . . . . . . . . . . . . . . 9
3.4.2. Sending Subsequent Answer . . . . . . . . . . . . . . 11 3.4.2. Sending Subsequent Answer . . . . . . . . . . . . . . 11
3.4.3. Receiving Answer for a Subsequent Offer . . . . . . . 13 3.4.3. Receiving Answer for a Subsequent Offer . . . . . . . 13
skipping to change at page 6, line 20 skipping to change at page 6, line 20
3.2.2. RTP/RTCP Considerations 3.2.2. RTP/RTCP Considerations
If an agent utilizes both RTP and RTCP, the agent MUST include SDP If an agent utilizes both RTP and RTCP, the agent MUST include SDP
candidate attributes for both the RTP and RTCP components in the "m=" candidate attributes for both the RTP and RTCP components in the "m="
section. section.
If an agent uses separate ports for RTP and RTCP, the agent MUST If an agent uses separate ports for RTP and RTCP, the agent MUST
include an SDP rtcp attribute in the "m=" section, as described in include an SDP rtcp attribute in the "m=" section, as described in
[RFC3605]. In the cases where the port number for the RTCP is one [RFC3605]. In the cases where the port number for the RTCP is one
higher than the RTP port and RTCP component address is same as the higher than the RTP port and RTCP component address is same as the
address of the RTP component, the SDP rtcp attribute MUST not be address of the RTP component, the SDP rtcp attribute MAY be omitted.
included.
If the agent does not utilize RTCP, it indicates that by including If the agent does not utilize RTCP, it indicates that by including
b=RS:0 and b=RR:0 SDP attributes, as described in [RFC3556]. b=RS:0 and b=RR:0 SDP attributes, as described in [RFC3556].
3.2.3. Determining Role 3.2.3. Determining Role
The offerer acts as the Initiating agent. The answerer acts as the The offerer acts as the Initiating agent. The answerer acts as the
Responding agent. The ICE roles (controlling and controlled) are Responding agent. The ICE roles (controlling and controlled) are
determined using the procedures in [ICE-BIS]. determined using the procedures in [ICE-BIS].
3.2.4. STUN Considerations 3.2.4. STUN Considerations
Once an agent has provided its local candidates to its peer in an SDP Once an agent has provided its local candidates to its peer in an SDP
offer or answer, the agent MUST be prepared to receive STUN offer or answer, the agent MUST be prepared to receive STUN
connectivity check Binding requests on those candidates. connectivity check Binding requests on those candidates.
3.2.5. ICE Mismatch 3.2.5. Verifying ICE Support Procedures
The agent will proceed with the ICE procedures defined in [ICE-BIS] The agents will proceed with the ICE procedures defined in [ICE-BIS]
and this specification if, for each data stream in the SDP it and this specification if, for each data stream in the SDP it
received, the default destination for each component of that data received, the default destination for each component of that data
stream appears in a candidate attribute. For example, in the case of stream appears in a candidate attribute. For example, in the case of
RTP, the IP address and port in the "c=" and "m=" lines, RTP, the IP address and port in the "c=" and "m=" lines,
respectively, appear in a candidate attribute and the value in the respectively, appear in a candidate attribute and the value in the
rtcp attribute appears in a candidate attribute. rtcp attribute appears in a candidate attribute.
If this condition is not met, the agent MUST process the SDP based on If this condition is not met, the agents MUST process the SDP based
normal [RFC3264] procedures, without using any of the ICE mechanisms on normal [RFC3264] procedures, without using any of the ICE
described in the remainder of this specification with the following mechanisms described in the remainder of this specification with the
exceptions: following exceptions:
1. The agent MUST follow the rules of section 11 of [ICE-BIS], which
describe keepalive procedures for all agents.
2. If the agent is not proceeding with ICE because there were 1. A controlled/responding agent MUST follow the rules of section 11
a=candidate attributes, but none that matched the default of [ICE-BIS], which describe keepalive procedures for all agents.
destination of the data stream, the agent MUST include an a=ice- Also, If the default candidates were relayed candidates learned
mismatch attribute in its answer and MAY omit a=candidate through a TURN server, the controlled agent MUST create
attributes for such data streams. See Section 9.2.2 for a permissions in the TURN server for the IP addresses learned from
discussion of cases where this can happen. This specification its peer in the offer SDP it just received. If this is not done,
provides no guidance on how an agent should proceed in such a initial packets in the data stream from the peer may be lost.
failure case.
3. If the default candidates were relayed candidates learned through 2. On the other hand, If the controlled agent is not proceeding with
a TURN server, the agent MUST create permissions in the TURN ICE because there were a=candidate attributes, but none that
server for the IP addresses learned from its peer in the SDP it matched the default destination of the data stream, the agent
just received. If this is not done, initial packets in the data MUST include an a=ice-mismatch attribute in its answer and MAY
stream from the peer may be lost. omit a=candidate attributes for such data streams. See
Section 9.2.2 for a discussion of cases where this can happen.
This specification provides no guidance on how an controlling/
initiator agent should proceed in such a failure case.
3.2.6. SDP Example 3.2.6. SDP Example
The following is an example SDP message that includes ICE attributes The following is an example SDP message that includes ICE attributes
(lines folded for readability): (lines folded for readability):
v=0 v=0
o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1 o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
s= s=
c=IN IP4 192.0.2.3 c=IN IP4 192.0.2.3
skipping to change at page 27, line 47 skipping to change at page 27, line 47
of ICE for it to act as a tool for "working around" SBCs. If one is of ICE for it to act as a tool for "working around" SBCs. If one is
present, ICE will not be used and the SBC techniques take precedence. present, ICE will not be used and the SBC techniques take precedence.
10. IANA Considerations 10. IANA Considerations
10.1. SDP Attributes 10.1. SDP Attributes
The original ICE specification defined seven new SDP attributes per The original ICE specification defined seven new SDP attributes per
the procedures of Section 8.2.4 of [RFC4566]. The registration the procedures of Section 8.2.4 of [RFC4566]. The registration
information from the original specification is included here with information from the original specification is included here with
modifications to include Mux Category and to align with the recent modifications to include Mux Category and also defines a new SDP
recommendations for populating Contact information. attribute 'ice-pacing'.
10.1.1. candidate Attribute 10.1.1. candidate Attribute
Attribute Name: candidate Attribute Name: candidate
Type of Attribute: media-level Type of Attribute: media-level
Subject to charset: No Subject to charset: No
Purpose: This attribute is used with Interactive Connectivity Purpose: This attribute is used with Interactive Connectivity
skipping to change at page 31, line 52 skipping to change at page 31, line 52
values. values.
Appropriate Values: See Section 4 of RFC XXXX. Appropriate Values: See Section 4 of RFC XXXX.
Contact Name: IESG Contact Name: IESG
Contact e-mail: iesg@ietf.org [8] Contact e-mail: iesg@ietf.org [8]
Reference: RFCXXXX Reference: RFCXXXX
Mux Category: TRANSPORT Mux Category: NORMAL
10.2. Interactive Connectivity Establishment (ICE) Options Registry 10.2. Interactive Connectivity Establishment (ICE) Options Registry
IANA maintains a registry for ice-options identifiers under the IANA maintains a registry for ice-options identifiers under the
Specification Required policy as defined in "Guidelines for Writing Specification Required policy as defined in "Guidelines for Writing
an IANA Considerations Section in RFCs" [RFC5226]. an IANA Considerations Section in RFCs" [RFC5226].
ICE options are of unlimited length according to the syntax in ICE options are of unlimited length according to the syntax in
Section 4.6; however, they are RECOMMENDED to be no longer than 20 Section 4.6; however, they are RECOMMENDED to be no longer than 20
characters. This is to reduce message sizes and allow for efficient characters. This is to reduce message sizes and allow for efficient
skipping to change at page 36, line 17 skipping to change at page 36, line 17
Initiation Protocol (SIP)", RFC 5626, Initiation Protocol (SIP)", RFC 5626,
DOI 10.17487/RFC5626, October 2009, DOI 10.17487/RFC5626, October 2009,
<http://www.rfc-editor.org/info/rfc5626>. <http://www.rfc-editor.org/info/rfc5626>.
[RFC5898] Andreasen, F., Camarillo, G., Oran, D., and D. Wing, [RFC5898] Andreasen, F., Camarillo, G., Oran, D., and D. Wing,
"Connectivity Preconditions for Session Description "Connectivity Preconditions for Session Description
Protocol (SDP) Media Streams", RFC 5898, Protocol (SDP) Media Streams", RFC 5898,
DOI 10.17487/RFC5898, July 2010, DOI 10.17487/RFC5898, July 2010,
<http://www.rfc-editor.org/info/rfc5898>. <http://www.rfc-editor.org/info/rfc5898>.
12.3. URIs
[1] mailto:iesg@ietf.org
[2] mailto:iesg@ietf.org
[3] mailto:iesg@ietf.org
[4] mailto:iesg@ietf.org
[5] mailto:iesg@ietf.org
[6] mailto:iesg@ietf.org
[7] mailto:iesg@ietf.org
[8] mailto:iesg@ietf.org
[9] mailto:christer.holmberg@ericsson.com
[10] mailto:rshpount@turbobridge.com
[11] mailto:thomass.stach@gmail.com
Appendix A. Examples Appendix A. Examples
For the example shown in section 16 of [ICE-BIS] the resulting offer For the example shown in section 16 of [ICE-BIS] the resulting offer
(message 5) encoded in SDP looks like: (message 5) encoded in SDP looks like:
v=0 v=0
o=jdoe 2890844526 2890842807 IN IP6 $L-PRIV-1.IP o=jdoe 2890844526 2890842807 IN IP6 $L-PRIV-1.IP
s= s=
c=IN IP6 $NAT-PUB-1.IP c=IN IP6 $NAT-PUB-1.IP
t=0 0 t=0 0
skipping to change at page 41, line 14 skipping to change at page 41, line 14
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 "m=" and "c=" lines and the rtcp attribute -- must be retained. For
this reason, an updated offer must be sent. this reason, an updated offer must be sent.
Appendix E. Contributors Appendix E. Contributors
Following experts have contributed a textual and structural Following experts have contributed textual and structural
suggestions for this work improvements for this work
1. Christer Holmberg 1. Christer Holmberg
* Ericsson * Ericsson
* Email: christer.holmberg@ericsson.com [9] * Email: christer.holmberg@ericsson.com [9]
2. Roman Shpount 2. Roman Shpount
* TurboBridge * TurboBridge
 End of changes. 12 change blocks. 
55 lines changed or deleted 29 lines changed or added

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