draft-ietf-mmusic-sdp-bundle-negotiation-24.txt   draft-ietf-mmusic-sdp-bundle-negotiation-25.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 14, 2016 C. Jennings Expires: July 21, 2016 C. Jennings
Cisco Cisco
January 11, 2016 January 18, 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-24.txt draft-ietf-mmusic-sdp-bundle-negotiation-25.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 14, 2016. This Internet-Draft will expire on July 21, 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 23 skipping to change at page 3, line 23
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 . . . . . . . . . . . . . . . . . . . . . 21
11.1. General . . . . . . . . . . . . . . . . . . . . . . . . 21 11.1. General . . . . . . . . . . . . . . . . . . . . . . . . 21
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 . . . . . . . . . . . . . 22
11.2.4. Offerer Processing of the SDP Answer . . . . . . . . 22 11.2.4. Offerer Processing of the SDP Answer . . . . . . . . 23
11.2.5. Modifying the Session . . . . . . . . . . . . . . . 22 11.2.5. Modifying the Session . . . . . . . . . . . . . . . 23
12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 23 12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 23
13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 23 13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 24
13.1. General . . . . . . . . . . . . . . . . . . . . . . . . 23 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 24 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
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 25
13.6. Original text of section 8.4 (6th paragraph) of RFC 3264 25 13.6. Original text of section 8.4 (6th paragraph) of RFC 3264 25
13.7. New text replacing section 8.4 (6th paragraph) of RFC 13.7. New text replacing section 8.4 (6th paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 25
14. RTP/RTCP extensions for identification-tag transport . . . . 25 14. RTP/RTCP extensions for identification-tag transport . . . . 26
14.1. General . . . . . . . . . . . . . . . . . . . . . . . . 25 14.1. General . . . . . . . . . . . . . . . . . . . . . . . . 26
14.2. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 26 14.2. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 27
14.3. RTP MID Header Extension . . . . . . . . . . . . . . . . 27 14.3. RTP MID Header Extension . . . . . . . . . . . . . . . . 27
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
15.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 27 15.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 28
15.2. New RTP Header Extension URI . . . . . . . . . . . . . . 28 15.2. New RTP Header Extension URI . . . . . . . . . . . . . . 28
15.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 28 15.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 28
15.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 28 15.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 29
16. Security Considerations . . . . . . . . . . . . . . . . . . . 29 16. Security Considerations . . . . . . . . . . . . . . . . . . . 29
17. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 29 17. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 30
17.1. Example: Bundle Address Selection . . . . . . . . . . . 29 17.1. Example: Bundle Address Selection . . . . . . . . . . . 30
17.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 31 17.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 32
17.3. Example: Offerer Adds A Media Description To A BUNDLE 17.3. Example: Offerer Adds A Media Description To A BUNDLE
Group . . . . . . . . . . . . . . . . . . . . . . . . . 32 Group . . . . . . . . . . . . . . . . . . . . . . . . . 33
17.4. Example: Offerer Moves A Media Description Out Of A 17.4. Example: Offerer Moves A Media Description Out Of A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 34
17.5. Example: Offerer Disables A Media Description Within A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 35 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 35
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 17.5. Example: Offerer Disables A Media Description Within A
19. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 37 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 36
20. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38
20.1. Normative References . . . . . . . . . . . . . . . . . . 43 19. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 38
20.2. Informative References . . . . . . . . . . . . . . . . . 45 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
Appendix A. Design Considerations . . . . . . . . . . . . . . . 45 20.1. Normative References . . . . . . . . . . . . . . . . . . 44
A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 45 20.2. Informative References . . . . . . . . . . . . . . . . . 46
A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 46 Appendix A. Design Considerations . . . . . . . . . . . . . . . 46
A.3. Usage of port number value zero . . . . . . . . . . . . . 47 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 46
A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 48 A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 47
A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 48 A.3. Usage of port number value zero . . . . . . . . . . . . . 49
A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 48 A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 49
A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 49 A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 50
A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
1. Introduction 1. Introduction
This specification defines a way to use a single address:port This specification defines a way to use a single address:port
combination (BUNDLE address) for receiving media associated with combination (BUNDLE address) for receiving media associated with
multiple SDP media descriptions ("m=" lines). multiple SDP media descriptions ("m=" lines).
This specification defines a new SDP Grouping Framework [RFC5888] This specification defines a new SDP Grouping Framework [RFC5888]
extension called 'BUNDLE'. The extension can be used with the extension called 'BUNDLE'. The extension can be used with the
Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264] Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264]
skipping to change at page 20, line 29 skipping to change at page 20, line 29
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
multiplexing for one or more "m=" lines (excluding any bundle-only
"m=" line) within the BUNDLE group, the offerer MUST associate an SDP
'rtcp' attribute [RFC3605] with those "m=" lines, as described in
[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 IP address and port combination for RTCP
MUST be unique in each bundled RTP-based "m=" line (excluding a MUST be unique in each bundled RTP-based "m=" line (excluding a
'bundle-only' "m=" line), similar to RTP. 'bundle-only' "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 offerer indicated
support of RTP/RTCP multiplexing [RFC5761] within a BUNDLE group in support of RTP/RTCP multiplexing [RFC5761] within a BUNDLE group in
the associated offer, the answerer MUST accept usage of RTP/RTCP the associated offer, the answerer MUST accept usage of RTP/RTCP
multiplexing within the BUNDLE group. If an SDP "rtcp-mux" attribute multiplexing within the BUNDLE group. If an SDP "rtcp-mux" attribute
was not associated with a bundled "m=" line in the associated offer, was not associated with a bundled "m=" line in the associated offer,
the answerer MUST NOT included that "m=" line in the BUNDLE group. the answerer MUST NOT included that "m=" line in the BUNDLE group.
If the offerer indicated exclusive support of RTP/RTCP multiplexing
for one or more bundled "m=" lines within the offer, and if the
answerer does not accept the usage of RTP/RTCP multiplexing within
the bundle group, the answerer MUST reject those "m=" lines.
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. The answerer MUST
NOT associate an SDP 'rtcp' attribute with any bundled "m=" line in NOT associate an SDP 'rtcp' attribute with any bundled "m=" line in
the answer. The answerer will use the port value of the selected the answer. The answerer will use the port value of the selected
offerer BUNDLE address for sending RTP and RTCP packets associated offerer BUNDLE address for sending RTP and RTCP packets associated
with each RTP-based bundled "m=" line towards the offerer. 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
skipping to change at page 21, line 22 skipping to change at page 21, line 33
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: If is considered a protocol error if the answerer has not
accpeted 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 generatees 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.
11. ICE Considerations 11. ICE Considerations
11.1. General 11.1. General
This section describes how to use the BUNDLE grouping extension This section describes how to use the BUNDLE grouping extension
skipping to change at page 37, 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-24
o - Reference and procedures associated with exclusive RTP/RTCP mux
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
o - Correct based on comment from Paul Kyzivat o - Correct based on comment from Paul Kyzivat
o -- 'received packets' replaced with 'received data' o -- 'received packets' replaced with 'received data'
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-20 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-20
skipping to change at page 44, line 50 skipping to change at page 46, line 7
Protocol (SDP) Grouping Framework", RFC 5888, Protocol (SDP) Grouping Framework", RFC 5888,
DOI 10.17487/RFC5888, June 2010, DOI 10.17487/RFC5888, June 2010,
<http://www.rfc-editor.org/info/rfc5888>. <http://www.rfc-editor.org/info/rfc5888>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
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-08 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-12
(work in progress), January 2015. (work in progress), January 2016.
[I-D.mmusic-mux-exclusive]
Holmberg, C., "Indicating Exclusive Support of RTP/RTCP
Multiplexing using SDP", draft-ietf-mmusic-mux-
exclusive-00 (work in progress), January 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. 23 change blocks. 
41 lines changed or deleted 62 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/