draft-ietf-mmusic-sdp-bundle-negotiation-39.txt   draft-ietf-mmusic-sdp-bundle-negotiation-40.txt 
MMUSIC Working Group C. Holmberg MMUSIC Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 3264 (if approved) H. Alvestrand Updates: 3264 (if approved) H. Alvestrand
Intended status: Standards Track Google Intended status: Standards Track Google
Expires: March 4, 2018 C. Jennings Expires: May 24, 2018 C. Jennings
Cisco Cisco
August 31, 2017 November 20, 2017
Negotiating Media Multiplexing Using the Session Description Protocol Negotiating Media Multiplexing Using the Session Description Protocol
(SDP) (SDP)
draft-ietf-mmusic-sdp-bundle-negotiation-39.txt draft-ietf-mmusic-sdp-bundle-negotiation-40.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 address:port combination (BUNDLE address) for receiving media, single transport (5-tuple) for sending and receiving media described
referred to as bundled media, specified by multiple SDP media by multiple SDP media descriptions ("m=" sections). Such transport
descriptions ("m=" lines). 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
a BUNDLE group.
To assist endpoints in negotiating the use of bundle this To assist endpoints in negotiating the use of bundle this
specification defines a new SDP attribute, 'bundle-only', which can specification defines a new SDP attribute, 'bundle-only', which can
be used to request that specific media is only used if bundled. The be used to request that specific media is only used if bundled. The
specification also updates RFC 3264, to allow usage of zero port specification also updates RFC 3264, to allow assigning a zero port
values without meaning that media is rejected. value to a "m= section without meaning that the media described by
the "m=" section is disabled or rejected.
There are multiple ways to correlate the bundled RTP packets with the When RTP-based media is used, there are multiple ways to correlate
appropriate media descriptions. This specification defines a new bundled RTP packets with the appropriate "m=" section. This
Real-time Transport Protocol (RTP) source description (SDES) item and specification defines a new Real-time Transport Protocol (RTP) source
a new RTP header extension that provides an additional way to do this description (SDES) item and a new RTP header extension that provides
correlation by using them to carry a value that associates the RTP/ an additional way to do this correlation by using them to carry a
RTCP packets with a specific media description. value that associates the RTP/RTCP packets with a specific "m="
section.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://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 March 4, 2018. This Internet-Draft will expire on May 24, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 (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
skipping to change at page 2, line 39 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Applicability Statement . . . . . . . . . . . . . . . . . . . 7 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 7
5. SDP Grouping Framework BUNDLE Extension . . . . . . . . . . . 7 5. SDP Grouping Framework BUNDLE Extension . . . . . . . . . . . 7
6. SDP 'bundle-only' Attribute . . . . . . . . . . . . . . . . . 8 6. SDP 'bundle-only' Attribute . . . . . . . . . . . . . . . . . 8
7. SDP Information Considerations . . . . . . . . . . . . . . . 9 7. SDP Information Considerations . . . . . . . . . . . . . . . 9
7.1. Connection Data (c=) . . . . . . . . . . . . . . . . . . 9 7.1. Connection Data (c=) . . . . . . . . . . . . . . . . . . 9
7.2. Bandwidth (b=) . . . . . . . . . . . . . . . . . . . . . 9 7.2. Bandwidth (b=) . . . . . . . . . . . . . . . . . . . . . 9
8. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 9 8. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 9
8.1. Mux Category Considerations . . . . . . . . . . . . . . . 10 8.1. Mux Category Considerations . . . . . . . . . . . . . . . 10
8.2. Generating the Initial SDP Offer . . . . . . . . . . . . 10 8.2. Generating the Initial SDP Offer . . . . . . . . . . . . 11
8.2.1. Suggesting the offerer BUNDLE address . . . . . . . . 11 8.2.1. Suggesting the offerer BUNDLE address . . . . . . . . 11
8.2.2. Example: Initial SDP Offer . . . . . . . . . . . . . 11 8.2.2. Example: Initial SDP Offer . . . . . . . . . . . . . 12
8.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 12 8.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 12
8.3.1. Answerer Selection of Offerer Bundle Address . . . . 13 8.3.1. Answerer Selection of Offerer Bundle Address . . . . 13
8.3.2. Answerer Selection of Answerer BUNDLE Address . . . . 14 8.3.2. Answerer Selection of Answerer BUNDLE Address . . . . 14
8.3.3. Moving A Media Description Out Of A BUNDLE Group . . 14 8.3.3. Moving A Media Description Out Of A BUNDLE Group . . 14
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 . . . . . . . . . . . . . . . . . 15 8.3.5. Example: SDP Answer . . . . . . . . . . . . . . . . . 15
8.4. Offerer Processing of the SDP Answer . . . . . . . . . . 15 8.4. Offerer Processing of the SDP Answer . . . . . . . . . . 16
8.5. Modifying the Session . . . . . . . . . . . . . . . . . . 16 8.5. Modifying the Session . . . . . . . . . . . . . . . . . . 16
8.5.1. Suggesting a new offerer BUNDLE address . . . . . . . 16 8.5.1. Suggesting a new offerer BUNDLE address . . . . . . . 17
8.5.2. Adding a media description to a BUNDLE group . . . . 17 8.5.2. Adding a media description to a BUNDLE group . . . . 17
8.5.3. Moving A Media Description Out Of A BUNDLE Group . . 17 8.5.3. Moving A Media Description Out Of A BUNDLE Group . . 18
8.5.4. Disabling A Media Description In A BUNDLE Group . . . 18 8.5.4. Disabling A Media Description In A BUNDLE Group . . . 19
9. Protocol Identification . . . . . . . . . . . . . . . . . . . 18 9. Protocol Identification . . . . . . . . . . . . . . . . . . . 19
9.1. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 19 9.1. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 19
10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 19 10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 20
10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 19 10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 20
10.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . 20 10.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . 21
10.2. Associating RTP/RTCP Streams With Correct SDP Media 10.2. Associating RTP/RTCP Streams With Correct SDP Media
Description . . . . . . . . . . . . . . . . . . . . . . 20 Description . . . . . . . . . . . . . . . . . . . . . . 21
10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 26 10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 27
10.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . 26 10.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . 27
11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 28 11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 29
11.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 29 11.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 30
11.1.1. Generating the Initial SDP Offer . . . . . . . . . . 30 11.1.1. Generating the Initial SDP Offer . . . . . . . . . . 31
11.1.2. Generating the SDP Answer . . . . . . . . . . . . . 30 11.1.2. Generating the SDP Answer . . . . . . . . . . . . . 31
11.1.3. Offerer Processing of the SDP Answer . . . . . . . . 30 11.1.3. Offerer Processing of the SDP Answer . . . . . . . . 31
11.1.4. Modifying the Session . . . . . . . . . . . . . . . 30 11.1.4. Modifying the Session . . . . . . . . . . . . . . . 31
12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 30 12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 31
13. RTP Header Extensions Consideration . . . . . . . . . . . . . 31 13. RTP Header Extensions Consideration . . . . . . . . . . . . . 32
14. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 31 14. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 32
14.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 31 14.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 32
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 33
14.3. Original text of section 8.2 (2nd paragraph) of RFC 3264 32 14.3. Original text of section 8.2 (2nd paragraph) of RFC 3264 33
14.4. New text replacing section 8.2 (2nd paragraph) of RFC 14.4. New text replacing section 8.2 (2nd paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 32
14.5. Original text of section 8.4 (6th paragraph) of RFC 3264 32
14.6. New text replacing section 8.4 (6th paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 33
15. RTP/RTCP extensions for identification-tag transport . . . . 33 14.5. Original text of section 8.4 (6th paragraph) of RFC 3264 33
15.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 34 14.6. New text replacing section 8.4 (6th paragraph) of RFC
15.2. RTP SDES Header Extension For MID . . . . . . . . . . . 34 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 34
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 15. RTP/RTCP extensions for identification-tag transport . . . . 34
16.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 35 15.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 35
16.2. New RTP SDES Header Extension URI . . . . . . . . . . . 35 15.2. RTP SDES Header Extension For MID . . . . . . . . . . . 35
16.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 36 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
16.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 36 16.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 36
17. Security Considerations . . . . . . . . . . . . . . . . . . . 37 16.2. New RTP SDES Header Extension URI . . . . . . . . . . . 36
18. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 38 16.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 37
18.1. Example: Bundle Address Selection . . . . . . . . . . . 38 16.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 37
18.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 40 17. Security Considerations . . . . . . . . . . . . . . . . . . . 38
18. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 39
18.1. Example: Bundle Address Selection . . . . . . . . . . . 39
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 . . . . . . . . . . . . . . . . . . . . . . . . . 41 Group . . . . . . . . . . . . . . . . . . . . . . . . . 42
18.4. Example: Offerer Moves A Media Description Out Of A 18.4. Example: Offerer Moves A Media Description Out Of A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 43 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 44
18.5. Example: Offerer Disables A Media Description Within A 18.5. Example: Offerer Disables A Media Description Within A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 45 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 46
19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47
20. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 47 20. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 48
21. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 57
21.1. Normative References . . . . . . . . . . . . . . . . . . 56 21.1. Normative References . . . . . . . . . . . . . . . . . . 57
21.2. Informative References . . . . . . . . . . . . . . . . . 58 21.2. Informative References . . . . . . . . . . . . . . . . . 59
Appendix A. Design Considerations . . . . . . . . . . . . . . . 59 Appendix A. Design Considerations . . . . . . . . . . . . . . . 60
A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 59 A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 61
A.2. Usage of port number value zero . . . . . . . . . . . . . 61 A.2. Usage of port number value zero . . . . . . . . . . . . . 62
A.3. B2BUA And Proxy Interoperability . . . . . . . . . . . . 61 A.3. B2BUA And Proxy Interoperability . . . . . . . . . . . . 62
A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 62 A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 63
A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 62 A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 63
A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 62 A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 63
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64
1. Introduction 1. Introduction
When multimedia communications are established, each 5-tuple reserved When multimedia communications are established, each transport
for an individual media stream consume additional resources (5-tuple) reserved for an individual media stream consume additional
(especially when Interactive Connectivity Establishment (ICE) resources (especially when Interactive Connectivity Establishment
[RFC5245] is used). For this reason, it is attractive to use a (ICE) [I-D.ietf-ice-rfc5245bis] is used). For this reason, it is
5-tuple for multiple media streams. attractive to use a single transport for multiple media streams.
This specification defines a way to use a single address:port This specification defines a way to use a single transport (BUNDLE
combination (BUNDLE address) for receiving media specified by transport) for sending and receiving media (bundled media) described
multiple SDP media descriptions ("m=" lines). by multiple SDP media descriptions ("m=" sections). The same BUNDLE
transport is used for sending and receiving bundled media, which
means that the symmetric 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 the usage of a BUNDLE group. Within the BUNDLE group, a to negotiate which "m=" sections will become part of a BUNDLE group.
BUNDLE address is used for receiving media specified by multiple "m=" Within a BUNDLE group, each "m=" section will use a BUNDLE transport
lines. This is referred to as bundled media. for sending and receiving bundled media.
The offerer and answerer [RFC3264] use the BUNDLE extension to Within a BUNDLE group, each endpoint uses a single address:port
negotiate the BUNDLE addresses, one for the offerer (offerer BUNDLE combination for sending and receiving bundled media. The
address) and one for the answerer (answerer BUNDLE address), to be address:port combination is referred to as BUNDLE address. In
used for receiving the bundled media specified by a BUNDLE group. addition to negotiating the BUNDLE group, the offerer and answerer
Once the offerer and the answerer have negotiated a BUNDLE group, [RFC3264] use the BUNDLE extension to negotiate the BUNDLE addresses,
they associate their respective BUNDLE address with each "m=" line in one for the offerer (offerer BUNDLE address) and one for the answerer
the BUNDLE group. The BUNDLE addresses are used to receive all media (answerer BUNDLE address). Once the offerer and the answerer have
specified by the BUNDLE group. negotiated the BUNDLE addresses, and a BUNDLE group has been formed,
they assign their respective BUNDLE address to each "m=" section
within the BUNDLE group. The endpoints then use the BUNDLE addresses
for sending and receiving the bundled media associated with the
BUNDLE group.
The use of a BUNDLE group and a BUNDLE address also allows the usage The use of a BUNDLE transport also allows the usage of a single set
of a single set of Interactive Connectivity Establishment (ICE) of Interactive Connectivity Establishment (ICE)
[RFC5245] candidates for multiple "m=" lines. [I-D.ietf-ice-rfc5245bis] candidates for the whole BUNDLE group.
This specification also defines a new SDP attribute, 'bundle-only', This specification also defines a new SDP attribute, 'bundle-only',
which can be used to request that specific media is only used if kept which can be used to request that specific media is only used if the
within a BUNDLE group. The specification also updates RFC 3264, to "m=" section describing the media is kept within a BUNDLE group. The
allow usage of zero port values without meaning that media is specification also updates RFC 3264, to allow usage of zero port
rejected. values without meaning that media is rejected.
As defined in RFC 4566 [RFC4566], the semantics of assigning the same As defined in RFC 4566 [RFC4566], the semantics of assigning the same
transport address (IP address and port) to multiple "m=" lines are transport address (IP address and port) to multiple "m=" sections are
undefined, and there is no grouping defined by such means. Instead, undefined, and there is no grouping defined by such means. Instead,
an explicit grouping mechanism needs to be used to express the an explicit grouping mechanism needs to be used to express the
intended semantics. This specification provides such an extension. intended semantics. This specification provides such an extension.
This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264 This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264
[RFC3264]. The update allows an answerer to assign a non-zero port [RFC3264]. The update allows an answerer to assign a non-zero port
value to an "m=" line in an SDP answer, even if the "m=" line in the value to an "m=" section in an SDP answer, even if the "m=" section
associated SDP offer contained a zero port value. in the associated SDP offer contained a zero port value.
This specification also defines a new Real-time Transport Protocol This specification also defines a new Real-time Transport Protocol
(RTP) [RFC3550] source description (SDES) item, 'MID', and a new RTP (RTP) [RFC3550] source description (SDES) item, 'MID', and a new RTP
SDES header extension that can be used to associate RTP streams with SDES header extension that can be used to associate RTP streams with
media descriptions. "m=" sections.
SDP bodies can contain multiple BUNDLE groups. A given BUNDLE SDP bodies can contain multiple BUNDLE groups. A given BUNDLE
address MUST only be associated with a single BUNDLE group. The address MUST only be associated with a single BUNDLE group. The
procedures in this specification apply independently to a given procedures in this specification apply independently to a given
BUNDLE group. All RTP based media flows described by a single BUNDLE BUNDLE group. All RTP based media flows described by a single BUNDLE
group belong to a single RTP session [RFC3550]. 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 without an SDP 'group:BUNDLE' attribute, and are expected to assign a
associate a unique address with each "m=" line within an offer and unique address to each "m=" section within an offer and answer,
answer, according to the procedures in [RFC4566] and [RFC3264] according to the procedures in [RFC4566] and [RFC3264]
2. Terminology 2. Terminology
"m=" line: SDP bodies contain one or more media descriptions. Each "m=" section: SDP bodies contain one or more media descriptions,
media description is identified by an SDP "m=" line. referred to as "m=" sections. Each "m=" section is represented by an
SDP "m=" line, and zero or more SDP attributes associated with the
"m=" line. An local address:port combination is assigned to each
"m=" section.
5-tuple: A collection of the following values: source address, source 5-tuple: A collection of the following values: source address, source
port, destination address, destination port, and transport-layer port, destination address, destination port, and transport-layer
protocol. protocol.
Unique address: An IP address and port combination that is associated Unique address: An address:port combination that is assigned to only
with only one "m=" line in an offer or answer. one "m=" section in an offer or answer.
Shared address: An IP address and port combination that is associated Shared address: An address:port combination that is assigned to
with multiple "m=" lines within an offer or answer. multiple "m=" sections within an offer or answer.
Offerer BUNDLE-tag: The first identification-tag in a given SDP Offerer BUNDLE-tag: The first identification-tag in a given SDP
'group:BUNDLE' attribute identification-tag list in an offer. 'group:BUNDLE' attribute identification-tag list in an offer.
Answerer BUNDLE-tag: The first identification-tag in a given SDP Answerer BUNDLE-tag: The first identification-tag in a given SDP
'group:BUNDLE' attribute identification-tag list in an answer. 'group:BUNDLE' attribute identification-tag list in an answer.
Offerer BUNDLE address: Within a given BUNDLE group, an IP address Offerer BUNDLE address: Within a given BUNDLE group, an address:port
and port combination used by an offerer to receive all media combination used by an offerer to receive all media described by each
specified by each "m=" line within the BUNDLE group. "m=" section within the BUNDLE group.
Answerer BUNDLE address: Within a given BUNDLE group, an IP address Answerer BUNDLE address: Within a given BUNDLE group, an address:port
and port combination used by an answerer to receive all media combination used by an answerer to receive all media described by
specified by each "m=" line within the BUNDLE group. each "m=" section within the BUNDLE group.
BUNDLE group: A set of "m=" lines, created using an SDP Offer/Answer BUNDLE transport: The transport (5-tuple) used by all media described
exchange, which uses the same BUNDLE address for receiving media. by the "m=" sections within a BUNDLE group.
Bundled "m=" line: An "m=" line, whose identification-tag is placed BUNDLE group: A set of "m=" sections, created using an SDP Offer/
in an SDP 'group:BUNDLE' attribute identification-tag list in an Answer exchange, which uses a single BUNDLE transport for sending and
offer or answer. receiving all media described by the set of "m=" sections. The same
BUNDLE transport is used for sending and receiving media.
Bundle-only "m=" line: A bundled "m=" line with an associated SDP Bundled "m=" section: An "m=" section, whose identification-tag is
placed in an SDP 'group:BUNDLE' attribute identification-tag list in
an offer or answer.
Bundle-only "m=" section: A bundled "m=" section that contains an SDP
'bundle-only' attribute. 'bundle-only' attribute.
Bundled media: All media specified by a given BUNDLE group. Bundled media: All media specified by a given BUNDLE group.
Initial offer: The first offer, within an SDP session (e.g. a SIP Initial offer: The first offer, within an SDP session (e.g. a SIP
dialog when the Session Initiation Protocol (SIP) [RFC3261] is used dialog when the Session Initiation Protocol (SIP) [RFC3261] is used
to carry SDP), in which the offerer indicates that it wants to create to carry SDP), in which the offerer indicates that it wants to create
a given BUNDLE group. a given BUNDLE group.
Subsequent offer: An offer which contains a BUNDLE group that has Subsequent offer: An offer which contains a BUNDLE group that has
been created as part of a previous offer/answer exchange. been created as part of a previous offer/answer exchange.
Identification-tag: A unique token value that is used to identify an Identification-tag: A unique token value that is used to identify an
"m=" line. The SDP 'mid' attribute [RFC5888], associated with an "m=" section. The SDP 'mid' attribute [RFC5888] in an "m=" section
"m=" line, carries an unique identification-tag. The session-level carries the unique identification-tag assigned to that "m=" section.
SDP 'group' attribute [RFC5888] carries a list of identification- The session-level SDP 'group' attribute [RFC5888] carries a list of
tags, identifying the "m=" lines associated with that particular identification-tags, identifying the "m=" sections associated with
'group' attribute. that particular 'group' attribute.
3. Conventions 3. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. [RFC2119].
4. Applicability Statement 4. Applicability Statement
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
This section defines a new SDP Grouping Framework extension This section defines a new SDP Grouping Framework [RFC5888]
[RFC5888], 'BUNDLE'. The BUNDLE extension can be used with the SDP extension, 'BUNDLE'. The BUNDLE extension can be used with the SDP
Offer/Answer mechanism to negotiate the usage of a single Offer/Answer mechanism to negotiate a set of "m=" sections that will
address:port combination (BUNDLE address) for receiving bundled become part of a BUNDLE group. Within a BUNDLE group, each "m="
media. section will use a BUNDLE transport for sending and receiving bundled
media. Each endpoint use a single address:port combination for
A single address:port combination is also used for sending bundled sending receiving the bundled media.
media. The address:port combination used for sending bundled media
MAY be the same as the BUNDLE address, used to receive bundled media,
depending on whether symmetric RTP [RFC4961] is used.
All media associated with a BUNDLE group MUST be transport using the
same transport-layer protocol (e.g., UDP or TCP).
The BUNDLE extension is indicated using an SDP 'group' attribute with The BUNDLE extension is indicated using an SDP 'group' attribute with
a "BUNDLE" semantics value [RFC5888]. An identification-tag is a "BUNDLE" semantics value [RFC5888]. An identification-tag is
associated with each bundled "m=" line, and each identification-tag assigned to each bundled "m=" section, and each identification-tag is
is listed in the SDP 'group:BUNDLE' attribute identification-tag listed in the SDP 'group:BUNDLE' attribute identification-tag list.
list. Each "m=" line whose identification-tag is listed in the
Each "m=" section whose identification-tag is listed in the
identification-tag list is associated with a given BUNDLE group. identification-tag list is associated with a given BUNDLE group.
SDP bodies can contain multiple BUNDLE groups. Any given bundled SDP bodies can contain multiple BUNDLE groups. Any given bundled
"m=" line 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.
NOTE: The order of the "m=" lines 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=" lines occur in the SDP. order in which the "m=" sections occur in the SDP.
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.
skipping to change at page 8, line 27 skipping to change at page 8, line 38
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 In order to ensure that an answerer that does not support the BUNDLE
extension always rejects a bundled "m=" line, the offerer can assign extension always rejects a bundled "m=" section, the offerer can
a zero port value to the "m=" line. According to [RFC3264] an assign a zero port value to the "m=" section. According to [RFC3264]
answerer will reject such "m=" line. By associating an SDP 'bundle- an answerer will reject such "m=" section. By including an SDP
only' attribute with such "m=" line, the offerer can request that the 'bundle-only' attribute in such "m=" section, the offerer can request
answerer accepts the "m=" line if the answerer supports the Bundle that the answerer accepts the "m=" section if the answerer supports
extension, and if the answerer keeps the "m=" line within the the Bundle extension, and if the answerer keeps the "m=" section
associated BUNDLE group. within the associated BUNDLE group.
NOTE: Once the offerer BUNDLE address has been selected, the offerer NOTE: Once the offerer BUNDLE address has been selected, the offerer
does not need to include the 'bundle-only' attribute in subsequent does not need to include the 'bundle-only' attribute in subsequent
offers. By associating the offerer BUNDLE address with an "m=" line offers. By assigning the offerer BUNDLE address to an "m=" section
of a subsequent offer, the offerer will ensure that the answerer will of a subsequent offer, the offerer will ensure that the answerer will
either keep the "m=" line within the BUNDLE group, or the answerer either keep the "m=" section within the BUNDLE group, or the answerer
will have to reject the "m=" line. will have to reject the "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=" line with a zero port value, within an offer. Other bundled "m=" section with a zero port value, within an offer. Other
usage is unspecified. usage is 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
This section describes restrictions associated with the usage of SDP This section describes restrictions associated with the usage of SDP
parameters within a BUNDLE group. It also describes, when parameter parameters within a BUNDLE group. It also describes, when parameter
and attribute values have been associated with each bundled "m=" and attribute values have been assigned to each bundled "m=" section,
line, how to calculate a value for the whole BUNDLE group. how to calculate a value for the whole BUNDLE group.
7.1. Connection Data (c=) 7.1. Connection Data (c=)
The "c=" line nettype value [RFC4566] associated with a bundled "m=" The "c=" line nettype value [RFC4566] associated with a bundled "m="
line MUST be 'IN'. section MUST be 'IN'.
The "c=" line addrtype value [RFC4566] associated with a bundled "m=" The "c=" line addrtype value [RFC4566] associated with a bundled "m="
line MUST be 'IP4' or 'IP6'. The same value MUST be associated with section MUST be 'IP4' or 'IP6'. The same value MUST be associated
each "m=" line. with each "m=" section.
NOTE: Extensions to this specification can specify usage of the NOTE: Extensions to this specification can specify usage of the
BUNDLE mechanism for other nettype and addrtype values than the ones BUNDLE mechanism for other nettype and addrtype values than the ones
listed above. listed above.
7.2. Bandwidth (b=) 7.2. Bandwidth (b=)
An offerer and answerer MUST use the rules and restrictions defined An offerer and answerer MUST use the rules and restrictions defined
in [I-D.ietf-mmusic-sdp-mux-attributes] for associating the SDP in [I-D.ietf-mmusic-sdp-mux-attributes] for associating the SDP
bandwidth (b=) line with bundled "m=" lines. bandwidth (b=) line with bundled "m=" section.
8. SDP Offer/Answer Procedures 8. SDP Offer/Answer Procedures
This section describes the SDP Offer/Answer [RFC3264] procedures for: This section describes the SDP Offer/Answer [RFC3264] procedures for:
o Negotiating and creating a BUNDLE group; and o Negotiating and creating a BUNDLE group; and
o Selecting the BUNDLE addresses (offerer BUNDLE address and o Selecting the BUNDLE addresses (offerer BUNDLE address and
answerer BUNDLE address); and answerer BUNDLE address); and
o Adding an "m=" line to a BUNDLE group; and o Adding an "m=" section to a BUNDLE group; and
o Moving an "m=" line out of a BUNDLE group; and
o Disabling an "m=" line within a BUNDLE group. o Moving an "m=" section out of a BUNDLE group; and
o Disabling an "m=" section within a BUNDLE group.
The generic rules and procedures defined in [RFC3264] and [RFC5888] The generic rules and procedures defined in [RFC3264] and [RFC5888]
also apply to the BUNDLE extension. For example, if an offer is also apply to the BUNDLE extension. For example, if an offer is
rejected by the answerer, the previously negotiated SDP parameters rejected by the answerer, the previously negotiated SDP parameters
and characteristics (including those associated with a BUNDLE group) and characteristics (including those associated with a BUNDLE group)
apply. Hence, if an offerer generates an offer in which the offerer apply. Hence, if an offerer generates an offer in which the offerer
wants to create a BUNDLE group, and the answerer rejects the offer, wants to create a BUNDLE group, and the answerer rejects the offer,
the BUNDLE group is not created. the BUNDLE group is not created.
The procedures in this section are independent of the media type or The procedures in this section are independent of the media type or
"m=" line proto value represented by a bundled "m=" line. Section 10 "m=" line proto value assigned to a bundled "m=" section. Section 10
defines additional considerations for RTP based media. Section 6 defines additional considerations for RTP based media. Section 6
defines additional considerations for the usage of the SDP 'bundle- defines additional considerations for the usage of the SDP 'bundle-
only' attribute. Section 11 defines additional considerations for only' attribute. Section 11 defines additional considerations for
the usage of Interactive Connectivity Establishment (ICE) the usage of Interactive Connectivity Establishment (ICE)
[I-D.ietf-ice-rfc5245bis] mechanism. [I-D.ietf-ice-rfc5245bis] mechanism.
SDP offers and answers can contain multiple BUNDLE groups. The SDP offers and answers can contain multiple BUNDLE groups. The
procedures in this section apply independently to a given BUNDLE procedures in this section apply independently to a given BUNDLE
group. group.
8.1. Mux Category Considerations 8.1. Mux Category Considerations
When an offerer or answerer associates SDP attributes with a bundled When an offerer or answerer includes SDP attributes in a bundled "m="
"m=" line (including any bundle-only "m=" line) associated with a section (including any bundle-only "m=" section) to which a shared
shared address, IDENTICAL and TRANSPORT mux category SDP attributes address has been assigned, IDENTICAL and TRANSPORT mux category SDP
[I-D.ietf-mmusic-sdp-mux-attributes] are associated with the "m=" attributes [I-D.ietf-mmusic-sdp-mux-attributes] are included in the
line only if the "m=" line is also associated with the offerer/ "m=" section only if the "m=" section is also associated with the
answerer BUNDLE-tag. Otherwise the offerer/answerer MUST NOT offerer/answerer BUNDLE-tag. Otherwise the offerer/answerer MUST NOT
associate such SDP attributes with the "m=" line. The rule above include such SDP attributes in the "m=" section. The rule above does
does not apply to a bundled "m=" line associated with a unique not apply to a bundled "m=" section to which a unique address has
address. been assigned.
NOTE: As bundled "m=" lines (including any bundle-only "m=" line) NOTE: As bundled "m=" section (including any bundle-only "m="
associated with a shared address will share the same IDENTICAL and section) to which a shared address has been assigned will share the
TRANSPORT mux category SDP attributes, and attribute values, there is same IDENTICAL and TRANSPORT mux category SDP attributes, and
no need to associate such SDP attributes with each "m=" line. The attribute values, there is no need to include such SDP attributes in
attributes and attribute values are implicitly applied to each "m=" each "m=" section. The attributes and attribute values are
line. implicitly included and applied to each "m=" section.
The semantics of some SDP attributes only apply to specific types of The semantics of some SDP attributes only apply to specific types of
media. For example, the semantics of the SDP 'rtcp-mux' and SDP media. For example, the semantics of the SDP 'rtcp-mux' and SDP
'rtcp-mux-only' attributes only apply to "m=" lines describing RTP- 'rtcp-mux-only' attributes only apply to "m=" sections describing
based media. However, as described in Section 8.1, there are cases RTP-based media. However, as described in Section 8.1, there are
where IDENTICAL and TRANSPORT mux category SDP attributes are only cases where IDENTICAL and TRANSPORT mux category SDP attributes are
associated with the "m=" line associated with the BUNDLE-tag. That only included in the "m=" sections associated with the BUNDLE-tag.
means that media-specific IDENTICAL and TRANSPORT mux category That means that media-specific IDENTICAL and TRANSPORT mux category
attributes can be associated with an "m=" line associated with attributes can be included in an "m=" section associated with another
another type of media. type of media.
8.2. Generating the Initial SDP Offer 8.2. Generating the Initial SDP Offer
When an offerer generates an initial offer, in order to create a When an offerer generates an initial offer, in order to create a
BUNDLE group, it MUST: BUNDLE group, it MUST:
o Assign a unique address to each "m=" line within the offer, o Assign a unique address to each "m=" section within the offer,
following the procedures in [RFC3264], unless the media line is a following the procedures in [RFC3264], unless the media line is a
'bundle-only' "m=" line (see below); and 'bundle-only' "m=" section (see below); and
o Add an SDP 'group:BUNDLE' attribute to the offer; and o Include an SDP 'group:BUNDLE' attribute in the offer; and
o Place the identification-tag of each bundled "m=" line in the SDP o Place the identification-tag of each bundled "m=" section in the
'group:BUNDLE' attribute identification-tag list; and SDP 'group:BUNDLE' attribute identification-tag list; and
o Indicate which unique address the offerer suggests as the offerer o Indicate which unique address the offerer suggests as the offerer
BUNDLE address [Section 8.2.1]. BUNDLE address [Section 8.2.1].
If the offerer wants to request that the answerer accepts a given If the offerer wants to request that the answerer accepts a given
bundled "m=" line only if the answerer keeps the "m=" line within the bundled "m=" section only if the answerer keeps the "m=" section
BUNDLE group, the offerer MUST: within the BUNDLE group, the offerer MUST:
o Associate an SDP 'bundle-only' attribute [Section 8.2.1] with the o Include an SDP 'bundle-only' attribute [Section 8.2.1] in the "m="
"m=" line; and secction; and
o Assign a zero port value to the "m=" line. o Assign a zero port value to the "m=" section.
NOTE: If the offerer assigns a zero port value to an "m=" line, but NOTE: If the offerer assigns a zero port value to an "m=" section,
does not also associate an SDP 'bundle-only' attribute with the "m=" but does not also include an SDP 'bundle-only' attribute in the "m="
line, it is an indication that the offerer wants to disable the "m=" section, it is an indication that the offerer wants to disable the
line [Section 8.5.4]. "m=" section [Section 8.5.4].
[Section 18.1] shows an example of an initial offer. [Section 18.1] shows an example of an initial offer.
8.2.1. Suggesting the offerer BUNDLE address 8.2.1. Suggesting the offerer BUNDLE address
In the offer, the address associated with the "m=" line associated In the offer, the address:port combination assigned to the "m="
with the offerer BUNDLE-tag indicates the address that the offerer section associated with the offerer BUNDLE-tag indicates the
suggests as the offerer BUNDLE address. address:port combination that the offerer suggests as the offerer
BUNDLE address.
The "m=" line associated with the offerer BUNDLE-tag MUST NOT contain The offerer MUST NOT assign a zero port value, or an SDP 'bundle-
a zero port value or an SDP 'bundle-only' attribute. only' attribute, to the "m=" section associated with the offerer
BUNDLE-tag.
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="
lines in the SDP, and suggests that both are included in a BUNDLE section in the SDP, and suggests that both are included in a BUNDLE
group. The audio "m=" line is associated with the offerer BUNDLE-tag group. The audio "m=" section is associated with the offerer BUNDLE-
(placed first in the SDP group:BUNDLE attribute identificatoin-id tag (placed first in the SDP group:BUNDLE attribute identification-id
list). list).
SDP Offer SDP Offer
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s= s=
c=IN IP4 atlanta.example.com c=IN IP4 atlanta.example.com
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
skipping to change at page 12, line 38 skipping to change at page 12, line 46
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 following general SDP grouping framework restrictions, defined in the 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 MUST NOT include a BUNDLE group in the answer, unless
the offerer requested the BUNDLE group to be created in the the offerer requested the BUNDLE group to be created in the
corresponding offer; and corresponding offer; and
o The answerer MUST NOT include an "m=" line within a BUNDLE group, o The answerer MUST NOT include an "m=" section within a BUNDLE
unless the offerer requested the "m=" line to be within that group, unless the offerer requested the "m=" section to be within
BUNDLE group in the corresponding offer. that BUNDLE group in the corresponding offer.
o If the answer contains multiple BUNDLE groups, the answerer MUST
NOT move an "m=" section from one BUNDLE group to another.
If the answer contains a BUNDLE group, the answerer MUST: If the answer contains a BUNDLE group, the answerer MUST:
o Select an Offerer BUNDLE Address [Section 8.3.1]; and o Select an Offerer BUNDLE Address [Section 8.3.1]; and
o Select an Answerer BUNDLE Address [Section 8.3.2]; o Select an Answerer BUNDLE Address [Section 8.3.2];
The answerer is allowed to select a new Answerer BUNDLE address each The answerer is allowed to select a new Answerer BUNDLE address each
time it generates an answer to an offer. time it generates an answer to an offer.
If the answerer does not want to keep an "m=" line 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=" line out of the BUNDLE group [Section 8.3.3]; or o Move the "m=" section out of the BUNDLE group [Section 8.3.3]; or
o Reject the "m=" line [Section 8.3.4]; o Reject the "m=" section [Section 8.3.4];
If the answerer keeps a bundle-only "m=" line within the BUNDLE If the answerer keeps a bundle-only "m=" section within the BUNDLE
group, it follows the procedures (associates the answerer BUNDLE group, it follows the procedures (assigns the answerer BUNDLE address
address with the "m=" line etc) for any other "m=" line kept within to the "m=" section etc) for any other "m=" section kept within the
the BUNDLE group. BUNDLE group.
If the answerer does not want to keep a bundle-only "m=" line within If the answerer does not want to keep a bundle-only "m=" section
the BUNDLE group, it MUST reject the "m=" line [Section 8.3.4]. within the BUNDLE group, it MUST reject the "m=" section
[Section 8.3.4].
The answerer MUST NOT associate an SDP 'bundle-only' attribute with The answerer MUST NOT include an SDP 'bundle-only' attribute in any
any "m=" line in an answer. "m=" section in an answer.
NOTE: If a bundled "m=" line in an offer contains a zero port value, NOTE: If a bundled "m=" section in an offer contains a zero port
but the "m=" line does not contain an SDP 'bundle-only' attribute, it value, but the "m=" section does not contain an SDP 'bundle-only'
is an indication that the offerer wants to disable the "m=" line attribute, it is an indication that the offerer wants to disable the
[Section 8.5.4]. "m=" section [Section 8.5.4].
8.3.1. Answerer Selection of Offerer Bundle Address 8.3.1. Answerer Selection of Offerer Bundle Address
In an offer, the address (unique or shared) associated with the In an offer, the address (unique or shared) assigned to the bundled
bundled "m=" line associated with the offerer BUNDLE-tag indicates "m=" section associated with the offerer BUNDLE-tag indicates the
the address that the offerer suggests as the offerer BUNDLE address address that the offerer suggests as the offerer BUNDLE address
[Section 8.2.1]. The answerer MUST check whether that "m=" line [Section 8.2.1]. The answerer MUST check whether that "m=" section
fulfils the following criteria: fulfils the following criteria:
o The answerer will not move the "m=" line out of the BUNDLE group o The answerer will not move the "m=" section out of the BUNDLE
[Section 8.3.3]; and group [Section 8.3.3]; and
o The answerer will not reject the "m=" line [Section 8.3.4]; and
o The "m=" line does not contain a zero port value. o The answerer will not reject the "m=" section [Section 8.3.4]; and
o The "m=" section does not contain a zero port value.
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 address associated with the "m=" line as the offerer BUNDLE the address assigned to the "m=" section as the offerer BUNDLE
address. In the answer, the answerer BUNDLE-tag represents the "m=" address. In the answer, the answerer BUNDLE-tag represents the "m="
line, and the address associated with the "m=" line in the offer section, and the address assigned to the "m=" section in the offer
becomes the offerer BUNDLE address. becomes the offerer BUNDLE address.
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
select the next identification-tag in the identification-tag list, select the next identification-tag in the identification-tag list,
and perform the same criteria check for the "m=" line associated with and perform the same criteria check for the "m=" section associated
that identification-tag. If there are no more identification-tags in with that identification-tag. If there are no more identification-
the identification-tag list, the answerer MUST NOT create the BUNDLE tags in the identification-tag list, the answerer MUST NOT create the
group. In addition, unless the answerer rejects the whole offer, the BUNDLE group. In addition, unless the answerer rejects the whole
answerer MUST apply the answerer procedures for moving an "m=" line offer, the answerer MUST apply the answerer procedures for moving an
out of a BUNDLE group [Section 8.3.3] to each bundled "m=" line in "m=" section out of a BUNDLE group [Section 8.3.3] to each bundled
the offer when creating the answer. "m=" section in the offer when creating the answer.
[Section 18.1] shows an example of an offerer BUNDLE address [Section 18.1] shows an example of an offerer BUNDLE address
selection. selection.
8.3.2. Answerer Selection of Answerer BUNDLE Address 8.3.2. Answerer Selection of Answerer BUNDLE Address
When the answerer selects a BUNDLE address for itself, referred to as When the answerer selects a BUNDLE address for itself, referred to as
the answerer BUNDLE address, it MUST associate that address with each the answerer BUNDLE address, it MUST assign that address to each
bundled "m=" line within the created BUNDLE group in the answer. bundled "m=" section within the created BUNDLE group in the answer.
The answerer MUST NOT associate the answerer BUNDLE address with an The answerer MUST NOT assign the answerer BUNDLE address to an "m="
"m=" line that is not within the BUNDLE group, or to an "m=" line section that is not within the BUNDLE group, or to an "m=" section
that is within another BUNDLE group. that is within another BUNDLE group.
[Section 18.1] shows an example of an answerer BUNDLE address [Section 18.1] shows an example of an answerer BUNDLE address
selection. selection.
8.3.3. Moving A Media Description Out Of A BUNDLE Group 8.3.3. Moving A Media Description Out Of A BUNDLE Group
When an answerer wants to move an "m=" line out of a BUNDLE group, it When an answerer wants to move an "m=" section out of a BUNDLE group,
MUST first check the following criteria: it MUST first check the following criteria:
o In the corresponding offer, the "m=" line is associated with a o In the corresponding offer, a shared address (e.g. a previously
shared address (e.g. a previously selected offerer BUNDLE selected offerer BUNDLE address) has been assigned to the "m="
address); or section; or
o In the corresponding offer, an SDP 'bundle-only' attribute is o In the corresponding offer, the "m=" section contains an SDP
associated with the "m=" line, and the "m=" line contains a zero 'bundle-only' attribute, and the "m=" section contains a zero port
port value. value.
An answerer MUST NOT move an "m=" section from one BUNDLE group to
another within an answer. If the answerer wants to move an "m="
section from one BUNDLE group to another it MUST first move the
BUNDLE group out of the current BUNDLE group, and then generate an
offer where the "m=" section is added to another BUNDLE group
[Section 8.5.2].
If either criteria above is fulfilled, the answerer MUST reject the If either criteria above is fulfilled, the answerer MUST reject the
"m=" line [Section 8.3.4]. "m=" section [Section 8.3.4].
Otherwise, if in the corresponding offer the "m=" line is associated Otherwise, if a unique address has been assigned to the "m=" section
with a unique address, the answerer MUST associate a unique address in the corresponding offer, the answerer MUST assign a unique address
with the "m=" line in the answer (the answerer does not reject the to the "m=" section in the answer (the answerer does not reject the
"m=" line). "m=" section).
In addition, in either case above, the answerer MUST NOT place the In addition, in either case above, the answerer MUST NOT place the
identification-tag, associated with the moved "m=" line, in the SDP identification-tag, associated with the moved "m=" section, in the
'group' attribute identification-tag list associated with the BUNDLE SDP 'group' attribute identification-tag list associated with the
group. BUNDLE group.
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 rejects an "m=" line, it MUST associate an address When an answerer rejects an "m=" section, it MUST assign a zero port
with a zero port value with the "m=" line in the answer, according to value to "m=" section in the answer, according to the procedures in
the procedures in [RFC3264]. [RFC3264].
In addition, the answerer MUST NOT place the identification-tag, In addition, the answerer MUST NOT place the identification-tag
associated with the rejected "m=" line, in the SDP 'group' attribute associated with the rejected "m=" section in the SDP 'group'
identification-tag list associated with the BUNDLE group. attribute identification-tag list associated with the BUNDLE group.
8.3.5. Example: SDP Answer 8.3.5. Example: SDP Answer
The example shows an SDP answer, based on the SDP offer in The example shows an SDP answer, based on the SDP offer in
[Section 8.2.2]. The answers acceppts both "m=" lines in the BUNDLE [Section 8.2.2]. The answers accepts both "m=" sections within the
group. BUNDLE group.
SDP Answer SDP Answer
v=0 v=0
o=bob 2808844564 2808844564 IN IP4 biloxi.example.com o=bob 2808844564 2808844564 IN IP4 biloxi.example.com
s= s=
c=IN IP4 biloxi.example.com c=IN IP4 biloxi.example.com
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
skipping to change at page 15, line 44 skipping to change at page 16, line 28
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 20000 RTP/AVP 32 m=video 20000 RTP/AVP 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
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=" line in the group, the offerer MUST check that any bundled "m=" section in the
answer was indicated as bundled in the corresponding offer. If there answer was indicated as bundled in the corresponding offer. If there
is no mismatch, the offerer MUST use the offerer BUNDLE address, is no mismatch, the offerer MUST use the offerer BUNDLE address,
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=" line. bundled "m=" section.
NOTE: As the answerer might reject one or more bundled "m=" lines, or NOTE: As the answerer might reject one or more bundled "m=" sections,
move a bundled "m=" line out of a BUNDLE group, each bundled "m=" or move a bundled "m=" section out of a BUNDLE group, each bundled
line in the offer might not be indicated as bundled in the answer. "m=" section in the offer might not be indicated as bundled in the
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, it MUST associate the When an offerer generates a subsequent offer, it MUST assign the
previously selected offerer BUNDLE address [Section 8.3.1] with each previously selected offerer BUNDLE address [Section 8.3.1] to each
bundled "m=" line (including any bundle-only "m=" line), except if: bundled "m=" section (including any bundle-only "m=" section), except
if:
o The offerer suggests a new offerer BUNDLE address [Section 8.5.1]; o The offerer suggests a new offerer BUNDLE address [Section 8.5.1];
or or
o The offerer wants to add a bundled "m=" line to the BUNDLE group o The offerer wants to add a bundled "m=" section to the BUNDLE
[Section 8.5.2]; or group [Section 8.5.2]; or
o The offerer wants to move a bundled "m=" line out of the BUNDLE o The offerer wants to move a bundled "m=" section out of the BUNDLE
group [Section 8.5.3]; or group [Section 8.5.3]; or
o The offerer wants to disable the bundled "m=" line o The offerer wants to disable the bundled "m=" section
[Section 8.5.4]. [Section 8.5.4].
In addition, the offerer MUST select an offerer BUNDLE-tag In addition, the offerer MUST select an offerer BUNDLE-tag
[Section 8.2.1] associated with the previously selected offerer [Section 8.2.1] associated with the previously selected offerer
BUNDLE address, unless the offerer suggests a new offerer BUNDLE BUNDLE address, unless the offerer suggests a new offerer BUNDLE
address. address.
8.5.1. Suggesting a new offerer BUNDLE address 8.5.1. Suggesting a new offerer BUNDLE address
When an offerer generates an offer, in which it suggests a new When an offerer generates an offer, in which it suggests a new
offerer BUNDLE address [Section 8.2.1], the offerer MUST: offerer BUNDLE address [Section 8.2.1], the offerer MUST:
o Assign the address (shared address) to each "m=" line within the o Assign the address (shared address) to each "m=" section within
BUNDLE group; or the BUNDLE group; or
o Assign the address (unique address) to one bundled "m=" line. o Assign the address (unique address) to one bundled "m=" section.
In addition, the offerer MUST indicate that the address is the new In addition, the offerer MUST indicate that the address is the new
suggested offerer BUNDLE address [Section 8.2.1]. suggested offerer BUNDLE address [Section 8.2.1].
NOTE: Unless the offerer associates the new suggested offerer BUNDLE NOTE: Unless the offerer assigns the new suggested offerer BUNDLE
address with each bundled "m=" line, it can associate unique address to each bundled "m=" section, it can assign unique addresses
addresses with any number of bundled "m=" lines (and the previously to any number of bundled "m=" sections (and the previously selected
selected offerer BUNDLE address to any remaining bundled "m=" line) offerer BUNDLE address to any remaining bundled "m=" section) if it
if it wants to suggest multiple alternatives for the new offerer wants to suggest multiple alternatives for the new offerer BUNDLE
BUNDLE address. address.
8.5.2. Adding a media description to a BUNDLE group 8.5.2. Adding a media description to a BUNDLE group
When an offerer generates an offer, in which it wants to add a When an offerer generates an offer, in which it wants to add a
bundled "m=" line to a BUNDLE group, the offerer MUST: bundled "m=" section to a BUNDLE group, the offerer MUST:
o Assign a unique address to the added "m=" line; or o Assign a unique address to the added "m=" section; or
o Assign the previously selected offerer BUNDLE address to the added o Assign the previously selected offerer BUNDLE address to the added
"m=" line; or "m=" section; or
o If the offerer associates a new (shared address) suggested offerer o If the offerer assigns a new (shared address) suggested offerer
BUNDLE address with each bundled "m=" line [Section 8.5.1], also BUNDLE address to each bundled "m=" section [Section 8.5.1], also
associate that address with the added "m=" line. assigns that address to the added "m=" section.
In addition, the offerer MUST add the identification-tag associated In addition, the offerer MUST place the identification-tag associated
with the added "m=" line to the SDP 'group:BUNDLE' attribute with the added "m=" section in the SDP 'group:BUNDLE' attribute
identification-tag list with the BUNDLE group [Section 8.2.1]. identification-tag list associated with the BUNDLE group
[Section 8.2.1].
NOTE: Assigning a unique address to the "m=" line allows the answerer NOTE: Assigning a unique address to the "m=" section allows the
to move the "m=" line out of the BUNDLE group [Section 8.3.3], answerer to move the "m=" section out of the BUNDLE group
without having to reject the "m=" line. [Section 8.3.3], without having to reject the "m=" section.
If the offerer associates a unique address with the added "m=" line, If the offerer assigns a unique address to the added "m=" section,
and if the offerer suggests that address as the new offerer BUNDLE and if the offerer suggests that address as the new offerer BUNDLE
address [Section 8.5.1], the offerer BUNDLE-tag MUST represent the address [Section 8.5.1], the offerer BUNDLE-tag MUST represent the
added "m=" line [Section 8.2.1]. added "m=" section [Section 8.2.1].
If the offerer associates a new suggested offerer BUNDLE address with If the offerer associates a new suggested offerer BUNDLE address with
each bundled "m=" line [Section 8.5.1], including the added "m=" each bundled "m=" section [Section 8.5.1], including the added "m="
line, the offerer BUNDLE-tag MAY represent the added "m=" line section, the offerer BUNDLE-tag MAY represent the added "m=" section
[Section 8.2.1]. [Section 8.2.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=" line 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=" line out of a BUNDLE group it was added to in a previous bundled "m=" section out of a BUNDLE group it was added to in a
offer/answer transaction, the offerer: previous offer/answer transaction, the offerer:
o MUST assign a unique address to the "m=" section; and
o MUST associate a unique address with the "m=" line; and
o MUST NOT place the identification-tag associated with the "m=" o MUST NOT place the identification-tag associated with the "m="
line in the SDP 'group:BUNDLE' attribute identification-tag list section in the SDP 'group:BUNDLE' attribute identification-tag
associated with the BUNDLE group. list associated with the BUNDLE group.
NOTE: If the removed "m=" line is associated with the previously NOTE: If the removed "m=" section is associated with the previously
selected BUNDLE-tag, the offerer needs to suggest a new BUNDLE-tag selected BUNDLE-tag, the offerer needs to suggest a new BUNDLE-tag
[Section 8.2.1]. [Section 8.2.1].
NOTE: If an "m=" line, when being moved out of a BUNDLE group, is NOTE: If an "m=" section, when being moved out of a BUNDLE group, is
added to another BUNDLE group, the offerer applies the procedures in added to another BUNDLE group, the offerer applies the procedures in
[Section 8.5.2] to the "m=" line. [Section 8.5.2] to the "m=" section.
[Section 18.4] shows an example of an offer for moving an "m=" line An offerer MUST NOT move an "m=" section from one BUNDLE group to
out of a BUNDLE group. 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
BUNDLE group out of the current BUNDLE group, and then generate a
second offer where the "m=" section is added to another BUNDLE group
[Section 8.5.2].
[Section 18.4] shows an example of an offer for moving an "m="
section out of a BUNDLE group.
8.5.4. Disabling A Media Description In A BUNDLE Group 8.5.4. 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 an offer, in which it wants to disable a
bundled "m=" line (added to the BUNDLE group in a previous offer/ bundled "m=" section (added to the BUNDLE group in a previous offer/
answer transaction), the offerer: answer transaction), the offerer:
o MUST associate an address with a zero port value with the "m=" o MUST assign an address with a zero port value to the "m=" section,
line, following the procedures in [RFC4566]; and following the 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="
line in the SDP 'group:BUNDLE' attribute identification-tag list section in the SDP 'group:BUNDLE' attribute identification-tag
associated with the BUNDLE group. list associated with the BUNDLE group.
[Section 18.5] shows an example of an offer for disabling an "m=" [Section 18.5] shows an example of an offer for disabling an "m="
line within a BUNDLE group. section within a BUNDLE group.
9. Protocol Identification 9. Protocol Identification
Each "m=" line 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=" lines use different protocols on top layer protocol. If bundled "m=" sections use different protocols on
of the transport-layer protocol, there MUST exist a publicly top of the transport-layer protocol, there MUST exist a publicly
available specification which describes a mechanism, for this available specification which describes a mechanism, for this
particular protocol combination, how to associate received data with particular protocol combination, how to associate received data with
the correct protocol. the correct protocol.
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=" line, there MUST exist a publicly available bundled "m=" section, there MUST exist a publicly available
specification which describes a mechanism for associating the specification which describes a mechanism for associating the
received data with the correct "m=" line. received data with the correct "m=" section.
This document describes a mechanism to identify the protocol of This document describes a mechanism to identify the protocol of
received data among the STUN, DTLS and SRTP protocols (in any received data among the STUN, DTLS and SRTP protocols (in any
combination), when UDP is used as transport-layer protocol, but does combination), when UDP is used as transport-layer protocol, but does
not describe how to identify different protocols transported on DTLS. not describe how to identify different protocols transported on DTLS.
While the mechanism is generally applicable to other protocols and While the mechanism is generally applicable to other protocols and
transport-layer protocols, any such use requires further 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 9.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, Datagram Transport protocol of a received packet among the STUN, Datagram Transport
Layer Security (DTLS) and SRTP protocols (in any combination). If an Layer Security (DTLS) and SRTP protocols (in any combination). If an
offer or answer includes bundled "m=" lines that represent these offer or answer includes bundled "m=" section that represent these
protocols, the offerer or answerer MUST support the mechanism protocols, the offerer or answerer MUST support the mechanism
described in [RFC5764], and no explicit negotiation is required in described in [RFC5764], and no explicit negotiation is required in
order to indicate support and usage of the mechanism. order to indicate support and usage of the 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=" line, there MUST exist a specification which with more than one "m=" section, there MUST exist a specification
describes a mechanism for associating the received DTLS packet with which describes a mechanism for associating the received DTLS packet
the correct "m=" line. with the correct "m=" section.
[Section 10.2] describes how to associate the packets in a received [Section 10.2] describes how to associate the packets in a received
SRTP stream with the correct "m=" line. SRTP stream with the correct "m=" section.
10. RTP Considerations 10. RTP Considerations
10.1. Single RTP Session 10.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 RTP session is used for each bundle group, all "m=" Since a single BUNDLE transport is used for sending and receiving
lines representing RTP-based media in a bundle group will share a bundled media, the symmetric RTP mechanism [RFC4961] MUST be used for
single SSRC numbering space [RFC3550]. RTP-based bundled media.
Since a single RTP session is used for each BUNDLE group, all "m="
sections representing RTP-based media within a BUNDLE group will
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="
lines only if each codec associated with the payload type number sections only if each codec associated with the payload type
shares an identical codec configuration [Section 10.1.1]. number shares an identical codec configuration [Section 10.1.1].
o The proto value in each bundled RTP-based "m=" line 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 associating an o The RTP MID header extension MUST be enabled, by including an SDP
SDP 'extmap' attribute [RFC5285], with a 'urn:ietf:params:rtp- 'extmap' attribute [RFC8285], with a 'urn:ietf:params:rtp-
hdrext:sdes:mid' URI value, with each bundled RTP-based "m=" line 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
that originate from different bundled "m=" lines. that originate from different bundled "m=" sections.
NOTE: The last bullet above is to avoid sending multiple media types NOTE: The last bullet above is to avoid sending multiple media types
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=" line) after source (possibly associated with a different bundled "m=" section)
a delay of 5 RTCP reporting intervals (the delay is to ensure the after a delay of 5 RTCP reporting intervals (the delay is to ensure
SSRC has timed out, in case the RTCP BYE packet was lost [RFC3550]). the SSRC has timed out, in case the RTCP BYE packet was lost
[RFC3550]).
10.1.1. Payload Type (PT) Value Reuse 10.1.1. Payload Type (PT) Value Reuse
Multiple bundled "m=" lines might represent RTP based media. As all Multiple bundled "m=" section might describe RTP based media. As all
RTP based media specified by a BUNDLE group belong to the same RTP 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 inside session, in order for a given payload type value to be used inside
more than one bundled "m=" line, all codecs associated with the more than one bundled "m=" section, all codecs associated with the
payload type number MUST share an identical codec configuration. payload type number MUST share an identical codec configuration.
This means that the codecs MUST share the same media type, encoding This means that the codecs MUST share the same media type, encoding
name, clock rate and any parameter that can affect the codec name, clock rate and any parameter that can affect the codec
configuration and packetization. configuration and packetization.
[I-D.ietf-mmusic-sdp-mux-attributes] lists SDP attributes, whose [I-D.ietf-mmusic-sdp-mux-attributes] lists SDP attributes, whose
attribute values must be identical for all codecs that use the same attribute values must be identical for all codecs that use the same
payload type value. payload type value.
10.2. Associating RTP/RTCP Streams With Correct SDP Media Description 10.2. Associating RTP/RTCP Streams With Correct SDP Media Description
skipping to change at page 21, line 4 skipping to change at page 21, line 46
streams [RFC7656]. Each RTP stream is identified by an SSRC value, streams [RFC7656]. Each RTP stream is identified by an SSRC value,
and each RTP packet includes an SSRC field that is used to associate and each RTP packet includes an SSRC field that is used to associate
the packet with the correct RTP stream. RTCP packets also use SSRCs the packet with the correct RTP stream. RTCP packets also use SSRCs
to identify which RTP streams the packet relates to. However, a RTCP to identify which RTP streams the packet relates to. However, a RTCP
packet can contain multiple SSRC fields, in the course of providing packet can contain multiple SSRC fields, in the course of providing
feedback or reports on different RTP streams, and therefore can be feedback or reports on different RTP streams, and therefore can be
associated with multiple such streams. associated with multiple such streams.
In order to be able to process received RTP/RTCP packets correctly, In order to be able to process received RTP/RTCP packets correctly,
it must be possible to associate an RTP stream with the correct "m=" it must be possible to associate an RTP stream with the correct "m="
line, as the "m=" line and SDP attributes associated with the "m=" section, as the "m=" section and SDP attributes associated with the
line contain information needed to process the packets. "m=" section contains information needed to process the packets.
As all RTP streams associated with a BUNDLE group use the same As all RTP streams associated with a BUNDLE group use the same
address:port combination for sending and receiving RTP/RTCP packets, transport for sending and receiving RTP/RTCP packets, the local
the local address:port combination cannot be used to associate an RTP address:port combination part of the transport cannot be used to
stream with the correct "m=" line. In addition, multiple RTP streams associate an RTP stream with the correct "m=" section. In addition,
might be associated with the same "m=" line. multiple RTP streams might be associated with the same "m=" section.
An offerer and answerer can inform each other which SSRC values they An offerer and answerer can inform each other which SSRC values they
will use for an RTP stream by using the SDP 'ssrc' attribute will use for an RTP stream by using the SDP 'ssrc' attribute
[RFC5576]. However, an offerer will not know which SSRC values the [RFC5576]. However, an offerer will not know which SSRC values the
answerer will use until the offerer has received the answer providing answerer will use until the offerer has received the answer providing
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=" line 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=" line, the offerer and answerer an RTP stream with the correct "m=" section, the offerer and answerer
using the BUNDLE extension MUST support the mechanism defined in using the BUNDLE extension MUST support the mechanism defined in
Section 15, where the offerer and answerer insert the identification- Section 15, where the offerer and answerer insert the identification-
tag associated with an "m=" line (provided by the remote peer) into tag associated with an "m=" section (provided by the remote peer)
RTP and RTCP packets associated with a BUNDLE group. into RTP and RTCP packets associated with a BUNDLE group.
When using this mechanism, the mapping from an SSRC to an When using this mechanism, the mapping from an SSRC to an
identification-tag is carried in RTP header extensions or RTCP SDES identification-tag is carried in RTP header extensions or RTCP SDES
packets, as specified in Section 15. Since a compound RTCP packet packets, as specified in Section 15. Since a compound RTCP packet
can contain multiple RTCP SDES packets, and each RTCP SDES packet can can contain multiple RTCP SDES packets, and each RTCP SDES packet can
contain multiple chunks, a single RTCP packet can contain several contain multiple chunks, a single RTCP packet can contain several
SSRC to identification-tag mappings. The offerer and answerer SSRC to identification-tag mappings. The offerer and answerer
maintain tables used for routing that are updated each time an RTP/ maintain tables used for routing that are updated each time an RTP/
RTCP packet contains new information that affects how packets should RTCP packet contains new information that affects how packets should
be routed. be routed.
However, some implementations of may not include this identification- However, some implementations of may not include this identification-
tag in their RTP and RTCP traffic when using the BUNDLE mechanism, tag in their RTP and RTCP traffic when using the BUNDLE mechanism,
and instead use a payload type based mechanism to associate RTP and instead use a payload type based mechanism to associate RTP
streams with SDP m= lines. In this situation, each "m=" line MUST streams with SDP "m=" sections. In this situation, each "m=" section
use unique payload type values, in order for the payload type to be a MUST use unique payload type values, in order for the payload type to
reliable indicator of the relevant "m=" line for the RTP stream. be a reliable indicator of the relevant "m=" section for the RTP
Note that when using the payload type to associate RTP streams with stream. Note that when using the payload type to associate RTP
m= lines an RTP stream, identified by SSRC, will be mapped to an "m=" streams with "m=" sections an RTP stream, identified by SSRC, will be
line when the first packet of that RTP stream is received, and the mapped to an "m=" section when the first packet of that RTP stream is
mapping will not be changed even if the payload type used by that RTP received, and the mapping will not be changed even if the payload
stream changes. In other words, the SSRC cannot to "move" to a type used by that RTP stream changes. In other words, the SSRC
different "m=" line simply by changing the payload type. cannot to "move" to a different "m=" section simply by changing the
payload type.
Applications can implement RTP stacks in many different ways. The Applications can implement RTP stacks in many different ways. The
algorithm below details one way that RTP streams can be associated algorithm below details one way that RTP streams can be associated
with m= lines, but is not meant to be prescriptive about exactly how with "m=" sections, but is not meant to be prescriptive about exactly
an RTP stack needs to be implemented. Applications MAY use any how an RTP stack needs to be implemented. Applications MAY use any
algorithm that achieves equivalent results to those described in the algorithm that achieves equivalent results to those described in the
algorithm below. algorithm below.
To prepare to associate RTP streams with the correct "m=" line, the To prepare to associate RTP streams with the correct "m=" section,
following steps MUST be followed for each BUNDLE group. the following steps MUST be followed for each BUNDLE group.
Construct a table mapping MID to "m=" line for each "m=" line in Construct a table mapping MID to "m=" section for each "m="
this BUNDLE group. Note that an "m=" line may only have one MID. section in this BUNDLE group. Note that an "m=" section may only
have one MID.
Construct a table mapping SSRCs of incoming RTP streams to "m=" Construct a table mapping SSRCs of incoming RTP streams to "m="
line for each "m=" line in this BUNDLE group and for each SSRC section for each "m=" section in this BUNDLE group and for each
configured for receiving in that "m=" line. SSRC configured for receiving in that "m=" section.
Construct a table mapping the SSRC of each outgoing RTP stream to Construct a table mapping the SSRC of each outgoing RTP stream to
"m=line" for each "m=" line in this BUNDLE group and for each SSRC "m=" section for each "m=" section in this BUNDLE group and for
configured for sending in that "m=" line. each SSRC configured for sending in that "m=" section.
Construct a table mapping payload type to "m=" line for each "m=" Construct a table mapping payload type to "m=" section for each
line in the BUNDLE group and for each payload type configured for "m=" section in the BUNDLE group and for each payload type
receiving in that "m=" line. If any payload type is configured configured for receiving in that "m=" section. If any payload
for receiving in more than one "m=" line in the BUNDLE group, do type is configured for receiving in more than one "m=" section in
not it include it in the table, as it cannot be used to uniquely the BUNDLE group, do not it include it in the table, as it cannot
identify a "m=" line. be used to uniquely identify a "m=" section.
Note that for each of these tables, there can only be one mapping Note that for each of these tables, there can only be one mapping
for any given key (MID, SSRC, or PT). In other words, the tables for any given key (MID, SSRC, or PT). In other words, the tables
are not multimaps. are not multimaps.
As "m=" lines are added or removed from the BUNDLE groups, or their As "m=" sections are added or removed from the BUNDLE groups, or
configurations are changed, the tables above MUST also be updated. their configurations are changed, the tables above MUST also be
updated.
When an RTP packet is received, it MUST be delivered to the RTP When an RTP packet is received, it MUST be delivered to the RTP
stream corresponding to its SSRC. That RTP stream MUST then be stream corresponding to its SSRC. That RTP stream MUST then be
associated with the correct m= line within a BUNDLE group, for associated with the correct "m=" section within a BUNDLE group, for
additional processing, according to the following steps. additional processing, according to the following steps.
If the MID associated with the RTP stream is not in the table If the MID associated with the RTP stream is not in the table
mapping MID to a€œm=a€œ line, then the RTP mapping MID to "m=" section, then the RTP stream is not decoded
stream is not decoded and the payload data is discarded. and the payload data is discarded.
If the packet has a MID, and the packet's extended sequence number If the packet has a MID, and the packet's extended sequence number
is greater than that of the last MID update, as discussed in is greater than that of the last MID update, as discussed in
[RFC7941], Section 4.2.6, update the MID associated with the RTP [RFC7941], Section 4.2.6, update the MID associated with the RTP
stream to match the MID carried in the RTP packet, then update the stream to match the MID carried in the RTP packet, then update the
mapping tables to include an entry that maps the SSRC of that RTP mapping tables to include an entry that maps the SSRC of that RTP
stream to the a€œm=a€œ line for that MID. stream to the "m=" section for that MID.
If the SSRC of the RTP stream is in the incoming SSRC mapping If the SSRC of the RTP stream is in the incoming SSRC mapping
table, check that the payload type used by the RTP stream matches table, check that the payload type used by the RTP stream matches
a payload type included on the matching a payload type included on the matching "m=" section. If so,
a€œm=a€œ line. If so, associate the RTP associate the RTP stream with that "m=" section. Otherwise, the
stream with that a€œm=a€œ line. Otherwise, RTP stream is not decoded and the payload data is discarded.
the RTP stream is not decoded and the payload data is discarded.
If the payload type used by the RTP stream is in the payload type If the payload type used by the RTP stream is in the payload type
table, update the incoming SSRC mapping table to include an entry table, update the incoming SSRC mapping table to include an entry
that maps the RTP streama€™s SSRC to the that maps the RTP stream's SSRC to the "m=" section for that
a€œm=a€œ line for that payload type. payload type. Associate the RTP stream with the corresponding
Associate the RTP stream with the corresponding "m=" section.
a€œm=a€œ line.
Otherwise, mark the RTP stream as not for decoding and discard the Otherwise, mark the RTP stream as not for decoding and discard the
payload. payload.
If the RTP packet contains one of more contributing source (CSRC) If the RTP packet contains one of more contributing source (CSRC)
identifiers, then each CSRC is looked up in the incoming SSRC table identifiers, then each CSRC is looked up in the incoming SSRC table
and a copy of the RTP packet is associated with the corresponding m= and a copy of the RTP packet is associated with the corresponding
line for additional processing. "m=" section for additional processing.
For each RTCP packet received (including each RTCP packet that is For each RTCP packet received (including each RTCP packet that is
part of a compound RTCP packet), the packet is processed as usual by part of a compound RTCP packet), the packet is processed as usual by
the RTP layer, then is passed to the a€œm=a€œ the RTP layer, then is passed to the "m=" sections corresponding to
lines corresponding to the RTP streams it contains information about the RTP streams it contains information about for additional
for additional processing. This routing is type-dependent, as each processing. This routing is type-dependent, as each kind of RTCP
kind of RTCP packet has its own mechanism for associating it with the packet has its own mechanism for associating it with the relevant RTP
relevant RTP streams. streams.
RTCP packets for which no appropriate a€œm=a€œ RTCP packets for which no appropriate "m=" section can be identified
line can be identified MUST be processed as usual by the RTP layer, MUST be processed as usual by the RTP layer, updating the metadata
updating the metadata associated with the corresponding RTP streams, associated with the corresponding RTP streams, but are not passed to
but are not passed to any a€œm=a€œ line. This any "m=" section. This situation can occur with certain multiparty
situation can occur with certain multiparty RTP topologies, or when RTP topologies, or when RTCP packets are sent containing a subset of
RTCP packets are sent containing a subset of the SDES information. the SDES information.
Rules for additional processing of the various types of RTCP packets Rules for additional processing of the various types of RTCP packets
are explained below. are explained below.
If the RTCP packet is of type SDES, for each chunk in the packet If the RTCP packet is of type SDES, for each chunk in the packet
whose SSRC is found in the incoming SSRC table, deliver a copy of whose SSRC is found in the incoming SSRC table, deliver a copy of
the SDES packet to the "m=" line associated with that SSRC. In the SDES packet to the "m=" section associated with that SSRC. In
addition, for any SDES MID items contained in these chunks, if the addition, for any SDES MID items contained in these chunks, if the
MID is found in the table mapping MID to "m=" line, update the MID is found in the table mapping MID to "m=" section, update the
incoming SSRC table to include an entry that maps the RTP stream incoming SSRC table to include an entry that maps the RTP stream
associated with chunk's SSRC to the "m=" line associated with that associated with chunk's SSRC to the "m=" section associated with
MID, unless the packet is older than the packet that most recently that MID, unless the packet is older than the packet that most
updated the mapping for this SSRC, as discussed in [RFC7941], recently updated the mapping for this SSRC, as discussed in
Section 4.2.6. [RFC7941], Section 4.2.6.
Note that if an SDES packet is received as part of a compound RTCP Note that if an SDES packet is received as part of a compound RTCP
packet, the SSRC to "m=" line mapping may not exist until the SDES packet, the SSRC to "m=" section mapping may not exist until the
packet is handled (e.g., in the case where RTCP for a source is SDES packet is handled (e.g., in the case where RTCP for a source
received before any RTP packets). Therefore, when processing a is received before any RTP packets). Therefore, when processing a
compound packet, any contained SDES packet MUST be handled first. compound packet, any contained SDES packet MUST be handled first.
Note that this is a backwards change from [RFC3550] Section 6.1, Note that this is a backwards change from [RFC3550] Section 6.1,
which states that "Each individual RTCP packet in the compound which states that "Each individual RTCP packet in the compound
packet may be processed independently with no requirements upon packet may be processed independently with no requirements upon
the order or combination of packets". the order or combination of packets".
If the RTCP packet is of type BYE, it indicates that the RTP If the RTCP packet is of type BYE, it indicates that the RTP
streams referenced in the packet are ending. Therefore, for each streams referenced in the packet are ending. Therefore, for each
SSRC indicated in the packet that is found in the incoming SSRC SSRC indicated in the packet that is found in the incoming SSRC
table, first deliver a copy of the BYE packet to the "m=" line table, first deliver a copy of the BYE packet to the "m=" section
associated with that SSRC, but then remove the entry for that SSRC associated with that SSRC, but then remove the entry for that SSRC
from the incoming SSRC table after an appropriate delay to account from the incoming SSRC table after an appropriate delay to account
for "straggler packets", as specified in [RFC3550], Section 6.2.1. for "straggler packets", as specified in [RFC3550], Section 6.2.1.
If the RTCP packet is of type SR or RR, for each report block in If the RTCP packet is of type SR or RR, for each report block in
the report whose "SSRC of source" is found in the outgoing SSRC the report whose "SSRC of source" is found in the outgoing SSRC
table, deliver a copy of the SR or RR packet to the "m=" line table, deliver a copy of the SR or RR packet to the "m=" section
associated with that SSRC. In addition, if the packet is of type associated with that SSRC. In addition, if the packet is of type
SR, and the sender SSRC for the packet is found in the incoming SR, and the sender SSRC for the packet is found in the incoming
SSRC table, deliver a copy of the SR packet to the "m=" line SSRC table, deliver a copy of the SR packet to the "m=" section
associated with that SSRC. associated with that SSRC.
If the implementation supports RTCP XR and the packet is of type If the implementation supports RTCP XR and the packet is of type
XR, as defined in [RFC3611], for each report block in the report XR, as defined in [RFC3611], for each report block in the report
whose "SSRC of source" is is found in the outgoing SSRC table, whose "SSRC of source" is is found in the outgoing SSRC table,
deliver a copy of the XR packet to the "m=" line associated with deliver a copy of the XR packet to the "m=" section associated
that SSRC. In addition, if the sender SSRC for the packet is with that SSRC. In addition, if the sender SSRC for the packet is
found in the incoming SSRC table, deliver a copy of the XR packet found in the incoming SSRC table, deliver a copy of the XR packet
to the "m=" line associated with that SSRC. to the "m=" section associated with that SSRC.
If the RTCP packet is a feedback message of type RTPFB or PSFB, as If the RTCP packet is a feedback message of type RTPFB or PSFB, as
defined in [RFC4585], it will contain a media source SSRC, and defined in [RFC4585], it will contain a media source SSRC, and
this SSRC is used for routing certain subtypes of feedback this SSRC is used for routing certain subtypes of feedback
messages. However, several subtypes of PSFB messages include messages. However, several subtypes of PSFB messages include
target SSRC(s) in a section called Feedback Control Information target SSRC(s) in a section called Feedback Control Information
(FCI). For these messages, the target SSRC(s) are used for (FCI). For these messages, the target SSRC(s) are used for
routing. routing.
If the RTCP packet is a feedback packet that does not include If the RTCP packet is a feedback packet that does not include
target SSRCs in its FCI section, and the media source SSRC is target SSRCs in its FCI section, and the media source SSRC is
found in the outgoing SSRC table, deliver the feedback packet to found in the outgoing SSRC table, deliver the feedback packet to
the "m=" line associated with that SSRC. RTPFB and PSFB types the "m=" section associated with that SSRC. RTPFB and PSFB types
that are handled in this way include: that are handled in this way include:
Generic NACK: [RFC4585] (PT=RTPFB, FMT=1). Generic NACK: [RFC4585] (PT=RTPFB, FMT=1).
Picture Loss Indication (PLI): [RFC4585] (PT=PSFB, FMT=1). Picture Loss Indication (PLI): [RFC4585] (PT=PSFB, FMT=1).
Slice Loss Indication (SLI): [RFC4585] (PT=PSFB, FMT=2). Slice Loss Indication (SLI): [RFC4585] (PT=PSFB, FMT=2).
Reference Picture Selection Indication (RPSI): [RFC4585] Reference Picture Selection Indication (RPSI): [RFC4585]
(PT=PSFB, FMT=3). (PT=PSFB, FMT=3).
If the RTCP packet is a feedback message that does include target If the RTCP packet is a feedback message that does include target
SSRC(s) in its FCI section, it can either be a request or a SSRC(s) in its FCI section, it can either be a request or a
notification. Requests reference a RTP stream that is being sent notification. Requests reference a RTP stream that is being sent
by the message recipient, whereas notifications are responses to by the message recipient, whereas notifications are responses to
an earlier request, and therefore reference a RTP stream that is an earlier request, and therefore reference a RTP stream that is
being received by the message recipient. being received by the message recipient.
If the RTCP packet is a feedback request that includes target If the RTCP packet is a feedback request that includes target
SSRC(s), for each target SSRC that is found in the outgoing SSRC SSRC(s), for each target SSRC that is found in the outgoing SSRC
table, deliver a copy of the RTCP packet to the "m=" line table, deliver a copy of the RTCP packet to the "m=" section
associated with that SSRC. PSFB types that are handled in this associated with that SSRC. PSFB types that are handled in this
way include: way include:
Full Intra Request (FIR): [RFC5104] (PT=PSFB, FMT=4). Full Intra Request (FIR): [RFC5104] (PT=PSFB, FMT=4).
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).
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=TBD).
If the RTCP packet is a feedback notification that include target If the RTCP packet is a feedback notification that include 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=" line table, deliver a copy of the RTCP packet to the "m=" section
associated with the RTP stream with matching SSRC. PSFB types associated with the RTP stream with matching SSRC. PSFB types
that are handled in this way include: 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.
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.
When RTP/RTCP multiplexing is enabled, the same address:port When RTP/RTCP multiplexing is enabled, the same transport will be
combination will be used for sending all RTP packets and the RTCP used for both RTP packets and RTCP packets associated with the BUNDLE
packets associated with the BUNDLE group. Each endpoint will send group.
the packets towards the BUNDLE address of the other endpoint. The
same address:port combination MAY be used for receiving RTP packets
and RTCP packets.
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
multiplexing for RTP-based media associated with a BUNDLE group. multiplexing for RTP-based media associated with a BUNDLE group.
The mux category [I-D.ietf-mmusic-sdp-mux-attributes] of the SDP The mux category [I-D.ietf-mmusic-sdp-mux-attributes] of the SDP
'rtcp-mux' and 'rtcp-mux-only' attributes is IDENTICAL. Section 8.1 'rtcp-mux' and 'rtcp-mux-only' attributes is IDENTICAL. Section 8.1
describes the details regarding which bundled "m=" lines an offerer describes the details regarding which bundled "m=" sections an
and answerer associates the attributes with. offerer and answerer associates the attributes with.
RTP/RTCP multiplexing only applies to RTP-based media. However, as RTP/RTCP multiplexing only applies to RTP-based media. However, as
described in Section 8.1, within a BUNDLE group the SDP 'rtcp-mux' described in Section 8.1, within a BUNDLE group the SDP 'rtcp-mux'
and SDP 'rtcp-mux-only' attributes might be associated with a non- and SDP 'rtcp-mux-only' attributes might be included in a non-RTP-
RTP-based bundled "m=" line. based bundled "m=" section.
10.3.1.1. Generating the Initial SDP Offer 10.3.1.1. Generating the Initial SDP Offer
When an offerer generates an initial offer, if the offer contains one When an offerer generates an initial offer, if the offer contains one
or more RTP-based bundled "m=" lines (or, if there is a chance that or more RTP-based bundled "m=" sections (or, if there is a chance
RTP-based "m=" lines will later be added to the BUNDLE group), the that RTP-based "m=" sections will later be added to the BUNDLE
offerer MUST associate an SDP 'rtcp-mux' attribute [RFC5761] with one group), the offerer MUST include an SDP 'rtcp-mux' attribute
or more "m=" lines, following the procedures for IDENTICAL mux [RFC5761] in one or more "m=" sections, following the procedures for
category attributes in Section 8.1. In addition, the offerer MAY IDENTICAL mux category attributes in Section 8.1. In addition, the
associate an SDP 'rtcp-mux-only' attribute offerer MAY include an SDP 'rtcp-mux-only' attribute
[I-D.ietf-mmusic-mux-exclusive] with the same "m=" lines. [I-D.ietf-mmusic-mux-exclusive] in the same "m=" section.
NOTE: Whether the offerer associates the SDP 'rtcp-mux-only' NOTE: Whether the offerer associates the SDP 'rtcp-mux-only'
attribute depends on whether the offerer supports fallback to usage attribute depends on whether the offerer supports fallback to usage
of a separate port for RTCP in case the answerer moves one or more of a separate port for RTCP in case the answerer moves one or more
RTP-based "m=" line out of the BUNDLE group in the answer. RTP-based "m=" section out of the BUNDLE group in the answer.
NOTE: If the offerer associates an SDP 'rtcp-mux' attribute with one NOTE: If the offerer includes an SDP 'rtcp-mux' attribute in one or
or more bundled "m=" lines, but does not associate an SDP 'rtcp-mux- more bundled "m=" sections, but does not include an SDP 'rtcp-mux-
only' attribute, the offerer can also associate an SDP 'rtcp' only' attribute, the offerer can also include an SDP 'rtcp' attribute
attribute [RFC3605] with one or more RTP-based "m=" line in order to [RFC3605] in one or more RTP-based "m=" sections in order to provide
provide a fallback port for RTCP, as described in [RFC5761]. a fallback port for RTCP, as described in [RFC5761]. However, the
However, the fallback port will only be used for RTP-based "m=" lines fallback port will only be used for RTP-based "m=" sections moved out
moved out of the BUNDLE group by the answerer. 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=" line (excluding a bundle-only unique in each bundled RTP-based "m=" section (excluding a bundle-
"m=" line), similar to RTP. only "m=" section), similar to RTP.
10.3.1.2. Generating the SDP Answer 10.3.1.2. Generating the SDP Answer
When an answerer generates an answer, if the answerer supports RTP- When an answerer generates an answer, if the answerer supports RTP-
based media, and if a bundled "m=" line in the offer contained an SDP based media, and if a bundled "m=" section in the offer contained an
'rtcp-mux' attribute, the answerer MUST enable usage of RTP/RTCP SDP 'rtcp-mux' attribute, the answerer MUST enable usage of RTP/RTCP
multiplexing, even if there currently are no RTP-based "m=" lines multiplexing, even if there currently are no RTP-based "m=" sections
within the BUNDLE group. The answerer MUST associate an SDP 'rtcp- within the BUNDLE group. The answerer MUST include an SDP 'rtcp-mux'
mux' attribute with "m=" lines within the BUNDLE group in the answer attribute in "m=" sections within the BUNDLE group in the answer
following the procedures for IDENTICAL mux category attributes in following the procedures for IDENTICAL mux category attributes in
Section 8.1. In addition, if the "m=" line in the offer contained an Section 8.1. In addition, if the "m=" section in the offer contained
an SDP "rtcp-mux-only" attribute, the answerer MUST associate an SDP an an SDP "rtcp-mux-only" attribute, the answerer MUST include an SDP
"rtcp-mux-only" attribute with the "m=" line in the answer. "rtcp-mux-only" attribute to the "m=" section in the answer.
If the "m=" line associated with the offerer BUNDLE-tag in the offer If the "m=" section associated with the offerer BUNDLE-tag in the
contained an SDP 'rtcp-mux-only' attribute, and if the answerer moves offer contained an SDP 'rtcp-mux-only' attribute, and if the answerer
an RTP-based "m=" line out of the BUNDLE group in the answer moves an RTP-based "m=" section out of the BUNDLE group in the answer
Section 8.3.3, the answerer MUST either associate the attribute with Section 8.3.3, the answerer MUST either include the attribute with in
the moved "m=" line (and enable RTP/RTCP multiplexing for the media moved "m=" section (and enable RTP/RTCP multiplexing for the media
associated with the "m=" line), or reject the "m=" line associated with the "m=" section), or reject the "m=" section
Section 8.3.4. Section 8.3.4.
The answerer MUST NOT associate an SDP 'rtcp' attribute with any "m=" The answerer MUST NOT include an SDP 'rtcp' attribute in any "m="
line within the BUNDLE group in the answer. The answerer will use section within the BUNDLE group in the answer. The answerer will use
the port value of the selected offerer BUNDLE address for sending RTP the port value of the selected offerer BUNDLE address for sending RTP
and RTCP packets associated with each RTP-based bundled "m=" line and RTCP packets associated with each RTP-based bundled "m=" section
towards the offerer. 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 transaction, the answerer MUST negotiated in a previous offer/answer transaction, the answerer MUST
associate an SDP 'rtcp-mux' attribute with the "m=" line associated include an SDP 'rtcp-mux' attribute in the "m=" section associated
with the answerer BUNDLE-tag in the answer. It is not possible to with the answerer BUNDLE-tag in the answer. It is not possible to
disable RTP/RTCP multiplexing within a BUNDLE group. disable RTP/RTCP multiplexing within a BUNDLE group.
10.3.1.3. Offerer Processing of the SDP Answer 10.3.1.3. Offerer Processing of the SDP Answer
When an offerer receives an answer, if the answerer has accepted the When an offerer receives an answer, if the answerer has accepted the
usage of RTP/RTCP multiplexing (see Section 10.3.1.2), the answerer usage of RTP/RTCP multiplexing (see Section 10.3.1.2), the answerer
follows the procedures for RTP/RTCP multiplexing defined in follows the procedures for RTP/RTCP multiplexing defined in
[RFC5761]. The offerer will use the port value associated with the [RFC5761]. The offerer will use the port value associated with the
answerer BUNDLE address for sending RTP and RTCP packets associated answerer BUNDLE address for sending RTP and RTCP packets associated
with each RTP-based bundled "m=" line towards the answerer. with each RTP-based bundled "m=" section towards the answerer.
NOTE: It is considered a protocol error if the answerer has not NOTE: It is considered a protocol error if the answerer has not
accepted the usage of RTP/RTCP multiplexing for RTP-based "m=" lines accepted the usage of RTP/RTCP multiplexing for RTP-based "m="
that the answerer included in the BUNDLE group. sections that the answerer included in the BUNDLE group.
10.3.1.4. Modifying the Session 10.3.1.4. Modifying the Session
When an offerer generates a subsequent offer, the offerer MUST When an offerer generates a subsequent offer, the offerer MUST
associate an SDP 'rtcp-mux' attribute with a bundled "m=" line, include an SDP 'rtcp-mux' attribute in a bundled "m=" section,
following the procedures for IDENTICAL mux category attributes in following the procedures for IDENTICAL mux category attributes in
Section 8.1. Section 8.1.
If the offerer wants to add a bundled RTP-based "m=" line to the If the offerer wants to add a bundled RTP-based "m=" section to the
BUNDLE group, it MAY also associate an SDP 'rtcp-mux-only' attribute BUNDLE group, it MAY also include an SDP 'rtcp-mux-only' attribute in
with a bundled "m=", following the procedures for IDENTICAL mux a bundled "m=" section, following the procedures for IDENTICAL mux
category attributes in Section 8.1. This allows the offerer to category attributes in Section 8.1. This allows the offerer to
mandate RTP/RTCP multiplexing for the added "m=" line (or the "m=" mandate RTP/RTCP multiplexing for the added "m=" section (or the "m="
line to be rejected by the answerer) even if the answerer does not section to be rejected by the answerer) even if the answerer does not
accept the "m=" line within the BUNDLE group. accept the "m=" section within the BUNDLE group.
11. ICE Considerations 11. ICE Considerations
This section describes how to use the BUNDLE grouping extension This section describes how to use the BUNDLE grouping extension
together with the Interactive Connectivity Establishment (ICE) together with the Interactive Connectivity Establishment (ICE)
mechanism [I-D.ietf-ice-rfc5245bis]. mechanism [I-D.ietf-ice-rfc5245bis].
The generic procedures for negotiating usage of ICE using SDP, The generic procedures for negotiating usage of ICE using SDP,
defined in [I-D.ietf-mmusic-ice-sip-sdp], also apply to usage of ICE defined in [I-D.ietf-mmusic-ice-sip-sdp], also apply to usage of ICE
with BUNDLE, with the following exceptions: with BUNDLE, with the following exceptions:
o When BUNDLE addresses for a BUNDLE group have been selected for o When the BUNDLE transport has been established, ICE connectivity
both endpoints, ICE connectivity checks and keep-alives only need checks and keep-alives only need to be performed for the BUNDLE
to be performed for the whole BUNDLE group, instead of per bundled transport, instead of per individual "m=" section within the
"m=" line. BUNDLE group.
o Among bundled "m=" lines (including any bundle-only "m=" line) o Among bundled "m=" sections (including any bundle-only "m="
with which the offerer has associated a shared address, the section) to which the offerer has assigned a shared address, the
offerer only associates ICE-related media-level SDP attributes offerer only includes ICE-related media-level SDP attributes in
with the "m=" line associated with the offerer BUNDLE-tag, the "m=" section associated with the offerer BUNDLE-tag, following
following the procedures in Section 8.1. the procedures in Section 8.1.
o Among "m=" lines with which the answerer has associated a shared o Among "m=" sections within a BUNDLE group, to which the answerer
address within a BUNDLE group, the answerer only associates ICE- has assigned a shared address within, the answerer only includes
related media-level SDP attributes with the "m=" line associated ICE-related media-level SDP attributes in the "m=" section
with the answerer BUNDLE-tag, following the procedures in associated with the answerer BUNDLE-tag, following the procedures
Section 8.1. in Section 8.1.
Initially, before ICE has produced a candidate pair that will be used
for media, there might by multiple transports established (if
multiple candidate pairs are tested). Once ICE has produced a
transport that will be used for media, that becomes 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. is OPTIONAL.
11.1. SDP Offer/Answer Procedures 11.1. SDP Offer/Answer Procedures
When an offerer associates a unique address with a bundled "m=" line When an offerer assigns a unique address to a bundled "m=" section
(excluding any bundle-only "m=" line), the offerer MUST associate SDP (excluding any bundle-only "m=" section), the offerer MUST include
'candidate' attributes (and other applicable ICE-related media-level SDP 'candidate' attributes (and other applicable ICE-related media-
SDP attributes), containing unique ICE properties (candidates etc), level SDP attributes), containing unique ICE properties (candidates
with the "m=" line, according to the procedures in etc), in the "m=" section according to the procedures in
[I-D.ietf-mmusic-ice-sip-sdp]. [I-D.ietf-mmusic-ice-sip-sdp].
When an offerer associates a shared address with a bundled "m=" line, When an offerer assigns a shared address to a bundled "m=" section,
the offerer MUST associate SDP 'candidate' attributes (and other the offerer MUST include SDP 'candidate' attributes (and other
applicable ICE-related media-level SDP attributes) with the "m=" line applicable ICE-related media-level SDP attributes) in the "m="
following the procedures in Section 8.1. section following the procedures in Section 8.1.
When an answerer associates a shared address with an "m=" line within When an answerer assigns a shared address to an "m=" section within a
a BUNDLE group, if the answerer MUST associate SDP 'candidate' BUNDLE group, the answerer MUST include SDP 'candidate' attributes
attributes (and other applicable ICE-related media-level SDP (and other applicable ICE-related media-level SDP attributes) in the
attributes) with the "m=" line following the procedures in "m=" section following the procedures in Section 8.1.
Section 8.1.
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 associate an attribute with a bundled "m=" line. 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]: 'candidiate', 'remote- defined in [I-D.ietf-mmusic-ice-sip-sdp]: 'candidiate', 'remote-
candidates', 'ice-mismatch', 'ice-ufrag', 'ice-pwd', and 'ice- candidates', 'ice-mismatch', 'ice-ufrag', 'ice-pwd', and 'ice-
pacing'. pacing'.
11.1.1. Generating the Initial SDP Offer 11.1.1. Generating the Initial SDP Offer
When an offerer generates an initial offer, the offerer MUST When an offerer generates an initial offer, the offerer MUST include
associate ICE-related media-level SDP attributes with bundled "m=" ICE-related media-level SDP attributes in bundled "m=" sections
lines forllowin the procedures in [Section 11.1]. following the procedures in [Section 11.1].
11.1.2. Generating the SDP Answer 11.1.2. 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 answer MUST associate ICE-related SDP attributes to "m=" lines the answer MUST include ICE-related SDP attributes in "m=" sections
within the BUNDLE group according to [Section 11.1]. within the BUNDLE group according to [Section 11.1].
11.1.3. Offerer Processing of the SDP Answer 11.1.3. Offerer Processing of the SDP Answer
When an offerer receives an answer, if the answerer supports and uses When an offerer receives an answer, if the answerer supports and uses
the ICE mechanism and the BUNDLE extension, the offerer MUST the ICE mechanism and the BUNDLE extension, the offerer MUST apply
associate the ICE properties associated with the offerer BUNDLE the ICE properties associated with the offerer BUNDLE address,
address, selected by the answerer [Section 8.3.1], with each bundled selected by the answerer [Section 8.3.1], to each bundled "m="
"m=" line. section.
11.1.4. Modifying the Session 11.1.4. Modifying the Session
When an offerer generates a subsequent offer, it MUST associate ICE When an offerer generates a subsequent offer, it MUST include ICE-
properties to bundled "m=" lines following the procedures in related SDP attributes in a bundled "m=" section following the
[Section 11.1]. procedures in [Section 11.1].
12. DTLS Considerations 12. 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:
skipping to change at page 31, line 18 skipping to change at page 32, line 18
of DTLS-SRTP is not negotiated as part of the multimedia session of DTLS-SRTP is not negotiated as part of the multimedia session
(e.g., SIP session [RFC3261]. (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 [RFC5285] RTP header extensions are used in the context of this When [RFC8285] RTP header extensions are used in the context of this
specification, the identifier used for a given extension MUST specification, the identifier used for a given extension MUST
identify the same extension across all the bundled media identify the same extension across all the bundled media
descriptions. descriptions.
14. Update to RFC 3264 14. Update to RFC 3264
This section replaces the text of the following sections of RFC 3264: This section replaces the text of the following sections of RFC 3264:
o Section 5.1 (Unicast Streams). o Section 5.1 (Unicast Streams).
skipping to change at page 33, line 24 skipping to change at page 34, line 24
ports at the time of the offer. Of course, when used, the port ports at the time of the offer. Of course, when used, the port
number MUST NOT be zero, if it would specify that the stream has been number MUST NOT be zero, if it would specify that the stream has been
disabled. However, an extension mechanism might specify different disabled. However, an extension mechanism might specify different
semantics of the zero port number usage. An agent MUST be capable of semantics of the zero port number usage. An agent MUST be capable of
receiving SDP with a connection address of 0.0.0.0, in which case it receiving SDP with a connection address of 0.0.0.0, in which case it
means that neither RTP nor RTCP should be sent to the peer. means that neither RTP nor RTCP should be sent to the peer.
15. RTP/RTCP extensions for identification-tag transport 15. RTP/RTCP extensions for identification-tag transport
SDP Offerers and Answerers [RFC3264] can associate identification- SDP Offerers and Answerers [RFC3264] can associate identification-
tags with "m=" lines 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=" line. 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.
The SDES item and RTP SDES header extension make it possible for a The SDES item and RTP SDES header extension make it possible for a
receiver to associate each RTP stream with with a specific "m=" line, receiver to associate each RTP stream with with a specific "m="
with which the receiver has associated an identification-tag, even if section, with which the receiver has associated an identification-
those "m=" lines are part of the same RTP session. The RTP SDES tag, even if those "m=" sections are part of the same RTP session.
header extension also ensures that the media recipient gets the The RTP SDES header extension also ensures that the media recipient
identification-tag upon receipt of the first decodable media and is gets the identification-tag upon receipt of the first decodable media
able to associate the media with the correct application. and is able to associate the media with the correct application.
A media recipient informs the media sender about the identification- A media recipient informs the media sender about the identification-
tag associated with an "m=" line through the use of an 'mid' tag associated with an "m=" section through the use of an 'mid'
attribute [RFC5888]. The media sender then inserts the attribute [RFC5888]. The media sender then inserts the
identification-tag in RTCP and RTP packets sent to the media identification-tag in RTCP and RTP packets sent to the media
recipient. recipient.
NOTE: This text above defines how identification-tags are carried in NOTE: This text above defines how identification-tags are carried in
SDP Offers and Answers. The usage of other signalling protocols for SDP Offers and Answers. The usage of other signalling protocols for
carrying identification-tags is not prevented, but the usage of such carrying identification-tags is not prevented, but the usage of such
protocols is outside the scope of this document. protocols is outside the scope of this document.
[RFC3550] defines general procedures regarding the RTCP transmission [RFC3550] defines general procedures regarding the RTCP transmission
skipping to change at page 35, line 7 skipping to change at page 36, line 7
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
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 [RFC5285]. next 32-bit boundary using zero bytes [RFC8285].
As the identification-tag is included in either an RTCP SDES item or As the identification-tag is included in either an RTCP SDES item or
an RTP SDES header extension, or both, there should be some an RTP SDES header extension, or both, there should be some
consideration about the packet expansion caused by the consideration about the packet expansion caused by the
identification-tag. To avoid Maximum Transmission Unit (MTU) issues identification-tag. To avoid Maximum Transmission Unit (MTU) issues
for the RTP packets, the header extension's size needs to be taken for the RTP packets, the header extension's size needs to be taken
into account when encoding the media. into account when encoding the media.
It is recommended that the identification-tag is kept short. Due to It is recommended that the identification-tag is kept short. Due to
the properties of the RTP header extension mechanism, when using the the properties of the RTP header extension mechanism, when using the
skipping to change at page 36, line 15 skipping to change at page 37, line 15
Header Extensions sub-registry of the RTP Compact Header Extensions Header Extensions sub-registry of the RTP Compact Header Extensions
registry sub-registry, according to the following data: registry sub-registry, according to the following data:
Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid
Description: Media identification Description: Media identification
Contact: christer.holmberg@ericsson.com Contact: christer.holmberg@ericsson.com
Reference: RFCXXXX Reference: RFCXXXX
The SDES item does not reveal privacy information about the users. The SDES item does not reveal privacy information about the users.
It is simply used to associate RTP-based media with the correct SDP It is simply used to associate RTP-based media with the correct SDP
media description (m- line) in the SDP used to negotiate the media. media description ("m=" section) in the SDP used to negotiate the
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 16.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.]
skipping to change at page 38, line 34 skipping to change at page 39, line 34
Options for Securing RTP Sessions [RFC7201], for example SRTP Options for Securing RTP Sessions [RFC7201], for example SRTP
[RFC3711] can provide the necessary security functions of ensuring [RFC3711] can provide the necessary security functions of ensuring
the integrity and source authenticity. the integrity and source authenticity.
18. Examples 18. Examples
18.1. Example: Bundle Address Selection 18.1. Example: Bundle Address Selection
The example below shows: The example below shows:
o An offer, in which the offerer associates a unique address with o An offer, in which the offerer assigns a unique address to each
each bundled "m=" line within the BUNDLE group. bundled "m=" section within the BUNDLE group.
o An answer, in which the answerer selects the offerer BUNDLE o An answer, in which the answerer selects the offerer BUNDLE
address, and then selects its own BUNDLE address (the answerer address, and then selects its own BUNDLE address (the answerer
BUNDLE address) and associates it with each bundled "m=" line BUNDLE address) and assigns it to each bundled "m=" section within
within the BUNDLE group. the BUNDLE group.
SDP Offer (1) SDP Offer (1)
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s= s=
c=IN IP4 atlanta.example.com c=IN IP4 atlanta.example.com
t=0 0 t=0 0
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 40, line 9 skipping to change at page 41, line 9
m=video 20000 RTP/AVP 32 m=video 20000 RTP/AVP 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
18.2. Example: BUNDLE Extension Rejected 18.2. Example: BUNDLE Extension Rejected
The example below shows: The example below shows:
o An offer, in which the offerer associates a unique address with o An offer, in which the offerer assigns a unique address to each
each bundled "m=" line within the BUNDLE group. bundled "m=" section within the BUNDLE group.
o An answer, in which the answerer rejects the offered BUNDLE group, o An answer, in which the answerer rejects the offered BUNDLE group,
and associates a unique address with each "m=" line (following and assigns a unique address to each "m=" section (following
normal RFC 3264 procedures). normal RFC 3264 procedures).
SDP Offer (1) SDP Offer (1)
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s= s=
c=IN IP4 atlanta.example.com c=IN IP4 atlanta.example.com
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
skipping to change at page 42, line 7 skipping to change at page 43, line 7
b=AS:1000 b=AS:1000
a=rtcp-mux a=rtcp-mux
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
18.3. Example: Offerer Adds A Media Description To A BUNDLE Group 18.3. Example: Offerer Adds A Media Description To A BUNDLE Group
The example below shows: The example below shows:
o A subsequent offer (the BUNDLE group has been created as part of a o A subsequent offer (the BUNDLE group has been created as part of a
previous offer/answer exchange), in which the offerer adds a new previous offer/answer exchange), in which the offerer adds a new
"m=" line, represented by the "zen" identification-tag, to a "m=" section, represented by the "zen" identification-tag, to a
previously negotiated BUNDLE group, associates a unique address previously negotiated BUNDLE group, associates a unique address
with the added "m=" line, and associates the previously selected with the added "m=" section, and assigns the previously selected
offerer BUNDLE address with each of the other bundled "m=" lines offerer BUNDLE address to each of the other bundled "m=" sections
within the BUNDLE group. within the BUNDLE group.
o An answer, in which the answerer associates the answerer BUNDLE o An answer, in which the answerer assigns the answerer BUNDLE
address with each bundled "m=" line (including the newly added address to each bundled "m=" section (including the newly added
"m=" line) within the BUNDLE group. "m=" section) within the BUNDLE group.
SDP Offer (1) SDP Offer (1)
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s= s=
c=IN IP4 atlanta.example.com c=IN IP4 atlanta.example.com
t=0 0 t=0 0
a=group:BUNDLE foo bar zen a=group:BUNDLE foo bar zen
m=audio 10000 RTP/AVP 0 8 97 m=audio 10000 RTP/AVP 0 8 97
skipping to change at page 43, line 30 skipping to change at page 44, line 30
a=mid:zen a=mid:zen
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
18.4. Example: Offerer Moves A Media Description Out Of A BUNDLE Group 18.4. Example: Offerer Moves A Media Description Out Of A BUNDLE Group
The example below shows: The example below shows:
o A subsequent offer (the BUNDLE group has been created as part of a o A subsequent offer (the BUNDLE group has been created as part of a
previous offer/answer transaction), in which the offerer moves a previous offer/answer transaction), in which the offerer moves a
bundled "m=" line out of a BUNDLE group, associates a unique bundled "m=" section out of a BUNDLE group, assigns a unique
address with the moved "m=" line, and associates the offerer address to the moved "m=" section, and assigns the offerer BUNDLE
BUNDLE address with each other bundled "m=" line within the BUNDLE address to each other bundled "m=" section within the BUNDLE
group. group.
o An answer, in which the answerer moves the "m=" line out of the o An answer, in which the answerer moves the "m=" section out of the
BUNDLE group, associates a unique address with the moved "m=" BUNDLE group, assigns a unique address to the moved "m=" section,
line, and associates the answerer BUNDLE address with each of the and assigns the answerer BUNDLE address to each of the remaining
remaining bundled "m=" line within the BUNDLE group. bundled "m=" sections within the BUNDLE group.
SDP Offer (1) SDP Offer (1)
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s= s=
c=IN IP4 atlanta.example.com c=IN IP4 atlanta.example.com
t=0 0 t=0 0
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 45, line 12 skipping to change at page 46, line 12
a=rtcp-mux a=rtcp-mux
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
18.5. Example: Offerer Disables A Media Description Within A BUNDLE 18.5. Example: Offerer Disables A Media Description Within A BUNDLE
Group Group
The example below shows: The example below shows:
o A subsequent offer (the BUNDLE group has been created as part of a o A subsequent offer (the BUNDLE group has been created as part of a
previous offer/answer transaction), in which the offerer disables previous offer/answer transaction), in which the offerer disables
a bundled "m=" line within a BUNDLE group, assigns a zero port a bundled "m=" section within a BUNDLE group, assigns a zero port
number to the disabled "m=" line, and associates the offerer number to the disabled "m=" section, and assigns the offerer
BUNDLE address with each of the other bundled "m=" lines within BUNDLE address to each of the other bundled "m=" sections within
the BUNDLE group. the BUNDLE group.
o An answer, in which the answerer moves the disabled "m=" line out o An answer, in which the answerer moves the disabled "m=" sections
of the BUNDLE group, assigns a zero port value to the disabled out of the BUNDLE group, assigns a zero port value to the disabled
"m=" line, and associates the answerer BUNDLE address with each of "m=" section, and assigns the answerer BUNDLE address to each of
the remaining bundled "m=" line within the BUNDLE group. the remaining bundled "m=" sections within the BUNDLE group.
SDP Offer (1) SDP Offer (1)
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s= s=
c=IN IP4 atlanta.example.com c=IN IP4 atlanta.example.com
t=0 0 t=0 0
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 46, line 38 skipping to change at page 47, line 38
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.
Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas
Stach, Ari Keranen, Adam Roach, Christian Groves, Roman Shpount, Stach, Ari Keranen, Adam Roach, Christian Groves, Roman Shpount,
Suhas Nandakumar, Nils Ohlmeier, Jens Guballa, Raju Makaraju and Suhas Nandakumar, Nils Ohlmeier, Jens Guballa, Raju Makaraju, Justin
Justin Uberti for reading the text, and providing useful feedback. Uberti, Taylor Brandstetter, Byron Campen and Eric Rescorla for
reading the text, and providing useful feedback.
Thanks to Bernard Aboba, Cullen Jennings, Peter Thatcher, Justin Thanks to Bernard Aboba, Cullen Jennings, Peter Thatcher, Justin
Uberti, and Magnus Westerlund for providing the text for the section Uberti, and Magnus Westerlund for providing the text for the section
on RTP/RTCP stream association. on RTP/RTCP stream association.
Thanks to Magnus Westerlund, Colin Perkins and Jonathan Lennox for Thanks to Magnus Westerlund, Colin Perkins and Jonathan Lennox for
providing help and text on the RTP/RTCP procedures. providing help and text on the RTP/RTCP procedures.
Thanks to Spotify for providing music for the countless hours of Thanks to Spotify for providing music for the countless hours of
document editing. document editing.
20. Change Log 20. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing] [RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-39
o Editorial terminology changes.
o RFC 5285 reference replaced by reference to RFC 8285.
o https://github.com/cdh4u/draft-sdp-bundle/pull/44
o - Clarify that an m- section can not be moved between BUNDLE
groups without first moving the m- section out of a BUNDLE group.
o https://github.com/cdh4u/draft-sdp-bundle/pull/41
o - Addition of BUNDLE transport concept.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-38 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-38
o Changes to RTP streaming mapping section based on text from Colin o Changes to RTP streaming mapping section based on text from Colin
Perkins. Perkins.
o The following GitHub pull requests were merged: o The following GitHub pull requests were merged:
o https://github.com/cdh4u/draft-sdp-bundle/pull/34 o https://github.com/cdh4u/draft-sdp-bundle/pull/34
o - Proposed updates to RTP processing o - Proposed updates to RTP processing
skipping to change at page 56, line 42 skipping to change at page 58, line 9
<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>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
DOI 10.17487/RFC5245, April 2010, <https://www.rfc-
editor.org/info/rfc5245>.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July
2008, <https://www.rfc-editor.org/info/rfc5285>.
[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, <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, <https://www.rfc- DOI 10.17487/RFC5764, May 2010, <https://www.rfc-
editor.org/info/rfc5764>. editor.org/info/rfc5764>.
skipping to change at page 57, line 30 skipping to change at page 58, line 34
[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>.
[RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General
Mechanism for RTP Header Extensions", RFC 8285,
DOI 10.17487/RFC8285, October 2017, <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-10 (work in progress), May 2017. rfc5245bis-15 (work in progress), November 2017.
[I-D.ietf-mmusic-sdp-mux-attributes] [I-D.ietf-mmusic-sdp-mux-attributes]
Nandakumar, S., "A Framework for SDP Attributes when Nandakumar, S., "A Framework for SDP Attributes when
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16
(work in progress), December 2016. (work in progress), December 2016.
[I-D.ietf-mmusic-mux-exclusive] [I-D.ietf-mmusic-mux-exclusive]
Holmberg, C., "Indicating Exclusive Support of RTP/RTCP Holmberg, C., "Indicating Exclusive Support of RTP/RTCP
Multiplexing using SDP", draft-ietf-mmusic-mux- Multiplexing using SDP", draft-ietf-mmusic-mux-
exclusive-12 (work in progress), May 2017. exclusive-12 (work in progress), May 2017.
[I-D.ietf-mmusic-ice-sip-sdp] [I-D.ietf-mmusic-ice-sip-sdp]
Petit-Huguenin, M., Keranen, A., and S. Nandakumar, Petit-Huguenin, M., Keranen, A., and S. Nandakumar,
"Session Description Protocol (SDP) Offer/Answer "Session Description Protocol (SDP) Offer/Answer
procedures for Interactive Connectivity Establishment procedures for Interactive Connectivity Establishment
(ICE)", draft-ietf-mmusic-ice-sip-sdp-13 (work in (ICE)", draft-ietf-mmusic-ice-sip-sdp-14 (work in
progress), June 2017. progress), October 2017.
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, <https://www.rfc- DOI 10.17487/RFC3261, June 2002, <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.,
skipping to change at page 59, line 9 skipping to change at page 60, line 19
[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, <https://www.rfc-
editor.org/info/rfc7656>. editor.org/info/rfc7656>.
[I-D.ietf-ice-trickle] [I-D.ietf-ice-trickle]
Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre,
"Trickle ICE: Incremental Provisioning of Candidates for "Trickle ICE: Incremental Provisioning of Candidates for
the Interactive Connectivity Establishment (ICE) the Interactive Connectivity Establishment (ICE)
Protocol", draft-ietf-ice-trickle-13 (work in progress), Protocol", draft-ietf-ice-trickle-15 (work in progress),
July 2017. November 2017.
[I-D.ietf-avtext-lrr] [I-D.ietf-avtext-lrr]
Lennox, J., Hong, D., Uberti, J., Holmer, S., and M. Lennox, J., Hong, D., Uberti, J., Holmer, S., and M.
Flodman, "The Layer Refresh Request (LRR) RTCP Feedback Flodman, "The Layer Refresh Request (LRR) RTCP Feedback
Message", draft-ietf-avtext-lrr-07 (work in progress), Message", draft-ietf-avtext-lrr-07 (work in progress),
July 2017. July 2017.
Appendix A. Design Considerations Appendix A. Design Considerations
One of the main issues regarding the BUNDLE grouping extensions has One of the main issues regarding the BUNDLE grouping extensions has
been whether, in SDP Offers and SDP Answers, the same port value been whether, in SDP Offers and SDP Answers, the same port value
should be inserted in "m=" lines associated with a BUNDLE group, as should be inserted in "m=" lines associated with a BUNDLE group, as
the purpose of the extension is to negotiate the usage of a single the purpose of the extension is to negotiate the usage of a single
address:port combination for media specified by the "m=" lines. transport for media specified by the "m=" sections. Issues with both
Issues with both approaches, discussed in the Appendix have been approaches, discussed in the Appendix have been raised. The outcome
raised. The outcome was to specify a mechanism which uses SDP Offers was to specify a mechanism which uses SDP Offers with both different
with both different and identical port values. and identical port values.
Below are the primary issues that have been considered when defining Below are the primary issues that have been considered when defining
the "BUNDLE" grouping extension: the "BUNDLE" grouping extension:
o 1) Interoperability with existing UAs. o 1) Interoperability with existing UAs.
o 2) Interoperability with intermediary B2BUA- and proxy entities. o 2) Interoperability with intermediary B2BUA- and proxy entities.
o 3) Time to gather, and the number of, ICE candidates. o 3) Time to gather, and the number of, ICE candidates.
skipping to change at page 60, line 36 skipping to change at page 61, line 41
m=video 20002 RTP/AVP 97 m=video 20002 RTP/AVP 97
a=rtpmap:97 H261/90000 a=rtpmap:97 H261/90000
RFC 4961 specifies a way of doing symmetric RTP but that is an a RFC 4961 specifies a way of doing symmetric RTP but that is an a
later invention to RTP and Bob can not assume that Alice supports RFC later invention to RTP and Bob can not assume that Alice supports RFC
4961. This means that Alice may be sending RTP from a different port 4961. This means that Alice may be sending RTP from a different port
than 10000 or 10002 - some implementation simply send the RTP from an than 10000 or 10002 - some implementation simply send the RTP from an
ephemeral port. When Bob's endpoint receives an RTP packet, the only ephemeral port. When Bob's endpoint receives an RTP packet, the only
way that Bob knows if it should be passed to the video or audio codec way that Bob knows if it should be passed to the video or audio codec
is by looking at the port it was received on. This lead some SDP is by looking at the port it was received on. This lead some SDP
implementations to use the fact that each "m=" line had a different implementations to use the fact that each "m=" section had a
port number to use that port number as an index to find the correct m different port number to use that port number as an index to find the
line in the SDP. As a result, some implementations that do support correct m line in the SDP. As a result, some implementations that do
symmetric RTP and ICE still use a SDP data structure where SDP with support symmetric RTP and ICE still use a SDP data structure where
"m=" lines with the same port such as: SDP with "m=" sections with the same port such as:
SDP Offer SDP Offer
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s= s=
c=IN IP4 atlanta.example.com c=IN IP4 atlanta.example.com
t=0 0 t=0 0
m=audio 10000 RTP/AVP 97 m=audio 10000 RTP/AVP 97
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
m=video 10000 RTP/AVP 98 m=video 10000 RTP/AVP 98
a=rtpmap:98 H261/90000 a=rtpmap:98 H261/90000
will result in the second "m=" line being considered an SDP error will result in the second "m=" section being considered an SDP error
because it has the same port as the first line. because it has the same port as the first line.
A.2. Usage of port number value zero A.2. Usage of port number value zero
In an SDP Offer or SDP Answer, the media specified by an "m=" line In an SDP Offer or SDP Answer, the media specified by an "m=" section
can be disabled/rejected by setting the port number value to zero. can be disabled/rejected by setting the port number value to zero.
This is different from e.g., using the SDP direction attributes, This is different from e.g., using the SDP direction attributes,
where RTCP traffic will continue even if the SDP "inactive" attribute where RTCP traffic will continue even if the SDP "inactive" attribute
is indicated for the associated "m=" line. is indicated for the associated "m=" section.
If each "m=" line associated with a BUNDLE group would contain If each "m=" section associated with a BUNDLE group would contain
different port values, and one of those port values would be used for different port values, and one of those port values would be used for
a BUNDLE address associated with the BUNDLE group, problems would a BUNDLE address associated with the BUNDLE group, problems would
occur if an endpoint wants to disable/reject the "m=" line associated occur if an endpoint wants to disable/reject the "m=" sectcion
with that port, by setting the port value to zero. After that, no associated with that port, by setting the port value to zero. After
"m=" line would contain the port value which is used for the BUNDLE that, no "m=" section would contain the port value which is used for
address. In addition, it is unclear what would happen to the ICE the BUNDLE address. In addition, it is unclear what would happen to
candidates associated with the "m=" line, as they are also used for the ICE candidates associated with the "m=" section, as they are also
the BUNDLE address. used for the BUNDLE address.
A.3. B2BUA And Proxy Interoperability A.3. B2BUA And Proxy Interoperability
Some back to back user agents may be configured in a mode where if Some back to back user agents may be configured in a mode where if
the incoming call leg contains an SDP attribute the B2BUA does not the incoming call leg contains an SDP attribute the B2BUA does not
understand, the B2BUA still generates that SDP attribute in the Offer understand, the B2BUA still generates that SDP attribute in the Offer
for the outgoing call leg. Consider a B2BUA that did not understand for the outgoing call leg. Consider a B2BUA that did not understand
the SDP "rtcp" attribute, defined in RFC 3605, yet acted this way. the SDP "rtcp" attribute, defined in RFC 3605, yet acted this way.
Further assume that the B2BUA was configured to tear down any call Further assume that the B2BUA was configured to tear down any call
where it did not see any RTCP for 5 minutes. In this case, if the where it did not see any RTCP for 5 minutes. In this case, if the
skipping to change at page 62, line 40 skipping to change at page 63, line 40
be terminated in case media is not sent or received on the ports be terminated in case media is not sent or received on the ports
retrieved from the SDP. This typically occurs once the session is retrieved from the SDP. This typically occurs once the session is
already established and ongoing. already established and ongoing.
A.3.2. Bandwidth Allocation A.3.2. Bandwidth Allocation
Sometimes intermediaries do not act as B2BUA, in the sense that they Sometimes intermediaries do not act as B2BUA, in the sense that they
don't modify SDP bodies, nor do they terminate SIP dialogs. Still, don't modify SDP bodies, nor do they terminate SIP dialogs. Still,
however, they may use SDP information (e.g., codecs and media types) however, they may use SDP information (e.g., codecs and media types)
in order to control bandwidth allocation functions. The bandwidth in order to control bandwidth allocation functions. The bandwidth
allocation is done per "m=" line, which means that it might not be allocation is done per "m=" section, which means that it might not be
enough if media specified by all "m=" lines try to use that enough if media specified by all "m=" sections try to use that
bandwidth. That may either simply lead to bad user experience, or to bandwidth. That may either simply lead to bad user experience, or to
termination of the call. termination of the call.
A.4. Candidate Gathering A.4. Candidate Gathering
When using ICE, a candidate needs to be gathered for each port. This When using ICE, a candidate needs to be gathered for each port. This
takes approximately 20 ms extra for each extra "m=" line due to the takes approximately 20 ms extra for each extra "m=" section due to
NAT pacing requirements. All of this gather can be overlapped with the NAT pacing requirements. All of this gather can be overlapped
other things while for exampe a web-page is loading to minimize the with other things while for exampe a web-page is loading to minimize
impact. If the client only wants to generate TURN or STUN ICE the impact. If the client only wants to generate TURN or STUN ICE
candidates for one of the "m=" lines and then use trickle ICE candidates for one of the "m=" lines and then use trickle ICE
[I-D.ietf-ice-trickle] to get the non host ICE candidates for the [I-D.ietf-ice-trickle] to get the non host ICE candidates for the
rest of the "m=" lines, it MAY do that and will not need any rest of the "m=" sections, it MAY do that and will not need any
additional gathering time. additional gathering time.
Some people have suggested a TURN extension to get a bunch of TURN Some people have suggested a TURN extension to get a bunch of TURN
allocations at once. This would only provide a single STUN result so allocations at once. This would only provide a single STUN result so
in cases where the other end did not support BUNDLE, may cause more in cases where the other end did not support BUNDLE, may cause more
use of the TURN server but would be quick in the cases where both use of the TURN server but would be quick in the cases where both
sides supported BUNDLE and would fall back to a successful call in sides supported BUNDLE and would fall back to a successful call in
the other cases. the other cases.
Authors' Addresses Authors' Addresses
 End of changes. 237 change blocks. 
615 lines changed or deleted 671 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/