draft-ietf-avtext-sdes-hdr-ext-02.txt   draft-ietf-avtext-sdes-hdr-ext-03.txt 
Network Working Group M. Westerlund Network Working Group M. Westerlund
Internet-Draft B. Burman Internet-Draft B. Burman
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: January 7, 2016 R. Even Expires: August 18, 2016 R. Even
Huawei Technologies Huawei Technologies
M. Zanaty M. Zanaty
Cisco Systems Cisco Systems
July 6, 2015 February 15, 2016
RTP Header Extension for RTCP Source Description Items RTP Header Extension for RTCP Source Description Items
draft-ietf-avtext-sdes-hdr-ext-02 draft-ietf-avtext-sdes-hdr-ext-03
Abstract Abstract
Source Description (SDES) items are normally transported in RTP Source Description (SDES) items are normally transported in RTP
control protocol (RTCP). In some cases it can be beneficial to speed control protocol (RTCP). In some cases it can be beneficial to speed
up the delivery of these items. Mainly when a new source (SSRC) up the delivery of these items. Mainly when a new source (SSRC)
joins an RTP session and the receivers needs this source's identity, joins an RTP session and the receivers needs this source's identity,
relation to other sources, or its synchronization context, all of relation to other sources, or its synchronization context, all of
which may be fully or partially identified using SDES items. To which may be fully or partially identified using SDES items. To
enable this optimization, this document specifies a new RTP header enable this optimization, this document specifies a new RTP header
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 January 7, 2016. This Internet-Draft will expire on August 18, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . . . 5
4.1.2. Two-Byte Format . . . . . . . . . . . . . . . . . . . 6 4.1.2. Two-Byte Format . . . . . . . . . . . . . . . . . . . 5
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 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 . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . 9
4.2.6. Update Flaps . . . . . . . . . . . . . . . . . . . . 10 4.2.6. Update Flaps . . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5.1. Reservation of the SDES URN sub-space . . . . . . . . . . 11 5.1. Reservation of the SDES URN sub-space . . . . . . . . . . 11
5.2. Registration of SDES Items . . . . . . . . . . . . . . . 11 5.2. Registration of SDES Items . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
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. By including that can carry RTCP source description (SDES) items. By including
selected SDES items in a header extension the determination of selected SDES items in a header extension the determination of
relationship and synchronization context for new RTP streams (SSRCs) relationship and synchronization context for new RTP streams (SSRCs)
in an RTP session can be optimized. Which relationship and what in an RTP session can be optimized. Which relationship and what
skipping to change at page 3, line 35 skipping to change at page 3, line 35
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 Grouping This document uses terminology defined in "A Taxonomy of Semantics
Semantics and Mechanisms for Real-Time Transport Protocol (RTP) and Mechanisms for Real-Time Transport Protocol (RTP) Sources"
Sources" [I-D.ietf-avtext-rtp-grouping-taxonomy]. In particular the [RFC7656]. In particular the following definitions:
following definitions:
Media Source Media Source
RTP Stream RTP Stream
Media Encoder Media Encoder
Encoded Stream
Participant Participant
3. Motivation 3. Motivation
Source Description (SDES) items are associated with a particular SSRC Source Description (SDES) items are associated with a particular SSRC
and thus RTP stream. The source description items provide various and thus RTP stream. The source description items provide various
meta data associated with the SSRC. How important it is to have this meta data 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 receiving the first RTP packets 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
skipping to change at page 5, line 36 skipping to change at page 5, line 32
The ID field, independent of short or long format, identifies both The ID field, independent of 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 the IANA consideration (Section 5)
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
text. The type of text and its mapping to the SDES item type is text. The type of text and its mapping to the SDES item type is
determined by the ID field value. 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 ... |
skipping to change at page 6, line 46 skipping to change at page 6, line 40
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 does not allow mixing one-byte and two-byte headers for
the same RTP stream (SSRC), so if the value size of any of the SDES the same RTP stream (SSRC), so if the value size of any of the SDES
items value requires the two-byte header, then all other header items value requires the two-byte header, then all other header
extensions MUST also use the two-byte header format. extensions MUST also use the two-byte header format.
For example using CNAMEs that are generated according to "Guidelines For example using CNAMEs that are generated according to "Guidelines
for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)" for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)"
[RFC7022], using short term persistent values, and if 96-bit random [RFC7022], using short term persistent values, and if 96-bit random
values prior to base64 encoding are sufficient, then they will fit values prior to base64 encoding are sufficient, then they will fit
into the One-Byte header format. 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
to 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 Secondly, it needs to know the size of the SDES items that are going
to be included, and use two bytes headers if any are longer than 16 to be included, and use two bytes headers if any are longer than 16
bytes. An RTP middlebox that forwards a stream, i.e. not mixing it bytes. An RTP middlebox that forwards a stream, i.e. not mixing it
or combing it with other streams, may be able to base its choice on or combing 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.
skipping to change at page 7, line 27 skipping to change at page 7, line 22
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 both CNAME, a MID, and the rapid time
synchronization extension from RFC 6051 are needed. Such a synchronization extension from RFC 6051 are 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 word aligned, thus in total 36 bytes. extension word aligned, thus in total 36 bytes.
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
skipping to change at page 8, line 41 skipping to change at page 8, line 37
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. N is selected so that the header extension target delivery optimal. 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
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 XR Loss RLE report block [RFC3611], which will indicate
succesful delivery of particular packets. If the RTP/AVPF Transport successful delivery of particular packets. If the RTP/AVPF Transport
Layer Feedback Messages for generic NACK [RFC4585] is used, it can Layer Feedback Messages for generic NACK [RFC4585] is used, it can
indicate the failure to deliver an RTP packet with the header 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 succesful 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
skipping to change at page 9, line 42 skipping to change at page 9, line 42
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 extensions 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 which mode one's RTCP feedback transmitter is
working on, extra RTCP packets may be sent as immediate or early working on, extra RTCP packets may be sent as immediate or early
packets, enabling more timely SDES information delivery. 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. Secondly, it is difficult to
determine if an RTCP packet is actually delivered. This, as the RTCP determine if an RTCP packet is actually delivered. This, as the RTCP
packets lack both sequence number or a mechanism providing feedback packets lack both sequence number and a mechanism providing feedback
on the RTCP packets themselves. on the RTCP 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 performing some However, most of these issues can be avoided in the receiver by
checks before updating the receiver's stored value. To handle flaps performing some checks before updating the receiver's stored value.
caused by reordering, only SDES items received in RTP packets with a To handle flaps caused by reordering, only SDES items received in RTP
higher extended sequence number than the last change shall be packets with a higher extended sequence number than the last change
applied, i.e. discard items that can be determined to be older than shall be applied, i.e. discard items that can be determined to be
the current one. For compound RTCP packets, which will contain an older than the current one. For compound RTCP packets, which will
Sender Report (SR) packet (assuming an active RTP sender), the contain an Sender Report (SR) packet (assuming an active RTP sender),
receiver can compare the RTCP Sender Report's Timestamp field, to the receiver can use the RTCP SR Timestamp field to determine at what
determine at what approximate time it was transmitted. If the approximate time it was transmitted. If the timestamp is earlier
timestamp is earlier than the last received RTP packet extension than the last received RTP packet with a header extension carrying an
carrying an SDES item, and especially if carrying a previously used SDES item, and especially if carrying a previously used value, the
value, the SDES item in the RTCP SDES packet can be ignored. Note SDES item in the RTCP SDES packet can be ignored. Note that media
that media processing and transmission pacing can easily cause the processing and transmission pacing can easily cause the RTP header
RTP header timestamp field as well as the RTCP SR timestamp field to timestamp field as well as the RTCP SR timestamp field to not match
not match with the actual transmission time. with the actual transmission time.
5. IANA Considerations 5. IANA Considerations
This section makes the following requests to IANA: This section makes the following requests to IANA:
o Register and reserve for SDES items the URN sub-space o Register and reserve for SDES items the URN sub-space
"urn:ietf:params:rtp-hdrext:sdes:" in the RTP Compact Header "urn:ietf:params:rtp-hdrext:sdes:" in the RTP Compact Header
Extensions registry. Extensions registry.
o Register the SDES items appropriate for use with the RTP header o Register the SDES items appropriate for use with the RTP header
extension defined in this document. extension defined in this document.
5.1. Reservation of the SDES URN sub-space 5.1. Reservation of the SDES URN sub-space
The reason to require registering a URN within an SDES sub-space is The reason to require registering a URN within an SDES sub-space is
that the name represents an RTCP Source Description item, where a that the name represents an RTCP Source Description item, where a
specification is strongly recommended. The formal policy is specification is strongly recommended. The formal policy is
maintained from the main space, i.e. Expert Review. However, some maintained from the main space, as specified by [RFC5285], i.e.
additional considerations are provided here that needs to be Expert Review. However, the following additional items need to be
considered when applying for a registration within this sub-space of considered when applying for a registration within this sub-space of
the RTP Compact Header Extensions registry. the RTP Compact Header Extensions registry:
Any registration using an Extension URI that starts with o Any registration using an Extension URI that starts with
"urn:ietf:params:rtp-hdrext:sdes:" MUST also have a registered Source "urn:ietf:params:rtp-hdrext:sdes:" MUST also have a registered
Description item in the "RTP SDES item types" registry. Secondly, a Source Description item in the "RTP SDES item types" registry.
security and privacy consideration for the SDES item must be provided
with the registration, preferably in a publicly available reference. o Secondly, a security and privacy consideration for the SDES item
Thirdly, information must be provided on why this SDES item requires must be provided with the registration.
timely delivery, motivating it to be transported in an header
extension rather than as RTCP only. o Thirdly, information must be provided on why this SDES item
requires timely delivery, motivating it to be transported in a
header extension rather than as RTCP only.
IANA is requested to register the below in the RTP Compact Header IANA is requested to register the below in the RTP Compact Header
Extensions: Extensions:
Extension URI: urn:ietf:params:rtp-hdrext:sdes Extension URI: urn:ietf:params:rtp-hdrext:sdes
Description: Reserved as base URN for SDES items that are also Description: Reserved as base URN for SDES items that are also
defined as RTP Compact header extensions. defined as RTP Compact header extensions.
Contact: Authors of [RFCXXXX] Contact: Authors of [RFCXXXX]
Reference: [RFCXXXX] Reference: [RFCXXXX]
RFC-editor note: Please replace all occurances of RFCXXXX with the RFC-editor note: Please replace all occurrences of RFCXXXX with the
RFC number this specification receives when published. RFC number this specification receives when published.
5.2. Registration of SDES Items 5.2. Registration of SDES Items
It is requested that the following SDES item is registered in the RTP It is requested that the following SDES item is registered in the RTP
Compact Header Extensions registry: 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)
skipping to change at page 12, line 24 skipping to change at page 12, line 31
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 MAC address has long term
tracking potentials. 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 per default. This implies that to provide confidentiality, protected. This implies that to provide confidentiality, users of
users of SRTP need to implement encrypted header extensions per SRTP need to implement and use encrypted header extensions per
[RFC6904]. Commonly, it is expected that the same security level is [RFC6904]. The security level that is applied to RTCP packets
applied to RTCP packets carrying SDES items, and to an RTP header carrying SDES items SHOULD also be applied to SDES items carried as
extension containing SDES items. If the security level is different, RTP header extensions. If the security level is chosen to be
it is important to consider the security properties as the worst in different for an SDES item in RTCP and RTP header extension, it is
each aspect for the different configurations. important to motivate the exception, and to consider the security
properties as the worst in each aspect for the different
configurations.
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
requirements on integrity 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.
7. Acknowledgements 7. Acknowledgements
The authors likes to thanks the following individuals for feedback The authors likes to thank the following individuals for feedback and
and suggestions; Colin Perkins. suggestions; Colin Perkins.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<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, July 2003. Applications", STD 64, RFC 3550, DOI 10.17487/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, July 2008. Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July
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, April Real-time Transport Protocol (SRTP)", RFC 6904,
2013. DOI 10.17487/RFC6904, April 2013,
<http://www.rfc-editor.org/info/rfc6904>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-avtext-rtp-grouping-taxonomy]
Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, "A Taxonomy of Semantics and Mechanisms for
Real-Time Transport Protocol (RTP) Sources", draft-ietf-
avtext-rtp-grouping-taxonomy-07 (work in progress), June
2015.
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-22 (work in progress), June 2015. negotiation-25 (work in progress), January 2016.
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
Protocol Extended Reports (RTCP XR)", RFC 3611, November "RTP Control Protocol Extended Reports (RTCP XR)",
2003. RFC 3611, DOI 10.17487/RFC3611, November 2003,
<http://www.rfc-editor.org/info/rfc3611>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
2006. DOI 10.17487/RFC4585, July 2006,
<http://www.rfc-editor.org/info/rfc4585>.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006. DOI 10.17487/RFC4588, July 2006,
<http://www.rfc-editor.org/info/rfc4588>.
[RFC5109] Li, A., "RTP Payload Format for Generic Forward Error [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, December 2007. Correction", RFC 5109, DOI 10.17487/RFC5109, December
2007, <http://www.rfc-editor.org/info/rfc5109>.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, June 2009. (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009,
<http://www.rfc-editor.org/info/rfc5576>.
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
Flows", RFC 6051, November 2010. Flows", RFC 6051, DOI 10.17487/RFC6051, November 2010,
<http://www.rfc-editor.org/info/rfc6051>.
[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla,
"Guidelines for Choosing RTP Control Protocol (RTCP) "Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs)", RFC 7022, September 2013. Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022,
September 2013, <http://www.rfc-editor.org/info/rfc7022>.
[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>.
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
 End of changes. 41 change blocks. 
88 lines changed or deleted 101 lines changed or added

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