draft-ietf-mmusic-sdp-bundle-negotiation-50.txt   draft-ietf-mmusic-sdp-bundle-negotiation-51.txt 
MMUSIC Working Group C. Holmberg MMUSIC Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 3264,7941 (if approved) H. Alvestrand Updates: 3264,7941 (if approved) H. Alvestrand
Intended status: Standards Track Google Intended status: Standards Track Google
Expires: October 26, 2018 C. Jennings Expires: November 3, 2018 C. Jennings
Cisco Cisco
April 24, 2018 May 2, 2018
Negotiating Media Multiplexing Using the Session Description Protocol Negotiating Media Multiplexing Using the Session Description Protocol
(SDP) (SDP)
draft-ietf-mmusic-sdp-bundle-negotiation-50.txt draft-ietf-mmusic-sdp-bundle-negotiation-51.txt
Abstract Abstract
This specification defines a new Session Description Protocol (SDP) This specification defines a new Session Description Protocol (SDP)
Grouping Framework extension, 'BUNDLE'. The extension can be used Grouping Framework extension, 'BUNDLE'. The extension can be used
with the SDP Offer/Answer mechanism to negotiate the usage of a with the SDP Offer/Answer mechanism to negotiate the usage of a
single transport (5-tuple) for sending and receiving media described single transport (5-tuple) for sending and receiving media described
by multiple SDP media descriptions ("m=" sections). Such transport by multiple SDP media descriptions ("m=" sections). Such transport
is referred to as a BUNDLE transport, and the media is referred to as is referred to as a BUNDLE transport, and the media is referred to as
bundled media. The "m=" sections that use the BUNDLE transport form bundled media. The "m=" sections that use the BUNDLE transport form
a BUNDLE group. a BUNDLE group.
This specification updates RFC 3264, to allow assigning a zero port This specification updates RFC 3264, to also allow assigning a zero
value to a "m=" section also in cases where the media described by port value to a "m=" section in cases where the media described by
the "m=" section is not disabled or rejected. the "m=" section is not disabled or rejected.
This specification defines a new RTP Control Protocol (RTCP) source This specification defines a new RTP Control Protocol (RTCP) source
description (SDES) item and a new RTP header extension that can be description (SDES) item and a new RTP header extension that can be
used to correlate bundled RTP/RTCP packets with their appropriate used to correlate bundled RTP/RTCP packets with their appropriate
"m=" section. "m=" section.
This specification updates RFC 7941, by adding an exception, for the This specification updates RFC 7941, by adding an exception, for the
MID RTP header extension, to the requirement regarding protection of MID RTP header extension, to the requirement regarding protection of
an SDES RTP header extension carrying an SDES item for the MID RTP an SDES RTP header extension carrying an SDES item for the MID RTP
header extension. header extension.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 26, 2018. This Internet-Draft will expire on November 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
skipping to change at page 2, line 42 skipping to change at page 2, line 42
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.2. BUNDLE Mechanism . . . . . . . . . . . . . . . . . . . . 4
4. Applicability Statement . . . . . . . . . . . . . . . . . . . 7 1.3. Protocol Extensions . . . . . . . . . . . . . . . . . . . 5
5. SDP Grouping Framework BUNDLE Extension . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. SDP 'bundle-only' Attribute . . . . . . . . . . . . . . . . . 8 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. SDP Information Considerations . . . . . . . . . . . . . . . 9 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 8
7.1. Connection Data (c=) . . . . . . . . . . . . . . . . . . 9 5. SDP Grouping Framework BUNDLE Extension . . . . . . . . . . . 8
7.2. Bandwidth (b=) . . . . . . . . . . . . . . . . . . . . . 9 6. SDP 'bundle-only' Attribute . . . . . . . . . . . . . . . . . 9
8. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 9 7. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 10
8.1. Multiplexing Category Considerations . . . . . . . . . . 10 7.1. Generic SDP Considerations . . . . . . . . . . . . . . . 10
8.2. Generating the Initial SDP Offer . . . . . . . . . . . . 11 7.1.1. Connection Data (c=) . . . . . . . . . . . . . . . . 10
8.2.1. Suggesting the Offerer BUNDLE Address:Port . . . . . 11 7.1.2. Bandwidth (b=) . . . . . . . . . . . . . . . . . . . 11
8.2.2. Example: Initial SDP Offer . . . . . . . . . . . . . 12 7.1.3. Attributes (a=) . . . . . . . . . . . . . . . . . . . 11
8.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 13 7.2. Generating the Initial SDP Offer . . . . . . . . . . . . 12
8.3.1. Answerer Selection of Offerer BUNDLE Address:Port . . 14 7.2.1. Suggesting the Offerer tagged 'm=' section . . . . . 13
8.3.2. Answerer Selection of Answerer BUNDLE Address:Port . 14 7.2.2. Example: Initial SDP Offer . . . . . . . . . . . . . 13
8.3.3. Moving A Media Description Out Of A BUNDLE Group . . 15 7.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 14
8.3.4. Rejecting a Media Description in a BUNDLE Group . . . 15 7.3.1. Answerer Selection of Offerer tagged 'm=' section . . 16
8.3.5. Example: SDP Answer . . . . . . . . . . . . . . . . . 16 7.3.2. Answerer Selection of Answerer tagged 'm=' section . 16
8.4. Offerer Processing of the SDP Answer . . . . . . . . . . 17 7.3.3. Moving A Media Description Out Of A BUNDLE Group . . 16
8.5. Modifying the Session . . . . . . . . . . . . . . . . . . 17 7.3.4. Rejecting a Media Description in a BUNDLE Group . . . 17
8.5.1. Suggesting a New Offerer BUNDLE Address:Port . . . . 18 7.3.5. Example: SDP Answer . . . . . . . . . . . . . . . . . 18
8.5.2. Adding a Media Description to a BUNDLE group . . . . 18 7.4. Offerer Processing of the SDP Answer . . . . . . . . . . 19
8.5.3. Moving a Media Description Out of a BUNDLE Group . . 19 7.5. Modifying the Session . . . . . . . . . . . . . . . . . . 19
8.5.4. Disabling a Media Description in a BUNDLE Group . . . 19 7.5.1. Adding a Media Description to a BUNDLE group . . . . 20
9. Protocol Identification . . . . . . . . . . . . . . . . . . . 20 7.5.2. Moving a Media Description Out of a BUNDLE Group . . 21
9.1. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 20 7.5.3. Disabling a Media Description in a BUNDLE Group . . . 21
10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 21 8. Protocol Identification . . . . . . . . . . . . . . . . . . . 22
10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 21 8.1. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 22
10.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . 22 9. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 23
10.2. Associating RTP/RTCP Streams with the Correct SDP Media 9.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 23
Description . . . . . . . . . . . . . . . . . . . . . . 22 9.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . . 24
10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 28 9.2. Associating RTP/RTCP Streams with the Correct SDP Media
10.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . 28 Description . . . . . . . . . . . . . . . . . . . . . . . 24
11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 30 9.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . . 30
11.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 31 9.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . 30
12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 32 10. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 32
13. RTP Header Extensions Consideration . . . . . . . . . . . . . 33 11. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 33
14. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 33 12. RTP Header Extensions Consideration . . . . . . . . . . . . . 34
14.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 33 13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 34
14.2. New text replacing section 5.1 (2nd paragraph) of RFC 13.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 34
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 34 13.2. New text replacing section 5.1 (2nd paragraph) of RFC
14.3. Original text of section 8.4 (6th paragraph) of RFC 3264 34 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 35
14.4. New text replacing section 8.4 (6th paragraph) of RFC 13.3. Original text of section 8.4 (6th paragraph) of RFC 3264 35
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 34 13.4. New text replacing section 8.4 (6th paragraph) of RFC
15. RTP/RTCP extensions for identification-tag transport . . . . 35 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 35
15.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 36 14. RTP/RTCP extensions for identification-tag transport . . . . 36
15.2. RTP SDES Header Extension For MID . . . . . . . . . . . 36 14.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 37
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 14.2. RTP SDES Header Extension For MID . . . . . . . . . . . 37
16.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 37 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
16.2. New RTP SDES Header Extension URI . . . . . . . . . . . 37 15.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 38
16.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 38 15.2. New RTP SDES Header Extension URI . . . . . . . . . . . 38
16.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 38 15.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 39
17. Security Considerations . . . . . . . . . . . . . . . . . . . 39 15.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 39
18. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 40 16. Security Considerations . . . . . . . . . . . . . . . . . . . 39
18.1. Example: BUNDLE Address:Port Selection . . . . . . . . . 40 17. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 41
18.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 41 17.1. Example: Tagged m= Section Selections . . . . . . . . . 41
18.3. Example: Offerer Adds a Media Description to a BUNDLE 17.2. Example: BUNDLE Group Rejected . . . . . . . . . . . . . 42
17.3. Example: Offerer Adds a Media Description to a BUNDLE
Group . . . . . . . . . . . . . . . . . . . . . . . . . 44 Group . . . . . . . . . . . . . . . . . . . . . . . . . 44
17.4. Example: Offerer Moves a Media Description Out of a
18.4. Example: Offerer Moves a Media Description Out of a
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 45 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 45
18.5. Example: Offerer Disables a Media Description Within a 17.5. Example: Offerer Disables a Media Description Within a
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 47 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 47
19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49
20. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 50 19. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 49
21. References . . . . . . . . . . . . . . . . . . . . . . . . . 60 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 60
21.1. Normative References . . . . . . . . . . . . . . . . . . 60 20.1. Normative References . . . . . . . . . . . . . . . . . . 60
21.2. Informative References . . . . . . . . . . . . . . . . . 63 20.2. Informative References . . . . . . . . . . . . . . . . . 62
Appendix A. Design Considerations . . . . . . . . . . . . . . . 64 Appendix A. Design Considerations . . . . . . . . . . . . . . . 64
A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 64 A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 64
A.2. Usage of Port Number Value Zero . . . . . . . . . . . . . 66 A.2. Usage of Port Number Value Zero . . . . . . . . . . . . . 66
A.3. B2BUA And Proxy Interoperability . . . . . . . . . . . . 66 A.3. B2BUA And Proxy Interoperability . . . . . . . . . . . . 66
A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 67 A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 67
A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 67 A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 67
A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 67 A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 67
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68
1. Introduction 1. Introduction
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) Interactive Connectivity Establishment (ICE)
[I-D.ietf-ice-rfc5245bis] is used). For this reason, it is [I-D.ietf-ice-rfc5245bis] is used). For this reason, it is
attractive to use a single transport for multiple media streams. attractive to use a single transport for multiple media streams.
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 same BUNDLE by multiple SDP media descriptions ("m=" sections). The address:port
transport is used for sending and receiving bundled media, which combination used by an endpoint for sending and receiving bundled
means that the symmetric Real-time Transport Protocol (RTP) mechanism media is referred to as the BUNDLE address:port. The set of SDP
[RFC4961] is always used for RTP-based bundled media. attributes that are applied to each "m=" section within a BUNDLE
group is referred to as BUNDLE attributes. The same BUNDLE transport
is used for sending and receiving bundled media, which means that the
symmetric Real-time Transport Protocol (RTP) mechanism [RFC4961] is
always used for RTP-based bundled media.
This specification defines a new SDP Grouping Framework [RFC5888] This specification defines a new SDP Grouping Framework [RFC5888]
extension called 'BUNDLE'. The extension can be used with the extension called 'BUNDLE'. The extension can be used with the
Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264] Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264]
to negotiate which "m=" sections will become part of a BUNDLE group. to negotiate which "m=" sections will become part of a BUNDLE group.
Within a BUNDLE group, each "m=" section will use a BUNDLE transport
for sending and receiving bundled media.
Within a BUNDLE group, each endpoint uses a single address:port In addition, the offerer and answerer [RFC3264] use the BUNDLE
combination for sending and receiving bundled media. The extension to negotiate the BUNDLE addresses:ports (offerer BUNDLE
address:port combination is referred to as the BUNDLE address:port. address:port and answerer BUNDLE address:port) and the set of BUNDLE
In addition to negotiating the BUNDLE group, the offerer and answerer attributes (offerer BUNDLE attributes and answerer BUNDLE attributes)
[RFC3264] use the BUNDLE extension to negotiate the BUNDLE that will be applied to each "m=" section within the BUNDLE group.
addresses:ports, one for the offerer (offerer BUNDLE address:port)
and one for the answerer (answerer BUNDLE address:port). Once the
offerer and the answerer have negotiated the BUNDLE addresses:ports,
and a BUNDLE group has been formed, they assign their respective
BUNDLE address:port to each "m=" section within the BUNDLE group.
The endpoints then use the BUNDLE addresses:ports for sending and
receiving the bundled media associated with the BUNDLE group.
The use of a BUNDLE transport allows the usage of a single set of The use of a BUNDLE transport allows the usage of a single set of
Interactive Connectivity Establishment (ICE) Interactive Connectivity Establishment (ICE)
[I-D.ietf-ice-rfc5245bis] candidates for the whole BUNDLE group. [I-D.ietf-ice-rfc5245bis] candidates for the whole BUNDLE group.
This specification defines a new SDP attribute, 'bundle-only', which
can be used to request that specific media is only used if the "m="
section describing the media is kept within a BUNDLE group.
This specification updates RFC 3264 [RFC3264], to allow assigning a
zero port value to a "m=" section also in cases where the media
described by the "m=" section is not disabled or rejected.
This specification defines a new RTP Control Protocol (RTCP)
[RFC3550] source description (SDES) item, 'MID', and a new RTP SDES
header extension that can be used to associate RTP streams with "m="
sections.
This specification updates [RFC7941], by adding an exception, for the
MID RTP header extension, to the requirement regarding protection of
an SDES RTP header extension carrying an SDES item for the MID RTP
header extension.
A given BUNDLE address:port MUST only be associated with a single A given BUNDLE address:port MUST only be associated with a single
BUNDLE group. If an SDP offer or answer contains multiple BUNDLE BUNDLE group. If an SDP offer or answer contains multiple BUNDLE
groups, the procedures in this specification apply to each group groups, the procedures in this specification apply to each group
independently. All RTP based media flows described by a single independently. All RTP-based bundled media associated with a given
BUNDLE group belong to a single RTP session [RFC3550]. BUNDLE group belong to a single RTP session [RFC3550].
The BUNDLE extension is backward compatible. Endpoints that do not The BUNDLE extension is backward compatible. Endpoints that do not
support the extension are expected to generate offers and answers support the extension are expected to generate offers and answers
without an SDP 'group:BUNDLE' attribute, and are expected to assign a without an SDP 'group:BUNDLE' attribute, and are expected to assign a
unique address:port to each "m=" section within an offer and answer, unique address:port to each "m=" section within an offer and answer,
according to the procedures in [RFC4566] and [RFC3264]. according to the procedures in [RFC4566] and [RFC3264].
1.3. Protocol Extensions
In addition to defining the new SDP Grouping Framework extension,
this specification defines the following protocol extensions and RFC
updates:
o The specification defines a new SDP attribute, 'bundle-only',
which can be used to request that a specific "m=" section (and the
associated media) is used only used if kept within a BUNDLE group.
o The specification updates RFC 3264 [RFC3264], to also allow
assigning a zero port value to a "m=" section in cases where the
media described by the "m=" section is not disabled or rejected.
o The specification defines a new RTP Control Protocol (RTCP)
[RFC3550] source description (SDES) item, 'MID', and a new RTP
SDES header extension that can be used to associate RTP streams
with "m=" sections.
o The specification updates [RFC7941], by adding an exception, for
the MID RTP header extension, to the requirement regarding
protection of an SDES RTP header extension carrying an SDES item
for the MID RTP header extension.
2. Terminology 2. Terminology
o "m=" section: SDP bodies contain one or more media descriptions, o "m=" section: SDP bodies contain one or more media descriptions,
referred to as "m=" sections. Each "m=" section is represented by referred to as "m=" sections. Each "m=" section is represented by
an SDP "m=" line, and zero or more SDP attributes associated with an SDP "m=" line, and zero or more SDP attributes associated with
the "m=" line. A local address:port combination is assigned to the "m=" line. A local address:port combination is assigned to
each "m=" section. each "m=" section.
o 5-tuple: A collection of the following values: source address, o 5-tuple: A collection of the following values: source address,
source port, destination address, destination port, and transport- source port, destination address, destination port, and transport-
skipping to change at page 6, line 18 skipping to change at page 6, line 26
o Unique address:port: An address:port combination that is assigned o Unique address:port: An address:port combination that is assigned
to only one "m=" section in an offer or answer. to only one "m=" section in an offer or answer.
o Offerer BUNDLE-tag: The first identification-tag in a given SDP o Offerer BUNDLE-tag: The first identification-tag in a given SDP
'group:BUNDLE' attribute identification-tag list in an offer. 'group:BUNDLE' attribute identification-tag list in an offer.
o Answerer BUNDLE-tag: The first identification-tag in a given SDP o Answerer BUNDLE-tag: The first identification-tag in a given SDP
'group:BUNDLE' attribute identification-tag list in an answer. 'group:BUNDLE' attribute identification-tag list in an answer.
o Suggested offerer tagged "m=" section: The bundled "m=" section
identified by the offerer BUNDLE-tag in an initial offer, before a
BUNDLE group has been negotiated.
o Offerer tagged "m=" section: The bundled "m=" section identified
by the offerer BUNDLE-tag in a subsequent offer. The "m=" section
contains characteristics (offerer BUNDLE address:port and offerer
BUNDLE attributes) applied to each "m=" section within the BUNDLE
group.
o Answerer tagged "m=" section: The bundled "m=" section identified
by the answerer BUNDLE-tag in an answer (initial or subsequent).
The "m=" section contains characteristics (answerer BUNDLE
address:port and answerer BUNDLE attributes) applied to each "m="
section within the BUNDLE group.
o BUNDLE address:port: An address:port combination that an endpoint o BUNDLE address:port: An address:port combination that an endpoint
uses for sending and receiving bundled media. uses for sending and receiving bundled media.
o Offerer BUNDLE address:port: the address:port combination used by o Offerer BUNDLE address:port: the address:port combination used by
the offerer for sending and receiving media. the offerer for sending and receiving media.
o Suggested Offerer BUNDLE address:port: before an offerer BUNDLE
address:port has been selected by the answerer, or when the
offerer wants to change a previously selected offerer BUNDLE
address:port, the address:port combination that the offerer wants
to use for sending and receiving media. While suggested by the
offerer, the selection of the offerer BUNDLE address:port is done
by the answerer.
o Answerer BUNDLE address:port: the address:port combination used by o Answerer BUNDLE address:port: the address:port combination used by
the answerer for sending and receiving media. the answerer for sending and receiving media.
o BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing category
SDP attributes. Once a BUNDLE group has been created, the
attribute values apply to each bundled "m=" section within the
BUNDLE group.
o Offerer BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing
category SDP attributes included in the offerer tagged "m="
section.
o Answerer BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing
category SDP attributes included in the answerer tagged "m="
section.
o BUNDLE transport: The transport (5-tuple) used by all media o 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.
o BUNDLE group: A set of "m=" sections, created using an SDP Offer/ o BUNDLE group: A set of bundled "m=" sections, created using an SDP
Answer exchange, which uses a single BUNDLE transport for sending Offer/Answer exchange, which uses a single BUNDLE transport, and a
and receiving all media (bundled media) described by the set of single set of BUNDLE attributes, for sending and receiving all
"m=" sections. The same BUNDLE transport is used for sending and media (bundled media) described by the set of "m=" sections. The
receiving bundled media. same BUNDLE transport is used for sending and receiving bundled
media.
o Bundled "m=" section: An "m=" section, whose identification-tag is o Bundled "m=" section: An "m=" section, whose identification-tag is
placed in an SDP 'group:BUNDLE' attribute identification-tag list placed in an SDP 'group:BUNDLE' attribute identification-tag list
in an offer or answer. in an offer or answer.
o Bundle-only "m=" section: A bundled "m=" section that contains an o Bundle-only "m=" section: A bundled "m=" section that contains an
SDP 'bundle-only' attribute. SDP 'bundle-only' attribute.
o Bundled media: All media associated with a given BUNDLE group. o Bundled media: All media associated with a given BUNDLE group.
o Initial offer: The first offer, within an SDP session (e.g. a SIP o Initial offer: The first offer, within an SDP session (e.g. a SIP
dialog when the Session Initiation Protocol (SIP) [RFC3261] is dialog when the Session Initiation Protocol (SIP) [RFC3261] is
used to carry SDP), in which the offerer indicates that it wants used to carry SDP), in which the offerer indicates that it wants
to create a given BUNDLE group. to negotiate a given BUNDLE group.
o Initial answer: The answer to an initial offer in which the
offerer indicates that it wants to negotiate a BUNDLE group, and
where the answerer accepts the creation of the BUNDLE group. The
BUNDLE group is created once the answerer sends the initial
answer.
o Subsequent offer: An offer which contains a BUNDLE group that has o Subsequent offer: An offer which contains a BUNDLE group that has
been created as part of a previous offer/answer exchange. been created as part of a previous offer/answer exchange.
o Subsequent answer: An answer to a subsequent offer.
o Identification-tag: A unique token value that is used to identify o Identification-tag: A unique token value that is used to identify
an "m=" section. The SDP 'mid' attribute [RFC5888] in an "m=" an "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 [RFC5888] "m=" section. The session-level SDP 'group' attribute [RFC5888]
carries a list of identification-tags, identifying the "m=" carries a list of identification-tags, identifying the "m="
sections associated with that particular 'group' attribute. sections associated with that particular 'group' attribute.
3. Conventions 3. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 8, line 13 skipping to change at page 8, line 49
identification-tag list is associated with a given BUNDLE group. identification-tag list is associated with a given BUNDLE group.
SDP bodies can contain multiple BUNDLE groups. Any given bundled SDP bodies can contain multiple BUNDLE groups. Any given bundled
"m=" section MUST NOT be associated with more than one BUNDLE group "m=" section MUST NOT be associated with more than one BUNDLE group
at any given time. at any given time.
NOTE: The order of the "m=" sections listed in the SDP 'group:BUNDLE' NOTE: The order of the "m=" sections listed in the SDP 'group:BUNDLE'
attribute identification-tag list does not have to be the same as the attribute identification-tag list does not have to be the same as the
order in which the "m=" sections occur in the SDP. order in which the "m=" sections occur in the SDP.
The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the The multiplexing category [I-D.ietf-mmusic-sdp-mux-attributes] for
'group:BUNDLE' attribute is 'NORMAL'. the 'group:BUNDLE' attribute is 'NORMAL'.
Section 8 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], and
hence has no value. hence 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, the offerer can extension always rejects a bundled "m=" section in an offer, the
assign a zero port value to the "m=" section. According to [RFC3264] offerer can assign a zero port value to the "m=" section. According
an answerer will reject such an "m=" section. By including an SDP to [RFC3264] an answerer will reject such an "m=" section. By
'bundle-only' attribute in such an "m=" section, the offerer can including an SDP 'bundle-only' attribute in a bundled "m=" section,
request that the answerer accepts the "m=" section if the answerer the offerer can request that the answerer accepts the "m=" section
supports the BUNDLE extension, and if the answerer keeps the "m=" only if the answerer supports the BUNDLE extension, and if the
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: Example:
a=bundle-only a=bundle-only
Once the offerer and answerer BUNDLE addresses:ports have been Once the offerer tagged "m=" section and the answerer tagged "m="
selected, an offerer and answerer only assign the BUNDLE address:port section have been selected, an offerer and answerer will include an
to one bundled "m=" section. The offerer and answerer assign a zero SDP 'bundle-only' attribute in, and assign a zero port value to,
port value and include an SDP 'bundle-only' attribute to every other every other bundled "m=" section.
bundled "m=" section.
The usage of the 'bundle-only' attribute is only defined for a The usage of the 'bundle-only' attribute is only defined for a
bundled "m=" section with a zero port value. Other usage is bundled "m=" section with a zero port value. Other usage is
unspecified. unspecified.
Section 8 defines the detailed SDP Offer/Answer procedures for the Section 7 defines the detailed SDP Offer/Answer procedures for the
'bundle-only' attribute. 'bundle-only' attribute.
7. SDP Information Considerations 7. SDP Offer/Answer Procedures
This section describes restrictions associated with the usage of SDP
parameters within a BUNDLE group. It also describes how to calculate
a value for the whole BUNDLE group, when parameter and attribute
values have been assigned to each bundled "m=" section.
7.1. Connection Data (c=)
The "c=" line nettype value [RFC4566] associated with a bundled "m="
section MUST be 'IN'.
The "c=" line addrtype value [RFC4566] associated with a bundled "m="
section MUST be 'IP4' or 'IP6'. The same value MUST be associated
with each "m=" section.
NOTE: Extensions to this specification can specify usage of the
BUNDLE mechanism for other nettype and addrtype values than the ones
listed above.
7.2. Bandwidth (b=)
An offerer and answerer MUST use the rules and restrictions defined
in [I-D.ietf-mmusic-sdp-mux-attributes] for associating the SDP
bandwidth (b=) line with bundled "m=" sections.
8. SDP Offer/Answer Procedures
This section describes the SDP Offer/Answer [RFC3264] procedures for: This section describes the SDP Offer/Answer [RFC3264] procedures for:
o Negotiating a BUNDLE group; and o Negotiating a BUNDLE group; and
o Selecting the BUNDLE addresses:ports (offerer BUNDLE address:port o Suggesting and selecting the tagged "m=" sections (offerer tagged
and answerer BUNDLE address:port); and "m=" section and answerer tagged "m=" section); and
o Adding an "m=" section to a BUNDLE group; and o Adding an "m=" section to a BUNDLE group; and
o Moving an "m=" section out of a BUNDLE group; and o Moving an "m=" section out of a BUNDLE group; and
o Disabling an "m=" section within a BUNDLE group. o Disabling an "m=" section within a BUNDLE group.
The generic rules and procedures defined in [RFC3264] and [RFC5888] The generic rules and procedures defined in [RFC3264] and [RFC5888]
also apply to the BUNDLE extension. For example, if an offer is also apply to the BUNDLE extension. For example, if an offer is
rejected by the answerer, the previously negotiated SDP parameters rejected by the answerer, the previously negotiated addresses:ports,
and characteristics (including those associated with a BUNDLE group) SDP parameters and characteristics (including those associated with a
apply. Hence, if an offerer generates an offer in which the offerer BUNDLE group) apply. Hence, if an offerer generates an offer in
wants to create a BUNDLE group, and the answerer rejects the offer, order to negotiate a BUNDLE group, and the answerer rejects the
the BUNDLE group is not created. offer, the BUNDLE group is not created.
The procedures in this section are independent of the media type or The procedures in this section are independent of the media type or
"m=" line proto value assigned to a bundled "m=" section. Section 10 "m=" line proto value assigned to a bundled "m=" section. Section 9
defines additional considerations for RTP based media. Section 6 defines additional considerations for RTP based media. Section 6
defines additional considerations for the usage of the SDP 'bundle- defines additional considerations for the usage of the SDP 'bundle-
only' attribute. Section 11 defines additional considerations for only' attribute. Section 10 defines additional considerations for
the usage of Interactive Connectivity Establishment (ICE) the usage of Interactive Connectivity Establishment (ICE)
[I-D.ietf-ice-rfc5245bis] mechanism. [I-D.ietf-ice-rfc5245bis] mechanism.
SDP offers and answers can contain multiple BUNDLE groups. The Offers and answers can contain multiple BUNDLE groups. The
procedures in this section apply independently to a given BUNDLE procedures in this section apply independently to a given BUNDLE
group. group.
8.1. Multiplexing Category Considerations 7.1. Generic SDP Considerations
When a BUNDLE group is initially negotiated, and a unique This section describes generic restrictions associated with the usage
address:port is assigned to each bundled "m=" section (excluding any of SDP parameters within a BUNDLE group. It also describes how to
bundle-only "m=" section) in the initial offer [Section 8.2], any calculate a value for the whole BUNDLE group, when parameter and
IDENTICAL and TRANSPORT multiplexing category SDP attributes included attribute values have been assigned to each bundled "m=" section.
in the BUNDLE group MUST explicitly be included in each bundled "m="
section (excluding any bundle-only "m=" sections).
When an offerer or answerer includes SDP attributes in bundled "m=" 7.1.1. Connection Data (c=)
sections within a BUNDLE group, IDENTICAL and TRANSPORT multiplexing
category SDP attributes [I-D.ietf-mmusic-sdp-mux-attributes] are only
included in the "m=" section indicated by the BUNDLE-tag in the offer
or answer. The SDP attribute values are implicitly applied to each
bundled "m=" section (including any bundle-only "m=" section). The
offerer and answerer MUST NOT include such SDP attributes in any
other bundled "m=" section.
One consequence of these rules is that media-specific IDENTICAL and The "c=" line nettype value [RFC4566] associated with a bundled "m="
TRANSPORT multiplexing category SDP attributes which are appropriate section MUST be 'IN'.
only to some other bundled "m=" sections within the BUNDLE group
might appear in the "m=" section indicated by the BUNDLE-tag. For
instance, the "m=" section indicated by the BUNDLE-tag might contain
an SDP 'rtcp-mux' attribute even if the "m=" section does not
describe RTP-based media, but another "m=" section within the BUNDLE
group does describe RTP-based media.
8.2. Generating the Initial SDP Offer The "c=" line addrtype value [RFC4566] associated with a bundled "m="
section MUST be 'IP4' or 'IP6'. The same value MUST be associated
with each "m=" section.
NOTE: Extensions to this specification can specify usage of the
BUNDLE mechanism for other nettype and addrtype values than the ones
listed above.
7.1.2. Bandwidth (b=)
An offerer and answerer MUST use the rules and restrictions defined
in [I-D.ietf-mmusic-sdp-mux-attributes] for associating the SDP
bandwidth (b=) line with bundled "m=" sections.
7.1.3. Attributes (a=)
An offerer and answerer MUST include SDP attributes in every bundled
"m=" section where applicable, following the normal offer/answer
procedures for each attribute, with the following exceptions:
o In the initial offerer, the offerer MUST NOT include IDENTICAL and
TRANSPORT multiplexing category SDP attributes (BUNDLE attributes)
in bundle-only "m=" sections. The offerer MUST included such
attributes in all other bundled "m=" sections. In the initial
offer each bundled "m=" line can contain a different set of BUNDLE
attributes, and attribute values. Once the offerer tagged "m="
section has been selected, the BUNDLE attributes contained in the
offerer tagged "m=" section will apply to each bundled "m="
section within the BUNDLE group.
o In a subsequent offer, or in an answer (initial of subsequent),
the offerer and answerer MUST include IDENTICAL and TRANSPORT
multiplexing category SDP attributes (BUNDLE attributes) only in
the tagged "m=" section (offerer tagged "m=" section or answerer
tagged "m=" section). The offerer and answerer MUST NOT include
such attributes in any other bundled "m=" section. The BUNDLE
attributes contained in the tagged "m=" section will apply to each
bundled "m=" section within the BUNDLE group.
o In an offer (initial or subsequent), or in an answer (initial or
subsequent), the offerer and answerer MUST include SDP attributes
of other categories than IDENTICAL and TRANSPORT in each bundled
"m=" section that a given attribute applies to. Each bundled "m="
line can contain a different set of such attributes, and attribute
values, as such attributes only apply to the given bundled "m="
section in which they are included.
NOTE: A consequence of the rules above is that media-specific
IDENTICAL and TRANSPORT multiplexing category SDP attributes which
are applicable only to some of the bundled "m=" sections within the
BUNDLE group might appear in the tagged "m=" section for which they
are not applicable. For instance, the tagged "m=" section might
contain an SDP 'rtcp-mux' attribute even if the tagged "m=" section
does not describe RTP-based media (but another bundled "m=" section
within the BUNDLE group does describe RTP-based media).
7.2. Generating the Initial SDP Offer
When an offerer generates an initial offer, in order to negotiate a When an offerer generates an initial offer, in order to negotiate a
BUNDLE group, it MUST: BUNDLE group, it MUST:
o Assign a unique address:port to each "m=" section within the o Assign a unique address:port to each bundled "m=" section,
offer, following the procedures in [RFC3264], excluding any following the procedures in [RFC3264], excluding any bundle-only
bundle-only "m=" sections (see below); and "m=" sections (see below); and
o Pick a bundled "m=" section as the suggested offerer tagged "m="
section [Section 7.2.1]; and
o Include SDP attributes in the bundled "m=" sections following the
rules in [Section 7.1.3]; and
o Include an SDP 'group:BUNDLE' attribute in the offer; and o Include an SDP 'group:BUNDLE' attribute in the offer; and
o Place the identification-tag of each bundled "m=" section in the o Place the identification-tag of each bundled "m=" section in the
SDP 'group:BUNDLE' attribute identification-tag list; and SDP 'group:BUNDLE' attribute identification-tag list. The offerer
BUNDLE-tag indicates the suggested offerer tagged "m=" section.
o Indicate which unique address:port the offerer suggests as the
offerer BUNDLE address:port [Section 8.2.1].
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 address:port combination has associated answer and finds out which bundled "m=" section (and
been selected as the offerer BUNDLE-address. associated address:port combination) the answerer has selected as 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 accepts a given
bundled "m=" section only if the answerer keeps the "m=" section bundled "m=" section only if the answerer keeps the "m=" section
within the BUNDLE group, the offerer MUST: within the negotiated BUNDLE group, the offerer MUST:
o Assign a zero port value to the "m=" section; and o Include an SDP 'bundle-only' attribute [Section 7.2.1] in the "m="
section; and
o Include an SDP 'bundle-only' attribute [Section 8.2.1] in the "m=" o Assign a zero port value to the "m=" section.
section.
NOTE: If the offerer assigns a zero port value to an "m=" section, NOTE: If the offerer assigns a zero port value to a bundled "m="
but does not include an SDP 'bundle-only' attribute in the "m=" section, but does not include an SDP 'bundle-only' attribute in the
section, it is an indication that the offerer wants to disable the "m=" section, it is an indication that the offerer wants to disable
"m=" section [Section 8.5.4]. the "m=" section [Section 7.5.3].
[Section 8.2.2] and [Section 18.1] show an example of an initial [Section 7.2.2] and [Section 17.1] show an example of an initial
offer. offer.
8.2.1. Suggesting the Offerer BUNDLE Address:Port 7.2.1. Suggesting the Offerer tagged 'm=' section
In the offer, the address:port combination assigned to the "m=" In the initial offer, the bundled "m=" section indicated by the
section indicated by the offerer BUNDLE-tag indicates the offerer offerer BUNDLE-tag is the suggested offerer tagged "m=" section. The
BUNDLE address:port, i.e., the address:port combination that the address:port combination associated with the "m=" section will be
offerer suggests for sending and receiving bundled media. used by the offerer for sending and receiving bundled media if the
answerer selects the "m=" section as the offerer tagged "m=" section
[Section 7.3.1]. In addition, if the answerer selects the "m="
section as the offerer tagged "m=" section, the BUNDLE attributes
included in the "m=" section will be applied to each "m=" section
within the negotiated BUNDLE group.
The offerer BUNDLE-tag MUST NOT represent a bundle-only "m=" section. The offerer MUST NOT suggest a bundle-only "m=" section as the
Hence, the offer MUST contain at least one bundled "m=" section with offerer tagged "m=" section.
a unique address:port (and a non-zero port value).
It is RECOMMENDED that the offerer assigns the suggested offerer It is RECOMMENDED that the suggested offerer tagged "m=" section is a
BUNDLE address:port to a bundled "m=" section that the offerer bundled "m=" section that the offerer believes it is unlikely that
believes it is unlikely that the answerer will reject, or move out of the answerer will reject, or move out of the BUNDLE group. How such
the BUNDLE group. How such assumption is made is outside the scope assumption is made is outside the scope of this document.
of this document.
8.2.2. Example: Initial SDP Offer 7.2.2. Example: Initial SDP Offer
The example shows an initial SDP offer. The offer includes two "m=" The example shows an initial offer. The offer includes two "m="
sections in the SDP, and suggests that both are included in a BUNDLE sections in the offer, and suggests that both "m=" sections are
group. The audio "m=" section is indicated by the offerer BUNDLE-tag included in a BUNDLE group. The audio "m=" section is the suggested
(placed first in the SDP group:BUNDLE attribute identification-id offerer tagged "m=" section, indicated by placing the identification-
list). tag associated with the "m=" section (offerer BUNDLE-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 13, line 5 skipping to change at page 14, line 31
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 10002 RTP/AVP 31 32 m=video 10002 RTP/AVP 31 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=rtcp-mux a=rtcp-mux
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
8.3. Generating the SDP Answer 7.3. Generating the SDP Answer
When an answerer generates an answer that contains a BUNDLE group the When an answerer generates an answer (initial or subsequent) that
following general SDP grouping framework restrictions, defined in contains a BUNDLE group the following general SDP grouping framework
[RFC5888], also apply to the BUNDLE group: restrictions, defined in [RFC5888], also apply to the BUNDLE group:
o The answerer is only allowed to include a BUNDLE group in the o The answerer is only allowed to include a BUNDLE group in an
answer if the offerer requested the BUNDLE group to be negotiated initial answer if the offerer requested the BUNDLE group to be
in the corresponding offer; and created in the corresponding initial offer; and
o The answerer is only allowed to include an "m=" section within a o The answerer is only allowed to include a BUNDLE group in a
BUNDLE group if the offerer requested the "m=" section to be subsequent answer if the corresponding subsequent offer contains a
within that same BUNDLE group in the corresponding offer. previously negotiated BUNDLE group; and
If the answer contains a BUNDLE group, the answerer MUST: o The answerer is only allowed to include a bundled "m=" section in
an answer if the "m=" section was indicated as bundled in the
corresponding offer; and
o Select an offerer BUNDLE address:port [Section 8.3.1]; and o The answerer is only allowed to include a bundled "m=" section in
the same BUNDLE group as the bundled "m=" line in the
corresponding offer.
o Select an answerer BUNDLE address:port [Section 8.3.2]. In addition, when an answerer generates an answer (initial or
subsequent) that contains a BUNDLE group, the answerer MUST:
The answerer is allowed to select a new answerer BUNDLE address:port o In case of an initial answer, select the offerer tagged "m="
each time it generates an answer to an offer. section using the procedures in Section 7.3.1. In case of a
subsequent answer, the offerer tagged "m=" section is indicated in
the corresponding subsequent offer, and MUST NOT be changed by the
answerer; and
o Select the answerer tagged "m=" section [Section 7.3.2]; and
o Assign the answerer BUNDLE address:port to the answerer tagged
"m=" section; and
o Include an SDP 'bundle-only' attribute in, and assign a zero port
value to, every other bundled "m=" section within the BUNDLE
group; and
o Include SDP attributes in the bundled "m=" sections following the
rules in [Section 7.1.3]; and
o Include an SDP 'group:BUNDLE' attribute in the answer; and
o Place the identification-tag of each bundled "m=" section in the
SDP 'group:BUNDLE' attribute identification-tag list. The
answerer BUNDLE-tag indicates the answerer tagged "m=" section
[Section 7.3.2].
If the answerer does not want to keep an "m=" section within a BUNDLE If the answerer does not want to keep an "m=" section within a BUNDLE
group, it MUST: group, it MUST:
o Move the "m=" section out of the BUNDLE group [Section 8.3.3]; or o Move the "m=" section out of the BUNDLE group [Section 7.3.3]; or
o Reject the "m=" section [Section 8.3.4].
When the answerer creates the answer, it selects the offerer BUNDLE o Reject the "m=" section [Section 7.3.4].
address:port [Section 8.3.1] and the answerer BUNDLE address:port
[Section 8.3.2]. The answerer then assigns the answerer BUNDLE
address:port to the bundled "m=" section indicated by the answerer
BUNDLE-tag. In every other bundled "m=" section the answerer
includes an SDP 'bundle-only' attribute and assigns a zero port value
to the "m=" section.
If the answerer does not want to keep a bundle-only "m=" section The answerer can modify the answerer BUNDLE address:port, add and
within the BUNDLE group, it MUST reject the "m=" section remove SDP attributes, or modify SDP attribute values, in a
[Section 8.3.4]. subsequent answer. Changes to the answerer BUNDLE address:port and
the answerer BUNDLE attributes will be applied to each bundled "m="
section within 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 the
"m=" section [Section 8.5.4]. "m=" section [Section 7.5.3].
8.3.1. Answerer Selection of Offerer BUNDLE Address:Port 7.3.1. Answerer Selection of Offerer tagged 'm=' section
In an offer, the bundled "m=" section indicated by the offerer When the answerer selects the offerer tagged "m=" section, it first
BUNDLE-tag contains the suggested offerer BUNDLE address:port, i.e, checks the suggested offerer tagged "m=" section [Section 7.2.1].
the address:port combination that the offerer wants to use for The answerer MUST check whether the "m=" section fulfils the
sending and receiving bundled media [Section 8.2.1]. The answerer following criteria:
MUST check whether that "m=" section fulfils the following criteria:
o The answerer will not move the "m=" section out of the BUNDLE o The answerer will not move the "m=" section out of the BUNDLE
group [Section 8.3.3]; and group [Section 7.3.3]; and
o The answerer will not reject the "m=" section [Section 8.3.4]; and o The answerer will not reject the "m=" section [Section 7.3.4]; and
o The "m=" section does not contain a zero port value. o The "m=" section does not contain a zero port value.
If all of the criteria above are fulfilled, the answerer MUST select If all of the criteria above are fulfilled, the answerer MUST select
the suggested offerer BUNDLE address:port. the "m=" section as the offerer tagged "m=" section.
If one or more of the criteria are not fulfilled, the answerer MUST If one or more of the criteria are not fulfilled, the answerer MUST
pick the next identification-tag in the identification-tag list in pick the next identification-tag in the identification-tag list in
the offer, and perform the same criteria check for the "m=" section the offer, and perform the same criteria check for the "m=" section
indicated by that identification-tag. If there are no more indicated by that identification-tag. If there are no more
identification-tags in the identification-tag list, the answerer MUST identification-tags in the identification-tag list, the answerer MUST
NOT create the BUNDLE group. Unless the answerer rejects the whole NOT create the BUNDLE group. Unless the answerer rejects the whole
offer, the answerer MUST apply the answerer procedures for moving an offer, the answerer MUST apply the answerer procedures for moving an
"m=" section out of a BUNDLE group [Section 8.3.3] or rejecting an "m=" section out of a BUNDLE group [Section 7.3.3] or rejecting an
"m=" section within a BUNDLE group [Section 8.3.4] to every bundled "m=" section within a BUNDLE group [Section 7.3.4] to every bundled
"m=" section in the offer when creating the answer. "m=" section in the offer when creating the answer.
[Section 18.1] shows an example of an offerer BUNDLE address:port [Section 17.1] shows an example of an offerer BUNDLE address:port
selection. selection.
8.3.2. Answerer Selection of Answerer BUNDLE Address:Port 7.3.2. Answerer Selection of Answerer tagged 'm=' section
When the answerer selects a BUNDLE address:port for itself (answerer
BUNDLE address:port), the answerer MUST assign the answerer BUNDLE
address:port to the "m=" section that contains the selected offerer
BUNDLE address:port in the corresponding offer. The answerer BUNDLE-
tag represents that "m=" section in the answer. To every other
bundled "m=" section the answerer MUST assign a zero port value and
include an SDP 'bundle-only' attribute.
The answerer MUST NOT assign an answerer BUNDLE address:port to an The answerer MUST select the "m=" section in that corresponds to the
"m=" section that is not within the BUNDLE group, or to an "m=" selected offerer tagged "m=" section in the corresponding offer
section that is within another BUNDLE group. [Section 7.3.1] as the answerer tagged "m=" section. In the answer
the answerer BUNDLE-tag indicates the answerer tagged "m=" section.
[Section 8.3.5] and [Section 18.1] show an example of an answerer [Section 7.3.5] and [Section 17.1] show an example of an answerer
BUNDLE address:port selection. tagged "m=" section selection.
8.3.3. Moving A Media Description Out Of A BUNDLE Group 7.3.3. Moving A Media Description Out Of A BUNDLE Group
When an answerer wants to move a bundled "m=" section out of a BUNDLE When an answerer generates the answer, if the answerer wants to move
group in an answer, it MUST first check the following criteria: a bundled "m=" section out of the negotiated BUNDLE group, the
answerer MUST first check the following criteria:
o In the corresponding offer, an offerer BUNDLE address:port o In the corresponding offer, the "m=" section is within a
(previously selected [Section 8.3.1] or newly suggested previously negotiated BUNDLE group; and
[Section 8.5.1]) has been assigned to the "m=" section by the
offerer; or
o In the corresponding offer, the "m=" section contains an SDP o In the corresponding offer, the "m=" section contains an SDP
'bundle-only' attribute and a zero port value. 'bundle-only' attribute.
If either criterium above is fulfilled the answerer can not move the If either criterium above is fulfilled the answerer can not move the
"m=" section out of the BUNDLE group in the answer. The answerer can "m=" section out of the BUNDLE group in the answer. The answerer can
either reject the whole offer, reject each bundled "m=" section either reject the whole offer, reject each bundled "m=" section
within the BUNDLE group [Section 8.3.4], or keep the "m=" section within the BUNDLE group [Section 7.3.4], or keep the "m=" section
within the BUNDLE group in the answer and later create an offer where within the BUNDLE group in the answer and later create an offer where
the "m=" section is moved out of the BUNDLE group [Section 8.5.3]. the "m=" section is moved out of the BUNDLE group [Section 7.5.2].
NOTE: One consequence of the rules above is that, once a BUNDLE group
has been negotiated, a bundled "m=" section can not be moved 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:
o MUST assign a unique address:port to the "m=" section; and o MUST assign a unique address:port to the "m=" section; and
o MUST include any applicable SDP attribute in the "m=" section,
using the normal offer/answer procedures for the each Attributes;
and
o MUST NOT place the identification-tag associated with the "m=" o MUST NOT place the identification-tag associated with the "m="
section in the SDP 'group:BUNDLE' attribute identification-tag section in the SDP 'group:BUNDLE' attribute identification-tag
list associated with the BUNDLE group; and list associated with the BUNDLE group.
o MUST NOT assign an SDP 'bundle-only' attribute to the "m=" o MUST NOT include an SDP 'bundle-only' attribute to the "m="
section. section; and
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
BUNDLE group to another within an answer [Section 8.3], if the BUNDLE group to another within an answer [Section 7.3], if the
answerer wants to move an "m=" section from one BUNDLE group to answerer wants to move an "m=" section from one BUNDLE group to
another it MUST first move the "m=" section out of the current BUNDLE another it MUST first move the "m=" section out of the current BUNDLE
group, and then generate an offer where the "m=" section is added to group, and then generate an offer where the "m=" section is added to
another BUNDLE group [Section 8.5.2]. another BUNDLE group [Section 7.5.1].
8.3.4. Rejecting a Media Description in a BUNDLE Group 7.3.4. Rejecting a Media Description in a BUNDLE Group
When an answerer wants to reject a bundled "m=" section in an answer, When an answerer wants to reject a bundled "m=" section in an answer,
it MUST first check the following criterium: it MUST first check the following criterium:
o In the corresponding offer, an offerer BUNDLE address:port o In the corresponding offer, the "m=" section is the offerer tagged
(previously selected [Section 8.3.1] or newly suggested "m=" section.
[Section 8.5.1]) has been assigned to the "m=" section by the
offerer.
If the criterium above is fulfilled the answerer can not reject the If the criterium above is fulfilled the answerer can not reject the
"m=" section in the answer (unless the answerer rejects each bundled "m=" section in the answer. The answerer can either reject the whole
"m=" section within the BUNDLE group). The answerer can either offer, reject each bundled "m=" section within the BUNDLE group, or
reject the whole offer, reject each bundled "m=" section within the keep the "m=" section within the BUNDLE group in the answer and later
BUNDLE group, or keep the "m=" section within the BUNDLE group in the create an offer where the "m=" section is disabled within the BUNDLE
answer and later create an offer where the "m=" section is disabled group [Section 7.5.3].
within the BUNDLE group [Section 8.5.4].
When an answerer generates an answer, in which it rejects a bundled When an answerer generates an answer, in which it rejects a bundled
"m=" section, the answerer: "m=" section, the answerer:
o MUST assign a zero port value to the "m=" section, according to o MUST assign a zero port value to the "m=" section, according to
the procedures in [RFC3264]; and the procedures in [RFC3264]; and
o MUST NOT place the identification-tag associated with the "m=" o MUST NOT place the identification-tag associated with the "m="
section in the SDP 'group:BUNDLE' attribute identification-tag section in the SDP 'group:BUNDLE' attribute identification-tag
list associated with the BUNDLE group; and list associated with the BUNDLE group; and
o MUST NOT assign an SDP 'bundle-only' attribute to the "m=" o MUST NOT include an SDP 'bundle-only' attribute in the "m="
section. section.
8.3.5. Example: SDP Answer 7.3.5. Example: SDP Answer
The example below shows an SDP answer, based on the SDP offer in The example below shows an answer, based on the corresponding offer
[Section 8.2.2]. The answerer accepts both "m=" sections within the in [Section 7.2.2]. The answerer accepts both bundled "m=" sections
BUNDLE group. The answerer assigns the answerer BUNDLE address:port within the created BUNDLE group. The audio "m=" section is the
to the "m=" section indicated by the answerer BUNDLE-tag. The answerer tagged "m=" section, indicated by placing the
answerer assigns a zero port value and an SDP 'bundle-only' attribute identification-tag associated with the "m=" section (answerer BUNDLE-
to the other bundled "m=" section. tag) first in the SDP group;BUNDLE attribute identification-id list.
The answerer includes an SDP 'bundle-only' attribute in, and assigns
a zero port value to, the video "m=" section.
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 17, line 28 skipping to change at page 19, line 28
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 0 RTP/AVP 32 m=video 0 RTP/AVP 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=bundle-only a=bundle-only
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
8.4. Offerer Processing of the SDP Answer 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. If there answer was indicated as bundled in the corresponding offer. If there
is no mismatch, the offerer MUST use the offerer BUNDLE address:port, is no mismatch, the offerer MUST apply the properties (BUNDLE
selected by the answerer [Section 8.3.1], as the address for each address:port, BUNDLE attributes etc) of the offerer tagged "m="
bundled "m=" section. section (selected by the answerer [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=" sections
or move a bundled "m=" section out of a BUNDLE group, a given bundled in an initial offer, or move a bundled "m=" section out of a BUNDLE
"m=" section in the offer might not be indicated as bundled in the group, a given bundled "m=" section in the offer might not be
corresponding answer. 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.
8.5. Modifying the Session 7.5. Modifying the Session
When an offerer generates a subsequent offer (i.e., a BUNDLE group
has previously been negotiated), it MUST assign the previously
selected offerer BUNDLE address:port [Section 8.3.1], or a newly
suggested offerer BUNDLE address:port [Section 8.5.1], to exactly one
"m=" section within the BUNDLE group.
The offerer MUST NOT assign an offerer BUNDLE address:port
(previously selected [Section 8.3.1] or newly suggested
[Section 8.5.1]) to a bundled "m=" section if:
o The offerer wants to move the bundled "m=" section out of the
BUNDLE group [Section 8.5.3]; or
o The offerer wants to disable the bundled "m=" section
[Section 8.5.4].
To every other "m=" section within the BUNDLE group, the offerer MUST When a BUNDLE group has previously been negotiated, and an offerer
assign a zero port value and an SDP 'bundle-only' attribute. generates a subsequent offer, the offerer MUST:
When the offerer generates a subsequent offer, the offerer BUNDLE-tag o Pick one bundled "m=" section as the offerer tagged "m=" section.
MUST represent the bundled "m=" section to which the offerer BUNDLE The offerer can either pick the "m=" section that was previously
address:port (previously negotiated or newly suggested) has been selected by the answerer as the offerer tagged "m=" section, or
assigned. pick another bundled "m=" section within the BUNDLE group; and
8.5.1. Suggesting a New Offerer BUNDLE Address:Port o Assign a BUNDLE address:port (previously negotiated or newly
suggest) to the offerer tagged "m=" section; and
When an offerer generates an offer, in which it suggests a new o Include an SDP 'bundle-only' attribute in, and assign a zero port
offerer BUNDLE address:port [Section 8.2.1], the offerer MUST: value to, every other bundled "m=" section within the BUNDLE
group; and
o Assign the newly suggested offerer BUNDLE address:port to exactly o Include SDP attributes in the bundled "m=" sections following the
one "m=" section within the BUNDLE group; and rules in [Section 7.1.3]; and
o Assign a zero port value and an SDP 'bundle-only' attribute to o Include an SDP 'group:BUNDLE' attribute in the offer; and
every other "m=" section within the BUNDLE group.
8.5.2. Adding a Media Description to a BUNDLE group o Place the identification-tag of each bundled "m=" section in the
SDP 'group:BUNDLE' attribute identification-tag list. The offerer
BUNDLE-tag indicates the offerer tagged "m=" section.
When an offerer generates an offer, in which it wants to add a new The offerer MUST NOT pick a given bundled "m=" section as the offerer
bundled "m=" section, the offerer MUST: tagged "m=" section if:
o Assign the offerer BUNDLE address:port (previously selected o The offerer wants to move the "m=" section out of the BUNDLE group
[Section 8.3.1] or newly suggested [Section 8.5.1]) to the added [Section 7.5.2]; or
"m=" section; or
o Assign a zero port value and an SDP 'bundle-only' attribute to the o The offerer wants to disable the "m=" section [Section 7.5.3].
added "m=" section (in this case the offerer BUNDLE address:port
is assigned to another "m=" section within the BUNDLE group).
In addition, the offerer MUST place the identification-tag associated The offerer can modify the offerer BUNDLE address:port, add and
with the added "m=" section in the SDP 'group:BUNDLE' attribute remove SDP attributes, or modify SDP attribute values, in the
identification-tag list associated with the BUNDLE group subsequent offer. Changes to the offerer BUNDLE address:port and the
[Section 8.2.1]. offerer BUNDLE attributes will (if the offer is accepted by the
answerer) be applied to each bundled "m=" section within the BUNDLE
group.
NOTE: If the offerer also wants to suggest a new offerer BUNDLE 7.5.1. Adding a Media Description to a BUNDLE group
address:port to the BUNDLE group, the offerer can assign the newly
suggested offerer BUNDLE address:port either to the added "m="
section, or to some other "m=" section within the BUNDLE group
[Section 8.5.1]. To all the other "m=" sections within the BUNDLE
group the offerer will assign an SDP 'bundle-only' attribute and a
zero port value [Section 8.5.1].
[Section 18.3] shows an example where an offerer sends an offer in When an offerer generates a subsequent offer, in which it wants to
order to add a bundled "m=" section to a BUNDLE group. add a bundled "m=" section to a previously negotiated BUNDLE group,
the offerer follows the procedures in [Section 7.5]. The offerer
either picks the added "m=" section, or an "m=" section previously
added to the BUNDLE group, as the offerer tagged "m=" section.
8.5.3. 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 an offer, in which it wants to move a When an offerer generates a subsequent offer, in which it want to
bundled "m=" section out of a BUNDLE group, the offerer: remove a bundled "m=" section from a BUNDLE group, the offerer:
o MUST assign a unique address:port to the "m=" section; and o MUST assign a unique address:port to the "m=" section; and
o MUST include SDP attributes in the "m=" section following the
normal offer/answer rules for each attribute; and
o MUST NOT place the identification-tag associated with the "m=" o MUST NOT place the identification-tag associated with the "m="
section in the SDP 'group:BUNDLE' attribute identification-tag section in the SDP 'group:BUNDLE' attribute identification-tag
list associated with the BUNDLE group; and list associated with the BUNDLE group; and
o MUST NOT assign an SDP 'bundle-only' attribute to the "m=" o MUST NOT assign an SDP 'bundle-only' attribute to the "m="
section. section.
For the other bundled "m=" sections within the BUNDLE group, the
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 8.5.2]. [Section 7.5.1].
[Section 18.4] shows an example of an offer for moving an "m=" [Section 17.4] shows an example of an offer for moving an "m="
section out of a BUNDLE group. section out of a BUNDLE group.
8.5.4. Disabling a Media Description in a BUNDLE Group 7.5.3. Disabling a Media Description in a BUNDLE Group
When an offerer generates an offer, in which it wants to disable a When an offerer generates a subsequent offer, in which it want to
bundled "m=" section, the offerer: disable a bundled "m=" section from a BUNDLE group, the offerer:
o MUST assign a zero port value to the "m=" section, following the o MUST assign a zero port value to the "m=" section, following the
procedures in [RFC4566]; and procedures in [RFC4566]; and
o MUST NOT place the identification-tag associated with the "m=" o MUST NOT place the identification-tag associated with the "m="
section in the SDP 'group:BUNDLE' attribute identification-tag section in the SDP 'group:BUNDLE' attribute identification-tag
list associated with the BUNDLE group; and list associated with the BUNDLE group; and
o MUST NOT assign an SDP 'bundle-only' attribute to the "m=" o MUST NOT assign an SDP 'bundle-only' attribute to the "m="
section. section.
[Section 18.5] shows an example of an offer and answer for disabling For the other bundled "m=" sections within the BUNDLE group, the
offerer follows the procedures in [Section 7.5].
[Section 17.5] shows an example of an offer and answer for disabling
an "m=" section within a BUNDLE group. an "m=" section within a BUNDLE group.
9. Protocol Identification 8. Protocol Identification
Each "m=" section within a BUNDLE group MUST use the same transport- Each "m=" section within a BUNDLE group MUST use the same transport-
layer protocol. If bundled "m=" sections use different upper-layer layer protocol. If bundled "m=" sections use different upper-layer
protocols on top of the transport-layer protocol, there MUST exist a protocols on top of the transport-layer protocol, there MUST exist a
publicly available specification which describes a mechanism how to publicly available specification which describes a mechanism how to
associate received data with the correct protocol for this particular associate received data with the correct protocol for this particular
protocol combination. protocol combination.
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
skipping to change at page 20, line 39 skipping to change at page 22, line 32
This document describes a mechanism to identify the protocol of This document describes a mechanism to identify the protocol of
received data among the STUN, DTLS and SRTP protocols (in any received data among the STUN, DTLS and SRTP protocols (in any
combination), when UDP is used as transport-layer protocol, but it combination), when UDP is used as transport-layer protocol, but it
does not describe how to identify different protocols transported on does not describe how to identify different protocols transported on
DTLS. While the mechanism is generally applicable to other protocols DTLS. While the mechanism is generally applicable to other protocols
and transport-layer protocols, any such use requires further and transport-layer protocols, any such use requires further
specification around how to multiplex multiple protocols on a given specification around how to multiplex multiple protocols on a given
transport-layer protocol, and how to associate received data with the transport-layer protocol, and how to associate received data with the
correct protocols. correct protocols.
9.1. STUN, DTLS, SRTP 8.1. STUN, DTLS, 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 protocols protocol of a received packet among the STUN, DTLS and SRTP protocols
(in any combination). If an offer or answer includes a bundled "m=" (in any combination). If an offer or answer includes a bundled "m="
section that represents these protocols, the offerer or answerer MUST section that represents these protocols, the offerer or answerer MUST
support the mechanism described in [RFC5764], and no explicit support the mechanism described in [RFC5764], and no explicit
negotiation is required in order to indicate support and usage of the negotiation is required in order to indicate support and usage of the
mechanism. mechanism.
[RFC5764] does not describe how to identify different protocols [RFC5764] does not describe how to identify different protocols
transported on DTLS, only how to identify the DTLS protocol itself. transported on DTLS, only how to identify the DTLS protocol itself.
If multiple protocols are transported on DTLS, there MUST exist a If multiple protocols are transported on DTLS, there MUST exist a
specification describing a mechanism for identifying each individual specification describing a mechanism for identifying each individual
protocol. In addition, if a received DTLS packet can be associated protocol. In addition, if a received DTLS packet can be associated
with more than one "m=" section, there MUST exist a specification with more than one "m=" section, there MUST exist a specification
which describes a mechanism for associating the received DTLS packets which describes a mechanism for associating the received DTLS packets
with the correct "m=" section. with the correct "m=" section.
[Section 10.2] describes how to associate the packets in a received [Section 9.2] describes how to associate the packets in a received
SRTP stream with the correct "m=" section. SRTP stream with the correct "m=" section.
10. RTP Considerations 9. RTP Considerations
10.1. Single RTP Session 9.1. Single RTP Session
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 SSRC numbering space [RFC3550]. share a single SSRC numbering space [RFC3550].
The following rules and restrictions apply for a single RTP session: The following rules and restrictions apply for a single RTP session:
o A specific payload type value can be used in multiple bundled "m=" o 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 10.1.1]. number shares an identical codec configuration [Section 9.1.1].
o The proto value in each bundled RTP-based "m=" section MUST be o The proto value in each bundled RTP-based "m=" section MUST be
identical (e.g., RTP/AVPF). identical (e.g., RTP/AVPF).
o The RTP MID header extension MUST be enabled, by including an SDP o 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, in each bundled RTP-based "m=" section hdrext:sdes:mid' URI value, in each bundled RTP-based "m=" section
in every offer and answer. in every offer and answer.
o A given SSRC MUST NOT transmit RTP packets using payload types o A given SSRC MUST NOT transmit RTP packets using payload types
skipping to change at page 22, line 11 skipping to change at page 24, line 5
sending an RTCP BYE packet), that SSRC can be reused by another sending an RTCP BYE packet), that SSRC can be reused by another
source (possibly associated with a different bundled "m=" section) source (possibly associated with a different bundled "m=" section)
after a delay of 5 RTCP reporting intervals (the delay is to ensure after a delay of 5 RTCP reporting intervals (the delay is to ensure
the SSRC has timed out, in case the RTCP BYE packet was lost the SSRC has timed out, in case the RTCP BYE packet was lost
[RFC3550]). [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.
10.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. configuration and packetization.
[I-D.ietf-mmusic-sdp-mux-attributes] lists SDP attributes, whose [I-D.ietf-mmusic-sdp-mux-attributes] lists SDP attributes, whose
attribute values are required to be identical for all codecs that use attribute values are required to be identical for all codecs that use
the same payload type value. the same payload type value.
10.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, a RTCP to identify which RTP streams the packet relates to. However, a RTCP
packet can contain multiple SSRC fields, in the course of providing packet can contain multiple SSRC fields, in the course of providing
feedback or reports on different RTP streams, and therefore can be feedback or reports on different RTP streams, and therefore can be
associated with multiple such streams. associated with multiple such streams.
skipping to change at page 23, line 14 skipping to change at page 25, line 8
that information. Due to this, before the offerer has received the that information. Due to this, before the offerer has received the
answer, the offerer will not be able to associate an RTP stream with answer, the offerer will not be able to associate an RTP stream with
the correct "m=" section using the SSRC value associated with the RTP the correct "m=" section using the SSRC value associated with the RTP
stream. In addition, the offerer and answerer may start using new stream. In addition, the offerer and answerer may start using new
SSRC values mid-session, without informing each other using the SDP SSRC values mid-session, without informing each other using the SDP
'ssrc' attribute. 'ssrc' attribute.
In order for an offerer and answerer to always be able to associate In order for an offerer and answerer to always be able to associate
an RTP stream with the correct "m=" section, the offerer and answerer an RTP stream with the correct "m=" section, the offerer and answerer
using the BUNDLE extension MUST support the mechanism defined in using the BUNDLE extension MUST support the mechanism defined in
Section 15, where the offerer and answerer insert the identification- Section 14, 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 14. Since a compound RTCP packet
can contain multiple RTCP SDES packets, and each RTCP SDES packet can can contain multiple RTCP SDES packets, and each RTCP SDES packet can
contain multiple chunks, a single RTCP packet can contain several contain multiple chunks, a single RTCP packet can contain several
SSRC to identification-tag mappings. The offerer and answerer SSRC to identification-tag mappings. The offerer and answerer
maintain tables used for routing that are updated each time an RTP/ maintain tables used for routing that are updated each time an RTP/
RTCP packet contains new information that affects how packets are to RTCP packet contains new information that affects how packets are to
be routed. be routed.
However, some legacy implementations may not include this However, some legacy implementations may not include this
identification-tag in their RTP and RTCP traffic when using the identification-tag in their RTP and RTCP traffic when using the
BUNDLE mechanism, and instead use a payload type based mechanism to BUNDLE mechanism, and instead use a payload type based mechanism to
skipping to change at page 28, line 13 skipping to change at page 30, line 5
to a prior TSTR. to a prior TSTR.
Temporary Maximum Media Bit Rate Notification (TMMBN): [RFC5104] Temporary Maximum Media Bit Rate Notification (TMMBN): [RFC5104]
(PT=RTPFB, FMT=4). This message is a notification in response (PT=RTPFB, FMT=4). This message is a notification in response
to a prior TMMBR, but can also be sent unsolicited. to a prior TMMBR, but can also 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
recognise the APP packet, then it MUST be discarded. recognise the APP packet, then it MUST be discarded.
10.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 media specified by the multiplexing [RFC5761] for the RTP-based bundled media (i.e., the
BUNDLE group. In addition, the offerer and answerer MUST support the same transport will be used for both RTP packets and RTCP packets).
SDP 'rtcp-mux-only' attribute [I-D.ietf-mmusic-mux-exclusive]. In addition, the offerer and answerer MUST support the SDP 'rtcp-mux-
only' attribute [I-D.ietf-mmusic-mux-exclusive].
When RTP/RTCP multiplexing is enabled, the same transport will be
used for both RTP packets and RTCP packets associated with the BUNDLE
group.
10.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' attribute [RFC5761] and the SDP 'rtcp-mux-only' attribute mux' attribute [RFC5761] and the SDP 'rtcp-mux-only' attribute
[I-D.ietf-mmusic-mux-exclusive] to negotiate usage of RTP/RTCP [I-D.ietf-mmusic-mux-exclusive] to negotiate usage of RTP/RTCP
multiplexing for RTP-based media associated with a BUNDLE group. multiplexing for RTP-based bundled media.
The mux category [I-D.ietf-mmusic-sdp-mux-attributes] of the SDP
'rtcp-mux' and 'rtcp-mux-only' attributes is IDENTICAL. Section 8.1
describes the details regarding which bundled "m=" sections an
offerer and answerer associates the attributes with.
RTP/RTCP multiplexing only applies to RTP-based media. However, as RTP/RTCP multiplexing only applies to RTP-based media. However, as
described in Section 8.1, within a BUNDLE group the SDP 'rtcp-mux' described in Section 7.1.3, within an offer or answer the SDP 'rtcp-
and SDP 'rtcp-mux-only' attributes might be included in a non-RTP- mux' and SDP 'rtcp-mux-only' attributes might be included in a
based bundled "m=" section (if such "m=" line is indicated by a bundled "m=" section for non-RTP-based media (if such "m=" section is
BUNDLE-tag). the offerer tagged "m=" section or answerer tagged "m=" section).
NOTE: The offer in which the offerer indicates that it wants to
create a BUNDLE group can be the initial offer of the session, or a
subsequent offer within the session. As defined in Section 2, within
the scope of this document the initial offer always refers to the
offer in which the offerer indicates that it wants to create a BUNDLE
group, no matter whether that offer is the initial offer, or a
subsequent offer, within the session.
10.3.1.1. Generating the Initial SDP Offer 9.3.1.1. Generating the Initial SDP Offer
When an offerer generates an initial offer, if the offer contains one When an offerer generates an initial offer, if the offer contains one
or more RTP-based bundled "m=" sections (or, if there is a chance or more bundled "m=" sections for RTP-based media (or, if there is a
that RTP-based "m=" sections will later be added to the BUNDLE chance that "m=" sections for RTP-based media will later be added to
group), the offerer MUST include an SDP 'rtcp-mux' attribute the BUNDLE group), the offerer MUST include an SDP 'rtcp-mux'
[RFC5761] in each bundled "m=" section (excluding any bundle-only attribute [RFC5761] in each bundled "m=" section (excluding any
"m=" sections), following the procedures for IDENTICAL mux category bundle-only "m=" sections). In addition, the offerer MAY include an
attributes in Section 8.1. In addition, the offerer MAY include an SDP 'rtcp-mux-only' attribute [I-D.ietf-mmusic-mux-exclusive] in one
SDP 'rtcp-mux-only' attribute [I-D.ietf-mmusic-mux-exclusive] in a or more bundled "m=" sections for RTP-based media.
RTP-based bundled "m=" section.
NOTE: Whether the offerer includes the SDP 'rtcp-mux-only' attribute NOTE: Whether the offerer includes the SDP 'rtcp-mux-only' attribute
depends on whether the offerer supports fallback to usage of a depends on whether the offerer supports fallback to usage of a
separate port for RTCP in case the answerer moves one or more RTP- separate port for RTCP in case the answerer moves one or more "m="
based "m=" section out of the BUNDLE group in the answer. 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 to
provide a fallback port for RTCP, as described in [RFC5761]. provide a fallback port for RTCP, as described in [RFC5761].
However, the fallback port will only be used for RTP-based "m=" However, the fallback port will only be applied to "m=" sections for
sections moved out of the BUNDLE group by the answerer. RTP-based media that are moved out of the BUNDLE group by the
answerer.
In the initial offer, the address:port combination for RTCP MUST be In the initial offer, the address:port combination for RTCP MUST be
unique in each bundled RTP-based "m=" section (excluding a bundle- unique in each bundled "m=" section for RTP-based media (excluding a
only "m=" section), similar to RTP. bundle-only "m=" section), similar to RTP.
10.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 offer contained an based media, and if a bundled "m=" section in the corresponding offer
SDP 'rtcp-mux' attribute, the answerer MUST enable usage of RTP/RTCP contained an SDP 'rtcp-mux' attribute, the answerer MUST enable usage
multiplexing, even if there currently are no RTP-based "m=" sections of RTP/RTCP multiplexing, even if there currently are no bundled "m="
within the BUNDLE group. The answerer MUST include an SDP 'rtcp-mux' sections for RTP-based media within the BUNDLE group. The answerer
attribute in the bundled "m=" section indicated by the answerer MUST include an SDP 'rtcp-mux' attribute in the answerer tagged "m="
BUNDLE-tag, following the procedures for IDENTICAL mux category section, following the procedures for BUNDLE attributes
attributes in Section 8.1. In addition, if the "m=" section in the [Section 7.1.3]. In addition, if the "m=" section that is selected
offer contained an SDP "rtcp-mux-only" attribute, the answerer MUST as the offerer tagged "m=" section contained an SDP "rtcp-mux-only"
include an SDP "rtcp-mux-only" attribute in the bundled "m=" section attribute, the answerer MUST include an SDP "rtcp-mux-only" attribute
indicated by the answerer BUNDLE-tag in the answer. in the answerer tagged "m=" section.
If the "m=" section indicated by the offerer BUNDLE-tag in the offer In an initial offer, if the suggested offerer tagged "m=" section
contained an SDP 'rtcp-mux-only' attribute, and if the answerer moves contained an SDP 'rtcp-mux-only' attribute, the "m=" section was for
an RTP-based "m=" section out of the BUNDLE group in the answer RTP-based media, and the answerer does not accept the "m=" section in
[Section 8.3.3], the answerer MUST either include the attribute in the created BUNDLE group, the answerer MUST either move the "m="
the moved "m=" section (and enable RTP/RTCP multiplexing for the section out of the BUNDLE group [Section 7.3.3], include the
media associated with the "m=" section), or reject the "m=" section attribute in the moved "m=" section and enable RTP/RTCP multiplexing
[Section 8.3.4]. for the media associated with the "m=" section, or reject the "m="
section [Section 7.3.4].
The answerer MUST NOT include an SDP 'rtcp' attribute in any "m=" The answerer MUST NOT include an SDP 'rtcp' attribute in any bundled
section within the BUNDLE group in the answer. The answerer will use "m=" section in the answer. The answerer will use the port value of
the port value of the selected offerer BUNDLE address:port for the tagged offerer "m=" section sending RTP and RTCP packets
sending RTP and RTCP packets associated with each RTP-based bundled associated with RTP-based bundled media towards the offerer.
"m=" section towards the offerer.
If the usage of RTP/RTCP multiplexing within a BUNDLE group has been If the usage of RTP/RTCP multiplexing within a BUNDLE group has been
negotiated in a previous offer/answer exchange, the answerer MUST negotiated in a previous offer/answer exchange, the answerer MUST
include an SDP 'rtcp-mux' attribute in the "m=" section associated include an SDP 'rtcp-mux' attribute in the answerer tagged "m="
with the answerer BUNDLE-tag in the answer. It is not possible to section . It is not possible to disable RTP/RTCP multiplexing within
disable RTP/RTCP multiplexing within a BUNDLE group. a BUNDLE group.
10.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 (see Section 10.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 associated with the [RFC5761]. The offerer will use the port value of the answerer
answerer BUNDLE address:port for sending RTP and RTCP packets tagged "m=" section for sending RTP and RTCP packets associated with
associated with each RTP-based bundled "m=" section towards the RTP-based bundled media towards the answerer.
answerer.
NOTE: It is considered a protocol error if the answerer has not NOTE: It is considered a protocol error if the answerer has not
accepted the usage of RTP/RTCP multiplexing for RTP-based "m=" accepted the usage of RTP/RTCP multiplexing for RTP-based "m="
sections that the answerer included in the BUNDLE group. sections that the answerer included in the BUNDLE group.
10.3.1.4. Modifying the Session 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 bundled "m=" section include an SDP 'rtcp-mux' attribute in the offerer tagged "m="
indicated by the offerer BUNDLE-tag, following the procedures for section, following the procedures for IDENTICAL multiplexing category
IDENTICAL mux category attributes in Section 8.1. attributes in Section 7.1.3.
11. ICE Considerations 10. ICE Considerations
This section describes how to use the BUNDLE grouping extension This section describes how to use the BUNDLE grouping extension
together with the Interactive Connectivity Establishment (ICE) together with the Interactive Connectivity Establishment (ICE)
mechanism [I-D.ietf-ice-rfc5245bis]. mechanism [I-D.ietf-ice-rfc5245bis].
The generic procedures for negotiating usage of ICE using SDP, The generic procedures for negotiating usage of ICE using SDP,
defined in [I-D.ietf-mmusic-ice-sip-sdp], also apply to usage of ICE defined in [I-D.ietf-mmusic-ice-sip-sdp], also apply to usage of ICE
with BUNDLE, with the following exceptions: with BUNDLE, with the following exceptions:
o When the BUNDLE transport has been established, ICE connectivity o When the BUNDLE transport has been established, ICE connectivity
checks and keep-alives only need to be performed for the BUNDLE checks and keep-alives only need to be performed for the BUNDLE
transport, instead of per individual "m=" section within the transport, instead of per individual bundled "m=" section within
BUNDLE group. the BUNDLE group.
o In an offer, if the offer assigns a unique address:port to one or o The generic SDP attribute offer/answer considerations
more bundled "m=" sections (excluding any bundle-only "m=" [Section 7.1.3] also apply to ICE-related attributes. Therefore,
sections), the offerer MUST include ICE-related media-level when an offer sends an initial offer (in order to negotiate a
attributes in each of those "m=" sections. If the offerer assigns BUNDLE group) the offerer include ICE-related media-level
an offerer BUNDLE address:port (previously selected attributes in each bundled "m=" section (excluding any bundle-only
[Section 8.3.1] or newly suggested [Section 8.5.1]) to a bundled "m=" section), and each "m=" section MUST contain unique ICE
"m=" section (the "m=" section indicated by the offerer BUNDLE- properties. When an answerer generates an answer (initial or
tag), the offerer only includes ICE-related media-level SDP subsequent) that contains a BUNDLE group, and when an offerer
attributes in that "m=" section, following the procedures in sends a subsequent offer that contains a BUNDLE group, ICE-related
Section 8.1. media-level attributes are only included in the tagged "m="
section (suggested offerer tagged "m=" section or answerer tagged
"m=" section), and the ICE properties are applied to each bundled
"m=" section within the BUNDLE group.
o In an answer, the answerer only includes ICE-related media-level NOTE: Most ICE-related media-level SDP attributes belong to the
SDP attributes in the bundled "m=" section to which the answerer TRANSPORT multiplexing category [I-D.ietf-mmusic-sdp-mux-attributes],
has assigned the answerer BUNDLE address:port (the "m=" section and the generic SDP attribute offer/answer considerations for
indicated by the answerer BUNDLE-tag), following the procedures in TRANSPORT multiplexing category apply to the attributes. However, in
Section 8.1. the case of ICE-related attributes, the same considerations also
apply to ICE-related media-level attributes that belong to other
multiplexing categories.
Initially, before ICE has produced a candidate pair that will be used NOTE: The following ICE-related media-level SDP attributes are
for media, there might be multiple transports established (if defined in [I-D.ietf-mmusic-ice-sip-sdp]: 'candidate', 'remote-
multiple candidate pairs are tested). Once ICE has produced a candidates', 'ice-mismatch', 'ice-ufrag', 'ice-pwd', and 'ice-
transport that will be used for media, that becomes the BUNDLE pacing'.
transport.
Initially, before ICE has produced selected candidate pairs that will
be used for media, there might be multiple transports established (if
multiple candidate pairs are tested). Once ICE has selected
candidate pairs, they form the BUNDLE transport.
Support and usage of ICE mechanism together with the BUNDLE extension Support and usage of ICE mechanism together with the BUNDLE extension
is OPTIONAL, and the procedures in this section only apply when the is OPTIONAL, and the procedures in this section only apply when the
ICE mechanism is used. Note that applications might mandate usage of ICE mechanism is used. Note that applications might mandate usage of
the ICE mechanism even if the BUNDLE extension is not used. the ICE mechanism even if the BUNDLE extension is not used.
11.1. SDP Offer/Answer Procedures
When an offerer assigns a unique address:port to one or more bundled
"m=" sections (excluding any bundle-only "m=" section), the offerer
MUST include SDP 'candidate' attributes (and other applicable ICE-
related media-level SDP attributes), containing unique ICE properties
(candidates etc), in each of those "m=" sections, following the
procedures in [I-D.ietf-mmusic-ice-sip-sdp].
When an offerer assigns a BUNDLE address:port (previously selected or
newly suggested) to a bundled "m=" section, (the "m=" section
indicated by the offerer BUNDLE-tag) the offerer MUST only include
SDP 'candidate' attributes (and other applicable ICE-related media-
level SDP attributes) in that "m=" section, following the procedures
in Section 8.1.
When an answerer assigns a BUNDLE address to an "m=" section within a
BUNDLE group (the "m=" section represented by the answerer BUNDLE-
tag), the answerer only includes SDP 'candidate' attributes (and
other applicable ICE-related media-level SDP attributes) in that "m="
section, following the procedures in Section 8.1. The answerer MUST
NOT include ICE-related media-level SDP attributes in any other "m="
sections.
NOTE: If the trickle ICE mechanism [I-D.ietf-mmusic-trickle-ice-sip] NOTE: If the trickle ICE mechanism [I-D.ietf-mmusic-trickle-ice-sip]
is used, an offerer and answerer might assign a port value of '9', is used, an offerer and answerer might assign a port value of '9',
and an IPv4 address of '0.0.0.0' (or, the IPv6 equivalent '::') to and an IPv4 address of '0.0.0.0' (or, the IPv6 equivalent '::') to
multiple "m=" sections. As far as the procedures in this multiple bundled "m=" sections in the initial offer. The offerer and
specification are concerned, before a BUNDLE group has been answerer will follow the normal procedures for generating the offers
negotiated, those addresses:ports are processed as unique and answers, including picking a bundled "m=" section as the
addresses:ports. suggested offerer tagged "m=" section, selecting the tagged "m="
sections etc. The only difference is that media can not be sent
NOTE: As most ICE-related media-level SDP attributes belong to the until one or more candidates have been provided. Once a BUNDLE group
TRANSPORT mux category [I-D.ietf-mmusic-sdp-mux-attributes], the has been negotiated, trickled candidates associated with a bundled
offerer and answerer follow the procedures in Section 8.1 when "m=" section will be applied to all bundled "m=" sections within the
deciding whether to include an attribute in a bundled "m=" section. BUNDLE group.
However, in the case of ICE-related media-level attributes, the rules
apply to all attributes (see note below), even if they belong to a
different mux category.
NOTE: The following ICE-related media-level SDP attributes are
defined in [I-D.ietf-mmusic-ice-sip-sdp]: 'candidate', 'remote-
candidates', 'ice-mismatch', 'ice-ufrag', 'ice-pwd', and 'ice-
pacing'.
12. 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
Datagram Transport Layer Security (DTLS) protocol [RFC6347] in order Datagram Transport Layer Security (DTLS) protocol [RFC6347] in order
to encrypt the data, or to negotiate encryption keys if another to encrypt the data, or to negotiate encryption keys if another
encryption mechanism is used to encrypt media. encryption mechanism is used to encrypt 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:
o There can only be one DTLS association [RFC6347] associated with o There can only be one DTLS association [RFC6347] associated with
the BUNDLE group; and the BUNDLE group; and
skipping to change at page 33, line 18 skipping to change at page 34, line 16
the 'use_srtp' extension [RFC5764] in the DTLS ClientHello message the 'use_srtp' extension [RFC5764] in the DTLS ClientHello message
[RFC5764]. The client MUST include the extension even if the [RFC5764]. The client MUST include the extension even if the
usage of DTLS-SRTP is not negotiated as part of the multimedia usage of DTLS-SRTP is not negotiated as part of the multimedia
session (e.g., SIP session [RFC3261]). session (e.g., 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 required
in order to include the extension, in case DTLS-SRTP encrypted media in order to include the extension, in case DTLS-SRTP encrypted media
is added to the BUNDLE group later during the multimedia session. is added to the BUNDLE group later during the multimedia session.
13. RTP Header Extensions Consideration 12. RTP Header Extensions Consideration
When [RFC8285] RTP header extensions are used in the context of this When [RFC8285] RTP header extensions are used in the context of this
specification, the identifier used for a given extension MUST specification, the identifier used for a given extension MUST
identify the same extension across all the bundled media identify the same extension across all the bundled media
descriptions. descriptions.
14. Update to RFC 3264 13. Update to RFC 3264
This section updates RFC 3264, in order to allow extensions to define This section updates RFC 3264, in order to allow extensions to define
the usage of a zero port value in offers and answers for other the usage of a zero port value in offers and answers for other
purposes than removing or disabling media streams. The following purposes than removing or disabling media streams. The following
sections of RFC 3264 are updated: sections of RFC 3264 are updated:
o Section 5.1 (Unicast Streams). o Section 5.1 (Unicast Streams).
o Section 8.4 (Putting a Unicast Media Stream on Hold). o Section 8.4 (Putting a Unicast Media Stream on Hold).
14.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 13.1. Original text of section 5.1 (2nd paragraph) of RFC 3264
For recvonly and sendrecv streams, the port number and address in the For recvonly and sendrecv streams, the port number and address in the
offer indicate where the offerer would like to receive the media offer indicate where the offerer would like to receive the media
stream. For sendonly RTP streams, the address and port number stream. For sendonly RTP streams, the address and port number
indirectly indicate where the offerer wants to receive RTCP reports. indirectly indicate where the offerer wants to receive RTCP reports.
Unless there is an explicit indication otherwise, reports are sent to Unless there is an explicit indication otherwise, reports are sent to
the port number one higher than the number indicated. The IP address the port number one higher than the number indicated. The IP address
and port present in the offer indicate nothing about the source IP and port present in the offer indicate nothing about the source IP
address and source port of RTP and RTCP packets that will be sent by address and source port of RTP and RTCP packets that will be sent by
the offerer. A port number of zero in the offer indicates that the the offerer. A port number of zero in the offer indicates that the
stream is offered but MUST NOT be used. This has no useful semantics stream is offered but MUST NOT be used. This has no useful semantics
in an initial offer, but is allowed for reasons of completeness, in an initial offer, but is allowed for reasons of completeness,
since the answer can contain a zero port indicating a rejected stream since the answer can contain a zero port indicating a rejected stream
(Section 6). Furthermore, existing streams can be terminated by (Section 6). Furthermore, existing streams can be terminated by
setting the port to zero (Section 8). In general, a port number of setting the port to zero (Section 8). In general, a port number of
zero indicates that the media stream is not wanted. zero indicates that the media stream is not wanted.
14.2. New text replacing section 5.1 (2nd paragraph) of RFC 3264 13.2. New text replacing section 5.1 (2nd paragraph) of RFC 3264
For recvonly and sendrecv streams, the port number and address in the For recvonly and sendrecv streams, the port number and address in the
offer indicate where the offerer would like to receive the media offer indicate where the offerer would like to receive the media
stream. For sendonly RTP streams, the address and port number stream. For sendonly RTP streams, the address and port number
indirectly indicate where the offerer wants to receive RTCP reports. indirectly indicate where the offerer wants to receive RTCP reports.
Unless there is an explicit indication otherwise, reports are sent to Unless there is an explicit indication otherwise, reports are sent to
the port number one higher than the number indicated. The IP address the port number one higher than the number indicated. The IP address
and port present in the offer indicate nothing about the source IP and port present in the offer indicate nothing about the source IP
address and source port of RTP and RTCP packets that will be sent by address and source port of RTP and RTCP packets that will be sent by
the offerer. A port number of zero in the offer by default indicates the offerer. A port number of zero in the offer by default indicates
that the stream is offered but MUST NOT be used, but an extension that the stream is offered but MUST NOT be used, but an extension
mechanism might specify different semantics for the usage of a zero mechanism might specify different semantics for the usage of a zero
port value. Furthermore, existing streams can be terminated by port value. Furthermore, existing streams can be terminated by
setting the port to zero (Section 8). In general, a port number of setting the port to zero (Section 8). In general, a port number of
zero by default indicates that the media stream is not wanted. zero by default indicates that the media stream is not wanted.
14.3. Original text of section 8.4 (6th paragraph) of RFC 3264 13.3. Original text of section 8.4 (6th paragraph) of RFC 3264
RFC 2543 [10] specified that placing a user on hold was accomplished RFC 2543 [10] specified that placing a user on hold was accomplished
by setting the connection address to 0.0.0.0. Its usage for putting by setting the connection address to 0.0.0.0. Its usage for putting
a call on hold is no longer recommended, since it doesn't allow for a call on hold is no longer recommended, since it doesn't allow for
RTCP to be used with held streams, doesn't work with IPv6, and breaks RTCP to be used with held streams, doesn't work with IPv6, and breaks
with connection oriented media. However, it can be useful in an with connection oriented media. However, it can be useful in an
initial offer when the offerer knows it wants to use a particular set initial offer when the offerer knows it wants to use a particular set
of media streams and formats, but doesn't know the addresses and of media streams and formats, but doesn't know the addresses and
ports at the time of the offer. Of course, when used, the port ports at the time of the offer. Of course, when used, the port
number MUST NOT be zero, which would specify that the stream has been number MUST NOT be zero, which would specify that the stream has been
disabled. An agent MUST be capable of receiving SDP with a disabled. An agent MUST be capable of receiving SDP with a
connection address of 0.0.0.0, in which case it means that neither connection address of 0.0.0.0, in which case it means that neither
RTP nor RTCP is to be sent to the peer. RTP nor RTCP is to be sent to the peer.
14.4. New text replacing section 8.4 (6th paragraph) of RFC 3264 13.4. New text replacing section 8.4 (6th paragraph) of RFC 3264
RFC 2543 [10] specified that placing a user on hold was accomplished RFC 2543 [10] specified that placing a user on hold was accomplished
by setting the connection address to 0.0.0.0. Its usage for putting by setting the connection address to 0.0.0.0. Its usage for putting
a call on hold is no longer recommended, since it doesn't allow for a call on hold is no longer recommended, since it doesn't allow for
RTCP to be used with held streams, doesn't work with IPv6, and breaks RTCP to be used with held streams, doesn't work with IPv6, and breaks
with connection oriented media. However, it can be useful in an with connection oriented media. However, it can be useful in an
initial offer when the offerer knows it wants to use a particular set initial offer when the offerer knows it wants to use a particular set
of media streams and formats, but doesn't know the addresses and of media streams and formats, but doesn't know the addresses and
ports at the time of the offer. Of course, when used, the port ports at the time of the offer. Of course, when used, the port
number MUST NOT be zero, if it would specify that the stream has been number MUST NOT be zero, if it would specify that the stream has been
disabled. However, an extension mechanism might specify different disabled. However, an extension mechanism might specify different
semantics of the zero port number usage. An agent MUST be capable of semantics of the zero port number usage. An agent MUST be capable of
receiving SDP with a connection address of 0.0.0.0, in which case it receiving SDP with a connection address of 0.0.0.0, in which case it
means that neither RTP nor RTCP is to be sent to the peer. means that neither RTP nor RTCP is to be sent to the peer.
15. RTP/RTCP extensions for identification-tag transport 14. RTP/RTCP extensions for identification-tag transport
SDP Offerers and Answerers [RFC3264] can associate identification- SDP Offerers and Answerers [RFC3264] can associate identification-
tags with "m=" sections within SDP Offers and Answers, using the tags with "m=" sections within SDP Offers and Answers, using the
procedures in [RFC5888]. Each identification-tag uniquely represents procedures in [RFC5888]. Each identification-tag uniquely represents
an "m=" section. an "m=" section.
This section defines a new RTCP SDES item [RFC3550], 'MID', which is This section defines a new RTCP SDES item [RFC3550], 'MID', which is
used to carry identification-tags within RTCP SDES packets. This used to carry identification-tags within RTCP SDES packets. This
section also defines a new RTP SDES header extension [RFC7941], which section also defines a new RTP SDES header extension [RFC7941], which
is used to carry the 'MID' RTCP SDES item in RTP packets. is used to carry the 'MID' RTCP SDES item in RTP packets.
skipping to change at page 36, line 13 skipping to change at page 37, line 10
in which this header extension is sent is intentionally not specified in which this header extension is sent is intentionally not specified
here, as it will depend on expected packet loss rate and loss here, as it will depend on expected packet loss rate and loss
patterns, the overhead the application can tolerate, and the patterns, the overhead the application can tolerate, and the
importance of immediate receipt of the identification-tag. importance of immediate receipt of the identification-tag.
For robustness, endpoints need to be prepared for situations where For robustness, endpoints need to be prepared for situations where
the reception of the identification-tag is delayed, and SHOULD NOT the reception of the identification-tag is delayed, and SHOULD NOT
terminate sessions in such cases, as the identification-tag is likely terminate sessions in such cases, as the identification-tag is likely
to arrive soon. to arrive soon.
15.1. RTCP MID SDES Item 14.1. RTCP MID SDES Item
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MID=TBD | length | identification-tag ... | MID=TBD | length | identification-tag ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The identification-tag payload is UTF-8 encoded [RFC3629], as in SDP. The identification-tag payload is UTF-8 encoded [RFC3629], as in SDP.
The identification-tag is not zero terminated. The identification-tag is not zero terminated.
[RFC EDITOR NOTE: Please replace TBD with the assigned SDES [RFC EDITOR NOTE: Please replace TBD with the assigned SDES
identifier value.] identifier value.]
15.2. RTP SDES Header Extension For MID 14.2. RTP SDES Header Extension For MID
The payload, containing the identification-tag, of the RTP SDES The payload, containing the identification-tag, of the RTP SDES
header extension element can be encoded using either the one-byte or header extension element can be encoded using either the one-byte or
two-byte header [RFC7941]. The identification-tag payload is UTF-8 two-byte header [RFC7941]. The identification-tag payload is UTF-8
encoded, as in SDP. encoded, as in SDP.
The identification-tag is not zero terminated. Note, that the set of The identification-tag is not zero terminated. Note, that the set of
header extensions included in the packet needs to be padded to the header extensions included in the packet needs to be padded to the
next 32-bit boundary using zero bytes [RFC8285]. next 32-bit boundary using zero bytes [RFC8285].
skipping to change at page 37, line 11 skipping to change at page 38, line 7
the properties of the RTP header extension mechanism, when using the the properties of the RTP header extension mechanism, when using the
one-byte header, a tag that is 1-3 bytes will result in a minimal one-byte header, a tag that is 1-3 bytes will result in a minimal
number of 32-bit words used for the RTP SDES header extension, in number of 32-bit words used for the RTP SDES header extension, in
case no other header extensions are included at the same time. Note, case no other header extensions are included at the same time. Note,
do take into account that some single characters when UTF-8 encoded do take into account that some single characters when UTF-8 encoded
will result in multiple octets. The identification-tag MUST NOT will result in multiple octets. The identification-tag MUST NOT
contain any user information, and applications SHALL avoid generating contain any user information, and applications SHALL avoid generating
the identification-tag using a pattern that enables user- or the identification-tag using a pattern that enables user- or
application identification. application identification.
16. IANA Considerations 15. IANA Considerations
16.1. New SDES item 15.1. New SDES item
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this
document.] document.]
[RFC EDITOR NOTE: Please replace TBD with the assigned SDES [RFC EDITOR NOTE: Please replace TBD with the assigned SDES
identifier value.] identifier value.]
This document adds the MID SDES item to the IANA "RTP SDES item This document adds the MID SDES item to the IANA "RTP SDES item
types" registry as follows: types" registry as follows:
Value: TBD Value: TBD
Abbrev.: MID Abbrev.: MID
Name: Media Identification Name: Media Identification
Reference: RFCXXXX Reference: RFCXXXX
16.2. New RTP SDES Header Extension URI 15.2. New RTP SDES Header Extension URI
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this
document.] document.]
This document defines a new extension URI in the RTP SDES Compact This document defines a new extension URI in the RTP SDES Compact
Header Extensions sub-registry of the RTP Compact Header Extensions Header Extensions sub-registry of the RTP Compact Header Extensions
registry sub-registry, according to the following data: registry sub-registry, according to the following data:
Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid
Description: Media identification Description: Media identification
skipping to change at page 38, line 19 skipping to change at page 39, line 5
The SDES item does not reveal privacy information about the users. The SDES item does not reveal privacy information about the users.
It is simply used to associate RTP-based media with the correct SDP It is simply used to associate RTP-based media with the correct SDP
media description ("m=" section) in the SDP used to negotiate the media description ("m=" section) in the SDP used to negotiate the
media. media.
The purpose of the extension is for the offerer to be able to The purpose of the extension is for the offerer to be able to
associate received multiplexed RTP-based media before the offerer associate received multiplexed RTP-based media before the offerer
receives the associated SDP answer. receives the associated SDP answer.
16.3. New SDP Attribute 15.3. New SDP Attribute
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this
document.] document.]
This document defines a new SDP media-level attribute, 'bundle-only', This document defines a new SDP media-level attribute, 'bundle-only',
according to the following data: according to the following data:
Attribute name: bundle-only Attribute name: bundle-only
Type of attribute: media Type of attribute: media
Subject to charset: No Subject to charset: No
Purpose: Request a media description to be accepted Purpose: Request a media description to be accepted
in the answer only if kept within a BUNDLE in the answer only if kept within a BUNDLE
group by the answerer. group by the answerer.
Appropriate values: N/A Appropriate values: N/A
Contact name: IESG Contact name: IESG
Contact e-mail: iesg@ietf.org Contact e-mail: iesg@ietf.org
Reference: RFCXXXX Reference: RFCXXXX
Mux category: NORMAL Mux category: NORMAL
16.4. New SDP Group Semantics 15.4. New SDP Group Semantics
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this
document.] document.]
This document registers the following semantics with IANA in the This document registers the following semantics with IANA in the
"Semantics for the "group" SDP Attribute" subregistry (under the "Semantics for the "group" SDP Attribute" subregistry (under the
"Session Description Protocol (SDP) Parameters" registry: "Session Description Protocol (SDP) Parameters" registry:
Semantics Token Reference Semantics Token Reference
------------------------------------- ------ --------- ------------------------------------- ------ ---------
Media bundling BUNDLE [RFCXXXX] Media bundling BUNDLE [RFCXXXX]
Mux category: NORMAL Mux category: NORMAL
17. Security Considerations 16. Security Considerations
The security considerations defined in [RFC3264] and [RFC5888] apply The security considerations defined in [RFC3264] and [RFC5888] apply
to the BUNDLE extension. Bundle does not change which information, to the BUNDLE extension. Bundle does not change which information,
e.g., RTP streams, flows over the network, with the exception of the e.g., RTP streams, flows over the network, with the exception of the
usage of the MID SDES item as discussed below. Primarily it changes usage of the MID SDES item as discussed below. Primarily it changes
which addresses and ports, and thus in which (RTP) sessions the which addresses and ports, and thus in which (RTP) sessions the
information is flowing. This affects the security contexts being information is flowing. This affects the security contexts being
used and can cause previously separated information flows to share used and can cause previously separated information flows to share
the same security context. This has very little impact on the the same security context. This has very little impact on the
performance of the security mechanism of the RTP sessions. In cases performance of the security mechanism of the RTP sessions. In cases
skipping to change at page 40, line 25 skipping to change at page 41, line 9
However, assuming the above requirements and recommendations are However, assuming the above requirements and recommendations are
followed, there are no known significant security risks with leaving followed, there are no known significant security risks with leaving
the MID RTP header extension without confidentiality protection. the MID RTP header extension without confidentiality protection.
Therefore, this specification updates RFC 7941 by adding the Therefore, this specification updates RFC 7941 by adding the
exception that this requirement MAY be ignored for the MID RTP header exception that this requirement MAY be ignored for the MID RTP header
extension. Security mechanisms for RTP/RTCP are discussed in Options extension. Security mechanisms for RTP/RTCP are discussed in Options
for Securing RTP Sessions [RFC7201], for example SRTP [RFC3711] can for Securing RTP Sessions [RFC7201], for example SRTP [RFC3711] can
provide the necessary security functions of ensuring the integrity provide the necessary security functions of ensuring the integrity
and source authenticity. and source authenticity.
18. Examples 17. Examples
18.1. Example: BUNDLE Address:Port Selection 17.1. Example: Tagged m= Section Selections
The example below shows: The example below shows:
o An offer, in which the offerer assigns a unique address:port to o An initial offer, in which the offerer wants to negotiate a BUNDLE
each bundled "m=" section within the BUNDLE group. group, and indicates the audio m= section as the suggested offerer
tagged "m=" section.
o An answer, in which the answerer selects the offerer BUNDLE o An initial answer, in which the answerer accepts the creation of
address:port, and then selects its own BUNDLE address (the the BUNDLE group, selects the audio m= section in the offer as the
answerer BUNDLE address:port) and assigns it to the bundled "m=" offerer tagged "m=" section, selects the audio "m=" section in the
section indicated by the answerer BUNDLE-tag. answer as the answerer tagged "m=" section and assigns the
answerer BUNDLE address:port to that "m=" section.
SDP Offer (1) SDP Offer (1)
v=0 v=0
o=alice 2890844526 2890844526 IN IP6 2001:db8::3 o=alice 2890844526 2890844526 IN IP6 2001:db8::3
s= s=
c=IN IP6 2001:db8::3 c=IN IP6 2001:db8::3
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
skipping to change at page 41, line 41 skipping to change at page 42, line 28
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 0 RTP/AVP 32 m=video 0 RTP/AVP 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=bundle-only a=bundle-only
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
18.2. Example: BUNDLE Extension Rejected 17.2. Example: BUNDLE Group Rejected
The example below shows: The example below shows:
o An offer, in which the offerer assigns a unique address:port to o An initial offer, in which the offerer wants to negotiate a BUNDLE
each bundled "m=" section within the BUNDLE group. group, and indicates the audio m= section as the suggested offerer
tagged "m=" section.
o An answer, in which the answerer rejects the offered BUNDLE group, o An initial answer, in which the answerer rejects the creation of
and assigns a unique address:port to each "m=" section (following the BUNDLE group, generates a normal answer and assigns a unique
normal RFC 3264 procedures). address:port to each "m=" section in the answer.
SDP Offer (1) SDP Offer (1)
v=0 v=0
o=alice 2890844526 2890844526 IN IP6 2001:db8::3 o=alice 2890844526 2890844526 IN IP6 2001:db8::3
s= s=
c=IN IP6 2001:db8::3 c=IN IP6 2001:db8::3
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
skipping to change at page 44, line 5 skipping to change at page 44, line 5
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
b=AS:200 b=AS:200
a=rtcp-mux a=rtcp-mux
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
m=video 30000 RTP/AVP 32 m=video 30000 RTP/AVP 32
b=AS:1000 b=AS:1000
a=rtcp-mux a=rtcp-mux
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
18.3. Example: Offerer Adds a Media Description to a BUNDLE Group 17.3. Example: Offerer Adds a Media Description to a BUNDLE Group
The example below shows: The example below shows:
o A subsequent offer (the BUNDLE group has been created as part of a o A subsequent offer, in which the offerer adds a new bundled "m="
previous offer/answer exchange), in which the offerer adds a new section (video), indicated by the "zen" identification-tag, to a
"m=" section, indicated by the "zen" identification-tag, to a previously negotiated BUNDLE group, indicates the new "m=" section
previously negotiated BUNDLE group, assigns the previously as the offerer tagged "m=" section and assigns the offerer BUNDLE
selected offerer BUNDLE address:port to the added "m=" section, address:port to that "m=" section.
indicated by the offerer BUNDLE-tag. To every other bundled "m="
section the offerer assigns a zero port value and includes an SDP
'bundle-only' attribute.
o An answer, in which the answerer assigns the answerer BUNDLE o A subsequent answer, in which the answerer indicates the new video
address:port to the bundled "m=" section indicated by the answerer "m=" section in the answer as the answerer tagged "m=" section and
BUNDLE-tag. To every other bundled "m=" section the answerer assigns the answerer BUNDLE address:port to that "m=" section.
assigns a zero port value and includes an SDP 'bundle-only'
attribute.
SDP Offer (1) SDP Offer (1)
v=0 v=0
o=alice 2890844526 2890844526 IN IP6 2001:db8::3 o=alice 2890844526 2890844526 IN IP6 2001:db8::3
s= s=
c=IN IP6 2001:db8::3 c=IN IP6 2001:db8::3
t=0 0 t=0 0
a=group:BUNDLE zen foo bar a=group:BUNDLE zen foo bar
skipping to change at page 45, line 39 skipping to change at page 45, line 35
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 20000 RTP/AVP 66 m=video 20000 RTP/AVP 66
b=AS:1000 b=AS:1000
a=mid:zen a=mid:zen
a=rtcp-mux a=rtcp-mux
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
18.4. Example: Offerer Moves a Media Description Out of a BUNDLE Group 17.4. Example: Offerer Moves a Media Description Out of a BUNDLE Group
The example below shows: The example below shows:
o A subsequent offer (the BUNDLE group has been created as part of a o A subsequent offer, in which the offerer removes a "m=" section
previous offer/answer transaction), in which the offerer moves a (video), indicated by the "zen" identification-tag, from a
bundled "m=" section, indicated by the "zen" identification-tag, previously negotiated BUNDLE group, indicates one of the bundled
out of a BUNDLE group, assigns a unique address:port to the moved "m=" sections (audio) remaining in the BUNDLE group as the offerer
"m=" section, and assigns the previously selected offerer BUNDLE tagged "m=" section and assigns the offerer BUNDLE address:port to
address:port to another bundled "m=" section, indicated by the that "m=" section.
offerer BUNDLE-tag. To every other bundled "m=" section the
offerer assigns a zero port value and includes an SDP 'bundle-
only' attribute.
o An answer, in which the answerer moves the "m=" section out of the o A subsequent answer, in which the answerer removes the "m="
BUNDLE group, assigns a unique address:port to the moved "m=" section from the BUNDLE group, indicates the audio "m=" section in
section, and assigns the answerer BUNDLE address:port to the the answer as the answerer tagged "m=" section and assigns the
bundled "m=" section indicated by the answerer BUNDLE-tag. To answerer BUNDLE address:port to that "m=" section.
every other bundled "m=" section the answerer assigns a zero port
value and includes an SDP 'bundle-only' attribute.
SDP Offer (1) SDP Offer (1)
v=0 v=0
o=alice 2890844526 2890844526 IN IP6 2001:db8::3 o=alice 2890844526 2890844526 IN IP6 2001:db8::3
s= s=
c=IN IP6 2001:db8::3 c=IN IP6 2001:db8::3
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
skipping to change at page 47, line 30 skipping to change at page 47, line 17
a=bundle-only a=bundle-only
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 60000 RTP/AVP 66 m=video 60000 RTP/AVP 66
b=AS:1000 b=AS:1000
a=mid:zen a=mid:zen
a=rtcp-mux a=rtcp-mux
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
18.5. Example: Offerer Disables a Media Description Within a BUNDLE 17.5. Example: Offerer Disables a Media Description Within a BUNDLE
Group Group
The example below shows: The example below shows:
o A subsequent offer (the BUNDLE group has been created as part of a o A subsequent offer, in which the offerer disables (by assigning a
previous offer/answer transaction), in which the offerer disables zero port value) a "m=" section (video), indicated by the "zen"
a bundled "m=" section indicated by the "zen" identification-tag, identification-tag, from a previously negotiated BUNDLE group,
within a BUNDLE group, assigns a zero port number to the disabled indicates one of the bundled "m=" sections (audio) remaining
"m=" section, and assigns the offerer BUNDLE address:port to active in the BUNDLE group as the offerer tagged "m=" section and
another bundled "m=" section, indicated by the offerer BUNDLE-tag. assigns the offerer BUNDLE address:port to that "m=" section.
To every other bundled "m=" section the offerer assigns a zero
port value and includes an SDP 'bundle-only' attribute.
o An answer, in which the answerer moves the disabled "m=" sections o A subsequent answer, in which the answerer disables the "m="
out of the BUNDLE group, assigns a zero port value to the disabled section, indicates the audio "m=" section in the answer as the
"m=" section, and assigns the answerer BUNDLE address:port to the answerer tagged "m=" section and assigns the answerer BUNDLE
bundled "m=" section indicated by the answerer BUNDLE-tag. To address:port to that "m=" section.
every other bundled "m=" section the answerer assigns a zero port
value and includes an SDP 'bundle-only' attribute.
SDP Offer (1) SDP Offer (1)
v=0 v=0
o=alice 2890844526 2890844526 IN IP6 2001:db8::3 o=alice 2890844526 2890844526 IN IP6 2001:db8::3
s= s=
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97 m=audio 10000 RTP/AVP 0 8 97
skipping to change at page 49, line 16 skipping to change at page 49, line 5
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=bundle-only a=bundle-only
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 0 RTP/AVP 66 m=video 0 RTP/AVP 66
a=mid:zen a=mid:zen
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
19. Acknowledgements 18. Acknowledgements
The usage of the SDP grouping extension for negotiating bundled media The usage of the SDP grouping extension for negotiating bundled media
is based on similar alternatives proposed by Harald Alvestrand and is based on similar alternatives proposed by Harald Alvestrand and
Cullen Jennings. The BUNDLE extension described in this document is Cullen Jennings. The BUNDLE extension described in this document is
based on the different alternative proposals, and text (e.g., SDP based on the different alternative proposals, and text (e.g., SDP
examples) have been borrowed (and, in some cases, modified) from examples) have been borrowed (and, in some cases, modified) from
those alternative proposals. those alternative proposals.
The SDP examples are also modified versions from the ones in the The SDP examples are also modified versions from the ones in the
Alvestrand proposal. Alvestrand proposal.
skipping to change at page 50, line 5 skipping to change at page 49, line 37
Thanks to Magnus Westerlund, Colin Perkins and Jonathan Lennox for Thanks to Magnus Westerlund, Colin Perkins and Jonathan Lennox for
providing help and text on the RTP/RTCP procedures. providing help and text on the RTP/RTCP procedures.
Thanks to Charlie Kaufman for performing the Sec-Dir review. Thanks to Charlie Kaufman for performing the Sec-Dir review.
Thanks to Linda Dunbar for performing the Gen-ART review. Thanks to Linda Dunbar for performing the Gen-ART review.
Thanks to Spotify for providing music for the countless hours of Thanks to Spotify for providing music for the countless hours of
document editing. document editing.
20. Change Log 19. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing] [RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-50
o Changes based on IESG reviews.
o - Adding of tagged m- section concept.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-49 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-49
o Changes based on IESG reviews. o Changes based on IESG reviews.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-48 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-48
o Changes based on Sec-Dir review by Charlie Kaufman. o Changes based on Sec-Dir review by Charlie Kaufman.
o - s/unique address/unique address:port o - s/unique address/unique address:port
o Changes based on Gen-ART review by Linda Dunbar. o Changes based on Gen-ART review by Linda Dunbar.
o Mux category for group:BUNDLE attribute added. o Mux category for group:BUNDLE attribute added.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-47 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-47
skipping to change at page 60, line 45 skipping to change at page 60, line 40
o Draft name changed. o Draft name changed.
o Harald Alvestrand added as co-author. o Harald Alvestrand added as co-author.
o "Multiplex" terminology changed to "bundle". o "Multiplex" terminology changed to "bundle".
o Added text about single versus multiple RTP Sessions. o Added text about single versus multiple RTP Sessions.
o Added reference to RFC 3550. o Added reference to RFC 3550.
21. References 20. References
21.1. Normative References 20.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002, <https://www.rfc- DOI 10.17487/RFC3264, June 2002,
editor.org/info/rfc3264>. <https://www.rfc-editor.org/info/rfc3264>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/info/rfc3550>. July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
in Session Description Protocol (SDP)", RFC 3605, in Session Description Protocol (SDP)", RFC 3605,
DOI 10.17487/RFC3605, October 2003, <https://www.rfc- DOI 10.17487/RFC3605, October 2003,
editor.org/info/rfc3605>. <https://www.rfc-editor.org/info/rfc3605>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>. 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004, RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/info/rfc3711>. <https://www.rfc-editor.org/info/rfc3711>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566, Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <https://www.rfc-editor.org/info/rfc4566>. July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",
BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007,
<https://www.rfc-editor.org/info/rfc4961>. <https://www.rfc-editor.org/info/rfc4961>.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, Control Packets on a Single Port", RFC 5761,
DOI 10.17487/RFC5761, April 2010, <https://www.rfc- DOI 10.17487/RFC5761, April 2010,
editor.org/info/rfc5761>. <https://www.rfc-editor.org/info/rfc5761>.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, Real-time Transport Protocol (SRTP)", RFC 5764,
DOI 10.17487/RFC5764, May 2010, <https://www.rfc- DOI 10.17487/RFC5764, May 2010,
editor.org/info/rfc5764>. <https://www.rfc-editor.org/info/rfc5764>.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, Protocol (SDP) Grouping Framework", RFC 5888,
DOI 10.17487/RFC5888, June 2010, <https://www.rfc- DOI 10.17487/RFC5888, June 2010,
editor.org/info/rfc5888>. <https://www.rfc-editor.org/info/rfc5888>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP [RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP
Header Extension for the RTP Control Protocol (RTCP) Header Extension for the RTP Control Protocol (RTCP)
Source Description Items", RFC 7941, DOI 10.17487/RFC7941, Source Description Items", RFC 7941, DOI 10.17487/RFC7941,
August 2016, <https://www.rfc-editor.org/info/rfc7941>. August 2016, <https://www.rfc-editor.org/info/rfc7941>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General
Mechanism for RTP Header Extensions", RFC 8285, Mechanism for RTP Header Extensions", RFC 8285,
DOI 10.17487/RFC8285, October 2017, <https://www.rfc- DOI 10.17487/RFC8285, October 2017,
editor.org/info/rfc8285>. <https://www.rfc-editor.org/info/rfc8285>.
[I-D.ietf-ice-rfc5245bis] [I-D.ietf-ice-rfc5245bis]
Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", draft-ietf-ice- Address Translator (NAT) Traversal", draft-ietf-ice-
rfc5245bis-20 (work in progress), March 2018. rfc5245bis-20 (work in progress), March 2018.
[I-D.ietf-mmusic-sdp-mux-attributes] [I-D.ietf-mmusic-sdp-mux-attributes]
Nandakumar, S., "A Framework for SDP Attributes when Nandakumar, S., "A Framework for SDP Attributes when
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16
skipping to change at page 63, line 5 skipping to change at page 62, line 48
procedures for Interactive Connectivity Establishment procedures for Interactive Connectivity Establishment
(ICE)", draft-ietf-mmusic-ice-sip-sdp-20 (work in (ICE)", draft-ietf-mmusic-ice-sip-sdp-20 (work in
progress), April 2018. progress), April 2018.
[I-D.ietf-mmusic-trickle-ice-sip] [I-D.ietf-mmusic-trickle-ice-sip]
Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A
Session Initiation Protocol (SIP) Usage for Trickle ICE", Session Initiation Protocol (SIP) Usage for Trickle ICE",
draft-ietf-mmusic-trickle-ice-sip-14 (work in progress), draft-ietf-mmusic-trickle-ice-sip-14 (work in progress),
February 2018. February 2018.
21.2. Informative References 20.2. Informative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, <https://www.rfc- DOI 10.17487/RFC3261, June 2002,
editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
"RTP Control Protocol Extended Reports (RTCP XR)", "RTP Control Protocol Extended Reports (RTCP XR)",
RFC 3611, DOI 10.17487/RFC3611, November 2003, RFC 3611, DOI 10.17487/RFC3611, November 2003,
<https://www.rfc-editor.org/info/rfc3611>. <https://www.rfc-editor.org/info/rfc3611>.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile "Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104,
February 2008, <https://www.rfc-editor.org/info/rfc5104>. February 2008, <https://www.rfc-editor.org/info/rfc5104>.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
DOI 10.17487/RFC4585, July 2006, <https://www.rfc- DOI 10.17487/RFC4585, July 2006,
editor.org/info/rfc4585>. <https://www.rfc-editor.org/info/rfc4585>.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009,
<https://www.rfc-editor.org/info/rfc5576>. <https://www.rfc-editor.org/info/rfc5576>.
[RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple
Clock Rates in an RTP Session", RFC 7160, Clock Rates in an RTP Session", RFC 7160,
DOI 10.17487/RFC7160, April 2014, <https://www.rfc- DOI 10.17487/RFC7160, April 2014,
editor.org/info/rfc7160>. <https://www.rfc-editor.org/info/rfc7160>.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
<https://www.rfc-editor.org/info/rfc7201>. <https://www.rfc-editor.org/info/rfc7201>.
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms
for Real-Time Transport Protocol (RTP) Sources", RFC 7656, for Real-Time Transport Protocol (RTP) Sources", RFC 7656,
DOI 10.17487/RFC7656, November 2015, <https://www.rfc- DOI 10.17487/RFC7656, November 2015,
editor.org/info/rfc7656>. <https://www.rfc-editor.org/info/rfc7656>.
[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services
(Diffserv) and Real-Time Communication", RFC 7657, (Diffserv) and Real-Time Communication", RFC 7657,
DOI 10.17487/RFC7657, November 2015, <https://www.rfc- DOI 10.17487/RFC7657, November 2015,
editor.org/info/rfc7657>. <https://www.rfc-editor.org/info/rfc7657>.
[I-D.ietf-ice-trickle] [I-D.ietf-ice-trickle]
Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre,
"Trickle ICE: Incremental Provisioning of Candidates for "Trickle ICE: Incremental Provisioning of Candidates for
the Interactive Connectivity Establishment (ICE) the Interactive Connectivity Establishment (ICE)
Protocol", draft-ietf-ice-trickle-21 (work in progress), Protocol", draft-ietf-ice-trickle-21 (work in progress),
April 2018. April 2018.
[I-D.ietf-avtext-lrr] [I-D.ietf-avtext-lrr]
Lennox, J., Hong, D., Uberti, J., Holmer, S., and M. Lennox, J., Hong, D., Uberti, J., Holmer, S., and M.
 End of changes. 208 change blocks. 
655 lines changed or deleted 679 lines changed or added

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