rfc9143.original   rfc9143.txt 
MMUSIC Working Group C. Holmberg Internet Engineering Task Force (IETF) C. Holmberg
Internet-Draft Ericsson Request for Comments: 9143 Ericsson
Obsoletes: 8843 (if approved) H. Alvestrand Obsoletes: 8843 H. Alvestrand
Updates: 3264, 5888, 7941 (if approved) Google Updates: 3264, 5888, 7941 Google
Intended status: Standards Track C. Jennings Category: Standards Track C. Jennings
Expires: 8 June 2022 Cisco ISSN: 2070-1721 Cisco
5 December 2021 February 2022
Negotiating Media Multiplexing Using the Session Description Protocol Negotiating Media Multiplexing Using the Session Description Protocol
(SDP) (SDP)
draft-ietf-mmusic-rfc8843bis-09
Abstract Abstract
This specification defines a new Session Description Protocol (SDP) This specification defines a new Session Description Protocol (SDP)
Grouping Framework extension called 'BUNDLE'. The extension can be Grouping Framework extension called 'BUNDLE'. The extension can be
used with the SDP offer/answer mechanism to negotiate the usage of a used 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
bundled media. The "m=" sections that use the BUNDLE transport form as "bundled media". The "m=" sections that use the BUNDLE transport
a BUNDLE group. form a BUNDLE group.
This specification defines a new RTP Control Protocol (RTCP) Source This specification defines a new RTP Control Protocol (RTCP) Source
Description (SDES) item and a new RTP header extension. Description (SDES) item and a new RTP header extension.
This specification updates RFCs 3264, 5888, and 7941. This specification updates RFCs 3264, 5888, and 7941.
This specification obsoletes RFC 8843. This specification obsoletes RFC 8843.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 8 June 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9143.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
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
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Background
1.2. BUNDLE Mechanism . . . . . . . . . . . . . . . . . . . . 4 1.2. BUNDLE Mechanism
1.3. Protocol Extensions . . . . . . . . . . . . . . . . . . . 5 1.3. Protocol Extensions
1.4. Changes from RFC 8843 . . . . . . . . . . . . . . . . . . 6 1.4. Changes from RFC 8843
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Conventions
4. Applicability Statement . . . . . . . . . . . . . . . . . . . 8 4. Applicability Statement
5. SDP Grouping Framework BUNDLE Extension . . . . . . . . . . . 8 5. SDP Grouping Framework BUNDLE Extension
6. SDP 'bundle-only' Attribute . . . . . . . . . . . . . . . . . 9 6. SDP 'bundle-only' Attribute
7. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 10 7. SDP Offer/Answer Procedures
7.1. Generic SDP Considerations . . . . . . . . . . . . . . . 11 7.1. Generic SDP Considerations
7.1.1. Connection Data ("c=") . . . . . . . . . . . . . . . 11 7.1.1. Connection Data ("c=")
7.1.2. Bandwidth ("b=") . . . . . . . . . . . . . . . . . . 11 7.1.2. Bandwidth ("b=")
7.1.3. Attributes ("a=") . . . . . . . . . . . . . . . . . . 11 7.1.3. Attributes ("a=")
7.2. Generating the Initial BUNDLE offer . . . . . . . . . . . 12 7.2. Generating the Initial BUNDLE Offer
7.2.1. Suggesting the Offerer-Tagged 'm=' Section . . . . . 13 7.2.1. Suggesting the Offerer-Tagged "m=" Section
7.2.2. Example: Initial BUNDLE offer . . . . . . . . . . . . 14 7.2.2. Example: Initial BUNDLE Offer
7.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 15 7.3. Generating the SDP Answer
7.3.1. Answerer Selection of Tagged 'm=' Sections . . . . . 17 7.3.1. Answerer Selection of Tagged "m=" Sections
7.3.2. Moving a Media Description Out of a BUNDLE Group . . 17 7.3.2. Moving a Media Description Out of a BUNDLE Group
7.3.3. Rejecting a Media Description in a BUNDLE Group . . . 18 7.3.3. Rejecting a Media Description in a BUNDLE Group
7.3.4. Example: SDP Answer . . . . . . . . . . . . . . . . . 19 7.3.4. Example: SDP Answer
7.3.5. RFC 8843 Considerations . . . . . . . . . . . . . . . 20 7.3.5. RFC 8843 Considerations
7.4. Offerer Processing of the SDP Answer . . . . . . . . . . 20 7.4. Offerer Processing of the SDP Answer
7.4.1. RFC 8843 Considerations . . . . . . . . . . . . . . . 21 7.4.1. RFC 8843 Considerations
7.5. Modifying the Session . . . . . . . . . . . . . . . . . . 22 7.5. Modifying the Session
7.5.1. Adding a Media Description to a BUNDLE Group . . . . 22 7.5.1. Adding a Media Description to a BUNDLE Group
7.5.2. Moving a Media Description Out of a BUNDLE Group . . 23 7.5.2. Moving a Media Description Out of a BUNDLE Group
7.5.3. Disabling a Media Description in a BUNDLE Group . . . 23 7.5.3. Disabling a Media Description in a BUNDLE Group
7.6. 3PCC Considerations . . . . . . . . . . . . . . . . . . . 24 7.6. 3PCC Considerations
8. Protocol Identification . . . . . . . . . . . . . . . . . . . 24 8. Protocol Identification
8.1. STUN, DTLS, and SRTP . . . . . . . . . . . . . . . . . . 25 8.1. STUN, DTLS, and SRTP
9. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 25 9. RTP Considerations
9.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 25 9.1. Single RTP Session
9.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . . 26 9.1.1. Payload Type (PT) Value Reuse
9.2. Associating RTP/RTCP Streams with the Correct SDP Media 9.2. Associating RTP/RTCP Streams with the Correct SDP Media
Description . . . . . . . . . . . . . . . . . . . . . . . 27 Description
9.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . . 33 9.3. RTP/RTCP Multiplexing
9.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . 33 9.3.1. SDP Offer/Answer Procedures
10. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 35 10. ICE Considerations
11. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 36 11. DTLS Considerations
12. RTP Header Extensions Consideration . . . . . . . . . . . . . 37 12. RTP Header Extensions Consideration
13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 37 13. Updates to RFC 3264
13.1. Original Text from RFC 3264, Section 5.1, 2nd 13.1. Original Text from RFC 3264, Section 5.1, Paragraph 2
Paragraph . . . . . . . . . . . . . . . . . . . . . . . 37 13.2. New Text Replacing RFC 3264, Section 5.1, Paragraph 2
13.2. New Text Replacing RFC 3264, Section 5.1, 2nd 13.3. Original Text from RFC 3264, Section 8.4, Paragraph 6
Paragraph . . . . . . . . . . . . . . . . . . . . . . . 38 13.4. New Text Replacing RFC 3264, Section 8.4, Paragraph 6
13.3. Original Text from RFC 3264, Section 8.4, 6th 14. Update to RFC 5888
Paragraph . . . . . . . . . . . . . . . . . . . . . . . 38 14.1. Original Text from RFC 5888, Section 9.2, Paragraph 3
13.4. New Text Replacing RFC 3264, Section 8.4, 6th 14.2. New Text Replacing RFC 5888, Section 9.2, Paragraph 3
Paragraph . . . . . . . . . . . . . . . . . . . . . . . 38 15. RTP/RTCP Extensions for identification-tag Transport
14. Update to RFC 5888 . . . . . . . . . . . . . . . . . . . . . 39 15.1. RTCP MID SDES Item
14.1. Original Text from RFC 5888, Section 9.2, 3rd 15.2. RTP SDES Header Extension for MID
Paragraph . . . . . . . . . . . . . . . . . . . . . . . 39 16. IANA Considerations
14.2. New Text Replacing RFC 5888, Section 9.2, 3rd 16.1. SDES Item
Paragraph . . . . . . . . . . . . . . . . . . . . . . . 39 16.2. RTP SDES Header Extension URI
15. RTP/RTCP Extensions for identification-tag Transport . . . . 39 16.3. SDP Attribute
15.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 40 16.4. SDP Group Semantics
15.2. RTP SDES Header Extension For MID . . . . . . . . . . . 41 17. Security Considerations
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 18. Examples
16.1. New SDES Item . . . . . . . . . . . . . . . . . . . . . 41 18.1. Example: Tagged "m=" Section Selections
16.2. New RTP SDES Header Extension URI . . . . . . . . . . . 42 18.2. Example: BUNDLE Group Rejected
16.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 42
16.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 43
17. Security Considerations . . . . . . . . . . . . . . . . . . . 43
18. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 44
18.1. Example: Tagged "m=" Section Selections . . . . . . . . 44
18.2. Example: BUNDLE Group Rejected . . . . . . . . . . . . . 46
18.3. Example: Offerer Adds a Media Description to a BUNDLE 18.3. Example: Offerer Adds a Media Description to a BUNDLE
Group . . . . . . . . . . . . . . . . . . . . . . . . . 47 Group
18.4. Example: Offerer Moves a Media Description Out of a BUNDLE 18.4. Example: Offerer Moves a Media Description Out of a BUNDLE
Group . . . . . . . . . . . . . . . . . . . . . . . . . 49 Group
18.5. Example: Offerer Disables a Media Description within a 18.5. Example: Offerer Disables a Media Description within a
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 51 BUNDLE Group
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 19. References
19.1. Normative References . . . . . . . . . . . . . . . . . . 53 19.1. Normative References
19.2. Informative References . . . . . . . . . . . . . . . . . 55 19.2. Informative References
Appendix A. Design Considerations . . . . . . . . . . . . . . . 57 Appendix A. Design Considerations
A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 57 A.1. UA Interoperability
A.2. Usage of Port Number Value Zero . . . . . . . . . . . . . 59 A.2. Usage of Port Number Value Zero
A.3. B2BUA and Proxy Interoperability . . . . . . . . . . . . 59 A.3. B2BUA and Proxy Interoperability
A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 60 A.3.1. Traffic Policing
A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 60 A.3.2. Bandwidth Allocation
A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 60 A.4. Candidate Gathering
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 61 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 Authors' Addresses
1. Introduction 1. Introduction
1.1. Background 1.1. Background
When the SDP offer/answer mechanism [RFC3264] is used to negotiate When the SDP offer/answer mechanism [RFC3264] is used to negotiate
the establishment of multimedia communication sessions, if separate the establishment of multimedia communication sessions, if separate
transports (5-tuples) are negotiated for each individual media transports (5-tuples) are negotiated for each individual media
stream, each transport consumes additional resources (especially when stream, each transport consumes additional resources (especially when
Interactive Connectivity Establishment (ICE) [RFC8445] is used). For Interactive Connectivity Establishment (ICE) [RFC8445] is used). For
this reason, it is attractive to use a single transport for multiple this reason, it is attractive to use a single transport for multiple
media streams. media streams.
1.2. BUNDLE Mechanism 1.2. BUNDLE Mechanism
This specification defines a way to use a single transport (BUNDLE This specification defines a way to use a single transport (BUNDLE
transport) for sending and receiving media (bundled media) described transport) for sending and receiving media (bundled media) described
by multiple SDP media descriptions ("m=" sections). The address:port by multiple SDP media descriptions ("m=" sections). The address:port
combination used by an endpoint for sending and receiving bundled combination used by an endpoint for sending and receiving bundled
media is referred to as the BUNDLE address:port. The set of SDP media is referred to as the "BUNDLE address:port". The set of SDP
attributes that are applied to each "m=" section within a BUNDLE attributes that are applied to each "m=" section within a BUNDLE
group is referred to as BUNDLE attributes. The same BUNDLE transport group is referred to as "BUNDLE attributes". The same BUNDLE
is used for sending and receiving bundled media, which means that the transport is used for sending and receiving bundled media, which
symmetric Real-time Transport Protocol (RTP) mechanism [RFC4961] is means that the symmetric Real-time Transport Protocol (RTP) mechanism
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.
In addition, the offerer and answerer [RFC3264] use the BUNDLE In addition, the offerer and answerer [RFC3264] use the BUNDLE
extension to negotiate the BUNDLE addresses:ports (offerer BUNDLE extension to negotiate the BUNDLE addresses:ports (offerer BUNDLE
address:port and answerer BUNDLE address:port) and the set of BUNDLE address:port and answerer BUNDLE address:port) and the set of BUNDLE
attributes (offerer BUNDLE attributes and answerer BUNDLE attributes) attributes (offerer BUNDLE attributes and answerer BUNDLE attributes)
that will be applied to each "m=" section within the BUNDLE group. that will be applied to each "m=" section within the BUNDLE group.
The use of a BUNDLE transport allows the usage of a single set of ICE The use of a BUNDLE transport allows the usage of a single set of ICE
[RFC8445] candidates for the whole BUNDLE group. candidates [RFC8445] for the whole BUNDLE group.
A given BUNDLE address:port MUST only be associated with a single A given BUNDLE address:port MUST only be associated with a single
BUNDLE group. If an SDP offer or SDP answer (hereafter referred to BUNDLE group. If an SDP offer or SDP answer (hereafter referred to
as "offer" and "answer") contains multiple BUNDLE groups, the as "offer" and "answer") contains multiple BUNDLE groups, the
procedures in this specification apply to each group independently. procedures in this specification apply to each group independently.
All RTP-based bundled media associated with a given BUNDLE group All RTP-based bundled media associated with a given BUNDLE group
belong to a single RTP session [RFC3550]. 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 assign a unique without an SDP 'group:BUNDLE' attribute and assign a unique
address:port to each "m=" section within an offer and answer, address:port to each "m=" section within an offer and answer,
according to the procedures in [RFC3264] and [RFC4566]. according to the procedures in [RFC3264] and [RFC4566].
1.3. Protocol Extensions 1.3. Protocol Extensions
In addition to defining the new SDP Grouping Framework extension, In addition to defining the new SDP Grouping Framework extension,
this specification defines the following protocol extensions and RFC this specification defines the following protocol extensions and
updates. This specification: makes the following updates to RFCs. This specification:
* defines a new SDP attribute, 'bundle-only', which can be used to * defines a new SDP attribute, 'bundle-only', which can be used to
request that a specific "m=" section (and the associated media) be request that a specific "m=" section (and the associated media) be
used only if kept within a BUNDLE group. used only if kept within a BUNDLE group.
* updates RFC 3264 [RFC3264], to also allow assigning a zero port * updates RFC 3264 [RFC3264] to also allow assigning a zero port
value to an "m=" section in cases where the media described by the value to an "m=" section in cases where the media described by the
"m=" section is not disabled or rejected. "m=" section is not disabled or rejected.
* defines a new RTCP [RFC3550] SDES item, 'MID', and a new RTP SDES * defines a new RTCP [RFC3550] SDES item, Media Identification
header extension that can be used to associate RTP streams with ('MID'), and a new RTP SDES header extension that can be used to
"m=" sections. associate RTP streams with "m=" sections.
* updates [RFC7941] by adding an exception, for the MID RTP header * updates [RFC7941] by adding an exception, for the MID RTP header
extension, to the requirement regarding protection of an SDES RTP extension, to the requirement regarding protection of an SDES RTP
header extension carrying an SDES item for the MID RTP header header extension carrying an SDES item for the MID RTP header
extension. extension.
* updates [RFC5888] by allowing an SDP 'group' attribute to contain * updates [RFC5888] by allowing an SDP 'group' attribute to contain
an identification-tag that identifies an "m=" section with the an identification-tag that identifies an "m=" section with the
port value set to zero. port value set to zero.
1.4. Changes from RFC 8843 1.4. Changes from RFC 8843
When RFC 8843 and [RFC8829] were published an inconsistency between When [RFC8843] and [RFC8829] were published, an inconsistency between
the specifications was identified. The procedures regarding the specifications was identified. The procedures regarding
assigning the port value to a bundled "m=" section in an answer assigning the port value to a bundled "m=" section in an answer
(initial or subsequent) and a subsequent offer were inconsistent. (initial or subsequent) and a subsequent offer were inconsistent.
This specification removes the inconsistency by aligning the port This specification removes the inconsistency by aligning the port
value assignment procedure with the procedure in RFC 8829. value assignment procedure with the procedure in [RFC8829].
In addition, this document implements the following erratas: 6431, In addition, this document implements changes from the following
6437 errata reports: [Err6431], [Err6437].
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 referred to as "m=" sections. Each "m=" section is represented by
by an SDP "m=" line and zero or more SDP attributes associated an SDP "m=" line and zero or more SDP attributes associated with
with the "m=" line. A local address:port combination is the "m=" line. A local address:port combination is assigned to
assigned to each "m=" section. each "m=" section.
5-tuple: A collection of the following values: source address, 5-tuple: A collection of the following values: source address,
source port, destination address, destination port, and source port, destination address, destination port, and transport-
transport-layer protocol. layer protocol.
Unique address:port: An address:port combination that is assigned Unique address:port: An address:port combination that is assigned to
to only 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 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 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.
Suggested offerer-tagged "m=" section: The bundled "m=" section Suggested offerer-tagged "m=" section: The bundled "m=" section
identified by the offerer BUNDLE-tag in an initial BUNDLE identified by the offerer BUNDLE-tag in an initial BUNDLE offer,
offer, before a BUNDLE group has been negotiated. before a BUNDLE group has been negotiated.
Offerer-tagged "m=" section: The bundled "m=" section identified Offerer-tagged "m=" section: The bundled "m=" section identified by
by the offerer BUNDLE-tag in a subsequent offer. The "m=" the offerer BUNDLE-tag in a subsequent offer. The "m=" section
section contains characteristics (offerer BUNDLE address:port contains characteristics (offerer BUNDLE address:port and offerer
and offerer BUNDLE attributes) that are applied to each "m=" BUNDLE attributes) that are applied to each "m=" section within
section within the BUNDLE group. the BUNDLE group.
Answerer-tagged "m=" section: The bundled "m=" section identified Answerer-tagged "m=" section: The bundled "m=" section identified by
by the answerer BUNDLE-tag in an answer (initial BUNDLE answer the answerer BUNDLE-tag in an answer (initial BUNDLE answer or
or subsequent). The "m=" section contains characteristics subsequent). The "m=" section contains characteristics (answerer
(answerer BUNDLE address:port and answerer BUNDLE attributes) BUNDLE address:port and answerer BUNDLE attributes) that are
that are applied to each "m=" section within the BUNDLE group. applied to each "m=" section within the BUNDLE group.
BUNDLE address:port: An address:port combination that an endpoint BUNDLE address:port: An address:port combination that an endpoint
uses for sending and receiving bundled media. uses for sending and receiving bundled media.
Offerer BUNDLE address:port: The address:port combination used by Offerer BUNDLE address:port: The address:port combination used by
the offerer for sending and receiving media. the offerer for sending and receiving media.
Answerer BUNDLE address:port: The address:port combination used Answerer BUNDLE address:port: The address:port combination used by
by the answerer for sending and receiving media. the answerer for sending and receiving media.
BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing category BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing category SDP
SDP attributes. Once a BUNDLE group has been created, the attributes. Once a BUNDLE group has been created, the attribute
attribute values apply to each bundled "m=" section within the values apply to each bundled "m=" section within the BUNDLE group.
BUNDLE group.
Offerer BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing Offerer BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing
category SDP attributes included in the offerer-tagged "m=" category SDP attributes included in the offerer-tagged "m="
section. section.
Answerer BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing Answerer BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing
category SDP attributes included in the answerer-tagged "m=" category SDP attributes included in the answerer-tagged "m="
section. section.
BUNDLE transport: The transport (5-tuple) used by all media BUNDLE transport: The transport (5-tuple) used by all media
described by the "m=" sections within a BUNDLE group. described by the "m=" sections within a BUNDLE group.
BUNDLE group: A set of bundled "m=" sections, created using an BUNDLE group: A set of bundled "m=" sections, created using an SDP
SDP offer/answer exchange, that uses a single BUNDLE transport, offer/answer exchange, that uses a single BUNDLE transport and a
and a single set of BUNDLE attributes, for sending and single set of BUNDLE attributes for sending and receiving all
receiving all media (bundled media) described by the set of media (bundled media) described by the set of "m=" sections. The
"m=" sections. The same BUNDLE transport is used for sending same BUNDLE transport is used for sending and receiving bundled
and receiving bundled media. media.
Bundled "m=" section: An "m=" section, whose identification-tag Bundled "m=" section: An "m=" section, whose identification-tag is
is placed in an SDP 'group:BUNDLE' attribute identification-tag placed in an SDP 'group:BUNDLE' attribute identification-tag list
list in an offer or answer. in an offer or answer.
Bundle-only "m=" section: A bundled "m=" section that contains an Bundle-only "m=" section: A bundled "m=" section that contains an
SDP 'bundle-only' attribute. SDP 'bundle-only' attribute.
Bundled media: All media associated with a given BUNDLE group. Bundled media: All media associated with a given BUNDLE group.
Initial BUNDLE offer: The first offer, within an SDP session Initial BUNDLE offer: The first offer, within an SDP session (e.g.,
(e.g., a SIP dialog when SIP [RFC3261] is used to carry SDP), a SIP dialog when SIP [RFC3261] is used to carry SDP), in which
in which the offerer indicates that it wants to negotiate a the offerer indicates that it wants to negotiate a given BUNDLE
given BUNDLE group. group.
Initial BUNDLE answer: The answer to an initial BUNDLE offer in Initial BUNDLE answer: The answer to an initial BUNDLE offer in
which the offerer indicates that it wants to negotiate a BUNDLE which the offerer indicates that it wants to negotiate a BUNDLE
group, and the answerer accepts the creation of the BUNDLE group, and the answerer accepts the creation of the BUNDLE group.
group. The BUNDLE group is created once the answerer sends the The BUNDLE group is created once the answerer sends the initial
initial BUNDLE answer. BUNDLE answer.
Subsequent offer: An offer that contains a BUNDLE group that has Subsequent offer: An offer that 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.
Subsequent answer: An answer to a subsequent offer. Subsequent answer: An answer to a subsequent offer.
Identification-tag: A unique token value that is used to identify Identification-tag: A unique token value that is used to identify an
an "m=" section. The SDP 'mid' attribute [RFC5888] in an "m=" "m=" section. The SDP 'mid' attribute [RFC5888] in an "m="
section carries the unique identification-tag assigned to that section carries the unique identification-tag assigned to that
"m=" section. The session-level SDP 'group' attribute "m=" section. The session-level SDP 'group' attribute [RFC5888]
[RFC5888] carries a list of identification-tags, identifying carries a list of identification-tags, identifying the "m="
the "m=" sections associated with that particular 'group' sections associated with that particular 'group' attribute.
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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
4. Applicability Statement 4. Applicability Statement
skipping to change at page 9, line 29 skipping to change at line 395
The multiplexing category [RFC8859] for the 'group:BUNDLE' attribute The multiplexing category [RFC8859] for the 'group:BUNDLE' attribute
is 'NORMAL'. is 'NORMAL'.
Section 7 defines the detailed SDP offer/answer procedures for the Section 7 defines the detailed SDP offer/answer procedures for the
BUNDLE extension. BUNDLE extension.
6. SDP 'bundle-only' Attribute 6. SDP 'bundle-only' Attribute
This section defines a new SDP media-level attribute [RFC4566], This section defines a new SDP media-level attribute [RFC4566],
'bundle-only'. 'bundle-only' is a property attribute [RFC4566] and 'bundle-only'. 'bundle-only' is a property attribute [RFC4566];
hence has no value. hence, it has no value.
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 in an offer, the extension always rejects a bundled "m=" section in an offer, the
offerer can assign a zero port value to the "m=" section. According offerer can assign a zero port value to the "m=" section. According
to [RFC3264], an answerer will reject such an "m=" section. By to [RFC3264], an answerer will reject such an "m=" section. By
including an SDP 'bundle-only' attribute in a bundled "m=" section, including an SDP 'bundle-only' attribute in a bundled "m=" section,
the offerer can request that the answerer accepts the "m=" section the offerer can request that the answerer accept the "m=" section
only if the answerer supports the BUNDLE extension and if the only if the answerer supports the BUNDLE extension and if the
answerer keeps the "m=" section within the associated BUNDLE group. answerer keeps the "m=" section within the associated BUNDLE group.
Name: bundle-only Name: bundle-only
Value: N/A Value: N/A
Usage Level: media Usage Level: media
Charset Dependent: no Charset Dependent: no
Example: a=bundle-only Example: a=bundle-only
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. If an offerer or answerer receives a 'bundle-only' unspecified. If an offerer or answerer receives a 'bundle-only'
attribute in a non-bundled "m=" section the offerer or answerer MUST attribute in a non-bundled "m=" section, the offerer or answerer MUST
discard the attribute. discard the attribute.
Section 7 defines the detailed SDP offer/answer procedures for the Section 7 defines the detailed SDP offer/answer procedures for the
'bundle-only' attribute. 'bundle-only' attribute.
7. SDP Offer/Answer Procedures 7. SDP Offer/Answer Procedures
This section describes the SDP offer/answer [RFC3264] procedures for: This section describes the SDP offer/answer [RFC3264] procedures for:
* Negotiating a BUNDLE group; * Negotiating a BUNDLE group;
skipping to change at page 10, line 34 skipping to change at line 446
* Moving an "m=" section out of a BUNDLE group; and * Moving an "m=" section out of a BUNDLE group; and
* Disabling an "m=" section within a BUNDLE group. * 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 addresses:ports, rejected by the answerer, the previously negotiated addresses:ports,
SDP parameters, and characteristics (including those associated with SDP parameters, and characteristics (including those associated with
a BUNDLE group) apply. Hence, if an offerer generates an offer in a BUNDLE group) apply. Hence, if an offerer generates an offer in
order to negotiate a BUNDLE group, and the answerer rejects the order to negotiate a BUNDLE group and the answerer rejects the offer,
offer, the BUNDLE group is not created. the BUNDLE group is not created.
The procedures in this section are independent of the media type or The procedures in this section are independent of the media type or
"m=" line proto value assigned to a bundled "m=" section. Section 6 "m=" line proto value assigned to a bundled "m=" section. 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 9 defines additional considerations for only' attribute. Section 9 defines additional considerations for
RTP-based media. Section 10 defines additional considerations for RTP-based media. Section 10 defines additional considerations for
the usage of the ICE [RFC8445] mechanism. the usage of the ICE mechanism [RFC8445].
Offers and answers can contain multiple BUNDLE groups. The Offers and answers can contain multiple BUNDLE groups. The
procedures in this section apply independently to a given BUNDLE procedures in this section apply independently to a given BUNDLE
group. group.
7.1. Generic SDP Considerations 7.1. Generic SDP Considerations
This section describes generic restrictions associated with the usage This section describes generic restrictions associated with the usage
of SDP parameters within a BUNDLE group. It also describes how to of SDP parameters within a BUNDLE group. It also describes how to
calculate a value for the whole BUNDLE group, when parameter and calculate a value for the whole BUNDLE group, when parameter and
skipping to change at page 11, line 21 skipping to change at line 476
7.1.1. Connection Data ("c=") 7.1.1. Connection Data ("c=")
The "c=" line nettype value [RFC4566] associated with a bundled "m=" The "c=" line nettype value [RFC4566] associated with a bundled "m="
section MUST be 'IN'. section MUST be 'IN'.
The "c=" line addrtype value [RFC4566] associated with a bundled "m=" The "c=" line addrtype value [RFC4566] associated with a bundled "m="
section MUST be 'IP4' or 'IP6'. The same value MUST be associated section MUST be 'IP4' or 'IP6'. The same value MUST be associated
with each "m=" section. with each "m=" section.
NOTE: Extensions to this specification can specify usage of the NOTE: Extensions to this specification can specify usage of the
BUNDLE mechanism for other nettype and addrtype values than the ones BUNDLE mechanism for other nettype and addrtype values than the
listed above. ones listed above.
7.1.2. Bandwidth ("b=") 7.1.2. Bandwidth ("b=")
An offerer and answerer MUST use the rules and restrictions defined An offerer and answerer MUST use the rules and restrictions defined
in [RFC8859] for associating the SDP bandwidth ("b=") line with in [RFC8859] for associating the SDP bandwidth ("b=") line with
bundled "m=" sections. bundled "m=" sections.
7.1.3. Attributes ("a=") 7.1.3. Attributes ("a=")
An offerer and answerer MUST include SDP attributes in every bundled An offerer and answerer MUST include SDP attributes in every bundled
skipping to change at page 12, line 5 skipping to change at line 502
* In the initial BUNDLE offer, the offerer MUST NOT include * In the initial BUNDLE offer, the offerer MUST NOT include
IDENTICAL and TRANSPORT multiplexing category SDP attributes IDENTICAL and TRANSPORT multiplexing category SDP attributes
(BUNDLE attributes) in bundle-only "m=" sections. The offerer (BUNDLE attributes) in bundle-only "m=" sections. The offerer
MUST include such attributes in all other bundled "m=" sections. MUST include such attributes in all other bundled "m=" sections.
In the initial BUNDLE offer, each bundled "m=" line can contain a In the initial BUNDLE offer, each bundled "m=" line can contain a
different set of BUNDLE attributes and attribute values. Once the different set of BUNDLE attributes and attribute values. Once the
offerer-tagged "m=" section has been selected, the BUNDLE offerer-tagged "m=" section has been selected, the BUNDLE
attributes contained in the offerer-tagged "m=" section will apply attributes contained in the offerer-tagged "m=" section will apply
to each bundled "m=" section within the BUNDLE group. to each bundled "m=" section within the BUNDLE group.
* In a subsequent offer, or in an answer (initial or subsequent), * In a subsequent offer or in an answer (initial or subsequent), the
the offerer and answerer MUST include IDENTICAL and TRANSPORT offerer and answerer MUST include IDENTICAL and TRANSPORT
multiplexing category SDP attributes (BUNDLE attributes) only in multiplexing category SDP attributes (BUNDLE attributes) only in
the tagged "m=" section (offerer-tagged "m=" section or answerer- the tagged "m=" section (offerer-tagged "m=" section or answerer-
tagged "m=" section). The offerer and answerer MUST NOT include tagged "m=" section). The offerer and answerer MUST NOT include
such attributes in any other bundled "m=" section. The BUNDLE such attributes in any other bundled "m=" section. The BUNDLE
attributes contained in the tagged "m=" section will apply to each attributes contained in the tagged "m=" section will apply to each
bundled "m=" section within the BUNDLE group. bundled "m=" section within the BUNDLE group.
* In an offer (initial BUNDLE offer or subsequent), or in an answer * In an offer (initial BUNDLE offer or subsequent) or in an answer
(initial BUNDLE answer or subsequent), the offerer and answerer (initial BUNDLE answer or subsequent), the offerer and answerer
MUST include SDP attributes from categories other than IDENTICAL MUST include SDP attributes from categories other than IDENTICAL
and TRANSPORT in each bundled "m=" section that a given attribute and TRANSPORT in each bundled "m=" section that a given attribute
applies to. Each bundled "m=" line can contain a different set of applies to. Each bundled "m=" line can contain a different set of
such attributes, and attribute values, as such attributes only such attributes and attribute values, as such attributes only
apply to the given bundled "m=" section in which they are apply to the given bundled "m=" section in which they are
included. included.
NOTE: A consequence of the rules above is that media-specific NOTE: A consequence of the rules above is that media-specific
IDENTICAL and TRANSPORT multiplexing category SDP attributes that are IDENTICAL and TRANSPORT multiplexing category SDP attributes that
applicable only to some of the bundled "m=" sections within the are applicable only to some of the bundled "m=" sections within
BUNDLE group might appear in the tagged "m=" section for which they the BUNDLE group might appear in the tagged "m=" section for which
are not applicable. For instance, the tagged "m=" section might they are not applicable. For instance, the tagged "m=" section
contain an SDP 'rtcp-mux' attribute even if the tagged "m=" section might contain an SDP 'rtcp-mux' attribute even if the tagged "m="
does not describe RTP-based media (but another bundled "m=" section section does not describe RTP-based media (but another bundled
within the BUNDLE group does describe RTP-based media). "m=" section within the BUNDLE group does describe RTP-based
media).
7.2. Generating the Initial BUNDLE offer 7.2. Generating the Initial BUNDLE Offer
The procedures in this section apply to the first offer, within an The procedures in this section apply to the first offer within an SDP
SDP session (e.g., a SIP dialog when SIP [RFC3261] is used to carry session (e.g., a SIP dialog when SIP [RFC3261] is used to carry SDP)
SDP), in which the offerer indicates that it wants to negotiate a in which the offerer indicates that it wants to negotiate a given
given BUNDLE group. This could occur in the initial offer, or in a BUNDLE group. This could occur in the initial offer, or in a
subsequent offer, of the SDP session. subsequent offer, of the SDP session.
When an offerer generates an initial BUNDLE offer, in order to When an offerer generates an initial BUNDLE offer, in order to
negotiate a BUNDLE group, it MUST: negotiate a BUNDLE group, it MUST:
* Assign a unique address:port to each bundled "m=" section, * Assign a unique address:port to each bundled "m=" section
following the procedures in [RFC3264], excluding any bundle-only following the procedures in [RFC3264], excluding any bundle-only
"m=" sections (see below); "m=" sections (see below);
* Pick a bundled "m=" section as the suggested offerer-tagged "m=" * Pick a bundled "m=" section as the suggested offerer-tagged "m="
(Section 7.2.1); (Section 7.2.1);
* Include SDP attributes in the bundled "m=" sections following the * Include SDP attributes in the bundled "m=" sections following the
rules in Section 7.1.3; rules in Section 7.1.3;
* Include an SDP 'group:BUNDLE' attribute in the offer; and * Include an SDP 'group:BUNDLE' attribute in the offer; and
* Place the identification-tag of each bundled "m=" section in the * Place the identification-tag of each bundled "m=" section in the
SDP 'group:BUNDLE' attribute identification-tag list. The offerer SDP 'group:BUNDLE' attribute identification-tag list. The offerer
BUNDLE-tag indicates the suggested offerer-tagged "m=" section. BUNDLE-tag indicates the suggested offerer-tagged "m=" section.
NOTE: When the offerer assigns unique addresses:ports to multiple NOTE: When the offerer assigns unique addresses:ports 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:port, until it receives the bundled media on each unique address:port until it receives the
associated answer and finds out which bundled "m=" section (and associated answer and finds out which bundled "m=" section (and
associated address:port combination) the answerer has selected as the associated address:port combination) the answerer has selected as
offerer-tagged "m=" section. the offerer-tagged "m=" section.
If the offerer wants to request that the answerer accepts a given If the offerer wants to request that the answerer accept 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 negotiated BUNDLE group, the offerer MUST: within the negotiated BUNDLE group, the offerer MUST:
* Include an SDP 'bundle-only' attribute (Section 7.2.1) in the "m=" * Include an SDP 'bundle-only' attribute (Section 7.2.1) in the "m="
section, and section, and
* Assign a zero port value to the "m=" section. * Assign a zero port value to the "m=" section.
NOTE: If the offerer assigns a zero port value to a bundled "m=" NOTE: If the offerer assigns a zero port value to a bundled "m="
section, but does not include an SDP 'bundle-only' attribute in the section but does not include an SDP 'bundle-only' attribute in the
"m=" section, it is an indication that the offerer wants to disable "m=" section, it is an indication that the offerer wants to
the "m=" section (Section 7.5.3). disable the "m=" section (Section 7.5.3).
Sections 7.2.2 and 18.1 show an example of an initial BUNDLE offer. Sections 7.2.2 and 18.1 show an example of an initial BUNDLE offer.
7.2.1. Suggesting the Offerer-Tagged 'm=' Section 7.2.1. Suggesting the Offerer-Tagged "m=" Section
In the initial BUNDLE offer, the bundled "m=" section indicated by In the initial BUNDLE offer, the bundled "m=" section indicated by
the offerer BUNDLE-tag is the suggested offerer-tagged "m=" section. the offerer BUNDLE-tag is the suggested offerer-tagged "m=" section.
The address:port combination associated with the "m=" section will be The address:port combination associated with the "m=" section will be
used by the offerer for sending and receiving bundled media if the used by the offerer for sending and receiving bundled media if the
answerer selects the "m=" section as the offerer-tagged "m=" section answerer selects the "m=" section as the offerer-tagged "m=" section
(Section 7.3.1). In addition, if the answerer selects the "m=" (Section 7.3.1). In addition, if the answerer selects the "m="
section as the offerer-tagged "m=" section, the BUNDLE attributes section as the offerer-tagged "m=" section, the BUNDLE attributes
included in the "m=" section will be applied to each "m=" section included in the "m=" section will be applied to each "m=" section
within the negotiated BUNDLE group. within the negotiated BUNDLE group.
The offerer MUST NOT suggest a bundle-only "m=" section as the The offerer MUST NOT suggest a bundle-only "m=" section as the
offerer-tagged "m=" section. offerer-tagged "m=" section.
It is RECOMMENDED that the suggested offerer-tagged "m=" section be a It is RECOMMENDED that the suggested offerer-tagged "m=" section be a
bundled "m=" section that the offerer believes is unlikely that the bundled "m=" section which the offerer believes is unlikely to be
answerer will reject or move out of the BUNDLE group. How such rejected or moved out of the BUNDLE group by the answerer. How such
assumption is made is outside the scope of this document. an assumption is made is outside the scope of this document.
7.2.2. Example: Initial BUNDLE offer 7.2.2. Example: Initial BUNDLE Offer
The following example shows an initial BUNDLE offer. The offer The following example shows an initial BUNDLE offer. The offer
includes two "m=" sections in the offer and suggests that both "m=" includes two "m=" sections in the offer and suggests that both "m="
sections are included in a BUNDLE group. The audio "m=" section is sections be included in a BUNDLE group. The audio "m=" section is
the suggested offerer-tagged "m=" section, indicated by placing the the suggested offerer-tagged "m=" section, indicated by placing the
identification-tag associated with the "m=" section (offerer BUNDLE- identification-tag associated with the "m=" section (offerer BUNDLE-
tag) first in the SDP group:BUNDLE attribute identification-id list. tag) first in the SDP 'group:BUNDLE' attribute identification-id
list.
SDP Offer SDP Offer
v=0 v=0
o=alice 2890844526 2890844526 IN IP6 2001:db8::3 o=alice 2890844526 2890844526 IN IP6 2001:db8::3
s= s=
c=IN IP6 2001:db8::3 c=IN IP6 2001:db8::3
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
skipping to change at page 14, line 43 skipping to change at line 639
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
The following example shows an initial BUNDLE offer. The offer The following example shows an initial BUNDLE offer. The offer
includes two "m=" sections in the offer and suggests that both "m=" includes two "m=" sections in the offer and suggests that both "m="
sections are included in a BUNDLE group. The offerer includes an SDP sections are included in a BUNDLE group. The offerer includes an SDP
'bundle-only' attribute in the video "m=" section, to request that 'bundle-only' attribute in the video "m=" section to request that the
the answerer accepts the "m=" section only if the answerer supports answerer accept the "m=" section only if the answerer supports the
the BUNDLE extension and if the answerer keeps the "m=" section BUNDLE extension and if the answerer keeps the "m=" section within
within the associated BUNDLE group. The audio "m=" section is the the associated BUNDLE group. The audio "m=" section is the suggested
suggested offerer-tagged "m=" section, indicated by placing the offerer-tagged "m=" section, indicated by placing the identification-
identification-tag associated with the "m=" section (offerer BUNDLE- tag associated with the "m=" section (offerer BUNDLE-tag) first in
tag) first in the SDP group:BUNDLE attribute identification-id list. the SDP 'group:BUNDLE' attribute identification-id list.
SDP Offer SDP Offer
v=0 v=0
o=alice 2890844526 2890844526 IN IP6 2001:db8::3 o=alice 2890844526 2890844526 IN IP6 2001:db8::3
s= s=
c=IN IP6 2001:db8::3 c=IN IP6 2001:db8::3
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97 m=audio 10000 RTP/AVP 0 8 97
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
skipping to change at page 16, line 18 skipping to change at line 709
* In case of an initial BUNDLE answer, select the offerer-tagged * In case of an initial BUNDLE answer, select the offerer-tagged
"m=" section using the procedures in Section 7.3.1. In case of a "m=" section using the procedures in Section 7.3.1. In case of a
subsequent answer, the offerer-tagged "m=" section is indicated in subsequent answer, the offerer-tagged "m=" section is indicated in
the corresponding subsequent offer and MUST NOT be changed by the the corresponding subsequent offer and MUST NOT be changed by the
answerer; answerer;
* Select the answerer-tagged "m=" section (Section 7.3.1); * Select the answerer-tagged "m=" section (Section 7.3.1);
* Assign the answerer BUNDLE address:port to the answerer-tagged * Assign the answerer BUNDLE address:port to the answerer-tagged
"m=" section, and to every other bundled "m=" section within the "m=" section and to every other bundled "m=" section within the
BUNDLE group; BUNDLE group;
* Include SDP attributes in the bundled "m=" sections following the * Include SDP attributes in the bundled "m=" sections following the
rules in Section 7.1.3; rules in Section 7.1.3;
* Include an SDP 'group:BUNDLE' attribute in the answer; and * Include an SDP 'group:BUNDLE' attribute in the answer; and
* Place the identification-tag of each bundled "m=" section in the * Place the identification-tag of each bundled "m=" section in the
SDP 'group:BUNDLE' attribute identification-tag list. The SDP 'group:BUNDLE' attribute identification-tag list. The
answerer BUNDLE-tag indicates the answerer-tagged "m=" section answerer BUNDLE-tag indicates the answerer-tagged "m=" section
skipping to change at page 16, line 44 skipping to change at line 735
* Move the "m=" section out of the BUNDLE group (Section 7.3.2); or * Move the "m=" section out of the BUNDLE group (Section 7.3.2); or
* Reject the "m=" section (Section 7.3.3). * Reject the "m=" section (Section 7.3.3).
The answerer can modify the answerer BUNDLE address:port, add and The answerer can modify the answerer BUNDLE address:port, add and
remove SDP attributes, or modify SDP attribute values in a subsequent remove SDP attributes, or modify SDP attribute values in a subsequent
answer. Changes to the answerer BUNDLE address:port and the answerer answer. Changes to the answerer BUNDLE address:port and the answerer
BUNDLE attributes will be applied to each bundled "m=" section within BUNDLE attributes will be applied to each bundled "m=" section within
the BUNDLE group. the BUNDLE group.
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
"m=" section (Section 7.5.3). the "m=" section (Section 7.5.3).
7.3.1. Answerer Selection of Tagged 'm=' Sections 7.3.1. Answerer Selection of Tagged "m=" Sections
When selecting the offerer-tagged "m=" section, the answerer MUST When selecting the offerer-tagged "m=" section, the answerer MUST
first check whether the "m=" section fulfills the following criteria first check whether the "m=" section fulfills the following criteria
Section 7.2.1: (Section 7.2.1):
* The answerer will not move the "m=" section out of the BUNDLE * The answerer will not move the "m=" section out of the BUNDLE
group (Section 7.3.2); group (Section 7.3.2);
* The answerer will not reject the "m=" section (Section 7.3.3); and * The answerer will not reject the "m=" section (Section 7.3.3); and
* The "m=" section does not contain a zero port value. * 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 "m=" section as the offerer-tagged "m=" section and MUST also the "m=" section as the offerer-tagged "m=" section and MUST also
skipping to change at page 17, line 44 skipping to change at line 779
creating the answer. creating the answer.
Section 18.1 shows an example of an offerer BUNDLE address:port Section 18.1 shows an example of an offerer BUNDLE address:port
selection. selection.
Sections 7.3.4 and 18.1 show an example of an answerer-tagged "m=" Sections 7.3.4 and 18.1 show an example of an answerer-tagged "m="
section selection. section selection.
7.3.2. Moving a Media Description Out of a BUNDLE Group 7.3.2. Moving a Media Description Out of a BUNDLE Group
When an answerer generates the answer, if the answerer wants to move When an answerer generates the answer, the answerer MUST first check
a bundled "m=" section out of the negotiated BUNDLE group, the the following criteria if it wants to move a bundled "m=" section out
answerer MUST first check the following criteria: of the negotiated BUNDLE group:
* In the corresponding offer, the "m=" section is within a * In the corresponding offer, the "m=" section is within a
previously negotiated BUNDLE group, and previously negotiated BUNDLE group, and
* In the corresponding offer, the "m=" section contains an SDP * In the corresponding offer, the "m=" section contains an SDP
'bundle-only' attribute. 'bundle-only' attribute.
If either criterion above is fulfilled, the answerer cannot move the If either criterion above is fulfilled, the answerer cannot 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
reject the whole offer, reject each bundled "m=" section within the reject the whole offer, reject each bundled "m=" section within the
BUNDLE group (Section 7.3.3), or keep the "m=" section within the BUNDLE group (Section 7.3.3), or keep the "m=" section within the
BUNDLE group in the answer and later create an offer where the "m=" BUNDLE group in the answer and later create an offer where the "m="
section is moved out of the BUNDLE group (Section 7.5.2). section is moved out of the BUNDLE group (Section 7.5.2).
NOTE: One consequence of the rules above is that, once a BUNDLE group NOTE: One consequence of the rules above is that, once a BUNDLE
has been negotiated, a bundled "m=" section cannot be moved out of group has been negotiated, a bundled "m=" section cannot be moved
the BUNDLE group in an answer. Instead, an offer is needed. out of the BUNDLE group in an answer. Instead, an offer is
needed.
When the answerer generates an answer, in which it moves a bundled When the answerer generates an answer in which it moves a bundled
"m=" section out of a BUNDLE group, the answerer: "m=" section out of a BUNDLE group, the answerer:
* MUST assign a unique address:port to the "m=" section; * MUST assign a unique address:port to the "m=" section;
* MUST include any applicable SDP attribute in the "m=" section, * MUST include any applicable SDP attribute in the "m=" section
using the normal offer/answer procedures for each attribute; using the normal offer/answer procedures for each attribute;
* MUST NOT place the identification-tag associated with the "m=" * MUST NOT place the identification-tag associated with the "m="
section in the SDP 'group:BUNDLE' attribute identification-tag section in the SDP 'group:BUNDLE' attribute identification-tag
list associated with the BUNDLE group; and list associated with the BUNDLE group; and
* MUST NOT include an SDP 'bundle-only' attribute to the "m=" * MUST NOT include an SDP 'bundle-only' attribute to the "m="
section. section.
Because an answerer is not allowed to move an "m=" section from one Because an answerer is not allowed to move an "m=" section from one
skipping to change at page 19, line 5 skipping to change at line 838
* In the corresponding offer (subsequent), the "m=" section is the * In the corresponding offer (subsequent), the "m=" section is the
offerer-tagged "m=" section. offerer-tagged "m=" section.
If the criterion above is fulfilled, the answerer cannot reject the If the criterion above is fulfilled, the answerer cannot reject the
"m=" section in the answer. The answerer can reject the whole offer, "m=" section in the answer. The answerer can reject the whole offer,
reject each bundled "m=" section within the BUNDLE group, or keep the reject each bundled "m=" section within the BUNDLE group, or keep the
"m=" section within the BUNDLE group in the answer and later create "m=" section within the BUNDLE group in the answer and later create
an offer where the "m=" section is disabled within the BUNDLE group an offer where the "m=" section is disabled within the BUNDLE group
(Section 7.5.3). (Section 7.5.3).
When an answerer generates an answer, in which it rejects a bundled When an answerer generates an answer in which it rejects a bundled
"m=" section, the answerer: "m=" section, the answerer:
* MUST assign a zero port value to the "m=" section, according to * MUST assign a zero port value to the "m=" section, according to
the procedures in [RFC3264]; the procedures in [RFC3264];
* MUST NOT place the identification-tag associated with the "m=" * MUST NOT place the identification-tag associated with the "m="
section in the SDP 'group:BUNDLE' attribute identification-tag section in the SDP 'group:BUNDLE' attribute identification-tag
list associated with the BUNDLE group; and list associated with the BUNDLE group; and
* MUST NOT include an SDP 'bundle-only' attribute in the "m=" * MUST NOT include an SDP 'bundle-only' attribute in the "m="
section. section.
7.3.4. Example: SDP Answer 7.3.4. Example: SDP Answer
The example below shows an answer, based on the corresponding offer The example below shows an answer based on the corresponding offer in
in Section 7.2.2. The answerer accepts both bundled "m=" sections Section 7.2.2. The answerer accepts both bundled "m=" sections
within the created BUNDLE group. The audio "m=" section is the within the created BUNDLE group. The audio "m=" section is the
answerer-tagged "m=" section, indicated by placing the answerer-tagged "m=" section, indicated by placing the
identification-tag associated with the "m=" section (answerer BUNDLE- identification-tag associated with the "m=" section (answerer BUNDLE-
tag) first in the SDP group;BUNDLE attribute identification-id list. tag) first in the SDP 'group:BUNDLE' attribute identification-id
list.
SDP Answer SDP Answer
v=0 v=0
o=bob 2808844564 2808844564 IN IP6 2001:db8::1 o=bob 2808844564 2808844564 IN IP6 2001:db8::1
s= s=
c=IN IP6 2001:db8::1 c=IN IP6 2001:db8::1
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
skipping to change at page 20, line 7 skipping to change at line 885
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 20000 RTP/AVP 32 m=video 20000 RTP/AVP 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
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
7.3.5. RFC 8843 Considerations 7.3.5. RFC 8843 Considerations
In RFC 8843, instead of assigning the offerer BUNDLE address:port to In [RFC8843], instead of assigning the offerer BUNDLE address:port to
each "m=" section within the BUNDLE group when modifying the session each "m=" section within the BUNDLE group when modifying the session
(Section 7.5), the offerer only assigned the offerer BUNDLE (Section 7.5), the offerer only assigned the offerer BUNDLE
address:port to the offerer-tagged "m=" section. For every other address:port to the offerer-tagged "m=" section. For every other
"m=" section within the BUNDLE group, the offerer included an SDP "m=" section within the BUNDLE group, the offerer included an SDP
'bundle-only' attribute in, and assigned a zero port value to, the 'bundle-only' attribute in, and assigned a zero port value to, the
"m=" section. The way an answerer compliant to this specification "m=" section. The way an answerer compliant with this specification
processes such offer is considered an implementation issue (e.g., processes such offer is considered an implementation issue (e.g.,
based on whether the answerer needs to be backward compatible with based on whether the answerer needs to be backward compatible with
RFC 8843 compliant offerers), and is outside the scope of this offerers compliant with [RFC8843]) and is outside the scope of this
specification. The example below shows such SDP offer: specification. The example below shows such an SDP Offer:
SDP Offer SDP Offer
v=0 v=0
o=alice 2890844526 2890844526 IN IP6 2001:db8::3 o=alice 2890844526 2890844526 IN IP6 2001:db8::3
s= s=
c=IN IP6 2001:db8::3 c=IN IP6 2001:db8::3
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
skipping to change at page 21, line 6 skipping to change at line 933
7.4. Offerer Processing of the SDP Answer 7.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 (for the answer was indicated as bundled in the corresponding offer (for the
same BUNDLE group). If there is no mismatch, the offerer MUST apply same BUNDLE group). If there is no mismatch, the offerer MUST apply
the properties (BUNDLE address:port, BUNDLE attributes, etc.) of the the properties (BUNDLE address:port, BUNDLE attributes, etc.) of the
offerer-tagged "m=" section (selected by the answerer; see offerer-tagged "m=" section (selected by the answerer; see
Section 7.3.1) to each bundled "m=" section within the BUNDLE group. Section 7.3.1) to each bundled "m=" section within the BUNDLE group.
NOTE: As the answerer might reject one or more bundled "m=" sections NOTE: As the answerer might reject one or more bundled "m="
in an initial BUNDLE offer, or move a bundled "m=" section out of a sections in an initial BUNDLE offer or move a bundled "m=" section
BUNDLE group, a given bundled "m=" section in the offer might not be out of a BUNDLE group, a given bundled "m=" section in the offer
indicated as bundled in the corresponding answer. might not be indicated as bundled in the corresponding 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.
7.4.1. RFC 8843 Considerations 7.4.1. RFC 8843 Considerations
In RFC 8843, instead of assigning the answerer BUNDLE address:port to In [RFC8843], instead of assigning the answerer BUNDLE address:port
each "m=" section within the BUNDLE group when generating the SDP to each "m=" section within the BUNDLE group when generating the SDP
answer(Section 7.3), the answerer only assigned the answerer BUNDLE Answer (Section 7.3), the answerer only assigned the answerer BUNDLE
address:port to the answerer-tagged "m=" section. For every other address:port to the answerer-tagged "m=" section. For every other
"m=" section within the BUNDLE group, the answerer included an SDP "m=" section within the BUNDLE group, the answerer included an SDP
'bundle-only' attribute in, and assigned a zero port value to, the 'bundle-only' attribute in, and assigned a zero port value to, the
"m=" section. The way an offerer compliant to this specification "m=" section. The way an offerer compliant with this specification
processes such SDP answer is considered an implementation issue processes such an SDP Answer is considered an implementation issue
(e.g., based on whether the answerer needs to be backward compatible (e.g., based on whether the answerer needs to be backward compatible
with RFC 8843 compliant offerers), and is outside the scope of this with offerers compliant with [RFC8843]) and is outside the scope of
specification. The example below shows such SDP answer: this specification. The example below shows such an SDP Answer:
SDP Answer SDP Answer
v=0 v=0
o=bob 2808844564 2808844564 IN IP6 2001:db8::1 o=bob 2808844564 2808844564 IN IP6 2001:db8::1
s= s=
c=IN IP6 2001:db8::1 c=IN IP6 2001:db8::1
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
skipping to change at page 22, line 7 skipping to change at line 980
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
7.5. Modifying the Session 7.5. Modifying the Session
When a BUNDLE group has been previously negotiated, and an offerer When a BUNDLE group has been previously negotiated and an offerer
generates a subsequent offer, the offerer MUST: generates a subsequent offer, the offerer MUST:
* Pick one bundled "m=" section as the offerer-tagged "m=" section. * Pick one bundled "m=" section as the offerer-tagged "m=" section.
The offerer can pick either the "m=" section that was previously The offerer can pick either the "m=" section that was previously
selected by the answerer as the offerer-tagged "m=" section or selected by the answerer as the offerer-tagged "m=" section or
another bundled "m=" section within the BUNDLE group; another bundled "m=" section within the BUNDLE group;
* Assign a BUNDLE address:port (previously negotiated or newly * Assign a BUNDLE address:port (previously negotiated or newly
suggested) to the offerer-tagged "m=" section, and to every other suggested) to the offerer-tagged "m=" section and to every other
bundled "m=" section within the BUNDLE group; bundled "m=" section within the BUNDLE group;
* Include SDP attributes in the bundled "m=" sections following the * Include SDP attributes in the bundled "m=" sections following the
rules in Section 7.1.3; rules in Section 7.1.3;
* Include an SDP 'group:BUNDLE' attribute in the offer; and * Include an SDP 'group:BUNDLE' attribute in the offer; and
* Place the identification-tag of each bundled "m=" section in the * Place the identification-tag of each bundled "m=" section in the
SDP 'group:BUNDLE' attribute identification-tag list. The offerer SDP 'group:BUNDLE' attribute identification-tag list. The offerer
BUNDLE-tag indicates the offerer-tagged "m=" section. BUNDLE-tag indicates the offerer-tagged "m=" section.
skipping to change at page 22, line 45 skipping to change at line 1018
The offerer can modify the offerer BUNDLE address:port, add and The offerer can modify the offerer BUNDLE address:port, add and
remove SDP attributes, or modify SDP attribute values in the remove SDP attributes, or modify SDP attribute values in the
subsequent offer. Changes to the offerer BUNDLE address:port and the subsequent offer. Changes to the offerer BUNDLE address:port and the
offerer BUNDLE attributes will (if the offer is accepted by the offerer BUNDLE attributes will (if the offer is accepted by the
answerer) be applied to each bundled "m=" section within the BUNDLE answerer) be applied to each bundled "m=" section within the BUNDLE
group. group.
7.5.1. Adding a Media Description to a BUNDLE Group 7.5.1. Adding a Media Description to a BUNDLE Group
When an offerer generates a subsequent offer, in which it wants to When an offerer generates a subsequent offer in which it wants to add
add a bundled "m=" section to a previously negotiated BUNDLE group, a bundled "m=" section to a previously negotiated BUNDLE group, the
the offerer follows the procedures in Section 7.5. The offerer picks offerer follows the procedures in Section 7.5. The offerer picks
either the added "m=" section or an "m=" section previously added to either the added "m=" section or an "m=" section previously added to
the BUNDLE group as the offerer-tagged "m=" section. the BUNDLE group as the offerer-tagged "m=" section.
NOTE: As described in Section 7.3.2, the answerer cannot move the NOTE: As described in Section 7.3.2, the answerer cannot move the
added "m=" section out of the BUNDLE group in its answer. If the added "m=" section out of the BUNDLE group in its answer. If the
answerer wants to move the "m=" section out of the BUNDLE group, it answerer wants to move the "m=" section out of the BUNDLE group,
will have to first accept it into the BUNDLE group in the answer, and it will have to first accept it into the BUNDLE group in the
then send a subsequent offer where the "m=" section is moved out of answer and then send a subsequent offer where the "m=" section is
the BUNDLE group (Section 7.5.2). moved out of the BUNDLE group (Section 7.5.2).
7.5.2. Moving a Media Description Out of a BUNDLE Group 7.5.2. Moving a Media Description Out of a BUNDLE Group
When an offerer generates a subsequent offer, in which it wants to When an offerer generates a subsequent offer in which it wants to
remove a bundled "m=" section from a BUNDLE group, the offerer: remove a bundled "m=" section from a BUNDLE group, the offerer:
* MUST assign a unique address:port to the "m=" section; * MUST assign a unique address:port to the "m=" section;
* MUST include SDP attributes in the "m=" section following the * MUST include SDP attributes in the "m=" section following the
normal offer/answer rules for each attribute; normal offer/answer rules for each attribute;
* MUST NOT place the identification-tag associated with the "m=" * MUST NOT place the identification-tag associated with the "m="
section in the SDP 'group:BUNDLE' attribute identification-tag section in the SDP 'group:BUNDLE' attribute identification-tag
list associated with the BUNDLE group; and list associated with the BUNDLE group; and
* MUST NOT assign an SDP 'bundle-only' attribute to the "m=" * MUST NOT assign an SDP 'bundle-only' attribute to the "m="
section. section.
For the other bundled "m=" sections within the BUNDLE group, the For the other bundled "m=" sections within the BUNDLE group, the
offerer follows the procedures in Section 7.5. offerer follows the procedures in Section 7.5.
An offerer MUST NOT move an "m=" section from one BUNDLE group to An offerer MUST NOT move an "m=" section from one BUNDLE group to
another within a single offer. If the offerer wants to move an "m=" another within a single offer. If the offerer wants to move an "m="
section from one BUNDLE group to another, it MUST first move the section from one BUNDLE group to another, it MUST first move the
BUNDLE group out of the current BUNDLE group, and then generate a BUNDLE group out of the current BUNDLE group and then generate a
second offer where the "m=" section is added to another BUNDLE group second offer where the "m=" section is added to another BUNDLE group
(Section 7.5.1). (Section 7.5.1).
Section 18.4 shows an example of an offer for moving an "m=" section Section 18.4 shows an example of an offer for moving an "m=" section
out of a BUNDLE group. out of a BUNDLE group.
7.5.3. Disabling a Media Description in a BUNDLE Group 7.5.3. Disabling a Media Description in a BUNDLE Group
When an offerer generates a subsequent offer, in which it wants to When an offerer generates a subsequent offer in which it wants to
disable a bundled "m=" section from a BUNDLE group, the offerer: disable a bundled "m=" section from a BUNDLE group, the offerer:
* MUST assign a zero port value to the "m=" section, following the * MUST assign a zero port value to the "m=" section, following the
procedures in [RFC4566]; procedures in [RFC4566];
* MUST NOT place the identification-tag associated with the "m=" * MUST NOT place the identification-tag associated with the "m="
section in the SDP 'group:BUNDLE' attribute identification-tag section in the SDP 'group:BUNDLE' attribute identification-tag
list associated with the BUNDLE group; and list associated with the BUNDLE group; and
* MUST NOT assign an SDP 'bundle-only' attribute to the "m=" * MUST NOT assign an SDP 'bundle-only' attribute to the "m="
section. section.
For the other bundled "m=" sections within the BUNDLE group, the For the other bundled "m=" sections within the BUNDLE group, the
offerer follows the procedures in Section 7.5. offerer follows the procedures in Section 7.5.
Section 18.5 shows an example of an offer and answer for disabling an Section 18.5 shows an example of an offer and answer for disabling an
"m=" section within a BUNDLE group. "m=" section within a BUNDLE group.
7.6. 3PCC Considerations 7.6. 3PCC Considerations
In some 3rd Party Call Control (3PCC) scenarios a new session will be In some third-party call control (3PCC) scenarios, a new session will
established between an endpoint that is currently part of an ongoing be established between an endpoint that is currently part of an
session and an endpoint that is not currently part of an ongoing ongoing session and an endpoint that is not currently part of an
session. In this situation, the endpoint that is not part of a ongoing session. In this situation, the endpoint that is not part of
session, while expecting an initial offer, can receive an SDP offer a session, while expecting an initial offer, can receive an SDP offer
created as a subsequent offer. The text below describes how this can created as a subsequent offer. The text below describes how this can
occur with the Session Initiation Protocol (SIP) [RFC3261]. occur with the Session Initiation Protocol (SIP) [RFC3261].
SIP allows a User Agent Client (UAC) to send a re-INVITE request SIP [RFC3261] allows a User Agent Client (UAC) to send a re-INVITE
without an SDP body (sometimes referred to as an empty re-INVITE). request without an SDP body (sometimes referred to as an "empty re-
In such cases, the User Agent Server (UAS) will include an SDP offer INVITE"). In such cases, the User Agent Server (UAS) will include an
in the associated 200 (OK) response, and when the UAS is a part of an SDP Offer in the associated 200 (OK) response; when the UAS is a part
ongoing SIP session, this offer will be a subsequent offer. This of an ongoing SIP session, this offer will be a subsequent offer.
offer will be received by the 3PCC controller (UAC) and then This offer will be received by the 3PCC controller (UAC) and then
forwarded to another User Agent (UA). When that UA is not part of an forwarded to another User Agent (UA). When that UA is not part of an
ongoing SIP session, as noted above, it will process the offer as an ongoing SIP session, as noted above, it will process the offer as an
initial SDP offer. initial SDP offer.
When the BUNDLE mechanism is used, an initial BUNDLE offer is When the BUNDLE mechanism is used, an initial BUNDLE offer is
constructed using different rules than subsequent BUNDLE offers, and constructed using different rules than subsequent BUNDLE offers, and
it cannot be assumed that a UA is able to correctly process a it cannot be assumed that a UA is able to correctly process a
subsequent BUNDLE offer as an initial BUNDLE offer. Therefore, the subsequent BUNDLE offer as an initial BUNDLE offer. Therefore, the
3PCC controller SHOULD take actions to mitigate this problem, and 3PCC controller SHOULD take action to mitigate this problem, e.g.,
e.g., rewrite the subsequent BUNDLE offer into a valid initial BUNDLE rewrite the subsequent BUNDLE offer into a valid initial BUNDLE offer
offer (Section 7.2), before it forwards the BUNDLE offer to a UA. (Section 7.2), before it forwards the BUNDLE offer to a UA.
8. Protocol Identification 8. Protocol Identification
Each "m=" section within a BUNDLE group MUST use the same transport- Each "m=" section within a BUNDLE group MUST use the same transport-
layer protocol. If bundled "m=" sections use different upper-layer layer protocol. If bundled "m=" sections use different upper-layer
protocols on top of the transport-layer protocol, there MUST exist a protocols on top of the transport-layer protocol, there MUST exist a
publicly available specification that describes how a mechanism publicly available specification that describes how a mechanism
associates received data with the correct protocol for this associates received data with the correct protocol for this
particular protocol combination. particular 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 that describes a mechanism for associating the received specification that describes a mechanism for associating the received
data with the correct "m=" section. 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 Session Traversal Utilities for NAT (STUN), received data among the Session Traversal Utilities for NAT (STUN),
DTLS, and the Secure Real-time Transport Protocol (SRTP) (in any Datagram Transport Layer Security (DTLS), and the Secure Real-time
combination) when UDP is used as a transport-layer protocol, but it Transport Protocol (SRTP) (in any combination) when UDP is used as a
does not describe how to identify different protocols transported on transport-layer protocol, but it does not describe how to identify
DTLS. While the mechanism is generally applicable to other protocols different protocols transported on DTLS. While the mechanism is
and transport-layer protocols, any such use requires further generally applicable to other protocols and transport-layer
specification that encompasses how to multiplex multiple protocols on protocols, any such use requires further specification that
a given transport-layer protocol and how to associate received data encompasses how to multiplex multiple protocols on a given transport-
with the correct protocols. layer protocol and how to associate received data with the correct
protocols.
8.1. STUN, DTLS, and SRTP 8.1. STUN, DTLS, and SRTP
Section 5.1.2 of [RFC5764] describes a mechanism to identify the Section 5.1.2 of [RFC5764] describes a mechanism to identify the
protocol of a received packet among the STUN, DTLS, and SRTP protocol of a received packet among the STUN, DTLS, and SRTP
protocols (in any combination). If an offer or answer includes a protocols (in any combination). If an offer or answer includes a
bundled "m=" section that represents these protocols, the offerer or bundled "m=" section that represents these protocols, the offerer or
answerer MUST support the mechanism described in [RFC5764], and no answerer MUST support the mechanism described in [RFC5764], and no
explicit negotiation is required in order to indicate support and explicit negotiation is required in order to indicate support and
usage of the mechanism. usage of the mechanism.
skipping to change at page 26, line 7 skipping to change at line 1171
All RTP-based media within a single BUNDLE group belong to a single All RTP-based media within a single BUNDLE group belong to a single
RTP session [RFC3550]. RTP session [RFC3550].
Since a single BUNDLE transport is used for sending and receiving Since a single BUNDLE transport is used for sending and receiving
bundled media, the symmetric RTP mechanism [RFC4961] MUST be used for bundled media, the symmetric RTP mechanism [RFC4961] MUST be used for
RTP-based bundled media. RTP-based bundled media.
Since a single RTP session is used for each BUNDLE group, all "m=" Since a single RTP session is used for each BUNDLE group, all "m="
sections representing RTP-based media within a BUNDLE group will sections representing RTP-based media within a BUNDLE group will
share a single Synchronization Source (SSRC) numbering space share a single synchronization source (SSRC) numbering space
[RFC3550]. [RFC3550].
The following rules and restrictions apply for a single RTP session: The following rules and restrictions apply for a single RTP session:
* A specific payload type value can be used in multiple bundled "m=" * A specific payload type value can be used in multiple bundled "m="
sections only if each codec associated with the payload type sections only if each codec associated with the payload type
number shares an identical codec configuration (Section 9.1.1). number shares an identical codec configuration (Section 9.1.1).
* The proto value in each bundled RTP-based "m=" section MUST be * The proto value in each bundled RTP-based "m=" section MUST be
identical (e.g., RTP/AVPF). identical (e.g., RTP/AVPF).
* The RTP MID header extension MUST be enabled, by including an SDP * The RTP MID header extension MUST be enabled by including an SDP
'extmap' attribute [RFC8285], with a 'urn:ietf:params:rtp- 'extmap' attribute [RFC8285], with a 'urn:ietf:params:rtp-
hdrext:sdes:mid' URI value defined in this specification, in each hdrext:sdes:mid' URI value defined in this specification in each
bundled RTP-based "m=" section in every offer and answer. bundled RTP-based "m=" section in every offer and answer.
* A given SSRC MUST NOT transmit RTP packets using payload types * A given SSRC MUST NOT transmit RTP packets using payload types
that originate from different bundled "m=" sections. that originate from different bundled "m=" sections.
NOTE: The last bullet above is to avoid sending multiple media types NOTE: The last bullet above is to avoid sending multiple media
from the same SSRC. If transmission of multiple media types are done types from the same SSRC. If transmission of multiple media types
with time overlap, RTP and RTCP fail to function. Even if done in is done with time overlap, RTP and RTCP fail to function. Even if
proper sequence, this causes RTP timestamp rate switching issues done in the proper sequence, this causes RTP timestamp rate
[RFC7160]. However, once an SSRC has left the RTP session (by switching issues [RFC7160]. However, once an SSRC has left the
sending an RTCP BYE packet), that SSRC can be reused by another RTP session (by sending an RTCP BYE packet), that SSRC can be
source (possibly associated with a different bundled "m=" section) reused by another source (possibly associated with a different
after a delay of 5 RTCP reporting intervals (the delay is to ensure bundled "m=" section) after a delay of 5 RTCP reporting intervals
the SSRC has timed out, in case the RTCP BYE packet was lost (the delay is to ensure the SSRC has timed out in case the RTCP
[RFC3550]). BYE packet was lost [RFC3550]).
[RFC7657] defines Differentiated Services (Diffserv) considerations [RFC7657] defines Differentiated Services (Diffserv) considerations
for RTP-based bundled media sent using a mixture of Diffserv for RTP-based bundled media sent using a mixture of Diffserv
Codepoints. Codepoints.
9.1.1. Payload Type (PT) Value Reuse 9.1.1. Payload Type (PT) Value Reuse
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. [RFC8859] lists SDP attributes, configuration and packetization. [RFC8859] lists SDP attributes
whose attribute values are required to be identical for all codecs whose attribute values are required to be identical for all codecs
that use the same payload type value. that use the same payload type value.
9.2. Associating RTP/RTCP Streams with the Correct SDP Media 9.2. Associating RTP/RTCP Streams with the Correct SDP Media
Description 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, an to identify which RTP streams the packet relates to. However, an
RTCP packet can contain multiple SSRC fields, in the course of RTCP packet can contain multiple SSRC fields in the course of
providing feedback or reports on different RTP streams, and therefore providing feedback or reports on different RTP streams; therefore,
can be associated with multiple such streams. they can be 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 contain 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
will use for an RTP stream by using the SDP 'ssrc' attribute will use for an RTP stream by using the SDP 'ssrc' attribute
[RFC5576]. However, an offerer will not know which SSRC values the [RFC5576]. However, an offerer will not know which SSRC values the
skipping to change at page 27, line 50 skipping to change at line 1263
In order for an offerer and answerer to always be able to associate In order for an offerer and answerer to always be able to associate
an RTP stream with the correct "m=" section, the offerer and answerer an RTP stream with the correct "m=" section, the offerer and answerer
using the BUNDLE extension MUST support the mechanism defined in using the BUNDLE extension MUST support the mechanism defined in
Section 15, where the offerer and answerer insert the identification- Section 15, where the offerer and answerer insert the identification-
tag associated with an "m=" section (provided by the remote peer) tag associated with an "m=" section (provided by the remote peer)
into RTP and RTCP packets associated with a BUNDLE group. into RTP and RTCP packets associated with a BUNDLE group.
When using this mechanism, the mapping from an SSRC to an When using this mechanism, the mapping from an SSRC to an
identification-tag is carried in RTP header extensions or RTCP SDES identification-tag is carried in RTP header extensions or RTCP SDES
packets, as specified in Section 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
mappings of SSRC to identification-tag. The offerer and answerer mappings of SSRC to identification-tag. The offerer and answerer
maintain tables used for routing that are updated each time an RTP/ maintain tables used for routing that are updated each time an RTP/
RTCP packet contains new information that affects how packets are to RTCP packet contains new information that affects how packets are to
be routed. be routed.
However, some legacy implementations may not include this However, some legacy implementations may not include this
identification-tag in their RTP and RTCP traffic when using the identification-tag in their RTP and RTCP traffic when using the
BUNDLE mechanism and instead use a mechanism based on the payload BUNDLE mechanism and instead use a mechanism based on the payload
type to associate RTP streams with SDP "m=" sections. In this type to associate RTP streams with SDP "m=" sections. In this
situation, each "m=" section needs to use unique payload type values, situation, each "m=" section needs to use unique payload type values
in order for the payload type to be a reliable indicator of the in order for the payload type to be a reliable indicator of the
relevant "m=" section for the RTP stream. If an implementation fails relevant "m=" section for the RTP stream. If an implementation fails
to ensure unique payload type values, it will be impossible to to ensure unique payload type values, it will be impossible to
associate the RTP stream using that payload type value to a associate the RTP stream using that payload type value to a
particular "m=" section. Note that when using the payload type to particular "m=" section. Note that when using the payload type to
associate RTP streams with "m=" sections, an RTP stream, identified associate RTP streams with "m=" sections, an RTP stream, identified
by its SSRC, will be mapped to an "m=" section when the first packet by its SSRC, will be mapped to an "m=" section when the first packet
of that RTP stream is received, and the mapping will not be changed of that RTP stream is received, and the mapping will not be changed
even if the payload type used by that RTP stream changes. In other even if the payload type used by that RTP stream changes. In other
words, the SSRC cannot "move" to a different "m=" section simply by words, the SSRC cannot "move" to a different "m=" section simply by
skipping to change at page 29, line 16 skipping to change at line 1320
each "m=" section in the BUNDLE group and for each payload type each "m=" section in the BUNDLE group and for each payload type
configured for receiving in that "m=" section. If any payload configured for receiving in that "m=" section. If any payload
type is configured for receiving in more than one "m=" section in type is configured for receiving in more than one "m=" section in
the BUNDLE group, do not include it in the table, as it cannot be the BUNDLE group, do not include it in the table, as it cannot be
used to uniquely identify an "m=" section. used to uniquely identify an "m=" section.
* Note that for each of these tables, there can only be one mapping * Note that for each of these tables, there can only be one mapping
for any given key (MID, SSRC, or PT). In other words, the tables for any given key (MID, SSRC, or PT). In other words, the tables
are not multimaps. are not multimaps.
As "m=" sections are added or removed from the BUNDLE groups, or As "m=" sections are added or removed from the BUNDLE groups or their
their configurations are changed, the tables above MUST also be configurations are changed, the tables above MUST also be updated.
updated.
When an RTP packet is received, it MUST be delivered to the RTP When an RTP packet is received, it MUST be delivered to the RTP
stream corresponding to its SSRC. That RTP stream MUST then be stream corresponding to its SSRC. That RTP stream MUST then be
associated with the correct "m=" section within a BUNDLE group, for associated with the correct "m=" section within a BUNDLE group for
additional processing, according to the following steps: additional processing, according to the following steps:
* If the MID associated with the RTP stream is not in the table * If the MID associated with the RTP stream is not in the table
mapping a MID to an "m=" section, then the RTP stream is not mapping a MID to an "m=" section, then the RTP stream is not
decoded, and the payload data is discarded. decoded, and the payload data is discarded.
* If the packet has a MID, and the packet's extended sequence number * If the packet has a MID and the packet's extended sequence number
is greater than that of the last MID update, as discussed in is greater than that of the last MID update, as discussed in
[RFC7941], Section 4.2.6, update the MID associated with the RTP [RFC7941], Section 4.2.6, update the MID associated with the RTP
stream to match the MID carried in the RTP packet, and then update stream to match the MID carried in the RTP packet and then update
the mapping tables to include an entry that maps the SSRC of that the mapping tables to include an entry that maps the SSRC of that
RTP stream to the "m=" section for that MID. RTP stream to the "m=" section for that MID.
* If the SSRC of the RTP stream is in the incoming SSRC mapping * If the SSRC of the RTP stream is in the incoming SSRC mapping
table, check that the payload type used by the RTP stream matches table, check that the payload type used by the RTP stream matches
a payload type included on the matching "m=" section. If so, a payload type included in the matching "m=" section. If so,
associate the RTP stream with that "m=" section. Otherwise, the associate the RTP stream with that "m=" section. Otherwise, the
RTP stream is not decoded, and the payload data is discarded. RTP stream is not decoded, and the payload data is discarded.
* If the payload type used by the RTP stream is in the payload type * If the payload type used by the RTP stream is in the payload type
table, update the incoming SSRC mapping table to include an entry table, update the incoming SSRC mapping table to include an entry
that maps the RTP stream's SSRC to the "m=" section for that that maps the RTP stream's SSRC to the "m=" section for that
payload type. Associate the RTP stream with the corresponding payload type. Associate the RTP stream with the corresponding
"m=" section. "m=" section.
* Otherwise, mark the RTP stream as "not for decoding" and discard * Otherwise, mark the RTP stream as "not for decoding" and discard
the payload. the 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 associated with the appropriate "m=" sections, the RTP layer, then associated with the appropriate "m=" sections and
and processed for the RTP streams represented by those "m=" sections. 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 that cannot be associated with an appropriate "m=" RTCP packets that cannot be associated with an appropriate "m="
section MUST still be processed as usual by the RTP layer, which section MUST still be processed as usual by the RTP layer, which
updates the metadata associated with the corresponding RTP streams. updates the metadata associated with the corresponding RTP streams.
This situation can occur with certain multiparty RTP topologies or This situation can occur with certain multiparty RTP topologies or
when RTCP packets are sent containing a subset of the SDES when RTCP packets are sent containing a subset of the SDES
information. information.
skipping to change at page 30, line 49 skipping to change at line 1398
packet, the SSRC to "m=" section mapping might 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, it can be is received before any RTP packets). Therefore, it can be
beneficial for an implementation to delay RTCP packet routing, beneficial for an implementation to delay RTCP packet routing,
such that it either prioritizes processing of the SDES item to such that it either prioritizes processing of the SDES item to
generate or update the mapping or buffers the RTCP information generate or update the mapping or buffers the RTCP information
that needs to be routed until the SDES item(s) has been processed. that needs to be routed until the SDES item(s) has been processed.
If the implementation is unable to follow this recommendation, the If the implementation is unable to follow this recommendation, the
consequence could be that some RTCP information from this consequence could be that some RTCP information from this
particular RTCP compound packet is not provided to higher layers. particular RTCP compound packet is not provided to higher layers.
The impact from this is likely minor, when this information The impact from this is likely minor when this information relates
relates to a future incoming RTP stream. 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, and then remove the entry for that SSRC associated with that SSRC, and 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 Sender Report (SR) or Receiver * If the RTCP packet is of type sender report (SR) or receiver
Report (RR), for each report block in the report whose "SSRC of report (RR), for each report block in the report whose "SSRC of
source" is found in the outgoing SSRC table, deliver a copy of the source" is found in the outgoing SSRC table, deliver a copy of the
SR or RR packet to the "m=" section associated with that SSRC. In SR or RR packet to the "m=" section associated with that SSRC. In
addition, if the packet is of type SR, and the sender SSRC for the addition, if the packet is of type SR and the sender SSRC for the
packet is found in the incoming SSRC table, deliver a copy of the packet is found in the incoming SSRC table, deliver a copy of the
SR packet to the "m=" section associated with that SSRC. SR packet to the "m=" section associated with that SSRC.
* If the implementation supports the RTCP Extended Report (XR) and * If the implementation supports the RTCP Extended Report (XR) and
the packet is of type XR, as defined in [RFC3611], for each report the packet is of type XR, as defined in [RFC3611], for each report
block in the report whose "SSRC of source" is found in the block in the report whose "SSRC of source" is found in the
outgoing SSRC table, deliver a copy of the XR packet to the "m=" outgoing SSRC table, deliver a copy of the XR packet to the "m="
section associated with that SSRC. In addition, if the sender section associated with that SSRC. In addition, if the sender
SSRC for the packet is found in the incoming SSRC table, deliver a SSRC for the packet is found in the incoming SSRC table, deliver a
copy of the XR packet to the "m=" section associated with that copy of the XR packet to the "m=" section associated with that
skipping to change at page 31, line 45 skipping to change at line 1441
include a target SSRC(s) in a section called Feedback Control include a target SSRC(s) in a section called Feedback Control
Information (FCI). For these messages, the target SSRC(s) is used Information (FCI). For these messages, the target SSRC(s) is used
for routing. for routing.
* If the RTCP packet is a feedback packet that does not include * If the RTCP packet is a feedback packet that does not include
target SSRCs in its FCI section, and the media source SSRC is target SSRCs in its FCI section, and the media source SSRC is
found in the outgoing SSRC table, deliver the feedback packet to found in the outgoing SSRC table, deliver the feedback packet to
the "m=" section associated with that SSRC. RTPFB and PSFB types the "m=" section associated with that SSRC. RTPFB and PSFB types
that are handled in this way include: that are handled in this way include:
Generic NACK: (PT=RTPFB, FMT=1) [RFC4585]. Generic NACK: (PT=RTPFB, FMT=1) [RFC4585]
Picture Loss Indication (PLI): (PT=PSFB, FMT=1) [RFC4585]. Picture Loss Indication (PLI): (PT=PSFB, FMT=1) [RFC4585]
Slice Loss Indication (SLI): (PT=PSFB, FMT=2) [RFC4585]. Slice Loss Indication (SLI): (PT=PSFB, FMT=2) [RFC4585]
Reference Picture Selection Indication (RPSI): (PT=PSFB, Reference Picture Selection Indication (RPSI): (PT=PSFB, FMT=3)
FMT=3) [RFC4585]. [RFC4585]
* If the RTCP packet is a feedback message that does include a * If the RTCP packet is a feedback message that does include a
target SSRC(s) in its FCI section, it can either be a request or a target SSRC(s) in its FCI section, it can either be a request or a
notification. Requests reference an RTP stream that is being sent notification. Requests reference an RTP stream that is being sent
by the message recipient, whereas notifications are responses to by the message recipient, whereas notifications are responses to
an earlier request and therefore reference an RTP stream that is an earlier request and therefore reference an RTP stream that is
being received by the message recipient. being received by the message recipient.
* If the RTCP packet is a feedback request that includes a target * If the RTCP packet is a feedback request that includes a target
SSRC(s), for each target SSRC that is found in the outgoing SSRC SSRC(s), for each target SSRC that is found in the outgoing SSRC
table, deliver a copy of the RTCP packet to the "m=" section table, deliver a copy of the RTCP packet to the "m=" section
associated with that SSRC. PSFB and RTPFB types that are handled associated with that SSRC. PSFB and RTPFB types that are handled
in this way include: in this way include:
Full Intra Request (FIR): (PT=PSFB, FMT=4) [RFC5104]. Full Intra Request (FIR): (PT=PSFB, FMT=4) [RFC5104]
Temporal-Spatial Trade-off Request (TSTR): (PT=PSFB, FMT=5) Temporal-Spatial Trade-off Request (TSTR): (PT=PSFB, FMT=5)
[RFC5104]. [RFC5104]
H.271 Video Back Channel Message (VBCM): (PT=PSFB, FMT=7) H.271 Video Back Channel Message (VBCM): (PT=PSFB, FMT=7)
[RFC5104]. [RFC5104]
Temporary Maximum Media Stream Bit Rate Request (TMMBR): (PT=R Temporary Maximum Media Stream Bit Rate Request (TMMBR): (PT=RTPF
TPFB, FMT=3) [RFC5104]. B, FMT=3) [RFC5104]
Layer Refresh Request (LRR): (PT=PSFB, FMT=10) [LLR-RTCP]. Layer Refresh Request (LRR): (PT=PSFB, FMT=10) [LLR-RTCP].
* If the RTCP packet is a feedback notification that includes a * If the RTCP packet is a feedback notification that includes a
target SSRC(s), for each target SSRC that is found in the incoming target SSRC(s), for each target SSRC that is found in the incoming
SSRC table, deliver a copy of the RTCP packet to the "m=" section SSRC table, deliver a copy of the RTCP packet to the "m=" section
associated with the RTP stream with a matching SSRC. PSFB and associated with the RTP stream with a matching SSRC. PSFB and
RTPFB types that are handled in this way include: RTPFB types that are handled in this way include:
Temporal-Spatial Trade-off Notification (TSTN): (PT=PSFB, Temporal-Spatial Trade-off Notification (TSTN): (PT=PSFB, FMT=6)
FMT=6) [RFC5104]. This message is a notification in [RFC5104]. This message is a notification in response to a
response to a prior TSTR. prior TSTR.
Temporary Maximum Media Stream Bit Rate Notification Temporary Maximum Media Stream Bit Rate Notification (TMMBN): (PT
(TMMBN): (PT=RTPFB, FMT=4) [RFC5104]. This message is a =RTPFB, FMT=4) [RFC5104]. This message is a notification in
notification in response to a prior TMMBR, but it can also response to a prior TMMBR, but it can also be sent unsolicited.
be sent unsolicited.
If the RTCP packet is of type APP, then it is handled in an If the RTCP packet is of type APP, then it is handled in an
application-specific manner. If the application does not application-specific manner. If the application does not
recognize the APP packet, then it MUST be discarded. recognize the APP packet, then it MUST be discarded.
9.3. RTP/RTCP Multiplexing 9.3. RTP/RTCP Multiplexing
Within a BUNDLE group, the offerer and answerer MUST enable RTP/RTCP Within a BUNDLE group, the offerer and answerer MUST enable RTP/RTCP
multiplexing [RFC5761] for the RTP-based bundled media (i.e., the multiplexing [RFC5761] for the RTP-based bundled media (i.e., the
same transport will be used for both RTP packets and RTCP packets). same transport will be used for both RTP packets and RTCP packets).
In addition, the offerer and answerer MUST support the SDP 'rtcp-mux- In addition, the offerer and answerer MUST support the SDP 'rtcp-mux-
only' attribute [RFC8858]. only' attribute [RFC8858].
9.3.1. SDP Offer/Answer Procedures 9.3.1. SDP Offer/Answer Procedures
This section describes how an offerer and answerer use the SDP 'rtcp- This section describes how an offerer and answerer use the SDP 'rtcp-
mux' [RFC5761] and SDP 'rtcp-mux-only' attributes [RFC8858] to mux' [RFC5761] and SDP 'rtcp-mux-only' attributes [RFC8858] to
negotiate usage of RTP/RTCP multiplexing for RTP-based bundled media. negotiate usage of RTP/RTCP multiplexing for RTP-based bundled media.
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 7.1.3, within an offer or answer the SDP 'rtcp- described in Section 7.1.3, within an offer or answer, the SDP 'rtcp-
mux' and SDP 'rtcp-mux-only' attributes might be included in a mux' and SDP 'rtcp-mux-only' attributes might be included in a
bundled "m=" section for non-RTP-based media (if such "m=" section is bundled "m=" section for non-RTP-based media (if such an "m=" section
the offerer-tagged "m=" section or answerer-tagged "m=" section). is the offerer-tagged "m=" section or answerer-tagged "m=" section).
9.3.1.1. Generating the Initial BUNDLE offer 9.3.1.1. Generating the Initial BUNDLE Offer
When an offerer generates an initial BUNDLE offer, if the offer When an offerer generates an initial BUNDLE offer, if the offer
contains one or more bundled "m=" sections for RTP-based media (or, contains one or more bundled "m=" sections for RTP-based media (or if
if there is a chance that "m=" sections for RTP-based media will there is a chance that "m=" sections for RTP-based media will later
later be added to the BUNDLE group), the offerer MUST include an SDP be added to the BUNDLE group), the offerer MUST include an SDP 'rtcp-
'rtcp-mux' attribute [RFC5761] in each bundled "m=" section mux' attribute [RFC5761] in each bundled "m=" section (excluding any
(excluding any bundle-only "m=" sections). In addition, the offerer bundle-only "m=" sections). In addition, the offerer MAY include an
MAY include an SDP 'rtcp-mux-only' attribute [RFC8858] in one or more SDP 'rtcp-mux-only' attribute [RFC8858] in one or more bundled "m="
bundled "m=" sections for RTP-based media. sections for RTP-based media.
NOTE: Whether the offerer includes the SDP 'rtcp-mux-only' attribute NOTE: Whether the offerer includes the SDP 'rtcp-mux-only'
depends on whether the offerer supports fallback to usage of a attribute depends on whether the offerer supports fallback to
separate port for RTCP in case the answerer moves one or more "m=" usage of a separate port for RTCP in case the answerer moves one
sections for RTP-based media out of the BUNDLE group in the answer. or more "m=" sections for RTP-based media out of the BUNDLE group
in the answer.
NOTE: If the offerer includes an SDP 'rtcp-mux' attribute in the NOTE: If the offerer includes an SDP 'rtcp-mux' attribute in the
bundled "m=" sections, but does not include an SDP 'rtcp-mux-only' bundled "m=" sections but does not include an SDP 'rtcp-mux-only'
attribute, the offerer can also include an SDP 'rtcp' attribute attribute, the offerer can also include an SDP 'rtcp' attribute
[RFC3605] in one or more RTP-based bundled "m=" sections in order to [RFC3605] in one or more RTP-based bundled "m=" sections in order
provide a fallback port for RTCP, as described in [RFC5761]. to provide a fallback port for RTCP, as described in [RFC5761].
However, the fallback port will only be applied to "m=" sections for However, the fallback port will only be applied to "m=" sections
RTP-based media that are moved out of the BUNDLE group by the for RTP-based media that are moved out of the BUNDLE group by the
answerer. answerer.
In the initial BUNDLE offer, the address:port combination for RTCP In the initial BUNDLE offer, the address:port combination for RTCP
MUST be unique in each bundled "m=" section for RTP-based media MUST be unique in each bundled "m=" section for RTP-based media
(excluding a bundle-only "m=" section), similar to RTP. (excluding a bundle-only "m=" section), similar to RTP.
9.3.1.2. Generating the SDP Answer 9.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 corresponding offer based media and if a bundled "m=" section in the corresponding offer
contained an SDP 'rtcp-mux' attribute, the answerer MUST enable usage contained an SDP 'rtcp-mux' attribute, the answerer MUST enable usage
of RTP/RTCP multiplexing, even if there currently are no bundled "m=" of RTP/RTCP multiplexing, even if there currently are no bundled "m="
sections for RTP-based media within the BUNDLE group. The answerer sections for RTP-based media within the BUNDLE group. The answerer
MUST include an SDP 'rtcp-mux' attribute in the answerer-tagged "m=" MUST include an SDP 'rtcp-mux' attribute in the answerer-tagged "m="
section, following the procedures for BUNDLE attributes section, following the procedures for BUNDLE attributes
(Section 7.1.3). In addition, if the "m=" section that is selected (Section 7.1.3). In addition, if the "m=" section that is selected
as the offerer-tagged "m=" section contained an SDP 'rtcp-mux-only' as the offerer-tagged "m=" section contained an SDP 'rtcp-mux-only'
attribute, the answerer MUST include an SDP 'rtcp-mux-only' attribute attribute, the answerer MUST include an SDP 'rtcp-mux-only' attribute
in the answerer-tagged "m=" section. in the answerer-tagged "m=" section.
In an initial BUNDLE offer, if the suggested offerer-tagged "m=" In an initial BUNDLE offer, if the suggested offerer-tagged "m="
section contained an SDP 'rtcp-mux-only' attribute, the "m=" section section contained an SDP 'rtcp-mux-only' attribute, the "m=" section
was for RTP-based media. If the answerer does not accept the "m=" was for RTP-based media. If the answerer does not accept the "m="
section in the created BUNDLE group, and moves the "m=" section out section in the created BUNDLE group and moves the "m=" section out of
of the BUNDLE group (Section 7.3.2), the answerer MUST include the the BUNDLE group (Section 7.3.2), the answerer MUST include the
attribute in the moved "m=" section and enable RTP/RTCP multiplexing attribute in the moved "m=" section and enable RTP/RTCP multiplexing
for the media associated with the "m=" section. If the answerer for the media associated with the "m=" section. If the answerer
rejects the "m=" section (Section 7.3.3) the answerer MUST NOT rejects the "m=" section (Section 7.3.3), the answerer MUST NOT
include the attribute. include the attribute.
The answerer MUST NOT include an SDP 'rtcp' attribute in any bundled The answerer MUST NOT include an SDP 'rtcp' attribute in any bundled
"m=" section in the answer. The answerer will use the port value of "m=" section in the answer. The answerer will use the port value of
the offerer-tagged "m=" section sending RTP and RTCP packets the offerer-tagged "m=" section sending RTP and RTCP packets
associated with RTP-based bundled media towards the offerer. associated with RTP-based bundled media 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 answerer-tagged "m=" include an SDP 'rtcp-mux' attribute in the answerer-tagged "m="
skipping to change at page 34, line 49 skipping to change at line 1588
9.3.1.3. Offerer Processing of the SDP Answer 9.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 (Section 9.3.1.2), the answerer usage of RTP/RTCP multiplexing (Section 9.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 of the answerer- [RFC5761]. The offerer will use the port value of the answerer-
tagged "m=" section for sending RTP and RTCP packets associated with tagged "m=" section for sending RTP and RTCP packets associated with
RTP-based bundled media towards the answerer. RTP-based bundled media 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.
9.3.1.4. Modifying the Session 9.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 offerer-tagged "m=" include an SDP 'rtcp-mux' attribute in the offerer-tagged "m="
section, following the procedures for IDENTICAL multiplexing category section, following the procedures for IDENTICAL multiplexing category
attributes in Section 7.1.3. attributes in Section 7.1.3.
10. ICE Considerations 10. ICE Considerations
skipping to change at page 35, line 33 skipping to change at line 1620
transport, instead of per individual bundled "m=" section within transport, instead of per individual bundled "m=" section within
the BUNDLE group. the BUNDLE group.
* The generic SDP attribute offer/answer considerations * The generic SDP attribute offer/answer considerations
(Section 7.1.3) also apply to ICE-related attributes. Therefore, (Section 7.1.3) also apply to ICE-related attributes. Therefore,
when an offerer sends an initial BUNDLE offer (in order to when an offerer sends an initial BUNDLE offer (in order to
negotiate a BUNDLE group), the offerer includes ICE-related media- negotiate a BUNDLE group), the offerer includes ICE-related media-
level attributes in each bundled "m=" section (excluding any level attributes in each bundled "m=" section (excluding any
bundle-only "m=" sections), and each "m=" section MUST contain bundle-only "m=" sections), and each "m=" section MUST contain
unique ICE properties. When an answerer generates an answer unique ICE properties. When an answerer generates an answer
(initial BUNDLE answer or subsequent) that contains a BUNDLE (initial BUNDLE answer or subsequent) that contains a BUNDLE group
group, and when an offerer sends a subsequent offer that contains and when an offerer sends a subsequent offer that contains a
a BUNDLE group, ICE-related media-level attributes are only BUNDLE group, ICE-related media-level attributes are only included
included in the tagged "m=" section (suggested offerer-tagged "m=" in the tagged "m=" section (suggested offerer-tagged "m=" section
section or answerer-tagged "m=" section), and the ICE properties or answerer-tagged "m=" section), and the ICE properties are
are applied to each bundled "m=" section within the BUNDLE group. applied to each bundled "m=" section within the BUNDLE group.
NOTE: Most ICE-related media-level SDP attributes belong to the NOTE: Most ICE-related media-level SDP attributes belong to the
TRANSPORT multiplexing category [RFC8859], and the generic SDP TRANSPORT multiplexing category [RFC8859], and the generic SDP
attribute offer/answer considerations for the TRANSPORT multiplexing attribute offer/answer considerations for the TRANSPORT
category apply to the attributes. However, in the case of ICE- multiplexing category apply to the attributes. However, in the
related attributes, the same considerations also apply to ICE-related case of ICE-related attributes, the same considerations also apply
media-level attributes that belong to other multiplexing categories. to ICE-related media-level attributes that belong to other
multiplexing categories.
NOTE: The following ICE-related media-level SDP attributes are NOTE: The following ICE-related media-level SDP attributes are
defined in [RFC8839]: 'candidate', 'remote-candidates', 'ice- defined in [RFC8839]: 'candidate', 'remote-candidates', 'ice-
mismatch', 'ice-ufrag', 'ice-pwd', and 'ice-pacing'. mismatch', 'ice-ufrag', 'ice-pwd', and 'ice-pacing'.
Initially, before ICE has produced selected candidate pairs that will Initially, before ICE has produced selected candidate pairs that will
be used for media, there might be multiple transports established (if be used for media, there might be multiple transports established (if
multiple candidate pairs are tested). Once ICE has selected multiple candidate pairs are tested). Once ICE has selected
candidate pairs, they form the BUNDLE transport. candidate pairs, they form the BUNDLE transport.
Support and usage of the ICE mechanism together with the BUNDLE Support and usage of the ICE mechanism together with the BUNDLE
extension is OPTIONAL, and the procedures in this section only apply extension is OPTIONAL, and the procedures in this section only apply
when the ICE mechanism is used. Note that applications might mandate when the ICE mechanism is used. Note that applications might mandate
usage of the ICE mechanism even if the BUNDLE extension is not used. usage of the ICE mechanism even if the BUNDLE extension is not used.
NOTE: If the Trickle ICE mechanism [RFC8840] is used, an offerer and NOTE: If the Trickle ICE mechanism [RFC8840] is used, an offerer
answerer might assign a port value of '9' and an IPv4 address of and answerer might assign a port value of '9' and an IPv4 address
'0.0.0.0' (or, the IPv6 equivalent '::') to multiple bundled "m=" of '0.0.0.0' (or, the IPv6 equivalent '::') to multiple bundled
sections in the initial BUNDLE offer. The offerer and answerer will "m=" sections in the initial BUNDLE offer. The offerer and
follow the normal procedures for generating the offers and answers, answerer will follow the normal procedures for generating the
including picking a bundled "m=" section as the suggested offerer- offers and answers, including picking a bundled "m=" section as
tagged "m=" section, selecting the tagged "m=" sections, etc. The the suggested offerer-tagged "m=" section, selecting the tagged
only difference is that media cannot be sent until one or more "m=" sections, etc. The only difference is that media cannot be
candidates have been provided. Once a BUNDLE group has been sent until one or more candidates have been provided. Once a
negotiated, trickled candidates associated with a bundled "m=" BUNDLE group has been negotiated, trickled candidates associated
section will be applied to all bundled "m=" sections within the with a bundled "m=" section will be applied to all bundled "m="
BUNDLE group. sections within the BUNDLE group.
11. DTLS Considerations 11. DTLS Considerations
One or more media streams within a BUNDLE group might use the One or more media streams within a BUNDLE group might use the DTLS
Datagram Transport Layer Security (DTLS) protocol [RFC6347] in order protocol [RFC6347] in order to encrypt the data or negotiate
to encrypt the data or negotiate encryption keys if another encryption keys if another encryption mechanism is used to encrypt
encryption mechanism is used to encrypt media. media.
When DTLS is used within a BUNDLE group, the following rules apply: When DTLS is used within a BUNDLE group, the following rules apply:
* There can only be one DTLS association [RFC6347] associated with * There can only be one DTLS association [RFC6347] associated with
the BUNDLE group; the BUNDLE group;
* Each usage of the DTLS association within the BUNDLE group MUST * Each usage of the DTLS association within the BUNDLE group MUST
use the same mechanism for determining which endpoints (the use the same mechanism for determining which endpoints (the
offerer or answerer) become DTLS client and DTLS server; offerer or answerer) become DTLS client and DTLS server;
* Each usage of the DTLS association within the BUNDLE group MUST * Each usage of the DTLS association within the BUNDLE group MUST
use the same mechanism for determining whether an offer or answer use the same mechanism for determining whether an offer or answer
will trigger the establishment of a new DTLS association or an will trigger the establishment of a new DTLS association or if an
existing DTLS association will be used; and existing DTLS association will be used instead; and
* If the DTLS client supports DTLS-SRTP, it MUST include the * If the DTLS client supports DTLS-SRTP, it MUST include the
'use_srtp' extension in the DTLS ClientHello message [RFC5764]. 'use_srtp' extension in the DTLS ClientHello message [RFC5764].
The client MUST include the extension even if the usage of DTLS- The client MUST include the extension even if the usage of DTLS-
SRTP is not negotiated as part of the multimedia session (e.g., SRTP is not negotiated as part of the multimedia session (e.g.,
the SIP session [RFC3261]). the SIP session [RFC3261]).
NOTE: The inclusion of the 'use_srtp' extension during the initial NOTE: The inclusion of the 'use_srtp' extension during the initial
DTLS handshake ensures that a DTLS renegotiation will not be required DTLS handshake ensures that a DTLS renegotiation will not be
in order to include the extension, in case DTLS-SRTP encrypted media required in order to include the extension in case DTLS-SRTP
is added to the BUNDLE group later during the multimedia session. encrypted media is added to the BUNDLE group later during the
multimedia session.
12. RTP Header Extensions Consideration 12. RTP Header Extensions Consideration
When RTP header extensions [RFC8285] are used in the context of this When RTP header extensions [RFC8285] 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.
13. Update to RFC 3264 13. Updates to RFC 3264
This section updates RFC 3264, in order to allow extensions to define This section updates [RFC3264] in order to allow extensions to define
the usage of a zero port value in offers and answers for purposes the usage of a zero port value in offers and answers for purposes
other than removing or disabling media streams. The following other than removing or disabling media streams. The following
sections are being updated: sections are being updated:
* "Unicast Streams"; see Section 5.1 of [RFC3264] * "Unicast Streams"; see Section 5.1 of [RFC3264].
* "Putting a Unicast Media Stream on Hold"; see Section 8.4 of * "Putting a Unicast Media Stream on Hold"; see Section 8.4 of
[RFC3264]. [RFC3264].
13.1. Original Text from RFC 3264, Section 5.1, 2nd Paragraph 13.1. Original Text from RFC 3264, Section 5.1, Paragraph 2
| For recvonly and sendrecv streams, the port number and address in | For recvonly and sendrecv streams, the port number and address in
| the offer indicate where the offerer would like to receive the | the offer indicate where the offerer would like to receive the
| media stream. For sendonly RTP streams, the address and port | media stream. For sendonly RTP streams, the address and port
| number indirectly indicate where the offerer wants to receive RTCP | number indirectly indicate where the offerer wants to receive RTCP
| reports. Unless there is an explicit indication otherwise, | reports. Unless there is an explicit indication otherwise,
| reports are sent to the port number one higher than the number | reports are sent to the port number one higher than the number
| indicated. The IP address and port present in the offer indicate | indicated. The IP address and port present in the offer indicate
| nothing about the source IP address and source port of RTP and | nothing about the source IP address and source port of RTP and
| RTCP packets that will be sent by the offerer. A port number of | RTCP packets that will be sent by the offerer. A port number of
| zero in the offer indicates that the stream is offered but MUST | zero in the offer indicates that the stream is offered but MUST
| NOT be used. This has no useful semantics in an initial offer, | NOT be used. This has no useful semantics in an initial offer,
| but is allowed for reasons of completeness, since the answer can | but is allowed for reasons of completeness, since the answer can
| contain a zero port indicating a rejected stream (Section 6). | contain a zero port indicating a rejected stream (Section 6).
| Furthermore, existing streams can be terminated by setting the | Furthermore, existing streams can be terminated by setting the
| port to zero (Section 8). In general, a port number of zero | port to zero (Section 8). In general, a port number of zero
| indicates that the media stream is not wanted. | indicates that the media stream is not wanted.
13.2. New Text Replacing RFC 3264, Section 5.1, 2nd Paragraph 13.2. New Text Replacing RFC 3264, Section 5.1, Paragraph 2
For recvonly and sendrecv streams, the port number and address in the | For recvonly and sendrecv streams, the port number and address in
offer indicate where the offerer would like to receive the media | the offer indicate where the offerer would like to receive the
stream. For sendonly RTP streams, the address and port number | media stream. For sendonly RTP streams, the address and port
indirectly indicate where the offerer wants to receive RTCP reports. | number indirectly indicate where the offerer wants to receive RTCP
Unless there is an explicit indication otherwise, reports are sent to | reports. Unless there is an explicit indication otherwise,
the port number one higher than the number indicated. The IP address | reports are sent to the port number one higher than the number
and port present in the offer indicate nothing about the source IP | indicated. The IP address and port present in the offer indicate
address and source port of the RTP and RTCP packets that will be sent | nothing about the source IP address and source port of the RTP and
by the offerer. By default, a port number of zero in the offer | RTCP packets that will be sent by the offerer. By default, a port
indicates that the stream is offered but MUST NOT be used, but an | number of zero in the offer indicates that the stream is offered
extension mechanism might specify different semantics for the usage | but MUST NOT be used, but an extension mechanism might specify
of a zero port value. Furthermore, existing streams can be | different semantics for the usage of a zero port value.
terminated by setting the port to zero (Section 8). In general, a | Furthermore, existing streams can be terminated by setting the
port number of zero by default indicates that the media stream is not | port to zero (Section 8). In general, a port number of zero by
wanted. | default indicates that the media stream is not wanted.
13.3. Original Text from RFC 3264, Section 8.4, 6th Paragraph 13.3. Original Text from RFC 3264, Section 8.4, Paragraph 6
| RFC 2543 [10] specified that placing a user on hold was | RFC 2543 [10] specified that placing a user on hold was
| accomplished by setting the connection address to 0.0.0.0. Its | accomplished by setting the connection address to 0.0.0.0. Its
| usage for putting a call on hold is no longer recommended, since | usage for putting a call on hold is no longer recommended, since
| it doesn't allow for RTCP to be used with held streams, doesn't | it doesn't allow for RTCP to be used with held streams, doesn't
| work with IPv6, and breaks with connection oriented media. | work with IPv6, and breaks with connection oriented media.
| However, it can be useful in an initial offer when the offerer | However, it can be useful in an initial offer when the offerer
| knows it wants to use a particular set of media streams and | knows it wants to use a particular set of media streams and
| formats, but doesn't know the addresses and ports at the time of | formats, but doesn't know the addresses and ports at the time of
| the offer. Of course, when used, the port number MUST NOT be | the offer. Of course, when used, the port number MUST NOT be
| zero, which would specify that the stream has been disabled. An | zero, which would specify that the stream has been disabled. An
| agent MUST be capable of receiving SDP with a connection address | agent MUST be capable of receiving SDP with a connection address
| of 0.0.0.0, in which case it means that neither RTP nor RTCP | of 0.0.0.0, in which case it means that neither RTP nor RTCP
| should be sent to the peer. | should be sent to the peer.
13.4. New Text Replacing RFC 3264, Section 8.4, 6th Paragraph 13.4. New Text Replacing RFC 3264, Section 8.4, Paragraph 6
RFC 2543 [RFC2543] specifies that placing a user on hold was | RFC 2543 [RFC2543] specifies that placing a user on hold was
accomplished by setting the connection address to 0.0.0.0. Its usage | accomplished by setting the connection address to 0.0.0.0. Its
for putting a call on hold is no longer recommended, since it doesn't | usage for putting a call on hold is no longer recommended, since
allow for RTCP to be used with held streams, doesn't work with IPv6, | it doesn't allow for RTCP to be used with held streams, doesn't
and breaks with connection oriented media. However, it can be useful | work with IPv6, and breaks with connection oriented media.
in an initial offer when the offerer knows it wants to use a | However, it can be useful in an initial offer when the offerer
particular set of media streams and formats, but doesn't know the | knows it wants to use a particular set of media streams and
addresses and ports at the time of the offer. Of course, when used, | formats, but doesn't know the addresses and ports at the time of
the port number MUST NOT be zero, if it would specify that the stream | the offer. Of course, when used, the port number MUST NOT be
has been disabled. However, an extension mechanism might specify | zero, if it would specify that the stream has been disabled.
different semantics of the zero port number usage. An agent MUST be | However, an extension mechanism might specify different semantics
capable of receiving SDP with a connection address of 0.0.0.0, in | of the zero port number usage. An agent MUST be capable of
which case it means that neither RTP nor RTCP is to be sent to the | receiving SDP with a connection address of 0.0.0.0, in which case
peer. | it means that neither RTP nor RTCP is to be sent to the peer.
14. Update to RFC 5888 14. Update to RFC 5888
This section updates RFC 5888 [RFC5888], in order for extensions to This section updates RFC 5888 [RFC5888] in order for extensions to
allow an SDP 'group' attribute containing an identification-tag that allow an SDP 'group' attribute containing an identification-tag that
identifies an "m=" section with the port set to zero. "Group Value identifies an "m=" section with the port set to zero. "Group Value
in Answers" (Section 9.2 of [RFC5888]) is updated. in Answers" (Section 9.2 of [RFC5888]) is updated.
14.1. Original Text from RFC 5888, Section 9.2, 3rd Paragraph 14.1. Original Text from RFC 5888, Section 9.2, Paragraph 3
| SIP entities refuse media streams by setting the port to zero in | SIP entities refuse media streams by setting the port to zero in
| the corresponding "m" line. "a=group" lines MUST NOT contain | the corresponding "m" line. "a=group" lines MUST NOT contain
| identification-tags that correspond to "m" lines with the port set | identification-tags that correspond to "m" lines with the port set
| to zero. | to zero.
14.2. New Text Replacing RFC 5888, Section 9.2, 3rd Paragraph 14.2. New Text Replacing RFC 5888, Section 9.2, Paragraph 3
SIP entities refuse media streams by setting the port to zero in the | SIP entities refuse media streams by setting the port to zero in
corresponding "m" line. "a=group" lines MUST NOT contain | the corresponding "m" line. "a=group" lines MUST NOT contain
identification-tags that correspond to "m" lines with the port set to | identification-tags that correspond to "m" lines with the port set
zero, but an extension mechanism might specify different semantics | to zero, but an extension mechanism might specify different
for including identification-tags that correspond to such "m=" lines. | semantics for including identification-tags that correspond to
| such "m=" lines.
15. RTP/RTCP Extensions for identification-tag Transport 15. RTP/RTCP Extensions for identification-tag Transport
Offerers and answerers [RFC3264] can associate identification-tags Offerers and answerers [RFC3264] can associate identification-tags
with "m=" sections within offers and answers, using the procedures in with "m=" sections within offers and answers using the procedures in
[RFC5888]. Each identification-tag uniquely represents an "m=" [RFC5888]. Each identification-tag uniquely represents an "m="
section. section.
This section defines a new RTCP SDES item [RFC3550], 'MID', which is This section defines a new RTCP SDES item [RFC3550], 'MID', which is
used to carry identification-tags within RTCP SDES packets. This used to carry identification-tags within RTCP SDES packets. This
section also defines a new RTP SDES header extension [RFC7941], which section also defines a new RTP SDES header extension [RFC7941], which
is used to carry the 'MID' RTCP SDES item in RTP packets. is used to carry the 'MID' RTCP SDES item in RTP packets.
The SDES item and RTP SDES header extension make it possible for a The SDES item and RTP SDES header extension make it possible for a
receiver to associate each RTP stream with a specific "m=" section, receiver to associate each RTP stream with a specific "m=" section
with which the receiver has associated an identification-tag, even if with which the receiver has associated an identification-tag, even if
those "m=" sections are part of the same RTP session. The RTP SDES those "m=" sections are part of the same RTP session. The RTP SDES
header extension also ensures that the media recipient gets the header extension also ensures that the media recipient gets the
identification-tag upon receipt of the first decodable media and is identification-tag upon receipt of the first decodable media and is
able to associate the media with the correct application. able to associate the media with the correct application.
A media recipient informs the media sender about the identification- A media recipient informs the media sender about the identification-
tag associated with an "m=" section through the use of a 'mid' tag associated with an "m=" section through the use of a 'mid'
attribute [RFC5888]. The media sender then inserts the attribute [RFC5888]. The media sender then inserts the
identification-tag in RTCP and RTP packets sent to the media identification-tag in RTCP and RTP packets sent to the media
recipient. recipient.
NOTE: The text above defines how identification-tags are carried in NOTE: The text above defines how identification-tags are carried
offers and answers. The usage of other signaling protocols for in offers and answers. The usage of other signaling protocols for
carrying identification-tags is not prevented, but the usage of such carrying identification-tags is not prevented, but the usage of
protocols is outside the scope of this document. such protocols is outside the scope of this document.
[RFC3550] defines general procedures regarding the RTCP transmission [RFC3550] defines general procedures regarding the RTCP transmission
interval. The RTCP MID SDES item SHOULD be sent in the first few interval. The RTCP MID SDES item SHOULD be sent in the first few
RTCP packets after joining the session and SHOULD be sent regularly RTCP packets after joining the session and SHOULD be sent regularly
thereafter. The exact number of RTCP packets in which this SDES item thereafter. The exact number of RTCP packets in which this SDES item
is sent is intentionally not specified here, as it will depend on the is sent is intentionally not specified here, as it will depend on the
expected packet-loss rate, the RTCP reporting interval, and the expected packet-loss rate, the RTCP reporting interval, and the
allowable overhead. allowable overhead.
The RTP SDES header extension for carrying the 'MID' RTCP SDES SHOULD The RTP SDES header extension for carrying the 'MID' RTCP SDES SHOULD
skipping to change at page 41, line 5 skipping to change at line 1873
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MID=15 | length | identification-tag ... | MID=15 | length | identification-tag ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The identification-tag payload is UTF-8 encoded [RFC3629], as in SDP. The identification-tag payload is UTF-8 encoded [RFC3629], as in SDP.
The identification-tag is not zero terminated. The identification-tag is not zero terminated.
15.2. RTP SDES Header Extension For MID 15.2. RTP SDES Header Extension for MID
The payload, containing the identification-tag, of the RTP SDES The payload, containing the identification-tag, of the RTP SDES
header extension element can be encoded using either the 1-byte or header extension element can be encoded using either the 1-byte or
the 2-byte header [RFC7941]. The identification-tag payload is UTF-8 the 2-byte header [RFC7941]. The identification-tag payload is UTF-8
encoded, as in SDP. encoded, as in SDP.
The identification-tag is not zero terminated. Note that the set of The identification-tag is not zero terminated. Note that the set of
header extensions included in the packet needs to be padded to the header extensions included in the packet needs to be padded to the
next 32-bit boundary using zero bytes [RFC8285]. next 32-bit boundary using zero bytes [RFC8285].
skipping to change at page 41, line 27 skipping to change at line 1895
SDES header extension, or both, there needs to be some consideration SDES header extension, or both, there needs to be some consideration
about the packet expansion caused by the identification-tag. To about the packet expansion caused by the identification-tag. To
avoid Maximum Transmission Unit (MTU) issues for the RTP packets, the avoid Maximum Transmission Unit (MTU) issues for the RTP packets, the
header extension's size needs to be taken into account when encoding header extension's size needs to be taken into account when encoding
the media. the media.
It is recommended that the identification-tag be kept short. Due to It is recommended that the identification-tag be 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
1-byte header, a tag that is 1-3 bytes will result in a minimal 1-byte header, a tag that is 1-3 bytes will result in a minimal
number of 32-bit words used for the RTP SDES header extension, in number of 32-bit words used for the RTP SDES header extension, in
case no other header extensions are included at the same time. Note, case no other header extensions are included at the same time. Note:
do take into account that some single characters when UTF-8 encoded do take into account that some single characters when UTF-8 encoded
will result in multiple octets. The identification-tag MUST NOT will result in multiple octets. The identification-tag MUST NOT
contain any user information, and applications SHALL avoid generating contain any user information, and applications SHALL avoid generating
the identification-tag using a pattern that enables user or the identification-tag using a pattern that enables user or
application identification. application identification.
16. IANA Considerations 16. IANA Considerations
16.1. New SDES Item NOTE: Apart from the references, the IANA considerations in this
section are identical to those in [RFC8843].
This document updates the MID SDES item to the IANA "RTP SDES Item
Types" registry as follows:
Value: 15
Abbrev.: MID
Name: Media Identification
Reference: RFC XXXX
16.2. New RTP SDES Header Extension URI 16.1. SDES Item
This document updates the extension URI in the RTP SDES Compact This document updates the MID SDES entry in the "RTP SDES Item Types"
Header Extensions sub-registry of the RTP Compact Header Extensions registry as follows:
registry sub-registry, according to the following data:
Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid Value: 15
Abbrev.: MID
Name: Media Identification
Reference: RFC 9143
Description: Media identification 16.2. RTP SDES Header Extension URI
Contact: IESG (iesg@ietf.org) This document updates the extension URI in the "RTP SDES Compact
Header Extensions" subregistry of the "RTP Compact Header Extensions"
sub-registry, according to the following data:
Reference: RFC XXXX Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid
Description: Media identification
Contact: IESG (iesg@ietf.org)
Reference: RFC 9143
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 answer. receives the associated answer.
16.3. New SDP Attribute 16.3. SDP Attribute
This document updates the SDP media-level attribute, 'bundle-only', This document updates the SDP media-level attribute, 'bundle-only',
according to the following data: in the "attribute-name (formerly 'att-field')" subregistry of the
"Session Description Protocol (SDP) Parameters" registry according to
Attribute name: bundle-only the following data:
Type of attribute: media
Subject to charset: No
Purpose: Request a media description to be accepted in the answer
only if kept within a BUNDLE group by the answerer.
Appropriate values: N/A
Contact name: IESG
Contact e-mail: iesg@ietf.org
Reference: RFC XXXX
Mux category: NORMAL Attribute name: bundle-only
Type of attribute: media
Subject to charset: No
Purpose: Request a media description to be accepted in the answer
only if kept within a BUNDLE group by the answerer.
Appropriate values: N/A
Contact name: IESG
Contact e-mail: iesg@ietf.org
Reference: RFC 9143
Mux category: NORMAL
16.4. New SDP Group Semantics 16.4. SDP Group Semantics
This document updates the following semantics in the "Semantics for This document updates the following semantics in the "Semantics for
the 'group' SDP Attribute" subregistry (under the "Session the 'group' SDP Attribute" subregistry (under the "Session
Description Protocol (SDP) Parameters" registry): Description Protocol (SDP) Parameters" registry):
+================+========+==============+===========+ +================+========+==============+===========+
| Semantics | Token | Mux Category | Reference | | Semantics | Token | Mux Category | Reference |
+================+========+==============+===========+ +================+========+==============+===========+
| Media bundling | BUNDLE | NORMAL | RFC XXXX | | Media bundling | BUNDLE | NORMAL | RFC 9143 |
+----------------+--------+--------------+-----------+ +----------------+--------+--------------+-----------+
Table 1 Table 1: Update to SDP Group Semantics
17. Security Considerations 17. Security Considerations
The security considerations defined in [RFC3264] and [RFC5888] apply The security considerations defined in [RFC3264] and [RFC5888] apply
to the BUNDLE extension. BUNDLE does not change which information, to the BUNDLE extension. BUNDLE does not change which information,
e.g., RTP streams, flows over the network, except for the usage of e.g., RTP streams, flows over the network, except for the usage of
the MID SDES item as discussed below. Primarily, it changes which the MID SDES item as discussed below. Primarily, it changes which
addresses and ports, and thus in which (RTP) sessions, the addresses and ports, and thus in which (RTP) sessions, the
information flows to. This affects the security contexts being used information flows to. This affects the security contexts being used
and can cause previously separated information flows to share the and can cause previously separated information flows to share the
same security context. This has very little impact on the same security context. This has very little impact on the
performance of the security mechanism of the RTP sessions. In cases performance of the security mechanism of the RTP sessions. In cases
where one would have applied different security policies on the where one would have applied different security policies on the
different RTP streams being bundled, or where the parties having different RTP streams being bundled or where the parties having
access to the security contexts would have differed between the RTP access to the security contexts would have differed between the RTP
streams, additional analysis of the implications are needed before streams, additional analysis of the implications is needed before
selecting to apply BUNDLE. selecting to apply BUNDLE.
The identification-tag, independent of transport, RTCP SDES packet, The identification-tag, independent of transport, RTCP SDES packet,
or RTP header extension, can expose the value to parties beyond the or RTP header extension, can expose the value to parties beyond the
signaling chain. Therefore, the identification-tag values MUST be signaling chain. Therefore, the identification-tag values MUST be
generated in a fashion that does not leak user information, e.g., generated in a fashion that does not leak user information, e.g.,
randomly or using a per-bundle group counter, and SHOULD be 3 bytes randomly or using a per-bundle group counter, and SHOULD be 3 bytes
or fewer to allow them to efficiently fit into the MID RTP header or fewer to allow them to efficiently fit into the MID RTP header
extension. Note that if implementations use different methods for extension. Note that if implementations use different methods for
generating identification-tags, this could enable fingerprinting of generating identification-tags, this could enable fingerprinting of
the implementation making it vulnerable to targeted attacks. The the implementation, making it vulnerable to targeted attacks. The
identification-tag is exposed on the RTP stream level when included identification-tag is exposed on the RTP stream level when included
in the RTP header extensions; however, what it reveals of the RTP in the RTP header extensions; however, what it reveals of the RTP
media stream structure of the endpoint and application was already media stream structure of the endpoint and application was already
possible to deduce from the RTP streams without the MID SDES header possible to deduce from the RTP streams without the MID SDES header
extensions. As the identification-tag is also used to route the extensions. As the identification-tag is also used to route the
media stream to the right application functionality, it is important media stream to the right application functionality, it is important
that the value received is the one intended by the sender; thus, that the value received is the one intended by the sender; thus,
integrity and the authenticity of the source are important to prevent integrity and the authenticity of the source are important to prevent
denial of service on the application. Existing SRTP configurations denial of service on the application. Existing SRTP configurations
and other security mechanisms protecting the whole RTP/RTCP packets and other security mechanisms protecting the whole RTP/RTCP packets
skipping to change at page 44, line 24 skipping to change at line 2023
their classification in [RFC8859]. their classification in [RFC8859].
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] require Control Protocol (RTCP) Source Description Items" [RFC7941] require
that when RTCP is confidentiality protected, any SDES RTP header that when RTCP is confidentiality protected, any SDES RTP header
extension carrying an SDES item, such as the MID RTP 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.
Therefore, this specification updates RFC 7941 by adding the Therefore, this specification updates [RFC7941] by adding the
exception that this requirement MAY be ignored for the MID RTP header exception that this requirement MAY be ignored for the MID RTP header
extension. Security mechanisms for RTP/RTCP are discussed in extension. Security mechanisms for RTP/RTCP are discussed in
"Options for Securing RTP Sessions" [RFC7201], for example, SRTP "Options for Securing RTP Sessions" [RFC7201]; for example, SRTP
[RFC3711] can provide the necessary security functions of ensuring [RFC3711] can provide the necessary security functions of ensuring
the integrity and source authenticity. the integrity and source authenticity.
18. Examples 18. Examples
18.1. Example: Tagged "m=" Section Selections 18.1. Example: Tagged "m=" Section Selections
The example below shows: The example below shows:
* An initial BUNDLE offer, in which the offerer wants to negotiate a * An initial BUNDLE offer, in which the offerer wants to negotiate a
skipping to change at page 55, line 16 skipping to change at line 2453
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>.
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445, Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018, DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/info/rfc8445>. <https://www.rfc-editor.org/info/rfc8445>.
[RFC8839] Petit-Huguenin, M., Nandakumar, S., Holmberg, C., Keranen, [RFC8839] Petit-Huguenin, M., Nandakumar, S., Holmberg, C., Keränen,
A., and R. Shpount, "Session Description Protocol (SDP) A., and R. Shpount, "Session Description Protocol (SDP)
Offer/Answer Procedures for Interactive Connectivity Offer/Answer Procedures for Interactive Connectivity
Establishment (ICE)", RFC 8839, DOI 10.17487/RFC8839, Establishment (ICE)", RFC 8839, DOI 10.17487/RFC8839,
January 2021, <https://www.rfc-editor.org/info/rfc8839>. January 2021, <https://www.rfc-editor.org/info/rfc8839>.
[RFC8840] Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A [RFC8840] Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A
Session Initiation Protocol (SIP) Usage for Incremental Session Initiation Protocol (SIP) Usage for Incremental
Provisioning of Candidates for the Interactive Provisioning of Candidates for the Interactive
Connectivity Establishment (Trickle ICE)", RFC 8840, Connectivity Establishment (Trickle ICE)", RFC 8840,
DOI 10.17487/RFC8840, January 2021, DOI 10.17487/RFC8840, January 2021,
skipping to change at page 55, line 42 skipping to change at line 2479
DOI 10.17487/RFC8858, January 2021, DOI 10.17487/RFC8858, January 2021,
<https://www.rfc-editor.org/info/rfc8858>. <https://www.rfc-editor.org/info/rfc8858>.
[RFC8859] Nandakumar, S., "A Framework for Session Description [RFC8859] Nandakumar, S., "A Framework for Session Description
Protocol (SDP) Attributes When Multiplexing", RFC 8859, Protocol (SDP) Attributes When Multiplexing", RFC 8859,
DOI 10.17487/RFC8859, January 2021, DOI 10.17487/RFC8859, January 2021,
<https://www.rfc-editor.org/info/rfc8859>. <https://www.rfc-editor.org/info/rfc8859>.
19.2. Informative References 19.2. Informative References
[Err6431] RFC Errata, Erratum ID 6431, RFC 8843,
<https://www.rfc-editor.org/errata/eid6431>.
[Err6437] RFC Errata, Erratum ID 6437, RFC 8843,
<https://www.rfc-editor.org/errata/eid6437>.
[LLR-RTCP] Lennox, J., Hong, D., Uberti, J., Holmer, S., and M. [LLR-RTCP] 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", Work in Progress, Internet-Draft, draft-ietf- Message", Work in Progress, Internet-Draft, draft-ietf-
avtext-lrr-07, 2 July 2017, avtext-lrr-07, 2 July 2017,
<https://datatracker.ietf.org/doc/html/draft-ietf-avtext- <https://datatracker.ietf.org/doc/html/draft-ietf-avtext-
lrr-07>. lrr-07>.
[RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J.
Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
DOI 10.17487/RFC2543, March 1999, DOI 10.17487/RFC2543, March 1999,
skipping to change at page 57, line 16 skipping to change at line 2555
"JavaScript Session Establishment Protocol (JSEP)", "JavaScript Session Establishment Protocol (JSEP)",
RFC 8829, DOI 10.17487/RFC8829, January 2021, RFC 8829, DOI 10.17487/RFC8829, January 2021,
<https://www.rfc-editor.org/info/rfc8829>. <https://www.rfc-editor.org/info/rfc8829>.
[RFC8838] Ivov, E., Uberti, J., and P. Saint-Andre, "Trickle ICE: [RFC8838] Ivov, E., Uberti, J., and P. Saint-Andre, "Trickle ICE:
Incremental Provisioning of Candidates for the Interactive Incremental Provisioning of Candidates for the Interactive
Connectivity Establishment (ICE) Protocol", RFC 8838, Connectivity Establishment (ICE) Protocol", RFC 8838,
DOI 10.17487/RFC8838, January 2021, DOI 10.17487/RFC8838, January 2021,
<https://www.rfc-editor.org/info/rfc8838>. <https://www.rfc-editor.org/info/rfc8838>.
[RFC8843] Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", RFC 8843,
DOI 10.17487/RFC8843, January 2021,
<https://www.rfc-editor.org/info/rfc8843>.
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 offers and answers, the same port value can be been whether, in offers and answers, the same port value can be
inserted in "m=" lines associated with a BUNDLE group, as the purpose inserted in "m=" lines associated with a BUNDLE group, as the purpose
of the extension is to negotiate the usage of a single transport for of the extension is to negotiate the usage of a single transport for
media specified by the "m=" sections. Issues with both approaches, media specified by the "m=" sections. Issues with both approaches,
discussed in the Appendix, have been raised. The outcome was to discussed in Appendix A, have been raised. The outcome was to
specify a mechanism that uses offers with both different and specify a mechanism that uses offers with both different and
identical port values. 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:
1) Interoperability with existing User Agents (UAs). 1) Interoperability with existing User Agents (UAs).
2) Interoperability with intermediary Back-to-Back User Agent 2) Interoperability with intermediary Back-to-Back User Agent
(B2BUA) and proxy entities. (B2BUA) and proxy entities.
3) Time to gather, and the number of, ICE candidates. 3) The number of ICE candidates and the time to gather them.
4) Different error scenarios and when they occur. 4) Different error scenarios and when they occur.
5) SDP offer/answer impacts, including usage of port number value 5) SDP offer/answer impacts, including usage of port number value
zero. zero.
A.1. UA Interoperability A.1. UA Interoperability
Consider the following SDP offer/answer exchange, where Alice sends Consider the following SDP offer/answer exchange, where Alice sends
an offer to Bob: an offer to Bob:
skipping to change at page 58, line 28 skipping to change at line 2618
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
s= s=
c=IN IP4 biloxi.example.com c=IN IP4 biloxi.example.com
t=0 0 t=0 0
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 [RFC4961] specifies a way of doing symmetric RTP, but that is a later
extension to RTP, and Bob cannot assume that Alice supports RFC 4961. extension to RTP, and Bob cannot assume that Alice supports
This means that Alice may be sending RTP from a different port than [RFC4961]. This means that Alice may be sending RTP from a different
10000 or 10002 -- some implementations simply send the RTP from an port than 10000 or 10002 -- some implementations simply send the RTP
ephemeral port. When Bob's endpoint receives an RTP packet, the only from an ephemeral port. When Bob's endpoint receives an RTP packet,
way that Bob knows if the packet is to be passed to the video or the only way that Bob knows if the packet is to be passed to the
audio codec is by looking at the port it was received on. This video or audio codec is by looking at the port it was received on.
prompted some SDP implementations to use a port number as an index to This prompted some SDP implementations to use a port number as an
find the correct "m=" line in the SDP, since each "m"= section index to find the correct "m=" line in the SDP, since each "m"=
contains a different port number. As a result, some implementations section contains a different port number. As a result, some
that do support symmetric RTP and ICE still use an SDP data structure implementations that do support symmetric RTP and ICE still use an
where SDP with "m=" sections with the same port such as: SDP data structure where 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=
c=IN IP4 atlanta.example.com c=IN IP4 atlanta.example.com
t=0 0 t=0 0
m=audio 10000 RTP/AVP 97 m=audio 10000 RTP/AVP 97
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
m=video 10000 RTP/AVP 98 m=video 10000 RTP/AVP 98
a=rtpmap:98 H261/90000 a=rtpmap:98 H261/90000
skipping to change at page 59, line 26 skipping to change at line 2656
because it has the same port as the first line. because it has the same port as the first line.
A.2. Usage of Port Number Value Zero A.2. Usage of Port Number Value Zero
In an offer or answer, the media specified by an "m=" section can be In an offer or answer, the media specified by an "m=" section can be
disabled/rejected by setting the port number value to zero. This is disabled/rejected by setting the port number value to zero. This is
different from, e.g., using the SDP direction attributes, where RTCP different from, e.g., using the SDP direction attributes, where RTCP
traffic will continue even if the SDP 'inactive' attribute is traffic will continue even if the SDP 'inactive' attribute is
indicated for the associated "m=" section. 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 were to contain
different port values, and one of those port values would be used for different port values and one of those port values were used for a
a BUNDLE address:port associated with the BUNDLE group, problems BUNDLE address:port associated with the BUNDLE group, problems would
would occur if an endpoint wants to disable/reject the "m=" section 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 that is used for that, no "m=" section would contain the port value that is used for
the BUNDLE address:port. In addition, it is unclear what would the BUNDLE address:port. In addition, it is unclear what would
happen to the ICE candidates associated with the "m=" section, as happen to the ICE candidates associated with the "m=" section, as
they are also used for the BUNDLE address:port. 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 [RFC3605], 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
B2BUA received an offer like: B2BUA received an Offer like:
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=
c=IN IP4 atlanta.example.com c=IN IP4 atlanta.example.com
t=0 0 t=0 0
m=audio 49170 RTP/AVP 0 m=audio 49170 RTP/AVP 0
a=rtcp:53020 a=rtcp:53020
It would be looking for RTCP on port 49171 but would not see any it would be looking for RTCP on port 49171 but would not see any
because the RTCP would be on port 53020, and after five minutes, it because the RTCP would be on port 53020, and after five minutes, it
would tear down the call. Similarly, a B2BUA that did not understand would tear down the call. Similarly, a B2BUA that did not understand
BUNDLE yet put it in its offer may be looking for media on the wrong BUNDLE yet put it in its offer may be looking for media on the wrong
port and tear down the call. It is worth noting that a B2BUA that port and tear down the call. It is worth noting that a B2BUA that
generated an offer with capabilities it does not understand is not generated an Offer with capabilities it does not understand is not
compliant with the specifications. compliant with the specifications.
A.3.1. Traffic Policing A.3.1. Traffic Policing
Sometimes intermediaries do not act as B2BUAs, in the sense that they Sometimes intermediaries do not act as B2BUAs, in the sense that they
don't modify SDP bodies nor do they terminate SIP dialogs. However, don't modify SDP bodies nor do they terminate SIP dialogs. However,
they may still use SDP information (e.g., IP address and port) in they may still use SDP information (e.g., IP address and port) in
order to control traffic gating functions and to set traffic policing order to control traffic gating functions and to set traffic policing
rules. There might be rules that will trigger a session to be rules. There might be rules that will trigger a session to be
terminated in case media is not sent or received on the ports terminated in case media is not sent or received on the ports
skipping to change at page 60, line 40 skipping to change at line 2715
already established and ongoing. already established and ongoing.
A.3.2. Bandwidth Allocation A.3.2. Bandwidth Allocation
Sometimes, intermediaries do not act as B2BUAs, in the sense that Sometimes, intermediaries do not act as B2BUAs, in the sense that
they don't modify SDP bodies nor do they terminate SIP dialogs. they don't modify SDP bodies nor do they terminate SIP dialogs.
However, they may still use SDP information (e.g., codecs and media However, they may still use SDP information (e.g., codecs and media
types) in order to control bandwidth allocation functions. The types) in order to control bandwidth allocation functions. The
bandwidth allocation is done per "m=" section, which means that it bandwidth allocation is done per "m=" section, which means that it
might not be enough if media specified by all "m=" sections try to might not be enough if media specified by all "m=" sections try to
use that bandwidth. That may simply lead to either bad user use that bandwidth. That may simply lead to either a bad user
experience or termination of the call. experience or termination of the call.
A.4. Candidate Gathering A.4. Candidate Gathering
When using ICE, a candidate needs to be gathered for each port. This When using ICE, a candidate needs to be gathered for each port. This
takes approximately 20 ms extra for each extra "m=" section due to takes approximately 20 ms extra for each extra "m=" section due to
the NAT pacing requirements. All of this gathering can be overlapped the NAT pacing requirements. All of this gathering can be overlapped
with other things while, e.g., a web page is loading to minimize the with other things while, e.g., a web page is loading to minimize the
impact. If the client only wants to generate Traversal Using Relays impact. If the client only wants to generate Traversal Using Relays
around NAT (TURN) or STUN ICE candidates for one of the "m=" lines around NAT (TURN) or STUN ICE candidates for one of the "m=" lines
skipping to change at page 61, line 27 skipping to change at line 2750
is based on similar alternatives proposed by Harald Alvestrand and is based on similar alternatives proposed by Harald Alvestrand and
Cullen Jennings. The BUNDLE extension described in this document is Cullen Jennings. The BUNDLE extension described in this document is
based on the different alternative proposals, and text (e.g., SDP based on the different alternative proposals, and text (e.g., SDP
examples) has been borrowed (and, in some cases, modified) from those examples) has been borrowed (and, in some cases, modified) from those
alternative proposals. alternative proposals.
The SDP examples are also modified versions from the ones in the The SDP examples are also modified versions from the ones in the
Alvestrand proposal. Alvestrand proposal.
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 Keränen, 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, Peter Thatcher, Justin Uberti, and Magnus Thanks to Bernard Aboba, Peter Thatcher, Justin Uberti, and Magnus
Westerlund for providing the text for the section on RTP/RTCP stream Westerlund for providing the text for the section on RTP/RTCP stream
association. association.
Thanks to Magnus Westerlund, Colin Perkins, and Jonathan Lennox for Thanks to Magnus Westerlund, Colin Perkins, and Jonathan Lennox for
providing help and text on the RTP/RTCP procedures. providing help and text on the RTP/RTCP procedures.
skipping to change at page 62, line 4 skipping to change at line 2770
providing help and text on the RTP/RTCP procedures. providing help and text on the RTP/RTCP procedures.
Thanks to Charlie Kaufman for performing the Sec-Dir review. Thanks to Charlie Kaufman for performing the Sec-Dir review.
Thanks to Linda Dunbar for performing the Gen-ART review. Thanks to Linda Dunbar for performing the Gen-ART review.
Thanks to Spotify for providing music for the countless hours of Thanks to Spotify for providing music for the countless hours of
document editing. document editing.
Authors' Addresses Authors' Addresses
Christer Holmberg Christer Holmberg
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
FI-02420 Jorvas FI-02420 Jorvas
Finland Finland
Email: christer.holmberg@ericsson.com Email: christer.holmberg@ericsson.com
Harald Tveit Alvestrand Harald Tveit Alvestrand
Google Google
Kungsbron 2 Kungsbron 2
SE-11122 Stockholm SE-11122 Stockholm
Sweden Sweden
Email: harald@alvestrand.no Email: harald@alvestrand.no
Cullen Jennings Cullen Jennings
Cisco Cisco
400 3rd Avenue SW, Suite 350 Suite 350
400 3rd Avenue SW
Calgary AB T2P 4H2 Calgary AB T2P 4H2
Canada Canada
Email: fluffy@iii.ca Email: fluffy@iii.ca
 End of changes. 204 change blocks. 
584 lines changed or deleted 589 lines changed or added

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