draft-ietf-mmusic-sdp-bundle-negotiation-28.txt   draft-ietf-mmusic-sdp-bundle-negotiation-29.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: October 16, 2016 C. Jennings Expires: October 17, 2016 C. Jennings
Cisco Cisco
April 14, 2016 April 15, 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-28.txt draft-ietf-mmusic-sdp-bundle-negotiation-29.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, specified by multiple SDP media referred to as bundled media, specified by 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 October 16, 2016. This Internet-Draft will expire on October 17, 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 21 skipping to change at page 3, line 21
10.1.2. Payload Type (PT) Value Reuse . . . . . . . . . . . 19 10.1.2. Payload Type (PT) Value Reuse . . . . . . . . . . . 19
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 . . . . . . . . . . . . . . . . . 20 10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 20
10.3.1. General . . . . . . . . . . . . . . . . . . . . . . 20 10.3.1. General . . . . . . . . . . . . . . . . . . . . . . 20
10.3.2. SDP Offer/Answer Procedures . . . . . . . . . . . . 20 10.3.2. SDP Offer/Answer Procedures . . . . . . . . . . . . 20
11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 22 11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 22
11.1. General . . . . . . . . . . . . . . . . . . . . . . . . 22 11.1. General . . . . . . . . . . . . . . . . . . . . . . . . 22
11.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 23 11.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 23
11.2.1. General . . . . . . . . . . . . . . . . . . . . . . 23 11.2.1. General . . . . . . . . . . . . . . . . . . . . . . 23
11.2.2. Generating the Initial SDP Offer . . . . . . . . . . 23 11.2.2. Generating the Initial SDP Offer . . . . . . . . . . 24
11.2.3. Generating the SDP Answer . . . . . . . . . . . . . 24 11.2.3. Generating the SDP Answer . . . . . . . . . . . . . 24
11.2.4. Offerer Processing of the SDP Answer . . . . . . . . 24 11.2.4. Offerer Processing of the SDP Answer . . . . . . . . 24
11.2.5. Modifying the Session . . . . . . . . . . . . . . . 24 11.2.5. Modifying the Session . . . . . . . . . . . . . . . 24
12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 24 12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 24
13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 25 13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 25
13.1. General . . . . . . . . . . . . . . . . . . . . . . . . 25 13.1. General . . . . . . . . . . . . . . . . . . . . . . . . 25
13.2. Original text of section 5.1 (2nd paragraph) of RFC 3264 25 13.2. Original text of section 5.1 (2nd paragraph) of RFC 3264 25
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 25
13.4. Original text of section 8.2 (2nd paragraph) of RFC 3264 26 13.4. Original text of section 8.2 (2nd paragraph) of RFC 3264 26
skipping to change at page 3, line 44 skipping to change at page 3, line 44
13.6. Original text of section 8.4 (6th paragraph) of RFC 3264 26 13.6. Original text of section 8.4 (6th paragraph) of RFC 3264 26
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 26
14. RTP/RTCP extensions for identification-tag transport . . . . 27 14. RTP/RTCP extensions for identification-tag transport . . . . 27
14.1. General . . . . . . . . . . . . . . . . . . . . . . . . 27 14.1. General . . . . . . . . . . . . . . . . . . . . . . . . 27
14.2. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 28 14.2. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 28
14.3. RTP MID Header Extension . . . . . . . . . . . . . . . . 28 14.3. RTP MID Header Extension . . . . . . . . . . . . . . . . 28
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
15.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 29 15.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 29
15.2. New RTP Header Extension URI . . . . . . . . . . . . . . 29 15.2. New RTP Header Extension URI . . . . . . . . . . . . . . 29
15.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 29 15.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 30
15.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 30 15.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 30
16. Security Considerations . . . . . . . . . . . . . . . . . . . 30 16. Security Considerations . . . . . . . . . . . . . . . . . . . 30
17. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 31 17. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 31
17.1. Example: Bundle Address Selection . . . . . . . . . . . 31 17.1. Example: Bundle Address Selection . . . . . . . . . . . 31
17.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 33 17.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 33
17.3. Example: Offerer Adds A Media Description To A BUNDLE 17.3. Example: Offerer Adds A Media Description To A BUNDLE
Group . . . . . . . . . . . . . . . . . . . . . . . . . 34 Group . . . . . . . . . . . . . . . . . . . . . . . . . 34
17.4. Example: Offerer Moves A Media Description Out Of A 17.4. Example: Offerer Moves A Media Description Out Of A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 36 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 36
17.5. Example: Offerer Disables A Media Description Within A 17.5. Example: Offerer Disables A Media Description Within A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 37 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 37
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
19. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 39 19. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 39
20. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 46
20.1. Normative References . . . . . . . . . . . . . . . . . . 46 20.1. Normative References . . . . . . . . . . . . . . . . . . 46
20.2. Informative References . . . . . . . . . . . . . . . . . 47 20.2. Informative References . . . . . . . . . . . . . . . . . 48
Appendix A. Design Considerations . . . . . . . . . . . . . . . 48 Appendix A. Design Considerations . . . . . . . . . . . . . . . 48
A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 48 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 48
A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 49 A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 49
A.3. Usage of port number value zero . . . . . . . . . . . . . 50 A.3. Usage of port number value zero . . . . . . . . . . . . . 50
A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 50 A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 51
A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 51 A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 51
A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 51 A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 51
A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 52 A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
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 specified by combination (BUNDLE address) for receiving media specified by
multiple SDP media descriptions ("m=" lines). multiple SDP media descriptions ("m=" lines).
skipping to change at page 20, line 34 skipping to change at page 20, line 34
packets associated with the BUNDLE group. Each endpoint will send packets associated with the BUNDLE group. Each endpoint will send
the packets towards the BUNDLE address of the other endpoint. The the packets towards the BUNDLE address of the other endpoint. The
same address:port combination MAY be used for receiving RTP packets same address:port combination MAY be used for receiving RTP packets
and RTCP packets. and RTCP packets.
10.3.2. SDP Offer/Answer Procedures 10.3.2. SDP Offer/Answer Procedures
10.3.2.1. General 10.3.2.1. General
This section describes how an offerer and answerer use the SDP 'rtcp- This section describes how an offerer and answerer use the SDP 'rtcp-
mux' attribute [RFC5761] to negotiate usage of RTP/RTCP multiplexing mux' attribute [RFC5761] and the SDP 'rtcp-mux-only' attribute
for RTP-based media specified by a BUNDLE group. [I-D.ietf-mmusic-mux-exclusive] to negotiate usage of RTP/RTCP
multiplexing for RTP-based media specified by a BUNDLE group.
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 either an SDP 'rtcp-mux' attribute [RFC5761] or an SDP
RTP-based "m=" line (including any bundle-only "m=" line) in the 'rtcp-mux-only' attribute [I-D.ietf-mmusic-mux-exclusive] with each
offer. bundled RTP-based "m=" line in the offer. The offerer MUST associate
an SDP 'rtcp-mux-only' attribute with each bundle-only "m=" line. If
the offerer associates a 'rtcp-mux-only' attribute with an "m=" line,
the offerer may also associate a 'rtcp-mux' attribute with the same
"m=" line, as described in [I-D.ietf-mmusic-mux-exclusive].
If an offerer wants to indicate exclusive support of RTP/RTCP NOTE: Within a BUNDLE group, the offerer can associate the SDP 'rtcp-
multiplexing [I-D.ietf-mmusic-mux-exclusive] for one or more "m=" mux' attribute with some of the RTP-based "m=" lines, while it
lines within the BUNDLE group, the offerer MUST associate an SDP associates the SDP 'rtcp-mux-only' attribute to other RTP-based "m="
'rtcp-mux-exclusive' attribute with those "m=" lines. lines, depending on whether the offerer supports fallback to usage of
a separate port for RTCP in case the answerer does not include the
"m=" line in the BUNDLE group.
NOTE: The offerer might also associate an SDP 'rtcp' attribute NOTE: If the offerer associates an SDP 'rtcp-mux' attribute with an
"m=" line, the offerer can 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, as described in
fallback port will only be used in case the answerer does not include [RFC5761]. However, the fallback port will only be used in case the
the "m=" line in the BUNDLE group in the associated answer. answerer does not include the "m=" line in the BUNDLE group in the
associated answer.
In the initial offer, the address:port combination for RTCP MUST be In the initial offer, the address:port combination for RTCP MUST be
unique in each bundled RTP-based "m=" line (excluding a 'bundle-only' unique in each bundled RTP-based "m=" line (excluding a '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 answerer accepts an RTP- When an answerer generates an answer, if the answerer accepts one or
based "m=" line within a BUNDLE group, the answerer MUST enable usage more RTP-based "m=" lines within a BUNDLE group, the answerer MUST
of RTP/RTCP multiplexing. The answerer MUST associate an SDP "rtcp- enable usage of RTP/RTCP multiplexing. The answerer MUST associate
mux" attribute with the "m=" line in the answer. In addition, if the an SDP "rtcp-mux" attribute with each RTP-based "m=" line in the
"m=" line in the corresponding offer contained an SDP "rtcp-mux- answer. In addition, if an "m=" line in the corresponding offer
exclusive" attribute, the answerer MUST associate an SDP "rtcp-mux- contained an SDP "rtcp-mux-only" attribute, the answerer MUST also
exclusive" attribute with the "m=" line in the answer. associate an SDP "rtcp-mux-only" attribute with the "m=" line in the
answer.
If an RTP-based "m=" line in the corresponding offer did not contain If an RTP-based "m=" line in the corresponding offer did not contain
an SDP "rtcp-mux" attribute, the answerer MUST NOT accept the "m=" an SDP "rtcp-mux" attribute or an SDP "rtcp-mux-only" attribute, the
line within a BUNDLE group in the answer. answerer MUST NOT include the "m=" line within a BUNDLE group in the
answer.
If an RTP-based "m=" line in the corresponding offer contained an SDP If an RTP-based "m=" line in the corresponding offer contained an SDP
"rtcp-mux-exclusive" attribute, and if the answerer moves the "m=" "rtcp-mux-only" attribute, and if the answerer moves the "m=" line
line out of the BUNDLE group in the answer Section 8.4.4, the out of the BUNDLE group in the answer Section 8.4.4, the answerer
answerer MUST still either enable RTP/RTCP multiplexing, or reject MUST still either enable RTP/RTCP multiplexing for the media
the "m=" line Section 8.4.5. associated with the "m=" line, or reject the "m=" line Section 8.4.5.
When the answerer accepts the usage of RTP/RTCP multiplexing within
the BUNDLE group, it MUST associate an SDP 'rtcp-mux' attribute with
each bundled RTP-based "m=" line in the answer. In addition, if the
"m=" line in the corresponding offer contained an SDP 'rtcp-mux-
exclusive' attribute, the answerer MUST associated an SDP 'rtcp-mux-
exclusive' attribute with the corresponding "m=" line in the answer,
as described in.
The answerer MUST NOT associate an SDP 'rtcp' attribute with any The answerer MUST NOT associate an SDP 'rtcp' attribute with any
bundled "m=" line in the answer. The answerer will use the port bundled "m=" line in the answer. The answerer will use the port
value of the selected offerer BUNDLE address for sending RTP and RTCP value of the selected offerer BUNDLE address for sending RTP and RTCP
packets associated with each RTP-based bundled "m=" line towards the packets associated with each RTP-based bundled "m=" line towards the
offerer. 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
skipping to change at page 22, line 21 skipping to change at page 22, line 26
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: It 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 or an SDP 'rtcp-mux-only' attribute with
(including any bundled "m=" line that the offerer wants to add to the each RTP-based bundled "m=" line within the BUNDLE group (including
any bundled RTP-based "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
together with the Interactive Connectivity Establishment (ICE) together with the Interactive Connectivity Establishment (ICE)
mechanism [I-D.ietf-ice-rfc5245bis]. mechanism [I-D.ietf-ice-rfc5245bis].
skipping to change at page 39, line 37 skipping to change at page 39, 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-28
o - Alignment with exclusive mux procedures.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-27 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-27
o - Yet another terminology change. o - Yet another terminology change.
o - Mux category considerations added. o - Mux category considerations added.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-26 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-26
o - ICE considerations modified: ICE-related SDP attributes only o - ICE considerations modified: ICE-related SDP attributes only
added to the bundled m- line representing the selected BUNDLE added to the bundled m- line representing the selected BUNDLE
address. address.
o - Reference to draft-ietf-mmusic-ice-sip-sdp added. o - Reference to draft-ietf-mmusic-ice-sip-sdp added.
o - Reference to RFC 5245 replaced with reference to draft-ietf-ice- o - Reference to RFC 5245 replaced with reference to draft-ietf-ice-
rfc5245bis. rfc5245bis.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-25 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-25
 End of changes. 19 change blocks. 
45 lines changed or deleted 52 lines changed or added

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