draft-ietf-mmusic-sdp-bundle-negotiation-47.txt   draft-ietf-mmusic-sdp-bundle-negotiation-48.txt 
MMUSIC Working Group C. Holmberg MMUSIC Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 3264 (if approved) H. Alvestrand Updates: 3264,7941 (if approved) H. Alvestrand
Intended status: Standards Track Google Intended status: Standards Track Google
Expires: June 21, 2018 C. Jennings Expires: August 4, 2018 C. Jennings
Cisco Cisco
December 18, 2017 January 31, 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-47.txt draft-ietf-mmusic-sdp-bundle-negotiation-48.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.
To assist endpoints in negotiating the use of bundle this This specification updates RFC 3264, to allow assigning a zero port
specification defines a new SDP attribute, 'bundle-only', which can
be used to request that specific media is only used if bundled. The
specification also 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.
When Real-time Transport Protocol (RTP)-based media is used, there This specification defines a new RTP Control Protocol (RTCP) source
are multiple ways to correlate bundled RTP packets with the description (SDES) item and a new RTP header extension that van be
appropriate "m=" section. This specification defines a new RTP used to correlate bundled RTP/RTCP packets with their appropriate
Control Protocol (RTCP) source description (SDES) item and a new RTP "m=" section.
header extension that provides an additional way to do this
correlation by using them to carry a value that associates the RTP/
RTCP packets with a specific "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 June 21, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
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
skipping to change at page 2, line 42 skipping to change at page 2, line 36
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Applicability Statement . . . . . . . . . . . . . . . . . . . 7 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 7
5. SDP Grouping Framework BUNDLE Extension . . . . . . . . . . . 7 5. SDP Grouping Framework BUNDLE Extension . . . . . . . . . . . 7
6. SDP 'bundle-only' Attribute . . . . . . . . . . . . . . . . . 8 6. SDP 'bundle-only' Attribute . . . . . . . . . . . . . . . . . 8
7. SDP Information Considerations . . . . . . . . . . . . . . . 9 7. SDP Information Considerations . . . . . . . . . . . . . . . 9
7.1. Connection Data (c=) . . . . . . . . . . . . . . . . . . 9 7.1. Connection Data (c=) . . . . . . . . . . . . . . . . . . 9
7.2. Bandwidth (b=) . . . . . . . . . . . . . . . . . . . . . 9 7.2. Bandwidth (b=) . . . . . . . . . . . . . . . . . . . . . 9
8. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 9 8. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 9
8.1. Mux Category Considerations . . . . . . . . . . . . . . . 10 8.1. Multiplex Category Considerations . . . . . . . . . . . . 10
8.2. Generating the Initial SDP Offer . . . . . . . . . . . . 11 8.2. Generating the Initial SDP Offer . . . . . . . . . . . . 11
8.2.1. Suggesting the Offerer BUNDLE Address . . . . . . . . 12 8.2.1. Suggesting the Offerer BUNDLE Address:Port . . . . . 11
8.2.2. Example: Initial SDP Offer . . . . . . . . . . . . . 12 8.2.2. Example: Initial SDP Offer . . . . . . . . . . . . . 12
8.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 13 8.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 13
8.3.1. Answerer Selection of Offerer BUNDLE Address . . . . 14 8.3.1. Answerer Selection of Offerer BUNDLE Address:Port . . 14
8.3.2. Answerer Selection of Answerer BUNDLE Address . . . . 15 8.3.2. Answerer Selection of Answerer BUNDLE Address:Port . 14
8.3.3. Moving A Media Description Out Of A BUNDLE Group . . 15 8.3.3. Moving A Media Description Out Of A BUNDLE Group . . 15
8.3.4. Rejecting a Media Description in a BUNDLE Group . . . 16 8.3.4. Rejecting a Media Description in a BUNDLE Group . . . 15
8.3.5. Example: SDP Answer . . . . . . . . . . . . . . . . . 17 8.3.5. Example: SDP Answer . . . . . . . . . . . . . . . . . 16
8.4. Offerer Processing of the SDP Answer . . . . . . . . . . 17 8.4. Offerer Processing of the SDP Answer . . . . . . . . . . 17
8.5. Modifying the Session . . . . . . . . . . . . . . . . . . 18 8.5. Modifying the Session . . . . . . . . . . . . . . . . . . 17
8.5.1. Suggesting a New Offerer BUNDLE Address . . . . . . . 18 8.5.1. Suggesting a New Offerer BUNDLE Address:Port . . . . 18
8.5.2. Adding a Media Description to a BUNDLE group . . . . 18 8.5.2. Adding a Media Description to a BUNDLE group . . . . 18
8.5.3. Moving a Media Description Out of a BUNDLE Group . . 19 8.5.3. Moving a Media Description Out of a BUNDLE Group . . 19
8.5.4. Disabling a Media Description in a BUNDLE Group . . . 19 8.5.4. Disabling a Media Description in a BUNDLE Group . . . 19
9. Protocol Identification . . . . . . . . . . . . . . . . . . . 20 9. Protocol Identification . . . . . . . . . . . . . . . . . . . 20
9.1. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 20 9.1. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 20
10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 21 10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 21
10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 21 10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 21
10.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . 22 10.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . 21
10.2. Associating RTP/RTCP Streams with Correct SDP Media 10.2. Associating RTP/RTCP Streams with Correct SDP Media
Description . . . . . . . . . . . . . . . . . . . . . . 22 Description . . . . . . . . . . . . . . . . . . . . . . 22
10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 28 10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 27
10.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . 28 10.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . 28
11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 30 11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 30
11.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 31 11.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 31
12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 31 12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 32
13. RTP Header Extensions Consideration . . . . . . . . . . . . . 32 13. RTP Header Extensions Consideration . . . . . . . . . . . . . 32
14. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 32 14. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 33
14.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 33 14.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 33
14.2. New text replacing section 5.1 (2nd paragraph) of RFC 14.2. New text replacing section 5.1 (2nd paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 33
14.3. Original text of section 6 (4th paragraph) of RFC 3264 . 33 14.3. Original text of section 6 (4th paragraph) of RFC 3264 . 34
14.4. New text replacing section 6 (4th paragraph) of RFC 3264 34 14.4. New text replacing section 6 (4th paragraph) of RFC 3264 34
14.5. Original text of section 8.2 (2nd paragraph) of RFC 3264 34 14.5. Original text of section 8.4 (6th paragraph) of RFC 3264 34
14.6. New text replacing section 8.2 (2nd paragraph) of RFC 14.6. New text replacing section 8.4 (6th paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 34
14.7. Original text of section 8.4 (6th paragraph) of RFC 3264 34
14.8. New text replacing section 8.4 (6th paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 34
15. RTP/RTCP extensions for identification-tag transport . . . . 35 15. RTP/RTCP extensions for identification-tag transport . . . . 35
15.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 36 15.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 36
15.2. RTP SDES Header Extension For MID . . . . . . . . . . . 36 15.2. RTP SDES Header Extension For MID . . . . . . . . . . . 36
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
16.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 37 16.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 37
16.2. New RTP SDES Header Extension URI . . . . . . . . . . . 37 16.2. New RTP SDES Header Extension URI . . . . . . . . . . . 37
16.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 38 16.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 38
16.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 38 16.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 38
17. Security Considerations . . . . . . . . . . . . . . . . . . . 39 17. Security Considerations . . . . . . . . . . . . . . . . . . . 39
18. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 40 18. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 40
18.1. Example: Bundle Address Selection . . . . . . . . . . . 40 18.1. Example: BUNDLE Address:Port Selection . . . . . . . . . 40
18.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 42 18.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 42
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 . . . . . . . . . . . . . . . . . . . . . . . . . 59 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 60
21.1. Normative References . . . . . . . . . . . . . . . . . . 59 21.1. Normative References . . . . . . . . . . . . . . . . . . 60
21.2. Informative References . . . . . . . . . . . . . . . . . 61 21.2. Informative References . . . . . . . . . . . . . . . . . 61
Appendix A. Design Considerations . . . . . . . . . . . . . . . 63 Appendix A. Design Considerations . . . . . . . . . . . . . . . 63
A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 63 A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 63
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 multimedia communications are established, each transport When the SDP offer/answer mechanism [RFC3264] is used to negotiate
(5-tuple) reserved for an individual media stream consume additional the establishment of multimedia communication sessions, if separate
resources (especially when Interactive Connectivity Establishment transports (5-tuples) are negotiated for each individual media
(ICE) [I-D.ietf-ice-rfc5245bis] is used). For this reason, it is stream, each transport consumes additional resources (especially when
Interactive Connectivity Establishment (ICE)
[I-D.ietf-ice-rfc5245bis] is used). For this reason, it is
attractive to use a single transport for multiple media streams. attractive to use a single transport for multiple media streams.
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 same BUNDLE by multiple SDP media descriptions ("m=" sections). The same BUNDLE
transport is used for sending and receiving bundled media, which transport is used for sending and receiving bundled media, which
means that the symmetric Real-time Transport Protocol (RTP) mechanism means that the symmetric Real-time Transport Protocol (RTP) mechanism
[RFC4961] is always used for RTP-based bundled media. [RFC4961] is always used for RTP-based bundled media.
This specification defines a new SDP Grouping Framework [RFC5888] This specification defines a new SDP Grouping Framework [RFC5888]
extension called 'BUNDLE'. The extension can be used with the extension called 'BUNDLE'. The extension can be used with the
Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264] Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264]
to negotiate which "m=" sections will become part of a BUNDLE group. to negotiate which "m=" sections will become part of a BUNDLE group.
Within a BUNDLE group, each "m=" section will use a BUNDLE transport Within a BUNDLE group, each "m=" section will use a BUNDLE transport
for sending and receiving bundled media. for sending and receiving bundled media.
Within a BUNDLE group, each endpoint uses a single address:port Within a BUNDLE group, each endpoint uses a single address:port
combination for sending and receiving bundled media. The combination for sending and receiving bundled media. The
address:port combination is referred to as the BUNDLE address. In address:port combination is referred to as the BUNDLE address:port.
addition to negotiating the BUNDLE group, the offerer and answerer In addition to negotiating the BUNDLE group, the offerer and answerer
[RFC3264] use the BUNDLE extension to negotiate the BUNDLE addresses, [RFC3264] use the BUNDLE extension to negotiate the BUNDLE
one for the offerer (offerer BUNDLE address) and one for the answerer addresses:ports, one for the offerer (offerer BUNDLE address) and one
(answerer BUNDLE address). Once the offerer and the answerer have for the answerer (answerer BUNDLE address:port). Once the offerer
negotiated the BUNDLE addresses, and a BUNDLE group has been formed, and the answerer have negotiated the BUNDLE addresses:ports, and a
they assign their respective BUNDLE address to each "m=" section BUNDLE group has been formed, they assign their respective BUNDLE
within the BUNDLE group. The endpoints then use the BUNDLE addresses address:port to each "m=" section within the BUNDLE group. The
for sending and receiving the bundled media associated with the endpoints then use the BUNDLE addresses:ports for sending and
BUNDLE group. receiving the bundled media associated with the BUNDLE group.
The use of a BUNDLE transport also allows the usage of a single set The use of a BUNDLE transport allows the usage of a single set of
of Interactive Connectivity Establishment (ICE) Interactive Connectivity Establishment (ICE)
[I-D.ietf-ice-rfc5245bis] candidates for the whole BUNDLE group. [I-D.ietf-ice-rfc5245bis] candidates for the whole BUNDLE group.
This specification also defines a new SDP attribute, 'bundle-only', This specification defines a new SDP attribute, 'bundle-only', which
which can be used to request that specific media is only used if the can be used to request that specific media is only used if the "m="
"m=" section describing the media is kept within a BUNDLE group. The section describing the media is kept within a BUNDLE group.
specification also updates RFC 3264, to allow usage of zero port
values without meaning that media is rejected. This specification updates RFC 3264 [RFC3264], to allow assigning a
zero port value to a "m=" section without meaning that the media
described by the "m=" section is disabled or rejected.
As defined in RFC 4566 [RFC4566], the semantics of assigning the same As defined in RFC 4566 [RFC4566], the semantics of assigning the same
transport address (IP address and port) to multiple "m=" sections are transport address (IP address and port) to multiple "m=" sections are
undefined, and there is no grouping defined by such means. Instead, undefined, and there is no grouping defined by such means. Instead,
an explicit grouping mechanism needs to be used to express the an explicit grouping mechanism needs to be used to express the
intended semantics. This specification provides such an extension. intended semantics. This specification provides such an extension.
This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264 This specification defines a new RTP Control Protocol (RTCP)
[RFC3264]. The update allows an answerer to assign a non-zero port
value to an "m=" section in an SDP answer, even if the "m=" section
in the associated SDP offer contained a zero port value.
This specification also defines a new RTP Control Protocol (RTCP)
[RFC3550] source description (SDES) item, 'MID', and a new RTP SDES [RFC3550] source description (SDES) item, 'MID', and a new RTP SDES
header extension that can be used to associate RTP streams with "m=" header extension that can be used to associate RTP streams with "m="
sections. sections.
SDP bodies can contain multiple BUNDLE groups. A given BUNDLE A given BUNDLE address:port MUST only be associated with a single
address MUST only be associated with a single BUNDLE group. The BUNDLE group. If an SDP offer or answer contains multiple BUNDLE
procedures in this specification apply independently to a given groups, the procedures in this specification apply to each group
BUNDLE group. All RTP based media flows described by a single BUNDLE independently. All RTP based media flows described by a single
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 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.
5-tuple: A collection of the following values: source address, source o 5-tuple: A collection of the following values: source address,
port, destination address, destination port, and transport-layer source port, destination address, destination port, and transport-
protocol. layer protocol.
Unique address: An address:port combination that is assigned to only o Unique address: An address:port combination that is assigned to
one "m=" section in an offer or answer. only one "m=" section in an offer or answer.
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.
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.
BUNDLE address: An address:port combination that an endpoint uses for o BUNDLE address:port: An address:port combination that an endpoint
sending and receiving bundled media. uses for sending and receiving bundled media.
Offerer BUNDLE address: the address:port combination used by the o Offerer BUNDLE address:port: the address:port combination used by
offerer for sending and receiving media. the offerer for sending and receiving media.
Suggested Offerer BUNDLE address: before an offerer BUNDLE address o Suggested Offerer BUNDLE address:port: before an offerer BUNDLE
has been selected by the answerer, or when the offerer wants to address:port has been selected by the answerer, or when the
change a previously selected offerer BUNDLE address, the address:port offerer wants to change a previously selected offerer BUNDLE
combination that the offerer wants to use for sending and receiving address:port, the address:port combination that the offerer wants
media. While suggested by the offerer, the selection of the offerer to use for sending and receiving media. While suggested by the
BUNDLE address is done by the answerer. offerer, the selection of the offerer BUNDLE address:port is done
by the answerer.
Answerer BUNDLE address: the address:port combination used by the o Answerer BUNDLE address:port: the address:port combination used by
answerer for sending and receiving media. the answerer for sending and receiving media.
BUNDLE transport: The transport (5-tuple) used by all media described o BUNDLE transport: The transport (5-tuple) used by all media
by the "m=" sections within a BUNDLE group. described by the "m=" sections within a BUNDLE group.
BUNDLE group: A set of "m=" sections, created using an SDP Offer/ o BUNDLE group: A set of "m=" sections, created using an SDP Offer/
Answer exchange, which uses a single BUNDLE transport for sending and Answer exchange, which uses a single BUNDLE transport for sending
receiving all media (bundled media) described by the set of "m=" and receiving all media (bundled media) described by the set of
sections. The same BUNDLE transport is used for sending and "m=" sections. The same BUNDLE transport is used for sending and
receiving bundled media. receiving bundled media.
Bundled "m=" section: An "m=" section, whose identification-tag is o Bundled "m=" section: An "m=" section, whose identification-tag is
placed in an SDP 'group:BUNDLE' attribute identification-tag list in placed in an SDP 'group:BUNDLE' attribute identification-tag list
an offer or answer. in an offer or answer.
Bundle-only "m=" section: A bundled "m=" section that contains an SDP o Bundle-only "m=" section: A bundled "m=" section that contains an
'bundle-only' attribute. SDP 'bundle-only' attribute.
Bundled media: All media associated with a given BUNDLE group. o Bundled media: All media associated with a given BUNDLE group.
Initial offer: The first offer, within an SDP session (e.g. a SIP o Initial offer: The first offer, within an SDP session (e.g. a SIP
dialog when the Session Initiation Protocol (SIP) [RFC3261] is used dialog when the Session Initiation Protocol (SIP) [RFC3261] is
to carry SDP), in which the offerer indicates that it wants to create used to carry SDP), in which the offerer indicates that it wants
a given BUNDLE group. to create a given BUNDLE group.
Subsequent offer: An offer which contains a BUNDLE group that has o Subsequent offer: An offer which contains a BUNDLE group that has
been created as part of a previous offer/answer exchange. been created as part of a previous offer/answer exchange.
Identification-tag: A unique token value that is used to identify an o Identification-tag: A unique token value that is used to identify
"m=" section. The SDP 'mid' attribute [RFC5888] in an "m=" section an "m=" section. The SDP 'mid' attribute [RFC5888] in an "m="
carries the unique identification-tag assigned to that "m=" section. section carries the unique identification-tag assigned to that
The session-level SDP 'group' attribute [RFC5888] carries a list of "m=" section. The session-level SDP 'group' attribute [RFC5888]
identification-tags, identifying the "m=" sections associated with carries a list of identification-tags, identifying the "m="
that particular 'group' attribute. sections associated with that particular 'group' attribute.
3. Conventions 3. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. [RFC2119].
4. Applicability Statement 4. Applicability Statement
skipping to change at page 7, line 49 skipping to change at page 7, line 40
Description Protocol (SDP) [RFC4566], when used together with the SDP Description Protocol (SDP) [RFC4566], when used together with the SDP
offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of
scope of this document, and is thus undefined. scope of this document, and is thus undefined.
5. SDP Grouping Framework BUNDLE Extension 5. SDP Grouping Framework BUNDLE Extension
This section defines a new SDP Grouping Framework [RFC5888] This section defines a new SDP Grouping Framework [RFC5888]
extension, 'BUNDLE'. The BUNDLE extension can be used with the SDP extension, 'BUNDLE'. The BUNDLE extension can be used with the SDP
Offer/Answer mechanism to negotiate a set of "m=" sections that will Offer/Answer mechanism to negotiate a set of "m=" sections that will
become part of a BUNDLE group. Within a BUNDLE group, each "m=" become part of a BUNDLE group. Within a BUNDLE group, each "m="
section will use a BUNDLE transport for sending and receiving bundled section uses a BUNDLE transport for sending and receiving bundled
media. Each endpoint uses a single address:port combination for media. Each endpoint uses a single address:port combination for
sending and receiving the bundled media. sending and receiving the bundled media.
The BUNDLE extension is indicated using an SDP 'group' attribute with The BUNDLE extension is indicated using an SDP 'group' attribute with
a "BUNDLE" semantics value [RFC5888]. An identification-tag is a semantics value [RFC5888] of "BUNDLE". An identification-tag is
assigned to each bundled "m=" section, and each identification-tag is assigned to each bundled "m=" section, and each identification-tag is
listed in the SDP 'group:BUNDLE' attribute identification-tag list. listed in the SDP 'group:BUNDLE' attribute identification-tag list.
Each "m=" section whose identification-tag is listed in the Each "m=" section whose identification-tag is listed in the
identification-tag list is associated with a given BUNDLE group. identification-tag list is associated with a given BUNDLE group.
SDP bodies can contain multiple BUNDLE groups. Any given bundled SDP bodies can contain multiple BUNDLE groups. Any given bundled
"m=" section MUST NOT be associated with more than one BUNDLE group "m=" section MUST NOT be associated with more than one BUNDLE group
at any given time. at any given time.
NOTE: The order of the "m=" sections listed in the SDP 'group:BUNDLE' NOTE: The order of the "m=" sections listed in the SDP 'group:BUNDLE'
skipping to change at page 9, line 7 skipping to change at page 8, line 46
In order to ensure that an answerer that does not support the BUNDLE In order to ensure that an answerer that does not support the BUNDLE
extension always rejects a bundled "m=" section, the offerer can extension always rejects a bundled "m=" section, the offerer can
assign a zero port value to the "m=" section. According to [RFC3264] assign a zero port value to the "m=" section. According to [RFC3264]
an answerer will reject such an "m=" section. By including an SDP an answerer will reject such an "m=" section. By including an SDP
'bundle-only' attribute in such an "m=" section, the offerer can 'bundle-only' attribute in such an "m=" section, the offerer can
request that the answerer accepts the "m=" section if the answerer request that the answerer accepts the "m=" section if the answerer
supports the BUNDLE extension, and if the answerer keeps the "m=" supports the BUNDLE extension, and if the answerer keeps the "m="
section within the associated BUNDLE group. section within the associated BUNDLE group.
Once the offerer and answerer BUNDLE addresses have been selected, an Once the offerer and answerer BUNDLE addresses:ports have been
offerer and answerer only assign the BUNDLE address to one bundled selected, an offerer and answerer only assign the BUNDLE address:port
"m=" section. The offerer and answerer assign a zero port value and to one bundled "m=" section. The offerer and answerer assign a zero
includes an SDP 'bundle-only' attribute to every other bundled "m=" port value and includes an SDP 'bundle-only' attribute to every other
section. bundled "m=" section.
The usage of the 'bundle-only' attribute is only defined for a The usage of the 'bundle-only' attribute is only defined for a
bundled "m=" section with a zero port value. Other usage is bundled "m=" section with a zero port value. Other usage is
unspecified. unspecified.
Section 8 defines the detailed SDP Offer/Answer procedures for the Section 8 defines the detailed SDP Offer/Answer procedures for the
'bundle-only' attribute. 'bundle-only' attribute.
7. SDP Information Considerations 7. SDP Information Considerations
skipping to change at page 10, line 4 skipping to change at page 9, line 43
An offerer and answerer MUST use the rules and restrictions defined An offerer and answerer MUST use the rules and restrictions defined
in [I-D.ietf-mmusic-sdp-mux-attributes] for associating the SDP in [I-D.ietf-mmusic-sdp-mux-attributes] for associating the SDP
bandwidth (b=) line with bundled "m=" sections. bandwidth (b=) line with bundled "m=" sections.
8. SDP Offer/Answer Procedures 8. SDP Offer/Answer Procedures
This section describes the SDP Offer/Answer [RFC3264] procedures for: This section describes the SDP Offer/Answer [RFC3264] procedures for:
o Negotiating a BUNDLE group; and o Negotiating a BUNDLE group; and
o Selecting the BUNDLE addresses (offerer BUNDLE address and
answerer BUNDLE address); and o Selecting the BUNDLE addresses:ports (offerer BUNDLE address:port
and answerer BUNDLE address:port); and
o Adding an "m=" section to a BUNDLE group; and o Adding an "m=" section to a BUNDLE group; and
o Moving an "m=" section out of a BUNDLE group; and o Moving an "m=" section out of a BUNDLE group; and
o Disabling an "m=" section within a BUNDLE group. o Disabling an "m=" section within a BUNDLE group.
The generic rules and procedures defined in [RFC3264] and [RFC5888] The generic rules and procedures defined in [RFC3264] and [RFC5888]
also apply to the BUNDLE extension. For example, if an offer is also apply to the BUNDLE extension. For example, if an offer is
rejected by the answerer, the previously negotiated SDP parameters rejected by the answerer, the previously negotiated SDP parameters
skipping to change at page 10, line 33 skipping to change at page 10, line 25
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 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. Mux 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 address is
assigned to each bundled "m=" section (excluding any bundle-only "m=" assigned to each bundled "m=" section (excluding any bundle-only "m="
section) in the initial offer [Section 8.2], IDENTICAL and TRANSPORT section) in the initial offer [Section 8.2], any IDENTICAL and
mux category SDP attributes MUST explicitly be included in each TRANSPORT mux category SDP attributes included in the BUNDLE group
bundled "m=" section (excluding any bundle-only "m=" sections). MUST explicitly be included in each bundled "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 have been selected, IDENTICAL and TRANSPORT mux BUNDLE addresses:ports have been selected, IDENTICAL and TRANSPORT
category SDP attributes [I-D.ietf-mmusic-sdp-mux-attributes] are only mux category SDP attributes [I-D.ietf-mmusic-sdp-mux-attributes] are
included in the "m=" section represented 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.
The semantics of some SDP attributes only apply to specific types of The semantics of some SDP attributes only apply to specific types of
media. For example, the semantics of the SDP 'rtcp-mux' and SDP media. For example, the semantics of the SDP 'rtcp-mux' and SDP
'rtcp-mux-only' attributes only apply to "m=" sections describing 'rtcp-mux-only' attributes only apply to "m=" sections describing
RTP-based media. However, as described in Section 8.1, there are RTP-based media. However, as described in Section 8.1, there are
cases where IDENTICAL and TRANSPORT mux category SDP attributes are cases where IDENTICAL and TRANSPORT mux category SDP attributes are
only included in the "m=" sections represented by the BUNDLE-tag. only included in the "m=" sections indicated by the BUNDLE-tag. That
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 to each "m=" section within the offer,
following the procedures in [RFC3264], excluding any bundle-only following the procedures in [RFC3264], excluding any bundle-only
"m=" sections (see below); and "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 the offerer suggests as the offerer
BUNDLE address [Section 8.2.1]. 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="
secction; 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 to multiple bundled
"m=" sections, the offerer needs to be prepared to receive bundled "m=" sections, the offerer needs to be prepared to receive bundled
media on each unique address, until it receives the associated answer media on each unique address, until it receives the associated answer
and finds out which address:port combination has been selected as the and finds out which address:port combination has been selected as the
offerer BUNDLE-address. 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 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 represented by the offerer BUNDLE-tag indicates the offerer section indicated by the offerer BUNDLE-tag indicates the offerer
BUNDLE address, i.e., the address:port combination that the offerer BUNDLE address:port, i.e., the address:port combination that the
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 (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 to a bundled "m=" section that the offerer assumes it BUNDLE address:port to a bundled "m=" section that the offerer
is unlikely that the answerer will reject, or move out of the BUNDLE assumes it is unlikely that the answerer will reject, or move out of
group. How such assumption is made is outside the scope of this the BUNDLE group. How such assumption is made is outside the scope
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="
sections in the SDP, and suggests that both are included in a BUNDLE sections in the SDP, and suggests that both are included in a BUNDLE
group. The audio "m=" section is represented by the offerer BUNDLE- group. The audio "m=" section is indicated by the offerer BUNDLE-tag
tag (placed first in the SDP group:BUNDLE attribute identification-id (placed first in the SDP group:BUNDLE attribute identification-id
list). list).
SDP Offer SDP Offer
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com o=alice 2890844526 2890844526 IN IP6 2001:db8::3
s= s=
c=IN IP4 atlanta.example.com 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
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
a=rtcp-mux a=rtcp-mux
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
skipping to change at page 13, line 48 skipping to change at page 13, line 24
o The answerer MUST NOT include an "m=" section within a BUNDLE o The answerer MUST NOT include an "m=" section within a BUNDLE
group, unless the offerer requested the "m=" section to be within group, unless the offerer requested the "m=" section to be within
that BUNDLE group in the corresponding offer. that BUNDLE group in the corresponding offer.
o If the answer contains multiple BUNDLE groups, the answerer MUST o If the answer contains multiple BUNDLE groups, the answerer MUST
NOT move an "m=" section from one BUNDLE group to another. NOT move an "m=" section from one BUNDLE group to another.
If the answer contains a BUNDLE group, the answerer MUST: If the answer contains a BUNDLE group, the answerer MUST:
o Select an offerer BUNDLE Address [Section 8.3.1]; and o Select an offerer BUNDLE address:port [Section 8.3.1]; and
o Select an answerer BUNDLE Address [Section 8.3.2]. o Select an answerer BUNDLE address:port [Section 8.3.2].
The answerer is allowed to select a new answerer BUNDLE address each The answerer is allowed to select a new answerer BUNDLE address:port
time it generates an answer to an offer. each time it generates an answer to an offer.
If the answerer does not want to keep an "m=" section within a BUNDLE If the answerer does not want to keep an "m=" section within a BUNDLE
group, it MUST: group, it MUST:
o Move the "m=" section out of the BUNDLE group [Section 8.3.3]; or o Move the "m=" section out of the BUNDLE group [Section 8.3.3]; or
o Reject the "m=" section [Section 8.3.4]. o Reject the "m=" section [Section 8.3.4].
When the answerer creates the answer, it selects the offerer BUNDLE When the answerer creates the answer, it selects the offerer BUNDLE
address [Section 8.3.1] and the answerer BUNDLE address address:port [Section 8.3.1] and the answerer BUNDLE address:port
[Section 8.3.2]. The answerer then assigns the answerer BUNDLE [Section 8.3.2]. The answerer then assigns the answerer BUNDLE
address to the bundled "m=" section represented by the answerer address:port to the bundled "m=" section indicated by the answerer
BUNDLE-tag. In every other bundled "m=" section the answerer BUNDLE-tag. In every other bundled "m=" section the answerer
includes an SDP 'bundle-only' attribute and assigns a zero port value includes an SDP 'bundle-only' attribute and assigns a zero port value
to the "m=" section. to the "m=" section.
If the answerer does not want to keep a bundle-only "m=" section If the answerer does not want to keep a bundle-only "m=" section
within the BUNDLE group, it MUST reject the "m=" section within the BUNDLE group, it MUST reject the "m=" section
[Section 8.3.4]. [Section 8.3.4].
NOTE: If a bundled "m=" section in an offer contains a zero port NOTE: If a bundled "m=" section in an offer contains a zero port
value, but the "m=" section does not contain an SDP 'bundle-only' value, but the "m=" section does not contain an SDP 'bundle-only'
attribute, it is an indication that the offerer wants to disable the attribute, it is an indication that the offerer wants to disable the
"m=" section [Section 8.5.4]. "m=" section [Section 8.5.4].
8.3.1. Answerer Selection of Offerer BUNDLE Address 8.3.1. Answerer Selection of Offerer BUNDLE Address:Port
In an offer, the bundled "m=" section represented by the offerer In an offer, the bundled "m=" section indicated by the offerer
BUNDLE-tag contains the suggested offerer BUNDLE address, i.e, the BUNDLE-tag contains the suggested offerer BUNDLE address:port, i.e,
address:port combination that the offerer wants to use for sending the address:port combination that the offerer wants to use for
and receiving bundled media [Section 8.2.1]. The answerer MUST check sending and receiving bundled media [Section 8.2.1]. The answerer
whether that "m=" section fulfils the following criteria: MUST check whether that "m=" section fulfils the following criteria:
o The answerer will not move the "m=" section out of the BUNDLE o The answerer will not move the "m=" section out of the BUNDLE
group [Section 8.3.3]; and group [Section 8.3.3]; and
o The answerer will not reject the "m=" section [Section 8.3.4]; and o The answerer will not reject the "m=" section [Section 8.3.4]; and
o The "m=" section does not contain a zero port value. o The "m=" section does not contain a zero port value.
If all of the criteria above are fulfilled, the answerer MUST select If all of the criteria above are fulfilled, the answerer MUST select
the suggested offerer BUNDLE address. the suggested offerer BUNDLE address:port.
If one or more of the criteria are not fulfilled, the answerer MUST If one or more of the criteria are not fulfilled, the answerer MUST
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
represented 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 8.3.3] or rejecting an "m=" section out of a BUNDLE group [Section 8.3.3] or rejecting an
"m=" section within a BUNDLE group [Section 8.3.4] to every bundled "m=" section within a BUNDLE group [Section 8.3.4] to every bundled
"m=" section in the offer when creating the answer. "m=" section in the offer when creating the answer.
[Section 18.1] shows an example of an offerer BUNDLE address [Section 18.1] shows an example of an offerer BUNDLE address:port
selection. selection.
8.3.2. Answerer Selection of Answerer BUNDLE Address 8.3.2. Answerer Selection of Answerer BUNDLE Address:Port
When the answerer selects a BUNDLE address for itself (answerer When the answerer selects a BUNDLE address:port for itself (answerer
BUNDLE address), the answerer MUST assign the answerer BUNDLE address BUNDLE address:port), the answerer MUST assign the answerer BUNDLE
to the "m=" section that contains the selected offerer BUNDLE address address:port to the "m=" section that contains the selected offerer
in the corresponding offer. The answerer BUNDLE-tag represents that BUNDLE address:port in the corresponding offer. The answerer BUNDLE-
"m=" section in the answer. To every other bundled "m=" section the tag represents that "m=" section in the answer. To every other
answerer MUST assign a zero port value and include an SDP 'bundle- bundled "m=" section the answerer MUST assign a zero port value and
only' attribute. include an SDP 'bundle-only' attribute.
The answerer MUST NOT assign an answerer BUNDLE address to an "m=" The answerer MUST NOT assign an answerer BUNDLE address:port to an
section that is not within the BUNDLE group, or to an "m=" section "m=" section that is not within the BUNDLE group, or to an "m="
that is within another BUNDLE group. section that is within another BUNDLE group.
[Section 8.3.5] and [Section 18.1] show an example of an answerer [Section 8.3.5] and [Section 18.1] show an example of an answerer
BUNDLE address selection. BUNDLE address:port selection.
8.3.3. Moving A Media Description Out Of A BUNDLE Group 8.3.3. Moving A Media Description Out Of A BUNDLE Group
When an answerer wants to move a bundled "m=" section out of a BUNDLE When an answerer wants to move a bundled "m=" section out of a BUNDLE
group in an answer, it MUST first check the following criteria: group in an answer, it MUST first check the following criteria:
o In the corresponding offer, an offerer BUNDLE address (previously o In the corresponding offer, an offerer BUNDLE address:port
selected [Section 8.3.1] or new suggested [Section 8.5.1]) has (previously selected [Section 8.3.1] or newly suggested
been assigned to the "m=" section by the offerer; or [Section 8.5.1]) has been assigned to the "m=" section by the
offerer; or
o In the corresponding offer, the "m=" section contains an SDP o In the corresponding offer, the "m=" section contains an SDP
'bundle-only' attribute and a zero port value. 'bundle-only' attribute and a zero port value.
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].
skipping to change at page 16, line 29 skipping to change at page 16, line 5
section from one BUNDLE group to another it MUST first move the "m=" section from one BUNDLE group to another it MUST first move the "m="
section out of the current BUNDLE group, and then generate an offer section out of the current BUNDLE group, and then generate an offer
where the "m=" section is added to another BUNDLE group where the "m=" section is added to another BUNDLE group
[Section 8.5.2]. [Section 8.5.2].
8.3.4. Rejecting a Media Description in a BUNDLE Group 8.3.4. Rejecting a Media Description in a BUNDLE Group
When an answerer wants to reject a bundled "m=" section in an answer, When an answerer wants to reject a bundled "m=" section in an answer,
it MUST first check the following criteria: it MUST first check the following criteria:
o In the corresponding offer, an offerer BUNDLE address (previously o In the corresponding offer, an offerer BUNDLE address:port
selected [Section 8.3.1] or new suggested [Section 8.5.1]) has (previously selected [Section 8.3.1] or newly suggested
been assigned to the "m=" section by the offerer. [Section 8.5.1]) has been assigned to the "m=" section by the
offerer.
If the criteria above is fulfilled, the answerer can not reject the If the criteria above is fulfilled, the answerer can not reject the
"m=" section in the answer (unless the answerer rejects each bundled "m=" section in the answer (unless the answerer rejects each bundled
"m=" section within the BUNDLE group). The answerer can either "m=" section within the BUNDLE group). The answerer can either
reject the whole offer, reject each bundled "m=" section within the reject the whole offer, reject each bundled "m=" section within the
BUNDLE group, or keep the "m=" section within the BUNDLE group in the BUNDLE group, or keep the "m=" section within the BUNDLE group in the
answer and later create an offer where the "m=" section is disabled answer and later create an offer where the "m=" section is disabled
within the BUNDLE group [Section 8.5.4]. within the BUNDLE group [Section 8.5.4].
When an answerer generates an answer, in which it rejects a bundled When an answerer generates an answer, in which it rejects a bundled
skipping to change at page 17, line 9 skipping to change at page 16, line 35
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.
8.3.5. Example: SDP Answer 8.3.5. Example: SDP Answer
The example below shows an SDP answer, based on the SDP offer in The example below shows an SDP answer, based on the SDP offer in
[Section 8.2.2]. The answerer accepts both "m=" sections within the [Section 8.2.2]. The answerer accepts both "m=" sections within the
BUNDLE group. The answerer assigns the answerer BUNDLE address to BUNDLE group. The answerer assigns the answerer BUNDLE address:port
the "m=" section represented by the answerer BUNDLE-tag. The to the "m=" section indicated by the answerer BUNDLE-tag. The
answerer assigns a zero port value and an SDP 'bundle-only' attribute answerer assigns a zero port value and an SDP 'bundle-only' attribute
to the other bundled "m=" section. to the other bundled "m=" section.
SDP Answer SDP Answer
v=0 v=0
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com o=bob 2808844564 2808844564 IN IP6 2001:db8::3
s= s=
c=IN IP4 biloxi.example.com c=IN IP6 2001:db8::3
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
a=rtcp-mux a=rtcp-mux
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
8.4. Offerer Processing of the SDP Answer 8.4. Offerer Processing of the SDP Answer
When an offerer receives an answer, if the answer contains a BUNDLE When an offerer receives an answer, if the answer contains a BUNDLE
group, the offerer MUST check that any bundled "m=" section in the group, the offerer MUST check that any bundled "m=" section in the
answer was indicated as bundled in the corresponding offer. If there answer was indicated as bundled in the corresponding offer. If there
is no mismatch, the offerer MUST use the offerer BUNDLE address, is no mismatch, the offerer MUST use the offerer BUNDLE address:port,
selected by the answerer [Section 8.3.1], as the address for each selected by the answerer [Section 8.3.1], as the address for each
bundled "m=" section. bundled "m=" section.
NOTE: As the answerer might reject one or more bundled "m=" sections, NOTE: As the answerer might reject one or more bundled "m=" sections,
or move a bundled "m=" section out of a BUNDLE group, each bundled or move a bundled "m=" section out of a BUNDLE group, each bundled
"m=" section in the offer might not be indicated as bundled in the "m=" section in the offer might not be indicated as bundled in the
answer. answer.
If the answer does not contain a BUNDLE group, the offerer MUST If the answer does not contain a BUNDLE group, the offerer MUST
process the answer as a normal answer. process the answer as a normal answer.
8.5. Modifying the Session 8.5. Modifying the Session
When an offerer generates a subsequent offer (i.e., a BUNDLE group When an offerer generates a subsequent offer (i.e., a BUNDLE group
has previously been negotiated), it MUST assign the previously has previously been negotiated), it MUST assign the previously
selected offer BUNDLE address [Section 8.3.1], or a new suggested selected offerer BUNDLE address:port [Section 8.3.1], or a newly
offerer BUNDLE address [Section 8.5.1], to exactly one "m=" section suggested offerer BUNDLE address:port [Section 8.5.1], to exactly one
within the BUNDLE group. "m=" section within the BUNDLE group.
The offerer MUST NOT assign an offerer BUNDLE address (previously The offerer MUST NOT assign an offerer BUNDLE address:port
selected [Section 8.3.1] or new suggested [Section 8.5.1]) to a (previously selected [Section 8.3.1] or newly suggested
bundled "m=" section if: [Section 8.5.1]) to a bundled "m=" section if:
o The offerer wants to move the bundled "m=" section out of the o The offerer wants to move the bundled "m=" section out of the
BUNDLE group [Section 8.5.3]; or BUNDLE group [Section 8.5.3]; or
o The offerer wants to disable the bundled "m=" section o The offerer wants to disable the bundled "m=" section
[Section 8.5.4]. [Section 8.5.4].
To every other "m=" section within the BUNDLE group, the offerer MUST To every other "m=" section within the BUNDLE group, the offerer MUST
assign a zero port value and an SDP 'bundle-only' attribute. assign a zero port value and an SDP 'bundle-only' attribute.
When the offerer generates a subsequent offer, the offerer BUNDLE-tag When the offerer generates a subsequent offer, the offerer BUNDLE-tag
MUST represent the bundled "m=" section to which the offerer BUNDLE MUST represent the bundled "m=" section to which the offerer BUNDLE
address (previously negotiated or new suggested) has been assigned. address:port (previously negotiated or newly suggested) has been
assigned.
8.5.1. Suggesting a New Offerer BUNDLE Address 8.5.1. Suggesting a New Offerer BUNDLE Address:Port
When an offerer generates an offer, in which it suggests a new When an offerer generates an offer, in which it suggests a new
offerer BUNDLE address [Section 8.2.1], the offerer MUST: offerer BUNDLE address:port [Section 8.2.1], the offerer MUST:
o Assign the new suggested offerer BUNDLE address to exactly one o Assign the newly suggested offerer BUNDLE address:port to exactly
"m=" section within the BUNDLE group; and one "m=" section within the BUNDLE group; and
o Assign a zero port value and an SDP 'bundle-only' attribute to o Assign a zero port value and an SDP 'bundle-only' attribute to
every other "m=" section within the BUNDLE group. every other "m=" section within the BUNDLE group.
8.5.2. Adding a Media Description to a BUNDLE group 8.5.2. Adding a Media Description to a BUNDLE group
When an offerer generates an offer, in which it wants to add a When an offerer generates an offer, in which it wants to add a new
bundled "m=" section, the offerer MUST: bundled "m=" section, the offerer MUST:
o Assign the offerer BUNDLE address (previously selected o Assign the offerer BUNDLE address:port (previously selected
[Section 8.3.1] or new suggested [Section 8.5.1]) to the added [Section 8.3.1] or newly suggested [Section 8.5.1]) to the added
"m=" section; or "m=" section; or
o Assign a zero port value and an SDP 'bundle-only' attribute to the o Assign a zero port value and an SDP 'bundle-only' attribute to the
added "m=" section (in this case the offerer BUNDLE address is added "m=" section (in this case the offerer BUNDLE address:port
assigned to another "m=" section within the BUNDLE group). is assigned to another "m=" section within the BUNDLE group).
In addition, the offerer MUST place the identification-tag associated In addition, the offerer MUST place the identification-tag associated
with the added "m=" section in the SDP 'group:BUNDLE' attribute with the added "m=" section in the SDP 'group:BUNDLE' attribute
identification-tag list associated with the BUNDLE group identification-tag list associated with the BUNDLE group
[Section 8.2.1]. [Section 8.2.1].
NOTE: If the offerer also wants to suggest a new offerer BUNDLE NOTE: If the offerer also wants to suggest a new offerer BUNDLE
address to the BUNDLE group, the offerer can assign the new suggested address:port to the BUNDLE group, the offerer can assign the newly
offerer BUNDLE address either to the added "m=" section, or to some suggested offerer BUNDLE address:port either to the added "m="
other "m=" section within the BUNDLE group [Section 8.5.1]. section, or to some other "m=" section within the BUNDLE group
[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 to the "m=" section; and
skipping to change at page 20, line 18 skipping to change at page 20, line 11
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.
[Section 18.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.
9. Protocol Identification 9. 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 protocols on layer protocol. If bundled "m=" sections use different upper-layer
top of the transport-layer protocol, there MUST exist a publicly protocols on top of the transport-layer protocol, there MUST exist a
available specification which describes a mechanism how to associate publicly available specification which describes a mechanism how to
received data with the correct protocol for this particular protocol associate received data with the correct protocol for this particular
combination. protocol combination.
In addition, if received data can be associated with more than one In addition, if received data can be associated with more than one
bundled "m=" section, there MUST exist a publicly available bundled "m=" section, there MUST exist a publicly available
specification which describes a mechanism for associating the specification which describes a mechanism for associating the
received data with the correct "m=" section. received data with the correct "m=" section.
This document describes a mechanism to identify the protocol of This document describes a mechanism to identify the protocol of
received data among the STUN, DTLS and SRTP protocols (in any received data among the STUN, DTLS and SRTP protocols (in any
combination), when UDP is used as transport-layer protocol, but it combination), when UDP is used as transport-layer protocol, but it
does not describe how to identify different protocols transported on does not describe how to identify different protocols transported on
skipping to change at page 22, line 18 skipping to change at page 22, line 10
Multiple bundled "m=" sections might describe RTP based media. As Multiple bundled "m=" sections might describe RTP based media. As
all RTP based media associated with a BUNDLE group belong to the same all RTP based media associated with a BUNDLE group belong to the same
RTP session, in order for a given payload type value to be used RTP session, in order for a given payload type value to be used
inside more than one bundled "m=" section, all codecs associated with inside more than one bundled "m=" section, all codecs associated with
the payload type number MUST share an identical codec configuration. the payload type number MUST share an identical codec configuration.
This means that the codecs MUST share the same media type, encoding This means that the codecs MUST share the same media type, encoding
name, clock rate and any parameter that can affect the codec name, clock rate and any parameter that can affect the codec
configuration and packetization. configuration and packetization.
[I-D.ietf-mmusic-sdp-mux-attributes] lists SDP attributes, whose [I-D.ietf-mmusic-sdp-mux-attributes] lists SDP attributes, whose
attribute values must be identical for all codecs that use the same attribute values are required to be identical for all codecs that use
payload type value. the same payload type value.
10.2. Associating RTP/RTCP Streams with Correct SDP Media Description 10.2. Associating RTP/RTCP Streams with Correct SDP Media Description
As described in [RFC3550], RTP packets are associated with RTP As described in [RFC3550], RTP packets are associated with RTP
streams [RFC7656]. Each RTP stream is identified by an SSRC value, streams [RFC7656]. Each RTP stream is identified by an SSRC value,
and each RTP packet includes an SSRC field that is used to associate and each RTP packet includes an SSRC field that is used to associate
the packet with the correct RTP stream. RTCP packets also use SSRCs the packet with the correct RTP stream. RTCP packets also use SSRCs
to identify which RTP streams the packet relates to. However, a RTCP to identify which RTP streams the packet relates to. However, a RTCP
packet can contain multiple SSRC fields, in the course of providing packet can contain multiple SSRC fields, in the course of providing
feedback or reports on different RTP streams, and therefore can be feedback or reports on different RTP streams, and therefore can be
associated with multiple such streams. associated with multiple such streams.
In order to be able to process received RTP/RTCP packets correctly, In order to be able to process received RTP/RTCP packets correctly,
it must be possible to associate an RTP stream with the correct "m=" it MUST be possible to associate an RTP stream with the correct "m="
section, as the "m=" section and SDP attributes associated with the section, as the "m=" section and SDP attributes associated with the
"m=" section contains information needed to process the packets. "m=" section contains information needed to process the packets.
As all RTP streams associated with a BUNDLE group use the same As all RTP streams associated with a BUNDLE group use the same
transport for sending and receiving RTP/RTCP packets, the local transport for sending and receiving RTP/RTCP packets, the local
address:port combination part of the transport cannot be used to address:port combination part of the transport cannot be used to
associate an RTP stream with the correct "m=" section. In addition, associate an RTP stream with the correct "m=" section. In addition,
multiple RTP streams might be associated with the same "m=" section. multiple RTP streams might be associated with the same "m=" section.
An offerer and answerer can inform each other which SSRC values they An offerer and answerer can inform each other which SSRC values they
skipping to change at page 23, line 21 skipping to change at page 23, line 12
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 15. 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 should RTCP packet contains new information that affects how packets are to
be routed. be routed.
However, some implementations may not include this identification-tag However, some legacy implementations may not include this
in their RTP and RTCP traffic when using the BUNDLE mechanism, and identification-tag in their RTP and RTCP traffic when using the
instead use a payload type based mechanism to associate RTP streams BUNDLE mechanism, and instead use a payload type based mechanism to
with SDP "m=" sections. In this situation, each "m=" section MUST associate RTP streams with SDP "m=" sections. In this situation,
use unique payload type values, in order for the payload type to be a each "m=" section needs to use unique payload type values, in order
reliable indicator of the relevant "m=" section for the RTP stream. for the payload type to be a reliable indicator of the relevant "m="
section for the RTP stream. If an implementation fails to ensure
unique payload type values it will be impossible to associate the RTP
stream using that payload type value to a particular "m=" section.
Note that when using the payload type to associate RTP streams with Note that when using the payload type to associate RTP streams with
"m=" sections an RTP stream, identified by its SSRC, will be mapped "m=" sections an RTP stream, identified by its SSRC, will be mapped
to an "m=" section when the first packet of that RTP stream is to an "m=" section when the first packet of that RTP stream is
received, and the mapping will not be changed even if the payload received, and the mapping will not be changed even if the payload
type used by that RTP stream changes. In other words, the SSRC type used by that RTP stream changes. In other words, the SSRC
cannot "move" to a different "m=" section simply by changing the cannot "move" to a different "m=" section simply by changing the
payload type. payload type.
Applications can implement RTP stacks in many different ways. The Applications can implement RTP stacks in many different ways. The
algorithm below details one way that RTP streams can be associated algorithm below details one way that RTP streams can be associated
skipping to change at page 25, line 17 skipping to change at page 25, line 9
Otherwise, mark the RTP stream as not for decoding and discard the Otherwise, mark the RTP stream as not for decoding and discard the
payload. payload.
If the RTP packet contains one or more contributing source (CSRC) If the RTP packet contains one or more contributing source (CSRC)
identifiers, then each CSRC is looked up in the incoming SSRC table identifiers, then each CSRC is looked up in the incoming SSRC table
and a copy of the RTP packet is associated with the corresponding and a copy of the RTP packet is associated with the corresponding
"m=" section for additional processing. "m=" section for additional processing.
For each RTCP packet received (including each RTCP packet that is For each RTCP packet received (including each RTCP packet that is
part of a compound RTCP packet), the packet is processed as usual by part of a compound RTCP packet), the packet is processed as usual by
the RTP layer, then passed to the "m=" sections corresponding to the the RTP layer, then associated with the appropriate "m=" sections,
RTP streams it contains information about for additional processing. and processed for the RTP streams represented by those "m=" sections.
This routing is type-dependent, as each kind of RTCP packet has its This routing is type-dependent, as each kind of RTCP packet has its
own mechanism for associating it with the relevant RTP streams. own mechanism for associating it with the relevant RTP streams.
RTCP packets for which no appropriate "m=" section can be identified RTCP packets that cannot be associated with an appropriate "m="
MUST be processed as usual by the RTP layer, updating the metadata section MUST still be processed as usual by the RTP layer, updating
associated with the corresponding RTP streams, but are not passed to the metadata associated with the corresponding RTP streams. This
any "m=" section. This situation can occur with certain multiparty situation can occur with certain multiparty RTP topologies, or when
RTP topologies, or when RTCP packets are sent containing a subset of RTCP packets are sent containing a subset of the SDES information.
the SDES information.
Rules for additional processing of the various types of RTCP packets Additional rules for processing various types of RTCP packets are
are explained below. explained below.
If the RTCP packet is of type SDES, for each chunk in the packet If the RTCP packet is of type SDES, for each chunk in the packet
whose SSRC is found in the incoming SSRC table, deliver a copy of whose SSRC is found in the incoming SSRC table, deliver a copy of
the SDES packet to the "m=" section associated with that SSRC. In the SDES packet to the "m=" section associated with that SSRC. In
addition, for any SDES MID items contained in these chunks, if the addition, for any SDES MID items contained in these chunks, if the
MID is found in the table mapping MID to "m=" section, update the MID is found in the table mapping MID to "m=" section, update the
incoming SSRC table to include an entry that maps the RTP stream incoming SSRC table to include an entry that maps the RTP stream
associated with the chunk's SSRC to the "m=" section associated associated with the chunk's SSRC to the "m=" section associated
with that MID, unless the packet is older than the packet that with that MID, unless the packet is older than the packet that
most recently updated the mapping for this SSRC, as discussed in most recently updated the mapping for this SSRC, as discussed in
[RFC7941], Section 4.2.6. [RFC7941], Section 4.2.6.
Note that if an SDES packet is received as part of a compound RTCP Note that if an SDES packet is received as part of a compound RTCP
packet, the SSRC to "m=" section mapping may not exist until the packet, the SSRC to "m=" section mapping might not exist until the
SDES packet is handled (e.g., in the case where RTCP for a source SDES packet is handled (e.g., in the case where RTCP for a source
is received before any RTP packets). Therefore, when processing a is received before any RTP packets). Therefore, it can be
compound packet, any contained SDES packet MUST be handled first. beneficial for an implementation to delay RTCP packet routing,
Note that this is a change from [RFC3550] Section 6.1, which such that it either prioritizes processing of the SDES item to
states that "Each individual RTCP packet in the compound packet generate or update the mapping, or buffers the RTCP information
may be processed independently with no requirements upon the order that needs to be routed until the SDES item(s) has been processed.
or combination of packets". If the implementation is unable to follow this recommendation, the
consequence could be that some RTCP information from this
particular RTCP compound packet is not provided to higher layers.
The impact from this is likely minor, when this information
relates to a future incoming RTP stream.
If the RTCP packet is of type BYE, it indicates that the RTP If the RTCP packet is of type BYE, it indicates that the RTP
streams referenced in the packet are ending. Therefore, for each streams referenced in the packet are ending. Therefore, for each
SSRC indicated in the packet that is found in the incoming SSRC SSRC indicated in the packet that is found in the incoming SSRC
table, first deliver a copy of the BYE packet to the "m=" section table, first deliver a copy of the BYE packet to the "m=" section
associated with that SSRC, then remove the entry for that SSRC associated with that SSRC, then remove the entry for that SSRC
from the incoming SSRC table after an appropriate delay to account from the incoming SSRC table after an appropriate delay to account
for "straggler packets", as specified in [RFC3550], Section 6.2.1. for "straggler packets", as specified in [RFC3550], Section 6.2.1.
If the RTCP packet is of type SR or RR, for each report block in If the RTCP packet is of type SR or RR, for each report block in
skipping to change at page 28, line 30 skipping to change at page 28, line 24
multiplexing for RTP-based media associated with a BUNDLE group. multiplexing for RTP-based media associated with a BUNDLE group.
The mux category [I-D.ietf-mmusic-sdp-mux-attributes] of the SDP The mux category [I-D.ietf-mmusic-sdp-mux-attributes] of the SDP
'rtcp-mux' and 'rtcp-mux-only' attributes is IDENTICAL. Section 8.1 'rtcp-mux' and 'rtcp-mux-only' attributes is IDENTICAL. Section 8.1
describes the details regarding which bundled "m=" sections an describes the details regarding which bundled "m=" sections an
offerer and answerer associates the attributes with. offerer and answerer associates the attributes with.
RTP/RTCP multiplexing only applies to RTP-based media. However, as RTP/RTCP multiplexing only applies to RTP-based media. However, as
described in Section 8.1, within a BUNDLE group the SDP 'rtcp-mux' described in Section 8.1, within a BUNDLE group the SDP 'rtcp-mux'
and SDP 'rtcp-mux-only' attributes might be included in a non-RTP- and SDP 'rtcp-mux-only' attributes might be included in a non-RTP-
based bundled "m=" section (if such "m=" line is represented by a based bundled "m=" section (if such "m=" line is indicated by a
BUNDLE-tag). BUNDLE-tag).
NOTE: The offer in which the offerer indicates that it wants to
create a BUNDLE group can be the initial offer of the session, or a
subsequent offer within the session. As defined in Section 2, within
the scope of this document the initial offer always refers to the
offer in which the offerer indicates that it wants to create a BUNDLE
group, no matter whether that offer is the initial offer, or a
subsequent offer, within the session.
10.3.1.1. Generating the Initial SDP Offer 10.3.1.1. Generating the Initial SDP Offer
When an offerer generates an initial offer, if the offer contains one When an offerer generates an initial offer, if the offer contains one
or more RTP-based bundled "m=" sections (or, if there is a chance or more RTP-based bundled "m=" sections (or, if there is a chance
that RTP-based "m=" sections will later be added to the BUNDLE that RTP-based "m=" sections will later be added to the BUNDLE
group), the offerer MUST include an SDP 'rtcp-mux' attribute group), the offerer MUST include an SDP 'rtcp-mux' attribute
[RFC5761] in each bundled "m=" section (excluding any bundle-only [RFC5761] in each bundled "m=" section (excluding any bundle-only
"m=" sections), following the procedures for IDENTICAL mux category "m=" sections), following the procedures for IDENTICAL mux category
attributes in Section 8.1. In addition, the offerer MAY include an attributes in Section 8.1. In addition, the offerer MAY include an
SDP 'rtcp-mux-only' attribute [I-D.ietf-mmusic-mux-exclusive] in a SDP 'rtcp-mux-only' attribute [I-D.ietf-mmusic-mux-exclusive] in a
skipping to change at page 29, line 21 skipping to change at page 29, line 24
unique in each bundled RTP-based "m=" section (excluding a bundle- unique in each bundled RTP-based "m=" section (excluding a bundle-
only "m=" section), similar to RTP. only "m=" section), similar to RTP.
10.3.1.2. Generating the SDP Answer 10.3.1.2. Generating the SDP Answer
When an answerer generates an answer, if the answerer supports RTP- When an answerer generates an answer, if the answerer supports RTP-
based media, and if a bundled "m=" section in the offer contained an based media, and if a bundled "m=" section in the offer contained an
SDP 'rtcp-mux' attribute, the answerer MUST enable usage of RTP/RTCP SDP 'rtcp-mux' attribute, the answerer MUST enable usage of RTP/RTCP
multiplexing, even if there currently are no RTP-based "m=" sections multiplexing, even if there currently are no RTP-based "m=" sections
within the BUNDLE group. The answerer MUST include an SDP 'rtcp-mux' within the BUNDLE group. The answerer MUST include an SDP 'rtcp-mux'
attribute in the bundled "m=" section represented by the answerer attribute in the bundled "m=" section indicated by the answerer
BUNDLE-tag, following the procedures for IDENTICAL mux category BUNDLE-tag, following the procedures for IDENTICAL mux category
attributes in Section 8.1. In addition, if the "m=" section in the attributes in Section 8.1. In addition, if the "m=" section in the
offer contained an SDP "rtcp-mux-only" attribute, the answerer MUST offer contained an SDP "rtcp-mux-only" attribute, the answerer MUST
include an SDP "rtcp-mux-only" attribute in the bundled "m=" section include an SDP "rtcp-mux-only" attribute in the bundled "m=" section
represented by the answerer BUNDLE-tag in the answer. indicated by the answerer BUNDLE-tag in the answer.
If the "m=" section represented by the offerer BUNDLE-tag in the If the "m=" section indicated by the offerer BUNDLE-tag in the offer
offer contained an SDP 'rtcp-mux-only' attribute, and if the answerer contained an SDP 'rtcp-mux-only' attribute, and if the answerer moves
moves an RTP-based "m=" section out of the BUNDLE group in the answer an RTP-based "m=" section out of the BUNDLE group in the answer
[Section 8.3.3], the answerer MUST either include the attribute in [Section 8.3.3], the answerer MUST either include the attribute in
the moved "m=" section (and enable RTP/RTCP multiplexing for the the moved "m=" section (and enable RTP/RTCP multiplexing for the
media associated with the "m=" section), or reject the "m=" section media associated with the "m=" section), or reject the "m=" section
[Section 8.3.4]. [Section 8.3.4].
The answerer MUST NOT include an SDP 'rtcp' attribute in any "m=" The answerer MUST NOT include an SDP 'rtcp' attribute in any "m="
section within the BUNDLE group in the answer. The answerer will use section within the BUNDLE group in the answer. The answerer will use
the port value of the selected offerer BUNDLE address for sending RTP the port value of the selected offerer BUNDLE address:port for
and RTCP packets associated with each RTP-based bundled "m=" section sending RTP and RTCP packets associated with each RTP-based bundled
towards the offerer. "m=" section towards the offerer.
If the usage of RTP/RTCP multiplexing within a BUNDLE group has been If the usage of RTP/RTCP multiplexing within a BUNDLE group has been
negotiated in a previous offer/answer exchange, the answerer MUST negotiated in a previous offer/answer exchange, the answerer MUST
include an SDP 'rtcp-mux' attribute in the "m=" section associated include an SDP 'rtcp-mux' attribute in the "m=" section associated
with the answerer BUNDLE-tag in the answer. It is not possible to with the answerer BUNDLE-tag in the answer. It is not possible to
disable RTP/RTCP multiplexing within a BUNDLE group. disable RTP/RTCP multiplexing within a BUNDLE group.
10.3.1.3. Offerer Processing of the SDP Answer 10.3.1.3. Offerer Processing of the SDP Answer
When an offerer receives an answer, if the answerer has accepted the When an offerer receives an answer, if the answerer has accepted the
skipping to change at page 30, line 4 skipping to change at page 30, line 10
negotiated in a previous offer/answer exchange, the answerer MUST negotiated in a previous offer/answer exchange, the answerer MUST
include an SDP 'rtcp-mux' attribute in the "m=" section associated include an SDP 'rtcp-mux' attribute in the "m=" section associated
with the answerer BUNDLE-tag in the answer. It is not possible to with the answerer BUNDLE-tag in the answer. It is not possible to
disable RTP/RTCP multiplexing within a BUNDLE group. disable RTP/RTCP multiplexing within a BUNDLE group.
10.3.1.3. Offerer Processing of the SDP Answer 10.3.1.3. Offerer Processing of the SDP Answer
When an offerer receives an answer, if the answerer has accepted the When an offerer receives an answer, if the answerer has accepted the
usage of RTP/RTCP multiplexing (see Section 10.3.1.2), the answerer usage of RTP/RTCP multiplexing (see Section 10.3.1.2), the answerer
follows the procedures for RTP/RTCP multiplexing defined in follows the procedures for RTP/RTCP multiplexing defined in
[RFC5761]. The offerer will use the port value associated with the [RFC5761]. The offerer will use the port value associated with the
answerer BUNDLE address for sending RTP and RTCP packets associated answerer BUNDLE address:port for sending RTP and RTCP packets
with each RTP-based bundled "m=" section towards the answerer. associated with each RTP-based bundled "m=" section towards the
answerer.
NOTE: It is considered a protocol error if the answerer has not NOTE: It is considered a protocol error if the answerer has not
accepted the usage of RTP/RTCP multiplexing for RTP-based "m=" accepted the usage of RTP/RTCP multiplexing for RTP-based "m="
sections that the answerer included in the BUNDLE group. sections that the answerer included in the BUNDLE group.
10.3.1.4. Modifying the Session 10.3.1.4. Modifying the Session
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 bundled "m=" section include an SDP 'rtcp-mux' attribute in the bundled "m=" section
represented by the offerer BUNDLE-tag, following the procedures for indicated by the offerer BUNDLE-tag, following the procedures for
IDENTICAL mux category attributes in Section 8.1. IDENTICAL mux category attributes in Section 8.1.
11. ICE Considerations 11. 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 [I-D.ietf-ice-rfc5245bis]. 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
skipping to change at page 30, line 39 skipping to change at page 30, line 45
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 to one or more
bundled "m=" sections (excluding any bundle-only "m=" sections), bundled "m=" sections (excluding any bundle-only "m=" sections),
the offerer MUST include ICE-related media-level attributes in the offerer MUST include ICE-related media-level attributes in
each of those "m=" sections. If the offerer assigns an offerer each of those "m=" sections. If the offerer assigns an offerer
BUNDLE address (previously selected [Section 8.3.1] or new BUNDLE address:port (previously selected [Section 8.3.1] or newly
suggested [Section 8.5.1]) to a bundled "m=" section (the "m=" suggested [Section 8.5.1]) to a bundled "m=" section (the "m="
section represented by the offerer BUNDLE-tag), the offerer only section indicated by the offerer BUNDLE-tag), the offerer only
includes ICE-related media-level SDP attributes in that "m=" includes ICE-related media-level SDP attributes in that "m="
section, following the procedures in Section 8.1. 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 (the "m=" section has assigned the answerer BUNDLE address:port (the "m=" section
represented by the answerer BUNDLE-tag), following the procedures indicated by the answerer BUNDLE-tag), following the procedures in
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. ICE mechanism is used. Note that applications might mandate usage of
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 to one or more bundled "m="
sections (excluding any bundle-only "m=" section), the offerer MUST sections (excluding any bundle-only "m=" section), the offerer MUST
include SDP 'candidate' attributes (and other applicable ICE-related include SDP 'candidate' attributes (and other applicable ICE-related
media-level SDP attributes), containing unique ICE properties 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 (previously selected or new When an offerer assigns a BUNDLE address:port (previously selected or
suggested) to a bundled "m=" section, (the "m=" section represented newly suggested) to a bundled "m=" section, (the "m=" section
by the offerer BUNDLE-tag) the offerer MUST only include SDP indicated by the offerer BUNDLE-tag) the offerer MUST only include
'candidate' attributes (and other applicable ICE-related media-level SDP 'candidate' attributes (and other applicable ICE-related media-
SDP attributes) in that "m=" section, following the procedures in level SDP attributes) in that "m=" section, following the procedures
Section 8.1. in Section 8.1.
When an answerer assigns a BUNDLE address to an "m=" section within a When an answerer assigns a BUNDLE address to an "m=" section within a
BUNDLE group (the "m=" section represented by the answerer BUNDLE- BUNDLE group (the "m=" section represented by the answerer BUNDLE-
tag), the answerer MUST only include SDP 'candidate' attributes (and tag), the answerer onlys include SDP 'candidate' attributes (and
other applicable ICE-related media-level SDP attributes) in that "m=" other applicable ICE-related media-level SDP attributes) in that "m="
section, following the procedures in Section 8.1. section, following the procedures in Section 8.1. The answerer MUST
NOT include ICE-related media-level SDP attributes in any other "m="
sections.
NOTE: As most ICE-related media-level SDP attributes belong to the NOTE: As most ICE-related media-level SDP attributes belong to the
TRANSPORT mux category [I-D.ietf-mmusic-sdp-mux-attributes], the TRANSPORT mux category [I-D.ietf-mmusic-sdp-mux-attributes], the
offerer and answerer follow the procedures in Section 8.1 when offerer and answerer follow the procedures in Section 8.1 when
deciding whether to include an attribute in a bundled "m=" section. deciding whether to include an attribute in a bundled "m=" section.
However, in the case of ICE-related media-level attributes, the rules However, in the case of ICE-related media-level attributes, the rules
apply to all attributes (see note below), even if they belong to a apply to all attributes (see note below), even if they belong to a
different mux category. different mux category.
NOTE: The following ICE-related media-level SDP attributes are NOTE: The following ICE-related media-level SDP attributes are
skipping to change at page 32, line 41 skipping to change at page 33, line 7
13. RTP Header Extensions Consideration 13. RTP Header Extensions Consideration
When [RFC8285] RTP header extensions are used in the context of this When [RFC8285] RTP header extensions are used in the context of this
specification, the identifier used for a given extension MUST specification, the identifier used for a given extension MUST
identify the same extension across all the bundled media identify the same extension across all the bundled media
descriptions. descriptions.
14. Update to RFC 3264 14. Update to RFC 3264
This section replaces the text of the following sections of RFC 3264: This section updates RFC 3264, in order to allow extensions to define
the usage of a zero port value in offers and answers for other
purposes than removing or disabling media streams. The following
sections of RFC 3264 are updated:
o Section 5.1 (Unicast Streams). o Section 5.1 (Unicast Streams).
o Section 6 (Generating the Answer). o Section 6 (Generating the Answer).
o Section 8.2 (Removing a Media Stream).
o Section 8.4 (Putting a Unicast Media Stream on Hold). o Section 8.4 (Putting a Unicast Media Stream on Hold).
14.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 14.1. Original text of section 5.1 (2nd paragraph) of RFC 3264
For recvonly and sendrecv streams, the port number and address in the For recvonly and sendrecv streams, the port number and address in the
offer indicate where the offerer would like to receive the media offer indicate where the offerer would like to receive the media
stream. For sendonly RTP streams, the address and port number stream. For sendonly RTP streams, the address and port number
indirectly indicate where the offerer wants to receive RTCP reports. indirectly indicate where the offerer wants to receive RTCP reports.
Unless there is an explicit indication otherwise, reports are sent to Unless there is an explicit indication otherwise, reports are sent to
the port number one higher than the number indicated. The IP address the port number one higher than the number indicated. The IP address
skipping to change at page 34, line 16 skipping to change at page 34, line 25
An offered stream MAY be rejected in the answer, for any reason. If An offered stream MAY be rejected in the answer, for any reason. If
a stream is rejected, the offerer and answerer MUST NOT generate a stream is rejected, the offerer and answerer MUST NOT generate
media (or RTCP packets) for that stream. A port number of zero in media (or RTCP packets) for that stream. A port number of zero in
the answer by default indicates that the offered stream is rejected, the answer by default indicates that the offered stream is rejected,
but an extension mechanism might specify different semantics for the but an extension mechanism might specify different semantics for the
usage of a zero port value. If a stream is rejected, any media usage of a zero port value. If a stream is rejected, any media
formats listed are ignored. At least one MUST be present, as formats listed are ignored. At least one MUST be present, as
specified by SDP. specified by SDP.
14.5. Original text of section 8.2 (2nd paragraph) of RFC 3264 14.5. Original text of section 8.4 (6th paragraph) of RFC 3264
A stream that is offered with a port of zero MUST be marked with port
zero in the answer. Like the offer, the answer MAY omit all
attributes present previously, and MAY list just a single media
format from amongst those in the offer.
14.6. New text replacing section 8.2 (2nd paragraph) of RFC 3264
A stream that is offered with a port of zero MUST by default be
marked with port zero in the answer, unless an extension mechanism,
which specifies semantics for the usage of a non-zero port value, is
used. If the stream is marked with port zero in the answer, the
answer MAY omit all attributes present previously, and MAY list just
a single media format from amongst those in the offer.
14.7. Original text of section 8.4 (6th paragraph) of RFC 3264
RFC 2543 [10] specified that placing a user on hold was accomplished RFC 2543 [10] specified that placing a user on hold was accomplished
by setting the connection address to 0.0.0.0. Its usage for putting by setting the connection address to 0.0.0.0. Its usage for putting
a call on hold is no longer recommended, since it doesn't allow for a call on hold is no longer recommended, since it doesn't allow for
RTCP to be used with held streams, doesn't work with IPv6, and breaks RTCP to be used with held streams, doesn't work with IPv6, and breaks
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, which would specify that the stream has been number MUST NOT be zero, which would specify that the stream has been
disabled. An agent MUST be capable of receiving SDP with a disabled. An agent MUST be capable of receiving SDP with a
connection address of 0.0.0.0, in which case it means that neither connection address of 0.0.0.0, in which case it means that neither
RTP nor RTCP should be sent to the peer. RTP nor RTCP is to be sent to the peer.
14.8. New text replacing section 8.4 (6th paragraph) of RFC 3264 14.6. New text replacing section 8.4 (6th paragraph) of RFC 3264
RFC 2543 [10] specified that placing a user on hold was accomplished RFC 2543 [10] specified that placing a user on hold was accomplished
by setting the connection address to 0.0.0.0. Its usage for putting by setting the connection address to 0.0.0.0. Its usage for putting
a call on hold is no longer recommended, since it doesn't allow for a call on hold is no longer recommended, since it doesn't allow for
RTCP to be used with held streams, doesn't work with IPv6, and breaks RTCP to be used with held streams, doesn't work with IPv6, and breaks
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 should be sent to the peer. means that neither RTP nor RTCP is to be sent to the peer.
15. RTP/RTCP extensions for identification-tag transport 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
skipping to change at page 36, line 47 skipping to change at page 36, line 40
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].
As the identification-tag is included in either an RTCP SDES item or As the identification-tag is included in either an RTCP SDES item or
an RTP SDES header extension, or both, there should be some an RTP SDES header extension, or both, there needs to be some
consideration about the packet expansion caused by the consideration about the packet expansion caused by the
identification-tag. To avoid Maximum Transmission Unit (MTU) issues identification-tag. To avoid Maximum Transmission Unit (MTU) issues
for the RTP packets, the header extension's size needs to be taken for the RTP packets, the header extension's size needs to be taken
into account when encoding the media. into account when encoding the media.
It is recommended that the identification-tag is kept short. Due to It is recommended that the identification-tag is kept short. Due to
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 application the identification-tag using a pattern that enables user- or
identification. application identification.
16. IANA Considerations 16. IANA Considerations
16.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.]
skipping to change at page 38, line 7 skipping to change at page 38, line 7
[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
Contact: christer.holmberg@ericsson.com Contact: IESG (iesg@ietf.org)
Reference: RFCXXXX Reference: RFCXXXX
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.
skipping to change at page 38, line 34 skipping to change at page 38, line 34
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: Christer Holmberg Contact name: IESG
Contact e-mail: christer.holmberg@ericsson.com Contact e-mail: iesg@ietf.org
Reference: RFCXXXX Reference: RFCXXXX
Mux category: NORMAL Mux category: NORMAL
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
skipping to change at page 40, line 15 skipping to change at page 40, line 15
classification in [I-D.ietf-mmusic-sdp-mux-attributes]. classification in [I-D.ietf-mmusic-sdp-mux-attributes].
The security considerations of "RTP Header Extension for the RTP The security considerations of "RTP Header Extension for the RTP
Control Protocol (RTCP) Source Description Items" [RFC7941] requires Control Protocol (RTCP) Source Description Items" [RFC7941] requires
that when RTCP is confidentiality protected, and that any SDES RTP that when RTCP is confidentiality protected, and that any SDES RTP
header extension carrying an SDES item, such as the MID RTP header header extension carrying an SDES item, such as the MID RTP header
extension, is also protected using commensurate strength algorithms. extension, is also protected using commensurate strength algorithms.
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.
Thus, the requirements in RFC 7941 MAY be ignored for the MID RTP Therefore, this specification updates RFC 7941 by adding the
header extension. Security mechanisms for RTP/RTCP are discussed in exception that this requirement MAY be ignored for the MID RTP header
Options for Securing RTP Sessions [RFC7201], for example SRTP extension. Security mechanisms for RTP/RTCP are discussed in Options
[RFC3711] can provide the necessary security functions of ensuring for Securing RTP Sessions [RFC7201], for example SRTP [RFC3711] can
the integrity and source authenticity. provide the necessary security functions of ensuring the integrity
and source authenticity.
18. Examples 18. Examples
18.1. Example: Bundle Address 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 to each
bundled "m=" section within the BUNDLE group. 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, and then selects its own BUNDLE address (the answerer address:port, and then selects its own BUNDLE address (the
BUNDLE address) and assigns it to the bundled "m=" section answerer BUNDLE address:port) and assigns it to the bundled "m="
represented 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 IP4 atlanta.example.com o=alice 2890844526 2890844526 IN IP6 2001:db8::3
s= s=
c=IN IP4 atlanta.example.com 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
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
a=rtcp-mux a=rtcp-mux
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
skipping to change at page 41, line 32 skipping to change at page 41, line 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=rtcp-mux a=rtcp-mux
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
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
SDP Answer (2) SDP Answer (2)
v=0 v=0
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com o=bob 2808844564 2808844564 IN IP6 2001:db8::1
s= s=
c=IN IP4 biloxi.example.com c=IN IP6 2001:db8::1
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
a=rtcp-mux a=rtcp-mux
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
skipping to change at page 43, line 8 skipping to change at page 43, line 8
o An offer, in which the offerer assigns a unique address to each o An offer, in which the offerer assigns a unique address to each
bundled "m=" section within the BUNDLE group. 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 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 IP4 atlanta.example.com o=alice 2890844526 2890844526 IN IP6 2001:db8::3
s= s=
c=IN IP4 atlanta.example.com 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
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
a=rtcp-mux a=rtcp-mux
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
skipping to change at page 43, line 32 skipping to change at page 43, line 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=rtcp-mux a=rtcp-mux
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
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
SDP Answer (2) SDP Answer (2)
v=0 v=0
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com o=bob 2808844564 2808844564 IN IP6 2001:db8::1
s= s=
c=IN IP4 biloxi.example.com c=IN IP6 2001:db8::1
t=0 0 t=0 0
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
18.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 (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 exchange), in which the offerer adds a new previous offer/answer exchange), in which the offerer adds a new
"m=" section, represented by the "zen" identification-tag, to a "m=" section, indicated by the "zen" identification-tag, to a
previously negotiated BUNDLE group, assigns the previously previously negotiated BUNDLE group, assigns the previously
selected offerer BUNDLE address to the added "m=" section, selected offerer BUNDLE address:port to the added "m=" section,
represented by the offerer BUNDLE-tag. To every other bundled indicated by the offerer BUNDLE-tag. To every other bundled "m="
"m=" section the offerer assigns a zero port value and includes an section the offerer assigns a zero port value and includes an SDP
SDP 'bundle-only' attribute. 'bundle-only' attribute.
o An answer, in which the answerer assigns the answerer BUNDLE o An answer, in which the answerer assigns the answerer BUNDLE
address to the bundled "m=" section represented by the answerer address:port to the bundled "m=" section indicated by the answerer
BUNDLE-tag. To every other bundled "m=" section the answerer BUNDLE-tag. To every other bundled "m=" section the answerer
assigns a zero port value and includes an SDP 'bundle-only' assigns a zero port value and includes an SDP 'bundle-only'
attribute. attribute.
SDP Offer (1) SDP Offer (1)
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com o=alice 2890844526 2890844526 IN IP6 2001:db8::3
s= s=
c=IN IP4 atlanta.example.com c=IN IP6 2001:db8::3
t=0 0 t=0 0
a=group:BUNDLE zen foo bar a=group:BUNDLE zen foo bar
m=audio 0 RTP/AVP 0 8 97 m=audio 0 RTP/AVP 0 8 97
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
a=bundle-only a=bundle-only
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
skipping to change at page 45, line 5 skipping to change at page 45, line 5
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 10000 RTP/AVP 66 m=video 10000 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
SDP Answer (2) SDP Answer (2)
v=0 v=0
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com o=bob 2808844564 2808844564 IN IP6 2001:db8::1
s= s=
c=IN IP4 biloxi.example.com c=IN IP6 2001:db8::1
t=0 0 t=0 0
a=group:BUNDLE zen foo bar a=group:BUNDLE zen foo bar
m=audio 0 RTP/AVP 0 m=audio 0 RTP/AVP 0
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
a=bundle-only a=bundle-only
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
skipping to change at page 45, line 35 skipping to change at page 45, line 35
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
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, represented 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 to the moved "m="
section, and assigns the previously selected offerer BUNDLE section, and assigns the previously selected offerer BUNDLE
address to another bundled "m=" section, represented 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 to the moved "m=" section,
and assigns the answerer BUNDLE address to the bundled "m=" and assigns the answerer BUNDLE address:port to the bundled "m="
section represented by the answerer BUNDLE-tag. To every other section indicated by the answerer BUNDLE-tag. To every other
bundled "m=" section the answerer assigns a zero port value and bundled "m=" section the answerer assigns a zero port value and
includes an SDP 'bundle-only' attribute. includes an SDP 'bundle-only' attribute.
SDP Offer (1) SDP Offer (1)
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com o=alice 2890844526 2890844526 IN IP6 2001:db8::3
s= s=
c=IN IP4 atlanta.example.com 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
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
a=rtcp-mux a=rtcp-mux
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
skipping to change at page 46, line 37 skipping to change at page 46, line 37
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 50000 RTP/AVP 66 m=video 50000 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
SDP Answer (2) SDP Answer (2)
v=0 v=0
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com o=bob 2808844564 2808844564 IN IP6 2001:db8::1
s= s=
c=IN IP4 biloxi.example.com c=IN IP6 2001:db8::1
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
a=rtcp-mux a=rtcp-mux
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
skipping to change at page 47, line 19 skipping to change at page 47, line 19
a=rtcp-mux a=rtcp-mux
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
18.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 (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 disables previous offer/answer transaction), in which the offerer disables
a bundled "m=" section represented by the "zen" identification- a bundled "m=" section indicated by the "zen" identification-tag,
tag, within a BUNDLE group, assigns a zero port number to the within a BUNDLE group, assigns a zero port number to the disabled
disabled "m=" section, and assigns the offerer BUNDLE address to "m=" section, and assigns the offerer BUNDLE address:port to
another bundled "m=" section, represented by the offerer BUNDLE- another bundled "m=" section, indicated by the offerer BUNDLE-tag.
tag. To every other bundled "m=" section the offerer assigns a To every other bundled "m=" section the offerer assigns a zero
zero port value and includes an SDP 'bundle-only' attribute. port value and includes an SDP 'bundle-only' attribute.
o An answer, in which the answerer moves the disabled "m=" sections o An answer, in which the answerer moves the disabled "m=" sections
out of the BUNDLE group, assigns a zero port value to the disabled out of the BUNDLE group, assigns a zero port value to the disabled
"m=" section, and assigns the answerer BUNDLE address to the "m=" section, and assigns the answerer BUNDLE address:port to the
bundled "m=" section represented by the answerer BUNDLE-tag. To bundled "m=" section indicated by the answerer BUNDLE-tag. To
every other bundled "m=" section the answerer assigns a zero port every other bundled "m=" section the answerer assigns a zero port
value and 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 IP4 atlanta.example.com o=alice 2890844526 2890844526 IN IP6 2001:db8::3
s= s=
c=IN IP4 atlanta.example.com
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
c=IN IP6 2001:db8::3
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
a=rtcp-mux a=rtcp-mux
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/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 31 32 m=video 0 RTP/AVP 31 32
c=IN IP6 2001:db8::3
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=bundle-only a=bundle-only
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
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
SDP Answer (2) SDP Answer (2)
v=0 v=0
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com o=bob 2808844564 2808844564 IN IP6 2001:db8::1
s= s=
c=IN IP4 biloxi.example.com
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
c=IN IP6 2001:db8::1
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
a=rtcp-mux a=rtcp-mux
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
c=IN IP6 2001:db8::1
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
19. Acknowledgements 19. Acknowledgements
skipping to change at page 49, line 14 skipping to change at page 49, line 14
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.
Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas
Stach, Ari Keranen, Adam Roach, Christian Groves, Roman Shpount, Stach, Ari Keranen, Adam Roach, Christian Groves, Roman Shpount,
Suhas Nandakumar, Nils Ohlmeier, Jens Guballa, Raju Makaraju, Justin Suhas Nandakumar, Nils Ohlmeier, Jens Guballa, Raju Makaraju, Justin
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, Cullen Jennings, Peter Thatcher, Justin Thanks to Bernard Aboba, Peter Thatcher, Justin Uberti, and Magnus
Uberti, and Magnus Westerlund for providing the text for the section Westerlund for providing the text for the section on RTP/RTCP stream
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 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-47
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
o Mux category for SDP 'group:BUNDLE' attribute added. o Mux category for SDP 'group:BUNDLE' attribute added.
o https://github.com/cdh4u/draft-sdp-bundle/pull/54 o https://github.com/cdh4u/draft-sdp-bundle/pull/54
skipping to change at page 50, line 23 skipping to change at page 50, line 28
o https://github.com/cdh4u/draft-sdp-bundle/pull/46 o https://github.com/cdh4u/draft-sdp-bundle/pull/46
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-40 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-40
o Editorial changes and technical restrictions in order to make the o Editorial changes and technical restrictions in order to make the
specification more understandable: specification more understandable:
o https://github.com/cdh4u/draft-sdp-bundle/pull/45 o https://github.com/cdh4u/draft-sdp-bundle/pull/45
o - BUNDLE address is only assigned to m- section represented by o - BUNDLE address is only assigned to m- section indicated by
BUNDLE-tag. BUNDLE-tag.
o - bundle-only attribute also used in answers and subsequent o - bundle-only attribute also used in answers and subsequent
offers. offers.
o - Answerer cannot reject, or remove, the bundled m- section that o - Answerer cannot reject, or remove, the bundled m- section that
contains the BUNDLE address. contains the BUNDLE address.
o - ICE Offer/Answer sections removed, due to duplicated o - ICE Offer/Answer sections removed, due to duplicated
information. information.
skipping to change at page 55, line 29 skipping to change at page 55, line 35
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-15 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-15
o - Editorial fix. o - Editorial fix.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-14 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-14
o - Editorial changes. o - Editorial changes.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-13 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-13
o Changes to allow a new suggested offerer BUNDLE address to be o Changes to allow a newly suggested offerer BUNDLE address to be
assigned to each bundled m- line. assigned to each bundled m- line.
o Changes based on WGLC comments from Paul Kyzivat o Changes based on WGLC comments from Paul Kyzivat
o - Editorial fixes o - Editorial fixes
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-12 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-12
o Usage of SDP 'extmap' attribute added o Usage of SDP 'extmap' attribute added
skipping to change at page 61, line 19 skipping to change at page 61, line 28
[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-15 (work in progress), November 2017. rfc5245bis-16 (work in progress), January 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-16
(work in progress), December 2016. (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.
skipping to change at page 63, line 8 skipping to change at page 63, line 14
[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
been whether, in SDP Offers and SDP Answers, the same port value been whether, in SDP Offers and SDP Answers, the same port value can
should be inserted in "m=" lines associated with a BUNDLE group, as be inserted in "m=" lines associated with a BUNDLE group, as the
the purpose of the extension is to negotiate the usage of a single purpose of the extension is to negotiate the usage of a single
transport for media specified by the "m=" sections. Issues with both transport for media specified by the "m=" sections. Issues with both
approaches, discussed in the Appendix have been raised. The outcome approaches, discussed in the Appendix have been raised. The outcome
was to specify a mechanism which uses SDP Offers with both different was to specify a mechanism which uses SDP Offers with both different
and identical port values. and identical port values.
Below are the primary issues that have been considered when defining Below are the primary issues that have been considered when defining
the "BUNDLE" grouping extension: the "BUNDLE" grouping extension:
o 1) Interoperability with existing UAs. o 1) Interoperability with existing UAs.
skipping to change at page 64, line 22 skipping to change at page 64, line 34
m=audio 20000 RTP/AVP 97 m=audio 20000 RTP/AVP 97
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
m=video 20002 RTP/AVP 97 m=video 20002 RTP/AVP 97
a=rtpmap:97 H261/90000 a=rtpmap:97 H261/90000
RFC 4961 specifies a way of doing symmetric RTP but that is a later RFC 4961 specifies a way of doing symmetric RTP but that is a later
extension to RTP and Bob can not assume that Alice supports RFC 4961. extension to RTP and Bob can not assume that Alice supports RFC 4961.
This means that Alice may be sending RTP from a different port than This means that Alice may be sending RTP from a different port than
10000 or 10002 - some implementations simply send the RTP from an 10000 or 10002 - some implementations simply send the RTP from an
ephemeral port. When Bob's endpoint receives an RTP packet, the only ephemeral port. When Bob's endpoint receives an RTP packet, the only
way that Bob knows if it should be passed to the video or audio codec way that Bob knows if the packet is to be passed to the video or
is by looking at the port it was received on. This led some SDP audio codec is by looking at the port it was received on. This led
implementations to use the fact that each "m=" section had a some SDP implementations to use the fact that each "m=" section had a
different port number to use that port number as an index to find the different port number to use that port number as an index to find the
correct m line in the SDP. As a result, some implementations that do correct m line in the SDP. As a result, some implementations that do
support symmetric RTP and ICE still use an SDP data structure where support symmetric RTP and ICE still use an SDP data structure where
SDP with "m=" sections with the same port such as: SDP with "m=" sections with the same port such as:
SDP Offer SDP Offer
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s= s=
skipping to change at page 65, line 15 skipping to change at page 65, line 30
A.2. Usage of Port Number Value Zero A.2. Usage of Port Number Value Zero
In an SDP Offer or SDP Answer, the media specified by an "m=" section In an SDP Offer or SDP Answer, the media specified by an "m=" section
can be disabled/rejected by setting the port number value to zero. can be disabled/rejected by setting the port number value to zero.
This is different from e.g., using the SDP direction attributes, This is different from e.g., using the SDP direction attributes,
where RTCP traffic will continue even if the SDP "inactive" attribute where RTCP traffic will continue even if the SDP "inactive" attribute
is indicated for the associated "m=" section. is indicated for the associated "m=" section.
If each "m=" section associated with a BUNDLE group would contain If each "m=" section associated with a BUNDLE group would contain
different port values, and one of those port values would be used for different port values, and one of those port values would be used for
a BUNDLE address associated with the BUNDLE group, problems would a BUNDLE address:port associated with the BUNDLE group, problems
occur if an endpoint wants to disable/reject the "m=" section would occur if an endpoint wants to disable/reject the "m=" section
associated with that port, by setting the port value to zero. After associated with that port, by setting the port value to zero. After
that, no "m=" section would contain the port value which is used for that, no "m=" section would contain the port value which is used for
the BUNDLE address. In addition, it is unclear what would happen to the BUNDLE address:port. In addition, it is unclear what would
the ICE candidates associated with the "m=" section, as they are also happen to the ICE candidates associated with the "m=" section, as
used for the BUNDLE address. they are also used for the BUNDLE address:port.
A.3. B2BUA And Proxy Interoperability A.3. B2BUA And Proxy Interoperability
Some back to back user agents may be configured in a mode where if Some back to back user agents may be configured in a mode where if
the incoming call leg contains an SDP attribute the B2BUA does not the incoming call leg contains an SDP attribute the B2BUA does not
understand, the B2BUA still generates that SDP attribute in the Offer understand, the B2BUA still generates that SDP attribute in the Offer
for the outgoing call leg. Consider a B2BUA that did not understand for the outgoing call leg. Consider a B2BUA that did not understand
the SDP "rtcp" attribute, defined in RFC 3605, yet acted this way. the SDP "rtcp" attribute, defined in RFC 3605, yet acted this way.
Further assume that the B2BUA was configured to tear down any call Further assume that the B2BUA was configured to tear down any call
where it did not see any RTCP for 5 minutes. In this case, if the where it did not see any RTCP for 5 minutes. In this case, if the
 End of changes. 170 change blocks. 
359 lines changed or deleted 364 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/