draft-ietf-mmusic-sdp-bundle-negotiation-36.txt   draft-ietf-mmusic-sdp-bundle-negotiation-37.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: April 30, 2017 C. Jennings Expires: October 2, 2017 C. Jennings
Cisco Cisco
October 27, 2016 March 31, 2017
Negotiating Media Multiplexing Using the Session Description Protocol Negotiating Media Multiplexing Using the Session Description Protocol
(SDP) (SDP)
draft-ietf-mmusic-sdp-bundle-negotiation-36.txt draft-ietf-mmusic-sdp-bundle-negotiation-37.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, specified by multiple SDP media referred to as bundled media, specified by multiple SDP media
descriptions ("m=" lines). descriptions ("m=" lines).
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 April 30, 2017. This Internet-Draft will expire on October 2, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 24 skipping to change at page 3, line 24
8.5.2. Adding a media description to a BUNDLE group . . . . 17 8.5.2. Adding a media description to a BUNDLE group . . . . 17
8.5.3. Moving A Media Description Out Of A BUNDLE Group . . 17 8.5.3. Moving A Media Description Out Of A BUNDLE Group . . 17
8.5.4. Disabling A Media Description In A BUNDLE Group . . . 18 8.5.4. Disabling A Media Description In A BUNDLE Group . . . 18
9. Protocol Identification . . . . . . . . . . . . . . . . . . . 18 9. Protocol Identification . . . . . . . . . . . . . . . . . . . 18
9.1. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 19 9.1. STUN, DTLS, SRTP . . . . . . . . . . . . . . . . . . . . 19
10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 19 10. RTP Considerations . . . . . . . . . . . . . . . . . . . . . 19
10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 19 10.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 19
10.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . 20 10.1.1. Payload Type (PT) Value Reuse . . . . . . . . . . . 20
10.2. Associating RTP/RTCP Streams With Correct SDP Media 10.2. Associating RTP/RTCP Streams With Correct SDP Media
Description . . . . . . . . . . . . . . . . . . . . . . 20 Description . . . . . . . . . . . . . . . . . . . . . . 20
10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 22 10.3. RTP/RTCP Multiplexing . . . . . . . . . . . . . . . . . 25
10.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . 22 10.3.1. SDP Offer/Answer Procedures . . . . . . . . . . . . 26
11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 24 11. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 28
11.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 25 11.1. SDP Offer/Answer Procedures . . . . . . . . . . . . . . 28
11.1.1. Generating the Initial SDP Offer . . . . . . . . . . 25 11.1.1. Generating the Initial SDP Offer . . . . . . . . . . 29
11.1.2. Generating the SDP Answer . . . . . . . . . . . . . 25 11.1.2. Generating the SDP Answer . . . . . . . . . . . . . 29
11.1.3. Offerer Processing of the SDP Answer . . . . . . . . 26 11.1.3. Offerer Processing of the SDP Answer . . . . . . . . 29
11.1.4. Modifying the Session . . . . . . . . . . . . . . . 26 11.1.4. Modifying the Session . . . . . . . . . . . . . . . 29
12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 26 12. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 30
13. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 27 13. RTP Header Extensions Consideration . . . . . . . . . . . . . 30
13.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 27 14. Update to RFC 3264 . . . . . . . . . . . . . . . . . . . . . 30
13.2. New text replacing section 5.1 (2nd paragraph) of RFC 14.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 31
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 27 14.2. New text replacing section 5.1 (2nd paragraph) of RFC
13.3. Original text of section 8.2 (2nd paragraph) of RFC 3264 28 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 31
13.4. New text replacing section 8.2 (2nd paragraph) of RFC 14.3. Original text of section 8.2 (2nd paragraph) of RFC 3264 31
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 28 14.4. New text replacing section 8.2 (2nd paragraph) of RFC
13.5. Original text of section 8.4 (6th paragraph) of RFC 3264 28 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 31
13.6. New text replacing section 8.4 (6th paragraph) of RFC 14.5. Original text of section 8.4 (6th paragraph) of RFC 3264 32
3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 28 14.6. New text replacing section 8.4 (6th paragraph) of RFC
14. RTP/RTCP extensions for identification-tag transport . . . . 29 3264 . . . . . . . . . . . . . . . . . . . . . . . . . . 32
14.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 30 15. RTP/RTCP extensions for identification-tag transport . . . . 32
14.2. RTP SDES Header Extension For MID . . . . . . . . . . . 30 15.1. RTCP MID SDES Item . . . . . . . . . . . . . . . . . . . 33
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 15.2. RTP SDES Header Extension For MID . . . . . . . . . . . 34
15.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 31 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
15.2. New RTP SDES Header Extension URI . . . . . . . . . . . 31 16.1. New SDES item . . . . . . . . . . . . . . . . . . . . . 35
15.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 32 16.2. New RTP SDES Header Extension URI . . . . . . . . . . . 35
15.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 32 16.3. New SDP Attribute . . . . . . . . . . . . . . . . . . . 35
16. Security Considerations . . . . . . . . . . . . . . . . . . . 32 16.4. New SDP Group Semantics . . . . . . . . . . . . . . . . 36
17. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 33
17.1. Example: Bundle Address Selection . . . . . . . . . . . 33 17. Security Considerations . . . . . . . . . . . . . . . . . . . 36
17.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 35 18. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 38
17.3. Example: Offerer Adds A Media Description To A BUNDLE 18.1. Example: Bundle Address Selection . . . . . . . . . . . 38
Group . . . . . . . . . . . . . . . . . . . . . . . . . 36 18.2. Example: BUNDLE Extension Rejected . . . . . . . . . . . 40
17.4. Example: Offerer Moves A Media Description Out Of A 18.3. Example: Offerer Adds A Media Description To A BUNDLE
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 38 Group . . . . . . . . . . . . . . . . . . . . . . . . . 41
17.5. Example: Offerer Disables A Media Description Within A 18.4. Example: Offerer Moves A Media Description Out Of A
BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 40 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 43
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 18.5. Example: Offerer Disables A Media Description Within A
19. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 42 BUNDLE Group . . . . . . . . . . . . . . . . . . . . . . 45
20. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46
20.1. Normative References . . . . . . . . . . . . . . . . . . 50 20. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 47
20.2. Informative References . . . . . . . . . . . . . . . . . 52 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 55
Appendix A. Design Considerations . . . . . . . . . . . . . . . 52 21.1. Normative References . . . . . . . . . . . . . . . . . . 55
A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 53 21.2. Informative References . . . . . . . . . . . . . . . . . 57
A.2. Usage of port number value zero . . . . . . . . . . . . . 54 Appendix A. Design Considerations . . . . . . . . . . . . . . . 58
A.3. B2BUA And Proxy Interoperability . . . . . . . . . . . . 55 A.1. UA Interoperability . . . . . . . . . . . . . . . . . . . 59
A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 55 A.2. Usage of port number value zero . . . . . . . . . . . . . 61
A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 55 A.3. B2BUA And Proxy Interoperability . . . . . . . . . . . . 61
A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 56 A.3.1. Traffic Policing . . . . . . . . . . . . . . . . . . 62
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 A.3.2. Bandwidth Allocation . . . . . . . . . . . . . . . . 62
A.4. Candidate Gathering . . . . . . . . . . . . . . . . . . . 62
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63
1. Introduction 1. Introduction
When multimedia communications are established, each 5-tuple reserved When multimedia communications are established, each 5-tuple reserved
for an individual media stream consume additional resources for an individual media stream consume additional resources
(especially when Interactive Connectivity Establishment (ICE) (especially when Interactive Connectivity Establishment (ICE)
[RFC5245] is used). For this reason, it is attractive to use a [RFC5245] is used). For this reason, it is attractive to use a
5-tuple for multiple media streams. 5-tuple for multiple media streams.
This specification defines a way to use a single address:port This specification defines a way to use a single address:port
skipping to change at page 11, line 31 skipping to change at page 11, line 31
o Associate an SDP 'bundle-only' attribute [Section 8.2.1] with the o Associate an SDP 'bundle-only' attribute [Section 8.2.1] 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.4]. line [Section 8.5.4].
[Section 17.1] shows an example of an initial offer. [Section 18.1] shows an example of an initial offer.
8.2.1. Suggesting the offerer BUNDLE address 8.2.1. Suggesting the offerer BUNDLE address
In the offer, the address associated with the "m=" line associated In the offer, the address associated with the "m=" line associated
with the offerer BUNDLE-tag indicates the address that the offerer with the offerer BUNDLE-tag indicates the address that the offerer
suggests as the offerer BUNDLE address. suggests as the offerer BUNDLE address.
The "m=" line associated with the offerer BUNDLE-tag MUST NOT contain The "m=" line associated with the offerer BUNDLE-tag MUST NOT contain
a zero port value or an SDP 'bundle-only' attribute. a zero port value or an SDP 'bundle-only' attribute.
skipping to change at page 14, line 10 skipping to change at page 14, line 10
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.3] to each bundled "m=" line in out of a BUNDLE group [Section 8.3.3] to each bundled "m=" line in
the offer when creating the answer. the offer when creating the answer.
[Section 17.1] shows an example of an offerer BUNDLE address [Section 18.1] shows an example of an offerer BUNDLE address
selection. selection.
8.3.2. Answerer Selection of Answerer BUNDLE Address 8.3.2. Answerer Selection of Answerer BUNDLE Address
When the answerer selects a BUNDLE address for itself, referred to as When the answerer selects a BUNDLE address for itself, referred to as
the answerer BUNDLE address, it MUST associate that address with each the answerer BUNDLE address, it MUST associate that address with 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 associate the answerer BUNDLE address with an The answerer MUST NOT associate the answerer BUNDLE address with an
"m=" line that is not within the BUNDLE group, or to an "m=" line "m=" line that is not within the BUNDLE group, or to an "m=" line
that is within another BUNDLE group. that is within another BUNDLE group.
[Section 17.1] shows an example of an answerer BUNDLE address [Section 18.1] shows an example of an answerer BUNDLE address
selection. selection.
8.3.3. Moving A Media Description Out Of A BUNDLE Group 8.3.3. Moving A Media Description Out Of A BUNDLE Group
When an answerer wants to move an "m=" line out of a BUNDLE group, it When an answerer wants to move an "m=" line out of a BUNDLE group, it
MUST first check the following criteria: MUST first check the following criteria:
o In the corresponding offer, the "m=" line is associated with a o In the corresponding offer, the "m=" line is associated with a
shared address (e.g. a previously selected offerer BUNDLE shared address (e.g. a previously selected offerer BUNDLE
address); or address); or
skipping to change at page 17, line 39 skipping to change at page 17, line 39
If the offerer associates a unique address with the added "m=" line, If the offerer associates a unique address with the added "m=" line,
and if the offerer suggests that address as the new offerer BUNDLE and if the offerer suggests that address as the new offerer BUNDLE
address [Section 8.5.1], the offerer BUNDLE-tag MUST represent the address [Section 8.5.1], the offerer BUNDLE-tag MUST represent the
added "m=" line [Section 8.2.1]. added "m=" line [Section 8.2.1].
If the offerer associates a new suggested offerer BUNDLE address with If the offerer associates a new suggested offerer BUNDLE address with
each bundled "m=" line [Section 8.5.1], including the added "m=" each bundled "m=" line [Section 8.5.1], including the added "m="
line, the offerer BUNDLE-tag MAY represent the added "m=" line line, the offerer BUNDLE-tag MAY represent the added "m=" line
[Section 8.2.1]. [Section 8.2.1].
[Section 17.3] shows an example where an offerer sends an offer in [Section 18.3] shows an example where an offerer sends an offer in
order to add a bundled "m=" line to a BUNDLE group. order to add a bundled "m=" line to a BUNDLE group.
8.5.3. Moving A Media Description Out Of A BUNDLE Group 8.5.3. Moving A Media Description Out Of A BUNDLE Group
When an offerer generates an offer, in which it wants to move a When an offerer generates an offer, in which it wants to move a
bundled "m=" line out of a BUNDLE group it was added to in a previous bundled "m=" 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 associate a unique address with the "m=" line; and o MUST associate a unique address with the "m=" line; and
o MUST NOT place the identification-tag associated with the "m=" o MUST NOT place the identification-tag associated with the "m="
skipping to change at page 18, line 16 skipping to change at page 18, line 16
associated with the BUNDLE group. associated with the BUNDLE group.
NOTE: If the removed "m=" line is associated with the previously NOTE: If the removed "m=" line is associated with the previously
selected BUNDLE-tag, the offerer needs to suggest a new BUNDLE-tag selected BUNDLE-tag, the offerer needs to suggest a new BUNDLE-tag
[Section 8.2.1]. [Section 8.2.1].
NOTE: If an "m=" line, when being moved out of a BUNDLE group, is NOTE: If an "m=" 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.2] to the "m=" line. [Section 8.5.2] to the "m=" line.
[Section 17.4] shows an example of an offer for moving an "m=" line [Section 18.4] shows an example of an offer for moving an "m=" line
out of a BUNDLE group. out of a BUNDLE group.
8.5.4. Disabling A Media Description In A BUNDLE Group 8.5.4. Disabling A Media Description In A BUNDLE Group
When an offerer generates an offer, in which it wants to disable a When an offerer generates an offer, in which it wants to disable a
bundled "m=" line (added to the BUNDLE group in a previous offer/ bundled "m=" line (added to the BUNDLE group in a previous offer/
answer transaction), the offerer: answer transaction), the offerer:
o MUST associate an address with a zero port value with the "m=" o MUST associate an address with a zero port value with the "m="
line, following the procedures in [RFC4566]; and line, 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 17.5] shows an example of an offer for disabling an "m=" [Section 18.5] shows an example of an offer for disabling an "m="
line within a BUNDLE group. line within a BUNDLE group.
9. Protocol Identification 9. Protocol Identification
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 received data with particular protocol combination, how to associate received data with
the correct protocol. the correct protocol.
skipping to change at page 20, line 39 skipping to change at page 20, line 39
payload type number MUST share an identical codec configuration. payload type number MUST share an identical codec configuration.
This means that the codecs MUST share the same media type, encoding This means that the codecs MUST share the same media type, encoding
name, clock rate and any parameter that can affect the codec name, clock rate and any parameter that can affect the codec
configuration and packetization. configuration and packetization.
[I-D.ietf-mmusic-sdp-mux-attributes] lists SDP attributes, whose [I-D.ietf-mmusic-sdp-mux-attributes] lists SDP attributes, whose
attribute values must be identical for all codecs that use the same attribute values must be identical for all codecs that use the same
payload type value. payload type value.
10.2. Associating RTP/RTCP Streams With Correct SDP Media Description 10.2. Associating RTP/RTCP Streams With Correct SDP Media Description
As described in [RFC3550], RTP/RTCP packets are associated with RTP NOTE: The text in this section is copied from Appendix B of JSEP.
The community has not yet agreed on the text.
As described in [RFC3550], RTP packets are associated with RTP
streams [RFC7656]. Each RTP stream is identified by an SSRC value, streams [RFC7656]. Each RTP stream is identified by an SSRC value,
and each RTP/RTCP packet carries an SSRC value that is used to and each RTP packet includes an SSRC field that is used to associate
associate the packet with the correct RTP stream (an RTCP packet can the packet with the correct RTP stream. RTCP packets also use SSRCs
carry multiple SSRC values, and might therefore be associated with to identify which RTP streams the packet relates to. However, a RTCP
multiple RTP streams). packet can contain multiple SSRC fields, in the course of providing
feedback or reports on different RTP streams, and therefore can be
associated with multiple such streams.
In order to be able to process received RTP/RTCP packets correctly it In order to be able to process received RTP/RTCP packets correctly,
must be possible to associate an RTP stream with the correct "m=" it must be possible to associate an RTP stream with the correct "m="
line, as the "m=" line and SDP attributes associated with the "m=" line, as the "m=" line and SDP attributes associated with the "m="
line contain information needed to process the packets. line contain information needed to process the packets.
As all RTP streams associated with a BUNDLE group are using the same As all RTP streams associated with a BUNDLE group use the same
address:port combination for sending and receiving RTP/RTCP packets, address:port combination for sending and receiving RTP/RTCP packets,
the local address:port combination cannot be used to associate an RTP the local address:port combination cannot be used to associate an RTP
stream with the correct "m=" line. In addition, multiple RTP streams stream with the correct "m=" line. In addition, multiple RTP streams
might be associated with the same "m=" line. might be associated with the same "m=" line.
Also, as described in [Section 10.1.1], the same payload type value
might be used by multiple RTP streams, in which case the payload type
value cannot be used to associate an RTP stream with the correct "m="
line.
An offerer and answerer can inform each other which SSRC values they An offerer and answerer can inform each other which SSRC values they
will use for an RTP stream by using the SDP 'ssrc' attribute will use for an RTP stream by using the SDP 'ssrc' attribute
[RFC5576]. However, an offerer will not know which SSRC values the [RFC5576]. However, an offerer will not know which SSRC values the
answerer will use until the offerer has received the answer providing answerer will use until the offerer has received the answer providing
that information. Due to this, before the offerer has received the that information. Due to this, before the offerer has received the
answer, the offerer will not be able to associate an RTP stream with answer, the offerer will not be able to associate an RTP stream with
the correct "m=" line using the SSRC value associated with the RTP the correct "m=" line using the SSRC value associated with the RTP
stream. In addition, the offerer and answerer may start using new stream. In addition, the offerer and answerer may start using new
SSRC values mid-session, without informing each other using the SDP SSRC values mid-session, without informing each other using the SDP
'ssrc' attribute. 'ssrc' attribute.
In order for an offerer and answerer to always be able to associate In order for an offerer and answerer to always be able to associate
an RTP stream with the correct "m=" line, the offerer and answerer an RTP stream with the correct "m=" line, the offerer and answerer
using the BUNDLE extension MUST support the mechanism defined in using the BUNDLE extension MUST support the mechanism defined in
Section 14, where the offerer and answerer insert the identification- section 14, where the offerer and answerer insert the identification-
tag (provided by the remote peer) associated with an "m=" line in RTP tag associated with an "m=" line (provided by the remote peer) into
and RTCP packets associated with a BUNDLE group. RTP and RTCP packets associated with a BUNDLE group.
The mapping from an SSRC to an identification-tag is carried in RTCP When using this mechanism, the mapping from an SSRC to an
SDES packets or in RTP header extensions (Section 14). Since a identification-tag is carried in RTP header extensions or RTCP SDES
compound RTCP packet can contain multiple RTCP SDES packets, and each packets, as specified in section 14. Since a compound RTCP packet
RTCP SDES packet can contain multiple chunks, an RTCP packet can can contain multiple RTCP SDES packets, and each RTCP SDES packet can
contain several SSRC to identification-tag mappings. The offerer and contain multiple chunks, a single RTCP packet can contain several
answerer maintain tables mapping RTP streams identified by SSRC, to SSRC to identification-tag mappings. The offerer and answerer
a€œm=a€œ lines identified by the identification- maintain tables used for routing that are updated each time an RTP/
tag. These tables are updated each time an RTP/RTCP packet RTCP packet contains new information that affects how packets should
containing one or more mappings from SSRC to identification-tag is be routed.
received. Note that the mapping from SSRC to identification-tag can
change at any time during an RTP session. Once an offerer or
answerer recieve an RTP/RTCP packet carrying an identification-tag
and an SSRC value (an RTCP packet might carry multiple
identification-tags and SSRC values), it creates a mapping between
the SSRC value and the identification-tag, in order to associate the
RTP stream with the "m=" line associated with the identification-tag.
Note that the mapping might change mid-session if, for a given SSRC
value, a different identification-tag is provided in an RTP/RTCP
packet.
If an offerer and answerer is not able to associate an RTP stream However, some implementations of may not include this identification-
with an "m=" line (using the mechanisms described in this section, or tag in their RTP and RTCP traffic when using the BUNDLE mechanism,
using other appropriate mechanism, e.g, based on the payload type and instead use a payload type based mechanism for demuxing. In this
value if it is unique to a single "m=" line), it MUST either drop the situation, each "m=" line MUST use unique payload type values, in
RTP/RTCP packets associated with the RTP stream, or process them in order for the payload type to be a reliable indicator of the relevant
an application specific manner, once non-stream specific processing "m=" line for the RTP stream. Note that when using payload type
(e.g., related to congestion control) of the packets have occurred. based demuxing, an SSRC will be mapped to an "m=" line by the first
Note that RTCP packets can report on multiple RTP streams. packet with that SSRC, and the mapping will not be changed even if
the same SSRC is received with a different payload type. In other
words, the SSRC cannot to "move" to a different "m=" line simply by
changing the payload type.
Applications can implement RTP stacks in many different ways. The
algorithm below details one way that demultiplexing can be
accomplished, but is not meant to be prescriptive about exactly how
an RTP stack needs to be implemented. Applications MAY use any
algorithm that achieves equivalent results to those described in the
algorithm below.
To prepare for demultiplexing RTP/RTCP packets to the correct "m="
line, the following steps MUST be followed for each BUNDLE group.
Construct a table mapping MID to "m=" line for each "m=" line in
this BUNDLE group. Note that an "m=" line may only have one MID.
Construct a table mapping incoming SSRC to "m=" line for each "m="
line in this BUNDLE group and for each SSRC configured for
receiving in that "m=" line.
Construct a table mapping outgoing SSRC to "m=line" for each "m="
line in this BUNDLE group and for each SSRC configured for sending
in that "m=" line.
Construct a table mapping payload type to "m=" line for each "m="
line in the BUNDLE group and for each payload type configured for
receiving in that "m=" line. If any payload type is configured
for receiving in more than one "m=" line in the BUNDLE group, do
not it include it in the table, as it cannot be used to uniquely
identify a "m=" line.
Note that for each of these tables, there can only be one mapping
for any given key (MID, SSRC, or PT). In other words, the tables
are not multimaps.
As "m=" lines are added or removed from the BUNDLE groups, or their
configurations are changed, the tables above MUST also be updated.
For each RTP packet received, the following steps MUST be followed to
route the packet to the correct "m=" section within a BUNDLE group.
Note that the phrase 'deliver a packet to the "m=" line' means to
further process the packet as would normally happen with RTP/RTCP, if
it were received on a transport associated with that "m=" line
outside of a BUNDLE group (i.e., if the "m=" line were not BUNDLEd),
including dropping an RTP packet if the packet's PT does not match
any PT in the "m=" line.
If the packet has a MID, and that MID is not in the table mapping
MID to "m=" line, drop the packet and stop.
If the packet has a MID, and the packet's extended sequence number
is greater than that of the last MID update, as discussed in
[RFC7941], Section 4.2.6, update the incoming SSRC mapping table
to include an entry that maps the packet's SSRC to the "m=" line
for that MID.
If the packet's SSRC is in the incoming SSRC mapping table, check
that the packet's PT matches a PT included on the associated "m="
line. If so, route the packet to that associated "m=" line and
stop; otherwise drop the packet and stop.
If the packet's payload type is in the payload type table, update
the the incoming SSRC mapping table to include an entry that maps
the packet's SSRC to the "m=" line for that payload type. In
addition, route the packet to the associated "m=" line and stop.
Otherwise, drop the packet.
For each RTCP packet received (including each RTCP packet that is
part of a compound RTCP packet), the packet MUST be routed to the
"m=" line for the RTP streams it contains information about. This
routing is type-dependent, as each kind of RTCP packet has its own
mechanism for associating it with the relevant RTP streams.
Packets for which no appropriate "m=" line can be identified (i.e.,
for unknown RTP streams) are not relevant in the context of this
algorithm and MAY be dropped. This situation may occur with certain
multiparty RTP topologies.
Rules for handling the various types of RTCP packets are explained
below.
If the packet is of type SDES, for each chunk in the packet whose
SSRC is found in the incoming SSRC table, deliver a copy of the
packet to the "m=" line associated with that SSRC. In addition,
for any SDES MID items contained in these chunks, if the MID is
found in the table mapping MID to "m=" line, update the incoming
SSRC table to include an entry that maps the chunk's SSRC to the
"m=" line associated with that MID, unless the packet is older
than the packet that most recently updated the mapping for this
SSRC, as discussed in [RFC7941], Section 4.2.6.
Note that if an SDES packet is received as part of a compound RTCP
packet, the SSRC to "m=" line mapping may not exist until the SDES
packet is handled (e.g., in the case where RTCP for a source is
received before any RTP packets). Therefore, when processing a
compound packet, any contained SDES packet MUST be handled first.
If the packet is of type BYE, it indicates that the RTP streams
referenced in the packet are ending. Therefore, for each SSRC
indicated in the packet that is found in the incoming SSRC table,
first deliver a copy of the packet to the "m=" line associated
with that SSRC, but then remove the entry for that SSRC from the
incoming SSRC table after an appropriate delay to account for
"straggler packets", as specified in [RFC3550], Section 6.2.1.
If the packet is of type SR or RR, for each report block in the
report whose "SSRC of source" is found in the outgoing SSRC table,
deliver a copy of the RTCP packet to the "m=" line associated with
that SSRC. In addition, if the packet is of type SR, and the
sender SSRC for the packet is found in the incoming SSRC table,
deliver a copy of the packet to the "m=" line associated with that
SSRC.
If the implementation supports RTCP XR and the packet is of type
XR, as defined in [RFC3611], for each report block in the report
whose "SSRC of source" is is found in the outgoing SSRC table,
deliver a copy of the RTCP packet to the "m=" line associated with
that SSRC. In addition, if the sender SSRC for the packet is
found in the incoming SSRC table, deliver a copy of the packet to
the "m=" line associated with that SSRC.
If the packet is a feedback message of type RTPFB or PSFB, as
defined in [RFC4585], it will contain a media source SSRC, and
this SSRC is used for routing certain subtypes of feedback
messages. However, several subtypes of PSFB messages include
target SSRC(s) in a section called Feedback Control Information
(FCI). For these messages, the target SSRC(s) are used for
routing.
If the packet is a feedback message that does not include target
SSRCs in its FCI section, and the media source SSRC is found in
the outgoing SSRC table, deliver the packet to the "m=" line
associated with that SSRC. RTPFB and PSFB types that are handled
in this way include:
Generic NACK: [RFC4585] (PT=RTPFB, FMT=1).
Picture Loss Indication (PLI): [RFC4585] (PT=PSFB, FMT=1).
Slice Loss Indication (SLI): [RFC4585] (PT=PSFB, FMT=2).
Reference Picture Selection Indication (RPSI): [RFC4585]
(PT=PSFB, FMT=3).
If the packet is a feedback message that does include target
SSRC(s) in its FCI section, it can either be a request or a
notification. Requests reference a RTP stream that is being sent
by the message recipient, whereas notifications are responses to
an earlier request, and therefore reference a RTP stream that is
being received by the message recipient.
If the packet is a feedback request that includes target SSRC(s),
for each target SSRC that is found in the outgoing SSRC table,
deliver a copy of the RTCP packet to the "m=" line associated with
that SSRC. PSFB types that are handled in this way include:
Full Intra Request (FIR): [RFC5104] (PT=PSFB, FMT=4).
Temporal-Spatial Trade-off Request (TSTR): [RFC5104] (PT=PSFB,
FMT=5).
H.271 Video Back Channel Message (VBCM): [RFC5104] (PT=PSFB,
FMT=7).
Layer Refresh Request (LRR): [I-D.ietf-avtext-lrr] (PT=PSFB,
FMT=TBD).
If the packet is a feedback notification that include target
SSRC(s), for each target SSRC that is found in the incoming SSRC
table, deliver a copy of the RTCP packet to the "m=" line
associated with that SSRC. PSFB types that are handled in this
way include:
Temporal-Spatial Trade-off Notification (TSTN): [RFC5104]
(PT=PSFB, FMT=6). This message is a notification in response
to a prior TSTR.
If the packet is of type APP, the only routing information
included is the source of the packet, and therefore the packet
could be related to any existing "m=" line. Accordingly, deliver
a copy of the packet to each "m=" line.
10.3. RTP/RTCP Multiplexing 10.3. RTP/RTCP Multiplexing
Within a BUNDLE group, the offerer and answerer MUST enable RTP/RTCP Within a BUNDLE group, the offerer and answerer MUST enable RTP/RTCP
multiplexing [RFC5761] for the RTP-based media specified by the multiplexing [RFC5761] for the RTP-based media specified by the
BUNDLE group. BUNDLE group.
When RTP/RTCP multiplexing is enabled, the same address:port When RTP/RTCP multiplexing is enabled, the same address:port
combination will be used for sending all RTP packets and the RTCP combination will be used for sending all RTP packets and the RTCP
packets associated with the BUNDLE group. Each endpoint will send packets associated with the BUNDLE group. Each endpoint will send
skipping to change at page 27, line 5 skipping to change at page 30, line 37
the 'use_srtp' extension [RFC5764] in the DTLS ClientHello message the 'use_srtp' extension [RFC5764] in the DTLS ClientHello message
[RFC5764], The client MUST include the extension even if the usage [RFC5764], The client MUST include the extension even if the usage
of DTLS-SRTP is not negotiated as part of the multimedia session of DTLS-SRTP is not negotiated as part of the multimedia session
(e.g., SIP session [RFC3261]. (e.g., SIP session [RFC3261].
NOTE: The inclusion of the 'use_srtp' extension during the initial NOTE: The inclusion of the 'use_srtp' extension during the initial
DTLS handshake ensures that a DTLS renegotiation will not be required DTLS handshake ensures that a DTLS renegotiation will not be required
in order to include the extension, in case DTLS-SRTP encrypted media in order to include the extension, in case DTLS-SRTP encrypted media
is added to the BUNDLE group later during the multimedia session. is added to the BUNDLE group later during the multimedia session.
13. Update to RFC 3264 13. RTP Header Extensions Consideration
When [RFC5285] RTP header extensions are used in the context of this
specification, the identifier used for a given extension MUST
identify the same extension across all the bundled media
descriptions.
14. Update to RFC 3264
This section replaces the text of the following sections of RFC 3264: This section replaces the text of the following sections of RFC 3264:
o Section 5.1 (Unicast Streams). o Section 5.1 (Unicast Streams).
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).
13.1. Original text of section 5.1 (2nd paragraph) of RFC 3264 14.1. Original text of section 5.1 (2nd paragraph) of RFC 3264
For recvonly and sendrecv streams, the port number and address in the For recvonly and sendrecv streams, the port number and address in the
offer indicate where the offerer would like to receive the media offer indicate where the offerer would like to receive the media
stream. For sendonly RTP streams, the address and port number stream. For sendonly RTP streams, the address and port number
indirectly indicate where the offerer wants to receive RTCP reports. indirectly indicate where the offerer wants to receive RTCP reports.
Unless there is an explicit indication otherwise, reports are sent to Unless there is an explicit indication otherwise, reports are sent to
the port number one higher than the number indicated. The IP address the port number one higher than the number indicated. The IP address
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.
13.2. New text replacing section 5.1 (2nd paragraph) of RFC 3264 14.2. New text replacing section 5.1 (2nd paragraph) of RFC 3264
For recvonly and sendrecv streams, the port number and address in the For recvonly and sendrecv streams, the port number and address in the
offer indicate where the offerer would like to receive the media offer indicate where the offerer would like to receive the media
stream. For sendonly RTP streams, the address and port number stream. For sendonly RTP streams, the address and port number
indirectly indicate where the offerer wants to receive RTCP reports. indirectly indicate where the offerer wants to receive RTCP reports.
Unless there is an explicit indication otherwise, reports are sent to Unless there is an explicit indication otherwise, reports are sent to
the port number one higher than the number indicated. The IP address the port number one higher than the number indicated. The IP address
and port present in the offer indicate nothing about the source IP and port present in the offer indicate nothing about the source IP
address and source port of RTP and RTCP packets that will be sent by address and source port of RTP and RTCP packets that will be sent by
the offerer. A port number of zero in the offer by default indicates the offerer. A port number of zero in the offer by default indicates
that the stream is offered but MUST NOT be used, but an extension that the stream is offered but MUST NOT be used, but an extension
mechanism might specify different semantics for the usage of a zero mechanism might specify different semantics for the usage of a zero
port value. Furthermore, existing streams can be terminated by port value. Furthermore, existing streams can be terminated by
setting the port to zero (Section 8). In general, a port number of setting the port to zero (Section 8). In general, a port number of
zero by default indicates that the media stream is not wanted. zero by default indicates that the media stream is not wanted.
13.3. Original text of section 8.2 (2nd paragraph) of RFC 3264 14.3. 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.
13.4. New text replacing section 8.2 (2nd paragraph) of RFC 3264 14.4. 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."
13.5. Original text of section 8.4 (6th paragraph) of RFC 3264 14.5. Original text of section 8.4 (6th paragraph) of RFC 3264
RFC 2543 [10] specified that placing a user on hold was accomplished RFC 2543 [10] specified that placing a user on hold was accomplished
by setting the connection address to 0.0.0.0. Its usage for putting by setting the connection address to 0.0.0.0. Its usage for putting
a call on hold is no longer recommended, since it doesn't allow for a call on hold is no longer recommended, since it doesn't allow for
RTCP to be used with held streams, doesn't work with IPv6, and breaks RTCP to be used with held streams, doesn't work with IPv6, and breaks
with connection oriented media. However, it can be useful in an with connection oriented media. However, it can be useful in an
initial offer when the offerer knows it wants to use a particular set initial offer when the offerer knows it wants to use a particular set
of media streams and formats, but doesn't know the addresses and of media streams and formats, but doesn't know the addresses and
ports at the time of the offer. Of course, when used, the port ports at the time of the offer. Of course, when used, the port
number MUST NOT be zero, which would specify that the stream has been number MUST NOT be zero, which would specify that the stream has been
disabled. An agent MUST be capable of receiving SDP with a disabled. An agent MUST be capable of receiving SDP with a
connection address of 0.0.0.0, in which case it means that neither connection address of 0.0.0.0, in which case it means that neither
RTP nor RTCP should be sent to the peer. RTP nor RTCP should be sent to the peer.
13.6. New text replacing section 8.4 (6th paragraph) of RFC 3264 14.6. 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.
14. RTP/RTCP extensions for identification-tag transport 15. RTP/RTCP extensions for identification-tag transport
SDP Offerers and Answerers [RFC3264] can associate identification- SDP Offerers and Answerers [RFC3264] can associate identification-
tags with "m=" lines within SDP Offers and Answers, using the tags with "m=" 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 SDES header extension [RFC7941], which section also defines a new RTP SDES header extension [RFC7941], which
is used to carry the 'MID' RTCP SDES item in RTP packets. is used to carry the 'MID' RTCP SDES item in RTP packets.
skipping to change at page 30, line 10 skipping to change at page 33, line 44
in which this header extension is sent is intentionally not specified in which this header extension is sent is intentionally not specified
here, as it will depend on expected packet loss rate and loss here, as it will depend on expected packet loss rate and loss
patterns, the overhead the application can tolerate, and the patterns, the overhead the application can tolerate, and the
importance of immediate receipt of the identification-tag. importance of immediate receipt of the identification-tag.
For robustness 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.
14.1. RTCP MID SDES Item 15.1. RTCP MID SDES Item
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MID=TBD | length | identification-tag ... | MID=TBD | length | identification-tag ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The identification-tag payload is UTF-8 encoded, as in SDP. The identification-tag payload is UTF-8 encoded, 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.]
14.2. RTP SDES Header Extension For MID 15.2. RTP SDES Header Extension For MID
The payload, containing the identification-tag, of the RTP SDES The payload, containing the identification-tag, of the RTP SDES
header extension element can be encoded using either the one-byte or header extension element can be encoded using either the one-byte or
two-byte header [RFC7941]. The identification-tag payload is UTF-8 two-byte header [RFC7941]. The identification-tag payload is UTF-8
encoded, as in SDP. encoded, as in SDP.
The identification-tag is not zero terminated. Note, that the set of The identification-tag is not zero terminated. Note, that the set of
header extensions included in the packet needs to be padded to the header extensions included in the packet needs to be padded to the
next 32-bit boundary using zero bytes [RFC5285]. next 32-bit boundary using zero bytes [RFC5285].
skipping to change at page 31, line 7 skipping to change at page 34, line 46
the properties of the RTP header extension mechanism, when using the the properties of the RTP header extension mechanism, when using the
one-byte header, a tag that is 1-3 bytes will result in a minimal one-byte header, a tag that is 1-3 bytes will result in a minimal
number of 32-bit words used for the RTP SDES header extension, in number of 32-bit words used for the RTP SDES header extension, in
case no other header extensions are included at the same time. Note, case no other header extensions are included at the same time. Note,
do take into account that some single characters when UTF-8 encoded do take into account that some single characters when UTF-8 encoded
will result in multiple octets. The identification-tag MUST NOT will result in multiple octets. The identification-tag MUST NOT
contain any user information, and applications SHALL avoid generating contain any user information, and applications SHALL avoid generating
the identification-tag using a pattern that enables application the identification-tag using a pattern that enables application
identification. identification.
15. IANA Considerations 16. IANA Considerations
16.1. New SDES item
15.1. New SDES item
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this
document.] document.]
[RFC EDITOR NOTE: Please replace TBD with the assigned SDES [RFC EDITOR NOTE: Please replace TBD with the assigned SDES
identifier value.] identifier value.]
This document adds the MID SDES item to the IANA "RTP SDES item This document adds the MID SDES item to the IANA "RTP SDES item
types" registry as follows: types" registry as follows:
Value: TBD Value: TBD
Abbrev.: MID Abbrev.: MID
Name: Media Identification Name: Media Identification
Reference: RFCXXXX Reference: RFCXXXX
15.2. New RTP SDES Header Extension URI 16.2. New RTP SDES Header Extension URI
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this
document.] document.]
This document defines a new extension URI in the RTP SDES Compact This document defines a new extension URI in the RTP SDES Compact
Header Extensions sub-registry of the RTP Compact Header Extensions Header Extensions sub-registry of the RTP Compact Header Extensions
registry sub-registry, according to the following data: registry sub-registry, according to the following data:
Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid Extension URI: urn:ietf:params:rtp-hdrext:sdes:mid
Description: Media identification Description: Media identification
skipping to change at page 32, line 5 skipping to change at page 35, line 42
Reference: RFCXXXX Reference: RFCXXXX
The SDES item does not reveal privacy information about the users. The SDES item does not reveal privacy information about the users.
It is simply used to associate RTP-based media with the correct SDP It is simply used to associate RTP-based media with the correct SDP
media description (m- line) in the SDP used to negotiate the media. media description (m- line) in the SDP used to negotiate the media.
The purpose of the extension is for the offerer to be able to The purpose of the extension is for the offerer to be able to
associate received multiplexed RTP-based media before the offerer associate received multiplexed RTP-based media before the offerer
receives the associated SDP answer. receives the associated SDP answer.
15.3. New SDP Attribute 16.3. New SDP Attribute
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this
document.] document.]
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
skipping to change at page 32, line 25 skipping to change at page 36, line 19
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
Mux category: NORMAL Mux category: NORMAL
15.4. New SDP Group Semantics 16.4. New SDP Group Semantics
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this
document.] document.]
This document registers the following semantics with IANA in the This document registers the following semantics with IANA in the
"Semantics for the "group" SDP Attribute" subregistry (under the "Semantics for the "group" SDP Attribute" subregistry (under the
"Session Description Protocol (SDP) Parameters" registry: "Session Description Protocol (SDP) Parameters" registry:
Semantics Token Reference Semantics Token Reference
------------------------------------- ------ --------- ------------------------------------- ------ ---------
Media bundling BUNDLE [RFCXXXX] Media bundling BUNDLE [RFCXXXX]
16. Security Considerations 17. 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 addresses and ports e.g., RTP streams, flows over the network, with the exception of the
that information is flowing on and thus has very little impact on the usage of the MID SDES item as discussed below. Primarily it changes
security of the RTP sessions. which addresses and ports, and thus in which (RTP) sessions that the
information is flowing in. This affects the security contexts being
used and can cause previously separated information flows to share
the same security context. This has very little impact on the
performance of the security mechanism of the RTP sessions. In cases
where one would have applied different security policies on the
different RTP streams being bundled, or where the parties having
access to the security contexts would have differed between the RTP
stream, additional analysis of the implications are needed before
selecting to apply BUNDLE.
When the BUNDLE extension is used, a single set of security The identification-tag, independent of transport, RTCP SDES packet or
credentials might be used for all media streams specified by a BUNDLE RTP header extension, can expose the value to parties beyond the
group. signaling chain. Therefore, the identification-tag values MUST be
generated in a fashion that does not leak user information, e.g.,
randomly or using a per-bundle group counter, and SHOULD be 3 bytes
or less, to allow them to efficiently fit into the MID RTP header
extension. Note that if implementations use different methods for
generating identification-tags this could enable fingerprinting of
the implementation making it vulnerable to targeted attacks. The
identification-tag is exposed on the RTP stream level when included
in the RTP header extensions, however what it reveals of the RTP
media stream structure of the endpoint and application was already
possible to deduce from the RTP streams without the MID SDES header
extensions. As the identification-tag is also used to route the
media stream to the right application functionality it is also
important that the value received is the one intended by the sender,
thus integrity and the authenticity of the source are important to
prevent denial of service on the application. Existing SRTP
configurations and other security mechanisms protecting the whole
RTP/RTCP packets will provide the necessary protection.
When the BUNDLE extension is used, the number of SSRC values within a When the BUNDLE extension is used, the set of configurations of the
single RTP session increases, which increases the risk of SSRC security mechanism used in all the bundled media descriptions will
collision. [RFC4568] describes how SSRC collision may weaken SRTP need to be compatible so that they can simultaneously used in
and SRTCP encryption in certain situations. parallel, at least per direction or endpoint. When using SRTP this
will be the case, at least for the IETF defined key-management
solutions due to their SDP attributes (a=crypto, a=fingerprint,
a=mikey) and their classification in
[I-D.ietf-mmusic-sdp-mux-attributes].
17. Examples The security considerations of "RTP Header Extension for the RTP
Control Protocol (RTCP) Source Description Items" [RFC7941] requires
that when RTCP is confidentiality protected that any SDES RTP header
extension carrying an SDES item, such as the MID RTP header
extension, is also protected using commensurate strength algorithms.
However, assuming the above requirements and recommendations are
followed there are no known significant security risks with leaving
the MID RTP header extension without confidentiality protection.
Thus, the requirements in RFC 7941 MAY be ignored for the MID RTP
header extension. Security mechanisms for RTP/RTCP are discussed in
Options for Securing RTP Sessions [RFC7201], for example SRTP
[RFC3711] can provide the necessary security functions of ensuring
the integrity and source authenticity.
17.1. Example: Bundle Address Selection 18. Examples
18.1. Example: Bundle Address Selection
The example below shows: The example below shows:
o An offer, in which the offerer associates a unique address with o An offer, in which the offerer associates a unique address with
each bundled "m=" line within the BUNDLE group. each bundled "m=" line within the BUNDLE group.
o An answer, in which the answerer selects the offerer BUNDLE o An answer, in which the answerer selects the offerer BUNDLE
address, and then selects its own BUNDLE address (the answerer address, and then selects its own BUNDLE address (the answerer
BUNDLE address) and associates it with each bundled "m=" line BUNDLE address) and associates it with each bundled "m=" line
within the BUNDLE group. within the BUNDLE group.
skipping to change at page 35, line 5 skipping to change at page 40, line 5
a=rtcp-mux a=rtcp-mux
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 20000 RTP/AVP 32 m=video 20000 RTP/AVP 32
b=AS:1000 b=AS:1000
a=mid:bar a=mid:bar
a=rtcp-mux a=rtcp-mux
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
17.2. Example: BUNDLE Extension Rejected 18.2. Example: BUNDLE Extension Rejected
The example below shows: The example below shows:
o An offer, in which the offerer associates a unique address with o An offer, in which the offerer associates a unique address with
each bundled "m=" line within the BUNDLE group. each bundled "m=" line within the BUNDLE group.
o An answer, in which the answerer rejects the offered BUNDLE group, o An answer, in which the answerer rejects the offered BUNDLE group,
and associates a unique address with each "m=" line (following and associates a unique address with each "m=" line (following
normal RFC 3264 procedures). normal RFC 3264 procedures).
skipping to change at page 36, line 45 skipping to change at page 41, line 45
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=rtcp-mux a=rtcp-mux
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
m=video 30000 RTP/AVP 32 m=video 30000 RTP/AVP 32
b=AS:1000 b=AS:1000
a=rtcp-mux a=rtcp-mux
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
17.3. Example: Offerer Adds A Media Description To A BUNDLE Group 18.3. Example: Offerer Adds A Media Description To A BUNDLE Group
The example below shows: The example below shows:
o A subsequent offer (the BUNDLE group has been created as part of a o A subsequent offer (the BUNDLE group has been created as part of a
previous offer/answer exchange), in which the offerer adds a new previous offer/answer exchange), in which the offerer adds a new
"m=" line, represented by the "zen" identification-tag, to a "m=" line, represented by the "zen" identification-tag, to a
previously negotiated BUNDLE group, associates a unique address previously negotiated BUNDLE group, associates a unique address
with the added "m=" line, and associates the previously selected with the added "m=" line, and associates the previously selected
offerer BUNDLE address with each of the other bundled "m=" lines offerer BUNDLE address with each of the other bundled "m=" lines
within the BUNDLE group. within the BUNDLE group.
skipping to change at page 38, line 27 skipping to change at page 43, line 27
a=rtcp-mux a=rtcp-mux
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 20000 RTP/AVP 66 m=video 20000 RTP/AVP 66
b=AS:1000 b=AS:1000
a=mid:zen a=mid:zen
a=rtcp-mux a=rtcp-mux
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
17.4. Example: Offerer Moves A Media Description Out Of A BUNDLE Group 18.4. Example: Offerer Moves A Media Description Out Of A BUNDLE Group
The example below shows: The example below shows:
o A subsequent offer (the BUNDLE group has been created as part of a o A subsequent offer (the BUNDLE group has been created as part of a
previous offer/answer transaction), in which the offerer moves a previous offer/answer transaction), in which the offerer moves a
bundled "m=" line out of a BUNDLE group, associates a unique bundled "m=" line out of a BUNDLE group, associates a unique
address with the moved "m=" line, and associates the offerer address with the moved "m=" line, and associates the offerer
BUNDLE address with each other bundled "m=" line within the BUNDLE BUNDLE address with each other bundled "m=" line within the BUNDLE
group. group.
skipping to change at page 40, line 6 skipping to change at page 45, line 6
a=mid:bar a=mid:bar
a=rtcp-mux a=rtcp-mux
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 60000 RTP/AVP 66 m=video 60000 RTP/AVP 66
b=AS:1000 b=AS:1000
a=mid:zen a=mid:zen
a=rtcp-mux a=rtcp-mux
a=rtpmap:66 H261/90000 a=rtpmap:66 H261/90000
17.5. Example: Offerer Disables A Media Description Within A BUNDLE 18.5. Example: Offerer Disables A Media Description Within A BUNDLE
Group Group
The example below shows: The example below shows:
o A subsequent offer (the BUNDLE group has been created as part of a o A subsequent offer (the BUNDLE group has been created as part of a
previous offer/answer transaction), in which the offerer disables previous offer/answer transaction), in which the offerer disables
a bundled "m=" line within a BUNDLE group, assigns a zero port a bundled "m=" line within a BUNDLE group, assigns a zero port
number to the disabled "m=" line, and associates the offerer number to the disabled "m=" line, and associates the offerer
BUNDLE address with each of the other bundled "m=" lines within BUNDLE address with each of the other bundled "m=" lines within
the BUNDLE group. the BUNDLE group.
skipping to change at page 41, line 29 skipping to change at page 46, line 29
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=rtcp-mux a=rtcp-mux
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
18. Acknowledgements 19. 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, Ari Keranen, Adam Roach, Christian Groves, Roman Shpount, Stach, Ari Keranen, Adam Roach, Christian Groves, Roman Shpount,
Suhas Nandakumar, Nils Ohlmeier, Jens Guballa, Raju Makaraju and Suhas Nandakumar, Nils Ohlmeier, Jens Guballa, Raju Makaraju and
Justin Uberti for reading the text, and providing useful feedback. Justin Uberti for reading the text, and providing useful feedback.
Thanks to Bernard Aboba, Cullen Jennings, Peter Thatcher, Justin
Uberti, and Magnus Westerlund for providing the text for the section
on RTP/RTCP stream association.
Thanks to Magnus Westerlund, Colin Perkins and Jonathan Lennox for Thanks to Magnus Westerlund, Colin Perkins and Jonathan Lennox for
providing help and text on the RTP/RTCP procedures. providing help and text on the RTP/RTCP procedures.
Thanks to Spotify for providing music for the countless hours of Thanks to Spotify for providing music for the countless hours of
document editing. document editing.
19. Change Log 20. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing] [RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-36
o The following GitHub pull requests were merged:
o https://github.com/cdh4u/draft-sdp-bundle/pull/32
o - extmap handling in BUNDLE.
o https://github.com/cdh4u/draft-sdp-bundle/pull/31
o - Additional Acknowledgement text added.
o https://github.com/cdh4u/draft-sdp-bundle/pull/30
o - MID SDES item security procedures updated
o https://github.com/cdh4u/draft-sdp-bundle/pull/29
o - Appendix B of JSEP moved into BUNDLE.
o - Associating RTP/RTCP packets with SDP m- lines.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-35 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-35
o Editorial changes on RTP streaming mapping section based on o Editorial changes on RTP streaming mapping section based on
comments from Colin Perkins. comments from Colin Perkins.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-34 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-34
o RTP streams, instead of RTP packets, are associated with m- lines. o RTP streams, instead of RTP packets, are associated with m- lines.
Changes from draft-ietf-mmusic-sdp-bundle-negotiation-33 Changes from draft-ietf-mmusic-sdp-bundle-negotiation-33
skipping to change at page 50, line 11 skipping to change at page 55, line 40
o Draft name changed. o Draft name changed.
o Harald Alvestrand added as co-author. o Harald Alvestrand added as co-author.
o "Multiplex" terminology changed to "bundle". o "Multiplex" terminology changed to "bundle".
o Added text about single versus multiple RTP Sessions. o Added text about single versus multiple RTP Sessions.
o Added reference to RFC 3550. o Added reference to RFC 3550.
20. References 21. References
20.1. Normative References 21.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002, DOI 10.17487/RFC3264, June 2002,
<http://www.rfc-editor.org/info/rfc3264>. <http://www.rfc-editor.org/info/rfc3264>.
skipping to change at page 50, line 35 skipping to change at page 56, line 15
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>. July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
in Session Description Protocol (SDP)", RFC 3605, in Session Description Protocol (SDP)", RFC 3605,
DOI 10.17487/RFC3605, October 2003, DOI 10.17487/RFC3605, October 2003,
<http://www.rfc-editor.org/info/rfc3605>. <http://www.rfc-editor.org/info/rfc3605>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004,
<http://www.rfc-editor.org/info/rfc3711>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566, Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>. July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",
BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007,
<http://www.rfc-editor.org/info/rfc4961>. <http://www.rfc-editor.org/info/rfc4961>.
[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)
skipping to change at page 51, line 25 skipping to change at page 57, line 9
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, Protocol (SDP) Grouping Framework", RFC 5888,
DOI 10.17487/RFC5888, June 2010, DOI 10.17487/RFC5888, June 2010,
<http://www.rfc-editor.org/info/rfc5888>. <http://www.rfc-editor.org/info/rfc5888>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>. January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms
for Real-Time Transport Protocol (RTP) Sources", RFC 7656,
DOI 10.17487/RFC7656, November 2015,
<http://www.rfc-editor.org/info/rfc7656>.
[RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP [RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP
Header Extension for the RTP Control Protocol (RTCP) Header Extension for the RTP Control Protocol (RTCP)
Source Description Items", RFC 7941, DOI 10.17487/RFC7941, Source Description Items", RFC 7941, DOI 10.17487/RFC7941,
August 2016, <http://www.rfc-editor.org/info/rfc7941>. August 2016, <http://www.rfc-editor.org/info/rfc7941>.
[I-D.ietf-ice-rfc5245bis] [I-D.ietf-ice-rfc5245bis]
Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", draft-ietf-ice- Address Translator (NAT) Traversal", draft-ietf-ice-
rfc5245bis-04 (work in progress), June 2016. rfc5245bis-08 (work in progress), December 2016.
[I-D.ietf-mmusic-sdp-mux-attributes] [I-D.ietf-mmusic-sdp-mux-attributes]
Nandakumar, S., "A Framework for SDP Attributes when Nandakumar, S., "A Framework for SDP Attributes when
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-14 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16
(work in progress), September 2016. (work in progress), December 2016.
[I-D.ietf-mmusic-mux-exclusive] [I-D.ietf-mmusic-mux-exclusive]
Holmberg, C., "Indicating Exclusive Support of RTP/RTCP Holmberg, C., "Indicating Exclusive Support of RTP/RTCP
Multiplexing using SDP", draft-ietf-mmusic-mux- Multiplexing using SDP", draft-ietf-mmusic-mux-
exclusive-10 (work in progress), August 2016. exclusive-11 (work in progress), February 2017.
[I-D.ietf-mmusic-ice-sip-sdp] [I-D.ietf-mmusic-ice-sip-sdp]
Petit-Huguenin, M., Keranen, A., and S. Nandakumar, "Using Petit-Huguenin, M., Keranen, A., and S. Nandakumar, "Using
Interactive Connectivity Establishment (ICE) with Session Interactive Connectivity Establishment (ICE) with Session
Description Protocol (SDP) offer/answer and Session Description Protocol (SDP) offer/answer and Session
Initiation Protocol (SIP)", draft-ietf-mmusic-ice-sip- Initiation Protocol (SIP)", draft-ietf-mmusic-ice-sip-
sdp-10 (work in progress), July 2016. sdp-12 (work in progress), March 2017.
20.2. Informative References 21.2. Informative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>. <http://www.rfc-editor.org/info/rfc3261>.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
Description Protocol (SDP) Security Descriptions for Media "RTP Control Protocol Extended Reports (RTCP XR)",
Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, RFC 3611, DOI 10.17487/RFC3611, November 2003,
<http://www.rfc-editor.org/info/rfc4568>. <http://www.rfc-editor.org/info/rfc3611>.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104,
February 2008, <http://www.rfc-editor.org/info/rfc5104>.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
DOI 10.17487/RFC4585, July 2006,
<http://www.rfc-editor.org/info/rfc4585>.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009,
<http://www.rfc-editor.org/info/rfc5576>. <http://www.rfc-editor.org/info/rfc5576>.
[RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple
Clock Rates in an RTP Session", RFC 7160, Clock Rates in an RTP Session", RFC 7160,
DOI 10.17487/RFC7160, April 2014, DOI 10.17487/RFC7160, April 2014,
<http://www.rfc-editor.org/info/rfc7160>. <http://www.rfc-editor.org/info/rfc7160>.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
<http://www.rfc-editor.org/info/rfc7201>.
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms
for Real-Time Transport Protocol (RTP) Sources", RFC 7656,
DOI 10.17487/RFC7656, November 2015,
<http://www.rfc-editor.org/info/rfc7656>.
[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.
[I-D.ietf-avtext-lrr]
Lennox, J., Hong, D., Uberti, J., Holmer, S., and M.
Flodman, "The Layer Refresh Request (LRR) RTCP Feedback
Message", draft-ietf-avtext-lrr-03 (work in progress),
July 2016.
Appendix A. Design Considerations Appendix A. Design Considerations
One of the main issues regarding the BUNDLE grouping extensions has One of the main issues regarding the BUNDLE grouping extensions has
been whether, in SDP Offers and SDP Answers, the same port value been whether, in SDP Offers and SDP Answers, the same port value
should be inserted in "m=" lines associated with a BUNDLE group, as should be inserted in "m=" lines associated with a BUNDLE group, as
the purpose of the extension is to negotiate the usage of a single the purpose of the extension is to negotiate the usage of a single
address:port combination for media specified by the "m=" lines. address:port combination for media specified by the "m=" lines.
Issues with both approaches, discussed in the Appendix have been Issues with both approaches, discussed in the Appendix have been
raised. The outcome was to specify a mechanism which uses SDP Offers raised. The outcome was to specify a mechanism which uses SDP Offers
with both different and identical port values. with both different and identical port values.
 End of changes. 61 change blocks. 
160 lines changed or deleted 435 lines changed or added

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