One document matched: draft-ietf-avtext-sdes-hdr-ext-06.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-06"
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>Stockholm</city>
<code>16480</code>
<country>Sweden</country>
</postal>
<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 day="26" month="April" year="2016"/>
<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 identity, relation to
other sources, or its synchronization context, all of which may be fully
or partially identified using SDES items. To enable this optimization,
this document specifies a new RTP header extension that can carry 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. Normally the SDES items are carried in their
own <xref target="RFC3550">RTCP packet type</xref>. By including selected SDES items in a header
extension the determination of relationship and synchronization context
for new RTP streams (SSRCs) in an RTP session can be optimized. 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>It is important to note that not all SDES items are appropriate to
transmit using RTP header extensions. Some SDES items performs binding
or identifies synchronization context with strict timeliness
requirements, while many other SDES items do not have such requirements.
In addition, security and privacy concerns for the SDES item information
need to be considered. For example, the Name and Location SDES items are
highly sensitive from a privacy perspective and should not be
transported over the network without strong security. No use case has
identified where this information is required at the same time as the
first RTP packets arrive. A few seconds delay before such information is
available to the receiver appears acceptable. Therefore only appropriate
SDES items will be registered for use with this header extension, such
as CNAME.</t>
<t>First, some requirements language and terminology are 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 and usage
recommendations. Next, a sub-space of the header-extension URN is
defined to be used for existing and future SDES items, and then the
appropriate 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="RFC7656">"A
Taxonomy of 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>Participant</t>
</list></t>
<t/>
</section>
</section>
<section title="Motivation">
<t>Source Description (SDES) items are 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 either at
reception of the first RTP packet for this SSRC, or at least by the time
the first media can be played out. If it is not available, the
synchronization context cannot be determined and thus any related
streams cannot be correctly synchronized. Thus, this is a valuable
example for having this information early when a new RTP stream is
received.</t>
<t>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
actual media source, or additional participants in a multi-party 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 SSRCs.</t>
<t>For the case of rapid media synchronization, one may use the RTP
header extension for <xref target="RFC6051">Rapid Synchronization of RTP
Flows</xref>. This 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 <xref
target="RFC5576"/> 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. These figures can be used to
determine the benefit of reducing the initial delay before information
is available for some use cases.</t>
<t><xref target="RFC6051">Rapid Synchronization of RTP Flows</xref> 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>There is an another SDES item that can benefit from timely delivery,
and an RTP header extension SDES item was therefore defined for it:<list
style="hanging">
<t hangText="MID:">This is a media description identifier that
matches the value of the <xref target="RFC4566">Session Description
Protocol (SDP)</xref> 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>
</list></t>
<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>An RTP header extension scheme allowing for multiple extensions 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 the RTP header extension formats are 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 the known SDES items appropriate to use.</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 the number of data bytes
(len value +1) 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 determined by the ID field value.</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 the number of data bytes
following the 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 field value.</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 and the requirement from any other
header extensions 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 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,
then 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>
<t>An RTP middlebox needs to take care choosing between one-byte
headers and two-byte headers when creating the first packets for an
outgoing stream (SSRC) with header extensions. First of all it needs
to consider all the header extensions that may potentially be used.
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
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
the header size in incoming streams. This is assuming that the
middlebox does not modify the stream or add additional header
extensions to the stream it sends, in which case it needs to make
its own decision.</t>
</section>
<section title="MTU and Packet Expansion">
<t>The RTP packet size will clearly increase when a header extension
is included. How much depends on the type of header extensions and
their data content. The SDES items can vary in size. There are also
some use-cases that require transmitting multiple SDES items in the
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
synchronization extension from RFC 6051 are needed. Such a
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
headers, plus two bytes of header padding to make the complete
header extension 32-bit word aligned, thus in total 36 bytes.</t>
<t>If the packet expansion cannot be taken into account when
producing the RTP payload, it can cause an issue. An RTP payload
that is created to meet a particular IP level Maximum Transmission
Unit (MTU), taking the addition of IP/UDP/RTP headers but not RTP
header extensions into account, could exceed the MTU when the header
extensions are present, thus 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,
as well as increasing the target surface for other types of packet
losses.</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 burst loss is
likely, what distribution would be needed to avoid getting all
repetitions of the header extensions lost in a single burst.</t>
<t>If a set of packets are all needed to enable decoding, there
is commonly no reason for including the header extension in all
of these packets, as they share fate. Instead, at most one
instance of the header extension per independently decodable set
of media data would be a more efficient use of the
bandwidth.</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>As a 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 the header extension target delivery
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 possible to use feedback, such as RTCP, to determine when
the information in the header extensions has reached all receivers
and stop further repetitions. Feedback that can be used includes the
<xref target="RFC3611">RTCP XR Loss RLE report block</xref>, which
will indicate successful delivery of particular packets. If the
RTP/AVPF <xref target="RFC4585">Transport Layer Feedback Messages
for generic NACK</xref> is used, it can indicate the failure to
deliver an RTP packet with the header extension, thus indicating the
need for further repetitions. The normal RTCP report blocks can also
provide an indicator of successful delivery, if no losses are
indicated for a reporting interval covering the RTP packets with the
header extension. Note that loss of an RTCP packet reporting on an
interval where RTP header extension packets were sent, does not
necessarily mean that the RTP header extension packets themselves
were lost.</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, with high probability, that
all RTP session participants 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"/>. In centralized topologies where an RTP
middlebox is present, it can be responsible for transmitting the
known information, possibly stored, to the new session participant
only, and not repeat it to all the session participants.</t>
</section>
<section title="Information Change">
<t>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 extension is superior to RTCP. Using the RTP header
extension ensures that the information is updated on reception of
the related RTP media, ensuring synchronization between the two.
Continued use of the old SDES information can lead to undesired
effects in the application. Thus, header extension transmission
strategies with high probability of delivery should be chosen.</t>
</section>
</section>
<section title="SDES Items in RTCP">
<t>The RTP header extension information, i.e., SDES items, can and
will be sent also in RTCP. Therefore, it is worth making some
reflections on this interaction. As an alternative to the header
extension, it is possible to schedule a non-regular RTCP packet
transmission containing important SDES items, if one uses an
RTP/AVPF-based RTP profile. Depending on which mode one's RTCP
feedback transmitter is working on, extra RTCP packets may be sent
as immediate or early packets, enabling more timely SDES information
delivery.</t>
<t>There are however two aspects that differ between using RTP
header extensions 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 play out arrives. Secondly, it is
difficult to determine if an RTCP packet is actually delivered.
This, as the RTCP packets lack both sequence number and a mechanism
providing feedback on the RTCP packets themselves.</t>
</section>
<section title="Update Flaps">
<t>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 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 an SDES item is delivered to the receiver after the
first RTP/RTCP packet with the updated value. The second reason is
the different code-paths for RTP and RTCP in implementations. An
update to the sender's SDES item parameter can take a different time
to propagate to the receiver than the corresponding media data. For
example, an 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 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 the RTCP packet being sent.</t>
<t>However, most of these issues can be avoided by the receiver
performing some checks before updating the receiver's stored value.
To handle flaps caused by reordering, SDES items received in RTP
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
determined to be older than the current one. For compound RTCP
packets, which will contain a Sender Report (SR) packet (assuming an
active RTP sender), the receiver can use the RTCP SR Timestamp field
to determine at what approximate time it was transmitted. If the
timestamp is earlier than the last received RTP packet with a header
extension carrying an SDES item, and especially if carrying a
previously used value, the SDES item in the RTCP SDES packet can be
ignored. Note that media processing and transmission pacing can
easily cause the RTP header timestamp field as well as the RTCP SR
timestamp field to not match with the actual transmission time.</t>
</section>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This section makes the following requests to IANA:<list
style="symbols">
<t>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.</t>
<t>Register the SDES items appropriate for use with the RTP header
extension defined in this document.</t>
</list></t>
<t>RFC-editor note: Please replace all occurrences of RFCXXXX with the
RFC number this specification receives when published.</t>
<section anchor="iana-base-urn" title="Registration of an SDES Base URN">
<t>IANA is requested to register the below entry in the RTP Compact
Header Extensions registry:</t>
<figure>
<artwork><![CDATA[Extension URI: urn:ietf:params:rtp-hdrext:sdes
Description: Reserved as base URN for RTCP SDES items that are also
defined as RTP Compact header extensions.
Contact: Authors of [RFCXXXX]
Reference: [RFCXXXX]
]]></artwork>
</figure>
<t>The reason to register a base URN for an SDES sub-space is that the
name represents an RTCP Source Description item, where a specification
is strongly recommended <xref target="RFC3550"/>.</t>
</section>
<section title="Creation of an SDES Sub-Registry">
<t>IANA is requested to create a sub-registry to the RTP Compact
Header Extensions registry, with the same basic requirements,
structure and layout as the RTP Compact Header Extensions
registry.<list style="symbols">
<t>Registry name: RTP SDES Compact Header Extensions</t>
<t>Specification: RFCXXXX and RFCs updating RFCXXXX</t>
<t>Information required: Same as for <xref target="RFC5285">RTP
Header Extensions</xref> registry</t>
<t>Review process: Same as for <xref target="RFC5285">RTP Header
Extensions</xref> registry, with the following requirements added
to the expert review:<list style="numbers">
<t>Any registration using an Extension URI that starts with
<xref
target="iana-base-urn">"urn:ietf:params:rtp-hdrext:sdes:"</xref>
MUST also have a registered Source Description item in the
"RTP SDES item types" registry.</t>
<t>A security and privacy consideration for the SDES item MUST
be provided with the registration.</t>
<t>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.</t>
</list></t>
<t>Size and format of entries: Same as for <xref
target="RFC5285">RTP Header Extensions</xref> registry.</t>
<t>Initial assignments: See <xref target="iana-sdes-items"/>
below.</t>
</list></t>
</section>
<section anchor="iana-sdes-items" title="Registration of SDES Items">
<t>It is requested that the following SDES item is registered in the
newly formed RTP SDES Compact Header Extensions registry:</t>
<figure>
<artwork><![CDATA[Extension URI: urn:ietf:params:rtp-hdrext:sdes:cname
Description: Source Description: Canonical End-Point Identifier
(SDES CNAME)
Contact: Authors of [RFCXXXX]
Reference: [RFCXXXX]
]]></artwork>
</figure>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>Source Description items may contain data that are sensitive from a
security perspective. There are SDES items that are or may be sensitive
from a user privacy perspective, like CNAME, NAME, EMAIL, PHONE, LOC and
H323-CADDR. Some 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
<xref target="RFC7022">short term CNAME identifier generated using a
random number generator</xref> may have minimal security implications,
while a CNAME of the form user@host has privacy concerns, and a CNAME
generated from a MAC address has long term tracking potentials.</t>
<t>In RTP sessions where any type of confidentiality protection is
enabled for RTCP, the SDES item header extensions MUST also be
protected. This implies that to provide confidentiality, users of SRTP
need to implement and use encrypted header extensions per <xref
target="RFC6904"/>. The security level that is applied to RTCP packets
carrying SDES items SHOULD also be applied to SDES items carried as RTP
header extensions. If the security level is chosen to be different for
an SDES item in RTCP and RTP header extension, it is important to
motivate the exception, and to consider the security properties as the
worst in each aspect for the different configurations.</t>
<t>The <xref target="RFC5285">general RTP header extension
mechanism</xref> does not itself contain any functionality that is a
significant risk for a denial of service attack, neither from processing nor
storage requirements. The extension for SDES items defined, can
potentially be a risk. The risk depends on the received
SDES item and its content. If the SDES item causes the receiver to
perform a large amount of processing, create significant storage
structures, or emit network traffic, such a risk does exist. The CNAME
SDES item in the RTP header extension is only a minor risk, as reception
of a CNAME item will create an association between the stream carrying
the SDES item and other RTP streams with the same SDES item. This
usually results in time synchronizing the media streams, thus some
additional processing is performed. However, the application's media
quality is likely more affected by an erroneous or changing association
and media synchronization, than the application quality impact caused by
the additional processing.</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
integrity protection 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. For information
regarding options for securing RTP, see <xref target="RFC7201"/>.</t>
</section>
<section anchor="Acknowledgments" title="Acknowledgments">
<t>The authors likes to thank the following individuals for feedback and
suggestions: Colin Perkins, Ben Campbell, and Samuel Weiler.</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.3611'?>
<?rfc include='reference.RFC.4566'?>
<?rfc include='reference.RFC.4585'?>
<?rfc include='reference.RFC.4588'?>
<?rfc include='reference.RFC.5109'?>
<?rfc include='reference.RFC.5576'?>
<?rfc include='reference.RFC.6051'?>
<?rfc include='reference.RFC.7022'?>
<?rfc include='reference.RFC.7201'?>
<?rfc include='reference.RFC.7656'?>
<?rfc include='reference.I-D.ietf-mmusic-sdp-bundle-negotiation'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:45:48 |