draft-ietf-mmusic-sdp-bundle-negotiation-53.txt   draft-ietf-mmusic-sdp-bundle-negotiation-54.txt 
MMUSIC Working Group C. Holmberg MMUSIC Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 3264,7941 (if approved) H. Alvestrand Updates: 3264,5888,7941 (if approved) H. Alvestrand
Intended status: Standards Track Google Intended status: Standards Track Google
Expires: March 24, 2019 C. Jennings Expires: June 18, 2019 C. Jennings
Cisco Cisco
September 20, 2018 December 15, 2018
Negotiating Media Multiplexing Using the Session Description Protocol Negotiating Media Multiplexing Using the Session Description Protocol
(SDP) (SDP)
draft-ietf-mmusic-sdp-bundle-negotiation-53.txt draft-ietf-mmusic-sdp-bundle-negotiation-54.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 transport (5-tuple) for sending and receiving media described single transport (5-tuple) for sending and receiving media described
by multiple SDP media descriptions ("m=" sections). Such transport by multiple SDP media descriptions ("m=" sections). Such transport
is referred to as a BUNDLE transport, and the media is referred to as is referred to as a BUNDLE transport, and the media is referred to as
bundled media. The "m=" sections that use the BUNDLE transport form bundled media. The "m=" sections that use the BUNDLE transport form
a BUNDLE group. a BUNDLE group.
This specification updates RFC 3264, to also allow assigning a zero This specification updates RFC 3264, to also allow assigning a zero
port value to a "m=" section in cases where the media described by port value to a "m=" section in cases where the media described by
the "m=" section is not disabled or rejected. the "m=" section is not disabled or rejected.
This specification updates RFC 5888, to also allow an SDP 'group'
attribute to contain an identification-tag that identifies a "m="
section with the port set to zero.
This specification defines a new RTP Control Protocol (RTCP) source This specification defines a new RTP Control Protocol (RTCP) source
description (SDES) item and a new RTP header extension that can be description (SDES) item and a new RTP header extension that can be
used to correlate bundled RTP/RTCP packets with their appropriate used to correlate bundled RTP/RTCP packets with their appropriate
"m=" section. "m=" section.
This specification updates RFC 7941, by adding an exception, for the This specification updates RFC 7941, by adding an exception, for the
MID RTP header extension, to the requirement regarding protection of MID RTP header extension, to the requirement regarding protection of
an SDES RTP header extension carrying an SDES item for the MID RTP an SDES RTP header extension carrying an SDES item for the MID RTP
header extension. header extension.
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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://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 March 24, 2019. This Internet-Draft will expire on June 18, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://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
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
skipping to change at page 3, line 38 skipping to change at page 3, line 43
10. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 32 10. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 32
11. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 33 11. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 33
12. RTP Header Extensions Consideration . . . . . . . . . . . . . 34 12. RTP Header Extensions Consideration . . . . . . . . . . . . . 34
13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 34 13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 34
13.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 34 13.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 34
13.2. New text replacing section 5.1 (2nd paragraph) of RFC 13.2. New text replacing section 5.1 (2nd paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 35
13.3. Original text of section 8.4 (6th paragraph) of RFC 3264 35 13.3. Original text of section 8.4 (6th paragraph) of RFC 3264 35
13.4. New text replacing section 8.4 (6th paragraph) of RFC 13.4. New text replacing section 8.4 (6th paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 35
14. RTP/RTCP extensions for identification-tag transport . . . . 36 14. Update to RFC 5888 . . . . . . . . . . . . . . . . . . . . . 36
14.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 37 14.1. Original text of section 9.2 (3rd paragraph) of RFC 5888 36
14.2. RTP SDES Header Extension For MID . . . . . . . . . . . 37 14.2. New text replacing section 9.2 (3rd paragraph) of RFC
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 5888 . . . . . . . . . . . . . . . . . . . . . . . . . . 36
15.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 38 15. RTP/RTCP extensions for identification-tag transport . . . . 36
15.2. New RTP SDES Header Extension URI . . . . . . . . . . . 38 15.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 37
15.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 39 15.2. RTP SDES Header Extension For MID . . . . . . . . . . . 38
15.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 39 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
16. Security Considerations . . . . . . . . . . . . . . . . . . . 40 16.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 38
17. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 41 16.2. New RTP SDES Header Extension URI . . . . . . . . . . . 39
17.1. Example: Tagged m= Section Selections . . . . . . . . . 41 16.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 39
17.2. Example: BUNDLE Group Rejected . . . . . . . . . . . . . 42 16.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 40
17.3. Example: Offerer Adds a Media Description to a BUNDLE 17. Security Considerations . . . . . . . . . . . . . . . . . . . 40
18. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 41
18.1. Example: Tagged m= Section Selections . . . . . . . . . 41
18.2. Example: BUNDLE Group Rejected . . . . . . . . . . . . . 43
18.3. Example: Offerer Adds a Media Description to a BUNDLE
Group . . . . . . . . . . . . . . . . . . . . . . . . . 45 Group . . . . . . . . . . . . . . . . . . . . . . . . . 45
18.4. Example: Offerer Moves a Media Description Out of a
17.4. Example: Offerer Moves a Media Description Out of a
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 46 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 46
17.5. Example: Offerer Disables a Media Description Within a 18.5. Example: Offerer Disables a Media Description Within a
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 48 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 48
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50
19. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 50 20. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 50
20. References . . . . . . . . . . . . . . . . . . . . . . . . . 62 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 61
20.1. Normative References . . . . . . . . . . . . . . . . . . 62 21.1. Normative References . . . . . . . . . . . . . . . . . . 61
20.2. Informative References . . . . . . . . . . . . . . . . . 64 21.2. Informative References . . . . . . . . . . . . . . . . . 64
Appendix A. Design Considerations . . . . . . . . . . . . . . . 65 Appendix A. Design Considerations . . . . . . . . . . . . . . . 65
A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 66 A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 65
A.2. Usage of Port Number Value Zero . . . . . . . . . . . . . 67 A.2. Usage of Port Number Value Zero . . . . . . . . . . . . . 67
A.3. B2BUA And Proxy Interoperability . . . . . . . . . . . . 67 A.3. B2BUA And Proxy Interoperability . . . . . . . . . . . . 67
A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 68 A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 68
A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 68 A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 68
A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 69 A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 68
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 69
1. Introduction 1. Introduction
1.1. Background 1.1. Background
When the SDP offer/answer mechanism [RFC3264] is used to negotiate When the SDP offer/answer mechanism [RFC3264] is used to negotiate
the establishment of multimedia communication sessions, if separate the establishment of multimedia communication sessions, if separate
transports (5-tuples) are negotiated for each individual media transports (5-tuples) are negotiated for each individual media
stream, each transport consumes additional resources (especially when stream, each transport consumes additional resources (especially when
Interactive Connectivity Establishment (ICE) [RFC8445] is used). For Interactive Connectivity Establishment (ICE)
this reason, it is attractive to use a single transport for multiple [I-D.ietf-ice-rfc5245bis] is used). For this reason, it is
media streams. attractive to use a single transport for multiple media streams.
1.2. BUNDLE Mechanism 1.2. BUNDLE Mechanism
This specification defines a way to use a single transport (BUNDLE This specification defines a way to use a single transport (BUNDLE
transport) for sending and receiving media (bundled media) described transport) for sending and receiving media (bundled media) described
by multiple SDP media descriptions ("m=" sections). The address:port by multiple SDP media descriptions ("m=" sections). The address:port
combination used by an endpoint for sending and receiving bundled combination used by an endpoint for sending and receiving bundled
media is referred to as the BUNDLE address:port. The set of SDP media is referred to as the BUNDLE address:port. The set of SDP
attributes that are applied to each "m=" section within a BUNDLE attributes that are applied to each "m=" section within a BUNDLE
group is referred to as BUNDLE attributes. The same BUNDLE transport group is referred to as BUNDLE attributes. The same BUNDLE transport
skipping to change at page 5, line 10 skipping to change at page 5, line 19
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]
to negotiate which "m=" sections will become part of a BUNDLE group. to negotiate which "m=" sections will become part of a BUNDLE group.
In addition, the offerer and answerer [RFC3264] use the BUNDLE In addition, the offerer and answerer [RFC3264] use the BUNDLE
extension to negotiate the BUNDLE addresses:ports (offerer BUNDLE extension to negotiate the BUNDLE addresses:ports (offerer BUNDLE
address:port and answerer BUNDLE address:port) and the set of BUNDLE address:port and answerer BUNDLE address:port) and the set of BUNDLE
attributes (offerer BUNDLE attributes and answerer BUNDLE attributes) attributes (offerer BUNDLE attributes and answerer BUNDLE attributes)
that will be applied to each "m=" section within the BUNDLE group. that will be applied to each "m=" section within the BUNDLE group.
The use of a BUNDLE transport allows the usage of a single set of The use of a BUNDLE transport allows the usage of a single set of
Interactive Connectivity Establishment (ICE) [RFC8445] candidates for Interactive Connectivity Establishment (ICE)
the whole BUNDLE group. [I-D.ietf-ice-rfc5245bis] candidates for the whole BUNDLE group.
A given BUNDLE address:port MUST only be associated with a single A given BUNDLE address:port MUST only be associated with a single
BUNDLE group. If an SDP offer or answer contains multiple BUNDLE BUNDLE group. If an SDP offer or answer contains multiple BUNDLE
groups, the procedures in this specification apply to each group groups, the procedures in this specification apply to each group
independently. All RTP-based bundled media associated with a given independently. All RTP-based bundled media associated with a given
BUNDLE group belong to a single RTP session [RFC3550]. BUNDLE group belong to a single RTP session [RFC3550].
The BUNDLE extension is backward compatible. Endpoints that do not The BUNDLE extension is backward compatible. Endpoints that do not
support the extension are expected to generate offers and answers support the extension are expected to generate offers and answers
without an SDP 'group:BUNDLE' attribute, and are expected to assign a without an SDP 'group:BUNDLE' attribute, and are expected to assign a
skipping to change at page 10, line 33 skipping to change at page 10, line 33
SDP parameters and characteristics (including those associated with a SDP parameters and characteristics (including those associated with a
BUNDLE group) apply. Hence, if an offerer generates an offer in BUNDLE group) apply. Hence, if an offerer generates an offer in
order to negotiate a BUNDLE group, and the answerer rejects the order to negotiate a BUNDLE group, and the answerer rejects the
offer, the BUNDLE group is not created. offer, the BUNDLE group is not created.
The procedures in this section are independent of the media type or The procedures in this section are independent of the media type or
"m=" line proto value assigned to a bundled "m=" section. Section 9 "m=" line proto value assigned to a bundled "m=" section. Section 9
defines additional considerations for RTP based media. Section 6 defines additional considerations for RTP based media. Section 6
defines additional considerations for the usage of the SDP 'bundle- defines additional considerations for the usage of the SDP 'bundle-
only' attribute. Section 10 defines additional considerations for only' attribute. Section 10 defines additional considerations for
the usage of Interactive Connectivity Establishment (ICE) [RFC8445] the usage of Interactive Connectivity Establishment (ICE)
mechanism. [I-D.ietf-ice-rfc5245bis] mechanism.
Offers and answers can contain multiple BUNDLE groups. The Offers and answers can contain multiple BUNDLE groups. The
procedures in this section apply independently to a given BUNDLE procedures in this section apply independently to a given BUNDLE
group. group.
7.1. Generic SDP Considerations 7.1. Generic SDP Considerations
This section describes generic restrictions associated with the usage This section describes generic restrictions associated with the usage
of SDP parameters within a BUNDLE group. It also describes how to of SDP parameters within a BUNDLE group. It also describes how to
calculate a value for the whole BUNDLE group, when parameter and calculate a value for the whole BUNDLE group, when parameter and
skipping to change at page 13, line 15 skipping to change at page 13, line 15
o Include an SDP 'bundle-only' attribute [Section 7.2.1] in the "m=" o Include an SDP 'bundle-only' attribute [Section 7.2.1] in the "m="
section; and section; and
o Assign a zero port value to the "m=" section. o Assign a zero port value to the "m=" section.
NOTE: If the offerer assigns a zero port value to a bundled "m=" NOTE: If the offerer assigns a zero port value to a bundled "m="
section, but does not include an SDP 'bundle-only' attribute in the section, but does not include an SDP 'bundle-only' attribute in the
"m=" section, it is an indication that the offerer wants to disable "m=" section, it is an indication that the offerer wants to disable
the "m=" section [Section 7.5.3]. the "m=" section [Section 7.5.3].
[Section 7.2.2] and [Section 17.1] show an example of an initial [Section 7.2.2] and [Section 18.1] show an example of an initial
BUNDLE offer. BUNDLE offer.
7.2.1. Suggesting the Offerer tagged 'm=' section 7.2.1. Suggesting the Offerer tagged 'm=' section
In the initial BUNDLE offer, the bundled "m=" section indicated by In the initial BUNDLE offer, the bundled "m=" section indicated by
the offerer BUNDLE-tag is the suggested offerer tagged "m=" section. the offerer BUNDLE-tag is the suggested offerer tagged "m=" section.
The address:port combination associated with the "m=" section will be The address:port combination associated with the "m=" section will be
used by the offerer for sending and receiving bundled media if the used by the offerer for sending and receiving bundled media if the
answerer selects the "m=" section as the offerer tagged "m=" section answerer selects the "m=" section as the offerer tagged "m=" section
[Section 7.3.1]. In addition, if the answerer selects the "m=" [Section 7.3.1]. In addition, if the answerer selects the "m="
skipping to change at page 16, line 38 skipping to change at page 16, line 38
pick the next identification-tag in the identification-tag list in pick the next identification-tag in the identification-tag list in
the offer, and perform the same criteria check for the "m=" section the offer, and perform the same criteria check for the "m=" section
indicated by that identification-tag. If there are no more indicated by that identification-tag. If there are no more
identification-tags in the identification-tag list, the answerer MUST identification-tags in the identification-tag list, the answerer MUST
NOT create the BUNDLE group. Unless the answerer rejects the whole NOT create the BUNDLE group. Unless the answerer rejects the whole
offer, the answerer MUST apply the answerer procedures for moving an offer, the answerer MUST apply the answerer procedures for moving an
"m=" section out of a BUNDLE group [Section 7.3.2] or rejecting an "m=" section out of a BUNDLE group [Section 7.3.2] or rejecting an
"m=" section within a BUNDLE group [Section 7.3.3] to every bundled "m=" section within a BUNDLE group [Section 7.3.3] to every bundled
"m=" section in the offer when creating the answer. "m=" section in the offer when creating the answer.
[Section 17.1] shows an example of an offerer BUNDLE address:port [Section 18.1] shows an example of an offerer BUNDLE address:port
selection. selection.
[Section 7.3.4] and [Section 17.1] show an example of an answerer [Section 7.3.4] and [Section 18.1] show an example of an answerer
tagged "m=" section selection. tagged "m=" section selection.
7.3.2. Moving A Media Description Out Of A BUNDLE Group 7.3.2. Moving A Media Description Out Of A BUNDLE Group
When an answerer generates the answer, if the answerer wants to move When an answerer generates the answer, if the answerer wants to move
a bundled "m=" section out of the negotiated BUNDLE group, the a bundled "m=" section out of the negotiated BUNDLE group, the
answerer MUST first check the following criteria: answerer MUST first check the following criteria:
o In the corresponding offer, the "m=" section is within a o In the corresponding offer, the "m=" section is within a
previously negotiated BUNDLE group; and previously negotiated BUNDLE group; and
skipping to change at page 21, line 34 skipping to change at page 21, line 34
For the other bundled "m=" sections within the BUNDLE group, the For the other bundled "m=" sections within the BUNDLE group, the
offerer follows the procedures in [Section 7.5]. offerer follows the procedures in [Section 7.5].
An offerer MUST NOT move an "m=" section from one BUNDLE group to An offerer MUST NOT move an "m=" section from one BUNDLE group to
another within a single offer. If the offerer wants to move an "m=" another within a single offer. If the offerer wants to move an "m="
section from one BUNDLE group to another it MUST first move the section from one BUNDLE group to another it MUST first move the
BUNDLE group out of the current BUNDLE group, and then generate a BUNDLE group out of the current BUNDLE group, and then generate a
second offer where the "m=" section is added to another BUNDLE group second offer where the "m=" section is added to another BUNDLE group
[Section 7.5.1]. [Section 7.5.1].
[Section 17.4] shows an example of an offer for moving an "m=" [Section 18.4] shows an example of an offer for moving an "m="
section out of a BUNDLE group. section out of a BUNDLE group.
7.5.3. Disabling a Media Description in a BUNDLE Group 7.5.3. Disabling a Media Description in a BUNDLE Group
When an offerer generates a subsequent offer, in which it want to When an offerer generates a subsequent offer, in which it want to
disable a bundled "m=" section from a BUNDLE group, the offerer: disable a bundled "m=" section from a BUNDLE group, the offerer:
o MUST assign a zero port value to the "m=" section, following the o MUST assign a zero port value to the "m=" section, following the
procedures in [RFC4566]; and procedures in [RFC4566]; and
o MUST NOT place the identification-tag associated with the "m=" o MUST NOT place the identification-tag associated with the "m="
section in the SDP 'group:BUNDLE' attribute identification-tag section in the SDP 'group:BUNDLE' attribute identification-tag
list associated with the BUNDLE group; and list associated with the BUNDLE group; and
o MUST NOT assign an SDP 'bundle-only' attribute to the "m=" o MUST NOT assign an SDP 'bundle-only' attribute to the "m="
section. section.
For the other bundled "m=" sections within the BUNDLE group, the For the other bundled "m=" sections within the BUNDLE group, the
offerer follows the procedures in [Section 7.5]. offerer follows the procedures in [Section 7.5].
[Section 17.5] shows an example of an offer and answer for disabling [Section 18.5] shows an example of an offer and answer for disabling
an "m=" section within a BUNDLE group. an "m=" section within a BUNDLE group.
8. Protocol Identification 8. Protocol Identification
Each "m=" section within a BUNDLE group MUST use the same transport- Each "m=" section within a BUNDLE group MUST use the same transport-
layer protocol. If bundled "m=" sections use different upper-layer layer protocol. If bundled "m=" sections use different upper-layer
protocols on top of the transport-layer protocol, there MUST exist a protocols on top of the transport-layer protocol, there MUST exist a
publicly available specification which describes a mechanism how to publicly available specification which describes a mechanism how to
associate received data with the correct protocol for this particular associate received data with the correct protocol for this particular
protocol combination. protocol combination.
skipping to change at page 25, line 11 skipping to change at page 25, line 11
that information. Due to this, before the offerer has received the that information. Due to this, before the offerer has received the
answer, the offerer will not be able to associate an RTP stream with answer, the offerer will not be able to associate an RTP stream with
the correct "m=" section using the SSRC value associated with the RTP the correct "m=" section using the SSRC value associated with the RTP
stream. In addition, the offerer and answerer may start using new stream. In addition, the offerer and answerer may start using new
SSRC values mid-session, without informing each other using the SDP SSRC values mid-session, without informing each other using the SDP
'ssrc' attribute. 'ssrc' attribute.
In order for an offerer and answerer to always be able to associate In order for an offerer and answerer to always be able to associate
an RTP stream with the correct "m=" section, the offerer and answerer an RTP stream with the correct "m=" section, the offerer and answerer
using the BUNDLE extension MUST support the mechanism defined in using the BUNDLE extension MUST support the mechanism defined in
Section 14, where the offerer and answerer insert the identification- Section 15, where the offerer and answerer insert the identification-
tag associated with an "m=" section (provided by the remote peer) tag associated with an "m=" section (provided by the remote peer)
into RTP and RTCP packets associated with a BUNDLE group. into RTP and RTCP packets associated with a BUNDLE group.
When using this mechanism, the mapping from an SSRC to an When using this mechanism, the mapping from an SSRC to an
identification-tag is carried in RTP header extensions or RTCP SDES identification-tag is carried in RTP header extensions or RTCP SDES
packets, as specified in Section 14. Since a compound RTCP packet packets, as specified in Section 15. Since a compound RTCP packet
can contain multiple RTCP SDES packets, and each RTCP SDES packet can can contain multiple RTCP SDES packets, and each RTCP SDES packet can
contain multiple chunks, a single RTCP packet can contain several contain multiple chunks, a single RTCP packet can contain several
SSRC to identification-tag mappings. The offerer and answerer SSRC to identification-tag mappings. The offerer and answerer
maintain tables used for routing that are updated each time an RTP/ maintain tables used for routing that are updated each time an RTP/
RTCP packet contains new information that affects how packets are to RTCP packet contains new information that affects how packets are to
be routed. be routed.
However, some legacy implementations may not include this However, some legacy implementations may not include this
identification-tag in their RTP and RTCP traffic when using the identification-tag in their RTP and RTCP traffic when using the
BUNDLE mechanism, and instead use a payload type based mechanism to BUNDLE mechanism, and instead use a payload type based mechanism to
skipping to change at page 32, line 22 skipping to change at page 32, line 22
When an offerer generates a subsequent offer, the offerer MUST When an offerer generates a subsequent offer, the offerer MUST
include an SDP 'rtcp-mux' attribute in the offerer tagged "m=" include an SDP 'rtcp-mux' attribute in the offerer tagged "m="
section, following the procedures for IDENTICAL multiplexing category section, following the procedures for IDENTICAL multiplexing category
attributes in Section 7.1.3. attributes in Section 7.1.3.
10. ICE Considerations 10. ICE Considerations
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 [RFC8445]. mechanism [I-D.ietf-ice-rfc5245bis].
The generic procedures for negotiating usage of ICE using SDP, The generic procedures for negotiating usage of ICE using SDP,
defined in [I-D.ietf-mmusic-ice-sip-sdp], also apply to usage of ICE defined in [I-D.ietf-mmusic-ice-sip-sdp], also apply to usage of ICE
with BUNDLE, with the following exceptions: with BUNDLE, with the following exceptions:
o When the BUNDLE transport has been established, ICE connectivity o When the BUNDLE transport has been established, ICE connectivity
checks and keep-alives only need to be performed for the BUNDLE checks and keep-alives only need to be performed for the BUNDLE
transport, instead of per individual bundled "m=" section within transport, instead of per individual bundled "m=" section within
the BUNDLE group. the BUNDLE group.
skipping to change at page 36, line 8 skipping to change at page 36, line 8
with connection oriented media. However, it can be useful in an with connection oriented media. However, it can be useful in an
initial offer when the offerer knows it wants to use a particular set initial offer when the offerer knows it wants to use a particular set
of media streams and formats, but doesn't know the addresses and of media streams and formats, but doesn't know the addresses and
ports at the time of the offer. Of course, when used, the port ports at the time of the offer. Of course, when used, the port
number MUST NOT be zero, if it would specify that the stream has been number MUST NOT be zero, if it would specify that the stream has been
disabled. However, an extension mechanism might specify different disabled. However, an extension mechanism might specify different
semantics of the zero port number usage. An agent MUST be capable of semantics of the zero port number usage. An agent MUST be capable of
receiving SDP with a connection address of 0.0.0.0, in which case it receiving SDP with a connection address of 0.0.0.0, in which case it
means that neither RTP nor RTCP is to be sent to the peer. means that neither RTP nor RTCP is to be sent to the peer.
14. RTP/RTCP extensions for identification-tag transport 14. Update to RFC 5888
This section updates RFC 5888 [RFC5888]), in order to allow
extensions to allow an SDP 'group' attribute containing an
identification-tag that identifies a "m=" section with the port set
to zero Section 9.2 (Group Value in Answers) of RFC 5888 is updated.
14.1. Original text of section 9.2 (3rd paragraph) of RFC 5888
SIP entities refuse media streams by setting the port to zero in the
corresponding "m" line. "a=group" lines MUST NOT contain
identification-tags that correspond to "m" lines with the port set to
zero.
14.2. New text replacing section 9.2 (3rd paragraph) of RFC 5888
SIP entities refuse media streams by setting the port to zero in the
corresponding "m" line. "a=group" lines MUST NOT contain
identification-tags that correspond to "m" lines with the port set to
zero, but an extension mechanism might specify different semantics
for including identification-tags that correspond to such "m=" lines.
15. RTP/RTCP extensions for identification-tag transport
SDP Offerers and Answerers [RFC3264] can associate identification- SDP Offerers and Answerers [RFC3264] can associate identification-
tags with "m=" sections within SDP Offers and Answers, using the tags with "m=" sections within SDP Offers and Answers, using the
procedures in [RFC5888]. Each identification-tag uniquely represents procedures in [RFC5888]. Each identification-tag uniquely represents
an "m=" section. an "m=" section.
This section defines a new RTCP SDES item [RFC3550], 'MID', which is This section defines a new RTCP SDES item [RFC3550], 'MID', which is
used to carry identification-tags within RTCP SDES packets. This used to carry identification-tags within RTCP SDES packets. This
section also defines a new RTP SDES header extension [RFC7941], which section also defines a new RTP SDES header extension [RFC7941], which
is used to carry the 'MID' RTCP SDES item in RTP packets. is used to carry the 'MID' RTCP SDES item in RTP packets.
skipping to change at page 37, line 14 skipping to change at page 37, line 36
in which this header extension is sent is intentionally not specified in which this header extension is sent is intentionally not specified
here, as it will depend on expected packet loss rate and loss here, as it will depend on expected packet loss rate and loss
patterns, the overhead the application can tolerate, and the patterns, the overhead the application can tolerate, and the
importance of immediate receipt of the identification-tag. importance of immediate receipt of the identification-tag.
For robustness, endpoints need to be prepared for situations where For robustness, endpoints need to be prepared for situations where
the reception of the identification-tag is delayed, and SHOULD NOT the reception of the identification-tag is delayed, and SHOULD NOT
terminate sessions in such cases, as the identification-tag is likely terminate sessions in such cases, as the identification-tag is likely
to arrive soon. to arrive soon.
14.1. RTCP MID SDES Item 15.1. RTCP MID SDES Item
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MID=TBD | length | identification-tag ... | MID=TBD | length | identification-tag ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The identification-tag payload is UTF-8 encoded [RFC3629], as in SDP. The identification-tag payload is UTF-8 encoded [RFC3629], as in SDP.
The identification-tag is not zero terminated. The identification-tag is not zero terminated.
[RFC EDITOR NOTE: Please replace TBD with the assigned SDES [RFC EDITOR NOTE: Please replace TBD with the assigned SDES
identifier value.] identifier value.]
14.2. RTP SDES Header Extension For MID 15.2. RTP SDES Header Extension For MID
The payload, containing the identification-tag, of the RTP SDES The payload, containing the identification-tag, of the RTP SDES
header extension element can be encoded using either the one-byte or header extension element can be encoded using either the one-byte or
two-byte header [RFC7941]. The identification-tag payload is UTF-8 two-byte header [RFC7941]. The identification-tag payload is UTF-8
encoded, as in SDP. encoded, as in SDP.
The identification-tag is not zero terminated. Note, that the set of The identification-tag is not zero terminated. Note, that the set of
header extensions included in the packet needs to be padded to the header extensions included in the packet needs to be padded to the
next 32-bit boundary using zero bytes [RFC8285]. next 32-bit boundary using zero bytes [RFC8285].
skipping to change at page 38, line 12 skipping to change at page 38, line 34
the properties of the RTP header extension mechanism, when using the the properties of the RTP header extension mechanism, when using the
one-byte header, a tag that is 1-3 bytes will result in a minimal one-byte header, a tag that is 1-3 bytes will result in a minimal
number of 32-bit words used for the RTP SDES header extension, in number of 32-bit words used for the RTP SDES header extension, in
case no other header extensions are included at the same time. Note, case no other header extensions are included at the same time. Note,
do take into account that some single characters when UTF-8 encoded do take into account that some single characters when UTF-8 encoded
will result in multiple octets. The identification-tag MUST NOT will result in multiple octets. The identification-tag MUST NOT
contain any user information, and applications SHALL avoid generating contain any user information, and applications SHALL avoid generating
the identification-tag using a pattern that enables user- or the identification-tag using a pattern that enables user- or
application identification. application identification.
15. IANA Considerations 16. IANA Considerations
15.1. New SDES item 16.1. New SDES item
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this
document.] document.]
[RFC EDITOR NOTE: Please replace TBD with the assigned SDES [RFC EDITOR NOTE: Please replace TBD with the assigned SDES
identifier value.] identifier value.]
This document adds the MID SDES item to the IANA "RTP SDES item This document adds the MID SDES item to the IANA "RTP SDES item
types" registry as follows: types" registry as follows:
Value: TBD Value: TBD
Abbrev.: MID Abbrev.: MID
Name: Media Identification Name: Media Identification
Reference: RFCXXXX Reference: RFCXXXX
15.2. New RTP SDES Header Extension URI 16.2. New RTP SDES Header Extension URI
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this
document.] document.]
This document defines a new extension URI in the RTP SDES Compact This document defines a new extension URI in the RTP SDES Compact
Header Extensions sub-registry of the RTP Compact Header Extensions Header Extensions sub-registry of the RTP Compact Header Extensions
registry sub-registry, according to the following data: registry sub-registry, according to the following data:
Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid
Description: Media identification Description: Media identification
skipping to change at page 39, line 19 skipping to change at page 39, line 28
The SDES item does not reveal privacy information about the users. The SDES item does not reveal privacy information about the users.
It is simply used to associate RTP-based media with the correct SDP It is simply used to associate RTP-based media with the correct SDP
media description ("m=" section) in the SDP used to negotiate the media description ("m=" section) in the SDP used to negotiate the
media. media.
The purpose of the extension is for the offerer to be able to The purpose of the extension is for the offerer to be able to
associate received multiplexed RTP-based media before the offerer associate received multiplexed RTP-based media before the offerer
receives the associated SDP answer. receives the associated SDP answer.
15.3. New SDP Attribute 16.3. New SDP Attribute
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this
document.] document.]
This document defines a new SDP media-level attribute, 'bundle-only', This document defines a new SDP media-level attribute, 'bundle-only',
according to the following data: according to the following data:
Attribute name: bundle-only Attribute name: bundle-only
Type of attribute: media Type of attribute: media
Subject to charset: No Subject to charset: No
Purpose: Request a media description to be accepted Purpose: Request a media description to be accepted
in the answer only if kept within a BUNDLE in the answer only if kept within a BUNDLE
group by the answerer. group by the answerer.
Appropriate values: N/A Appropriate values: N/A
Contact name: IESG Contact name: IESG
Contact e-mail: iesg@ietf.org Contact e-mail: iesg@ietf.org
Reference: RFCXXXX Reference: RFCXXXX
Mux category: NORMAL Mux category: NORMAL
15.4. New SDP Group Semantics 16.4. New SDP Group Semantics
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this
document.] document.]
This document registers the following semantics with IANA in the This document registers the following semantics with IANA in the
"Semantics for the "group" SDP Attribute" subregistry (under the "Semantics for the "group" SDP Attribute" subregistry (under the
"Session Description Protocol (SDP) Parameters" registry: "Session Description Protocol (SDP) Parameters" registry:
Semantics Token Reference Semantics Token Reference
------------------------------------- ------ --------- ------------------------------------- ------ ---------
Media bundling BUNDLE [RFCXXXX] Media bundling BUNDLE [RFCXXXX]
Mux category: NORMAL Mux category: NORMAL
16. Security Considerations 17. Security Considerations
The security considerations defined in [RFC3264] and [RFC5888] apply The security considerations defined in [RFC3264] and [RFC5888] apply
to the BUNDLE extension. Bundle does not change which information, to the BUNDLE extension. Bundle does not change which information,
e.g., RTP streams, flows over the network, with the exception of the e.g., RTP streams, flows over the network, with the exception of the
usage of the MID SDES item as discussed below. Primarily it changes usage of the MID SDES item as discussed below. Primarily it changes
which addresses and ports, and thus in which (RTP) sessions the which addresses and ports, and thus in which (RTP) sessions the
information is flowing. This affects the security contexts being information is flowing. This affects the security contexts being
used and can cause previously separated information flows to share used and can cause previously separated information flows to share
the same security context. This has very little impact on the the same security context. This has very little impact on the
performance of the security mechanism of the RTP sessions. In cases performance of the security mechanism of the RTP sessions. In cases
skipping to change at page 41, line 25 skipping to change at page 41, line 35
However, assuming the above requirements and recommendations are However, assuming the above requirements and recommendations are
followed, there are no known significant security risks with leaving followed, there are no known significant security risks with leaving
the MID RTP header extension without confidentiality protection. the MID RTP header extension without confidentiality protection.
Therefore, this specification updates RFC 7941 by adding the Therefore, this specification updates RFC 7941 by adding the
exception that this requirement MAY be ignored for the MID RTP header exception that this requirement MAY be ignored for the MID RTP header
extension. Security mechanisms for RTP/RTCP are discussed in Options extension. Security mechanisms for RTP/RTCP are discussed in Options
for Securing RTP Sessions [RFC7201], for example SRTP [RFC3711] can for Securing RTP Sessions [RFC7201], for example SRTP [RFC3711] can
provide the necessary security functions of ensuring the integrity provide the necessary security functions of ensuring the integrity
and source authenticity. and source authenticity.
17. Examples 18. Examples
17.1. Example: Tagged m= Section Selections 18.1. Example: Tagged m= Section Selections
The example below shows: The example below shows:
o An initial BUNDLE offer, in which the offerer wants to negotiate a o An initial BUNDLE offer, in which the offerer wants to negotiate a
BUNDLE group, and indicates the audio m= section as the suggested BUNDLE group, and indicates the audio m= section as the suggested
offerer tagged "m=" section. offerer tagged "m=" section.
o An initial BUNDLE answer, in which the answerer accepts the o An initial BUNDLE answer, in which the answerer accepts the
creation of the BUNDLE group, selects the audio m= section in the creation of the BUNDLE group, selects the audio m= section in the
offer as the offerer tagged "m=" section, selects the audio "m=" offer as the offerer tagged "m=" section, selects the audio "m="
skipping to change at page 42, line 43 skipping to change at page 43, line 6
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 0 RTP/AVP 32 m=video 0 RTP/AVP 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=bundle-only a=bundle-only
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
17.2. Example: BUNDLE Group Rejected 18.2. Example: BUNDLE Group Rejected
The example below shows: The example below shows:
o An initial BUNDLE offer, in which the offerer wants to negotiate a o An initial BUNDLE offer, in which the offerer wants to negotiate a
BUNDLE group, and indicates the audio m= section as the suggested BUNDLE group, and indicates the audio m= section as the suggested
offerer tagged "m=" section. offerer tagged "m=" section.
o An initial BUNDLE answer, in which the answerer rejects the o An initial BUNDLE answer, in which the answerer rejects the
creation of the BUNDLE group, generates a normal answer and creation of the BUNDLE group, generates a normal answer and
assigns a unique address:port to each "m=" section in the answer. assigns a unique address:port to each "m=" section in the answer.
skipping to change at page 45, line 5 skipping to change at page 45, line 5
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
b=AS:200 b=AS:200
a=rtcp-mux a=rtcp-mux
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
m=video 30000 RTP/AVP 32 m=video 30000 RTP/AVP 32
b=AS:1000 b=AS:1000
a=rtcp-mux a=rtcp-mux
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
17.3. Example: Offerer Adds a Media Description to a BUNDLE Group 18.3. Example: Offerer Adds a Media Description to a BUNDLE Group
The example below shows: The example below shows:
o A subsequent offer, in which the offerer adds a new bundled "m=" o A subsequent offer, in which the offerer adds a new bundled "m="
section (video), indicated by the "zen" identification-tag, to a section (video), indicated by the "zen" identification-tag, to a
previously negotiated BUNDLE group, indicates the new "m=" section previously negotiated BUNDLE group, indicates the new "m=" section
as the offerer tagged "m=" section and assigns the offerer BUNDLE as the offerer tagged "m=" section and assigns the offerer BUNDLE
address:port to that "m=" section. address:port to that "m=" section.
o A subsequent answer, in which the answerer indicates the new video o A subsequent answer, in which the answerer indicates the new video
skipping to change at page 46, line 35 skipping to change at page 46, line 35
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 20000 RTP/AVP 66 m=video 20000 RTP/AVP 66
b=AS:1000 b=AS:1000
a=mid:zen a=mid:zen
a=rtcp-mux a=rtcp-mux
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
17.4. Example: Offerer Moves a Media Description Out of a BUNDLE Group 18.4. Example: Offerer Moves a Media Description Out of a BUNDLE Group
The example below shows: The example below shows:
o A subsequent offer, in which the offerer removes a "m=" section o A subsequent offer, in which the offerer removes a "m=" section
(video), indicated by the "zen" identification-tag, from a (video), indicated by the "zen" identification-tag, from a
previously negotiated BUNDLE group, indicates one of the bundled previously negotiated BUNDLE group, indicates one of the bundled
"m=" sections (audio) remaining in the BUNDLE group as the offerer "m=" sections (audio) remaining in the BUNDLE group as the offerer
tagged "m=" section and assigns the offerer BUNDLE address:port to tagged "m=" section and assigns the offerer BUNDLE address:port to
that "m=" section. that "m=" section.
skipping to change at page 48, line 17 skipping to change at page 48, line 17
a=bundle-only a=bundle-only
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 60000 RTP/AVP 66 m=video 60000 RTP/AVP 66
b=AS:1000 b=AS:1000
a=mid:zen a=mid:zen
a=rtcp-mux a=rtcp-mux
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
17.5. Example: Offerer Disables a Media Description Within a BUNDLE 18.5. Example: Offerer Disables a Media Description Within a BUNDLE
Group Group
The example below shows: The example below shows:
o A subsequent offer, in which the offerer disables (by assigning a o A subsequent offer, in which the offerer disables (by assigning a
zero port value) a "m=" section (video), indicated by the "zen" zero port value) a "m=" section (video), indicated by the "zen"
identification-tag, from a previously negotiated BUNDLE group, identification-tag, from a previously negotiated BUNDLE group,
indicates one of the bundled "m=" sections (audio) remaining indicates one of the bundled "m=" sections (audio) remaining
active in the BUNDLE group as the offerer tagged "m=" section and active in the BUNDLE group as the offerer tagged "m=" section and
assigns the offerer BUNDLE address:port to that "m=" section. assigns the offerer BUNDLE address:port to that "m=" section.
skipping to change at page 50, line 5 skipping to change at page 50, line 5
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=bundle-only a=bundle-only
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 0 RTP/AVP 66 m=video 0 RTP/AVP 66
a=mid:zen a=mid:zen
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
18. Acknowledgements 19. Acknowledgements
The usage of the SDP grouping extension for negotiating bundled media The usage of the SDP grouping extension for negotiating bundled media
is based on similar alternatives proposed by Harald Alvestrand and is based on similar alternatives proposed by Harald Alvestrand and
Cullen Jennings. The BUNDLE extension described in this document is Cullen Jennings. The BUNDLE extension described in this document is
based on the different alternative proposals, and text (e.g., SDP based on the different alternative proposals, and text (e.g., SDP
examples) have been borrowed (and, in some cases, modified) from examples) have been borrowed (and, in some cases, modified) from
those alternative proposals. those alternative proposals.
The SDP examples are also modified versions from the ones in the The SDP examples are also modified versions from the ones in the
Alvestrand proposal. Alvestrand proposal.
skipping to change at page 50, line 37 skipping to change at page 50, 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 Charlie Kaufman for performing the Sec-Dir review. Thanks to Charlie Kaufman for performing the Sec-Dir review.
Thanks to Linda Dunbar for performing the Gen-ART review. Thanks to Linda Dunbar for performing the Gen-ART review.
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 20. 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-52
o Editorial fix: colon added to exmap attribute examples.
o Reference updates.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-51 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-51
o Changes based on IESG reviews. o Changes based on IESG reviews.
o - Clarification of 'initial offer' terminology. o - Clarification of 'initial offer' terminology.
o - Merging of tagged m- section selection sections. o - Merging of tagged m- section selection sections.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-50 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-50
skipping to change at page 62, line 5 skipping to change at page 61, line 42
o Draft name changed. o Draft name changed.
o Harald Alvestrand added as co-author. o Harald Alvestrand added as co-author.
o "Multiplex" terminology changed to "bundle". o "Multiplex" terminology changed to "bundle".
o Added text about single versus multiple RTP Sessions. o Added text about single versus multiple RTP Sessions.
o Added reference to RFC 3550. o Added reference to RFC 3550.
20. References 21. References
20.1. Normative References 21.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002, DOI 10.17487/RFC3264, June 2002, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc3264>. editor.org/info/rfc3264>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/info/rfc3550>. July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
in Session Description Protocol (SDP)", RFC 3605, in Session Description Protocol (SDP)", RFC 3605,
DOI 10.17487/RFC3605, October 2003, DOI 10.17487/RFC3605, October 2003, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc3605>. editor.org/info/rfc3605>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>. 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004, RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/info/rfc3711>. <https://www.rfc-editor.org/info/rfc3711>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566, Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <https://www.rfc-editor.org/info/rfc4566>. July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",
BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007,
<https://www.rfc-editor.org/info/rfc4961>. <https://www.rfc-editor.org/info/rfc4961>.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, Control Packets on a Single Port", RFC 5761,
DOI 10.17487/RFC5761, April 2010, DOI 10.17487/RFC5761, April 2010, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc5761>. editor.org/info/rfc5761>.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, Real-time Transport Protocol (SRTP)", RFC 5764,
DOI 10.17487/RFC5764, May 2010, DOI 10.17487/RFC5764, May 2010, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc5764>. editor.org/info/rfc5764>.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, Protocol (SDP) Grouping Framework", RFC 5888,
DOI 10.17487/RFC5888, June 2010, DOI 10.17487/RFC5888, June 2010, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc5888>. 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, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP [RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP
Header Extension for the RTP Control Protocol (RTCP) Header Extension for the RTP Control Protocol (RTCP)
Source Description Items", RFC 7941, DOI 10.17487/RFC7941, Source Description Items", RFC 7941, DOI 10.17487/RFC7941,
August 2016, <https://www.rfc-editor.org/info/rfc7941>. August 2016, <https://www.rfc-editor.org/info/rfc7941>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General
Mechanism for RTP Header Extensions", RFC 8285, Mechanism for RTP Header Extensions", RFC 8285,
DOI 10.17487/RFC8285, October 2017, DOI 10.17487/RFC8285, October 2017, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc8285>. editor.org/info/rfc8285>.
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive [I-D.ietf-ice-rfc5245bis]
Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445, Address Translator (NAT) Traversal", draft-ietf-ice-
DOI 10.17487/RFC8445, July 2018, rfc5245bis-20 (work in progress), March 2018.
<https://www.rfc-editor.org/info/rfc8445>.
[I-D.ietf-mmusic-sdp-mux-attributes] [I-D.ietf-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-17 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16
(work in progress), February 2018. (work in progress), December 2016.
[I-D.ietf-mmusic-mux-exclusive] [I-D.ietf-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-12 (work in progress), May 2017. exclusive-12 (work in progress), May 2017.
[I-D.ietf-mmusic-ice-sip-sdp] [I-D.ietf-mmusic-ice-sip-sdp]
Petit-Huguenin, M., Nandakumar, S., and A. Keranen, Petit-Huguenin, M., Nandakumar, S., and A. Keranen,
"Session Description Protocol (SDP) Offer/Answer "Session Description Protocol (SDP) Offer/Answer
procedures for Interactive Connectivity Establishment procedures for Interactive Connectivity Establishment
(ICE)", draft-ietf-mmusic-ice-sip-sdp-21 (work in (ICE)", draft-ietf-mmusic-ice-sip-sdp-20 (work in
progress), June 2018. progress), April 2018.
[I-D.ietf-mmusic-trickle-ice-sip] [I-D.ietf-mmusic-trickle-ice-sip]
Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A
Session Initiation Protocol (SIP) Usage for Incremental Session Initiation Protocol (SIP) Usage for Trickle ICE",
Provisioning of Candidates for the Interactive draft-ietf-mmusic-trickle-ice-sip-14 (work in progress),
Connectivity Establishment (Trickle ICE)", draft-ietf- February 2018.
mmusic-trickle-ice-sip-18 (work in progress), June 2018.
20.2. Informative References 21.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, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc3261>. editor.org/info/rfc3261>.
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
"RTP Control Protocol Extended Reports (RTCP XR)", "RTP Control Protocol Extended Reports (RTCP XR)",
RFC 3611, DOI 10.17487/RFC3611, November 2003, RFC 3611, DOI 10.17487/RFC3611, November 2003,
<https://www.rfc-editor.org/info/rfc3611>. <https://www.rfc-editor.org/info/rfc3611>.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile "Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104,
February 2008, <https://www.rfc-editor.org/info/rfc5104>. February 2008, <https://www.rfc-editor.org/info/rfc5104>.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
DOI 10.17487/RFC4585, July 2006, DOI 10.17487/RFC4585, July 2006, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc4585>. editor.org/info/rfc4585>.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009,
<https://www.rfc-editor.org/info/rfc5576>. <https://www.rfc-editor.org/info/rfc5576>.
[RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple
Clock Rates in an RTP Session", RFC 7160, Clock Rates in an RTP Session", RFC 7160,
DOI 10.17487/RFC7160, April 2014, DOI 10.17487/RFC7160, April 2014, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc7160>. editor.org/info/rfc7160>.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
<https://www.rfc-editor.org/info/rfc7201>. <https://www.rfc-editor.org/info/rfc7201>.
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms
for Real-Time Transport Protocol (RTP) Sources", RFC 7656, for Real-Time Transport Protocol (RTP) Sources", RFC 7656,
DOI 10.17487/RFC7656, November 2015, DOI 10.17487/RFC7656, November 2015, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc7656>. editor.org/info/rfc7656>.
[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services
(Diffserv) and Real-Time Communication", RFC 7657, (Diffserv) and Real-Time Communication", RFC 7657,
DOI 10.17487/RFC7657, November 2015, DOI 10.17487/RFC7657, November 2015, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc7657>. editor.org/info/rfc7657>.
[I-D.ietf-ice-trickle] [I-D.ietf-ice-trickle]
Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre,
"Trickle ICE: Incremental Provisioning of Candidates for "Trickle ICE: Incremental Provisioning of Candidates for
the Interactive Connectivity Establishment (ICE) the Interactive Connectivity Establishment (ICE)
Protocol", draft-ietf-ice-trickle-21 (work in progress), Protocol", draft-ietf-ice-trickle-21 (work in progress),
April 2018. April 2018.
[I-D.ietf-avtext-lrr] [I-D.ietf-avtext-lrr]
Lennox, J., Hong, D., Uberti, J., Holmer, S., and M. Lennox, J., Hong, D., Uberti, J., Holmer, S., and M.
 End of changes. 63 change blocks. 
107 lines changed or deleted 129 lines changed or added

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