One document matched: draft-ietf-avtext-sdes-hdr-ext-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-avtext-sdes-hdr-ext-00"
ipr="trust200902">
<front>
<title abbrev="RTP HE for RTCP SDES">RTP Header Extension for RTCP Source
Description Items</title>
<author fullname="Magnus Westerlund" initials="M." surname="Westerlund">
<organization>Ericsson</organization>
<address>
<postal>
<street>Farogatan 6</street>
<city>SE-164 80 Stockholm</city>
<country>Sweden</country>
</postal>
<phone>+46 10 714 82 87</phone>
<email>magnus.westerlund@ericsson.com</email>
</address>
</author>
<author fullname="Bo Burman" initials="B." surname="Burman">
<organization>Ericsson</organization>
<address>
<postal>
<street>Kistavagen 25</street>
<city>SE-164 80 Stockholm</city>
<country>Sweden</country>
</postal>
<phone>+46 10 714 13 11</phone>
<email>bo.burman@ericsson.com</email>
</address>
</author>
<author fullname="Roni Even" initials="R." surname="Even">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street/>
<city>Tel Aviv</city>
<region/>
<code/>
<country>Israel</country>
</postal>
<phone/>
<facsimile/>
<email>roni.even@mail01.huawei.com</email>
<uri/>
</address>
</author>
<author fullname="Mo Zanaty" initials="M." surname="Zanaty">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>7100 Kit Creek</street>
<city>RTP</city>
<region>NC</region>
<code>27709</code>
<country>USA</country>
</postal>
<phone/>
<facsimile/>
<email>mzanaty@cisco.com</email>
<uri/>
</address>
</author>
<date year=""/>
<abstract>
<t>Source Description (SDES) items are normally transported in RTP
control protocol (RTCP). In some cases it can be beneficial to speed up
the delivery of these items. Mainly when a new source (SSRC) joins an
RTP session and the receivers needs this source's relation to other
sources and its synchronization context, which are fully or partially
identified using SDES items. To enable this optimization, this document
specifies a new RTP header extension that can carry any type of SDES
items.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This specification defines an <xref target="RFC3550">RTP header
extension</xref><xref target="RFC5285"/> that can carry RTCP source
description (SDES) items. By including selected SDES items in an header
extension the determination of relationship and synchronization context
for new RTP streams (SSRCs) in an RTP session can be speeded up. Which
relationship and what information depends on the SDES items carried.
This becomes a complement to using only RTCP for SDES Item delivery.</t>
<t>First, some requirements language is defined. The following section
motivates why this header extension is sometimes required or at least
provides a significant improvement compared to waiting for regular RTCP
packet transmissions of the information. This is followed by a
specification of the header extension. Next, a sub-space of the
header-extension URN is defined to be used for existing and future SDES
items, and the existing SDES items are registered.</t>
</section>
<section title="Definitions">
<t/>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
<section title="Terminology">
<t>This document uses terminology defined in <xref
target="I-D.ietf-avtext-rtp-grouping-taxonomy">"A Taxonomy of Grouping
Semantics and Mechanisms for Real-Time Transport Protocol (RTP)
Sources"</xref> . In particular the following definitions:<list
style="empty">
<t>Media Source</t>
<t>RTP Stream</t>
<t>Media Encoder</t>
<t>Encoded Stream</t>
<t>Participant</t>
</list></t>
<t/>
</section>
</section>
<section title="Motivation">
<t>Source Description (SDES) items are being associated with a
particular SSRC and thus RTP stream. The source description items
provide various 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 the item itself. The CNAME item is one item that is commonly
needed if not at reception of the first RTP packet for this SSRC, so at
least by the time the first media can be played out. If not, the
synchronization context cannot be determined and thus any related
streams cannot be correctly synchronized. Thus, this is a great example
for the need to have this information early when a new RTP stream is
received.</t>
<t>The main reason for new SSRCs in an RTP session is that a media
sources are added. This either because an end-point is adding a new
actual media source, or additional participants in a multi-party session
being added to the session. Another reason for a new SSRC can be an SSRC
collision that forces the colliding parties to select a new SSRC.</t>
<t>Returning to the case of rapid media synchronization, there exist an
RTP header extension for <xref target="RFC6051">Rapid Synchronization of
RTP Flows</xref>. That header extension carries the clock information
present in the RTCP sender report (SR) packets. It however assumes that
the CNAME binding is known, which can be provided via signaling in some
cases, but not all. Thus an RTP header extension for carrying SDES items
like CNAME is a powerful combination to enable rapid synchronization in
all cases.</t>
<t>The Rapid Synchronization of RTP Flows specification does provide an
analysis of the initial synchronization delay for different sessions
depending on number of receivers as well as on session bandwidth
(Section 2.1 of <xref target="RFC6051"/>). These results are applicable
also for other SDES items that have a similar time dependency until the
information can be sent using RTCP. Thus the benefit for reduction of
initial delay before information is available can be determined for some
use cases from these figures.</t>
<t>That document also discusses the case of late joiners, and defines an
RTCP Feedback format to request synchronization information, which is
another potential use case for SDES items in RTP header extension. It
would for example be natural to include CNAME SDES item with the header
extension containing the NTP formatted reference clock to ensure
synchronization.</t>
<t>Some new SDES items are currently proposed, which can all benefit
from timely delivery:<list style="hanging">
<t hangText="MID:">This is a media description identifier that
matches the value of the SDP a=mid attribute, to associate RTP
streams multiplexed on the same transport with their respective SDP
media description as described in <xref
target="I-D.ietf-mmusic-sdp-bundle-negotiation"/>.</t>
<t hangText="SRCNAME:">This is a media source and encoding
identifier to enable support for simulcast and improve some scalable
encoding usages <xref
target="I-D.westerlund-avtext-rtcp-sdes-srcname"/>. This SDES item
could be used both for new sources and late joiners.</t>
<t hangText="APPID:">This SDES item provides an application specific
identifier dynamically assigned to a particular RTP stream. The
intention is to provide a receiver with information about the
current role of the received RTP stream or its usage in an
application <xref target="I-D.even-mmusic-application-token"/>. Thus
a particular ID can be reassigned many times during the lifetime of
an RTP session. This puts additional timing requirements, not only
for new sources and late joiners, but also whenever the Application
token is reassigned to another stream.</t>
</list></t>
<t>Based on the above, there appear to be good reasons why an RTP header
extension for SDES items is worthwhile to pursue.</t>
</section>
<section title="Specification">
<t>This section first specifies the SDES item RTP header extension
format, followed by some usage considerations.</t>
<section title="SDES Item Header Extension">
<t>The RTP header extension scheme that allows for multiple extensions
to be included is defined in <xref target="RFC5285">"A General
Mechanism for RTP Header Extensions"</xref>. That specification
defines both short and long item headers. The 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 bytes. Thus that RTP
header extension format is capable of supporting any SDES item from a
data length perspective.</t>
<t>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
header extension, the type of SDES item. The mapping is done in
signaling by identifying the header extension and SDES item type using
a URN, which is defined in the <xref target="IANA">IANA
consideration</xref> for all existing SDES items.</t>
<section title="One-Byte Format">
<t>The one-byte header format for an SDES item extension element
consists of the One-Byte header (defined in Section 4.2 of <xref
target="RFC5285"/>), which consists of a 4-bit ID followed by a
4-bit length field (len) that identifies how many bytes (len value
+1) of data that follows the header. The data part consists of len+1
bytes of UTF-8 text. The type of text is determined by the ID field
value and its mapping to the type of SDES item.</t>
<figure anchor="fig-short-header">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | len | SDES Item text value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</section>
<section title="Two-Byte Format">
<t>The two-byte header format for an SDES item extension element
consists of the two-byte header (defined in Section 4.3 of <xref
target="RFC5285"/>), which consists of an 8-bit ID followed by an
8-bit length field (len) that identifies how many bytes of data that
follows the header. The data part consists of len bytes of UTF-8
text. The type of text is determined by the ID field value and its
mapping to the type of SDES item.</t>
<figure anchor="fig-long-header">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | len | SDES Item text value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t/>
</section>
</section>
<section title="Usage of the SDES Item Header Extension">
<t>This section discusses various usage considerations; which form of
header extension to use, the packet expansion, and when to send SDES
items in header extension.</t>
<section title="One or Two Byte Headers">
<t>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 used SDES items. The one-byte header SHOULD be used
when all non SDES item header extensions supports the one-byte
format and all SDES item text values contain at most 16 bytes. Note
that the RTP header extension 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 items value requires the two-byte
header, the all other header extensions MUST also use the two-byte
header format.</t>
<t>For example using CNAMEs that are generated according to <xref
target="RFC7022">"Guidelines for Choosing RTP Control Protocol
(RTCP) Canonical Names (CNAMEs)"</xref>, using short term persistent
values, and if 96-bit random values prior to base64 encoding are
sufficient, then they will fit into the One-Byte header format.</t>
</section>
<section title="MTU and Packet Expansion">
<t>The RTP packet size will clearly increase when they include the
header extension. How much depends on which header extensions and
their data parts. The SDES items can vary in size. There are also
some use-cases which require transmitting multiple SDES items in the
same packet to ensure that all relevant data reaches the receiver.
An example of that is when you need both the CNAME, a SRCNAME and an
appId plus the rapid time synchronization extension from RFC 6051.
Such a combination is quite likely to result in at least 16+3+1+8
bytes of data plus the headers, which will be another 8 bytes for
one-byte headers, thus in total 36 bytes.</t>
<t>The packet expansion can cause an issue when it cannot be taken
into account when producing the RTP payload. Thus an RTP payload
that is created to meet a particular IP level Maximum Transmission
Unit (MTU), taking the addition of IP/UDP/RTP headers into account
but excluding RTP header extensions suddenly exceeds the MTU,
resulting in IP fragmentation. IP fragmentation is known to
negatively impact the loss rate due to middleboxes unwilling or not
capable of dealing with IP fragments.</t>
<t>As this is a real issue, the media encoder and payload packetizer
should be flexible and be capable of handling dynamically varying
payload size restrictions to counter the packet expansion caused by
header extensions. If that is not possible, some reasonable worst
case packet expansion should be calculated and used to reduce the
RTP payload size of all RTP packets the sender transmits.</t>
</section>
<section title="Transmission Considerations">
<t>The general recommendation is to only send header extensions when
needed. This is especially true for SDES items that can be sent in
periodic repetitions of RTCP throughout the whole session. Thus, the
<xref target="sec-different-usages">different usages</xref> have
different recommendations. First some general considerations for
getting the header extensions delivered to the receiver:<list
style="numbers">
<t>The probability for packet loss and burst loss determine how
many repetitions of the header extensions will be required to
reach a targeted delivery probability, and if bust loss is
likely what dispersion would be needed to avoid getting multiple
header extensions lost in a single burst.</t>
<t>How early the SDES item information is needed, from the first
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 first N packets or be included only once per set of
packets, for example once per video frame.</t>
<t>The use of RTP level robustness mechanisms, such as <xref
target="RFC4588">RTP retransmission</xref>, or Forward Error
Correction, e.g., <xref target="RFC5109"> </xref> may treat
packets differently from a robustness perspective, and SDES
header extensions should be added to packets that get a
treatment corresponding to the relative importance of receiving
the information.</t>
</list></t>
<t>In summary, the number of header extension transmissions should
be tailored to a desired probability of delivery taking the receiver
population size into account. For the very basic case, N repetitions
of the header extensions should be sufficient, but may not be
optimal. N is selected so that probability of delivery of at least
one out of the N reaches the target value when calculating 1-P^N,
where P is the probability of packet loss. For point to point or
small receiver populations, it might also be possible to use
feedback, such as RTCP, to determine when the information in the
header extensions has likely reached all receivers.</t>
</section>
<section anchor="sec-different-usages" title="Different Usages">
<t/>
<section anchor="sec-new-ssrc" title="New SSRC">
<t>A new SSRC joins an RTP session. As this SSRC is completely new
for everyone, the goal is to ensure that all receivers with high
probability receives the information in the header extension. Thus
header extension transmission strategies that allow some margins
in the delivery probability should be considered.</t>
</section>
<section title="Late Joiner">
<t>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 necessary information, the use of header extensions to
deliver relevant information should be tailored to reach the new
receivers. The trigger to send header extensions can for example
either be RTCP from new receiver(s) or an explicit request like
the Rapid Resynchronization Request defined in <xref
target="RFC6051"/>.</t>
</section>
<section title="Information Change">
<t>In cases when the SDES item text value is changed and the new
SDES information is tightly coupled to and thus needs to be
synchronized with a related change in the RTP stream, use of a
header extension is far superior to RTCP SDES. In this case it is
equal or even more important with timely SDES information than in
the case of <xref target="sec-new-ssrc">new SSRCs</xref>.
Continued use of the old SDES information can lead to really
undesired effects in the application. <xref
target="I-D.even-mmusic-application-token">Application
Token</xref> would be one such case. Thus, header extension
transmission strategies with high probability of delivery should
be chosen.</t>
</section>
</section>
<section title="SDES Items in RTCP">
<t>As this RTP header extensions information, i.e. SDES Items can
and will be sent also in RTCP it is worth some reflections on this
interaction. There also exist the possibility to schedule a
non-regular RTCP packet transmission containing important SDES items
if one uses a RTP/AVPF based RTP profile. Depending on which mode
ones RTCP feedback transmitter is working on extra RTCP packets may
be sent as immediate or early packets, enabling more timely deliver
of SDES information.</t>
<t>There is however two aspects that differ between using RTP header
extension and any non-regular transmission of RTCP packets. First,
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 information. The order of arrival for the packets will matter.
With a header-extension the SDES items can be ensured to arrive if
the media data to played out arrives. Secondly, it is difficult to
determine if an RTCP packet is actually delivered. This, as the RTCP
packets lack both sequence number or a mechanism providing feedback
on the RTCP packets themselves.</t>
</section>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This IANA section firstly proposes to:<list style="symbols">
<t>Reserve the SDES item RTP header extension defined in this
document for use with current and future SDES items.</t>
<t>Register and assign the URN sub-space
"urn:ietf:params:rtp-hdrext:sdes:" in the RTP Compact Header
Extensions registry.</t>
</list></t>
<t>The reason to require registering a URN within that sub-space is that
the name represent an RTCP Source Description item, where a
specification is strongly recommended. The formal policy is maintained
from the main space, i.e. Expert Review.</t>
<t>Secondly, it is proposed that only the current existing SDES items
that are critical for immediate media processing, and therefore should
fate share their delivery with RTP media, are registered for usage in
the RTP Compact Header Extensions registry :</t>
<figure>
<artwork><![CDATA[URN SDES Item Reference
==================================================================
urn:ietf:params:rtp-hdrext:sdes:cname CNAME [RFC3550]
]]></artwork>
</figure>
<t/>
</section>
<section anchor="Security" title="Security Considerations">
<t>Source Description items may contain data that are sensitive from a
security perspective. There exist SDES items that are or may be
sensitive from a user privacy perspective, like CNAME, NAME, EMAIL,
PHONE, LOC and H323-CADDR. Others may contain sensitive information like
NOTE and PRIV, while others may be sensitive from profiling
implementations for vulnerability or other reasons, like TOOL. The CNAME
sensitivity can vary depending on how it is generated and what
persistence it has. A short term CNAME identifier generated using a
random number generator may have minimal security implications, while
one of the form user@host has privacy concerns and one generated from a
MAC address has long term tracking potentials.</t>
<t>The above security concerns may have to be put in relation to needs
of third party monitoring. In RTP sessions where any type of
confidentiality protection is enabled, the SDES item header extensions
SHOULD also be protected per default. This implies that to provide
confidentiality, users of SRTP need to implement encrypted header
extensions per <xref target="RFC6904"/>. Commonly, it is expected that
the same security level is applied both RTCP packets carrying SDES
items, as a RTP header extension containing a SDES item. If the security
level is different it is important to consider the security properties
as the worst in each aspect for the different configurations.</t>
<t>As the SDES items are used by the RTP based application to establish
relationships between RTP streams or between an RTP stream and
information about the originating Participant, there SHOULD be strong
requirements on integrity and source authentication of the header
extensions. If not, an attacker can modify the SDES item value to create
erroneous relationship bindings in the receiving application.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors likes to thanks the following individuals for feedback
and suggestions; Colin Perkins.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.RFC.3550'?>
<?rfc include='reference.RFC.5285'?>
<?rfc include='reference.RFC.6904'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.4588'?>
<?rfc include='reference.RFC.5109'?>
<?rfc include='reference.RFC.6051'?>
<?rfc include='reference.RFC.6776'?>
<?rfc include='reference.RFC.7022'?>
<?rfc include='reference.I-D.ietf-mmusic-sdp-bundle-negotiation'?>
<?rfc include='reference.I-D.even-mmusic-application-token'?>
<?rfc include='reference.I-D.ietf-avtext-rtp-grouping-taxonomy'?>
<?rfc include='reference.I-D.westerlund-avtext-rtcp-sdes-srcname'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:47:09 |