draft-ietf-mmusic-sdp-bundle-negotiation-48.txt   draft-ietf-mmusic-sdp-bundle-negotiation-49.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,7941 (if approved) H. Alvestrand
Intended status: Standards Track Google Intended status: Standards Track Google
Expires: August 4, 2018 C. Jennings Expires: September 4, 2018 C. Jennings
Cisco Cisco
January 31, 2018 March 3, 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-48.txt draft-ietf-mmusic-sdp-bundle-negotiation-49.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 allow assigning a zero port This specification updates RFC 3264, to allow assigning a zero port
value to a "m=" section without meaning that the media described by value to a "m=" section without meaning that the media described by
the "m=" section is disabled or rejected. the "m=" section is disabled or rejected.
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 van 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.
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 https://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 August 4, 2018. This Internet-Draft will expire on September 4, 2018.
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 (https://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 4, line 9 skipping to change at page 4, line 9
18.3. Example: Offerer Adds a Media Description to a BUNDLE 18.3. Example: Offerer Adds a Media Description to a BUNDLE
Group . . . . . . . . . . . . . . . . . . . . . . . . . 43 Group . . . . . . . . . . . . . . . . . . . . . . . . . 43
18.4. Example: Offerer Moves a Media Description Out of a 18.4. Example: Offerer Moves a Media Description Out of a
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 45 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 45
18.5. Example: Offerer Disables a Media Description Within a 18.5. Example: Offerer Disables a Media Description Within a
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 47 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 47
19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 48 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 48
20. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 49 20. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 49
21. References . . . . . . . . . . . . . . . . . . . . . . . . . 60 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 60
21.1. Normative References . . . . . . . . . . . . . . . . . . 60 21.1. Normative References . . . . . . . . . . . . . . . . . . 60
21.2. Informative References . . . . . . . . . . . . . . . . . 61 21.2. Informative References . . . . . . . . . . . . . . . . . 62
Appendix A. Design Considerations . . . . . . . . . . . . . . . 63 Appendix A. Design Considerations . . . . . . . . . . . . . . . 63
A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 63 A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 64
A.2. Usage of Port Number Value Zero . . . . . . . . . . . . . 65 A.2. Usage of Port Number Value Zero . . . . . . . . . . . . . 65
A.3. B2BUA And Proxy Interoperability . . . . . . . . . . . . 65 A.3. B2BUA And Proxy Interoperability . . . . . . . . . . . . 65
A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 66 A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 66
A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 66 A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 66
A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 66 A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 66
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67
1. Introduction 1. Introduction
When the SDP offer/answer mechanism [RFC3264] is used to negotiate When the SDP offer/answer mechanism [RFC3264] is used to negotiate
skipping to change at page 5, line 40 skipping to change at page 5, line 40
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 media flows described by a single independently. All RTP based media flows described by a single
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
unique address to each "m=" section within an offer and answer, unique address:port to each "m=" section within an offer and answer,
according to the procedures in [RFC4566] and [RFC3264]. according to the procedures in [RFC4566] and [RFC3264].
2. Terminology 2. Terminology
"m=" section: SDP bodies contain one or more media descriptions, "m=" section: SDP bodies contain one or more media descriptions,
referred to as "m=" sections. Each "m=" section is represented by an referred to as "m=" sections. Each "m=" section is represented by an
SDP "m=" line, and zero or more SDP attributes associated with the SDP "m=" line, and zero or more SDP attributes associated with the
"m=" line. A local address:port combination is assigned to each "m=" "m=" line. A local address:port combination is assigned to each "m="
section. section.
o 5-tuple: A collection of the following values: source address, o 5-tuple: A collection of the following values: source address,
source port, destination address, destination port, and transport- source port, destination address, destination port, and transport-
layer protocol. layer protocol.
o Unique address: An address:port combination that is assigned to o Unique address:port: An address:port combination that is assigned
only one "m=" section in an offer or answer. to only one "m=" section in an offer or answer.
o Offerer BUNDLE-tag: The first identification-tag in a given SDP o Offerer BUNDLE-tag: The first identification-tag in a given SDP
'group:BUNDLE' attribute identification-tag list in an offer. 'group:BUNDLE' attribute identification-tag list in an offer.
o Answerer BUNDLE-tag: The first identification-tag in a given SDP o Answerer BUNDLE-tag: The first identification-tag in a given SDP
'group:BUNDLE' attribute identification-tag list in an answer. 'group:BUNDLE' attribute identification-tag list in an answer.
o BUNDLE address:port: An address:port combination that an endpoint o BUNDLE address:port: An address:port combination that an endpoint
uses for sending and receiving bundled media. uses for sending and receiving bundled media.
skipping to change at page 10, line 27 skipping to change at page 10, line 27
only' attribute. Section 11 defines additional considerations for only' attribute. Section 11 defines additional considerations for
the usage of Interactive Connectivity Establishment (ICE) the usage of Interactive Connectivity Establishment (ICE)
[I-D.ietf-ice-rfc5245bis] mechanism. [I-D.ietf-ice-rfc5245bis] mechanism.
SDP offers and answers can contain multiple BUNDLE groups. The SDP 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.
8.1. Multiplex Category Considerations 8.1. Multiplex Category Considerations
When a BUNDLE group is initially negotiated, and a unique address is When a BUNDLE group is initially negotiated, and a unique
assigned to each bundled "m=" section (excluding any bundle-only "m=" address:port is assigned to each bundled "m=" section (excluding any
section) in the initial offer [Section 8.2], any IDENTICAL and bundle-only "m=" section) in the initial offer [Section 8.2], any
TRANSPORT mux category SDP attributes included in the BUNDLE group IDENTICAL and TRANSPORT mux category SDP attributes included in the
MUST explicitly be included in each bundled "m=a€œ section BUNDLE group MUST explicitly be included in each bundled
(excluding any bundle-only "m=" sections). "m=a€œ section (excluding any bundle-only "m=" sections).
When an offerer or answerer includes SDP attributes in bundled "m=" When an offerer or answerer includes SDP attributes in bundled "m="
sections within a BUNDLE group for which the offerer and answerer sections within a BUNDLE group for which the offerer and answerer
BUNDLE addresses:ports have been selected, IDENTICAL and TRANSPORT BUNDLE addresses:ports have been selected, IDENTICAL and TRANSPORT
mux category SDP attributes [I-D.ietf-mmusic-sdp-mux-attributes] are mux category SDP attributes [I-D.ietf-mmusic-sdp-mux-attributes] are
only included in the "m=" section indicated by the BUNDLE-tag in the only included in the "m=" section indicated by the BUNDLE-tag in the
offer or answer. The SDP attribute values are implicitly applied to offer or answer. The SDP attribute values are implicitly applied to
each bundled "m=" section (including any bundle-only "m=" section). each bundled "m=" section (including any bundle-only "m=" section).
The offerer and answerer MUST NOT include such SDP attributes in any The offerer and answerer MUST NOT include such SDP attributes in any
other bundled "m=" section. other bundled "m=" section.
skipping to change at page 11, line 10 skipping to change at page 11, line 10
only included in the "m=" sections indicated by the BUNDLE-tag. That only included in the "m=" sections indicated by the BUNDLE-tag. That
means that media-specific IDENTICAL and TRANSPORT mux category means that media-specific IDENTICAL and TRANSPORT mux category
attributes can be included in an "m=" section associated with another attributes can be included in an "m=" section associated with another
type of media. type of media.
8.2. Generating the Initial SDP Offer 8.2. Generating the Initial SDP Offer
When an offerer generates an initial offer, to negotiate a BUNDLE When an offerer generates an initial offer, to negotiate a BUNDLE
group, it MUST: group, it MUST:
o Assign a unique address to each "m=" section within the offer, o Assign a unique address:port to each "m=" section within the
following the procedures in [RFC3264], excluding any bundle-only offer, following the procedures in [RFC3264], excluding any
"m=" sections (see below); and bundle-only "m=" sections (see below); and
o Include an SDP 'group:BUNDLE' attribute in the offer; and o Include an SDP 'group:BUNDLE' attribute in the offer; and
o Place the identification-tag of each bundled "m=" section in the o Place the identification-tag of each bundled "m=" section in the
SDP 'group:BUNDLE' attribute identification-tag list; and SDP 'group:BUNDLE' attribute identification-tag list; and
o Indicate which unique address the offerer suggests as the offerer o Indicate which unique address:port the offerer suggests as the
BUNDLE address:port [Section 8.2.1]. offerer BUNDLE address:port [Section 8.2.1].
If the offerer wants to request that the answerer accepts a given If the offerer wants to request that the answerer accepts a given
bundled "m=" section only if the answerer keeps the "m=" section bundled "m=" section only if the answerer keeps the "m=" section
within the BUNDLE group, the offerer MUST: within the BUNDLE group, the offerer MUST:
o Include an SDP 'bundle-only' attribute [Section 8.2.1] in the "m=" o Include an SDP 'bundle-only' attribute [Section 8.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 an "m=" section, NOTE: If the offerer assigns a zero port value to an "m=" section,
but does not include an SDP 'bundle-only' attribute in the "m=" but does not include an SDP 'bundle-only' attribute in the "m="
section, it is an indication that the offerer wants to disable the section, it is an indication that the offerer wants to disable the
"m=" section [Section 8.5.4]. "m=" section [Section 8.5.4].
NOTE: If the offerer assigns unique addresses to multiple bundled NOTE: If the offerer assigns unique addresses:ports to multiple
"m=" sections, the offerer needs to be prepared to receive bundled bundled "m=" sections, the offerer needs to be prepared to receive
media on each unique address, until it receives the associated answer bundled media on each unique address:port, until it receives the
and finds out which address:port combination has been selected as the associated answer and finds out which address:port combination has
offerer BUNDLE-address. been selected as the offerer BUNDLE-address.
[Section 8.2.2] and [Section 18.1] show an example of an initial [Section 8.2.2] and [Section 18.1] show an example of an initial
offer. offer.
8.2.1. Suggesting the Offerer BUNDLE Address:Port 8.2.1. Suggesting the Offerer BUNDLE Address:Port
In the offer, the address:port combination assigned to the "m=" In the offer, the address:port combination assigned to the "m="
section indicated by the offerer BUNDLE-tag indicates the offerer section indicated by the offerer BUNDLE-tag indicates the offerer
BUNDLE address:port, i.e., the address:port combination that the BUNDLE address:port, i.e., the address:port combination that the
offerer suggests for sending and receiving bundled media. offerer suggests for sending and receiving bundled media.
The offerer BUNDLE-tag MUST NOT represent a bundle-only "m=" section. The offerer BUNDLE-tag MUST NOT represent a bundle-only "m=" section.
Hence, the offer MUST contain at least one bundled "m=" section with Hence, the offer MUST contain at least one bundled "m=" section with
a unique address (and a non-zero port value). a unique address:port (and a non-zero port value).
It is RECOMMENDED that the offerer assigns the suggested offerer It is RECOMMENDED that the offerer assigns the suggested offerer
BUNDLE address:port to a bundled "m=" section that the offerer BUNDLE address:port to a bundled "m=" section that the offerer
assumes it is unlikely that the answerer will reject, or move out of assumes it is unlikely that the answerer will reject, or move out of
the BUNDLE group. How such assumption is made is outside the scope the BUNDLE group. How such assumption is made is outside the scope
of this document. of this document.
8.2.2. Example: Initial SDP Offer 8.2.2. Example: Initial SDP Offer
The example shows an initial SDP offer. The offer includes two "m=" The example shows an initial SDP offer. The offer includes two "m="
skipping to change at page 15, line 31 skipping to change at page 15, line 31
If either criteria above is fulfilled, the answerer can not move the If either criteria above is fulfilled, the answerer can not move the
"m=" section out of the BUNDLE group in the answer. The answerer can "m=" section out of the BUNDLE group in the answer. The answerer can
either reject the whole offer, reject each bundled "m=" section either reject the whole offer, reject each bundled "m=" section
within the BUNDLE group [Section 8.3.4], or keep the "m=" section within the BUNDLE group [Section 8.3.4], or keep the "m=" section
within the BUNDLE group in the answer and later create an offer where within the BUNDLE group in the answer and later create an offer where
the "m=" section is moved out of the BUNDLE group [Section 8.5.3]. the "m=" section is moved out of the BUNDLE group [Section 8.5.3].
When the answerer generates an answer, in which it moves a bundled When the answerer generates an answer, in which it moves a bundled
"m=" section out of a BUNDLE group, the answerer: "m=" section out of a BUNDLE group, the answerer:
o MUST assign a unique address to the "m=" section; and o MUST assign a unique address:port to the "m=" section; 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.
An answerer MUST NOT move an "m=" section from one BUNDLE group to An answerer MUST NOT move an "m=" section from one BUNDLE group to
another within an answer. If the answerer wants to move an "m=" another within an answer. If the answerer wants to move an "m="
skipping to change at page 19, line 19 skipping to change at page 19, line 19
[Section 8.5.1]. [Section 8.5.1].
[Section 18.3] shows an example where an offerer sends an offer in [Section 18.3] shows an example where an offerer sends an offer in
order to add a bundled "m=" section to a BUNDLE group. order to add a bundled "m=" section to a BUNDLE group.
8.5.3. Moving a Media Description Out of a BUNDLE Group 8.5.3. Moving a Media Description Out of a BUNDLE Group
When an offerer generates an offer, in which it wants to move a When an offerer generates an offer, in which it wants to move a
bundled "m=" section out of a BUNDLE group, the offerer: bundled "m=" section out of a BUNDLE group, the offerer:
o MUST assign a unique address to the "m=" section; and o MUST assign a unique address:port to the "m=" section; 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.
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="
skipping to change at page 30, line 41 skipping to change at page 30, line 41
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 "m=" section within the transport, instead of per individual "m=" section within the
BUNDLE group. BUNDLE group.
o In an offer, if the offer assigns a unique address to one or more o In an offer, if the offer assigns a unique address:port to one or
bundled "m=" sections (excluding any bundle-only "m=" sections), more bundled "m=" sections (excluding any bundle-only "m="
the offerer MUST include ICE-related media-level attributes in sections), the offerer MUST include ICE-related media-level
each of those "m=" sections. If the offerer assigns an offerer attributes in each of those "m=" sections. If the offerer assigns
BUNDLE address:port (previously selected [Section 8.3.1] or newly an offerer BUNDLE address:port (previously selected
suggested [Section 8.5.1]) to a bundled "m=" section (the "m=" [Section 8.3.1] or newly suggested [Section 8.5.1]) to a bundled
section indicated by the offerer BUNDLE-tag), the offerer only "m=" section (the "m=" section indicated by the offerer BUNDLE-
includes ICE-related media-level SDP attributes in that "m=" tag), the offerer only includes ICE-related media-level SDP
section, following the procedures in Section 8.1. attributes in that "m=" section, following the procedures in
Section 8.1.
o In an answer, the answerer only includes ICE-related media-level o In an answer, the answerer only includes ICE-related media-level
SDP attributes in the bundled "m=" section to which the answerer SDP attributes in the bundled "m=" section to which the answerer
has assigned the answerer BUNDLE address:port (the "m=" section has assigned the answerer BUNDLE address:port (the "m=" section
indicated by the answerer BUNDLE-tag), following the procedures in indicated by the answerer BUNDLE-tag), following the procedures in
Section 8.1. Section 8.1.
Initially, before ICE has produced a candidate pair that will be used Initially, before ICE has produced a candidate pair that will be used
for media, there might be multiple transports established (if for media, there might be multiple transports established (if
multiple candidate pairs are tested). Once ICE has produced a multiple candidate pairs are tested). Once ICE has produced a
transport that will be used for media, that becomes the BUNDLE transport that will be used for media, that becomes the BUNDLE
transport. transport.
Support and usage of ICE mechanism together with the BUNDLE extension Support and usage of ICE mechanism together with the BUNDLE extension
is OPTIONAL, and the procedures in this section only apply when the is OPTIONAL, and the procedures in this section only apply when the
ICE mechanism is used. Note that applications might mandate usage of ICE mechanism is used. Note that applications might mandate usage of
the ICE mechanism even if the BUNDLE extension is not used. the ICE mechanism even if the BUNDLE extension is not used.
11.1. SDP Offer/Answer Procedures 11.1. SDP Offer/Answer Procedures
When an offerer assigns a unique address to one or more bundled "m=" When an offerer assigns a unique address:port to one or more bundled
sections (excluding any bundle-only "m=" section), the offerer MUST "m=" sections (excluding any bundle-only "m=" section), the offerer
include SDP 'candidate' attributes (and other applicable ICE-related MUST include SDP 'candidate' attributes (and other applicable ICE-
media-level SDP attributes), containing unique ICE properties related media-level SDP attributes), containing unique ICE properties
(candidates etc), in each of those "m=" sections, following the (candidates etc), in each of those "m=" sections, following the
procedures in [I-D.ietf-mmusic-ice-sip-sdp]. procedures in [I-D.ietf-mmusic-ice-sip-sdp].
When an offerer assigns a BUNDLE address:port (previously selected or When an offerer assigns a BUNDLE address:port (previously selected or
newly suggested) to a bundled "m=" section, (the "m=" section newly suggested) to a bundled "m=" section, (the "m=" section
indicated by the offerer BUNDLE-tag) the offerer MUST only include indicated by the offerer BUNDLE-tag) the offerer MUST only include
SDP 'candidate' attributes (and other applicable ICE-related media- SDP 'candidate' attributes (and other applicable ICE-related media-
level SDP attributes) in that "m=" section, following the procedures level SDP attributes) in that "m=" section, following the procedures
in Section 8.1. in Section 8.1.
skipping to change at page 39, line 5 skipping to change at page 39, line 5
16.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
17. 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
skipping to change at page 40, line 28 skipping to change at page 40, line 31
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.
18. Examples 18. Examples
18.1. Example: BUNDLE Address:Port Selection 18.1. Example: BUNDLE Address:Port Selection
The example below shows: The example below shows:
o An offer, in which the offerer assigns a unique address to each o An offer, in which the offerer assigns a unique address:port to
bundled "m=" section within the BUNDLE group. each bundled "m=" section within the BUNDLE group.
o An answer, in which the answerer selects the offerer BUNDLE o An answer, in which the answerer selects the offerer BUNDLE
address:port, and then selects its own BUNDLE address (the address:port, and then selects its own BUNDLE address (the
answerer BUNDLE address:port) and assigns it to the bundled "m=" answerer BUNDLE address:port) and assigns it to the bundled "m="
section indicated by the answerer BUNDLE-tag. section indicated by the answerer BUNDLE-tag.
SDP Offer (1) SDP Offer (1)
v=0 v=0
o=alice 2890844526 2890844526 IN IP6 2001:db8::3 o=alice 2890844526 2890844526 IN IP6 2001:db8::3
skipping to change at page 42, line 9 skipping to change at page 42, line 9
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
18.2. Example: BUNDLE Extension Rejected 18.2. Example: BUNDLE Extension Rejected
The example below shows: The example below shows:
o An offer, in which the offerer assigns a unique address to each o An offer, in which the offerer assigns a unique address:port to
bundled "m=" section within the BUNDLE group. each bundled "m=" section within the BUNDLE group.
o An answer, in which the answerer rejects the offered BUNDLE group, o An answer, in which the answerer rejects the offered BUNDLE group,
and assigns a unique address to each "m=" section (following and assigns a unique address:port to each "m=" section (following
normal RFC 3264 procedures). normal RFC 3264 procedures).
SDP Offer (1) SDP Offer (1)
v=0 v=0
o=alice 2890844526 2890844526 IN IP6 2001:db8::3 o=alice 2890844526 2890844526 IN IP6 2001:db8::3
s= s=
c=IN IP6 2001:db8::3 c=IN IP6 2001:db8::3
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
skipping to change at page 45, line 36 skipping to change at page 45, line 36
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
18.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 (the BUNDLE group has been created as part of a o A subsequent offer (the BUNDLE group has been created as part of a
previous offer/answer transaction), in which the offerer moves a previous offer/answer transaction), in which the offerer moves a
bundled "m=" section, indicated by the "zen" identification-tag, bundled "m=" section, indicated by the "zen" identification-tag,
out of a BUNDLE group, assigns a unique address to the moved "m=" out of a BUNDLE group, assigns a unique address:port to the moved
section, and assigns the previously selected offerer BUNDLE "m=" section, and assigns the previously selected offerer BUNDLE
address:port to another bundled "m=" section, indicated by the address:port to another bundled "m=" section, indicated by the
offerer BUNDLE-tag. To every other bundled "m=" section the offerer BUNDLE-tag. To every other bundled "m=" section the
offerer assigns a zero port value and includes an SDP 'bundle- offerer assigns a zero port value and includes an SDP 'bundle-
only' attribute. only' attribute.
o An answer, in which the answerer moves the "m=" section out of the o An answer, in which the answerer moves the "m=" section out of the
BUNDLE group, assigns a unique address to the moved "m=" section, BUNDLE group, assigns a unique address:port to the moved "m="
and assigns the answerer BUNDLE address:port to the bundled "m=" section, and assigns the answerer BUNDLE address:port to the
section indicated by the answerer BUNDLE-tag. To every other bundled "m=" section indicated by the answerer BUNDLE-tag. To
bundled "m=" section the answerer assigns a zero port value and every other bundled "m=" section the answerer assigns a zero port
includes an SDP 'bundle-only' attribute. value and includes an SDP 'bundle-only' attribute.
SDP Offer (1) SDP Offer (1)
v=0 v=0
o=alice 2890844526 2890844526 IN IP6 2001:db8::3 o=alice 2890844526 2890844526 IN IP6 2001:db8::3
s= s=
c=IN IP6 2001:db8::3 c=IN IP6 2001:db8::3
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97 m=audio 10000 RTP/AVP 0 8 97
skipping to change at page 49, line 21 skipping to change at page 49, line 21
Uberti, Taylor Brandstetter, Byron Campen and Eric Rescorla for Uberti, Taylor Brandstetter, Byron Campen and Eric Rescorla for
reading the text, and providing useful feedback. reading the text, and providing useful feedback.
Thanks to Bernard Aboba, Peter Thatcher, Justin Uberti, and Magnus Thanks to Bernard Aboba, Peter Thatcher, Justin Uberti, and Magnus
Westerlund for providing the text for the section on RTP/RTCP stream Westerlund for providing the text for the section on RTP/RTCP stream
association. association.
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 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.
20. 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-48
o Changes based on Sec-Dir review by Charlie Kaufman.
o - s/unique address/unique address:port
o Changes based on Gen-ART review by Linda Dunbar.
o Mux category for group:BUNDLE attribute added.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-47 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-47
o Changes based on AD review by Ben Campbell. o Changes based on AD review by Ben Campbell.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-46 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-46
o Pre-RFC5378 disclaimer removed put back. o Pre-RFC5378 disclaimer removed put back.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-45 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-45
skipping to change at page 61, line 28 skipping to change at page 61, line 39
[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-editor.org/info/rfc8285>. <https://www.rfc-editor.org/info/rfc8285>.
[I-D.ietf-ice-rfc5245bis] [I-D.ietf-ice-rfc5245bis]
Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 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", draft-ietf-ice- Address Translator (NAT) Traversal", draft-ietf-ice-
rfc5245bis-16 (work in progress), January 2018. rfc5245bis-18 (work in progress), February 2018.
[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-16 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17
(work in progress), December 2016. (work in progress), February 2018.
[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., Keranen, A., and S. Nandakumar, Petit-Huguenin, M., Keranen, A., and S. Nandakumar,
"Session Description Protocol (SDP) Offer/Answer "Session Description Protocol (SDP) Offer/Answer
procedures for Interactive Connectivity Establishment procedures for Interactive Connectivity Establishment
skipping to change at page 62, line 51 skipping to change at page 63, line 15
[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-editor.org/info/rfc7656>. <https://www.rfc-editor.org/info/rfc7656>.
[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-15 (work in progress), Protocol", draft-ietf-ice-trickle-17 (work in progress),
November 2017. February 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.
Flodman, "The Layer Refresh Request (LRR) RTCP Feedback Flodman, "The Layer Refresh Request (LRR) RTCP Feedback
Message", draft-ietf-avtext-lrr-07 (work in progress), Message", draft-ietf-avtext-lrr-07 (work in progress),
July 2017. July 2017.
Appendix A. Design Considerations Appendix A. Design Considerations
One of the main issues regarding the BUNDLE grouping extensions has One of the main issues regarding the BUNDLE grouping extensions has
 End of changes. 29 change blocks. 
62 lines changed or deleted 79 lines changed or added

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