draft-ietf-mmusic-sdp-bundle-negotiation-08.txt   draft-ietf-mmusic-sdp-bundle-negotiation-09.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: February 23, 2015 C. Jennings Expires: March 9, 2015 C. Jennings
Cisco Cisco
August 22, 2014 September 5, 2014
Negotiating Media Multiplexing Using the Session Description Protocol Negotiating Media Multiplexing Using the Session Description Protocol
(SDP) (SDP)
draft-ietf-mmusic-sdp-bundle-negotiation-08.txt draft-ietf-mmusic-sdp-bundle-negotiation-09.txt
Abstract Abstract
This specification defines a new SDP Grouping Framework extension, This specification defines a new SDP Grouping Framework extension,
"BUNDLE", that can be used with the Session Description Protocol 'BUNDLE'. The BUNDLE extension can be used with the Session
(SDP) Offer/Answer mechanism to negotiate the usage of bundled media, Description Protocol (SDP) Offer/Answer mechanism to negotiate the
which refers to the usage of a single 5-tuple for sending and usage of a single 5-tuple for sending and receiving media, referred
receiving media associated with multiple SDP media descriptions ("m=" to as bundled media, associated with multiple SDP media descriptions
lines). ("m=" lines). This specification also defines a new SDP attribute,
'bundle-only', which can be used to request that specific media is
only used if bundled.
This specification also updates sections 5.1, 8.1 and 8.2 of RFC This specification also updates sections 5.1, 8.1 and 8.2 of RFC
3264, in order to allow an answerer to in an SDP answer assign a non- 3264. The update allows an answerer to assign a non-zero port value
zero port value to an "m=" line, even if the offerer in the to an "m=" line in an answer, even if the "m=" line in the associated
associated SDP offer had assigned a zero port value to the "m=" line. offer contained a zero port value.
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 February 23, 2015. This Internet-Draft will expire on March 9, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 26 skipping to change at page 2, line 26
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 6
5. SDP Grouping Framework BUNDLE Extension Semantics . . . . . . 6 5. SDP Grouping Framework BUNDLE Extension . . . . . . . . . . . 6
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . 6 6. SDP 'bundle-only' Attribute . . . . . . . . . . . . . . . . . 7
5.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2.2. SDP Information Considerations . . . . . . . . . . . 7 6.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2.3. Generating the Initial SDP Offer . . . . . . . . . . 8 7. SDP Information Considerations . . . . . . . . . . . . . . . 8
5.2.4. Generating the SDP Answer . . . . . . . . . . . . . . 8 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2.5. Offerer Processing of the SDP Answer . . . . . . . . 10 7.2. Connection Data (c=) . . . . . . . . . . . . . . . . . . 8
5.2.6. Modifying the Session . . . . . . . . . . . . . . . . 11 7.3. Bandwidth (b=) . . . . . . . . . . . . . . . . . . . . . 8
6. SDP 'bundle-only' Attribute . . . . . . . . . . . . . . . . . 13 7.4. Attributes (a=) . . . . . . . . . . . . . . . . . . . . . 8
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 8
6.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . 13 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.2.1. Generating the Initial SDP Offer . . . . . . . . . . 13 8.2. Generating the Initial SDP Offer . . . . . . . . . . . . 9
6.2.2. Generating the SDP Answer . . . . . . . . . . . . . . 13 8.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 9
6.2.3. Offerer Processing of the SDP Answer . . . . . . . . 14 8.2.2. Request offerer BUNDLE address selection . . . . . . 10
6.2.4. Modifying the Session . . . . . . . . . . . . . . . . 14 8.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 10
7. Protocol Identification . . . . . . . . . . . . . . . . . . . 15 8.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.3.2. Answerer Selection of Offerer Bundle Address . . . . 11
7.2. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 15 8.3.3. Answerer Selection of Answerer BUNDLE Address . . . . 12
8. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 15 8.3.4. Moving A Media Description Out Of A BUNDLE Group . . 12
8.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 15 8.3.5. Rejecting A Media Description In A BUNDLE Group . . . 12
8.1.1. General . . . . . . . . . . . . . . . . . . . . . . . 16 8.4. Offerer Processing of the SDP Answer . . . . . . . . . . 13
8.1.2. Payload Type (PT) Value Re-usage . . . . . . . . . . 16 8.4.1. General . . . . . . . . . . . . . . . . . . . . . . . 13
8.2. Associating RTP/RTCP Packets With Correct SDP Media 8.4.2. Bundle Address Synchronization (BAS) . . . . . . . . 13
Description . . . . . . . . . . . . . . . . . . . . . . . 16 8.5. Modifying the Session . . . . . . . . . . . . . . . . . . 14
8.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . . 17 8.5.1. General . . . . . . . . . . . . . . . . . . . . . . . 14
8.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 17 8.5.2. Request new offerer BUNDLE address . . . . . . . . . 15
8.3.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . 18 8.5.3. Adding a media description to a BUNDLE group . . . . 15
9. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 19 8.5.4. Moving A Media Description Out Of A BUNDLE Group . . 16
9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.5.5. Disabling A Media Description In A BUNDLE Group . . . 16
9.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . 20 9. Protocol Identification . . . . . . . . . . . . . . . . . . . 16
9.2.1. Generating the Initial SDP Offer . . . . . . . . . . 20 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.2.2. Generating the SDP Answer . . . . . . . . . . . . . . 20 9.2. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 17
9.2.3. Offerer Processing of the SDP Answer . . . . . . . . 20 10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 17
9.2.4. Modifying the Session . . . . . . . . . . . . . . . . 20 10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 17
9.2.5. Keep-alives . . . . . . . . . . . . . . . . . . . . . 20 10.1.1. General . . . . . . . . . . . . . . . . . . . . . . 17
10. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 20 10.1.2. Payload Type (PT) Value Re-usage . . . . . . . . . . 18
10.1. General . . . . . . . . . . . . . . . . . . . . . . . . 20 10.2. Associating RTP/RTCP Packets With Correct SDP Media
10.2. Original text of section 5.1 (2nd paragraph) of RFC 3264 21 Description . . . . . . . . . . . . . . . . . . . . . . 18
10.3. New text replacing section 5.1 (2nd paragraph) of RFC 10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 19
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 21 10.3.1. General . . . . . . . . . . . . . . . . . . . . . . 19
10.4. Original text of section 8.2 (2nd paragraph) of RFC 3264 21 10.3.2. SDP Offer/Answer Procedures . . . . . . . . . . . . 19
10.5. New text replacing section 8.2 (2nd paragraph) of RFC 11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 21
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 22 11.1. General . . . . . . . . . . . . . . . . . . . . . . . . 21
10.6. Original text of section 8.4 (6th paragraph) of RFC 3264 22 11.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 21
10.7. New text replacing section 8.4 (6th paragraph) of RFC 11.2.1. General . . . . . . . . . . . . . . . . . . . . . . 21
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 22 11.2.2. Generating the Initial SDP Offer . . . . . . . . . . 22
11. RTP/RTCP extensions for mid value transport . . . . . . . . . 22 11.2.3. Generating the SDP Answer . . . . . . . . . . . . . 22
11.1. General . . . . . . . . . . . . . . . . . . . . . . . . 22 11.2.4. Offerer Processing of the SDP Answer . . . . . . . . 22
11.2. RTP MID SDES Item . . . . . . . . . . . . . . . . . . . 23 11.2.5. Modifying the Session . . . . . . . . . . . . . . . 22
11.3. RTP MID Header Extension . . . . . . . . . . . . . . . . 24 12. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 22
11.4. IANA Considerations . . . . . . . . . . . . . . . . . . 24 12.1. General . . . . . . . . . . . . . . . . . . . . . . . . 22
12. Security Considerations . . . . . . . . . . . . . . . . . . . 24 12.2. Original text of section 5.1 (2nd paragraph) of RFC 3264 22
13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 25 12.3. New text replacing section 5.1 (2nd paragraph) of RFC
13.1. Example: Bundle Address Selection . . . . . . . . . . . 25 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 23
13.2. Example: Bundle Mechanism Rejected . . . . . . . . . . . 26 12.4. Original text of section 8.2 (2nd paragraph) of RFC 3264 23
13.3. Example: Offerer Adds A Media Description To A BUNDLE 12.5. New text replacing section 8.2 (2nd paragraph) of RFC
Group . . . . . . . . . . . . . . . . . . . . . . . . . 27 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 23
13.4. Example: Offerer Moves A Media Description Out Of A 12.6. Original text of section 8.4 (6th paragraph) of RFC 3264 23
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 29 12.7. New text replacing section 8.4 (6th paragraph) of RFC
13.5. Example: Offerer Disables A Media Description Within A 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 24
13. RTP/RTCP extensions for mid value transport . . . . . . . . . 24
13.1. General . . . . . . . . . . . . . . . . . . . . . . . . 24
13.2. RTP MID SDES Item . . . . . . . . . . . . . . . . . . . 25
13.3. RTP MID Header Extension . . . . . . . . . . . . . . . . 25
13.4. IANA Considerations . . . . . . . . . . . . . . . . . . 25
14. Security Considerations . . . . . . . . . . . . . . . . . . . 26
15. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 26
15.1. Example: Bundle Address Selection . . . . . . . . . . . 26
15.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 28
15.3. Example: Offerer Adds A Media Description To A BUNDLE
Group . . . . . . . . . . . . . . . . . . . . . . . . . 29
15.4. Example: Offerer Moves A Media Description Out Of A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 31 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 31
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 15.5. Example: Offerer Disables A Media Description Within A
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 33
16. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 33 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35
17.1. Normative References . . . . . . . . . . . . . . . . . . 35 18. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 35
17.2. Informative References . . . . . . . . . . . . . . . . . 36 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
Appendix A. Design Considerations . . . . . . . . . . . . . . . 36 19.1. Normative References . . . . . . . . . . . . . . . . . . 38
A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 37 19.2. Informative References . . . . . . . . . . . . . . . . . 38
A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 37 Appendix A. Design Considerations . . . . . . . . . . . . . . . 39
A.3. Usage of port number value zero . . . . . . . . . . . . . 39 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 39
A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 39 A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 40
A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 40 A.3. Usage of port number value zero . . . . . . . . . . . . . 41
A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 40 A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 41
A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 42
A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 40 A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
In the IETF RTCWEB WG, a need to use a single 5-tuple for sending and In the IETF RTCWEB WG, a need to use a single 5-tuple for sending and
receiving media associated with multiple SDP media descriptions ("m=" receiving media associated with multiple SDP media descriptions ("m="
lines) has been identified. This would e.g. allow the usage of a lines) has been identified. This would e.g. allow the usage of a
single set of Interactive Connectivity Establishment (ICE) [RFC5245] single set of Interactive Connectivity Establishment (ICE) [RFC5245]
candidates for multiple media descriptions. Normally different media candidates for multiple media descriptions.
types (audio, video etc) will be described using different media
descriptions.
This specification defines a new SDP Grouping Framework [RFC5888] This specification defines a new SDP Grouping Framework [RFC5888]
extension, "BUNDLE", that can be used with the Session Description extension, 'BUNDLE'. The BUNDLE extension can be used with the
Protocol (SDP) Offer/Answer mechanism [RFC3264] to negotiate the Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264]
usage of bundled media, which refers to the usage of a single 5-tuple to negotiate the usage of a single 5-tuple for sending and receiving
for sending and receiving media associated with multiple SDP media media, referred to as bundled media, associated with multiple SDP
descriptions ("m=" lines). media descriptions ("m="). This specification also defines a new SDP
attribute, 'bundle-only', which can be used to request that specific
media is only used if bundled.
The offerer and answerer [RFC3264] use the BUNDLE mechanism to The offerer and answerer [RFC3264] use the BUNDLE extension to
negotiate BUNDLE addresses, one for the offerer (offerer BUNDLE negotiate the 5-tuples (BUNDLE addresses), one for the offerer
address) and one for the answerer (answerer BUNDLE address) to be (offerer BUNDLE address) and one for the answerer (answerer BUNDLE
used for the bundled media associated with a BUNDLE group. address) to be used for the bundled media associated with a BUNDLE
group.
Once the offerer and the answerer have negotiated a BUNDLE group, and Once the offerer and the answerer have negotiated a BUNDLE group, and
the associated BUNDLE addresses, each endpoint can assign its BUNDLE the associated BUNDLE addresses, each endpoint can assign its BUNDLE
address to each "m=" line within, and use the address to send and address to each "m=" line within, and use the address to send and
receive all media associated with, the BUNDLE group. receive all media associated with, the BUNDLE group.
NOTE: As defined in RFC 4566 [RFC4566], the semantics of assigning NOTE: As defined in RFC 4566 [RFC4566], the semantics of assigning
the same port value to multiple "m=" lines are undefined, and there the same port value to multiple "m=" lines are undefined, and there
is no grouping defined by such means. Instead, an explicit grouping is no grouping defined by such means. Instead, an explicit grouping
mechanism needs to be used to express the intended semantics. This mechanism needs to be used to express the intended semantics. This
specification provides such an extension. specification provides such an extension.
SDP bodies can contain multiple BUNDLE groups. Each BUNDLE group This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264
MUST use a unique 5-tuple. Any given "m=" line can only be [RFC3264]. The update allows an answerer to assign a non-zero port
associated with a single BUNDLE group. value to an "m=" line in an answer, even if the "m=" line in the
associated offer contained a zero port value.
SDP bodies can contain multiple BUNDLE groups. A given BUNDLE
address MUST only be associated with a single BUNDLE group.
The procedures in this specification apply independently to a given The procedures in this specification apply independently to a given
BUNDLE group. BUNDLE group.
All Real-time Transport Protocol (RTP) [RFC3550] based media flows All Real-time Transport Protocol (RTP) [RFC3550] based media flows
associated with a single BUNDLE group belong to a single RTP session associated with a single BUNDLE group belong to a single RTP session
[RFC3550]. [RFC3550].
The BUNDLE mechanism is backward compatible. Endpoints that do not The BUNDLE extension is backward compatible. Endpoints that do not
support the BUNDLE mechanism are expected to generate SDP offers and support the extension are expected to generate offers and answers
SDP answers without an SDP 'group:BUNDLE' attribute, and are expected without an SDP 'group:BUNDLE' attribute, and are expected to assign a
to assign a unique address to each "m=" line within an SDP offer and unique address to each "m=" line within an offer and answer,
SDP answer, according to the procedures in [RFC4566] and [RFC3264] according to the procedures in [RFC4566] and [RFC3264]
This specification also updates sections 5.1, 8.1 and 8.2 of
[RFC3264], in order to allow an answerer to assign a non-zero port
value to an "m=" line in an SDP answer, even if the offerer in the
associated SDP offer had assigned a zero port value to the "m=" line.
2. Terminology 2. Terminology
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 protocol. port, destination address, destination port and protocol.
Unique address: An IP address and IP port combination that is Unique address: An IP address and IP port combination that is
assigned to a single "m=" line in an SDP offer or SDP answer. assigned to only one "m=" line in an offer or answer.
Shared address: An IP address and IP port combination that is Shared address: An IP address and IP port combination that is
assigned to multiple "m=" lines in an SDP offer or SDP answer. assigned to multiple "m=" lines within an offer or answer.
Offerer suggested BUNDLE mid: The first mid value in a given SDP Offerer suggested BUNDLE mid: The first mid value in a given SDP
'group:BUNDLE' attribute mid list in an SDP offer. 'group:BUNDLE' attribute mid list in an offer.
Answerer selected BUNDLE mid: The first mid value in a given SDP Answerer selected BUNDLE mid: The first mid value in a given SDP
'group:BUNDLE' attribute mid list in an SDP answer. 'group:BUNDLE' attribute mid list in an answer.
Offerer BUNDLE address: Within a given BUNDLE group, an IP address Offerer BUNDLE address: Within a given BUNDLE group, an IP address
and IP port combination used by an offerer to receive all media and IP port combination used by an offerer to receive all media
associated with each "m=" line within the BUNDLE group. associated with each "m=" line within the BUNDLE group.
Answerer BUNDLE address: Within a given BUNDLE group, an IP address Answerer BUNDLE address: Within a given BUNDLE group, an IP address
and IP port combination used by an answerer to receive all media and IP port combination used by an answerer to receive all media
associated with each "m=" line within the BUNDLE group. associated with each "m=" line within the BUNDLE group.
BUNDLE group: A set of "m=" lines, created using an SDP offer/answer BUNDLE group: A set of "m=" lines, created using an SDP Offer/Answer
exchange, for which a single 5-tuple is used to send and receive exchange, for which each endpoint use a single 5-tuple is to send and
media. Each endpoint uses its BUNDLE address, associated with the receive media. Each endpoint uses its BUNDLE address, associated
BUNDLE group, to send and receive the media. with the BUNDLE group, to send and receive the media.
Bundled "m=" line: An "m=" line, in an SDP offer or SDP answer, Bundled "m=" line: An "m=" line, which SDP 'mid' attribute value is
associated with a BUNDLE group. placed in a SDP 'group:BUNDLE' attribute mid value list in an offer
or answer.
Bundle-only "m=" line: An "m=" line, to which an SDP 'bundle-only' Bundle-only "m=" line: A bundled "m=" line, to which an SDP 'bundle-
attribute has been assigned. only' attribute has been assigned.
Bundled media: All media associated with a BUNDLE group. Bundled media: All media associated with a given BUNDLE group.
Initial SDP offer: The first SDP offer, within an SDP session, in Initial offer: The first offer, within an SDP session, in which the
which the offerer indicates that it wants to create a given BUNDLE offerer indicates that it wants to create a given BUNDLE group.
group.
Subsequent SDP offer: An SDP offer which contains a BUNDLE group that Subsequent offer: An offer which contains a BUNDLE group that has
has been created as part of a previous SDP offer/answer exchange. been created as part of a previous SDP Offer/Answer exchange.
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]. Offer/Answer mechanism [RFC3264].
5. SDP Grouping Framework BUNDLE Extension Semantics 5. SDP Grouping Framework BUNDLE Extension
5.1. General 5.1. General
This section defines a new SDP Grouping Framework extension, BUNDLE. This section defines a new SDP Grouping Framework extension
[RFC5888], 'BUNDLE'. The BUNDLE extension can be used with the
Session Description Protocol (SDP) Offer/Answer mechanism to
negotiate the usage of a single 5-tuple for sending and receiving
media, referred to as bundled media, associated with multiple SDP
media descriptions ("m=" lines). Within a successfully created
BUNDLE group, media described with "m=" lines associated with the
BUNDLE group will be sent and received using a single 5-tuple.
The BUNDLE extension can be indicated using an SDP session-level The BUNDLE extension is indicated using an SDP 'group' attribute with
'group' attribute. Each SDP Media Description ("m=" line) that is a "BUNDLE" semantics value [RFC5888]. An SDP "mid" attribute is
grouped together, using SDP media-level mid attributes, belongs to a assigned to each bundled "m=" line, and the "mid" attribute value is
given BUNDLE group. listed in the 'group:BUNDLE' attribute mid value list. Each "m="
line, which mid value is listed in the mid value list, is associated
with a given BUNDLE group.
5.2. SDP Offer/Answer Procedures Any given "m=" line MUST NOT be associated with more than one BUNDLE
group.
5.2.1. General Section 8 defines the detailed SDP Offer/Answer procedures for the
BUNDLE extension.
This section describes usage of the SDP offer/answer mechanism 6. SDP 'bundle-only' Attribute
[RFC3264] for negotiating usage of the BUNDLE mechanism, for creating
a BUNDLE group, for selecting the BUNDLE addresses (offerer BUNDLE
address and answerer BUNDLE address), for adding an "m=" line to a
BUNDLE group, for moving an "m=" line out of a BUNDLE group, and for
disabling an "m=" line within a BUNDLE group.
The generic rules and procedures defined in [RFC3264] and [RFC5888] 6.1. General
also apply to the BUNDLE mechanism. For example, if an SDP offer is
rejected by the answerer, the previously negotiated SDP parameters
and characteristics (including those associated with a BUNDLE group)
apply. Hence, if an offerer generates an SDP offer in which the
offerer wants to create a BUNDLE group, and the answerer rejects the
SDP offer, the BUNDLE group is not created.
The procedures in this section are independent of the media type or This section defines a new SDP media-level attribute [RFC4566],
transport protocol represented by a bundled "m=" line. [Section 8] 'bundle-only'.
defines additional considerations for RTP based media. [Section 6]
defines additional considerations for the usage of the SDP 'bundle-
only' attribute. [Section 9] defines additional considerations for
the usage of Interactive Connectivity Establishment (ICE) mechanism
[RFC5245].
5.2.2. SDP Information Considerations The 'bundle-only' attribute can be assigned to a bundled "m=" line in
an offer, to request that the answerer only accepts the "m=" line if
the answerer keeps the "m=" line within the associated BUNDLE group.
5.2.2.1. General In order to ensure that an answerer that does not supports the BUNDLE
extension always rejects a 'bundle-only' "m=" line, the offerer can
assign a zero port value to the "m=" line to which the 'bundle-only'
attribute has been assigned. According to [RFC4566] an answerer will
reject such "m=" line.
The usage of the 'bundle-only' attribute is only defined for a
bundled "m=" line within an offer. Other usage is unspecified.
Section 8 defines the detailed SDP Offer/Answer procedures for the
'bundle-only' attribute.
6.2. Syntax
This section defines the Augmented Backus-Naur Form (ABNF) [RFC5234]
for the SDP 'bundle-only' attribute, based on the SDP [RFC4566]
grammar.
attribute =/ bundle-only-attribute
bundle-only-attribute = "bundle-only"
7. SDP Information Considerations
7.1. General
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 assigned to each bundled "m=" line, and attribute values have been assigned to each bundled "m=" line,
how to calculate a value for the whole BUNDLE group. how to calculate a value for the whole BUNDLE group.
5.2.2.2. Connection Data (c=) 7.2. Connection Data (c=)
The "c=" line nettype value [RFC4566] assigned to a bundled "m=" line The "c=" line nettype value [RFC4566] assigned to a bundled "m=" line
MUST be 'IN'. MUST be 'IN'.
The "c=" line addrtype value [RFC4566] assigned to a bundled "m=" The "c=" line addrtype value [RFC4566] assigned to a bundled "m="
line MUST be 'IP4' or 'IP6'. The same value MUST be assigned to each line MUST be 'IP4' or 'IP6'. The same value MUST be assigned to each
"m=" line. "m=" line.
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.
5.2.2.3. Bandwidth (b=) 7.3. Bandwidth (b=)
The total proposed bandwidth is the sum of the proposed bandwidth for The proposed bandwidth for a bundled "m=" line SHOULD be calculated
each bundled "m=" line. in the same way as for a non-bundled "m=" line.
5.2.2.4. Attributes (a=) The total proposed bandwidth for a BUNDLE group is the sum of the
proposed bandwidth for each bundled "m=" line.
[I-D.nandakumar-mmusic-sdp-mux-attributes] defines rules and The total proposed bandwidth for an offer or answer is the sum of the
restrictions for assigning different types of SDP attributes to a proposed bandwidth for each "m=" line (bundled and non-bundled)
bundled "m=" line. within the offer or answer.
5.2.3. Generating the Initial SDP Offer 7.4. Attributes (a=)
5.2.3.1. General [I-D.mmusic-sdp-mux-attributes] defines rules and restrictions for
assigning different types of SDP attributes to a bundled "m=" line.
When an offerer generates an initial SDP offer, in order to create a 8. SDP Offer/Answer Procedures
BUNDLE group, the offerer MUST in the SDP offer assign a unique
address to each "m=" line with a non-zero port value, following the
procedures in [RFC3264].
The offerer MUST in the SDP offer insert an SDP session level 8.1. General
'group:BUNDLE' attribute, associated with the BUNDLE group, and
assign an SDP 'mid' attribute [RFC5888] to each "m=" line that the
offerer wants to be within the BUNDLE group, and place the 'mid'
attribute value in the 'group:BUNDLE' attribute mid list.
[Section 13.1] shows an example of an initial SDP offer. This section describes the SDP Offer/Answer [RFC3264] procedures for:
5.2.3.2. Request offerer BUNDLE address selection o Negotiating and creating of a BUNDLE group;
o Selecting the BUNDLE addresses (offerer BUNDLE address and
answerer BUNDLE address);
When an offerer generates an initial SDP offer, in order to create a o Adding an "m=" line to a BUNDLE group;
BUNDLE group, the offerer MUST in the SDP offer indicate which unique
address, associated with one of the "m=" lines that the offerer wants
to be within the BUNDLE group, that the offerer wants the answerer to
select as the offerer BUNDLE address [Section 5.2.4.2]. In the SDP
offer, the offerer BUNDLE mid value represents that address.
5.2.4. Generating the SDP Answer o Moving an "m=" line out of a BUNDLE group; and
5.2.4.1. RFC 5888 restrictions o Disabling an "m=" line within a BUNDLE group.
When an answerer generates an SDP answer, the following restrictions, The generic rules and procedures defined in [RFC3264] and [RFC5888]
defined in [RFC5888], also apply a BUNDLE group: also apply to the BUNDLE extension. For example, if an offer is
rejected by the answerer, the previously negotiated SDP parameters
and characteristics (including those associated with a BUNDLE group)
apply. Hence, if an offerer generates an offer in which the offerer
wants to create a BUNDLE group, and the answerer rejects the offer,
the BUNDLE group is not created.
o 1) The answerer MUST NOT in the SDP answer include a BUNDLE group, The procedures in this section are independent of the media type or
unless the offerer in the associated SDP offer requested the transport protocol represented by a bundled "m=" line. [Section 10]
BUNDLE group to be created; and defines additional considerations for RTP based media. [Section 6]
defines additional considerations for the usage of the SDP 'bundle-
only' attribute. [Section 11] defines additional considerations for
the usage of Interactive Connectivity Establishment (ICE) mechanism
[RFC5245].
o 2) The answerer MUST NOT in the SDP answer include an "m=" line The offerer and answerer MUST follow the rules and restrictions
within a BUNDLE group, unless the offerer in the associated SDP defined in Section 7 when creating offers and answers.
offer requested the "m=" line to be within the BUNDLE group.
5.2.4.2. Answerer Selection of Offerer Bundle Address 8.2. Generating the Initial SDP Offer
When an answerer generates an SDP answer, it MUST select a BUNDLE 8.2.1. General
address for the offerer, referred to as the offerer BUNDLE address.
The answerer MUST select an address which the offerer in the
associated SDP offer requested to be within the BUNDLE group.
In the SDP offer, the offerer suggested BUNDLE mid represents the When an offerer generates an initial offer, in order to create a
"m=" line to which the offerer in the SDP offer has assigned the BUNDLE group, it MUST:
address that it wants the answerer to select as the offerer BUNDLE
address [Section 5.2.3.2]. The answerer MUST first select the "m="
line associated with the offerer suggested BUNDLE mid, and check
whether it fulfils the following criteria:
o The answerer will in the SDP answer create the BUNDLE group; o Assign a unique address to each "m=" line within the offer,
following the procedures in [RFC3264];
o The answerer will not in the SDP answer move the "m=" line out of o Assign an SDP 'group:BUNDLE' attribute to the offer;
the BUNDLE group [Section 5.2.4.4];
o The answerer will not in the SDP answer reject the "m=" line o Place the SDP 'mid' attribute value [RFC5888] of each bundled "m="
[Section 5.2.4.5]; and line to the SDP 'group:BUNDLE' attribute mid value list; and
o The offerer did not in the associated SDP offer assign a zero port o Indicate which unique address the offerer wants the answerer to
value to the "m=" line. select as the offerer BUNDLE address Section 8.2.2.
If the offerer wants to request that the answerer accepts a given
"m=" line only if the the answerer keeps the "m=" line within the
BUNDLE group, the offerer MUST:
o Assign an SDP 'bundle-only' attribute Section 8.2.2 to the "m="
line; and
o Assign a zero port value to the "m=" line.
NOTE: If the offerer assigns a zero port value to an "m=" line, but
does not also assign an SDP 'bundle-only' attribute to the "m=" line,
it is an indication that the offerer wants to disable the "m=" line
[Section 8.5.5].
[Section 15.1] shows an example of an initial offer.
8.2.2. Request offerer BUNDLE address selection
In the offer, the address assigned to the "m=" line associated with
the offerer suggested BUNDLE mid indicates the address that the
offerer wants the answer to select as the offerer BUNDLE address
[Section 8.3.2].
8.3. Generating the SDP Answer
8.3.1. General
When an answerer generates an answer, which contains a BUNDLE group,
the following general SDP grouping framework restrictions, defined in
[RFC5888], also apply to the BUNDLE group:
o The answerer MUST NOT include a BUNDLE group in the answer, unless
the offerer requested the BUNDLE group to be created in the
associated offer; and
o The answerer MUST NOT include an "m=" line within a BUNDLE group,
unless the offerer requested to "m=" line to be within a BUNDLE
group in the associated offer.
If the answer contains a BUNDLE group, the answerer MUST:
o Select an Offerer BUNDLE Address Section 8.3.2; and
o Select an Answerer BUNDLE Address Section 8.3.3;
The answerer is allowed to select a new Answerer BUNDLE address each
time it generates an answer to an offer.
If the answerer does not want to keep an "m=" line within a BUNDLE
group, it MUST:
o Move the "m=" line out of the BUNDLE group Section 8.3.4; or
o Reject the "m=" line Section 8.3.5;
If a bundled "m=" line in an offer contains an SDP 'bundle-only'
attribute, and if the answerer keeps the "m=" line within the BUNDLE
group, the answerer MUST process the "m=" line as any other bundled
"m=" line in the offer. The answerer MUST NOT assign a 'bundle-only'
attribute to any "m=" line in an answer (not even if the "m=" line in
the associated offer contains a 'bundle-only' attribute).
NOTE: If a bundled "m=" line in an offer contains a port zero value,
but the "m=" line does not contain an SDP 'bundle-only' attribute, it
is an indication that the offerer wants to disable the "m=" line
[Section 8.5.5].
8.3.2. Answerer Selection of Offerer Bundle Address
In an offer, the address (unique or shared) assigned to the bundled
"m=" line associated with the offerer suggested BUNDLE mid indicates
the address that the offerer wants the answer to select as the
offerer BUNDLE address [Section 8.2.2]. The answerer MUST check
whether the "m=" line fulfills the following criteria:
o The answerer will not move the "m=" line out of the BUNDLE group
[Section 8.3.4];
o The answerer will not reject the "m=" line [Section 8.3.5]; and
o The "m=" line does not contain a zero port value.
If all of the criteria above is fulfilled, the answerer MUST select If all of the criteria above is fulfilled, the answerer MUST select
the address associated with the "m=" line as the offerer BUNDLE the address associated with the "m=" line as the offerer BUNDLE
address. address. In the answer, the answerer selected BUNDLE mid represents
the "m=" line, and the address associated with the "m=" line in the
offer becomes the offerer BUNDLE address.
If all of the criteria is not fulfilled, the answerer MUST select the If all of the criteria is not fulfilled, the answerer MUST select the
next mid value in the mid list, and perform the same criteria check next mid value in the mid list, and perform the same criteria check
for the "m=" line associated with the mid value. for the "m=" line associated with that mid value. If there are no
more mid values in the mid list, the answerer MUST NOT create the
In the SDP answer, the answerer selected BUNDLE mid value represents BUNDLE group.
the "m=" line which address (in the associated SDP offer) the
answerer has selected as the offerer BUNDLE address.
[Section 13.1] shows an example of an offerer BUNDLE address [Section 15.1] shows an example of an offerer BUNDLE address
selection. selection.
5.2.4.3. Answerer Selection of Answerer BUNDLE Address 8.3.3. Answerer Selection of Answerer BUNDLE Address
When an answerer generates an SDP answer, the answerer MUST select a
BUNDLE address for itself, referred to as the answerer BUNDLE
address, and in the SDP answer assign the answerer BUNDLE address to
each "m=" line within the created BUNDLE group.
The answerer MUST NOT in the SDP answer assign the answerer BUNDLE When the answerer selects a BUNDLE address for itself, referred to as
address to an "m=" line that is not associated with the BUNDLE group, the answerer BUNDLE address, it MUST assign the address to each
or to an "m=" line that is associated with another BUNDLE group. bundled "m=" line within the created BUNDLE group in the answer.
The answerer is allowed to select a new answerer BUNDLE address in The answerer MUST NOT assign the answerer BUNDLE address to an "m="
every SDP answer that the answerer generates. line that is not within the BUNDLE group, or to an "m=" line that is
within another BUNDLE group.
[Section 13.1] shows an example of an answerer BUNDLE address [Section 15.1] shows an example of an answerer BUNDLE address
selection. selection.
5.2.4.4. Moving A Media Description Out Of A BUNDLE Group 8.3.4. Moving A Media Description Out Of A BUNDLE Group
When an answerer generates an SDP answer, in which the answerer moves When an answerer moves a "m=" line out of a BUNDLE group, it assigns
a bundled "m=" line out a BUNDLE group, the answerer assigns an an address to the "m=" line in the answer based on the following
address to the moved "m=" line based on the type of address that the rules:
offerer in the associated SDP offer assigned to the "m=" line.
o If the offerer in the SDP offer has assigned a shared address o In the associated offer, if the "m=" line contains a shared
(e.g. a previously selected offerer BUNDLE address) to the "m=" address (e.g. a previously selected offerer BUNDLE address), the
line, the answerer MUST in the SDP answer reject the moved "m=" answerer MUST reject the moved "m=" line [Section 8.3.5];
line, according to the procedures in [Section 5.2.4.5].
o If the offerer in the SDP offer assigned an SDP 'bundle-only' o In the associated offer, if the "m=" line contains a unique
attribute to the "m=" line, the answerer MUST in the SDP answer address, the answerer MUST assign a unique address to the "m="
reject the moved "m=" line, according to the procedures in line in the answer; or
[Section 5.2.4.5].
o If the offerer in the SDP offer assigned a unique address to the o In the associated offer, if the "m=" line contains an SDP 'bundle-
"m=" line, the answerer MUST in the SDP answer assign a unique only' attribute the answerer MUST reject the "m=" line
address to the moved "m=" line. [Section 8.3.5].
In addition, in either case above, the answerer MUST NOT in the SDP In addition, in either case above, the answerer MUST NOT include a
answer include a mid value, associated with the moved "m=" line, in mid value, associated with the moved "m=" line, in the SDP
the SDP 'group:BUNDLE' attribute mid list associated with the BUNDLE 'group:BUNDLE' attribute mid list associated with the BUNDLE group.
group.
5.2.4.5. Rejecting A Media Description In A BUNDLE Group 8.3.5. Rejecting A Media Description In A BUNDLE Group
When an answerer generates an SDP answer, in which the answerer When an answerer rejects an "m=" line, it MUST assign an address with
rejects an "m=" line, the answerer MUST in the SDP answer assign an a zero port value to the "m=" line in the answer, according to the
address with a zero port value to the rejected "m=" line, according procedures in [RFC4566].
to the procedures in [RFC4566].
In addition, the answerer MUST NOT in the SDP answer include a mid In addition, the answerer MUST NOT include a mid value, associated
value, associated with the rejected "m=" line, in the SDP with the rejected "m=" line, in the SDP 'group:BUNDLE' attribute mid
'group:BUNDLE' attribute mid list associated with the BUNDLE group. list associated with the BUNDLE group.
5.2.5. Offerer Processing of the SDP Answer 8.4. Offerer Processing of the SDP Answer
5.2.5.1. General 8.4.1. General
When an offerer receives an SDP answer, the offerer MUST apply the When an offerer receives an answer, if the answer contains a BUNDLE
selected offerer BUNDLE address to each bundled "m=" line. If the group, the offerer MUST check that any bundled "m=" line in the
offerer generates a subsequent SDP offer, the offerer MUST in the SDP answer was indicated as bundled in the associated offer. If there is
offer assign the offerer BUNDLE address to each bundled "m=" line no mismatch, the offerer MUST apply the offerer BUNDLE address,
(including any 'bundle-only' "m=" line) [Section 5.2.6]. selected by the answerer [Section 8.3.2], to each bundled "m=" line.
The offerer MUST assign the address to each bundled "m=" line
(excluding a bundled "m=" line added to a BUNDLE group, to which the
offerer MAY assign a unique address [Section 8.5.3]) in any
subsequent offer.
If the SDP answer does not contain a BUNDLE group, the offerer MUST NOTE: As the answerer might reject one or more bundled "m=" lines, or
cease to use any procedure associated with the BUNDLE mechanism. move a bundled "m=" line out of a BUNDLE group, each bundled "m="
line in the offer might not be indicated as bundled in the answer.
5.2.5.2. Bundle Address Synchronization (BAS) If the answer does not contain a BUNDLE group, the offerer MUST
process the answer as a normal answer.
If the selected offerer BUNDLE address is different than the address 8.4.2. Bundle Address Synchronization (BAS)
that the offerer in the associated SDP offer assigned to a bundled
"m=" line (including an "m=" line that the offerer in the SDP offer
added to an existing BUNDLE group [Section 5.2.6.2]), and the bundled
"m=" line was not rejected [Section 5.2.4.5], or moved out of the
BUNDLE group [Section 5.2.4.4] by the answerer, the offerer SHOULD as
soon as possible generate a subsequent SDP offer, in which the
offerer assigns the offerer BUNDLE address to each bundled "m=" line.
This procedure is referred to as Bundle Address Synchronization
(BAS), and the SDP offer is referred to as a BAS Offer.
The offerer MAY in the BAS offer modify any SDP parameter. When an offerer receives an answer, if the answer contains a BUNDLE
group, the offerer MUST check whether the offerer BUNDLE address,
selected by the answerer [Section 8.3.2], matches was assigned to
each bundled "m=" line (excluding any bundled "m=" line that was
rejected, or moved out of the BUNDLE group, by the answer) in the
associated offer. If there is a mismatch, the offerer SHOULD as soon
as possible generate a subsequent offer, in which it assigns the
offerer BUNDLE address to each bundled "m=" line. Such offer is
referred to as a Bundle Address Synchronization (BAS) offer.
A BAS offer is typically sent in the following scenarios:
o The offerer receives an answer to an initial offer, as the bundled
"m=" lines in the initial offer always contain unique addresses
[Section 8.2]; or
o The offerer receives an answer to an offer, in which a new bundled
"m=" line has been added to the BUNDLE group [Section 8.5.3], and
the offerer assigned a unique address to the bundled "m=" line in
the offer.
The offerer is allowed to modify any SDP parameter in the BAS offer.
NOTE: It is important that the BAS offer gets accepted by the NOTE: It is important that the BAS offer gets accepted by the
answerer. For that reason the offerer needs to consider the answerer. For that reason the offerer needs to consider the
necessity to in the BAS offer modify SDP parameters that could get necessity to modify SDP parameters in the BAS offer, in such a way
the answerer to reject the BAS offer. Disabling "m=" lines, or that could trigger the answerer to reject the BAS offer. Disabling
reducing the number of codecs, in a BAS offer is considered to have a "m=" lines, or reducing the number of codecs, in a BAS offer is
low risk of being rejected. considered to have a low risk of being rejected.
NOTE: The main purpose of the BAS offer is to ensure that NOTE: The main purpose of the BAS offer is to ensure that
intermediaries, that might not support the BUNDLE mechanism, have intermediaries, that might not support the BUNDLE extension, have
correct information regarding the address is going to be used to correct information regarding the address is going to be used to
transport the bundled media. transport the bundled media.
[Section 13.1] shows an example where an offerer sends a BAS offer. [Section 15.1] shows an example of a BAS offer.
5.2.6. Modifying the Session
5.2.6.1. General
When an offerer generates a subsequent SDP offer, the offerer MUST in
the SDP offer assign the previously selected offerer BUNDLE address
[Section 5.2.4.2] to each bundled "m=" line (including any bundle-
only "m=" line), unless the offerer in the SDP offer moves the "m="
line out of the BUNDLE group [Section 5.2.6.3], or disables the "m="
line [Section 5.2.6.4].
If the SDP offerer in the SDP offer adds an "m=" line to the BUNDLE 8.5. Modifying the Session
group [Section 5.2.6.2], the offerer MAY assign the previously
selected offerer BUNDLE address to the added "m=" line.
In addition, the offerer MUST in the SDP offer indicate which address 8.5.1. General
(unique or previously selected offerer BUNDLE address) it wants the
answerer to select as the offerer BUNDLE address, following the
procedures in [Section 5.2.3.2]. The offerer MUST do this even if
the offerer in the SDP offer assigns a previously selected offerer
BUNDLE address to each bundled "m=" line.
5.2.6.2. Adding a media description to a BUNDLE group When an offerer generates a subsequent offer, it MUST assign the
previously selected offerer BUNDLE address [Section 8.3.2], to each
bundled "m=" line (including any bundle-only "m=" line), with the
following exceptions:
When an offerer generates an SDP offer, in which the offerer wants to o The offerer wants to request the answerer to select a new offerer
add an "m=" line to a BUNDLE group, the offerer assigns in the SDP BUNDLE address [Section 8.5.2];
offer an address (unique or previously selected offerer BUNDLE
address) to the "m=" line, assigns an SDP 'mid' attribute to the "m="
line, and places the mid value in the SDP 'group:BUNDLE' attribute
mid list associated with the BUNDLE group [Section 5.2.3.2].
NOTE: If the offerer wants the answerer to select the address o The offerer wants to add a bundled "m=" line to the BUNDLE group
associated with the added "m=" as the offerer BUNDLE address, the [Section 8.5.3];
offerer suggested BUNDLE mid MUST represent the added "m=" line
[Section 5.2.3.2].
[Section 13.3] shows an example where an offerer sends an SDP offer o The offerer wants to move a bundled "m=" line out of the BUNDLE
in order to add an "m=" line to a BUNDLE group. group [Section 8.5.4]; or
5.2.6.3. Moving A Media Description Out Of A BUNDLE Group o The offerer wants to disable the bundled "m=" line
[Section 8.5.5].
When an offerer generates an SDP offer, in which the offerer wants to In addition, the offerer MUST select an offerer suggested BUNDLE mid
move a bundled "m=" line out of a BUNDLE group, the offerer MUST [Section 8.2.2], even if the offerer does not want the answerer to
assign a unique address to the "m=" line. In addition, the offerer select a new offerer BUNDLE address.
MUST NOT place a mid value associated with the "m=" line in the SDP
'group:BUNDLE' attribute mid list associated with the BUNDLE group.
NOTE: The offerer MAY keep a previously assigned SDP 'mid' attribute If the offerer assigns an SDP 'bundle-only' to a bundled "m=" line in
in an "m=" line that it wants to move out of a BUNDLE group, e.g. if the subsequent offer, if MUST assign the offerer BUNDLE address to
the mid value is used for some other SDP grouping extension than the "m=" line. The offerer MUST NOT assign a unique address, or a
BUNDLE. zero port value, to a bundle-only "m=" line in a subsequent offer.
[Section 13.4] shows an example where an offerer sends an SDP offer NOTE: The offerer can in assign an SDP 'bundle-only' attribute to a
in order to move an "m=" line out of a BUNDLE group. bundled "m=" line in a subsequent offer, even if the offerer did not
assign a 'bundle-only' attribute to the "m=" line in a previous
offer.
5.2.6.4. Disabling A Media Description In A BUNDLE Group 8.5.2. Request new offerer BUNDLE address
When an offerer generates an SDP offer, in which the offerer wants to When an offerer generates an offer, in which it wants the answerer to
disable a bundled "m=" line, the offerer MUST assign an address with select a new offerer BUNDLE address Section 8.2.2, the offerer MUST:
a zero port alue to the "m=" line, following the procedures in
[RFC4566]. In addition, the offerer MUST NOT place a mid value
associated with the "m=" line in the SDP 'group:BUNDLE' attribute mid
list associated with the BUNDLE group.
NOTE: The offerer MAY assign an SDP 'mid' attribute to an "m=" line o Assign a unique address, which the offerer wants the answerer to
that it wants to disable, e.g. if the mid value is used for some select as the offerer BUNDLE address, to a bundled "m=" line
other SDP grouping extension than BUNDLE. (added to the BUNDLE group in a previous offer/answer transaction,
or requested to be added to the BUNDLE group in the current
offer); and
[Section 13.5] shows an example where an offerer sends an SDP offer o Indicate that the offerer wants the answerer to select the unique
in order to disable an "m=" line within a BUNDLE group. address as the offerer BUNDLE address [Section 8.2.2]
6. SDP 'bundle-only' Attribute NOTE: The offerer can assign a unique address to each bundled "m="
line in the offer, or it can assign the previously negotiated offerer
BUNDLE address to each "m=" line (except the "m=" line to which it
assigns the unique address that it wants the answerer to select as
the new offerer BUNDLE address).
6.1. General 8.5.3. Adding a media description to a BUNDLE group
This section defines a new SDP media-level attribute [RFC4566], When an offerer generates an offer, in which it wants to add a
'bundle-only'. An offerer can in an SDP offer assign a 'bundle-only' bundled "m=" line to BUNDLE group, the offerer MUST:
"m=" line to a bundled "m=" line (including an "m=" line that the
offerer wants to add to the BUNDLE group [Section 5.2.6.2]), in order
to ensure that the answerer only accepts the "m=" line if the
answerer supports the BUNDLE mechanism, and if the answerer in the
SDP answer keeps the "m=" line within the BUNDLE group.
6.2. SDP Offer/Answer Procedures o Assign a unique address (excluding bundle-only "m=" lines), or the
offerer BUNDLE address (selected by the answerer in a previous
offer/answer transaction), to the "m=" line;
6.2.1. Generating the Initial SDP Offer o Place the SDP 'mid' attribute value associated with the "m=" line
in the SDP 'group:BUNDLE' attribute mid list associated with the
BUNDLE group [Section 8.2.2].
When an offerer generates an initial SDP offer, in order to create a If the offerer wants the answerer to select the address associated
BUNDLE group, the offerer can in the SDP offer assign an SDP 'bundle- with the added "m=" line as the new offerer BUNDLE address, the
only' attribute to an "m=" line that the offerer wants to be within offerer suggested BUNDLE mid MUST represent the added "m=" line
the BUNDLE group. [Section 8.2.2].
The offerer MUST in the SDP offer assign a zero port value the If the offerer assigns an SDP 'bundle-only' attribute to the added
bundle-only "m=" line. "m=" line, the offerer MUST assign the offerer BUNDLE address
(selected by the answerer in a previous offer/answer transaction) to
the "m=" line.
6.2.2. Generating the SDP Answer [Section 15.3] shows an example where an offerer sends an offer in
order to add a bundled "m=" line to a BUNDLE group.
When the answerer selects the offerer BUNDLE address 8.5.4. Moving A Media Description Out Of A BUNDLE Group
[Section 5.2.4.2], the answerer MUST also take a bundle-only "m="
line with a non-zero port value into consideration.
If the offerer in the SDP offer has assigned a zero port value to a When an offerer generates an offer, in which it wants to move a
bundle-only "m=" line, and if the answerer accepts the "m=" line, the bundled "m=" line (added to the BUNDLE group in a previous offer/
answerer will treat the "m=" line as any other bundle "m=" line when answer transaction), the offerer:
the answerer generates the SDP answer [Section 5.2.4].
NOTE: If the offerer in the SDP offer has assigned a zero port value o MUST assign a unique address to the "m=" line;
to a bundled "m=" line, but the offerer has not assigned a 'bundle-
only' SDP attribute to the "m=" line, it is an indication that the
offerer wants to disable the "m=" line [Section 5.2.6.4].
If the answerer in the SDP answer does not keep the bundle-only "m=" o MUST NOT place a mid value associated with the "m=" line in the
line within the BUNDLE group, the answerer MUST in the SDP answer SDP 'group:BUNDLE' attribute mid list associated with the BUNDLE
reject the "m=" line [Section 5.2.4.5]. group; and
The answerer MUST NOT in the SDP answer assign an SDP 'bundle-only' o MUST NOT assign an SDP 'bundle-only' attribute to the "m=" line.
attribute to an "m=" line (even if the offerer in the associated SDP
offer has assigned a 'bundle-only' attribute to the "m="line).
6.2.3. Offerer Processing of the SDP Answer [Section 15.4] shows an example of an offer for moving an "m=" line
out of a BUNDLE group.
When the offerer receives an SDP answer, the offerer follows the 8.5.5. Disabling A Media Description In A BUNDLE Group
procedures in [Section 5.2.5]. If the offerer in the associated SDP
offer assigned an SDP 'bundle-only' attribute to an "m=" line, and
the "m=" line was accepted (and was kept within the BUNDLE group) by
the answerer, the selected offerer BUNDLE address also applies to the
"m=" line.
6.2.4. Modifying the Session 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/
answer transaction), the offerer:
When an offerer creates a subsequent SDP offer, the offerer follows o MUST assign an address with a zero port value to the "m=" line,
the procedures in [Section 5.2.6]. If the offerer in the SDP offer following the procedures in [RFC4566];
assigns an SDP 'bundle-only' attribute to a bundled "m=" line, in
order to ensure that the answerer accepts the "m=" line only if the
answerer keeps the "m=" line within the BUNDLE group, the offerer
MUST NOT assign a zero port value to the "m=" line. Instead, the
offerer MUST in the SDP offer assign the offerer BUNDLE address or,
if the "m=" line is added to the BUNDLE group [Section 5.2.6.2],
either the offerer BUNDLE address or a unique address, to the "m="
line.
NOTE: The offerer can in a subsequent SDP offer assign an SDP o MUST NOT place a mid value associated with the "m=" line in the
'bundle-only' attribute to a bundled "m=" line even if the offerer SDP 'group:BUNDLE' attribute mid list associated with the BUNDLE
did not assign a 'bundle-only' attribute to the "m=" line in a group; and
previous SDP offer.
If the offerer in the SDP offer wants to move a bundled "m=" line out o MUST NOT assign an SDP 'bundle-only' attribute to the "m=" line.
of a BUNDLE group [Section 5.2.6.3], the offerer MUST NOT in the SDP
offer assign a 'bundle-only' attribute to the "m=" line.
If the offerer in the SDP offer wants to disable a bundled "m=" line [Section 15.5] shows an example of an offer for disabling an "m="
[Section 5.2.6.4], the offerer MUST NOT in the SDP offer assign a line within a BUNDLE group.
'bundle-only' attribute to the "m=" line.
7. Protocol Identification 9. Protocol Identification
7.1. General 9.1. General
If bundled "m=" lines represent different transport protocols, there If bundled "m=" lines represent different transport protocols, there
MUST exist a specification which describes a mechanism, for this MUST exist a publically available specification which describes a
specific transport protocol combination, how to associate a received mechanism, for this specific transport protocol combination, how to
packet with the correct transport protocol. associate a received packet with the correct transport protocol.
In addition, if a received packet can be associated with more than In addition, if a received packet can be associated with more than
one bundled "m=" line, there MUST exist a specification which one bundled "m=" line, there MUST exist a publically available
describes a mechanism how to associated the received packet with the specification which describes a mechanism how to associated the
correct "m=" line. received packet with the correct "m=" line.
7.2. STUN, DTLS, SRTP 9.2. STUN, DTLS, SRTP
Section 5.1.2 of [RFC5764] describes a mechanism how to identify the Section 5.1.2 of [RFC5764] describes a mechanism how to identify the
protocol among the STUN, DTLS and SRTP protocols (in any protocol among the STUN, DTLS and SRTP protocols (in any
combination). If an offer or answerer in SDP offers or answers combination). If an offer or answerer in offers or answers include
include bundled "m=" lines that represent these protocols, the bundled "m=" lines that represent these protocols, the offerer or
offerer or answerer MUST support the mechanism described in answerer MUST support the mechanism described in [RFC5764], and no
[RFC5764], and no explicit negotiation is required in order to explicit negotiation is required in order to indicate support and
indicate support and usage of the mechanism. 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 how to identify each individual specification describing a mechanism how to identify 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=" line, there MUST exist a specification which
describes a mechanism how to associate the received DTLS packet with describes a mechanism how to associate the received DTLS packet with
the correct "m=" line. the correct "m=" line.
[Section 8.2] describes how to associate a received (S)RTP packet [Section 10.2] describes how to associate a received (S)RTP packet
with the correct "m=" line. with the correct "m=" line.
8. RTP Considerations 10. RTP Considerations
8.1. Single RTP Session 10.1. Single RTP Session
8.1.1. General
10.1.1. General
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]. Disjoint BUNDLE groups will form multiple RTP RTP session [RFC3550]. Disjoint BUNDLE groups will form multiple RTP
sessions, one per BUNDLE group. sessions, one per BUNDLE group.
Since a single RTP session is used for each bundle group, all "m=" Since a single RTP session is used for each bundle group, all "m="
lines representing RTP-based media in a bundle group will share a lines representing RTP-based media in a bundle group will share a
single SSRC numbering space [RFC3550]. 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 if each codec associated with the payload type number shares lines if each codec associated with the payload type number shares
an identical codec configuration [Section 8.1.2]. an identical codec configuration [Section 10.1.2].
o The "proto" value in each bundled "m=" line MUST be identical o The "proto" value in each bundled "m=" line MUST be identical
(e.g. RTP/AVPF). (e.g. RTP/AVPF).
o A given SSRC SHOULD NOT transmit RTP packets using payload types o A given SSRC SHOULD NOT transmit RTP packets using payload types
that originates from different bundled "m=" lines. that originates from different bundled "m=" lines.
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 fails to function. Even if done in with time overlap RTP and RTCP fails to function. Even if done in
proper sequence this causes RTP Timestamp rate switching issues [ref proper sequence this causes RTP Timestamp rate switching issues [ref
to draft-ietf-avtext-multiple-clock-rates]. to draft-ietf-avtext-multiple-clock-rates].
8.1.2. Payload Type (PT) Value Re-usage 10.1.2. Payload Type (PT) Value Re-usage
Multiple bundled "m=" lines might represent RTP based media. As all Multiple bundled "m=" lines might represent RTP based media. As all
RTP based media associated with 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 used inside more session, in order for a given payload type value to used inside more
than one bundled "m=" line, all codecs associated with the payload than one bundled "m=" line, all codecs associated with the payload
type numbers MUST share an identical codec configuration. This means type numbers MUST share an identical codec configuration. This means
that the codecs MUST share the same media type, encoding name, clock that the codecs MUST share the same media type, encoding name, clock
rate and any parameter that can affect the codec configuration and rate and any parameter that can affect the codec configuration and
packetization. [I-D.nandakumar-mmusic-sdp-mux-attributes] lists SDP packetization. [I-D.mmusic-sdp-mux-attributes] lists SDP attributes,
attributes, which attribute values must be identical for all codecs which attribute values must be identical for all codecs that use the
that use the same payload type value. same payload type value.
8.2. Associating RTP/RTCP Packets With Correct SDP Media Description 10.2. Associating RTP/RTCP Packets With Correct SDP Media Description
In general, there are multiple mechanisms that can be used by an In general, there are multiple mechanisms that can be used by an
endpoint in order to associate received RTP/RTCP packets with the endpoint in order to associate received RTP/RTCP packets with the
bundled "m=" line representing the RTP packets. Such mechanisms bundled "m=" line representing the RTP packets. Such mechanisms
include using the local address:port combination on which the RTP include using the local address:port combination on which the RTP
packets are received, the payload type value carried inside the RTP packets are received, the payload type value carried inside the RTP
packets, the SSRC values carried inside the RTP packets, and other packets, the SSRC values carried inside the RTP packets, and other
"m=" line specific information carried inside the RTP packets. "m=" line specific information carried inside the RTP packets.
As all RTP/RTCP packets associated with a BUNDLE group are sent and As all RTP/RTCP packets associated with a BUNDLE group are sent and
received using the same 5-tuple, the local address:port combination received using the same 5-tuple, the local address:port combination
cannot be used to associate received RTP packets with the correct cannot be used to associate received RTP packets with the correct
"m=" line. "m=" line.
As described in [Section 8.1.2], the same payload type value might be As described in [Section 10.1.2], the same payload type value might
used inside RTP packets described by multiple "m=" lines. In such be used inside RTP packets described by multiple "m=" lines. In such
cases, the payload type value cannot be used to associate received cases, the payload type value cannot be used to associate received
RTP packets with the correct "m=" line. RTP packets with the correct "m=" line.
An offerer and answerer can in an SDP offer and answer inform each An offerer and answerer can in an offer and answer inform each other
other which SSRC values they will use inside sent RTP/RTCP packets which SSRC values they will use inside sent RTP/RTCP packets by, by
by, by assigning an SDP 'ssrc' attribute [RFC5576] to each bundled assigning an SDP 'ssrc' attribute [RFC5576] to each bundled "m=" line
"m=" line which contains a payload type value that is also used which contains a payload type value that is also used inside another
inside another bundled "m=" line. As the SSRC values will be carried bundled "m=" line. As the SSRC values will be carried inside the
inside the RTP/RTCP packets, the offerer and answerer can then use RTP/RTCP packets, the offerer and answerer can then use that
that information to associate received RTP packets with the correct information to associate received RTP packets with the correct "m="
"m=" line. However, an offerer will not know which SSRC values the line. However, an offerer will not know which SSRC values the
answerer will use until it has received the SDP answer providing that answerer will use until it has received the answer providing that
information. Due to this, before the offerer has received the SDP information. Due to this, before the offerer has received the
answer, the offerer will not be able to associate received RTP/RTCP answer, the offerer will not be able to associate received RTP/RTCP
packets with the correct "m=" line using the SSRC values. packets with the correct "m=" line using the SSRC values.
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
received RTP and RTCP packets with the correct "m=" line, an offerer received RTP and RTCP packets with the correct "m=" line, an offerer
and answerer using the BUNDLE mechanism MUST use the mechanism and answerer using the BUNDLE extension MUST use the mechanism
defined in Section 11, where the remote endpoint inserts the SDP defined in Section 13, where the remote endpoint inserts the SDP
'mid' attribute value of an "m=" line in RTP and RTCP packets 'mid' attribute value of an "m=" line in RTP and RTCP packets
associated with that "m=" line. associated with that "m=" line.
8.3. RTP/RTCP Multiplexing 10.3. RTP/RTCP Multiplexing
8.3.1. General 10.3.1. General
When a BUNDLE group, which contains RTP based media, is created, the When a BUNDLE group, which contains RTP based media, is created, the
offerer and answerer MUST negotiate whether to enable RTP/RTCP offerer and answerer MUST negotiate whether to enable RTP/RTCP
multiplexing for the RTP based media associated with the BUNDLE group multiplexing for the RTP based media associated with the BUNDLE group
[RFC5761]. [RFC5761].
If RTP/RTCP multiplexing is not enabled, separate 5-tuples will be If RTP/RTCP multiplexing is not enabled, separate 5-tuples will be
used for sending and receiving the RTP packets and the RTCP packets. used for sending and receiving the RTP packets and the RTCP packets.
8.3.2. SDP Offer/Answer Procedures 10.3.2. SDP Offer/Answer Procedures
8.3.2.1. General 10.3.2.1. General
This section describes how an offerer and answerer can use the SDP This section describes how an offerer and answerer can use the SDP
'rtcp-mux' attribute [RFC5761] and the SDP 'rtcp' attribute [RFC3605] 'rtcp-mux' attribute [RFC5761] and the SDP 'rtcp' attribute [RFC3605]
to negotiate usage of RTP/RTCP multiplexing for RTP based associated to negotiate usage of RTP/RTCP multiplexing for RTP based associated
with a BUNDLE group. with a BUNDLE group.
8.3.2.2. Generating the Initial SDP Offer 10.3.2.2. Generating the Initial SDP Offer
When an offerer generates an initial SDP offer, if the offerer wants When an offerer generates an initial offer, if the offerer wants to
to negotiate usage of RTP/RTCP multiplexing within a BUNDLE group, negotiate usage of RTP/RTCP multiplexing within a BUNDLE group, the
the offerer MUST in the SDP offer assign an SDP 'rtcp-mux' attribute offerer MUST assign an SDP 'rtcp-mux' attribute [RFC5761] to each
[RFC5761] to each bundled "m=" line (including any bundle-only "m=" bundled "m=" line (including any bundle-only "m=" line) in the offer.
line). In addition, the offerer MUST in the SDP offer assign an SDP In addition, the offerer MUST assign an SDP 'rtcp' attribute
'rtcp' attribute [RFC3605] to each bundled "m=" line (including any [RFC3605] to each bundled "m=" line (including any bundle-only "m="
bundle-only "m=" line), with an attribute value that is identical to line), with an attribute value that is identical to the port value
the port value assigned to the "m=" line itself. assigned to the "m=" line itself, in the offer.
If the offerer does not want to negotiate usage of RTP/RTCP If the offerer does not want to negotiate usage of RTP/RTCP
multiplexing, the offerer MUST NOT assign the SDP attributes above to multiplexing, it MUST NOT assign the SDP attributes above to any
any bundled "m=" line. bundled "m=" line.
8.3.2.3. Generating the SDP Answer
8.3.2.3.1. Generating the SDP Answer to an Initial SDP Offer 10.3.2.3. Generating the SDP Answer
When the answerer generates an SDP answer to an initial SDP offer, if When an answerer generates an answer, if the offerer indicated
the offerer in the associated SDP offer indicated support of RTP/RTCP support of RTP/RTCP multiplexing [RFC5761] within a BUNDLE group in
multiplexing [RFC5761] within a BUNDLE group, the answerer MUST in the associated offer, the answerer MUST either accept or reject the
the SDP answer either accept or reject usage of RTP/RTCP usage of RTP/RTCP multiplexing in the answer.
multiplexing.
If the answerer accepts usage of RTP/RTCP multiplexing within the If the answerer accepts usage of RTP/RTCP multiplexing within the
BUNDLE group, the answerer MUST in the SDP answer assign an SDP BUNDLE group, it MUST assign an SDP 'rtcp-mux' attribute to each
'rtcp-mux' attribute to each bundled "m=" line. The answerer MUST bundled "m=" line in the answer. The answerer MUST NOT assign an SDP
NOT in the SDP answer assign an SDP 'rtcp' attribute to any bundled 'rtcp' attribute to any bundled "m=" line in the answer.
"m=" line.
If the answerer rejects usage of RTP/RTCP multiplexing within the If the answerer rejects usage of RTP/RTCP multiplexing within the
BUNDLE group, the answerer MUST NOT in the SDP answer assign an SDP BUNDLE group, it MUST NOT assign an SDP 'rtcp-mux' or SDP 'rtcp'
'rtcp-mux' or SDP 'rtcp' attribute to any bundled "m=" line. attribute to any bundled "m=" line in the answer.
8.3.2.3.2. Generating the SDP Answer to a Subsequent SDP Offer
When the answerer generates an SDP answer to a subsequent SDP offer, If the usage of RTP/RTCP multiplexing has been negotiated in a
if the offerer in the associated SDP offer indicated support of RTP/ previous offer/answer transaction, and the offerer indicates that it
RTCP multiplexing [RFC5761] within a BUNDLE group, the answerer MUST wants to continue using RTP/RTCP multiplexing in a subsequent offer,
in the SDP answer assign an SDP 'rtcp-mux' attribute and SDP 'rtcp' the answerer MUST assign an SDP 'rtcp-mux' attribute to each bundled
attribute to each bundled "m=" line. "m=" line in the answer. I.e. the answerer MUST NOT disable the
usage of RTP/RTCP multiplexing.
NOTE: The BUNDLE mechanism does not allow the answerer to, in a 10.3.2.4. Offerer Processing of the SDP Answer
subsequent SDP answer, disable usage of RTP/RTCP multiplexing, if the
offerer in the associated SDP offer indicates that it wants to
continue using RTP/RTCP multiplexing.
8.3.2.4. Offerer Processing of the SDP Answer When the offerer receives an answer, if the answerer accepts the
usage of RTP/RTCP multiplexing, by including an SDP 'rtcp-mux'
attribute to each bundled "m=" line in the answer Section 10.3.2.3,
the answerer follows the procedures for RTP/RTCP multiplexing defined
in [RFC5245].
When the offerer receives an SDP answer, it follows the procedures If the answerer does not accept the usage of RTP/RTCP multiplexing
defined in [RFC5245]. Section 10.3.2.3, the offerer MUST use separate 5-tuples for RTP and
RTCP.
8.3.2.5. Modifying the Session 10.3.2.5. Modifying the Session
When an offerer generates a subsequent SDP offer, if the offerer When an offerer generates a subsequent offer, if it wants to
wants to negotiate usage of RTP/RTCP multiplexing within a BUNDLE negotiate usage of RTP/RTCP multiplexing within a BUNDLE group, or if
group, or if the offerer wants to continue usage of previously it wants to continue usage of RTP/RTCP multiplexing (negotiated in a
negotiated RTP/RTCP multiplexing within the BUNDLE group, the offerer previous offer/answer transaction), it MUST assign SDP 'rtcp-mux' and
MUST in the SDP offer assign 'rtcp-mux' and 'rtcp' attributes to each 'rtcp' attributes to each bundled "m=" line (including bundle-only
bundled "m=" line (including bundle-only "m=" lines), unless the "m=" "m=" lines, and a bundled "m=" line that the offerer wants to add to
line is disabled or removed from the BUNDLE group. the BUNDLE group), unless the offerer wants to disable or remove the
"m=" line from the BUNDLE group.
If the offerer does not want to negotiate usage of RTP/RTCP If the offerer does not want to negotiate usage of RTP/RTCP
multiplexing within the BUNDLE group, or if the offerer wants to multiplexing within the BUNDLE group, or if it wants to disable usage
disable previously negotiated usage of RTP/RTCP multiplexing within a of RTP/RTCP multiplexing (negotiated in a previous offer/answer
BUNDLE group, the offerer MUST NOT in the SDP offer assign 'rtcp-mux' transaction), the offerer MUST NOT assign SDP 'rtcp-mux' and 'rtcp'
and 'rtcp' attributes to any bundled "m=" line. attributes to any bundled "m=" line in the subsequent offer.
NOTE: It is RECOMMENDED that, once usage of RTP/RTCP multiplexing has NOTE: It is RECOMMENDED that, once usage of RTP/RTCP multiplexing has
been negotiated within a BUNDLE group, that the usage of not been negotiated within a BUNDLE group, that the usage is not
disabled. Disabling RTP/RTCP multiplexing means that the offerer and disabled. Disabling RTP/RTCP multiplexing means that the offerer and
answerer need to reserve new IP ports, to be used for sending and answerer need to reserve new IP ports, to be used for sending and
receiving RTCP packets. receiving RTCP packets.
9. ICE Considerations 11. ICE Considerations
9.1. General 11.1. General
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 [RFC5245]. mechanism [RFC5245].
Support and usage of ICE mechanism together with the BUNDLE mechanism The procedures defined in [RFC5245] also apply to usage of ICE with
is optional. BUNDLE, with the following exception:
9.2. SDP Offer/Answer Procedures o When BUNDLE addresses for a BUNDLE group have been selected for
both endpoints, ICE connectivity checks and keep-alives only need
to be performed for the whole BUNDLE group, instead of per bundled
"m=" line.
9.2.1. Generating the Initial SDP Offer Support and usage of ICE mechanism together with the BUNDLE extension
is OPTIONAL.
When an offerer generates an initial SDP offer, which contains a 11.2. SDP Offer/Answer Procedures
BUNDLE group, the offerer MUST assign ICE candidates [RFC5245] to
each bundled "m=" line, except to an "m=" line to which the offerer
assigns a zero port value (e.g. a bundle-only "m=" line). The
offerer MUST assign unique ICE candidate values to each "m=" line.
9.2.2. Generating the SDP Answer 11.2.1. General
When an answerer generates and SDP Answer, which contains a BUNDLE When an offerer or answerer assigns a unique address to a bundled
group, the answerer MUST assign ICE candidates to each bundled "m=" "m=" line (excluding bundle-only "m=" lines), it MUST also assign
line. The answerer MUST assign identical ICE candidate values to unique ICE candidates [RFC5245] to the "m=" line.
each bundled "m=" line.
9.2.3. Offerer Processing of the SDP Answer When an offerer or answerer assigns a shared address (i.e. a
previously selected BUNDLE address) to one or more bundled "m=" line
(including bundle-only "m=" lines), and when it assigns an address
with a zero port value to one or more bundle-only "m=" lines, it MUST
assign identical ICE candidates (referred to as shared ICE
candidates) to each of those "m=" lines.
When the offerer receives an SDP answer, it follows the procedures 11.2.2. Generating the Initial SDP Offer
defined in [RFC5245].
9.2.4. Modifying the Session When an offerer generates an initial offer, it assigns unique or
shared ICE candidates to the bundled "m=" lines, according to
Section 11.1.
When an offerer generates a subsequent SDP offer, for each bundled 11.2.3. Generating the SDP Answer
"m=" line to which the offerer assigns its BUNDLE address, the
offerer MUST assign identical ICE candidate values. The offerer MUST
assign the ICE candidate values associated with the "m=" line that
was used by the answerer to select the offerer BUNDLE address [ref-
to-be-added].
9.2.5. Keep-alives When an answerer generates an answer, which contains a BUNDLE group,
the answerer MUST assign shared ICE candidates to each bundled "m="
line (including "m=" lines that were indicated as bundle-only in the
associated offer) in the answer.
Once it is known that both endpoints support, and accept to use, the 11.2.4. Offerer Processing of the SDP Answer
BUNDLE grouping extension, ICE connectivity checks and keep-alives
only needs to be performed for the whole BUNDLE group, instead of for
each bundled "m=" line.
10. Update to RFC 3264 When an offerer receives an answer, if the answerer supports and uses
the ICE mechanism and the BUNDLE extension, the offerer MUST assign
the ICE candidates, associated with the "m=" line representing the
offerer BUNDLE address (selected by the answerer) to each bundled
"m=" line.
10.1. General 11.2.5. Modifying the Session
When an offerer generates a subsequent offer, it assigns unique or
shared ICE candidates to the bundled "m=" lines, according to
Section 11.1.
12. Update to RFC 3264
12.1. General
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).
o Section 8.2 (Removing a Media Stream). o Section 8.2 (Removing a Media Stream).
o Section 8.4 (Putting a Unicast Media Stream on Hold). o Section 8.4 (Putting a Unicast Media Stream on Hold).
10.2. Original text of section 5.1 (2nd paragraph) of RFC 3264 12.2. Original text of section 5.1 (2nd paragraph) of RFC 3264
For recvonly and sendrecv streams, the port number and address in the For recvonly and sendrecv streams, the port number and address in the
offer indicate where the offerer would like to receive the media offer indicate where the offerer would like to receive the media
stream. For sendonly RTP streams, the address and port number stream. For sendonly RTP streams, the address and port number
indirectly indicate where the offerer wants to receive RTCP reports. indirectly indicate where the offerer wants to receive RTCP reports.
Unless there is an explicit indication otherwise, reports are sent to Unless there is an explicit indication otherwise, reports are sent to
the port number one higher than the number indicated. The IP address the port number one higher than the number indicated. The IP address
and port present in the offer indicate nothing about the source IP and port present in the offer indicate nothing about the source IP
address and source port of RTP and RTCP packets that will be sent by address and source port of RTP and RTCP packets that will be sent by
the offerer. A port number of zero in the offer indicates that the the offerer. A port number of zero in the offer indicates that the
stream is offered but MUST NOT be used. This has no useful semantics stream is offered but MUST NOT be used. This has no useful semantics
in an initial offer, but is allowed for reasons of completeness, in an initial offer, but is allowed for reasons of completeness,
since the answer can contain a zero port indicating a rejected stream since the answer can contain a zero port indicating a rejected stream
(Section 6). Furthermore, existing streams can be terminated by (Section 6). Furthermore, existing streams can be terminated by
setting the port to zero (Section 8). In general, a port number of setting the port to zero (Section 8). In general, a port number of
zero indicates that the media stream is not wanted. zero indicates that the media stream is not wanted.
10.3. New text replacing section 5.1 (2nd paragraph) of RFC 3264 12.3. New text replacing section 5.1 (2nd paragraph) of RFC 3264
For recvonly and sendrecv streams, the port number and address in the For recvonly and sendrecv streams, the port number and address in the
offer indicate where the offerer would like to receive the media offer indicate where the offerer would like to receive the media
stream. For sendonly RTP streams, the address and port number stream. For sendonly RTP streams, the address and port number
indirectly indicate where the offerer wants to receive RTCP reports. indirectly indicate where the offerer wants to receive RTCP reports.
Unless there is an explicit indication otherwise, reports are sent to Unless there is an explicit indication otherwise, reports are sent to
the port number one higher than the number indicated. The IP address the port number one higher than the number indicated. The IP address
and port present in the offer indicate nothing about the source IP and port present in the offer indicate nothing about the source IP
address and source port of RTP and RTCP packets that will be sent by address and source port of RTP and RTCP packets that will be sent by
the offerer. A port number of zero in the offer by default indicates the offerer. A port number of zero in the offer by default indicates
that the stream is offered but MUST NOT be used, but an extension that the stream is offered but MUST NOT be used, but an extension
mechanism might specify different semantics for the usage of a zero mechanism might specify different semantics for the usage of a zero
port value. Furthermore, existing streams can be terminated by port value. Furthermore, existing streams can be terminated by
setting the port to zero (Section 8). In general, a port number of setting the port to zero (Section 8). In general, a port number of
zero by default indicates that the media stream is not wanted. zero by default indicates that the media stream is not wanted.
10.4. Original text of section 8.2 (2nd paragraph) of RFC 3264 12.4. Original text of section 8.2 (2nd paragraph) of RFC 3264
A stream that is offered with a port of zero MUST be marked with port A stream that is offered with a port of zero MUST be marked with port
zero in the answer. Like the offer, the answer MAY omit all zero in the answer. Like the offer, the answer MAY omit all
attributes present previously, and MAY list just a single media attributes present previously, and MAY list just a single media
format from amongst those in the offer. format from amongst those in the offer.
10.5. New text replacing section 8.2 (2nd paragraph) of RFC 3264 12.5. New text replacing section 8.2 (2nd paragraph) of RFC 3264
A stream that is offered with a port of zero MUST by default be A stream that is offered with a port of zero MUST by default be
marked with port zero in the answer, unless an extension mechanism, marked with port zero in the answer, unless an extension mechanism,
which specifies semantics for the usage of a non-zero port value, is which specifies semantics for the usage of a non-zero port value, is
used. used.
10.6. Original text of section 8.4 (6th paragraph) of RFC 3264 12.6. Original text of section 8.4 (6th paragraph) of RFC 3264
RFC 2543 [10] specified that placing a user on hold was accomplished RFC 2543 [10] specified that placing a user on hold was accomplished
by setting the connection address to 0.0.0.0. Its usage for putting by setting the connection address to 0.0.0.0. Its usage for putting
a call on hold is no longer recommended, since it doesn't allow for a call on hold is no longer recommended, since it doesn't allow for
RTCP to be used with held streams, doesn't work with IPv6, and breaks RTCP to be used with held streams, doesn't work with IPv6, and breaks
with connection oriented media. However, it can be useful in an with connection oriented media. However, it can be useful in an
initial offer when the offerer knows it wants to use a particular set initial offer when the offerer knows it wants to use a particular set
of media streams and formats, but doesn't know the addresses and of media streams and formats, but doesn't know the addresses and
ports at the time of the offer. Of course, when used, the port ports at the time of the offer. Of course, when used, the port
number MUST NOT be zero, which would specify that the stream has been number MUST NOT be zero, which would specify that the stream has been
disabled. An agent MUST be capable of receiving SDP with a disabled. An agent MUST be capable of receiving SDP with a
connection address of 0.0.0.0, in which case it means that neither connection address of 0.0.0.0, in which case it means that neither
RTP nor RTCP should be sent to the peer. RTP nor RTCP should be sent to the peer.
10.7. New text replacing section 8.4 (6th paragraph) of RFC 3264 12.7. New text replacing section 8.4 (6th paragraph) of RFC 3264
RFC 2543 [10] specified that placing a user on hold was accomplished RFC 2543 [10] specified that placing a user on hold was accomplished
by setting the connection address to 0.0.0.0. Its usage for putting by setting the connection address to 0.0.0.0. Its usage for putting
a call on hold is no longer recommended, since it doesn't allow for a call on hold is no longer recommended, since it doesn't allow for
RTCP to be used with held streams, doesn't work with IPv6, and breaks RTCP to be used with held streams, doesn't work with IPv6, and breaks
with connection oriented media. However, it can be useful in an with connection oriented media. However, it can be useful in an
initial offer when the offerer knows it wants to use a particular set initial offer when the offerer knows it wants to use a particular set
of media streams and formats, but doesn't know the addresses and of media streams and formats, but doesn't know the addresses and
ports at the time of the offer. Of course, when used, the port ports at the time of the offer. Of course, when used, the port
number MUST NOT be zero, if it would specify that the stream has been number MUST NOT be zero, if it would specify that the stream has been
disabled. However, an extension mechanism might specify different disabled. However, an extension mechanism might specify different
semantics of the zero port number usage. An agent MUST be capable of semantics of the zero port number usage. An agent MUST be capable of
receiving SDP with a connection address of 0.0.0.0, in which case it receiving SDP with a connection address of 0.0.0.0, in which case it
means that neither RTP nor RTCP should be sent to the peer. means that neither RTP nor RTCP should be sent to the peer.
11. RTP/RTCP extensions for mid value transport 13. RTP/RTCP extensions for mid value transport
11.1. General 13.1. General
SDP Offerers and Answerers [RFC3264] can assign values, mid values, SDP Offerers and Answerers [RFC3264] can assign values, mid values,
to SDP Media Descriptions (m= lines) within SDP Offers and Answers, to SDP Media Descriptions (m= lines) within SDP Offers and Answers,
using the procedures in [RFC5888]. Each mid value uniquely using the procedures in [RFC5888]. Each mid value uniquely
references an m= line. references an m= line.
This section defines a new RTP SDES item [RFC3550], 'MID', which is This section defines a new RTP SDES item [RFC3550], 'MID', which is
used to carry mid values within RTCP SDES packets. This section also used to carry mid values within RTCP SDES packets. This section also
defines a new RTP header extension [RFC5285], which can be used to defines a new RTP header extension [RFC5285], which can be used to
carry the mid value in RTP packets. carry the mid value in RTP packets.
skipping to change at page 23, line 44 skipping to change at page 25, line 28
I-frames). The exact number of RTP packets in which this header I-frames). The exact number of RTP packets in which this header
extension is sent is intentionally not specified here, as it will extension is sent is intentionally not specified here, as it will
depend on expected packet loss rate and loss patterns, the overhead depend on expected packet loss rate and loss patterns, the overhead
the application can tolerate, and the importance of immediate receipt the application can tolerate, and the importance of immediate receipt
of the mid value. of the mid value.
For robustness purpose, endpoints need to be prepared for situations For robustness purpose, endpoints need to be prepared for situations
where the mid value is delayed, and SHOULD NOT terminate sessions in where the mid value is delayed, and SHOULD NOT terminate sessions in
such cases, as the mid value is likely to arrive soon. such cases, as the mid value is likely to arrive soon.
11.2. RTP MID SDES Item 13.2. RTP MID SDES Item
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MID=TBD | length | mid value ... | MID=TBD | length | mid value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The mid value payload is UTF-8 encoded, as in SDP. The mid value payload is UTF-8 encoded, as in SDP.
11.3. RTP MID Header Extension 13.3. RTP MID Header Extension
The payload, containing the mid value, of the RTP MID header The payload, containing the mid value, of the RTP MID header
extension element can be encoded using either the one-byte or two- extension element can be encoded using either the one-byte or two-
byte header [RFC5285]. The mid value payload is UTF-8 encoded, as in byte header [RFC5285]. The mid value payload is UTF-8 encoded, as in
SDP. SDP.
11.4. IANA Considerations 13.4. IANA Considerations
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this
document.] document.]
[RFC EDITOR NOTE: Please replace TBD with the assigned SDES [RFC EDITOR NOTE: Please replace TBD with the assigned SDES
identifier value.] identifier value.]
This document adds the MID SDES item to the IANA "RTP SDES item This document adds the MID SDES item to the IANA "RTP SDES item
types" registry as follows: types" registry as follows:
skipping to change at page 24, line 39 skipping to change at page 26, line 25
This document defines a new extension URI in the RTP Compact Header This document defines a new extension URI in the RTP Compact Header
Extensions subregistry of the Real-Time Transport Protocol (RTP) Extensions subregistry of the Real-Time Transport Protocol (RTP)
Parameters registry, according to the following data: Parameters 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
12. Security Considerations 14. Security Considerations
This specification does not significantly change the security This specification does not significantly change the security
considerations of SDP which can be found in Section X of TBD. considerations of SDP which can be found in Section X of TBD.
TODO: Think carefully about security analysis of reuse of same SDES TODO: Think carefully about security analysis of reuse of same SDES
key on multiple "m=" lines when the far end does not use BUNDLE and key on multiple "m=" lines when the far end does not use BUNDLE and
warn developers of any risks. warn developers of any risks.
13. Examples 15. Examples
13.1. Example: Bundle Address Selection 15.1. Example: Bundle Address Selection
The example below shows: The example below shows:
o 1. An SDP offer, in which the offerer assigns a unique address to o 1. An offer, in which the offerer assigns a unique address to
each bundled "m=" line within the BUNDLE group. each bundled "m=" line within the BUNDLE group.
o 2. An SDP answer, in which the answerer selects the offerer o 2. An answer, in which the answerer selects the offerer BUNDLE
BUNDLE address, and in which selects its own BUNDLE address (the address, and in which selects its own BUNDLE address (the answerer
answerer BUNDLE address) and assigns it each bundled "m=" line BUNDLE address) and assigns it each bundled "m=" line within the
within the BUNDLE group. BUNDLE group.
o 3. A subsequent SDP offer (BAS offer), which is used to perform a o 3. A subsequent offer (BAS offer), which is used to perform a
Bundle Address Synchronization (BAS). Bundle Address Synchronization (BAS).
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 26, line 32 skipping to change at page 28, line 19
b=AS:200 b=AS:200
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
m=video 10000 RTP/AVP 31 32 m=video 10000 RTP/AVP 31 32
a=mid:bar a=mid:bar
b=AS:1000 b=AS:1000
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
13.2. Example: Bundle Mechanism Rejected 15.2. Example: BUNDLE Extension Rejected
The example below shows: The example below shows:
o 1. An SDP offer, in which the offerer assigns a unique address to o 1. An offer, in which the offerer assigns a unique address to
each bundled "m=" line within the BUNDLE group. each bundled "m=" line within the BUNDLE group.
o 2. An SDP answer, in which the answerer rejects the offered o 2. An answer, in which the answerer rejects the offered BUNDLE
BUNDLE group, and assigns a unique addresses to each "m=" line group, and assigns a unique addresses to each "m=" line (following
(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
m=audio 10000 RTP/AVP 0 8 97 m=audio 10000 RTP/AVP 0 8 97
skipping to change at page 27, line 39 skipping to change at page 29, line 39
s= s=
c=IN IP4 biloxi.example.com c=IN IP4 biloxi.example.com
t=0 0 t=0 0
m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0
b=AS:200 b=AS:200
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
m=video 30000 RTP/AVP 32 m=video 30000 RTP/AVP 32
b=AS:1000 b=AS:1000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
13.3. Example: Offerer Adds A Media Description To A BUNDLE Group 15.3. Example: Offerer Adds A Media Description To A BUNDLE Group
The example below shows: The example below shows:
o 1. An SDP offer, in which the offerer adds a new "m=" line, o 1. An offer, in which the offerer adds a new "m=" line,
represented by the "zen" mid value, to a previously negotiated represented by the "zen" mid value, to a previously negotiated
BUNDLE group, assigns a unique address to the added "m=" line, and BUNDLE group, assigns a unique address to the added "m=" line, and
assigns the previously selected offerer BUNDLE address to each of assigns the previously selected offerer BUNDLE address to each of
the other bundled "m=" lines within the BUNDLE group. the other bundled "m=" lines within the BUNDLE group.
o 2. An SDP answer, in which the answerer assigns the answerer o 2. An answer, in which the answerer assigns the answerer BUNDLE
BUNDLE address to each bundled "m=" line (including the newly address to each bundled "m=" line (including the newly added "m="
added "m=" line) within the BUNDLE group. line) within the BUNDLE group.
o 3. A subsequent SDP offer (BAS offer), which is used to perform a o 3. A subsequent offer (BAS offer), which is used to perform a
Bundle Address Synchronization (BAS). Bundle Address Synchronization (BAS).
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
skipping to change at page 29, line 34 skipping to change at page 31, line 34
m=video 10000 RTP/AVP 31 32 m=video 10000 RTP/AVP 31 32
a=mid:bar a=mid:bar
b=AS:1000 b=AS:1000
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
m=video 10000 RTP/AVP 66 m=video 10000 RTP/AVP 66
a=mid:zen a=mid:zen
b=AS:1000 b=AS:1000
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
13.4. Example: Offerer Moves A Media Description Out Of A BUNDLE Group 15.4. Example: Offerer Moves A Media Description Out Of A BUNDLE Group
The example below shows: The example below shows:
o 1. An SDP offer, in which the offerer moves a bundled "m=" line o 1. An offer, in which the offerer moves a bundled "m=" line out
out of a BUNDLE group, assigns a unique address to the moved "m=" of a BUNDLE group, assigns a unique address to the moved "m="
line, and assigns the offerer BUNDLE address to each other bundled line, and assigns the offerer BUNDLE address to each other bundled
"m=" line within the BUNDLE group. "m=" line within the BUNDLE group.
o 2. An SDP answer, in which the answerer moves the "m=" line out o 2. An answer, in which the answerer moves the "m=" line out of
of the BUNDLE group, assigns unique address to the moved "m=" the BUNDLE group, assigns unique address to the moved "m=" line,
line, and assigns the answerer BUNDLE address to each other and assigns the answerer BUNDLE address to each other bundled "m="
bundled "m=" line within the BUNDLE group. line 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 31, line 5 skipping to change at page 33, line 5
b=AS:200 b=AS:200
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
m=video 20000 RTP/AVP 32 m=video 20000 RTP/AVP 32
a=mid:bar a=mid:bar
b=AS:1000 b=AS:1000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
m=video 60000 RTP/AVP 66 m=video 60000 RTP/AVP 66
b=AS:1000 b=AS:1000
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
13.5. Example: Offerer Disables A Media Description Within A BUNDLE 15.5. Example: Offerer Disables A Media Description Within A BUNDLE
Group Group
The example below shows: The example below shows:
o 1. An SDP offer, in which the offerer disables a bundled "m=" o 1. An offer, in which the offerer disables a bundled "m=" line
line within BUNDLE group, assigns a zero port number the disabled within BUNDLE group, assigns a zero port number the disabled "m="
"m=" line, and assigns the offerer BUNDLE address to each of the line, and assigns the offerer BUNDLE address to each of the other
other bundled "m=" lines within the BUNDLE group. bundled "m=" lines within the BUNDLE group.
o 2. An SDP answer, in which the answerer moves the disabled "m=" o 2. An answer, in which the answerer moves the disabled "m=" line
line out of the BUNDLE group, assigns a zero port value to the out of the BUNDLE group, assigns a zero port value to the disabled
disabled "m=" line, and assigns the answerer BUNDLE address to "m=" line, and assigns the answerer BUNDLE address to each of the
each of the other bundled "m=" lines within the BUNDLE group. other bundled "m=" lines 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 33, line 5 skipping to change at page 35, line 5
a=mid:foo a=mid:foo
b=AS:200 b=AS:200
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
m=video 20000 RTP/AVP 32 m=video 20000 RTP/AVP 32
a=mid:bar a=mid:bar
b=AS:1000 b=AS:1000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
m=video 0 RTP/AVP 66 m=video 0 RTP/AVP 66
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
14. IANA Considerations 16. IANA Considerations
This document requests IANA to register the new SDP Grouping semantic This document requests IANA to register the new SDP Grouping semantic
extension called BUNDLE. extension called BUNDLE.
15. Acknowledgements 17. Acknowledgements
The usage of the SDP grouping extension for negotiating bundled media The usage of the SDP grouping extension for negotiating bundled media
is based on a similar alternatives proposed by Harald Alvestrand and is based on a similar alternatives proposed by Harald Alvestrand and
Cullen Jennings. The BUNDLE mechanism 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 and Martin Thompson for taking the the time to Thanks to Paul Kyzivat, Martin Thompson and Flemming Andreasen for
read the text along the way, and providing useful feedback. taking the time to read the text along the way, and providing useful
feedback.
16. Change Log 18. 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-08
o Editorial corrections.
o - "of"->"if" (8.3.2.5).
o - "optional"->"OPTIONAL" (9.1).
o - Syntax/ABNF for 'bundle-only' attribute added.
o - SDP Offer/Answer sections merged.
o - 'Request new offerer BUNDLE address' section added
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-07 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-07
o OPEN ISSUE regarding Receiver-ID closed. o OPEN ISSUE regarding Receiver-ID closed.
o - RTP MID SDES Item. o - RTP MID SDES Item.
o - RTP MID Header Extension. o - RTP MID Header Extension.
o OPEN ISSUE regarding insertion of SDP 'rtcp' attribute in SDP o OPEN ISSUE regarding insertion of SDP 'rtcp' attribute in answers
answers closed. closed.
o - Indicating that, when rtcp-mux is used, the answerer MUST NOT o - Indicating that, when rtcp-mux is used, the answerer MUST NOT
include an 'rtcp' attribute in the answer, based on the procedures include an 'rtcp' attribute in the answer, based on the procedures
in section 5.1.3 of RFC 5761. in section 5.1.3 of RFC 5761.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-06 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-06
o Draft title changed. o Draft title changed.
o Added "SDP" to section names containing "Offer" or "Answer". o Added "SDP" to section names containing "Offer" or "Answer".
skipping to change at page 34, line 31 skipping to change at page 36, line 48
o - Bundled "m=" line. o - Bundled "m=" line.
o - Bundle-only "m=" line. o - Bundle-only "m=" line.
o - Offerer suggested BUNDLE mid. o - Offerer suggested BUNDLE mid.
o - Answerer selected BUNDLE mid. o - Answerer selected BUNDLE mid.
o Q6 Closed (IETF#88): An Offerer MUST NOT assign a shared address o Q6 Closed (IETF#88): An Offerer MUST NOT assign a shared address
to multiple "m=" lines until it has received an SDP Answer to multiple "m=" lines until it has received an SDP Answer
indicating support of the BUNDLE mechanism. indicating support of the BUNDLE extension.
o Q8 Closed (IETF#88): An Offerer can, before it knows whether the o Q8 Closed (IETF#88): An Offerer can, before it knows whether the
Answerer supports the BUNDLE mechanism, assign a zero port value Answerer supports the BUNDLE extension, assign a zero port value
to a 'bundle-only' "m=" line. to a 'bundle-only' "m=" line.
o SDP 'bundle-only' attribute section added. o SDP 'bundle-only' attribute section added.
o Connection data nettype/addrtype restrictions added. o Connection data nettype/addrtype restrictions added.
o RFC 3264 update section added. o RFC 3264 update section added.
o Indicating that a specific payload type value can be used in o Indicating that a specific payload type value can be used in
multiple "m=" lines, if the value represents the same codec multiple "m=" lines, if the value represents the same codec
skipping to change at page 35, line 40 skipping to change at page 38, line 7
o Draft name changed. o Draft name changed.
o Harald Alvestrand added as co-author. o Harald Alvestrand added as co-author.
o "Multiplex" terminology changed to "bundle". o "Multiplex" terminology changed to "bundle".
o Added text about single versus multiple RTP Sessions. o Added text about single versus multiple RTP Sessions.
o Added reference to RFC 3550. o Added reference to RFC 3550.
17. References 19. References
17.1. Normative References 19.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June with Session Description Protocol (SDP)", RFC 3264, June
2002. 2002.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, July 2008. Header Extensions", RFC 5285, July 2008.
[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, April 2010. Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, June 2010. Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[I-D.nandakumar-mmusic-sdp-mux-attributes] [I-D.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-01 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-02
(work in progress), February 2014. (work in progress), July 2014.
17.2. Informative References 19.2. Informative References
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
in Session Description Protocol (SDP)", RFC 3605, October in Session Description Protocol (SDP)", RFC 3605, October
2003. 2003.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
 End of changes. 214 change blocks. 
600 lines changed or deleted 711 lines changed or added

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