draft-ietf-mmusic-sdp-bundle-negotiation-19.txt   draft-ietf-mmusic-sdp-bundle-negotiation-20.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: September 27, 2015 C. Jennings Expires: December 14, 2015 C. Jennings
Cisco Cisco
March 26, 2015 June 12, 2015
Negotiating Media Multiplexing Using the Session Description Protocol Negotiating Media Multiplexing Using the Session Description Protocol
(SDP) (SDP)
draft-ietf-mmusic-sdp-bundle-negotiation-19.txt draft-ietf-mmusic-sdp-bundle-negotiation-20.txt
Abstract Abstract
This specification defines a new Session Description Protocol (SDP) This specification defines a new Session Description Protocol (SDP)
Grouping Framework extension, 'BUNDLE'. The extension can be used Grouping Framework extension, 'BUNDLE'. The extension can be used
with the SDP Offer/Answer mechanism to negotiate the usage of a with the SDP Offer/Answer mechanism to negotiate the usage of a
single address:port combination (BUNDLE address) for receiving media, single address:port combination (BUNDLE address) for receiving media,
referred to as bundled media, associated with multiple SDP media referred to as bundled media, associated with multiple SDP media
descriptions ("m=" lines). descriptions ("m=" lines).
To assist endpoints in negotiating the use of bundle this To assist endpoints in negotiating the use of bundle this
specification defines a new SDP attribute, 'bundle-only', which can specification defines a new SDP attribute, 'bundle-only', which can
be used to request that specific media is only used if bundled. This be used to request that specific media is only used if bundled.
specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264 to
allow an answerer to assign a non-zero port value to an "m=" line in
an SDP answer, even if the "m=" line in the associated SDP offer
contained a zero port value.
There are multiple ways to correlate the bundled RTP packets with the There are multiple ways to correlate the bundled RTP packets with the
appropriate media descriptions. This specification defines a new appropriate media descriptions. This specification defines a new
RTCP source description (SDES) item and a new RTP header extension Real-time Transport Protocol (RTP) source description (SDES) item and
that provides an additional way to do this correlation by using them a new RTP header extension that provides an additional way to do this
to carry a value that associates the RTP/RTCP packets with a specific correlation by using them to carry a value that associates the RTP/
media description. RTCP packets with a specific media description.
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 December 14, 2015.
This Internet-Draft will expire on September 27, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 48 skipping to change at page 2, line 42
7.3. Bandwidth (b=) . . . . . . . . . . . . . . . . . . . . . 9 7.3. Bandwidth (b=) . . . . . . . . . . . . . . . . . . . . . 9
7.4. Attributes (a=) . . . . . . . . . . . . . . . . . . . . . 9 7.4. Attributes (a=) . . . . . . . . . . . . . . . . . . . . . 9
8. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 9 8. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 9
8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.2. Generating the Initial SDP Offer . . . . . . . . . . . . 10 8.2. Generating the Initial SDP Offer . . . . . . . . . . . . 10
8.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 10 8.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 10
8.2.2. Suggesting the offerer BUNDLE address . . . . . . . . 11 8.2.2. Suggesting the offerer BUNDLE address . . . . . . . . 11
8.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 11 8.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 11
8.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 11 8.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 11
8.3.2. Answerer Selection of Offerer Bundle Address . . . . 12 8.3.2. Answerer Selection of Offerer Bundle Address . . . . 12
8.3.3. Answerer Selection of Answerer BUNDLE Address . . . . 13 8.3.3. Answerer Selection of Answerer BUNDLE Address . . . . 12
8.3.4. Moving A Media Description Out Of A BUNDLE Group . . 13 8.3.4. Moving A Media Description Out Of A BUNDLE Group . . 13
8.3.5. Rejecting A Media Description In A BUNDLE Group . . . 13 8.3.5. Rejecting A Media Description In A BUNDLE Group . . . 13
8.4. Offerer Processing of the SDP Answer . . . . . . . . . . 14 8.4. Offerer Processing of the SDP Answer . . . . . . . . . . 13
8.4.1. General . . . . . . . . . . . . . . . . . . . . . . . 14
8.5. Modifying the Session . . . . . . . . . . . . . . . . . . 14 8.5. Modifying the Session . . . . . . . . . . . . . . . . . . 14
8.5.1. General . . . . . . . . . . . . . . . . . . . . . . . 14 8.5.1. General . . . . . . . . . . . . . . . . . . . . . . . 14
8.5.2. Suggesting a new offerer BUNDLE address . . . . . . . 14 8.5.2. Suggesting a new offerer BUNDLE address . . . . . . . 14
8.5.3. Adding a media description to a BUNDLE group . . . . 15 8.5.3. Adding a media description to a BUNDLE group . . . . 15
8.5.4. Moving A Media Description Out Of A BUNDLE Group . . 16 8.5.4. Moving A Media Description Out Of A BUNDLE Group . . 15
8.5.5. Disabling A Media Description In A BUNDLE Group . . . 16 8.5.5. Disabling A Media Description In A BUNDLE Group . . . 16
9. Protocol Identification . . . . . . . . . . . . . . . . . . . 16 9. Protocol Identification . . . . . . . . . . . . . . . . . . . 16
9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.2. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 17 9.2. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 17
10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 17 10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 17
10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 17 10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 17
10.1.1. General . . . . . . . . . . . . . . . . . . . . . . 17 10.1.1. General . . . . . . . . . . . . . . . . . . . . . . 17
10.1.2. Payload Type (PT) Value Reuse . . . . . . . . . . . 18 10.1.2. Payload Type (PT) Value Reuse . . . . . . . . . . . 18
10.2. Associating RTP/RTCP Packets With Correct SDP Media 10.2. Associating RTP/RTCP Packets With Correct SDP Media
Description . . . . . . . . . . . . . . . . . . . . . . 18 Description . . . . . . . . . . . . . . . . . . . . . . 18
10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 19 10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 19
skipping to change at page 3, line 25 skipping to change at page 3, line 19
10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 17 10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 17
10.1.1. General . . . . . . . . . . . . . . . . . . . . . . 17 10.1.1. General . . . . . . . . . . . . . . . . . . . . . . 17
10.1.2. Payload Type (PT) Value Reuse . . . . . . . . . . . 18 10.1.2. Payload Type (PT) Value Reuse . . . . . . . . . . . 18
10.2. Associating RTP/RTCP Packets With Correct SDP Media 10.2. Associating RTP/RTCP Packets With Correct SDP Media
Description . . . . . . . . . . . . . . . . . . . . . . 18 Description . . . . . . . . . . . . . . . . . . . . . . 18
10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 19 10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 19
10.3.1. General . . . . . . . . . . . . . . . . . . . . . . 19 10.3.1. General . . . . . . . . . . . . . . . . . . . . . . 19
10.3.2. SDP Offer/Answer Procedures . . . . . . . . . . . . 19 10.3.2. SDP Offer/Answer Procedures . . . . . . . . . . . . 19
11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 22 11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 22
11.1. General . . . . . . . . . . . . . . . . . . . . . . . . 22 11.1. General . . . . . . . . . . . . . . . . . . . . . . . . 22
11.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 22 11.2. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 23
11.2.1. General . . . . . . . . . . . . . . . . . . . . . . 22 11.2.1. General . . . . . . . . . . . . . . . . . . . . . . 23
11.2.2. Generating the Initial SDP Offer . . . . . . . . . . 23 11.2.2. Generating the Initial SDP Offer . . . . . . . . . . 23
11.2.3. Generating the SDP Answer . . . . . . . . . . . . . 23 11.2.3. Generating the SDP Answer . . . . . . . . . . . . . 23
11.2.4. Offerer Processing of the SDP Answer . . . . . . . . 23 11.2.4. Offerer Processing of the SDP Answer . . . . . . . . 23
11.2.5. Modifying the Session . . . . . . . . . . . . . . . 23 11.2.5. Modifying the Session . . . . . . . . . . . . . . . 24
12. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 23 12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 24
12.1. General . . . . . . . . . . . . . . . . . . . . . . . . 23 13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 24
12.2. Original text of section 5.1 (2nd paragraph) of RFC 3264 24 13.1. General . . . . . . . . . . . . . . . . . . . . . . . . 24
12.3. New text replacing section 5.1 (2nd paragraph) of RFC 13.2. Original text of section 5.1 (2nd paragraph) of RFC 3264 25
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 24 13.3. New text replacing section 5.1 (2nd paragraph) of RFC
12.4. Original text of section 8.2 (2nd paragraph) of RFC 3264 24
12.5. New text replacing section 8.2 (2nd paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.6. Original text of section 8.4 (6th paragraph) of RFC 3264 25
12.7. New text replacing section 8.4 (6th paragraph) of RFC
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 25
13. RTP/RTCP extensions for identification-tag transport . . . . 25 13.4. Original text of section 8.2 (2nd paragraph) of RFC 3264 25
13.1. General . . . . . . . . . . . . . . . . . . . . . . . . 25 13.5. New text replacing section 8.2 (2nd paragraph) of RFC
13.2. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 26 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 25
13.3. RTP MID Header Extension . . . . . . . . . . . . . . . . 27 13.6. Original text of section 8.4 (6th paragraph) of RFC 3264 26
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 13.7. New text replacing section 8.4 (6th paragraph) of RFC
14.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 27 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 26
14.2. New RTP Header Extension URI . . . . . . . . . . . . . . 28 14. RTP/RTCP extensions for identification-tag transport . . . . 26
14.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 28 14.1. General . . . . . . . . . . . . . . . . . . . . . . . . 26
15. Security Considerations . . . . . . . . . . . . . . . . . . . 28 14.2. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 27
16. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 29 14.3. RTP MID Header Extension . . . . . . . . . . . . . . . . 28
16.1. Example: Bundle Address Selection . . . . . . . . . . . 29 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
16.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 31 15.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 28
16.3. Example: Offerer Adds A Media Description To A BUNDLE 15.2. New RTP Header Extension URI . . . . . . . . . . . . . . 29
Group . . . . . . . . . . . . . . . . . . . . . . . . . 32 15.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 29
16.4. Example: Offerer Moves A Media Description Out Of A 15.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 29
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 34 16. Security Considerations . . . . . . . . . . . . . . . . . . . 30
16.5. Example: Offerer Disables A Media Description Within A 17. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 30
17.1. Example: Bundle Address Selection . . . . . . . . . . . 30
17.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 32
17.3. Example: Offerer Adds A Media Description To A BUNDLE
Group . . . . . . . . . . . . . . . . . . . . . . . . . 33
17.4. Example: Offerer Moves A Media Description Out Of A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 35 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 35
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 17.5. Example: Offerer Disables A Media Description Within A
18. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 37 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 36
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38
19.1. Normative References . . . . . . . . . . . . . . . . . . 42 19. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 38
19.2. Informative References . . . . . . . . . . . . . . . . . 43 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
Appendix A. Design Considerations . . . . . . . . . . . . . . . 44 20.1. Normative References . . . . . . . . . . . . . . . . . . 44
A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 44 20.2. Informative References . . . . . . . . . . . . . . . . . 44
A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 44 Appendix A. Design Considerations . . . . . . . . . . . . . . . 45
A.3. Usage of port number value zero . . . . . . . . . . . . . 46 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 45
A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 46 A.2. UA Interoperability . . . . . . . . . . . . . . . . . . . 46
A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 47 A.3. Usage of port number value zero . . . . . . . . . . . . . 47
A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 47 A.4. B2BUA And Proxy Interoperability . . . . . . . . . . . . 48
A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 47 A.4.1. Traffic Policing . . . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 A.4.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 48
A.5. Candidate Gathering . . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction 1. Introduction
This specification defines a way to use a single address:port This specification defines a way to use a single address:port
combination (BUNDLE address) for receiving media associated with combination (BUNDLE address) for receiving media associated with
multiple SDP media descriptions ("m=" lines). multiple SDP media descriptions ("m=" lines).
This specification defines a new SDP Grouping Framework [RFC5888] This specification defines a new SDP Grouping Framework [RFC5888]
extension called 'BUNDLE'. The extension can be used with the extension called 'BUNDLE'. The extension can be used with the
Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264] Session Description Protocol (SDP) Offer/Answer mechanism [RFC3264]
skipping to change at page 5, line 21 skipping to change at page 5, line 17
grouping defined by such means. Instead, an explicit grouping 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.
This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264 This specification also updates sections 5.1, 8.1 and 8.2 of RFC 3264
[RFC3264]. The update allows an answerer to assign a non-zero port [RFC3264]. The update allows an answerer to assign a non-zero port
value to an "m=" line in an SDP answer, even if the "m=" line in the value to an "m=" line in an SDP answer, even if the "m=" line in the
associated SDP offer contained a zero port value. associated SDP offer contained a zero port value.
This specification also defines a new Real-time Transport Protocol This specification also defines a new Real-time Transport Protocol
(RTP) [RFC3550] SDES item and a new RTP header extension that can be (RTP) [RFC3550] source description (SDES) item and a new RTP header
used to carry a value that associates RTP/RTCP packets with a extension that can be used to carry a value that associates RTP/RTCP
specific media description. This can be used to correlate a RTP packets with a specific media description. This can be used to
packet with the correct media. correlate a RTP packet with the correct media.
SDP bodies can contain multiple BUNDLE groups. A given BUNDLE SDP bodies can contain multiple BUNDLE groups. A given BUNDLE
address MUST only be associated with a single BUNDLE group. The address MUST only be associated with a single BUNDLE group. The
procedures in this specification apply independently to a given procedures in this specification apply independently to a given
BUNDLE group. All RTP based media flows associated with a single BUNDLE group. All RTP based media flows associated with a single
BUNDLE group belong to a single RTP session [RFC3550]. BUNDLE group belong to a single RTP session [RFC3550].
The BUNDLE extension is backward compatible. Endpoints that do not The BUNDLE extension is backward compatible. Endpoints that do not
support the extension are expected to generate offers and answers support the extension are expected to generate offers and answers
without an SDP 'group:BUNDLE' attribute, and are expected to assign a without an SDP 'group:BUNDLE' attribute, and are expected to assign a
unique address to each "m=" line within an offer and answer, unique address to each "m=" line within an offer and answer,
according to the procedures in [RFC4566] and [RFC3264] according to the procedures in [RFC4566] and [RFC3264]
2. Terminology 2. Terminology
"m=" line: SDP bodies contain one or more media descriptions. Each
media description is identified by an SDP "m=" line.
5-tuple: A collection of the following values: source address, source 5-tuple: A collection of the following values: source address, source
port, destination address, destination port, and transport-layer port, destination address, destination port, and transport-layer
protocol. protocol.
Unique address: An IP address and port combination that is assigned Unique address: An IP address and port combination that is assigned
to only one "m=" line in an offer or answer. to only one "m=" line in an offer or answer.
Shared address: An IP address and port combination that is assigned Shared address: An IP address and port combination that is assigned
to multiple "m=" lines within an offer or answer. to multiple "m=" lines within an offer or answer.
skipping to change at page 7, line 23 skipping to change at page 7, line 23
This section defines a new SDP Grouping Framework extension This section defines a new SDP Grouping Framework extension
[RFC5888], 'BUNDLE'. The BUNDLE extension can be used with the SDP [RFC5888], 'BUNDLE'. The BUNDLE extension can be used with the SDP
Offer/Answer mechanism to negotiate the usage of a single Offer/Answer mechanism to negotiate the usage of a single
address:port combination (BUNDLE address) for receiving bundled address:port combination (BUNDLE address) for receiving bundled
media. media.
A single address:port combination is also used for sending bundled A single address:port combination is also used for sending bundled
media. The address:port combination used for sending bundled media media. The address:port combination used for sending bundled media
MAY be the same as the BUNDLE address, used to receive bundled media, MAY be the same as the BUNDLE address, used to receive bundled media,
depending on whether symmetric RTP is used. A given address:port depending on whether symmetric RTP [RFC4961] is used.
combination MUST NOT be used for sending media associated with
multiple BUNDLE groups.
All media associated with a BUNDLE group share a single 5-tuple, i.e. All media associated with a BUNDLE group share a single 5-tuple, i.e.
in addition to using a single address:port combination all bundled in addition to using a single address:port combination all bundled
media MUST be transported using the same transport-layer protocol media MUST be transported using the same transport-layer protocol
(e.g. UDP or TCP). (e.g. UDP or TCP).
The BUNDLE extension is indicated using an SDP 'group' attribute with The BUNDLE extension is indicated using an SDP 'group' attribute with
a "BUNDLE" semantics value [RFC5888]. An identification-tag is a "BUNDLE" semantics value [RFC5888]. An identification-tag is
assigned to each bundled "m=" line, and each identification-tag is assigned to each bundled "m=" line, and each identification-tag is
listed in the SDP 'group:BUNDLE' attribute identification-tag list. listed in the SDP 'group:BUNDLE' attribute identification-tag list.
Each "m=" line, whose identification-tag is listed in the Each "m=" line whose identification-tag is listed in the
identification-tag list, is associated with a given BUNDLE group. identification-tag list is associated with a given BUNDLE group.
SDP bodies can contain multiple BUNDLE groups. Any given bundled SDP bodies can contain multiple BUNDLE groups. Any given bundled
"m=" line MUST NOT be associated with more than one BUNDLE group. "m=" line MUST NOT be associated with more than one BUNDLE group.
Section 8 defines the detailed SDP Offer/Answer procedures for the Section 8 defines the detailed SDP Offer/Answer procedures for the
BUNDLE extension. BUNDLE extension.
6. SDP 'bundle-only' Attribute 6. SDP 'bundle-only' Attribute
This section defines a new SDP media-level attribute [RFC4566], This section defines a new SDP media-level attribute [RFC4566],
skipping to change at page 8, line 17 skipping to change at page 8, line 17
Value: Value:
Usage Level: media Usage Level: media
Charset Dependent: no Charset Dependent: no
Example: Example:
a=bundle-only a=bundle-only
In order to ensure that an answerer that does not supports the BUNDLE In order to ensure that an answerer that does not support the BUNDLE
extension always rejects a bundled "m=" line, the offerer can assign extension always rejects a bundled "m=" line, the offerer can assign
a zero port value to the "m=" line. According to [RFC4566] an a zero port value to the "m=" line. According to [RFC4566] an
answerer will reject such "m=" line. By associating an SDP 'bundle- answerer will reject such "m=" line. By associating an SDP 'bundle-
only' attribute with such "m=" line, the offerer can request that the only' attribute with such "m=" line, the offerer can request that the
answerer accepts the "m=" line if the answerer supports the Bundle answerer accepts the "m=" line if the answerer supports the Bundle
extension, and if the answerer keeps the "m=" line within the extension, and if the answerer keeps the "m=" line within the
associated BUNDLE group. associated BUNDLE group.
NOTE: Once an offerer BUNDLE address has been selected, the offerer NOTE: Once the offerer BUNDLE address has been selected, the offerer
can ensure that an bundled "m=" line is accepted by the answerer only does not need to include the 'bundle-only' attribute in subsequent
if the answerer keeps the "m=" line within the associated BUNDLE offers. By assigning the offerer BUNDLE address to an "m=" line of a
group by assigning the offerer BUNDLE address to the "m=" line. If subsequent offer, the offerer will ensure that the answerer will
the answerer does not keep that "m=" line within the BUNDLE group, either keep the "m=" line within the BUNDLE group, or the answerer
the answerer will reject it. Therefore, the SDP 'bundle-only' will have to reject the "m=" line.
attribute is not needed in such cases
The usage of the 'bundle-only' attribute is only defined for a The usage of the 'bundle-only' attribute is only defined for a
bundled "m=" line with a zero port value, within an offer. Other bundled "m=" line with a zero port value, within an offer. Other
usage is unspecified. usage is unspecified.
Section 8 defines the detailed SDP Offer/Answer procedures for the Section 8 defines the detailed SDP Offer/Answer procedures for the
'bundle-only' attribute. 'bundle-only' attribute.
7. SDP Information Considerations 7. SDP Information Considerations
skipping to change at page 10, line 15 skipping to change at page 10, line 15
the BUNDLE group is not created. the BUNDLE group is not created.
The procedures in this section are independent of the media type or The procedures in this section are independent of the media type or
"m=" line proto value represented by a bundled "m=" line. Section 10 "m=" line proto value represented by a bundled "m=" line. Section 10
defines additional considerations for RTP based media. Section 6 defines additional considerations for RTP based media. Section 6
defines additional considerations for the usage of the SDP 'bundle- defines additional considerations for the usage of the SDP 'bundle-
only' attribute. Section 11 defines additional considerations for only' attribute. Section 11 defines additional considerations for
the usage of Interactive Connectivity Establishment (ICE) [RFC5245] the usage of Interactive Connectivity Establishment (ICE) [RFC5245]
mechanism . mechanism .
The offerer and answerer MUST follow the rules and restrictions
defined in Section 7 when creating offers and answers.
SDP offers and answers can contain multiple BUNDLE groups. The SDP offers and answers can contain multiple BUNDLE groups. The
procedures in this section apply independently to a given BUNDLE procedures in this section apply independently to a given BUNDLE
group. group.
8.2. Generating the Initial SDP Offer 8.2. Generating the Initial SDP Offer
8.2.1. General 8.2.1. General
When an offerer generates an initial offer, in order to create a When an offerer generates an initial offer, in order to create a
BUNDLE group, it MUST: BUNDLE group, it MUST:
skipping to change at page 11, line 7 skipping to change at page 11, line 5
o Associate an SDP 'bundle-only' attribute [Section 8.2.2] with the o Associate an SDP 'bundle-only' attribute [Section 8.2.2] with the
"m=" line; and "m=" line; and
o Assign a zero port value to the "m=" line. o Assign a zero port value to the "m=" line.
NOTE: If the offerer assigns a zero port value to an "m=" line, but NOTE: If the offerer assigns a zero port value to an "m=" line, but
does not also associate an SDP 'bundle-only' attribute with the "m=" does not also associate an SDP 'bundle-only' attribute with the "m="
line, it is an indication that the offerer wants to disable the "m=" line, it is an indication that the offerer wants to disable the "m="
line [Section 8.5.5]. line [Section 8.5.5].
[Section 16.1] shows an example of an initial offer. [Section 17.1] shows an example of an initial offer.
8.2.2. Suggesting the offerer BUNDLE address 8.2.2. Suggesting the offerer BUNDLE address
In the offer, the address assigned to the "m=" line associated with In the offer, the address assigned to the "m=" line associated with
the offerer BUNDLE-tag indicates the address that the offerer the offerer BUNDLE-tag indicates the address that the offerer
suggests as the offerer BUNDLE address. suggests as the offerer BUNDLE address.
8.3. Generating the SDP Answer 8.3. Generating the SDP Answer
8.3.1. General 8.3.1. General
When an answerer generates an answer, which contains a BUNDLE group, When an answerer generates an answer that contains a BUNDLE group,
the following general SDP grouping framework restrictions, defined in the following general SDP grouping framework restrictions, defined in
[RFC5888], also apply to the BUNDLE group: [RFC5888], also apply to the BUNDLE group:
o The answerer MUST NOT include a BUNDLE group in the answer, unless o The answerer MUST NOT include a BUNDLE group in the answer, unless
the offerer requested the BUNDLE group to be created in the the offerer requested the BUNDLE group to be created in the
associated offer; and associated offer; and
o The answerer MUST NOT include an "m=" line within a BUNDLE group, o The answerer MUST NOT include an "m=" line within a BUNDLE group,
unless the offerer requested the "m=" line to be within that unless the offerer requested the "m=" line to be within that
BUNDLE group in the associated offer. BUNDLE group in the associated offer.
skipping to change at page 12, line 47 skipping to change at page 12, line 44
If one or more of the criteria are not fulfilled, the answerer MUST If one or more of the criteria are not fulfilled, the answerer MUST
select the next identification-tag in the identification-tag list, select the next identification-tag in the identification-tag list,
and perform the same criteria check for the "m=" line associated with and perform the same criteria check for the "m=" line associated with
that identification-tag. If there are no more identification-tags in that identification-tag. If there are no more identification-tags in
the identification-tag list, the answerer MUST NOT create the BUNDLE the identification-tag list, the answerer MUST NOT create the BUNDLE
group. In addition, unless the answerer rejects the whole offer, the group. In addition, unless the answerer rejects the whole offer, the
answerer MUST apply the answerer procedures for moving an "m=" line answerer MUST apply the answerer procedures for moving an "m=" line
out of a BUNDLE group [Section 8.3.4] to each bundled "m=" line in out of a BUNDLE group [Section 8.3.4] to each bundled "m=" line in
the offer when creating the answer. the offer when creating the answer.
[Section 16.1] shows an example of an offerer BUNDLE address [Section 17.1] shows an example of an offerer BUNDLE address
selection. selection.
8.3.3. Answerer Selection of Answerer BUNDLE Address 8.3.3. Answerer Selection of Answerer BUNDLE Address
When the answerer selects a BUNDLE address for itself, referred to as When the answerer selects a BUNDLE address for itself, referred to as
the answerer BUNDLE address, it MUST assign that address to each the answerer BUNDLE address, it MUST assign that address to each
bundled "m=" line within the created BUNDLE group in the answer. bundled "m=" line within the created BUNDLE group in the answer.
The answerer MUST NOT assign the answerer BUNDLE address to an "m=" The answerer MUST NOT assign the answerer BUNDLE address to an "m="
line that is not within the BUNDLE group, or to an "m=" line that is line that is not within the BUNDLE group, or to an "m=" line that is
within another BUNDLE group. within another BUNDLE group.
[Section 16.1] shows an example of an answerer BUNDLE address [Section 17.1] shows an example of an answerer BUNDLE address
selection. selection.
8.3.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 moves a "m=" line out of a BUNDLE group, it assigns When an answerer wants to move an "m=" line out of a BUNDLE group, it
an address to the "m=" line in the answer based on the following MUST first check the following criteria:
rules:
o In the associated offer, if the "m=" line contains a shared
address (e.g. a previously selected offerer BUNDLE address), the
answerer MUST reject the moved "m=" line [Section 8.3.5];
o In the associated offer, if the "m=" line contains a unique o In the associated offer, the "m=" line contains a shared address
address, the answerer MUST assign a unique address also to the (e.g. a previously selected offerer BUNDLE address); or
"m=" line in the answer; or
o In the associated offer, if an SDP 'bundle-only' attribute is o In the associated offer, if an SDP 'bundle-only' attribute is
associated with the "m=" line, and if the "m=" line contains a associated with the "m=" line, and if the "m=" line contains a
zero port value, the answerer MUST reject the "m=" line zero port value.
[Section 8.3.5].
If either criteria above is fulfilled, the answerer MUST reject the
"m=" line [Section 8.3.5].
Otherwise, if in the associated offer the "m=" line contains a unique
address, the answerer MUST assign a unique address to the "m=" line
in the answer (the answerer does not reject the "m=" line).
In addition, in either case above, the answerer MUST NOT place the In addition, in either case above, the answerer MUST NOT place the
identification-tag, associated with the moved "m=" line, in the SDP identification-tag, associated with the moved "m=" line, in the SDP
'group' attribute identification-tag list associated with the BUNDLE 'group' attribute identification-tag list associated with the BUNDLE
group. group.
8.3.5. Rejecting A Media Description In A BUNDLE Group 8.3.5. Rejecting A Media Description In A BUNDLE Group
When an answerer rejects an "m=" line, it MUST assign an address with When an answerer rejects an "m=" line, it MUST assign an address with
a zero port value to the "m=" line in the answer, according to the a zero port value to the "m=" line in the answer, according to the
procedures in [RFC4566]. procedures in [RFC4566].
In addition, the answerer MUST NOT place the identification-tag, In addition, the answerer MUST NOT place the identification-tag,
associated with the rejected "m=" line, in the SDP 'group' attribute associated with the rejected "m=" line, in the SDP 'group' attribute
identification-tag list associated with the BUNDLE group. identification-tag list associated with the BUNDLE group.
8.4. Offerer Processing of the SDP Answer 8.4. Offerer Processing of the SDP Answer
8.4.1. General
When an offerer receives an answer, if the answer contains a BUNDLE When an offerer receives an answer, if the answer contains a BUNDLE
group, the offerer MUST check that any bundled "m=" line in the group, the offerer MUST check that any bundled "m=" line in the
answer was indicated as bundled in the associated offer. If there is answer was indicated as bundled in the associated offer. If there is
no mismatch, the offerer MUST use the offerer BUNDLE address, no mismatch, the offerer MUST use the offerer BUNDLE address,
selected by the answerer [Section 8.3.2], as the address for each selected by the answerer [Section 8.3.2], as the address for each
bundled "m=" line. bundled "m=" line.
NOTE: As the answerer might reject one or more bundled "m=" lines, or NOTE: As the answerer might reject one or more bundled "m=" lines, or
move a bundled "m=" line out of a BUNDLE group, each bundled "m=" 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. line in the offer might not be indicated as bundled in the answer.
skipping to change at page 15, line 51 skipping to change at page 15, line 43
If the offerer assigns a unique address to the added "m=" line, and If the offerer assigns a unique address to the added "m=" line, and
if the offerer suggests that address as the new offerer BUNDLE if the offerer suggests that address as the new offerer BUNDLE
address [Section 8.5.2], the offerer BUNDLE-tag MUST represent the address [Section 8.5.2], the offerer BUNDLE-tag MUST represent the
added "m=" line [Section 8.2.2]. added "m=" line [Section 8.2.2].
If the offerer assigns a new suggested offerer BUNDLE address to each If the offerer assigns a new suggested offerer BUNDLE address to each
bundled "m=" line [Section 8.5.2], including the added "m=" line, the bundled "m=" line [Section 8.5.2], including the added "m=" line, the
offerer BUNDLE-tag MAY represent the added "m=" line [Section 8.2.2]. offerer BUNDLE-tag MAY represent the added "m=" line [Section 8.2.2].
[Section 16.3] shows an example where an offerer sends an offer in [Section 17.3] shows an example where an offerer sends an offer in
order to add a bundled "m=" line to a BUNDLE group. order to add a bundled "m=" line to a BUNDLE group.
8.5.4. Moving A Media Description Out Of A BUNDLE Group 8.5.4. Moving A Media Description Out Of A BUNDLE Group
When an offerer generates an offer, in which it wants to move a When an offerer generates an offer, in which it wants to move a
bundled "m=" line out of a BUNDLE group it was added to in a previous bundled "m=" line out of a BUNDLE group it was added to in a previous
offer/answer transaction, the offerer: offer/answer transaction, the offerer:
o MUST assign a unique address to the "m=" line; and o MUST assign a unique address to the "m=" line; and
o MUST NOT place the identification-tag associated with the "m=" o MUST NOT place the identification-tag associated with the "m="
line in the SDP 'group:BUNDLE' attribute identification-tag list line in the SDP 'group:BUNDLE' attribute identification-tag list
associated with the BUNDLE group. associated with the BUNDLE group.
NOTE: If the removed "m=" line is associated with the previously
selected BUNDLE-tag, the offerer needs to suggest a new BUNDLE-tag
[Section 8.2.2].
NOTE: If an "m=" line, when being moved out of a BUNDLE group, is NOTE: If an "m=" line, when being moved out of a BUNDLE group, is
added to another BUNDLE group, the offerer applies the procedures in added to another BUNDLE group, the offerer applies the procedures in
[Section 8.5.3] to the "m=" line. [Section 8.5.3] to the "m=" line.
[Section 16.4] shows an example of an offer for moving an "m=" line [Section 17.4] shows an example of an offer for moving an "m=" line
out of a BUNDLE group. out of a BUNDLE group.
8.5.5. Disabling A Media Description In A BUNDLE Group 8.5.5. Disabling A Media Description In A BUNDLE Group
When an offerer generates an offer, in which it wants to disable a When an offerer generates an offer, in which it wants to disable a
bundled "m=" line (added to the BUNDLE group in a previous offer/ bundled "m=" line (added to the BUNDLE group in a previous offer/
answer transaction), the offerer: answer transaction), the offerer:
o MUST assign an address with a zero port value to the "m=" line, o MUST assign an address with a zero port value to the "m=" line,
following the procedures in [RFC4566]; and following the procedures in [RFC4566]; and
o MUST NOT place the identification-tag associated with the "m=" o MUST NOT place the identification-tag associated with the "m="
line in the SDP 'group:BUNDLE' attribute identification-tag list line in the SDP 'group:BUNDLE' attribute identification-tag list
associated with the BUNDLE group. associated with the BUNDLE group.
[Section 16.5] shows an example of an offer for disabling an "m=" [Section 17.5] shows an example of an offer for disabling an "m="
line within a BUNDLE group. line within a BUNDLE group.
9. Protocol Identification 9. Protocol Identification
9.1. General 9.1. General
Each "m=" line within a BUNDLE group MUST use the same transport- Each "m=" line within a BUNDLE group MUST use the same transport-
layer protocol. If bundled "m=" lines use different protocols on top layer protocol. If bundled "m=" lines use different protocols on top
of the transport-layer protocol, there MUST exist a publicly of the transport-layer protocol, there MUST exist a publicly
available specification which describes a mechanism, for this available specification which describes a mechanism, for this
particular protocol combination, how to associate a received packet particular protocol combination, how to associate a received packet
with the correct protocol. with the correct 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 publically available one bundled "m=" line, there MUST exist a publicly available
specification which describes a mechanism for associating the specification which describes a mechanism for associating the
received packet with the correct "m=" line. received packet with the correct "m=" line.
9.2. STUN, DTLS, SRTP 9.2. STUN, DTLS, SRTP
Section 5.1.2 of [RFC5764] describes a mechanism to identify the Section 5.1.2 of [RFC5764] describes a mechanism to identify the
protocol of a received packet among the STUN, DTLS and SRTP protocols protocol of a received packet among the STUN, Datagram Transport
(in any combination). If an offer or answer includes bundled "m=" Layer Security (DTLS) and SRTP protocols (in any combination). If an
lines that represent these protocols, the offerer or answerer MUST offer or answer includes bundled "m=" lines that represent these
support the mechanism described in [RFC5764], and no explicit protocols, the offerer or answerer MUST support the mechanism
negotiation is required in order to indicate support and usage of the described in [RFC5764], and no explicit negotiation is required in
mechanism. order to indicate support and usage of the mechanism.
[RFC5764] does not describe how to identify different protocols [RFC5764] does not describe how to identify different protocols
transported on DTLS, only how to identify the DTLS protocol itself. transported on DTLS, only how to identify the DTLS protocol itself.
If multiple protocols are transported on DTLS, there MUST exist a If multiple protocols are transported on DTLS, there MUST exist a
specification describing a mechanism for identifying each individual specification describing a mechanism for identifying each individual
protocol. In addition, if a received DTLS packet can be associated protocol. In addition, if a received DTLS packet can be associated
with more than one "m=" line, there MUST exist a specification which with more than one "m=" line, there MUST exist a specification which
describes a mechanism for associating the received DTLS packet with describes a mechanism for associating the received DTLS packet with
the correct "m=" line. the correct "m=" line.
skipping to change at page 19, line 5 skipping to change at page 19, line 5
As all RTP/RTCP packets associated with a BUNDLE group are received As all RTP/RTCP packets associated with a BUNDLE group are received
(and sent) using single address:port combinations, the local (and sent) using single address:port combinations, the local
address:port combination cannot be used to associate received RTP address:port combination cannot be used to associate received RTP
packets with the correct "m=" line. packets with the correct "m=" line.
As described in [Section 10.1.2], the same payload type value might As described in [Section 10.1.2], the same payload type value might
be 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 offer and answer inform each other An offerer and answerer can inform each other which SSRC values they
which SSRC values they will use inside sent RTP/RTCP packets, by will use or RTP and RTCP by using the SDP 'ssrc' attribute [RFC5576].
associating one or more SDP 'ssrc' attributes [RFC5576] with each To allow for proper association with this mechanism, the 'ssrc'
bundled "m=" line which contains a payload type value that is also attribute needs to be associated with each "m=" line that shares a
used inside another bundled "m=" line. As the SSRC values will be payload type with any other "m=" line in the same bundle. As the
carried inside the RTP/RTCP packets, the offerer and answerer can SSRC values will be carried inside the RTP/RTCP packets, the offerer
then use that information to associate received RTP packets with the and answerer can then use that information to associate received RTP
correct "m=" line. However, an offerer will not know which SSRC packets with the correct "m=" line. However, an offerer will not
values the answerer will use until it has received the answer know which SSRC values the answerer will use until it has received
providing that information. Due to this, before the offerer has the answer providing that information. Due to this, before the
received the answer, the offerer will not be able to associate offerer has received the answer, the offerer will not be able to
received RTP/RTCP packets with the correct "m=" line using the SSRC associate received RTP/RTCP packets with the correct "m=" line using
values. 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 extension MUST support the mechanism and answerer using the BUNDLE extension MUST support the mechanism
defined in Section 13, where the remote endpoint inserts the defined in Section 14, where the remote endpoint inserts the
identification-tag associated with an "m=" line in RTP and RTCP identification-tag associated with an "m=" line in RTP and RTCP
packets associated with that "m=" line. packets associated with that "m=" line.
10.3. RTP/RTCP Multiplexing 10.3. RTP/RTCP Multiplexing
10.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 enabled, the same address:port
combination will be used for receiving (and sending) all RTP packets
and the RTCP packets associated with the BUNDLE group. Each endpoint
will send the packets towards the BUNDLE address of the other
endpoint.
If RTP/RTCP multiplexing is not enabled, separate address:port If RTP/RTCP multiplexing is not enabled, separate address:port
combinations will be used for receiving (and sending) the RTP packets combinations will be used for receiving (and sending) the RTP packets
and the RTCP packets. and the RTCP packets. If the remote endpoint has associated an SDP
'rtcp' attribute with the "m=" line associated with the BUNDLE-tag,
the attribute value will be used for sending all RTCP packets
associated with the BUNDLE group towards that endpoint.
10.3.2. SDP Offer/Answer Procedures 10.3.2. SDP Offer/Answer Procedures
10.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 media to negotiate usage of RTP/RTCP multiplexing for RTP based media
associated with a BUNDLE group. associated with a BUNDLE group.
10.3.2.2. Generating the Initial SDP Offer 10.3.2.2. Generating the Initial SDP Offer
When an offerer generates an initial offer, if the offerer wants to When an offerer generates an initial offer, if the offerer wants to
skipping to change at page 23, line 23 skipping to change at page 23, line 37
shared ICE candidates) to each of those "m=" lines. shared ICE candidates) to each of those "m=" lines.
11.2.2. Generating the Initial SDP Offer 11.2.2. Generating the Initial SDP Offer
When an offerer generates an initial offer, it assigns unique or When an offerer generates an initial offer, it assigns unique or
shared ICE candidates to the bundled "m=" lines, according to shared ICE candidates to the bundled "m=" lines, according to
Section 11.1. Section 11.1.
11.2.3. Generating the SDP Answer 11.2.3. Generating the SDP Answer
When an answerer generates an answer, which contains a BUNDLE group, When an answerer generates an answer that contains a BUNDLE group,
the answerer MUST assign shared ICE candidates to each bundled "m=" the answerer MUST assign shared ICE candidates to each bundled "m="
line (including "m=" lines that were indicated as bundle-only in the line (including "m=" lines that were indicated as bundle-only in the
associated offer) in the answer. associated offer) in the answer.
11.2.4. Offerer Processing of the SDP Answer 11.2.4. Offerer Processing of the SDP Answer
When an offerer receives an answer, if the answerer supports and uses When an offerer receives an answer, if the answerer supports and uses
the ICE mechanism and the BUNDLE extension, the offerer MUST assign the ICE mechanism and the BUNDLE extension, the offerer MUST assign
the same ICE candidates, associated with the "m=" line representing the same ICE candidates, associated with the "m=" line representing
the offerer BUNDLE address (selected by the answerer), to each the offerer BUNDLE address (selected by the answerer), to each
bundled "m=" line. bundled "m=" line.
11.2.5. Modifying the Session 11.2.5. Modifying the Session
When an offerer generates a subsequent offer, it assigns unique or When an offerer generates a subsequent offer, it assigns unique or
shared ICE candidates to the bundled "m=" lines, according to shared ICE candidates to the bundled "m=" lines, according to
(Section 11.1). (Section 11.1).
12. Update to RFC 3264 12. DTLS Considerations
12.1. General One or more media streams within a BUNDLE group might use the
Datagram Transport Layer Security (DTLS) protocol [RFC6347] in order
to encrypt the data, or to negotiate encryption keys if another
encryption mechanism is used to encrypt media.
When DTLS is used within a BUNDLE group, the following rules apply:
o There can only be one DTLS association [RFC6347] associated with
the BUNDLE group;
o Each usage of the DTLS association within the BUNDLE group MUST
use the same mechanism for determining which endpoints (the
offerer or answerer) becomes DTLS client and DTLS server; and
o If the DTLS client supports DTLS-SRTP [RFC5764] it MUST include
the 'use_srtp' extension [RFC5764] in the DTLS ClientHello message
[RFC5764], The client MUST include the extension even if the usage
of DTLS-SRTP is not negotiated as part of the session.
NOTE: The inclusion of the 'use_srtp' extension during the initial
DTLS handshake ensures that a DTLS renegotiation will not be required
in order to include the extension, in case DTLS-SRTP encrypted media
is added to the BUNDLE group later during the session.
13. Update to RFC 3264
13.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).
12.2. Original text of section 5.1 (2nd paragraph) of RFC 3264 13.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.
12.3. New text replacing section 5.1 (2nd paragraph) of RFC 3264 13.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.
12.4. Original text of section 8.2 (2nd paragraph) of RFC 3264 13.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.
12.5. New text replacing section 8.2 (2nd paragraph) of RFC 3264 13.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. If the stream is marked with port zero in the answer, the used. If the stream is marked with port zero in the answer, the
answer MAY omit all attributes present previously, and MAY list just answer MAY omit all attributes present previously, and MAY list just
a single media format from amongst those in the offer." a single media format from amongst those in the offer."
12.6. Original text of section 8.4 (6th paragraph) of RFC 3264 13.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.
12.7. New text replacing section 8.4 (6th paragraph) of RFC 3264 13.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.
13. RTP/RTCP extensions for identification-tag transport 14. RTP/RTCP extensions for identification-tag transport
13.1. General 14.1. General
SDP Offerers and Answerers [RFC3264] can associate identification- SDP Offerers and Answerers [RFC3264] can associate identification-
tags with "m=" lines within SDP Offers and Answers, using the tags with "m=" lines within SDP Offers and Answers, using the
procedures in [RFC5888]. Each identification-tag uniquely represents procedures in [RFC5888]. Each identification-tag uniquely represents
an "m=" line. an "m=" line.
This section defines a new RTCP SDES item [RFC3550], 'MID', which is This section defines a new RTCP SDES item [RFC3550], 'MID', which is
used to carry identification-tags within RTCP SDES packets. This used to carry identification-tags within RTCP SDES packets. This
section also defines a new RTP header extension [RFC5285], which is section also defines a new RTP header extension [RFC5285], which is
used to carry identification-tags in RTP packets. used to carry identification-tags in RTP packets.
The SDES item and RTP header extension make it possible for a The SDES item and RTP header extension make it possible for a
receiver to associate received RTCP- and RTP packets with a specific receiver to associate received RTCP- and RTP packets with a specific
"m=" line, to which the receiver has assigned an identification-tag, "m=" line, to which the receiver has assigned an identification-tag,
even if those "m=" lines are part of the same RTP session. The even if those "m=" lines are part of the same RTP session. A media
endpoint informs the remote endpoint about the identification-tag recipient informs the media sender about the identification-tag
using the procedures in [RFC5888], and the remote endpoint then associated with an "m=" line through the use of an 'mid' attribute
inserts the identification-tag in RTCP- and RTP packets sent towards [RFC5888]. The media sender then inserts the identification-tag in
the other endpoint. RTCP and RTP packets sent to the media recipient.
NOTE: This text above defines how identification-tags are carried in NOTE: This text above defines how identification-tags are carried in
SDP Offers and Answers. The usage of other signalling protocols for SDP Offers and Answers. The usage of other signalling protocols for
carrying identification-tags is not prevented, but the usage of such carrying identification-tags is not prevented, but the usage of such
protocols is outside the scope of this document. protocols is outside the scope of this document.
[RFC3550] defines general procedures regarding the RTCP transmission [RFC3550] defines general procedures regarding the RTCP transmission
interval. The RTCP MID SDES item SHOULD be sent in the first few interval. The RTCP MID SDES item SHOULD be sent in the first few
RTCP packets sent on joining the session, and SHOULD be sent RTCP packets sent on joining the session, and SHOULD be sent
regularly thereafter. The exact number of RTCP packets in which this regularly thereafter. The exact number of RTCP packets in which this
skipping to change at page 26, line 42 skipping to change at page 27, line 42
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 identification-tag. of the identification-tag.
For robustness purpose, endpoints need to be prepared for situations For robustness purpose, endpoints need to be prepared for situations
where the reception of the identification-tag is delayed, and SHOULD where the reception of the identification-tag is delayed, and SHOULD
NOT terminate sessions in such cases, as the identification-tag is NOT terminate sessions in such cases, as the identification-tag is
likely to arrive soon. likely to arrive soon.
13.2. RTCP MID SDES Item 14.2. RTCP MID SDES Item
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MID=TBD | length | identification-tag ... | MID=TBD | length | identification-tag ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The identification-tag payload is UTF-8 encoded, as in SDP. The identification-tag payload is UTF-8 encoded, as in SDP.
The identification-tag is not zero terminated. The identification-tag is not zero terminated.
[RFC EDITOR NOTE: Please replace TBD with the assigned SDES [RFC EDITOR NOTE: Please replace TBD with the assigned SDES
identifier value.] identifier value.]
13.3. RTP MID Header Extension 14.3. RTP MID Header Extension
The payload, containing the identification-tag, of the RTP MID header The payload, containing the identification-tag, 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 identification-tag payload is UTF-8 byte header [RFC5285]. The identification-tag payload is UTF-8
encoded, as in SDP. encoded, as in SDP.
The identification-tag is not zero terminated. Note, that set of The identification-tag is not zero terminated. Note, that set of
header extensions included in the packet needs to be padded to the header extensions included in the packet needs to be padded to the
next 32-bit boundary using zero bytes [RFC5285]. next 32-bit boundary using zero bytes [RFC5285].
skipping to change at page 27, line 36 skipping to change at page 28, line 36
encoding media. encoding media.
It is recommended that the identification-tag is kept short. Due to It is recommended that the identification-tag is kept short. Due to
the properties of the RTP header extension mechanism, when using the the properties of the RTP header extension mechanism, when using the
one-byte header, a tag that is 1-3 bytes will result in that a one-byte header, a tag that is 1-3 bytes will result in that a
minimal number of 32-bit words are used for the RTP header extension, minimal number of 32-bit words are used for the RTP header extension,
in case no other header extensions are included at the same time. in case no other header extensions are included at the same time.
Note, do take into account that some single characters when UTF-8 Note, do take into account that some single characters when UTF-8
encoded will result in multiple octets. encoded will result in multiple octets.
14. IANA Considerations 15. IANA Considerations
14.1. New SDES item 15.1. New SDES item
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this
document.] document.]
[RFC EDITOR NOTE: Please replace TBD with the assigned SDES [RFC EDITOR NOTE: Please replace TBD with the assigned SDES
identifier value.] identifier value.]
This document adds the MID SDES item to the IANA "RTCP SDES item This document adds the MID SDES item to the IANA "RTCP SDES item
types" registry as follows: types" registry as follows:
Value: TBD Value: TBD
Abbrev.: MID Abbrev.: MID
Name: Media Identification Name: Media Identification
Reference: RFCXXXX Reference: RFCXXXX
14.2. New RTP Header Extension URI 15.2. New RTP Header Extension URI
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this
document.] document.]
This document defines a new extension URI in the RTP 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
14.3. New SDP Attribute 15.3. New SDP Attribute
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this
document.] document.]
This document defines a new SDP media-level attribute, 'bundle-only', This document defines a new SDP media-level attribute, 'bundle-only',
according to the following data: according to the following data:
Attribute name: bundle-only Attribute name: bundle-only
Type of attribute: media Type of attribute: media
Subject to charset: No Subject to charset: No
Purpose: Request a media description to be accepted Purpose: Request a media description to be accepted
in the answer only if kept within a BUNDLE in the answer only if kept within a BUNDLE
group by the answerer. group by the answerer.
Appropriate values: N/A Appropriate values: N/A
Contact name: Christer Holmberg Contact name: Christer Holmberg
Contact e-mail: christer.holmberg@ericsson.com Contact e-mail: christer.holmberg@ericsson.com
Reference: RFCXXXX Reference: RFCXXXX
15. Security Considerations 15.4. New SDP Group Semantics
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this
document.]
This document registers the following semantics with IANA in the
"Semantics for the "group" SDP Attribute" subregistry (under the
"Session Description Protocol (SDP) Parameters" registry:
Semantics Token Reference
------------------------------------- ------ ---------
Media bundling BUNDLE [RFCXXXX]
16. Security Considerations
The security considerations defined in [RFC3264] and [RFC5888] apply The security considerations defined in [RFC3264] and [RFC5888] apply
to the BUNDLE extension. Bundle does not change which information to the BUNDLE extension. Bundle does not change which information
flows over the network but only changes which ports that information flows over the network but only changes which ports that information
is flowing on and thus has very little impact on the security of the is flowing on and thus has very little impact on the security of the
RTP sessions. RTP sessions.
When the BUNDLE extension is used, a single set of security When the BUNDLE extension is used, a single set of security
credentials might be used for all media streams associated with a credentials might be used for all media streams associated with a
BUNDLE group. BUNDLE group.
When the BUNDLE extension is used, the number of SSRC values within a When the BUNDLE extension is used, the number of SSRC values within a
single RTP session increases, which increases the risk of SSRC single RTP session increases, which increases the risk of SSRC
collision. [RFC4568] describes how SSRC collision may weaken SRTP collision. [RFC4568] describes how SSRC collision may weaken SRTP
and SRTCP encryption in certain situations. and SRTCP encryption in certain situations.
16. Examples 17. Examples
16.1. Example: Bundle Address Selection 17.1. Example: Bundle Address Selection
The example below shows: The example below shows:
o 1. An 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 answer, in which the answerer selects the offerer BUNDLE o 2. An answer, in which the answerer selects the offerer BUNDLE
address, and in which selects its own BUNDLE address (the answerer address, and in which selects its own BUNDLE address (the answerer
BUNDLE address) and assigns it each bundled "m=" line within the BUNDLE address) and assigns it each bundled "m=" line within the
BUNDLE group. BUNDLE group.
skipping to change at page 31, line 5 skipping to change at page 32, line 5
b=AS:200 b=AS:200
a=mid:foo a=mid:foo
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 20000 RTP/AVP 32 m=video 20000 RTP/AVP 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
16.2. Example: BUNDLE Extension Rejected 17.2. Example: BUNDLE Extension Rejected
The example below shows: The example below shows:
o 1. An 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 answer, in which the answerer rejects the offered BUNDLE o 2. An answer, in which the answerer rejects the offered BUNDLE
group, and assigns a unique addresses to each "m=" line (following group, and assigns a unique addresses to each "m=" line (following
normal RFC 3264 procedures). normal RFC 3264 procedures).
skipping to change at page 32, line 41 skipping to change at page 33, line 41
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
16.3. Example: Offerer Adds A Media Description To A BUNDLE Group 17.3. Example: Offerer Adds A Media Description To A BUNDLE Group
The example below shows: The example below shows:
o 1. A subsequent offer (the BUNDLE group has been created as part o 1. A subsequent offer (the BUNDLE group has been created as part
of a previous offer/answer transaction), in which the offerer adds of a previous offer/answer transaction), in which the offerer adds
a new "m=" line, represented by the "zen" identification-tag, to a a new "m=" line, represented by the "zen" identification-tag, to a
previously negotiated BUNDLE group, assigns a unique address to previously negotiated BUNDLE group, assigns a unique address to
the added "m=" line, and assigns the previously selected offerer the added "m=" line, and assigns the previously selected offerer
BUNDLE address to each of the other bundled "m=" lines within the BUNDLE address to each of the other bundled "m=" lines within the
BUNDLE group. BUNDLE group.
skipping to change at page 34, line 16 skipping to change at page 35, line 16
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 20000 RTP/AVP 66 m=video 20000 RTP/AVP 66
b=AS:1000 b=AS:1000
a=mid:zen a=mid:zen
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
16.4. Example: Offerer Moves A Media Description Out Of A BUNDLE Group 17.4. Example: Offerer Moves A Media Description Out Of A BUNDLE Group
The example below shows: The example below shows:
o 1. A subsequent offer (the BUNDLE group has been created as part o 1. A subsequent offer (the BUNDLE group has been created as part
of a previous offer/answer transaction), in which the offerer of a previous offer/answer transaction), in which the offerer
moves a bundled "m=" line out of a BUNDLE group, assigns a unique moves a bundled "m=" line out of a BUNDLE group, assigns a unique
address to the moved "m=" line, and assigns the offerer BUNDLE address to the moved "m=" line, and assigns the offerer BUNDLE
address to each other bundled "m=" line within the BUNDLE group. address to each other bundled "m=" line within the BUNDLE group.
o 2. An answer, in which the answerer moves the "m=" line out of o 2. An answer, in which the answerer moves the "m=" line out of
skipping to change at page 35, line 35 skipping to change at page 36, line 35
m=video 20000 RTP/AVP 32 m=video 20000 RTP/AVP 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 60000 RTP/AVP 66 m=video 60000 RTP/AVP 66
b=AS:1000 b=AS:1000
a=mid:zen a=mid:zen
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
16.5. Example: Offerer Disables A Media Description Within A BUNDLE 17.5. Example: Offerer Disables A Media Description Within A BUNDLE
Group Group
The example below shows: The example below shows:
o 1. A subsequent offer (the BUNDLE group has been created as part o 1. A subsequent offer (the BUNDLE group has been created as part
of a previous offer/answer transaction), in which the offerer of a previous offer/answer transaction), in which the offerer
disables a bundled "m=" line within BUNDLE group, assigns a zero disables a bundled "m=" line within BUNDLE group, assigns a zero
port number to the disabled "m=" line, and assigns the offerer port number to the disabled "m=" line, and assigns the offerer
BUNDLE address to each of the other bundled "m=" lines within the BUNDLE address to each of the other bundled "m=" lines within the
BUNDLE group. BUNDLE group.
skipping to change at page 37, line 8 skipping to change at page 38, line 8
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 20000 RTP/AVP 32 m=video 20000 RTP/AVP 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 0 RTP/AVP 66 m=video 0 RTP/AVP 66
a=mid:zen a=mid:zen
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
17. Acknowledgements 18. Acknowledgements
The usage of the SDP grouping extension for negotiating bundled media The usage of the SDP grouping extension for negotiating bundled media
is based on a similar alternatives proposed by Harald Alvestrand and is based on a similar alternatives proposed by Harald Alvestrand and
Cullen Jennings. The BUNDLE extension described in this document is Cullen Jennings. The BUNDLE extension described in this document is
based on the different alternative proposals, and text (e.g. SDP based on the different alternative proposals, and text (e.g. SDP
examples) have been borrowed (and, in some cases, modified) from examples) have been borrowed (and, in some cases, modified) from
those alternative proposals. those alternative proposals.
The SDP examples are also modified versions from the ones in the The SDP examples are also modified versions from the ones in the
Alvestrand proposal. Alvestrand proposal.
Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas Thanks to Paul Kyzivat, Martin Thomson, Flemming Andreasen, Thomas
Stach and Ari Keraenen for taking the time to read the text along the Stach, Ari Keraenen, Adam Roach, Christian Groves, Roman Shpount,
way, and providing useful feedback. Suhas Nandakumar, Nils Ohlmeier, Jens Guballa, Raju Makaraju and
Justin Uberti for reading the text, and providing useful feedback.
18. Change Log Thanks to Magnus Westerlund, Colin Perkins and Jonathan Lennox for
providing help and text on the RTP/RTCP procedures.
Thanks to Spotify for providing music for the countless hours of
document editing.
19. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing] [RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-18 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-18
o - Changes based on agreements at IETF#92 o - DTLS Considerations section added.
o - BUNDLE semantics added to the IANA Considerations
o - Changes based on WGLC comments from Adam Roach
o -- http://www.ietf.org/mail-archive/web/mmusic/current/
msg14673.html
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-18
o - Changes based on agreements at IETF#92
o -- BAS Offer removed, based on agreement at IETF#92. o -- BAS Offer removed, based on agreement at IETF#92.
o -- Procedures regarding usage of SDP "b=" line is replaced with a o -- Procedures regarding usage of SDP "b=" line is replaced with a
reference to to draft-ietf-mmusic-sdp-mux-attributes. reference to to draft-ietf-mmusic-sdp-mux-attributes.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-17 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-17
o - Editorial changes based on comments from Magnus Westerlund. o - Editorial changes based on comments from Magnus Westerlund.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-16 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-16
skipping to change at page 42, line 30 skipping to change at page 44, line 5
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.
19. References 20. References
19.1. Normative References 20.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, 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.
skipping to change at page 43, line 10 skipping to change at page 44, line 33
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.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-08 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-08
(work in progress), January 2015. (work in progress), January 2015.
19.2. Informative References 20.2. Informative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[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.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session
Description Protocol (SDP) Security Descriptions for Media Description Protocol (SDP) Security Descriptions for Media
Streams", RFC 4568, July 2006. Streams", RFC 4568, July 2006.
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",
BCP 131, RFC 4961, July 2007.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April Traversal for Offer/Answer Protocols", RFC 5245, April
2010. 2010.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, June 2009. (SDP)", RFC 5576, June 2009.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.
[RFC7160] Petit-Huguenin, M. and G. Zorn, "Support for Multiple [RFC7160] Petit-Huguenin, M. and G. Zorn, "Support for Multiple
Clock Rates in an RTP Session", RFC 7160, April 2014. Clock Rates in an RTP Session", RFC 7160, April 2014.
[I-D.ietf-mmusic-trickle-ice] [I-D.ietf-mmusic-trickle-ice]
Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE: Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE:
Incremental Provisioning of Candidates for the Interactive Incremental Provisioning of Candidates for the Interactive
Connectivity Establishment (ICE) Protocol", draft-ietf- Connectivity Establishment (ICE) Protocol", draft-ietf-
mmusic-trickle-ice-02 (work in progress), January 2015. mmusic-trickle-ice-02 (work in progress), January 2015.
Appendix A. Design Considerations Appendix A. Design Considerations
 End of changes. 76 change blocks. 
165 lines changed or deleted 228 lines changed or added

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