draft-ietf-mmusic-sdp-bundle-negotiation-25.txt   draft-ietf-mmusic-sdp-bundle-negotiation-26.txt 
MMUSIC Working Group C. Holmberg MMUSIC Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 3264 (if approved) H. Alvestrand Updates: 3264 (if approved) H. Alvestrand
Intended status: Standards Track Google Intended status: Standards Track Google
Expires: July 21, 2016 C. Jennings Expires: August 19, 2016 C. Jennings
Cisco Cisco
January 18, 2016 February 16, 2016
Negotiating Media Multiplexing Using the Session Description Protocol Negotiating Media Multiplexing Using the Session Description Protocol
(SDP) (SDP)
draft-ietf-mmusic-sdp-bundle-negotiation-25.txt draft-ietf-mmusic-sdp-bundle-negotiation-26.txt
Abstract Abstract
This specification defines a new Session Description Protocol (SDP) This specification defines a new Session Description Protocol (SDP)
Grouping Framework extension, 'BUNDLE'. The extension can be used Grouping Framework extension, 'BUNDLE'. The extension can be used
with the SDP Offer/Answer mechanism to negotiate the usage of a with the SDP Offer/Answer mechanism to negotiate the usage of a
single address:port combination (BUNDLE address) for receiving media, single address:port combination (BUNDLE address) for receiving media,
referred to as bundled media, associated with multiple SDP media referred to as bundled media, associated with multiple SDP media
descriptions ("m=" lines). descriptions ("m=" lines).
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 21, 2016. This Internet-Draft will expire on August 19, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 17 skipping to change at page 3, line 17
9.2. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 17 9.2. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 17
10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 17 10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 17
10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 17 10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 17
10.1.1. General . . . . . . . . . . . . . . . . . . . . . . 18 10.1.1. General . . . . . . . . . . . . . . . . . . . . . . 18
10.1.2. Payload Type (PT) Value Reuse . . . . . . . . . . . 18 10.1.2. Payload Type (PT) Value Reuse . . . . . . . . . . . 18
10.2. Associating RTP/RTCP Packets With Correct SDP Media 10.2. Associating RTP/RTCP Packets With Correct SDP Media
Description . . . . . . . . . . . . . . . . . . . . . . 19 Description . . . . . . . . . . . . . . . . . . . . . . 19
10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 19 10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 19
10.3.1. General . . . . . . . . . . . . . . . . . . . . . . 19 10.3.1. General . . . . . . . . . . . . . . . . . . . . . . 19
10.3.2. SDP Offer/Answer Procedures . . . . . . . . . . . . 20 10.3.2. SDP Offer/Answer Procedures . . . . . . . . . . . . 20
11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 21 11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 22
11.1. General . . . . . . . . . . . . . . . . . . . . . . . . 21 11.1. General . . . . . . . . . . . . . . . . . . . . . . . . 22
11.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 22 11.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 22
11.2.1. General . . . . . . . . . . . . . . . . . . . . . . 22 11.2.1. General . . . . . . . . . . . . . . . . . . . . . . 22
11.2.2. Generating the Initial SDP Offer . . . . . . . . . . 22 11.2.2. Generating the Initial SDP Offer . . . . . . . . . . 22
11.2.3. Generating the SDP Answer . . . . . . . . . . . . . 22 11.2.3. Generating the SDP Answer . . . . . . . . . . . . . 23
11.2.4. Offerer Processing of the SDP Answer . . . . . . . . 23 11.2.4. Offerer Processing of the SDP Answer . . . . . . . . 23
11.2.5. Modifying the Session . . . . . . . . . . . . . . . 23 11.2.5. Modifying the Session . . . . . . . . . . . . . . . 23
12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 23 12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 23
13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 24 13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 24
13.1. General . . . . . . . . . . . . . . . . . . . . . . . . 24 13.1. General . . . . . . . . . . . . . . . . . . . . . . . . 24
13.2. Original text of section 5.1 (2nd paragraph) of RFC 3264 24 13.2. Original text of section 5.1 (2nd paragraph) of RFC 3264 24
13.3. New text replacing section 5.1 (2nd paragraph) of RFC 13.3. New text replacing section 5.1 (2nd paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 24
13.4. Original text of section 8.2 (2nd paragraph) of RFC 3264 25 13.4. Original text of section 8.2 (2nd paragraph) of RFC 3264 25
13.5. New text replacing section 8.2 (2nd paragraph) of RFC 13.5. New text replacing section 8.2 (2nd paragraph) of RFC
skipping to change at page 4, line 13 skipping to change at page 4, line 13
17.4. Example: Offerer Moves A Media Description Out Of A 17.4. Example: Offerer Moves A Media Description Out Of A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 35 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 35
17.5. Example: Offerer Disables A Media Description Within A 17.5. Example: Offerer Disables A Media Description Within A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 36 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 36
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38
19. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 38 19. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 38
20. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
20.1. Normative References . . . . . . . . . . . . . . . . . . 44 20.1. Normative References . . . . . . . . . . . . . . . . . . 44
20.2. Informative References . . . . . . . . . . . . . . . . . 46 20.2. Informative References . . . . . . . . . . . . . . . . . 46
Appendix A. Design Considerations . . . . . . . . . . . . . . . 46 Appendix A. Design Considerations . . . . . . . . . . . . . . . 46
A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 46 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 47
A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 47 A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 47
A.3. Usage of port number value zero . . . . . . . . . . . . . 49 A.3. Usage of port number value zero . . . . . . . . . . . . . 49
A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 49 A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 49
A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 50 A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 50
A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 50 A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 50
A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 50 A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
1. Introduction 1. Introduction
skipping to change at page 20, line 30 skipping to change at page 20, line 30
The procedures in this section only apply to RTP-based "m=" lines. The procedures in this section only apply to RTP-based "m=" lines.
10.3.2.2. Generating the Initial SDP Offer 10.3.2.2. Generating the Initial SDP Offer
When an offerer generates an initial offer, the offerer MUST When an offerer generates an initial offer, the offerer MUST
associate an SDP 'rtcp-mux' attribute [RFC5761] with each bundled associate an SDP 'rtcp-mux' attribute [RFC5761] with each bundled
RTP-based "m=" line (including any bundle-only "m=" line) in the RTP-based "m=" line (including any bundle-only "m=" line) in the
offer. offer.
If an offerer wants to indicate exclusive support of RTP/RTCP If an offerer wants to indicate exclusive support of RTP/RTCP
multiplexing for one or more "m=" lines (excluding any bundle-only multiplexing [I-D.mmusic-mux-exclusive] for one or more "m=" lines
"m=" line) within the BUNDLE group, the offerer MUST associate an SDP within the BUNDLE group, the offerer MUST associate an SDP 'rtcp-mux-
'rtcp' attribute [RFC3605] with those "m=" lines, as described in exclusive' attribute with those "m=" lines.
[I-D.mmusic-mux-exclusive].
NOTE: The offerer might also associate an SDP 'rtcp' attribute NOTE: The offerer might also associate an SDP 'rtcp' attribute
[RFC3605] with a bundled "m=" line, excluding a bundle-only "m=" [RFC3605] with a bundled "m=" line, excluding a bundle-only "m="
line, in order to provide a fallback port for RTCP. However, the line, in order to provide a fallback port for RTCP. However, the
fallback port will only be used in case the answerer does not include fallback port will only be used in case the answerer does not include
the "m=" line in the BUNDLE group in the associated answer. the "m=" line in the BUNDLE group in the associated answer.
In the initial offer, the IP address and port combination for RTCP In the initial offer, the address:port combination for RTCP MUST be
MUST be unique in each bundled RTP-based "m=" line (excluding a unique in each bundled RTP-based "m=" line (excluding a 'bundle-only'
'bundle-only' "m=" line), similar to RTP. "m=" line), similar to RTP.
10.3.2.3. Generating the SDP Answer 10.3.2.3. Generating the SDP Answer
When an answerer generates an answer, if the offerer indicated When an answerer generates an answer, if the answerer accepts an RTP-
support of RTP/RTCP multiplexing [RFC5761] within a BUNDLE group in based "m=" line within a BUNDLE group, the answerer MUST enable usage
the associated offer, the answerer MUST accept usage of RTP/RTCP of RTP/RTCP multiplexing. The answerer MUST associate an SDP "rtcp-
multiplexing within the BUNDLE group. If an SDP "rtcp-mux" attribute mux" attribute with the "m=" line in the answer. In addition, if the
was not associated with a bundled "m=" line in the associated offer, "m=" line in the associated offer contained an SDP "rtcp-mux-
the answerer MUST NOT included that "m=" line in the BUNDLE group. exclusive" attribute, the answerer MUST associate an SDP "rtcp-mux-
exclusive" attribute with the "m=" line in the answer.
If the offerer indicated exclusive support of RTP/RTCP multiplexing If an RTP-based "m=" line in the associated offer did not contain an
for one or more bundled "m=" lines within the offer, and if the SDP "rtcp-mux" attribute, the answerer MUST NOT accept the "m=" line
answerer does not accept the usage of RTP/RTCP multiplexing within within a BUNDLE group in the answer.
the bundle group, the answerer MUST reject those "m=" lines.
If an RTP-based "m=" line in the associated offer contained an SDP
"rtcp-mux-exclusive" attribute, and if the answerer moves the "m="
line out of the BUNDLE group in the answer Section 8.3.4, the
answerer MUST still either enable RTP/RTCP multiplexing, or reject
the "m=" line Section 8.3.5.
When the answerer accepts the usage of RTP/RTCP multiplexing within When the answerer accepts the usage of RTP/RTCP multiplexing within
the BUNDLE group, it MUST associate an SDP 'rtcp-mux' attribute with the BUNDLE group, it MUST associate an SDP 'rtcp-mux' attribute with
each bundled RTP-based "m=" line in the answer. The answerer MUST each bundled RTP-based "m=" line in the answer. In addition, if the
NOT associate an SDP 'rtcp' attribute with any bundled "m=" line in "m=" line in the associated offer contained an SDP 'rtcp-mux-
the answer. The answerer will use the port value of the selected exclusive' attribute, the answerer MUST associated an SDP 'rtcp-mux-
offerer BUNDLE address for sending RTP and RTCP packets associated exclusive' attribute with the corresponding "m=" line in the answer,
with each RTP-based bundled "m=" line towards the offerer. as described in.
The answerer MUST NOT associate an SDP 'rtcp' attribute with any
bundled "m=" line in the answer. The answerer will use the port
value of the selected offerer BUNDLE address for sending RTP and RTCP
packets associated with each RTP-based bundled "m=" line towards the
offerer.
If the usage of RTP/RTCP multiplexing within a BUNDLE group has been If the usage of RTP/RTCP multiplexing within a BUNDLE group has been
negotiated in a previous offer/answer transaction, the answerer MUST negotiated in a previous offer/answer transaction, the answerer MUST
associate an SDP 'rtcp-mux' attribute with each bundled RTP-based associate an SDP 'rtcp-mux' attribute with each bundled RTP-based
"m=" line in the answer. "m=" line in the answer.
10.3.2.4. Offerer Processing of the SDP Answer 10.3.2.4. Offerer Processing of the SDP Answer
When an offerer receives an answer, if the answerer has accepted the When an offerer receives an answer, if the answerer has accepted the
usage of RTP/RTCP multiplexing (see Section 10.3.2.3), the answerer usage of RTP/RTCP multiplexing (see Section 10.3.2.3), the answerer
follows the procedures for RTP/RTCP multiplexing defined in follows the procedures for RTP/RTCP multiplexing defined in
[RFC5761]. The offerer will use the port value associated with the [RFC5761]. The offerer will use the port value associated with the
answerer BUNDLE address for sending RTP and RTCP packets associated answerer BUNDLE address for sending RTP and RTCP packets associated
with each RTP-based bundled "m=" line towards the answerer. with each RTP-based bundled "m=" line towards the answerer.
NOTE: If is considered a protocol error if the answerer has not NOTE: It is considered a protocol error if the answerer has not
accepted the usage of RTP/RTCP multiplexing for RTP-based "m=" lines accepted the usage of RTP/RTCP multiplexing for RTP-based "m=" lines
that the answerer included in the BUNDLE group. that the answerer included in the BUNDLE group.
10.3.2.5. Modifying the Session 10.3.2.5. Modifying the Session
When an offerer generates a subsequent offer, it MUST associate an When an offerer generates a subsequent offer, it MUST associate an
SDP 'rtcp-mux' attribute with each RTP-based bundled "m=" line SDP 'rtcp-mux' attribute with each RTP-based bundled "m=" line
(including any bundled "m=" line that the offerer wants to add to the (including any bundled "m=" line that the offerer wants to add to the
BUNDLE group), unless the offerer wants to disable or remove the "m=" BUNDLE group), unless the offerer wants to disable or remove the "m="
line from the BUNDLE group. line from the BUNDLE group.
skipping to change at page 38, line 37 skipping to change at page 38, line 37
Thanks to Magnus Westerlund, Colin Perkins and Jonathan Lennox for Thanks to Magnus Westerlund, Colin Perkins and Jonathan Lennox for
providing help and text on the RTP/RTCP procedures. providing help and text on the RTP/RTCP procedures.
Thanks to Spotify for providing music for the countless hours of Thanks to Spotify for providing music for the countless hours of
document editing. document editing.
19. Change Log 19. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing] [RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-25
o - RTP/RTCP mux procedures updated with exclusive RTP/RTCP mux
considerations.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-24 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-24
o - Reference and procedures associated with exclusive RTP/RTCP mux o - Reference and procedures associated with exclusive RTP/RTCP mux
added added
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-23 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-23
o - RTCP-MUX mandatory for bundled RTP m- lines o - RTCP-MUX mandatory for bundled RTP m- lines
o - Editorial fixes based on comments from Flemming Andreasen o - Editorial fixes based on comments from Flemming Andreasen
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-22 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-22
o - Correction of Ari's family name o - Correction of Ari's family name
o - Editorial fixes based on comments from Thomas Stach o - Editorial fixes based on comments from Thomas Stach
o - RTP/RTCP correction based on comment from Magnus Westerlund o - RTP/RTCP correction based on comment from Magnus Westerlund
o -- http://www.ietf.org/mail-archive/web/mmusic/current/ o -- http://www.ietf.org/mail-archive/web/mmusic/current/
msg14861.html msg14861.html
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-21 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-21
skipping to change at page 46, line 13 skipping to change at page 46, line 17
January 2012, <http://www.rfc-editor.org/info/rfc6347>. January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[I-D.mmusic-sdp-mux-attributes] [I-D.mmusic-sdp-mux-attributes]
Nandakumar, S., "A Framework for SDP Attributes when Nandakumar, S., "A Framework for SDP Attributes when
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-12 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-12
(work in progress), January 2016. (work in progress), January 2016.
[I-D.mmusic-mux-exclusive] [I-D.mmusic-mux-exclusive]
Holmberg, C., "Indicating Exclusive Support of RTP/RTCP Holmberg, C., "Indicating Exclusive Support of RTP/RTCP
Multiplexing using SDP", draft-ietf-mmusic-mux- Multiplexing using SDP", draft-ietf-mmusic-mux-
exclusive-00 (work in progress), January 2016. exclusive-01 (work in progress), February 2016.
20.2. Informative References 20.2. Informative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>. <http://www.rfc-editor.org/info/rfc3261>.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
 End of changes. 17 change blocks. 
33 lines changed or deleted 49 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/