draft-ietf-avtext-sdes-hdr-ext-07.txt   rfc7941.txt 
Network Working Group M. Westerlund Internet Engineering Task Force (IETF) M. Westerlund
Internet-Draft B. Burman Request for Comments: 7941 B. Burman
Intended status: Standards Track Ericsson Category: Standards Track Ericsson
Expires: December 12, 2016 R. Even ISSN: 2070-1721 R. Even
Huawei Technologies Huawei Technologies
M. Zanaty M. Zanaty
Cisco Systems Cisco Systems
June 10, 2016 August 2016
RTP Header Extension for RTCP Source Description Items RTP Header Extension for
draft-ietf-avtext-sdes-hdr-ext-07 the RTP Control Protocol (RTCP) Source Description Items
Abstract Abstract
Source Description (SDES) items are normally transported in RTP Source Description (SDES) items are normally transported in the RTP
control protocol (RTCP). In some cases it can be beneficial to speed Control Protocol (RTCP). In some cases, it can be beneficial to
up the delivery of these items. Mainly when a new source (SSRC) speed up the delivery of these items. The main case is when a new
joins an RTP session and the receivers need this source's identity, synchronization source (SSRC) joins an RTP session and the receivers
relation to other sources, or its synchronization context, all of need this source's identity, relation to other sources, or its
which may be fully or partially identified using SDES items. To synchronization context, all of which may be fully or partially
enable this optimization, this document specifies a new RTP header identified using SDES items. To enable this optimization, this
extension that can carry SDES items. document specifies a new RTP header extension that can carry SDES
items.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on December 12, 2016. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7941.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. SDES Item Header Extension . . . . . . . . . . . . . . . 5 4.1. SDES Item Header Extension . . . . . . . . . . . . . . . 5
4.1.1. One-Byte Format . . . . . . . . . . . . . . . . . . . 5 4.1.1. One-Byte Format . . . . . . . . . . . . . . . . . . . 6
4.1.2. Two-Byte Format . . . . . . . . . . . . . . . . . . . 6 4.1.2. Two-Byte Format . . . . . . . . . . . . . . . . . . . 6
4.2. Usage of the SDES Item Header Extension . . . . . . . . . 6 4.2. Usage of the SDES Item Header Extension . . . . . . . . . 6
4.2.1. One or Two Byte Headers . . . . . . . . . . . . . . . 6 4.2.1. One-Byte or Two-Byte Headers . . . . . . . . . . . . 6
4.2.2. MTU and Packet Expansion . . . . . . . . . . . . . . 7 4.2.2. MTU and Packet Expansion . . . . . . . . . . . . . . 7
4.2.3. Transmission Considerations . . . . . . . . . . . . . 7 4.2.3. Transmission Considerations . . . . . . . . . . . . . 8
4.2.4. Different Usages . . . . . . . . . . . . . . . . . . 9 4.2.4. Different Usages . . . . . . . . . . . . . . . . . . 9
4.2.5. SDES Items in RTCP . . . . . . . . . . . . . . . . . 9 4.2.5. SDES Items in RTCP . . . . . . . . . . . . . . . . . 10
4.2.6. Update Flaps . . . . . . . . . . . . . . . . . . . . 10 4.2.6. Update Flaps . . . . . . . . . . . . . . . . . . . . 10
4.2.7. RTP Header Compression . . . . . . . . . . . . . . . 10 4.2.7. RTP Header Compression . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5.1. Registration of an SDES Base URN . . . . . . . . . . . . 11 5.1. Registration of an SDES Base URN . . . . . . . . . . . . 11
5.2. Creation of an SDES Sub-Registry . . . . . . . . . . . . 11 5.2. Creation of the "RTP SDES Compact Header Extensions"
Sub-Registry . . . . . . . . . . . . . . . . . . . . . . 12
5.3. Registration of SDES Item . . . . . . . . . . . . . . . . 12 5.3. Registration of SDES Item . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 14 7.2. Informative References . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 14 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
This specification defines an RTP header extension [RFC3550][RFC5285] This specification defines an RTP header extension [RFC3550][RFC5285]
that can carry RTCP source description (SDES) items. Normally the that can carry RTCP Source Description (SDES) items. Normally, the
SDES items are carried in their own RTCP packet type [RFC3550]. By SDES items are carried in their own RTCP packet type [RFC3550]. By
including selected SDES items in a header extension the determination including selected SDES items in a header extension, the
of relationship and synchronization context for new RTP streams determination of relationship and synchronization context for new RTP
(SSRCs) in an RTP session can be optimized. Which relationship and streams (SSRCs) in an RTP session can be optimized. Which
what information depends on the SDES items carried. This becomes a relationship and what information depends on the SDES items carried.
complement to using only RTCP for SDES Item delivery. This becomes a complement to using only RTCP for SDES item delivery.
It is important to note that not all SDES items are appropriate to It is important to note that not all SDES items are appropriate to
transmit using RTP header extensions. Some SDES items performs transmit using RTP header extensions. Some SDES items perform
binding or identifies synchronization context with strict timeliness binding or identify synchronization contexts with strict timeliness
requirements, while many other SDES items do not have such requirements, while many other SDES items do not have such
requirements. In addition, security and privacy concerns for the requirements. In addition, security and privacy concerns for the
SDES item information need to be considered. For example, the Name SDES item information need to be considered. For example, the Name
and Location SDES items are highly sensitive from a privacy and Location SDES items are highly sensitive from a privacy
perspective and should not be transported over the network without perspective and should not be transported over the network without
strong security. No use case has identified where this information strong security. No use case has identified that such information is
is required at the same time as the first RTP packets arrive. A few required when the first RTP packets arrive. A delay of a few seconds
seconds delay before such information is available to the receiver before such information is available to the receiver appears
appears acceptable. Therefore only appropriate SDES items will be acceptable. Therefore, only appropriate SDES items, such as CNAME,
registered for use with this header extension, such as CNAME. will be registered for use with this header extension.
First, some requirements language and terminology are defined. The Requirements language and terminology are defined in Section 2.
following section motivates why this header extension is sometimes Section 3 describes why this header extension is sometimes required
required or at least provides a significant improvement compared to or at least provides a significant improvement compared to waiting
waiting for regular RTCP packet transmissions of the information. for regular RTCP packet transmissions of the information. Section 4
This is followed by a specification of the header extension and usage provides a specification of the header extension and usage
recommendations. Next, a sub-space of the header-extension URN is recommendations. Section 5 defines a subspace of the header
defined to be used for existing and future SDES items, and then the extension URN to be used for existing and future SDES items and
appropriate existing SDES items are registered. registers the appropriate existing SDES items.
2. Definitions 2. Definitions
2.1. Requirements Language 2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2.2. Terminology 2.2. Terminology
This document uses terminology defined in "A Taxonomy of Semantics This document uses terminology defined in "A Taxonomy of Semantics
and Mechanisms for Real-Time Transport Protocol (RTP) Sources" and Mechanisms for Real-Time Transport Protocol (RTP) Sources"
[RFC7656]. In particular the following definitions: [RFC7656]. In particular, the following terms are used:
Media Source Media Source
RTP Stream RTP Stream
Media Encoder Media Encoder
Participant Participant
3. Motivation 3. Motivation
Source Description (SDES) items are associated with a particular SSRC SDES items are associated with a particular SSRC and thus with a
and thus RTP stream. The source description items provide various particular RTP stream. The Source Description items provide various
meta data associated with the SSRC. How important it is to have this metadata associated with the SSRC. How important it is to have this
data no later than when receiving the first RTP packets depends on data no later than when the first RTP packets is received depends on
the item itself. The CNAME item is one item that is commonly needed the item itself. The CNAME item is one item that is commonly needed
either at reception of the first RTP packet for this SSRC, or at either at reception of the first RTP packet for this SSRC or at least
least by the time the first media can be played out. If it is not by the time the first media can be played out. If it is not
available, the synchronization context cannot be determined and thus available, the synchronization context cannot be determined; thus,
any related streams cannot be correctly synchronized. Thus, this is any related streams cannot be correctly synchronized. Therefore,
a valuable example for having this information early when a new RTP this is a valuable example for having this information early when a
stream is received. new RTP stream is received.
The main reason for new SSRCs in an RTP session is when media sources The main reason for new SSRCs in an RTP session is when media sources
are added. This can be either because an end-point is adding a new are added. This can be because either an endpoint is adding a new
actual media source, or additional participants in a multi-party actual media source or additional participants in a multi-party
session are added to the session. Another reason for a new SSRC can session are added to the session. Another reason for a new SSRC can
be an SSRC collision that forces both colliding parties to select new be an SSRC collision that forces both colliding parties to select new
SSRCs. SSRCs.
For the case of rapid media synchronization, one may use the RTP For the case of rapid media synchronization, one may use the RTP
header extension for Rapid Synchronization of RTP Flows [RFC6051]. header extension for rapid synchronization of RTP flows [RFC6051].
This header extension carries the clock information present in the This header extension carries the clock information present in the
RTCP sender report (SR) packets. It however assumes that the CNAME RTCP sender report (SR) packets. However, it assumes that the CNAME
binding is known, which can be provided via signaling [RFC5576] in binding is known, which can be provided via signaling [RFC5576] in
some cases, but not all. Thus an RTP header extension for carrying some cases, but not all. Thus, an RTP header extension for carrying
SDES items like CNAME is a powerful combination to enable rapid SDES items like CNAME is a powerful combination to enable rapid
synchronization in all cases. synchronization in all cases.
The Rapid Synchronization of RTP Flows specification does provide an The "Rapid Synchronisation of RTP Flows" specification [RFC6051] does
analysis of the initial synchronization delay for different sessions provide an analysis of the initial synchronization delay for
depending on number of receivers as well as on session bandwidth different sessions depending on the number of receivers as well as on
(Section 2.1 of [RFC6051]). These results are applicable also for session bandwidth (Section 2.1 of [RFC6051]). These results are also
other SDES items that have a similar time dependency until the applicable for other SDES items that have a similar time dependency
information can be sent using RTCP. These figures can be used to until the information can be sent using RTCP. These figures can be
determine the benefit of reducing the initial delay before used to determine the benefit of reducing the initial delay before
information is available for some use cases. information is available for some use cases.
Rapid Synchronization of RTP Flows [RFC6051] also discusses the case [RFC6051] also discusses the case of late joiners and defines an RTCP
of late joiners, and defines an RTCP Feedback format to request Feedback format to request synchronization information, which is
synchronization information, which is another potential use case for another potential use case for SDES items in the RTP header
SDES items in RTP header extension. It would for example be natural extension. It would, for example, be natural to include a CNAME SDES
to include CNAME SDES item with the header extension containing the item with the header extension containing the NTP-formatted reference
NTP formatted reference clock to ensure synchronization. clock to ensure synchronization.
The ongoing work on bundling SDP media descriptions The ongoing work on bundling Session Description Protocol (SDP) media
[I-D.ietf-mmusic-sdp-bundle-negotiation] has identified a new SDES descriptions [SDP-BUNDLE] has identified a new SDES item that can
item that can benefit from timely delivery. A corresponding RTP SDES benefit from timely delivery. A corresponding RTP SDES compact
compact header extension is therefore also defined and registered in header extension is therefore also defined and registered in that
that document: document:
MID: This is a media description identifier that matches the value MID: This is a media description identifier that matches the value
of the Session Description Protocol (SDP) [RFC4566] a=mid of the SDP [RFC4566] a=mid attribute [RFC5888], to associate RTP
attribute [RFC5888], to associate RTP streams multiplexed on the streams multiplexed on the same transport with their respective
same transport with their respective SDP media description. SDP media description.
4. Specification 4. Specification
This section first specifies the SDES item RTP header extension This section first specifies the SDES item RTP header extension
format, followed by some usage considerations. format, followed by some usage considerations.
4.1. SDES Item Header Extension 4.1. SDES Item Header Extension
An RTP header extension scheme allowing for multiple extensions is An RTP header extension scheme allowing for multiple extensions is
defined in "A General Mechanism for RTP Header Extensions" [RFC5285]. defined in "A General Mechanism for RTP Header Extensions" [RFC5285].
That specification defines both short and long item headers. The That specification defines both short and long item headers. The
short headers (One-byte) are restricted to 1 to 16 bytes of data, short headers (one byte) are restricted to 1 to 16 bytes of data,
while the long format (Two-byte) supports a data length of 0 to 255 while the long format (two bytes) supports a data length of 0 to 255
bytes. Thus the RTP header extension formats are capable of bytes. Thus, the RTP header extension formats are capable of
supporting any SDES item from a data length perspective. supporting any SDES item from a data length perspective.
The ID field, independent of short or long format, identifies both The ID field, independent of a short or long format, identifies both
the type of RTP header extension and, in the case of the SDES item the type of RTP header extension and, in the case of the SDES item
header extension, the type of SDES item. The mapping is done in header extension, the type of SDES item. The mapping is done in
signaling by identifying the header extension and SDES item type signaling by identifying the header extension and SDES item type
using a URN, which is defined in the IANA consideration (Section 5) using a URN, which is defined in Section 5 ("IANA Considerations")
for the known SDES items appropriate to use. for the known SDES items appropriate to use.
4.1.1. One-Byte Format 4.1.1. One-Byte Format
The one-byte header format for an SDES item extension element The one-byte header format for an SDES item extension element
consists of the one-byte header (defined in Section 4.2 of consists of the one-byte header (defined in Section 4.2 of
[RFC5285]), which consists of a 4-bit ID followed by a 4-bit length [RFC5285]), which consists of a 4-bit ID followed by a 4-bit length
field (len) that identifies the number of data bytes (len value +1) field (len) that identifies the number of data bytes (len value +1)
following the header. The data part consists of len+1 bytes of UTF-8 following the header. The data part consists of len+1 bytes of UTF-8
[RFC3629] text. The type of text and its mapping to the SDES item [RFC3629] text. The type of text and its mapping to the SDES item
type is determined by the ID field value. type are determined by the ID field value.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | len | SDES Item text value ... | | ID | len | SDES item text value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 Figure 1
4.1.2. Two-Byte Format 4.1.2. Two-Byte Format
The two-byte header format for an SDES item extension element The two-byte header format for an SDES item extension element
consists of the two-byte header (defined in Section 4.3 of consists of the two-byte header (defined in Section 4.3 of
[RFC5285]), which consists of an 8-bit ID followed by an 8-bit length [RFC5285]), which consists of an 8-bit ID followed by an 8-bit length
field (len) that identifies the number of data bytes following the field (len) that identifies the number of data bytes following the
header. The data part consists of len bytes of UTF-8 text. The type header. The data part consists of len bytes of UTF-8 text. The type
of text and its mapping to the SDES item type is determined by the ID of text and its mapping to the SDES item type are determined by the
field value. ID field value.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | len | SDES Item text value ... | | ID | len | SDES item text value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 Figure 2
4.2. Usage of the SDES Item Header Extension 4.2. Usage of the SDES Item Header Extension
This section discusses various usage considerations; which form of This section discusses various usage considerations: which form of
header extension to use, the packet expansion, and when to send SDES the header extension to use, the packet expansion, and when to send
items in header extension. SDES items in the header extension.
4.2.1. One or Two Byte Headers 4.2.1. One-Byte or Two-Byte Headers
The RTP header extensions for SDES items MAY use either the one-byte The RTP header extensions for SDES items MAY use either the one-byte
or two-byte header formats, depending on the text value size for the or two-byte header formats, depending on the text value size for the
used SDES items and the requirement from any other header extensions used SDES items and the requirement from any other header extensions
used. The one-byte header SHOULD be used when all non SDES item used. The one-byte header SHOULD be used when all non-SDES item
header extensions supports the one-byte format and all SDES item text header extensions support the one-byte format and all SDES item text
values contain at most 16 bytes. Note that the RTP header extension values contain at most 16 bytes. Note that the RTP header extension
specification does not allow mixing one-byte and two-byte headers for specification [RFC5285] does not allow mixing one-byte and two-byte
the same RTP stream (SSRC), so if the value size of any of the SDES headers for the same RTP stream (SSRC), so if any SDES item requires
items value requires the two-byte header, then all other header the two-byte header, then all other header extensions MUST also use
extensions MUST also use the two-byte header format. the two-byte header format.
For example using CNAMEs that are generated according to "Guidelines For example, if using CNAMEs that are generated according to
for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)" "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names
[RFC7022], using short term persistent values, and if 96-bit random (CNAMEs)" [RFC7022], if using short-term persistent values, and if
values prior to base64 encoding are sufficient, then they will fit 96-bit random values prior to base64 encoding are sufficient, then
into the one-byte header format. they will fit into the one-byte header format.
An RTP middlebox needs to take care choosing between one-byte headers An RTP middlebox needs to take care choosing between one-byte headers
and two-byte headers when creating the first packets for an outgoing and two-byte headers when creating the first packets for an outgoing
stream (SSRC) with header extensions. First of all it needs to stream (SSRC) with header extensions. First of all, it needs to
consider all the header extensions that may potentially be used. consider all the header extensions that may potentially be used.
Secondly, it needs to know the size of the SDES items that are going Second, it needs to know the size of the SDES items that are going to
to be included, and use two bytes headers if any are longer than 16 be included and use two-byte headers if any are longer than 16 bytes.
bytes. An RTP middlebox that forwards a stream, i.e., not mixing it An RTP middlebox that forwards a stream, i.e., not mixing it or
or combing it with other streams, may be able to base its choice on combining it with other streams, may be able to base its choice on
the header size in incoming streams. This is assuming that the the header size in incoming streams. This is assuming that the
middlebox does not modify the stream or add additional header middlebox does not modify the stream or add additional header
extensions to the stream it sends, in which case it needs to make its extensions to the stream it sends, in which case it needs to make its
own decision. own decision.
4.2.2. MTU and Packet Expansion 4.2.2. MTU and Packet Expansion
The RTP packet size will clearly increase when a header extension is The RTP packet size will clearly increase when a header extension is
included. How much depends on the type of header extensions and included. How much depends on the type of header extensions and
their data content. The SDES items can vary in size. There are also their data content. The SDES items can vary in size. There are also
some use-cases that require transmitting multiple SDES items in the some use cases that require transmitting multiple SDES items in the
same packet to ensure that all relevant data reaches the receiver. same packet to ensure that all relevant data reaches the receiver.
An example of that is when both CNAME, a MID, and the rapid time An example of that is when CNAME, a MID, and the rapid time
synchronization extension from RFC 6051 are needed. Such a synchronization extension from RFC 6051 are all needed. Such a
combination is quite likely to result in at least 16+3+8 bytes of combination is quite likely to result in at least 16+3+8 bytes of
data plus the headers, which will be another 7 bytes for one-byte data plus the headers, which will be another 7 bytes for one-byte
headers, plus two bytes of header padding to make the complete header headers, plus two bytes of header padding to make the complete header
extension 32-bit word aligned, thus in total 36 bytes. extension 32-bit word aligned, thus 36 bytes in total.
If the packet expansion cannot be taken into account when producing If the packet expansion cannot be taken into account when producing
the RTP payload, it can cause an issue. An RTP payload that is the RTP payload, it can cause an issue. An RTP payload that is
created to meet a particular IP level Maximum Transmission Unit created to meet a particular IP-level Maximum Transmission Unit
(MTU), taking the addition of IP/UDP/RTP headers but not RTP header (MTU), taking the addition of IP/UDP/RTP headers but not RTP header
extensions into account, could exceed the MTU when the header extensions into account, could exceed the MTU when the header
extensions are present, thus resulting in IP fragmentation. IP extensions are present, thus resulting in IP fragmentation. IP
fragmentation is known to negatively impact the loss rate due to fragmentation is known to negatively impact the loss rate due to
middleboxes unwilling or not capable of dealing with IP fragments, as middleboxes unwilling or not capable of dealing with IP fragments, as
well as increasing the target surface for other types of packet well as increasing the target surface for other types of packet
losses. losses.
As this is a real issue, the media encoder and payload packetizer As this is a real issue, the media encoder and payload packetizer
should be flexible and be capable of handling dynamically varying should be flexible and be capable of handling dynamically varying
payload size restrictions to counter the packet expansion caused by payload size restrictions to counter the packet expansion caused by
header extensions. If that is not possible, some reasonable worst header extensions. If that is not possible, some reasonable worst-
case packet expansion should be calculated and used to reduce the RTP case packet expansion should be calculated and used to reduce the RTP
payload size of all RTP packets the sender transmits. payload size of all RTP packets the sender transmits.
4.2.3. Transmission Considerations 4.2.3. Transmission Considerations
The general recommendation is to only send header extensions when The general recommendation is to only send header extensions when
needed. This is especially true for SDES items that can be sent in needed. This is especially true for SDES items that can be sent in
periodic repetitions of RTCP throughout the whole session. Thus, the periodic repetitions of RTCP throughout the whole session. Thus, the
different usages (Section 4.2.4) have different recommendations. different usages (Section 4.2.4) have different recommendations. The
First some general considerations for getting the header extensions following are some general considerations for getting the header
delivered to the receiver: extensions delivered to the receiver:
1. The probability for packet loss and burst loss determine how many 1. The probability for packet loss and burst loss determine how many
repetitions of the header extensions will be required to reach a repetitions of the header extensions will be required to reach a
targeted delivery probability, and if burst loss is likely, what targeted delivery probability and, if burst loss is likely, what
distribution would be needed to avoid getting all repetitions of distribution would be needed to avoid getting all repetitions of
the header extensions lost in a single burst. the header extensions lost in a single burst.
2. If a set of packets are all needed to enable decoding, there is 2. If a set of packets are all needed to enable decoding, there is
commonly no reason for including the header extension in all of commonly no reason for including the header extension in all of
these packets, as they share fate. Instead, at most one instance these packets, as they share fate. Instead, at most one instance
of the header extension per independently decodable set of media of the header extension per independently decodable set of media
data would be a more efficient use of the bandwidth. data would be a more efficient use of the bandwidth.
3. How early the SDES item information is needed, from the first 3. How early the SDES item information is needed, from the first
received RTP data or only after some set of packets are received, received RTP data or only after some set of packets are received,
can guide if the header extension(s) should be in all of the can guide if the header extension(s) should be in all of the
first N packets or be included only once per set of packets, for first N packets or be included only once per set of packets, for
example once per video frame. example, once per video frame.
4. The use of RTP level robustness mechanisms, such as RTP 4. The use of RTP-level robustness mechanisms, such as RTP
retransmission [RFC4588], or Forward Error Correction, e.g., retransmission [RFC4588] or forward error correction [RFC5109],
[RFC5109] may treat packets differently from a robustness may treat packets differently from a robustness perspective, and
perspective, and SDES header extensions should be added to SDES header extensions should be added to packets that get a
packets that get a treatment corresponding to the relative treatment corresponding to the relative importance of receiving
importance of receiving the information. the information.
As a summary, the number of header extension transmissions should be As a summary, the number of header extension transmissions should be
tailored to a desired probability of delivery taking the receiver tailored to a desired probability of delivery, taking the receiver
population size into account. For the very basic case, N repetitions population size into account. For the very basic case, N repetitions
of the header extensions should be sufficient, but may not be of the header extensions should be sufficient but may not be optimal.
optimal. N is selected so that the header extension target delivery
N is selected so that the header extension target delivery
probability reaches 1-P^N, where P is the probability of packet loss. probability reaches 1-P^N, where P is the probability of packet loss.
For point to point or small receiver populations, it might also be For point-to-point or small receiver populations, it might also be
possible to use feedback, such as RTCP, to determine when the possible to use feedback, such as RTCP, to determine when the
information in the header extensions has reached all receivers and information in the header extensions has reached all receivers and to
stop further repetitions. Feedback that can be used includes the stop further repetitions. Feedback that can be used includes the
RTCP XR Loss RLE report block [RFC3611], which will indicate RTCP Extended Report (XR) Loss RLE Report Block [RFC3611], which
successful delivery of particular packets. If the RTP/AVPF Transport indicates successful delivery of particular packets. If the RTP/AVPF
Layer Feedback Messages for generic NACK [RFC4585] is used, it can transport-layer feedback message for generic NACK [RFC4585] is used,
indicate the failure to deliver an RTP packet with the header it can indicate the failure to deliver an RTP packet with the header
extension, thus indicating the need for further repetitions. The extension, thus indicating the need for further repetitions. The
normal RTCP report blocks can also provide an indicator of successful normal RTCP report blocks can also provide an indicator of successful
delivery, if no losses are indicated for a reporting interval delivery, if no losses are indicated for a reporting interval
covering the RTP packets with the header extension. Note that loss covering the RTP packets with the header extension. Note that loss
of an RTCP packet reporting on an interval where RTP header extension of an RTCP packet reporting on an interval where RTP header extension
packets were sent, does not necessarily mean that the RTP header packets were sent does not necessarily mean that the RTP header
extension packets themselves were lost. extension packets themselves were lost.
4.2.4. Different Usages 4.2.4. Different Usages
4.2.4.1. New SSRC 4.2.4.1. New SSRC
A new SSRC joins an RTP session. As this SSRC is completely new for A new SSRC joins an RTP session. As this SSRC is completely new for
everyone, the goal is to ensure, with high probability, that all RTP everyone, the goal is to ensure, with high probability, that all RTP
session participants receives the information in the header session participants receive the information in the header extension.
extension. Thus, header extension transmission strategies that allow Thus, header extension transmission strategies that allow some
some margins in the delivery probability should be considered. margins in the delivery probability should be considered.
4.2.4.2. Late Joiner 4.2.4.2. Late Joiner
In a multi-party RTP session where one or a small number of receivers In a multi-party RTP session where one or a small number of receivers
join a session where the majority of receivers already have all join a session where the majority of receivers already have all
necessary information, the use of header extensions to deliver necessary information, the use of header extensions to deliver
relevant information should be tailored to reach the new receivers. relevant information should be tailored to reach the new receivers.
The trigger to send header extensions can for example either be RTCP The trigger to send header extensions can, for example, be either
from new receiver(s) or an explicit request like the Rapid RTCP from a new receiver(s) or an explicit request like the Rapid
Resynchronization Request defined in [RFC6051]. In centralized Resynchronization Request defined in [RFC6051]. In centralized
topologies where an RTP middlebox is present, it can be responsible topologies where an RTP middlebox is present, it can be responsible
for transmitting the known information, possibly stored, to the new for transmitting the known information, possibly stored, to the new
session participant only, and not repeat it to all the session session participant only and not repeat it to all the session
participants. participants.
4.2.4.3. Information Change 4.2.4.3. Information Change
If the SDES information is tightly coupled with the RTP data, and the If the SDES information is tightly coupled with the RTP data, and the
SDES information needs to be updated, then the use of the RTP header SDES information needs to be updated, then the use of the RTP header
extension is superior to RTCP. Using the RTP header extension extension is superior to RTCP. Using the RTP header extension
ensures that the information is updated on reception of the related ensures that the information is updated on reception of the related
RTP media, ensuring synchronization between the two. Continued use RTP media, ensuring synchronization between the two. Continued use
of the old SDES information can lead to undesired effects in the of the old SDES information can lead to undesired effects in the
application. Thus, header extension transmission strategies with application. Thus, header extension transmission strategies with
high probability of delivery should be chosen. high probability of delivery should be chosen.
4.2.5. SDES Items in RTCP 4.2.5. SDES Items in RTCP
The RTP header extension information, i.e., SDES items, can and will The RTP header extension information, i.e., SDES items, can and will
be sent also in RTCP. Therefore, it is worth making some reflections be sent also in RTCP. Therefore, it is worth making some reflections
on this interaction. As an alternative to the header extension, it on this interaction. As an alternative to the header extension, it
is possible to schedule a non-regular RTCP packet transmission is possible to schedule a non-regular RTCP packet transmission
containing important SDES items, if one uses an RTP/AVPF-based RTP containing important SDES items, if one uses an RTP-/AVPF-based RTP
profile. Depending on which mode one's RTCP feedback transmitter is profile. Depending on the mode in which one's RTCP feedback
working on, extra RTCP packets may be sent as immediate or early transmitter is working, extra RTCP packets may be sent as immediate
packets, enabling more timely SDES information delivery. or early packets, enabling more timely SDES information delivery.
There are however two aspects that differ between using RTP header There are, however, two aspects that differ between using RTP header
extensions and any non-regular transmission of RTCP packets. First, extensions and any non-regular transmission of RTCP packets. First,
as the RTCP packet is a separate packet, there is no direct relation as the RTCP packet is a separate packet, there is no direct relation
and also no fate sharing between the relevant media data and the SDES and also no fate sharing between the relevant media data and the SDES
information. The order of arrival for the packets will matter. With information. The order of arrival for the packets will matter. With
a header-extension, the SDES items can be ensured to arrive if the a header extension, the SDES items can be ensured to arrive if the
media data to play out arrives. Secondly, it is difficult to media data to play out arrives. Second, it is difficult to determine
determine if an RTCP packet is actually delivered. This, as the RTCP if an RTCP packet is actually delivered, as the RTCP packets lack
packets lack both sequence number and a mechanism providing feedback both a sequence number and a mechanism providing feedback on the RTCP
on the RTCP packets themselves. packets themselves.
4.2.6. Update Flaps 4.2.6. Update Flaps
The SDES item may arrive both in RTCP and in RTP header extensions, The SDES item may arrive both in RTCP and in RTP header extensions,
potentially causing the value to flap back and forth at the time of potentially causing the value to flap back and forth at the time of
updating. There are at least two reasons for these flaps. The first updating. There are at least two reasons for these flaps. The first
one is packet reordering, where a pre-update RTP or RTCP packet with one is packet reordering, where a pre-update RTP or RTCP packet with
an SDES item is delivered to the receiver after the first RTP/RTCP an SDES item is delivered to the receiver after the first RTP/RTCP
packet with the updated value. The second reason is the different packet with the updated value. The second reason is the different
code-paths for RTP and RTCP in implementations. An update to the code paths for RTP and RTCP in implementations. An update to the
sender's SDES item parameter can take a different time to propagate sender's SDES item parameter can take a different time to propagate
to the receiver than the corresponding media data. For example, an to the receiver than the corresponding media data. For example, an
RTCP packet with the SDES item included that may have been generated RTCP packet with the SDES item included that may have been generated
prior to the update can still reside in a buffer and be sent prior to the update can still reside in a buffer and be sent
unmodified. The update of the item's value can at the same time unmodified. The update of the item's value can, at the same time,
cause RTP packets to be sent including the header extension, prior to cause RTP packets to be sent including the header extension, prior to
the RTCP packet being sent. the RTCP packet being sent.
However, most of these issues can be avoided by the receiver However, most of these issues can be avoided by the receiver
performing some checks before updating the receiver's stored value. performing some checks before updating the receiver's stored value.
To handle flaps caused by reordering, SDES items received in RTP To handle flaps caused by reordering, SDES items received in RTP
packets with the same or a lower extended sequence number than the packets with the same or a lower extended sequence number than the
last change MUST NOT be applied, i.e., discard items that can be last change MUST NOT be applied, i.e., discard items that can be
determined to be older than the current one. For compound RTCP determined to be older than the current one. For compound RTCP
packets, which will contain a Sender Report (SR) packet (assuming an packets, which will contain an SR packet (assuming an active RTP
active RTP sender), the receiver can use the RTCP SR Timestamp field sender), the receiver can use the RTCP SR timestamp field to
to determine at what approximate time it was transmitted. If the determine at what approximate time it was transmitted. If the
timestamp is earlier than the last received RTP packet with a header timestamp is earlier than the last received RTP packet with a header
extension carrying an SDES item, and especially if carrying a extension carrying an SDES item, and especially if carrying a
previously used value, the SDES item in the RTCP SDES packet can be previously used value, the SDES item in the RTCP SDES packet can be
ignored. Note that media processing and transmission pacing can ignored. Note that media processing and transmission pacing can
easily cause the RTP header timestamp field as well as the RTCP SR easily cause the RTP header timestamp field as well as the RTCP SR
timestamp field to not match with the actual transmission time. timestamp field to not match with the actual transmission time.
4.2.7. RTP Header Compression 4.2.7. RTP Header Compression
When robust header compression (ROHC) [RFC5225] is used with RTP, the When Robust Header Compression (ROHC) [RFC5225] is used with RTP, the
RTP header extension [RFC5285] data itself is not part of what is RTP header extension [RFC5285] data itself is not part of what is
being compressed and thus does not impact header compression being compressed and thus does not impact header compression
performance. The extension indicator (X) bit in the RTP header is performance. The extension indicator (X) bit in the RTP header is,
however compressed. It is classified as rarely changing, which may however, compressed. It is classified as rarely changing, which may
no longer be true for all RTP header extension usage, in turn leading no longer be true for all RTP header extension usage, in turn leading
to lower header compression efficiency. to lower header compression efficiency.
5. IANA Considerations 5. IANA Considerations
This section makes the following requests to IANA: This section details the following updates made by IANA:
o Create a new sub-registry reserved for RTCP SDES items with the
URN sub-space "urn:ietf:params:rtp-hdrext:sdes:" in the RTP
Compact Header Extensions registry.
o Register the SDES items appropriate for use with the RTP header o Creation of a new sub-registry reserved for RTCP SDES items with
extension defined in this document. the URN subspace "urn:ietf:params:rtp-hdrext:sdes:" in the "RTP
Compact Header Extensions" registry.
RFC-editor note: Please replace all occurrences of RFCXXXX with the o Registration of the SDES items appropriate for use with the RTP
RFC number this specification receives when published. header extension defined in this document.
5.1. Registration of an SDES Base URN 5.1. Registration of an SDES Base URN
IANA is requested to register the below entry in the RTP Compact IANA has registered the following entry in the "RTP Compact Header
Header Extensions registry: Extensions" registry:
Extension URI: urn:ietf:params:rtp-hdrext:sdes Extension URI: urn:ietf:params:rtp-hdrext:sdes
Description: Reserved as base URN for RTCP SDES items that are also Description: Reserved as base URN for RTCP SDES items that are also
defined as RTP Compact header extensions. defined as RTP compact header extensions.
Contact: Authors of [RFCXXXX] Contact: Authors of RFC 7941
Reference: [RFCXXXX] Reference: RFC 7941
The reason to register a base URN for an SDES sub-space is that the The reason to register a base URN for an SDES subspace is that the
name represents an RTCP Source Description item, where a name represents an RTCP Source Description item, for which a
specification is strongly recommended [RFC3550]. specification is strongly recommended [RFC3550].
5.2. Creation of an SDES Sub-Registry 5.2. Creation of the "RTP SDES Compact Header Extensions" Sub-Registry
IANA is requested to create a sub-registry to the RTP Compact Header IANA has created a sub-registry to the "RTP Compact Header
Extensions registry, with the same basic requirements, structure and Extensions" registry, with the same basic requirements, structure,
layout as the RTP Compact Header Extensions registry. and layout as the "RTP Compact Header Extensions" registry.
o Registry name: RTP SDES Compact Header Extensions o Registry name: RTP SDES Compact Header Extensions
o Specification: RFCXXXX and RFCs updating RFCXXXX o Specification: RFC 7941
o Information required: Same as for RTP Header Extensions [RFC5285] o Information required: Same as for the "RTP Compact Header
registry Extensions" registry [RFC5285]
o Review process: Same as for RTP Header Extensions [RFC5285] o Review process: Same as for the "RTP Compact Header Extensions"
registry, with the following requirements added to the expert registry [RFC5285], with the following requirements added to the
review: Expert Review [RFC5226]:
1. Any registration using an Extension URI that starts with 1. Any registration using an extension URI that starts with
"urn:ietf:params:rtp-hdrext:sdes:" (Section 5.1) MUST also "urn:ietf:params:rtp-hdrext:sdes:" (Section 5.1) MUST also
have a registered Source Description item in the "RTP SDES have a registered Source Description item in the "RTP SDES
item types" registry. item types" registry.
2. A security and privacy consideration for the SDES item MUST be 2. Security and privacy considerations for the SDES item MUST be
provided with the registration. provided with the registration.
3. Information MUST be provided on why this SDES item requires 3. Information MUST be provided on why this SDES item requires
timely delivery, motivating it to be transported in a header timely delivery, motivating it to be transported in a header
extension rather than as RTCP only. extension rather than as RTCP only.
o Size and format of entries: Same as for RTP Header Extensions o Size and format of entries: Same as for the "RTP Compact Header
[RFC5285] registry. Extensions" registry [RFC5285].
o Initial assignments: See Section 5.3 below. o Initial assignments: See Section 5.3 of this document.
5.3. Registration of SDES Item 5.3. Registration of SDES Item
It is requested that the following SDES item is registered in the IANA has registered the following SDES item in the newly formed "RTP
newly formed RTP SDES Compact Header Extensions registry: SDES Compact Header Extensions" registry:
Extension URI: urn:ietf:params:rtp-hdrext:sdes:cname Extension URI: urn:ietf:params:rtp-hdrext:sdes:cname
Description: Source Description: Canonical End-Point Identifier Description: Source Description: Canonical End-Point Identifier
(SDES CNAME) (SDES CNAME)
Contact: Authors of [RFCXXXX] Contact: Authors of RFC 7941
Reference: [RFCXXXX] Reference: RFC 7941
6. Security Considerations 6. Security Considerations
Source Description items may contain data that are sensitive from a Source Description items may contain data that are sensitive from a
security perspective. There are SDES items that are or may be security perspective. There are SDES items that are or may be
sensitive from a user privacy perspective, like CNAME, NAME, EMAIL, sensitive from a user privacy perspective, like CNAME, NAME, EMAIL,
PHONE, LOC and H323-CADDR. Some may contain sensitive information, PHONE, LOC, and H323-CADDR. Some may contain sensitive information,
like NOTE and PRIV, while others may be sensitive from profiling like NOTE and PRIV, while others may be sensitive from profiling
implementations for vulnerability or other reasons, like TOOL. The implementations for vulnerability or other reasons, like TOOL. The
CNAME sensitivity can vary depending on how it is generated and what CNAME sensitivity can vary depending on how it is generated and what
persistence it has. A short term CNAME identifier generated using a persistence it has. A short-term CNAME identifier generated using a
random number generator [RFC7022] may have minimal security random number generator [RFC7022] may have minimal security
implications, while a CNAME of the form user@host has privacy implications, while a CNAME of the form user@host has privacy
concerns, and a CNAME generated from a MAC address has long term concerns, and a CNAME generated from a Media Access Control (MAC)
tracking potentials. address has long-term tracking potentials.
In RTP sessions where any type of confidentiality protection is In RTP sessions where any type of confidentiality protection is
enabled for RTCP, the SDES item header extensions MUST also be enabled for RTCP, the SDES item header extensions MUST also be
protected. This implies that to provide confidentiality, users of protected. This implies that to provide confidentiality, users of
SRTP need to implement and use encrypted header extensions per the Secure Real-time Transport Protocol (SRTP) need to implement and
[RFC6904]. SDES items carried as RTP header extensions MUST then use use encrypted header extensions per [RFC6904]. SDES items carried as
commensurate strength algorithms and SHOULD use the same RTP header extensions MUST then use commensurate strength algorithms
cryptographic primitives (algorithms, modes) as applied to RTCP and SHOULD use the same cryptographic primitives (algorithms, modes)
packets carrying corresponding SDES items. If the security level is as applied to RTCP packets carrying corresponding SDES items. If the
chosen to be different for an SDES item in RTCP and RTP header security level is chosen to be different for an SDES item in RTCP and
extension, it is important to motivate the exception, and to consider an RTP header extension, it is important to justify the exception and
the security properties as the worst in each aspect for the different to consider the security properties as the worst in each aspect for
configurations. It is worth noting that the current Secure RTP the different configurations. It is worth noting that the current
(SRTP) [RFC3711] only provides protection for the next trusted RTP/ SRTP [RFC3711] only provides protection for the next trusted RTP/RTCP
RTCP hop, which is not necessarily end-to-end. hop, which is not necessarily end to end.
The general RTP header extension mechanism [RFC5285] does not itself The general RTP header extension mechanism [RFC5285] does not itself
contain any functionality that is a significant risk for a denial of contain any functionality that is a significant risk for a
service attack, neither from processing nor storage requirements. denial-of-service attack, neither from processing nor from storage
The extension for SDES items defined in this document, can requirements. The extension for SDES items defined in this document
potentially be a risk. The risk depends on the received SDES item can potentially be a risk. The risk depends on the received SDES
and its content. If the SDES item causes the receiver to perform a item and its content. If the SDES item causes the receiver to
large amount of processing, create significant storage structures, or perform a large amount of processing, create significant storage
emit network traffic, such a risk does exist. The CNAME SDES item in structures, or emit network traffic, such a risk does exist. The
the RTP header extension is only a minor risk, as reception of a CNAME SDES item in the RTP header extension is only a minor risk, as
CNAME item will create an association between the stream carrying the reception of a CNAME item will create an association between the
SDES item and other RTP streams with the same SDES item. This stream carrying the SDES item and other RTP streams with the same
usually results in time synchronizing the media streams, thus some SDES item. This usually results in time synchronizing the media
additional processing is performed. However, the application's media streams; thus, some additional processing is performed. However, the
quality is likely more affected by an erroneous or changing application's media quality is likely more affected by an erroneous
association and media synchronization, than the application quality or changing association and media synchronization than the
impact caused by the additional processing. application quality impact caused by the additional processing.
As the SDES items are used by the RTP based application to establish As the SDES items are used by the RTP-based application to establish
relationships between RTP streams or between an RTP stream and relationships between RTP streams or between an RTP stream and
information about the originating participant, there SHOULD be strong information about the originating participant, there SHOULD be strong
integrity protection and source authentication of the header integrity protection and source authentication of the header
extensions. If not, an attacker can modify the SDES item value to extensions. If not, an attacker can modify the SDES item value to
create erroneous relationship bindings in the receiving application. create erroneous relationship bindings in the receiving application.
For information regarding options for securing RTP, see [RFC7201]. For information regarding options for securing RTP, see [RFC7201].
7. Acknowledgments 7. References
The authors likes to thank the following individuals for feedback and
suggestions: Colin Perkins, Ben Campbell, and Samuel Weiler.
8. References
8.1. Normative References 7.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>.
[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>.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July
2008, <http://www.rfc-editor.org/info/rfc5285>. 2008, <http://www.rfc-editor.org/info/rfc5285>.
[RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure
Real-time Transport Protocol (SRTP)", RFC 6904, Real-time Transport Protocol (SRTP)", RFC 6904,
DOI 10.17487/RFC6904, April 2013, DOI 10.17487/RFC6904, April 2013,
<http://www.rfc-editor.org/info/rfc6904>. <http://www.rfc-editor.org/info/rfc6904>.
8.2. Informative References 7.2. Informative References
[I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-30 (work in progress), June 2016.
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
"RTP Control Protocol Extended Reports (RTCP XR)", "RTP Control Protocol Extended Reports (RTCP XR)",
RFC 3611, DOI 10.17487/RFC3611, November 2003, RFC 3611, DOI 10.17487/RFC3611, November 2003,
<http://www.rfc-editor.org/info/rfc3611>. <http://www.rfc-editor.org/info/rfc3611>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <http://www.rfc-editor.org/info/rfc3629>. 2003, <http://www.rfc-editor.org/info/rfc3629>.
skipping to change at page 15, line 25 skipping to change at page 15, line 29
[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, DOI 10.17487/RFC5109, December Correction", RFC 5109, DOI 10.17487/RFC5109, December
2007, <http://www.rfc-editor.org/info/rfc5109>. 2007, <http://www.rfc-editor.org/info/rfc5109>.
[RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression [RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression
Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and
UDP-Lite", RFC 5225, DOI 10.17487/RFC5225, April 2008, UDP-Lite", RFC 5225, DOI 10.17487/RFC5225, April 2008,
<http://www.rfc-editor.org/info/rfc5225>. <http://www.rfc-editor.org/info/rfc5225>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[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>.
[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>.
skipping to change at page 16, line 5 skipping to change at page 16, line 15
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
<http://www.rfc-editor.org/info/rfc7201>. <http://www.rfc-editor.org/info/rfc7201>.
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms
for Real-Time Transport Protocol (RTP) Sources", RFC 7656, for Real-Time Transport Protocol (RTP) Sources", RFC 7656,
DOI 10.17487/RFC7656, November 2015, DOI 10.17487/RFC7656, November 2015,
<http://www.rfc-editor.org/info/rfc7656>. <http://www.rfc-editor.org/info/rfc7656>.
[SDP-BUNDLE]
Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", Work in Progress,
draft-ietf-mmusic-sdp-bundle-negotiation-32, August 2016.
Acknowledgments
The authors would like to thank the following individuals for
feedback and suggestions: Colin Perkins, Ben Campbell, and Samuel
Weiler.
Authors' Addresses Authors' Addresses
Magnus Westerlund Magnus Westerlund
Ericsson Ericsson
Farogatan 6 Farogatan 6
SE-164 80 Stockholm SE-164 80 Stockholm
Sweden Sweden
Phone: +46 10 714 82 87 Phone: +46 10 714 82 87
Email: magnus.westerlund@ericsson.com Email: magnus.westerlund@ericsson.com
skipping to change at page 16, line 35 skipping to change at page 17, line 41
Huawei Technologies Huawei Technologies
Tel Aviv Tel Aviv
Israel Israel
Email: roni.even@mail01.huawei.com Email: roni.even@mail01.huawei.com
Mo Zanaty Mo Zanaty
Cisco Systems Cisco Systems
7100 Kit Creek 7100 Kit Creek
RTP, NC 27709 RTP, NC 27709
USA United States of America
Email: mzanaty@cisco.com Email: mzanaty@cisco.com
 End of changes. 101 change blocks. 
261 lines changed or deleted 264 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/