draft-ietf-mmusic-sdp-bundle-negotiation-49.txt   draft-ietf-mmusic-sdp-bundle-negotiation-50.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: September 4, 2018 C. Jennings Expires: October 26, 2018 C. Jennings
Cisco Cisco
March 3, 2018 April 24, 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-49.txt draft-ietf-mmusic-sdp-bundle-negotiation-50.txt
Abstract Abstract
This specification defines a new Session Description Protocol (SDP) This specification defines a new Session Description Protocol (SDP)
Grouping Framework extension, 'BUNDLE'. The extension can be used Grouping Framework extension, 'BUNDLE'. The extension can be used
with the SDP Offer/Answer mechanism to negotiate the usage of a with the SDP Offer/Answer mechanism to negotiate the usage of a
single transport (5-tuple) for sending and receiving media described single transport (5-tuple) for sending and receiving media described
by multiple SDP media descriptions ("m=" sections). Such transport by multiple SDP media descriptions ("m=" sections). Such transport
is referred to as a BUNDLE transport, and the media is referred to as is referred to as a BUNDLE transport, and the media is referred to as
bundled media. The "m=" sections that use the BUNDLE transport form bundled media. The "m=" sections that use the BUNDLE transport form
a BUNDLE group. a BUNDLE group.
This specification updates RFC 3264, to allow assigning a zero port This specification updates RFC 3264, to allow assigning a zero port
value to a "m=" section without meaning that the media described by value to a "m=" section also in cases where the media described by
the "m=" section is 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
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.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 4, 2018.
This Internet-Draft will expire on October 26, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
skipping to change at page 2, line 45 skipping to change at page 2, line 51
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Applicability Statement . . . . . . . . . . . . . . . . . . . 7 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 7
5. SDP Grouping Framework BUNDLE Extension . . . . . . . . . . . 7 5. SDP Grouping Framework BUNDLE Extension . . . . . . . . . . . 7
6. SDP 'bundle-only' Attribute . . . . . . . . . . . . . . . . . 8 6. SDP 'bundle-only' Attribute . . . . . . . . . . . . . . . . . 8
7. SDP Information Considerations . . . . . . . . . . . . . . . 9 7. SDP Information Considerations . . . . . . . . . . . . . . . 9
7.1. Connection Data (c=) . . . . . . . . . . . . . . . . . . 9 7.1. Connection Data (c=) . . . . . . . . . . . . . . . . . . 9
7.2. Bandwidth (b=) . . . . . . . . . . . . . . . . . . . . . 9 7.2. Bandwidth (b=) . . . . . . . . . . . . . . . . . . . . . 9
8. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 9 8. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 9
8.1. Multiplex Category Considerations . . . . . . . . . . . . 10 8.1. Multiplexing Category Considerations . . . . . . . . . . 10
8.2. Generating the Initial SDP Offer . . . . . . . . . . . . 11 8.2. Generating the Initial SDP Offer . . . . . . . . . . . . 11
8.2.1. Suggesting the Offerer BUNDLE Address:Port . . . . . 11 8.2.1. Suggesting the Offerer BUNDLE Address:Port . . . . . 11
8.2.2. Example: Initial SDP Offer . . . . . . . . . . . . . 12 8.2.2. Example: Initial SDP Offer . . . . . . . . . . . . . 12
8.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 13 8.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 13
8.3.1. Answerer Selection of Offerer BUNDLE Address:Port . . 14 8.3.1. Answerer Selection of Offerer BUNDLE Address:Port . . 14
8.3.2. Answerer Selection of Answerer BUNDLE Address:Port . 14 8.3.2. Answerer Selection of Answerer BUNDLE Address:Port . 14
8.3.3. Moving A Media Description Out Of A BUNDLE Group . . 15 8.3.3. Moving A Media Description Out Of A BUNDLE Group . . 15
8.3.4. Rejecting a Media Description in a BUNDLE Group . . . 15 8.3.4. Rejecting a Media Description in a BUNDLE Group . . . 15
8.3.5. Example: SDP Answer . . . . . . . . . . . . . . . . . 16 8.3.5. Example: SDP Answer . . . . . . . . . . . . . . . . . 16
8.4. Offerer Processing of the SDP Answer . . . . . . . . . . 17 8.4. Offerer Processing of the SDP Answer . . . . . . . . . . 17
8.5. Modifying the Session . . . . . . . . . . . . . . . . . . 17 8.5. Modifying the Session . . . . . . . . . . . . . . . . . . 17
8.5.1. Suggesting a New Offerer BUNDLE Address:Port . . . . 18 8.5.1. Suggesting a New Offerer BUNDLE Address:Port . . . . 18
8.5.2. Adding a Media Description to a BUNDLE group . . . . 18 8.5.2. Adding a Media Description to a BUNDLE group . . . . 18
8.5.3. Moving a Media Description Out of a BUNDLE Group . . 19 8.5.3. Moving a Media Description Out of a BUNDLE Group . . 19
8.5.4. Disabling a Media Description in a BUNDLE Group . . . 19 8.5.4. Disabling a Media Description in a BUNDLE Group . . . 19
9. Protocol Identification . . . . . . . . . . . . . . . . . . . 20 9. Protocol Identification . . . . . . . . . . . . . . . . . . . 20
9.1. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 20 9.1. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 20
10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 21 10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 21
10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 21 10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 21
10.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . 21 10.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . 22
10.2. Associating RTP/RTCP Streams with Correct SDP Media 10.2. Associating RTP/RTCP Streams with the Correct SDP Media
Description . . . . . . . . . . . . . . . . . . . . . . 22 Description . . . . . . . . . . . . . . . . . . . . . . 22
10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 27 10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 28
10.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . 28 10.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . 28
11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 30 11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 30
11.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 31 11.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 31
12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 32 12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 32
13. RTP Header Extensions Consideration . . . . . . . . . . . . . 32 13. RTP Header Extensions Consideration . . . . . . . . . . . . . 33
14. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 33 14. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 33
14.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 33 14.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 33
14.2. New text replacing section 5.1 (2nd paragraph) of RFC 14.2. New text replacing section 5.1 (2nd paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 34
14.3. Original text of section 6 (4th paragraph) of RFC 3264 . 34 14.3. Original text of section 8.4 (6th paragraph) of RFC 3264 34
14.4. New text replacing section 6 (4th paragraph) of RFC 3264 34 14.4. New text replacing section 8.4 (6th paragraph) of RFC
14.5. Original text of section 8.4 (6th paragraph) of RFC 3264 34
14.6. New text replacing section 8.4 (6th paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 34
15. RTP/RTCP extensions for identification-tag transport . . . . 35 15. RTP/RTCP extensions for identification-tag transport . . . . 35
15.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 36 15.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 36
15.2. RTP SDES Header Extension For MID . . . . . . . . . . . 36 15.2. RTP SDES Header Extension For MID . . . . . . . . . . . 36
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
16.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 37 16.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 37
16.2. New RTP SDES Header Extension URI . . . . . . . . . . . 37 16.2. New RTP SDES Header Extension URI . . . . . . . . . . . 37
16.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 38 16.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 38
16.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 38 16.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 38
17. Security Considerations . . . . . . . . . . . . . . . . . . . 39 17. Security Considerations . . . . . . . . . . . . . . . . . . . 39
18. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 40 18. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 40
18.1. Example: BUNDLE Address:Port Selection . . . . . . . . . 40 18.1. Example: BUNDLE Address:Port Selection . . . . . . . . . 40
18.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 42 18.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 41
18.3. Example: Offerer Adds a Media Description to a BUNDLE 18.3. Example: Offerer Adds a Media Description to a BUNDLE
Group . . . . . . . . . . . . . . . . . . . . . . . . . 43 Group . . . . . . . . . . . . . . . . . . . . . . . . . 44
18.4. Example: Offerer Moves a Media Description Out of a 18.4. Example: Offerer Moves a Media Description Out of a
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 45 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 45
18.5. Example: Offerer Disables a Media Description Within a 18.5. Example: Offerer Disables a Media Description Within a
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 47 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 47
19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 48 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49
20. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 49 20. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 50
21. References . . . . . . . . . . . . . . . . . . . . . . . . . 60 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 60
21.1. Normative References . . . . . . . . . . . . . . . . . . 60 21.1. Normative References . . . . . . . . . . . . . . . . . . 60
21.2. Informative References . . . . . . . . . . . . . . . . . 62 21.2. Informative References . . . . . . . . . . . . . . . . . 63
Appendix A. Design Considerations . . . . . . . . . . . . . . . 63 Appendix A. Design Considerations . . . . . . . . . . . . . . . 64
A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 64 A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 64
A.2. Usage of Port Number Value Zero . . . . . . . . . . . . . 65 A.2. Usage of Port Number Value Zero . . . . . . . . . . . . . 66
A.3. B2BUA And Proxy Interoperability . . . . . . . . . . . . 65 A.3. B2BUA And Proxy Interoperability . . . . . . . . . . . . 66
A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 66 A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 67
A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 66 A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 67
A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 66 A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 67
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68
1. Introduction 1. Introduction
When the SDP offer/answer mechanism [RFC3264] is used to negotiate When the SDP offer/answer mechanism [RFC3264] is used to negotiate
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.
skipping to change at page 4, line 48 skipping to change at page 4, line 52
Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264] Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264]
to negotiate which "m=" sections will become part of a BUNDLE group. to negotiate which "m=" sections will become part of a BUNDLE group.
Within a BUNDLE group, each "m=" section will use a BUNDLE transport Within a BUNDLE group, each "m=" section will use a BUNDLE transport
for sending and receiving bundled media. for sending and receiving bundled media.
Within a BUNDLE group, each endpoint uses a single address:port Within a BUNDLE group, each endpoint uses a single address:port
combination for sending and receiving bundled media. The combination for sending and receiving bundled media. The
address:port combination is referred to as the BUNDLE address:port. address:port combination is referred to as the BUNDLE address:port.
In addition to negotiating the BUNDLE group, the offerer and answerer In addition to negotiating the BUNDLE group, the offerer and answerer
[RFC3264] use the BUNDLE extension to negotiate the BUNDLE [RFC3264] use the BUNDLE extension to negotiate the BUNDLE
addresses:ports, one for the offerer (offerer BUNDLE address) and one addresses:ports, one for the offerer (offerer BUNDLE address:port)
for the answerer (answerer BUNDLE address:port). Once the offerer and one for the answerer (answerer BUNDLE address:port). Once the
and the answerer have negotiated the BUNDLE addresses:ports, and a offerer and the answerer have negotiated the BUNDLE addresses:ports,
BUNDLE group has been formed, they assign their respective BUNDLE and a BUNDLE group has been formed, they assign their respective
address:port to each "m=" section within the BUNDLE group. The BUNDLE address:port to each "m=" section within the BUNDLE group.
endpoints then use the BUNDLE addresses:ports for sending and The endpoints then use the BUNDLE addresses:ports for sending and
receiving the bundled media associated with the BUNDLE group. 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 This specification defines a new SDP attribute, 'bundle-only', which
can be used to request that specific media is only used if the "m=" can be used to request that specific media is only used if the "m="
section describing the media is kept within a BUNDLE group. section describing the media is kept within a BUNDLE group.
This specification updates RFC 3264 [RFC3264], to allow assigning a This specification updates RFC 3264 [RFC3264], to allow assigning a
zero port value to a "m=" section without meaning that the media zero port value to a "m=" section also in cases where the media
described by the "m=" section is disabled or rejected. described by the "m=" section is not disabled or rejected.
As defined in RFC 4566 [RFC4566], the semantics of assigning the same
transport address (IP address and port) to multiple "m=" sections are
undefined, and there is no grouping defined by such means. Instead,
an explicit grouping mechanism needs to be used to express the
intended semantics. This specification provides such an extension.
This specification defines a new RTP Control Protocol (RTCP) This specification defines a new RTP Control Protocol (RTCP)
[RFC3550] source description (SDES) item, 'MID', and a new RTP SDES [RFC3550] source description (SDES) item, 'MID', and a new RTP SDES
header extension that can be used to associate RTP streams with "m=" header extension that can be used to associate RTP streams with "m="
sections. sections.
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 media flows described by a single
BUNDLE group belong to a single RTP session [RFC3550]. BUNDLE group belong to a single RTP session [RFC3550].
The BUNDLE extension is backward compatible. Endpoints that do not The BUNDLE extension is backward compatible. Endpoints that do not
support the extension are expected to generate offers and answers support the extension are expected to generate offers and answers
without an SDP 'group:BUNDLE' attribute, and are expected to assign a without an SDP 'group:BUNDLE' attribute, and are expected to assign a
unique address: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].
2. Terminology 2. Terminology
"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 an referred to as "m=" sections. Each "m=" section is represented by
SDP "m=" line, and zero or more SDP attributes associated with the an SDP "m=" line, and zero or more SDP attributes associated with
"m=" line. A local address:port combination is assigned to each "m=" the "m=" line. A local address:port combination is assigned to
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-
layer protocol. layer protocol.
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.
skipping to change at page 7, line 23 skipping to change at page 7, line 23
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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in BCP 14, RFC 2119 "OPTIONAL" in this document are to be interpreted as described in BCP
[RFC2119]. 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
4. Applicability Statement 4. Applicability Statement
The mechanism in this specification only applies to the Session The mechanism in this specification only applies to the Session
Description Protocol (SDP) [RFC4566], when used together with the SDP Description Protocol (SDP) [RFC4566], when used together with the SDP
offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of
scope of this document, and is thus undefined. scope of this document, and is thus undefined.
5. SDP Grouping Framework BUNDLE Extension 5. SDP Grouping Framework BUNDLE Extension
skipping to change at page 8, line 25 skipping to change at page 8, line 25
Section 8 defines the detailed SDP Offer/Answer procedures for the Section 8 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
extension always rejects a bundled "m=" section, the offerer can
assign a zero port value to the "m=" section. According to [RFC3264]
an answerer will reject such an "m=" section. By including an SDP
'bundle-only' attribute in such an "m=" section, the offerer can
request that the answerer accepts the "m=" section if the answerer
supports the BUNDLE extension, and if the 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
In order to ensure that an answerer that does not support the BUNDLE
extension always rejects a bundled "m=" section, the offerer can
assign a zero port value to the "m=" section. According to [RFC3264]
an answerer will reject such an "m=" section. By including an SDP
'bundle-only' attribute in such an "m=" section, the offerer can
request that the answerer accepts the "m=" section if the answerer
supports the BUNDLE extension, and if the answerer keeps the "m="
section within the associated BUNDLE group.
Once the offerer and answerer BUNDLE addresses:ports have been Once the offerer and answerer BUNDLE addresses:ports have been
selected, an offerer and answerer only assign the BUNDLE address:port selected, an offerer and answerer only assign the BUNDLE address:port
to one bundled "m=" section. The offerer and answerer assign a zero to one bundled "m=" section. The offerer and answerer assign a zero
port value and includes an SDP 'bundle-only' attribute to every other port value and include an SDP 'bundle-only' attribute to 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 8 defines the detailed SDP Offer/Answer procedures for the
'bundle-only' attribute. 'bundle-only' attribute.
7. SDP Information Considerations 7. SDP Information Considerations
skipping to change at page 10, line 25 skipping to change at page 10, line 25
defines additional considerations for RTP based media. Section 6 defines additional considerations for RTP based media. Section 6
defines additional considerations for the usage of the SDP 'bundle- defines additional considerations for the usage of the SDP 'bundle-
only' attribute. Section 11 defines additional considerations for only' attribute. Section 11 defines additional considerations for
the usage of Interactive Connectivity Establishment (ICE) the usage of Interactive Connectivity Establishment (ICE)
[I-D.ietf-ice-rfc5245bis] mechanism. [I-D.ietf-ice-rfc5245bis] mechanism.
SDP offers and answers can contain multiple BUNDLE groups. The SDP offers and answers can contain multiple BUNDLE groups. The
procedures in this section apply independently to a given BUNDLE procedures in this section apply independently to a given BUNDLE
group. group.
8.1. Multiplex Category Considerations 8.1. Multiplexing Category Considerations
When a BUNDLE group is initially negotiated, and a unique When a BUNDLE group is initially negotiated, and a unique
address:port is assigned to each bundled "m=" section (excluding any address:port is assigned to each bundled "m=" section (excluding any
bundle-only "m=" section) in the initial offer [Section 8.2], any bundle-only "m=" section) in the initial offer [Section 8.2], any
IDENTICAL and TRANSPORT mux category SDP attributes included in the IDENTICAL and TRANSPORT multiplexing category SDP attributes included
BUNDLE group MUST explicitly be included in each bundled in the BUNDLE group MUST explicitly be included in each bundled "m="
"m=a€œ section (excluding any bundle-only "m=" sections). section (excluding any bundle-only "m=" sections).
When an offerer or answerer includes SDP attributes in bundled "m=" When an offerer or answerer includes SDP attributes in bundled "m="
sections within a BUNDLE group for which the offerer and answerer sections within a BUNDLE group, IDENTICAL and TRANSPORT multiplexing
BUNDLE addresses:ports have been selected, IDENTICAL and TRANSPORT category SDP attributes [I-D.ietf-mmusic-sdp-mux-attributes] are only
mux category SDP attributes [I-D.ietf-mmusic-sdp-mux-attributes] are included in the "m=" section indicated by the BUNDLE-tag in the offer
only included in the "m=" section indicated by the BUNDLE-tag in the or answer. The SDP attribute values are implicitly applied to each
offer or answer. The SDP attribute values are implicitly applied to bundled "m=" section (including any bundle-only "m=" section). The
each bundled "m=" section (including any bundle-only "m=" section). offerer and answerer MUST NOT include such SDP attributes in any
The offerer and answerer MUST NOT include such SDP attributes in any
other bundled "m=" section. other bundled "m=" section.
The semantics of some SDP attributes only apply to specific types of One consequence of these rules is that media-specific IDENTICAL and
media. For example, the semantics of the SDP 'rtcp-mux' and SDP TRANSPORT multiplexing category SDP attributes which are appropriate
'rtcp-mux-only' attributes only apply to "m=" sections describing only to some other bundled "m=" sections within the BUNDLE group
RTP-based media. However, as described in Section 8.1, there are might appear in the "m=" section indicated by the BUNDLE-tag. For
cases where IDENTICAL and TRANSPORT mux category SDP attributes are instance, the "m=" section indicated by the BUNDLE-tag might contain
only included in the "m=" sections indicated by the BUNDLE-tag. That an SDP 'rtcp-mux' attribute even if the "m=" section does not
means that media-specific IDENTICAL and TRANSPORT mux category describe RTP-based media, but another "m=" section within the BUNDLE
attributes can be included in an "m=" section associated with another group does describe RTP-based media.
type of media.
8.2. Generating the Initial SDP Offer 8.2. Generating the Initial SDP Offer
When an offerer generates an initial offer, to negotiate a BUNDLE When an offerer generates an initial offer, in order to negotiate a
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 "m=" section within the
offer, following the procedures in [RFC3264], excluding any offer, following the procedures in [RFC3264], excluding any
bundle-only "m=" sections (see below); and bundle-only "m=" sections (see below); and
o Include an SDP 'group:BUNDLE' attribute in the offer; and o Include an SDP 'group:BUNDLE' attribute in the offer; and
o Place the identification-tag of each bundled "m=" section in the o Place the identification-tag of each bundled "m=" section in the
SDP 'group:BUNDLE' attribute identification-tag list; and SDP 'group:BUNDLE' attribute identification-tag list; and
o Indicate which unique address:port the offerer suggests as the o Indicate which unique address:port the offerer suggests as the
offerer BUNDLE address:port [Section 8.2.1]. offerer BUNDLE address:port [Section 8.2.1].
NOTE: When the offerer assigns unique addresses:ports to multiple
bundled "m=" sections, the offerer needs to be prepared to receive
bundled media on each unique address:port, until it receives the
associated answer and finds out which address:port combination has
been selected as the offerer BUNDLE-address.
If the offerer wants to request that the answerer accepts a given If the offerer wants to request that the answerer accepts a given
bundled "m=" section only if the answerer keeps the "m=" section bundled "m=" section only if the answerer keeps the "m=" section
within the BUNDLE group, the offerer MUST: within the BUNDLE group, the offerer MUST:
o Include an SDP 'bundle-only' attribute [Section 8.2.1] in the "m=" o Assign a zero port value to the "m=" section; and
section; and
o Assign a zero port value to the "m=" section. o Include an SDP 'bundle-only' attribute [Section 8.2.1] in the "m="
section.
NOTE: If the offerer assigns a zero port value to an "m=" section, NOTE: If the offerer assigns a zero port value to an "m=" section,
but does not include an SDP 'bundle-only' attribute in the "m=" but does not include an SDP 'bundle-only' attribute in the "m="
section, it is an indication that the offerer wants to disable the section, it is an indication that the offerer wants to disable the
"m=" section [Section 8.5.4]. "m=" section [Section 8.5.4].
NOTE: If the offerer assigns unique addresses:ports to multiple
bundled "m=" sections, the offerer needs to be prepared to receive
bundled media on each unique address:port, until it receives the
associated answer and finds out which address:port combination has
been selected as the offerer BUNDLE-address.
[Section 8.2.2] and [Section 18.1] show an example of an initial [Section 8.2.2] and [Section 18.1] show an example of an initial
offer. offer.
8.2.1. Suggesting the Offerer BUNDLE Address:Port 8.2.1. Suggesting the Offerer BUNDLE Address:Port
In the offer, the address:port combination assigned to the "m=" In the offer, the address:port combination assigned to the "m="
section indicated by the offerer BUNDLE-tag indicates the offerer section indicated by the offerer BUNDLE-tag indicates the offerer
BUNDLE address:port, i.e., the address:port combination that the BUNDLE address:port, i.e., the address:port combination that the
offerer suggests for sending and receiving bundled media. offerer suggests for sending and receiving bundled media.
The offerer BUNDLE-tag MUST NOT represent a bundle-only "m=" section. The offerer BUNDLE-tag MUST NOT represent a bundle-only "m=" section.
Hence, the offer MUST contain at least one bundled "m=" section with Hence, the offer MUST contain at least one bundled "m=" section with
a unique address:port (and a non-zero port value). a unique address:port (and a non-zero port value).
It is RECOMMENDED that the offerer assigns the suggested offerer It is RECOMMENDED that the offerer assigns the suggested offerer
BUNDLE address:port to a bundled "m=" section that the offerer BUNDLE address:port to a bundled "m=" section that the offerer
assumes it is unlikely that the answerer will reject, or move out of believes it is unlikely that the answerer will reject, or move out of
the BUNDLE group. How such assumption is made is outside the scope the BUNDLE group. How such assumption is made is outside the scope
of this document. of this document.
8.2.2. Example: Initial SDP Offer 8.2.2. Example: Initial SDP Offer
The example shows an initial SDP offer. The offer includes two "m=" The example shows an initial SDP offer. The offer includes two "m="
sections in the SDP, and suggests that both are included in a BUNDLE sections in the SDP, and suggests that both are included in a BUNDLE
group. The audio "m=" section is indicated by the offerer BUNDLE-tag group. The audio "m=" section is indicated by the offerer BUNDLE-tag
(placed first in the SDP group:BUNDLE attribute identification-id (placed first in the SDP group:BUNDLE attribute identification-id
list). list).
skipping to change at page 13, line 7 skipping to change at page 13, line 7
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 8.3. Generating the SDP Answer
When an answerer generates an answer that contains a BUNDLE group, When an answerer generates an answer that contains a BUNDLE group the
the following general SDP grouping framework restrictions, defined in following general SDP grouping framework restrictions, defined in
[RFC5888], also apply to the BUNDLE group: [RFC5888], also apply to the BUNDLE group:
o The answerer MUST NOT include a BUNDLE group in the answer, unless o The answerer is only allowed to include a BUNDLE group in the
the offerer requested the BUNDLE group to be negotiated in the answer if the offerer requested the BUNDLE group to be negotiated
corresponding offer; and in the corresponding offer; and
o The answerer MUST NOT include an "m=" section within a BUNDLE
group, unless the offerer requested the "m=" section to be within
that BUNDLE group in the corresponding offer.
o If the answer contains multiple BUNDLE groups, the answerer MUST o The answerer is only allowed to include an "m=" section within a
NOT move an "m=" section from one BUNDLE group to another. BUNDLE group if the offerer requested the "m=" section to be
within that same BUNDLE group in the corresponding offer.
If the answer contains a BUNDLE group, the answerer MUST: If the answer contains a BUNDLE group, the answerer MUST:
o Select an offerer BUNDLE address:port [Section 8.3.1]; and o Select an offerer BUNDLE address:port [Section 8.3.1]; and
o Select an answerer BUNDLE address:port [Section 8.3.2]. o Select an answerer BUNDLE address:port [Section 8.3.2].
The answerer is allowed to select a new answerer BUNDLE address:port The answerer is allowed to select a new answerer BUNDLE address:port
each time it generates an answer to an offer. each time it generates an answer to an offer.
skipping to change at page 15, line 21 skipping to change at page 15, line 18
group in an answer, it MUST first check the following criteria: group in an answer, it MUST first check the following criteria:
o In the corresponding offer, an offerer BUNDLE address:port o In the corresponding offer, an offerer BUNDLE address:port
(previously selected [Section 8.3.1] or newly suggested (previously selected [Section 8.3.1] or newly suggested
[Section 8.5.1]) has been assigned to the "m=" section by the [Section 8.5.1]) has been assigned to the "m=" section by the
offerer; or offerer; or
o In the corresponding offer, the "m=" section contains an SDP o In the corresponding offer, the "m=" section contains an SDP
'bundle-only' attribute and a zero port value. 'bundle-only' attribute and a zero port value.
If either criteria above is fulfilled, the answerer can not move the If either 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 8.3.4], or keep the "m=" section
within the BUNDLE group in the answer and later create an offer where within the BUNDLE group in the answer and later create an offer where
the "m=" section is moved out of the BUNDLE group [Section 8.5.3]. the "m=" section is moved out of the BUNDLE group [Section 8.5.3].
When the answerer generates an answer, in which it moves a bundled When the answerer generates an answer, in which it moves a bundled
"m=" section out of a BUNDLE group, the answerer: "m=" section out of a BUNDLE group, the answerer:
o MUST assign a unique address:port to the "m=" section; and o MUST assign a unique address:port to the "m=" section; and
o MUST NOT place the identification-tag associated with the "m=" o MUST NOT place the identification-tag associated with the "m="
section in the SDP 'group:BUNDLE' attribute identification-tag section in the SDP 'group:BUNDLE' attribute identification-tag
list associated with the BUNDLE group; and list associated with the BUNDLE group; and
o MUST NOT assign an SDP 'bundle-only' attribute to the "m=" o MUST NOT assign an SDP 'bundle-only' attribute to the "m="
section. section.
An answerer MUST NOT move an "m=" section from one BUNDLE group to Because an answerer is not allowed to move an "m=" section from one
another within an answer. If the answerer wants to move an "m=" BUNDLE group to another within an answer [Section 8.3], if the
section from one BUNDLE group to another it MUST first move the "m=" answerer wants to move an "m=" section from one BUNDLE group to
section out of the current BUNDLE group, and then generate an offer another it MUST first move the "m=" section out of the current BUNDLE
where the "m=" section is added to another BUNDLE group group, and then generate an offer where the "m=" section is added to
[Section 8.5.2]. another BUNDLE group [Section 8.5.2].
8.3.4. Rejecting a Media Description in a BUNDLE Group 8.3.4. Rejecting a Media Description in a BUNDLE Group
When an answerer wants to reject a bundled "m=" section in an answer, When an answerer wants to reject a bundled "m=" section in an answer,
it MUST first check the following criteria: it MUST first check the following criterium:
o In the corresponding offer, an offerer BUNDLE address:port o In the corresponding offer, an offerer BUNDLE address:port
(previously selected [Section 8.3.1] or newly suggested (previously selected [Section 8.3.1] or newly suggested
[Section 8.5.1]) has been assigned to the "m=" section by the [Section 8.5.1]) has been assigned to the "m=" section by the
offerer. offerer.
If the criteria 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 (unless the answerer rejects each bundled
"m=" section within the BUNDLE group). The answerer can either "m=" section within the BUNDLE group). The answerer can either
reject the whole offer, reject each bundled "m=" section within the reject the whole offer, reject each bundled "m=" section within the
BUNDLE group, or keep the "m=" section within the BUNDLE group in the BUNDLE group, or keep the "m=" section within the BUNDLE group in the
answer and later create an offer where the "m=" section is disabled answer and later create an offer where the "m=" section is disabled
within the BUNDLE group [Section 8.5.4]. within the BUNDLE group [Section 8.5.4].
When an answerer generates an answer, in which it rejects a bundled When an answerer generates an answer, in which it rejects a bundled
"m=" section, the answerer: "m=" section, the answerer:
skipping to change at page 17, line 8 skipping to change at page 17, line 8
The example below shows an SDP answer, based on the SDP offer in The example below shows an SDP answer, based on the SDP offer in
[Section 8.2.2]. The answerer accepts both "m=" sections within the [Section 8.2.2]. The answerer accepts both "m=" sections within the
BUNDLE group. The answerer assigns the answerer BUNDLE address:port BUNDLE group. The answerer assigns the answerer BUNDLE address:port
to the "m=" section indicated by the answerer BUNDLE-tag. The to the "m=" section indicated by the answerer BUNDLE-tag. The
answerer assigns a zero port value and an SDP 'bundle-only' attribute answerer assigns a zero port value and an SDP 'bundle-only' attribute
to the other bundled "m=" section. to the other bundled "m=" section.
SDP Answer SDP Answer
v=0 v=0
o=bob 2808844564 2808844564 IN IP6 2001:db8::3 o=bob 2808844564 2808844564 IN IP6 2001:db8::1
s= s=
c=IN IP6 2001:db8::3 c=IN IP6 2001:db8::1
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
a=rtcp-mux a=rtcp-mux
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 0 RTP/AVP 32 m=video 0 RTP/AVP 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=bundle-only a=bundle-only
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
8.4. Offerer Processing of the SDP Answer 8.4. Offerer Processing of the SDP Answer
When an offerer receives an answer, if the answer contains a BUNDLE When an offerer receives an answer, if the answer contains a BUNDLE
skipping to change at page 17, line 36 skipping to change at page 17, line 38
8.4. Offerer Processing of the SDP Answer 8.4. Offerer Processing of the SDP Answer
When an offerer receives an answer, if the answer contains a BUNDLE When an offerer receives an answer, if the answer contains a BUNDLE
group, the offerer MUST check that any bundled "m=" section in the group, the offerer MUST check that any bundled "m=" section in the
answer was indicated as bundled in the corresponding offer. If there answer was indicated as bundled in the corresponding offer. If there
is no mismatch, the offerer MUST use the offerer BUNDLE address:port, is no mismatch, the offerer MUST use the offerer BUNDLE address:port,
selected by the answerer [Section 8.3.1], as the address for each selected by the answerer [Section 8.3.1], as the address for each
bundled "m=" section. bundled "m=" section.
NOTE: As the answerer might reject one or more bundled "m=" sections, NOTE: As the answerer might reject one or more bundled "m=" sections,
or move a bundled "m=" section out of a BUNDLE group, each bundled or move a bundled "m=" section out of a BUNDLE group, a given bundled
"m=" section in the offer might not be indicated as bundled in the "m=" section in the offer might not be indicated as bundled in the
answer. 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 8.5. Modifying the Session
When an offerer generates a subsequent offer (i.e., a BUNDLE group When an offerer generates a subsequent offer (i.e., a BUNDLE group
has previously been negotiated), it MUST assign the previously has previously been negotiated), it MUST assign the previously
selected offerer BUNDLE address:port [Section 8.3.1], or a newly selected offerer BUNDLE address:port [Section 8.3.1], or a newly
suggested offerer BUNDLE address:port [Section 8.5.1], to exactly one suggested offerer BUNDLE address:port [Section 8.5.1], to exactly one
skipping to change at page 19, line 9 skipping to change at page 19, line 11
In addition, the offerer MUST place the identification-tag associated In addition, the offerer MUST place the identification-tag associated
with the added "m=" section in the SDP 'group:BUNDLE' attribute with the added "m=" section in the SDP 'group:BUNDLE' attribute
identification-tag list associated with the BUNDLE group identification-tag list associated with the BUNDLE group
[Section 8.2.1]. [Section 8.2.1].
NOTE: If the offerer also wants to suggest a new offerer BUNDLE NOTE: If the offerer also wants to suggest a new offerer BUNDLE
address:port to the BUNDLE group, the offerer can assign the newly address:port to the BUNDLE group, the offerer can assign the newly
suggested offerer BUNDLE address:port either to the added "m=" suggested offerer BUNDLE address:port either to the added "m="
section, or to some other "m=" section within the BUNDLE group section, or to some other "m=" section within the BUNDLE group
[Section 8.5.1]. [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 [Section 18.3] shows an example where an offerer sends an offer in
order to add a bundled "m=" section to a BUNDLE group. order to add a bundled "m=" section to a BUNDLE group.
8.5.3. Moving a Media Description Out of a BUNDLE Group 8.5.3. Moving a Media Description Out of a BUNDLE Group
When an offerer generates an offer, in which it wants to move a When an offerer generates an offer, in which it wants to move a
bundled "m=" section out of a BUNDLE group, the offerer: bundled "m=" section out of a BUNDLE group, the offerer:
o MUST assign a unique address:port to the "m=" section; and o MUST assign a unique address:port to the "m=" section; and
skipping to change at page 21, line 48 skipping to change at page 22, line 7
from the same SSRC. If transmission of multiple media types are done from the same SSRC. If transmission of multiple media types are done
with time overlap, RTP and RTCP fail to function. Even if done in with time overlap, RTP and RTCP fail to function. Even if done in
proper sequence this causes RTP Timestamp rate switching issues proper sequence this causes RTP Timestamp rate switching issues
[RFC7160]. However, once an SSRC has left the RTP session (by [RFC7160]. However, once an SSRC has left the RTP session (by
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
for RTP-based bundled media sent using a mixture of Diffserv
Codepoints.
10.1.1. Payload Type (PT) Value Reuse 10.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 Correct SDP Media Description 10.2. Associating RTP/RTCP Streams with the Correct SDP Media
Description
As described in [RFC3550], RTP packets are associated with RTP As described in [RFC3550], RTP packets are associated with RTP
streams [RFC7656]. Each RTP stream is identified by an SSRC value, streams [RFC7656]. Each RTP stream is identified by an SSRC value,
and each RTP packet includes an SSRC field that is used to associate and each RTP packet includes an SSRC field that is used to associate
the packet with the correct RTP stream. RTCP packets also use SSRCs the packet with the correct RTP stream. RTCP packets also use SSRCs
to identify which RTP streams the packet relates to. However, a RTCP to identify which RTP streams the packet relates to. However, a RTCP
packet can contain multiple SSRC fields, in the course of providing packet can contain multiple SSRC fields, in the course of providing
feedback or reports on different RTP streams, and therefore can be feedback or reports on different RTP streams, and therefore can be
associated with multiple such streams. associated with multiple such streams.
skipping to change at page 27, line 25 skipping to change at page 27, line 39
Temporal-Spatial Trade-off Request (TSTR): [RFC5104] (PT=PSFB, Temporal-Spatial Trade-off Request (TSTR): [RFC5104] (PT=PSFB,
FMT=5). FMT=5).
H.271 Video Back Channel Message (VBCM): [RFC5104] (PT=PSFB, H.271 Video Back Channel Message (VBCM): [RFC5104] (PT=PSFB,
FMT=7). FMT=7).
Temporary Maximum Media Bit Rate Request (TMMBR): [RFC5104] Temporary Maximum Media Bit Rate Request (TMMBR): [RFC5104]
(PT=RTPFB, FMT=3). (PT=RTPFB, FMT=3).
Layer Refresh Request (LRR): [I-D.ietf-avtext-lrr] (PT=PSFB, Layer Refresh Request (LRR): [I-D.ietf-avtext-lrr] (PT=PSFB,
FMT=TBD). FMT=10).
If the RTCP packet is a feedback notification that includes target If the RTCP packet is a feedback notification that includes target
SSRC(s), for each target SSRC that is found in the incoming SSRC SSRC(s), for each target SSRC that is found in the incoming SSRC
table, deliver a copy of the RTCP packet to the "m=" section table, deliver a copy of the RTCP packet to the "m=" section
associated with the RTP stream with matching SSRC. PSFB and RTPFB associated with the RTP stream with matching SSRC. PSFB and RTPFB
types that are handled in this way include: types that are handled in this way include:
Temporal-Spatial Trade-off Notification (TSTN): [RFC5104] Temporal-Spatial Trade-off Notification (TSTN): [RFC5104]
(PT=PSFB, FMT=6). This message is a notification in response (PT=PSFB, FMT=6). This message is a notification in response
to a prior TSTR. to a prior TSTR.
skipping to change at page 27, line 49 skipping to change at page 28, line 17
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 10.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 media specified by the
BUNDLE group. BUNDLE group. 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 When RTP/RTCP multiplexing is enabled, the same transport will be
used for both RTP packets and RTCP packets associated with the BUNDLE used for both RTP packets and RTCP packets associated with the BUNDLE
group. group.
10.3.1. SDP Offer/Answer Procedures 10.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
skipping to change at page 28, line 47 skipping to change at page 29, line 17
When an offerer generates an initial offer, if the offer contains one When an offerer generates an initial offer, if the offer contains one
or more RTP-based bundled "m=" sections (or, if there is a chance or more RTP-based bundled "m=" sections (or, if there is a chance
that RTP-based "m=" sections will later be added to the BUNDLE that RTP-based "m=" sections will later be added to the BUNDLE
group), the offerer MUST include an SDP 'rtcp-mux' attribute group), the offerer MUST include an SDP 'rtcp-mux' attribute
[RFC5761] in each bundled "m=" section (excluding any bundle-only [RFC5761] in each bundled "m=" section (excluding any bundle-only
"m=" sections), following the procedures for IDENTICAL mux category "m=" sections), following the procedures for IDENTICAL mux category
attributes in Section 8.1. In addition, the offerer MAY include an attributes in Section 8.1. In addition, the offerer MAY include an
SDP 'rtcp-mux-only' attribute [I-D.ietf-mmusic-mux-exclusive] in a SDP 'rtcp-mux-only' attribute [I-D.ietf-mmusic-mux-exclusive] in a
RTP-based bundled "m=" section. RTP-based bundled "m=" section.
NOTE: Whether the offerer associates the SDP 'rtcp-mux-only' NOTE: Whether the offerer includes the SDP 'rtcp-mux-only' attribute
attribute depends on whether the offerer supports fallback to usage depends on whether the offerer supports fallback to usage of a
of a separate port for RTCP in case the answerer moves one or more separate port for RTCP in case the answerer moves one or more RTP-
RTP-based "m=" section out of the BUNDLE group in the answer. based "m=" section 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 used for RTP-based "m="
sections moved out of the BUNDLE group by the answerer. sections 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
skipping to change at page 31, line 40 skipping to change at page 32, line 7
When an offerer assigns a BUNDLE address:port (previously selected or When an offerer assigns a BUNDLE address:port (previously selected or
newly suggested) to a bundled "m=" section, (the "m=" section newly suggested) to a bundled "m=" section, (the "m=" section
indicated by the offerer BUNDLE-tag) the offerer MUST only include indicated by the offerer BUNDLE-tag) the offerer MUST only include
SDP 'candidate' attributes (and other applicable ICE-related media- SDP 'candidate' attributes (and other applicable ICE-related media-
level SDP attributes) in that "m=" section, following the procedures level SDP attributes) in that "m=" section, following the procedures
in Section 8.1. in Section 8.1.
When an answerer assigns a BUNDLE address to an "m=" section within a When an answerer assigns a BUNDLE address to an "m=" section within a
BUNDLE group (the "m=" section represented by the answerer BUNDLE- BUNDLE group (the "m=" section represented by the answerer BUNDLE-
tag), the answerer onlys include SDP 'candidate' attributes (and tag), the answerer only includes SDP 'candidate' attributes (and
other applicable ICE-related media-level SDP attributes) in that "m=" other applicable ICE-related media-level SDP attributes) in that "m="
section, following the procedures in Section 8.1. The answerer MUST section, following the procedures in Section 8.1. The answerer MUST
NOT include ICE-related media-level SDP attributes in any other "m=" NOT include ICE-related media-level SDP attributes in any other "m="
sections. sections.
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',
and an IPv4 address of '0.0.0.0' (or, the IPv6 equivalent '::') to
multiple "m=" sections. As far as the procedures in this
specification are concerned, before a BUNDLE group has been
negotiated, those addresses:ports are processed as unique
addresses:ports.
NOTE: As most ICE-related media-level SDP attributes belong to the NOTE: As most ICE-related media-level SDP attributes belong to the
TRANSPORT mux category [I-D.ietf-mmusic-sdp-mux-attributes], the TRANSPORT mux category [I-D.ietf-mmusic-sdp-mux-attributes], the
offerer and answerer follow the procedures in Section 8.1 when offerer and answerer follow the procedures in Section 8.1 when
deciding whether to include an attribute in a bundled "m=" section. deciding whether to include an attribute in a bundled "m=" section.
However, in the case of ICE-related media-level attributes, the rules However, in the case of ICE-related media-level attributes, the rules
apply to all attributes (see note below), even if they belong to a apply to all attributes (see note below), even if they belong to a
different mux category. different mux category.
NOTE: The following ICE-related media-level SDP attributes are NOTE: The following ICE-related media-level SDP attributes are
defined in [I-D.ietf-mmusic-ice-sip-sdp]: 'candidate', 'remote- defined in [I-D.ietf-mmusic-ice-sip-sdp]: 'candidate', 'remote-
skipping to change at page 32, line 35 skipping to change at page 33, line 11
o Each usage of the DTLS association within the BUNDLE group MUST o Each usage of the DTLS association within the BUNDLE group MUST
use the same mechanism for determining whether an offer or answer use the same mechanism for determining whether an offer or answer
will trigger the establishment of a new DTLS association, or will trigger the establishment of a new DTLS association, or
whether an existing DTLS association will be used; and whether an existing DTLS association will be used; and
o If the DTLS client supports DTLS-SRTP [RFC5764] it MUST include o If the DTLS client supports DTLS-SRTP [RFC5764] it MUST include
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 13. RTP Header Extensions Consideration
When [RFC8285] RTP header extensions are used in the context of this When [RFC8285] RTP header extensions are used in the context of this
specification, the identifier used for a given extension MUST specification, the identifier used for a given extension MUST
skipping to change at page 33, line 14 skipping to change at page 33, line 34
14. Update to RFC 3264 14. 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 6 (Generating the Answer).
o Section 8.4 (Putting a Unicast Media Stream on Hold). o Section 8.4 (Putting a Unicast Media Stream on Hold).
14.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 14.1. Original text of section 5.1 (2nd paragraph) of RFC 3264
For recvonly and sendrecv streams, the port number and address in the For recvonly and sendrecv streams, the port number and address in the
offer indicate where the offerer would like to receive the media offer indicate where the offerer would like to receive the media
stream. For sendonly RTP streams, the address and port number stream. For sendonly RTP streams, the address and port number
indirectly indicate where the offerer wants to receive RTCP reports. indirectly indicate where the offerer wants to receive RTCP reports.
Unless there is an explicit indication otherwise, reports are sent to Unless there is an explicit indication otherwise, reports are sent to
the port number one higher than the number indicated. The IP address the port number one higher than the number indicated. The IP address
skipping to change at page 34, line 5 skipping to change at page 34, line 24
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 6 (4th paragraph) of RFC 3264 14.3. Original text of section 8.4 (6th paragraph) of RFC 3264
An offered stream MAY be rejected in the answer, for any reason. If
a stream is rejected, the offerer and answerer MUST NOT generate
media (or RTCP packets) for that stream. To reject an offered
stream, the port number in the corresponding stream in the answer
MUST be set to zero. Any media formats listed are ignored. At least
one MUST be present, as specified by SDP.
14.4. New text replacing section 6 (4th paragraph) of RFC 3264
An offered stream MAY be rejected in the answer, for any reason. If
a stream is rejected, the offerer and answerer MUST NOT generate
media (or RTCP packets) for that stream. A port number of zero in
the answer by default indicates that the offered stream is rejected,
but an extension mechanism might specify different semantics for the
usage of a zero port value. If a stream is rejected, any media
formats listed are ignored. At least one MUST be present, as
specified by SDP.
14.5. 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.6. New text replacing section 8.4 (6th paragraph) of RFC 3264 14.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
skipping to change at page 36, line 21 skipping to change at page 36, line 21
to arrive soon. to arrive soon.
15.1. RTCP MID SDES Item 15.1. RTCP MID SDES Item
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MID=TBD | length | identification-tag ... | MID=TBD | length | identification-tag ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The identification-tag payload is UTF-8 encoded, 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 15.2. RTP SDES Header Extension For MID
The payload, containing the identification-tag, of the RTP SDES The payload, containing the identification-tag, of the RTP SDES
header extension element can be encoded using either the one-byte or header extension element can be encoded using either the one-byte or
skipping to change at page 40, line 12 skipping to change at page 40, line 12
When the BUNDLE extension is used, the set of configurations of the When the BUNDLE extension is used, the set of configurations of the
security mechanism used in all the bundled media descriptions will security mechanism used in all the bundled media descriptions will
need to be compatible so that they can be used simultaneously, at need to be compatible so that they can be used simultaneously, at
least per direction or endpoint. When using SRTP this will be the least per direction or endpoint. When using SRTP this will be the
case, at least for the IETF defined key-management solutions due to case, at least for the IETF defined key-management solutions due to
their SDP attributes (a=crypto, a=fingerprint, a=mikey) and their their SDP attributes (a=crypto, a=fingerprint, a=mikey) and their
classification in [I-D.ietf-mmusic-sdp-mux-attributes]. classification in [I-D.ietf-mmusic-sdp-mux-attributes].
The security considerations of "RTP Header Extension for the RTP The security considerations of "RTP Header Extension for the RTP
Control Protocol (RTCP) Source Description Items" [RFC7941] requires Control Protocol (RTCP) Source Description Items" [RFC7941] requires
that when RTCP is confidentiality protected, and that any SDES RTP that when RTCP is confidentiality protected, then any SDES RTP header
header extension carrying an SDES item, such as the MID RTP header extension carrying an SDES item, such as the MID RTP header
extension, is also protected using commensurate strength algorithms. extension, is also protected using commensurate strength algorithms.
However, assuming the above requirements and recommendations are However, assuming the above requirements and recommendations are
followed, there are no known significant security risks with leaving followed, there are no known significant security risks with leaving
the MID RTP header extension without confidentiality protection. the MID RTP header extension without confidentiality protection.
Therefore, this specification updates RFC 7941 by adding the Therefore, this specification updates 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.
skipping to change at page 49, line 32 skipping to change at page 50, line 9
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 20. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing] [RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-49
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.
skipping to change at page 60, line 23 skipping to change at page 60, line 51
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 21. References
21.1. Normative References 21.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002, DOI 10.17487/RFC3264, June 2002, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc3264>. editor.org/info/rfc3264>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/info/rfc3550>. July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
in Session Description Protocol (SDP)", RFC 3605, in Session Description Protocol (SDP)", RFC 3605,
DOI 10.17487/RFC3605, October 2003, DOI 10.17487/RFC3605, October 2003, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc3605>. editor.org/info/rfc3605>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004, RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/info/rfc3711>. <https://www.rfc-editor.org/info/rfc3711>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566, Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <https://www.rfc-editor.org/info/rfc4566>. July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",
BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007,
<https://www.rfc-editor.org/info/rfc4961>. <https://www.rfc-editor.org/info/rfc4961>.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, Control Packets on a Single Port", RFC 5761,
DOI 10.17487/RFC5761, April 2010, DOI 10.17487/RFC5761, April 2010, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc5761>. editor.org/info/rfc5761>.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, Real-time Transport Protocol (SRTP)", RFC 5764,
DOI 10.17487/RFC5764, May 2010, DOI 10.17487/RFC5764, May 2010, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc5764>. editor.org/info/rfc5764>.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, Protocol (SDP) Grouping Framework", RFC 5888,
DOI 10.17487/RFC5888, June 2010, DOI 10.17487/RFC5888, June 2010, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc5888>. editor.org/info/rfc5888>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP [RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP
Header Extension for the RTP Control Protocol (RTCP) Header Extension for the RTP Control Protocol (RTCP)
Source Description Items", RFC 7941, DOI 10.17487/RFC7941, Source Description Items", RFC 7941, DOI 10.17487/RFC7941,
August 2016, <https://www.rfc-editor.org/info/rfc7941>. August 2016, <https://www.rfc-editor.org/info/rfc7941>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General
Mechanism for RTP Header Extensions", RFC 8285, Mechanism for RTP Header Extensions", RFC 8285,
DOI 10.17487/RFC8285, October 2017, DOI 10.17487/RFC8285, October 2017, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc8285>. editor.org/info/rfc8285>.
[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-18 (work in progress), February 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-17 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16
(work in progress), February 2018. (work in progress), December 2016.
[I-D.ietf-mmusic-mux-exclusive] [I-D.ietf-mmusic-mux-exclusive]
Holmberg, C., "Indicating Exclusive Support of RTP/RTCP Holmberg, C., "Indicating Exclusive Support of RTP/RTCP
Multiplexing using SDP", draft-ietf-mmusic-mux- Multiplexing using SDP", draft-ietf-mmusic-mux-
exclusive-12 (work in progress), May 2017. exclusive-12 (work in progress), May 2017.
[I-D.ietf-mmusic-ice-sip-sdp] [I-D.ietf-mmusic-ice-sip-sdp]
Petit-Huguenin, M., Keranen, A., and S. Nandakumar, Petit-Huguenin, M., Nandakumar, S., and A. Keranen,
"Session Description Protocol (SDP) Offer/Answer "Session Description Protocol (SDP) Offer/Answer
procedures for Interactive Connectivity Establishment procedures for Interactive Connectivity Establishment
(ICE)", draft-ietf-mmusic-ice-sip-sdp-16 (work in (ICE)", draft-ietf-mmusic-ice-sip-sdp-20 (work in
progress), November 2017. progress), April 2018.
[I-D.ietf-mmusic-trickle-ice-sip]
Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A
Session Initiation Protocol (SIP) Usage for Trickle ICE",
draft-ietf-mmusic-trickle-ice-sip-14 (work in progress),
February 2018.
21.2. Informative References 21.2. Informative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc3261>. editor.org/info/rfc3261>.
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
"RTP Control Protocol Extended Reports (RTCP XR)", "RTP Control Protocol Extended Reports (RTCP XR)",
RFC 3611, DOI 10.17487/RFC3611, November 2003, RFC 3611, DOI 10.17487/RFC3611, November 2003,
<https://www.rfc-editor.org/info/rfc3611>. <https://www.rfc-editor.org/info/rfc3611>.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile "Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104,
February 2008, <https://www.rfc-editor.org/info/rfc5104>. February 2008, <https://www.rfc-editor.org/info/rfc5104>.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
DOI 10.17487/RFC4585, July 2006, DOI 10.17487/RFC4585, July 2006, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc4585>. editor.org/info/rfc4585>.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009,
<https://www.rfc-editor.org/info/rfc5576>. <https://www.rfc-editor.org/info/rfc5576>.
[RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple
Clock Rates in an RTP Session", RFC 7160, Clock Rates in an RTP Session", RFC 7160,
DOI 10.17487/RFC7160, April 2014, DOI 10.17487/RFC7160, April 2014, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc7160>. editor.org/info/rfc7160>.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
<https://www.rfc-editor.org/info/rfc7201>. <https://www.rfc-editor.org/info/rfc7201>.
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms
for Real-Time Transport Protocol (RTP) Sources", RFC 7656, for Real-Time Transport Protocol (RTP) Sources", RFC 7656,
DOI 10.17487/RFC7656, November 2015, DOI 10.17487/RFC7656, November 2015, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc7656>. editor.org/info/rfc7656>.
[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services
(Diffserv) and Real-Time Communication", RFC 7657,
DOI 10.17487/RFC7657, November 2015, <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-17 (work in progress), Protocol", draft-ietf-ice-trickle-21 (work in progress),
February 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.
Flodman, "The Layer Refresh Request (LRR) RTCP Feedback Flodman, "The Layer Refresh Request (LRR) RTCP Feedback
Message", draft-ietf-avtext-lrr-07 (work in progress), Message", draft-ietf-avtext-lrr-07 (work in progress),
July 2017. July 2017.
Appendix A. Design Considerations Appendix A. Design Considerations
One of the main issues regarding the BUNDLE grouping extensions has One of the main issues regarding the BUNDLE grouping extensions has
 End of changes. 81 change blocks. 
185 lines changed or deleted 204 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/