One document matched: draft-ietf-avt-rtp-howto-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1305 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1305.xml">
<!ENTITY rfc2026 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2026.xml">
<!ENTITY rfc2198 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2198.xml">
<!ENTITY rfc2326 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2326.xml">
<!ENTITY rfc2360 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2360.xml">
<!ENTITY rfc2418 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2418.xml">
<!ENTITY rfc2508 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2508.xml">
<!ENTITY rfc2616 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
<!ENTITY rfc2736 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2736.xml">
<!ENTITY rfc2959 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2959.xml">
<!ENTITY rfc2974 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2974.xml">
<!ENTITY rfc3095 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3095.xml">
<!ENTITY rfc3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY rfc3264 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3264.xml">
<!ENTITY rfc3285 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3285.xml">
<!ENTITY rfc3545 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3545.xml">
<!ENTITY rfc3550 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY rfc3551 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3551.xml">
<!ENTITY rfc3558 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3558.xml">
<!ENTITY rfc3569 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3569.xml">
<!ENTITY rfc3577 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3577.xml">
<!ENTITY rfc3611 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3611.xml">
<!ENTITY rfc3711 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3711.xml">
<!ENTITY rfc3978 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3978.xml">
<!ENTITY rfc3979 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3979.xml">
<!ENTITY rfc3984 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3984.xml">
<!ENTITY rfc4103 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4103.xml">
<!ENTITY rfc4170 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4170.xml">
<!ENTITY rfc4175 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4175.xml">
<!ENTITY rfc4288 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4288.xml">
<!ENTITY rfc4301 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml">
<!ENTITY rfc4346 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4346.xml">
<!ENTITY rfc4347 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4347.xml">
<!ENTITY rfc4352 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4352.xml">
<!ENTITY rfc4566 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml">
<!ENTITY rfc4585 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4585.xml">
<!ENTITY rfc4588 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4588.xml">
<!ENTITY rfc4677 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4677.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="no"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="no"?>
<?rfc subcompact="no"?>
<?rfc sortrefs="yes"?>
<rfc category="info" docName="draft-ietf-avt-rtp-howto-04" ipr="full3978">
<front>
<title abbrev="HOWTO: RTP Payload Formats">How to Write an RTP Payload
Format</title>
<author fullname="Magnus Westerlund" initials="M." surname="Westerlund">
<organization>Ericsson</organization>
<address>
<postal>
<street>Torshamgatan 23</street>
<city>Stockholm</city>
<code>SE-164 80</code>
<region></region>
<country>SWEDEN</country>
</postal>
<phone>+46 8 7190000</phone>
<facsimile>+46 8 757 55 50</facsimile>
<email>magnus.westerlund@ericsson.com</email>
</address>
</author>
<date day="11" month="July" year="2008" />
<area>Transport</area>
<workgroup>Audio Video Transport Working Group</workgroup>
<keyword>RTP, Payload format, Process</keyword>
<keyword>Draft</keyword>
<abstract>
<t>This document contains information on how to best write an RTP
payload format. Reading tips, design practices, and practical tips on
how to quickly and with good results produce an RTP payload format
specification. A template is also included with instructions that can be
used when writing an RTP payload format.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t><xref target="RFC3550">RTP</xref> payload formats define how a
specific real-time data format is structured in the payload of an RTP
packet. A real-time data format without a payload format specification
can't be transported using RTP. This creates an interest from many
individuals/organizations with media encoders or other types of
real-time data to define RTP payload formats. The specification of a
well designed RTP payload format is non-trivial and requires knowledge
of both RTP and the real-time data format.</t>
<t>This document intends to help any author of an RTP payload format to
make important design decisions, consider important features of RTP,
security, etc. The document is also intended to be a good starting point
for any person with little experience in IETF and/or RTP to learn the
necessary steps.</t>
<t>This document extends and updates the information that are available
in <xref target="RFC2736">"Guidelines for Writers of RTP Payload Format
Specifications"</xref>. Since this RFC was written further experience
has been gained on the design and specification of RTP payload format.
Several new RTP profiles, and robustness tools has also been defined,
which needs to be considered.</t>
<t>We also discuss the possible venues of defining an RTP payload
format, in IETF, by other standard bodies and proprietary ones.
Independent on the intended venue of specification, all will gain from
this document.</t>
<section title="Structure">
<t>This document has several different parts discussing different
aspects of the creation of an RTP payload format specification. After
the introduction and definitions there are a section discussing the
preparations the author(s) should do before start writing. The
following section discusses the different processes used when
specifying and completing an payload format, with focus on working
inside the IETF. Section 5 discusses the design of payload formats
themselves in detail. Section 6 discusses the current design trends
and provides good examples of practices that should be followed when
applicable. Following that there is a discussion on important sections
in the RTP payload format specification itself, like security and IANA
considerations. This document ends with an appendix containing an
template that can be used when writing RTP payload formats.</t>
</section>
</section>
<section title="Terminology">
<t></t>
<section title="Definitions">
<t><list style="hanging">
<t hangText="Media Stream:">A sequence of RTP packets that
together provides all or parts of a media. It is scoped in RTP by
the RTP session and a single sender source.</t>
<t hangText="RTP Session:">An association among a set of
participants communicating with RTP. The distinguishing feature of
an RTP session is that each maintains a full, separate space of
SSRC identifiers. See also <xref format="counter"
target="rtp-session">Section</xref>.</t>
<t hangText="RTP Payload Format:">The RTP Payload format specifies
how a specific media format is put into the RTP Payloads. Thus
enabling the format to be used in RTP sessions.</t>
</list></t>
</section>
<section title="Acronyms">
<t><list style="hanging">
<t hangText="ABNF:">Augmented Backus-Naur Form</t>
<t hangText="ADU:">Application Data Unit</t>
<t hangText="ALF:">Application Level Framing</t>
<t hangText="ASM:">Any-Source Multicast</t>
<t hangText="AVT:">Audio Video Transport</t>
<t hangText="BCP:">Best Current Practice</t>
<t hangText="ID:">Internet Draft</t>
<t hangText="MTU:">Maximum Transmission Unit</t>
<t hangText="WG:">Working Group</t>
<t hangText="QoS:">Quality of Service</t>
<t hangText="RFC:">Request For Comment</t>
<t hangText="RTP:">Real-time Transport Protocol</t>
<t hangText="RTCP:">RTP Control Protocol</t>
<t hangText="RTT:">Round Trip Time</t>
<t hangText="SSM:">Source Specific Multicast</t>
</list></t>
</section>
</section>
<section title="Preparations">
<t>RTP is a complex real-time media delivery framework and it has a lot
of details to consider when writing an RTP payload format. There is also
important to have a good understanding of the media codec/format so that
all its important features and properties are considered. First when one
has sufficient understanding of both parts can one produce an RTP
payload format of high quality. On top of this, one needs to understand
the process within IETF and especially the AVT WG to quickly go from
initial idea to a finished RFC. This and the next section helps an
author prepare himself in those regards.</t>
<section title="Recommend Reading">
<t>In the below sub sections there are a number of documents listed.
Not all needs to be read in full detail. However, an author basically
needs to be aware of everything listed below.</t>
<section title="IETF Process and Publication">
<t>For newcomers to IETF it is strongly recommended that one reads
the <xref target="RFC4677">"Tao of the IETF"</xref> that goes
through most things that one needs to know about the IETF. It
contains information about history, organisational structure, how
the WG and meetings work and many more details.</t>
<t>The main part of the IETF process is defined in <xref
target="RFC2026">RFC 2026</xref>. In addition an author needs to
understands the IETF rules and rights associated with copyright and
IPR documented in <xref target="RFC3978">BCP 78</xref> and <xref
target="RFC3979">BCP 79</xref>. <xref target="RFC2418">RFC
2418</xref> describes the WG process, the relation between the IESG
and the WG, and the responsibilities of WG chairs and
participants.</t>
<t>It is important to note that the RFC series contains documents of
several different classifications; standards track, informational,
experimental, best current practice (BCP), and historic. The
standard tracks contains documents of three different maturity
classifications, proposed, draft and Internet Standard. A standards
track document must start as proposed, after proved interoperability
of all the features it can be moved to draft standard, and final
when further experience has been gathered it can be moved to
Internet standard. As the content of the RFCs are not allowed to be
changed, the only way of updating an RFC is to write and publish a
new one that either updates or replaces the old one. Therefore it is
important to both consider the Category field in the header and
check if the RFC one is reading or going to reference is the latest
and valid. One way of checking the current status of an RFC is to
use the RFC-editor's RFC search engine, which displays the current
status and which if any RFCs that updates or obsolete it.</t>
<t>Before starting to write an draft one should also read the
Internet Draft writing guidelines
(http://www.ietf.org/ietf/1id-guidelines.txt), the ID checklist
(http://www.ietf.org/ID-Checklist.html) and the <xref
target="RFC-ED">RFC editoral guidelines and procedures</xref>.
Another document that can be useful is the <xref
target="RFC2360">"Guide for Internet Standards Writers"</xref>.</t>
<t>There are also a number of documents to consider in process of
writing of drafts intended to become RFCs. These are important when
writing certain type of text. <list style="hanging">
<t hangText="RFC 2606:">When writing examples using DNS names in
Internet drafts, those name shall be using the example.com,
example.net, and example.org domains.</t>
<t hangText="RFC 3849:">Defines the range of IPv6 unicast
addresses (2001:DB8::/32) that should be used in any
examples.</t>
<t hangText="RFC 3330:">Defines the range of IPv4 unicast
addresses reserved for documentation and examples:
192.0.2.0/24.</t>
<t hangText="RFC 5234:">Augmented Backus-Naur Form (ABNF) is
often used when writing text field specifications. Not that
commonly used in RTP payload formats but may be useful when
defining Media Type parameters of some complexity.</t>
</list></t>
</section>
<section title="RTP">
<t>The recommended reading for RTP consist of several different
parts; design guidelines, the RTP protocol, profiles, robustness
tools, and media specific recommendations.</t>
<t>Any author of RTP payload formats should start with reading <xref
target="RFC2736">RFC 2736</xref> which contains an introduction to
the application layer framing (ALF) principle, the channel
characteristics of IP channels, and design guidelines for RTP
payload formats. The goal of ALF is to be able to transmit
Application Data Units (ADUs) that are independently usable by the
receiver in individual RTP packets. Thus minimizing dependencies
between RTP packets and the effects of packet loss.</t>
<t>Then it is suitable to learn more about the RTP protocol, by
studying the RTP specification <xref target="RFC3550">RFC
3550</xref> and the existing profiles. As a complement to the
standards document there exist a book totally dedicated to <xref
target="CSP-RTP">RTP</xref>. There exist several profiles for RTP
today, but all are based on the <xref target="RFC3551">"RTP Profile
for Audio and Video Conferences with Minimal Control" (RFC
3551)</xref> (abbreviated AVP). The other profiles that one should
known about are <xref target="RFC3711">Secure RTP (SAVP)</xref>,
<xref target="RFC4585">"Extended RTP Profile for RTCP-based
Feedback"</xref> and <xref target="RFC5124">"Extended Secure RTP
Profile for RTCP-based Feedback (RTP/SAVPF)"</xref>. It is important
to understand RTP and the AVP profile in detail. For the other
profiles it is sufficient to have an understanding on what
functionality they provided and the limitations they create.</t>
<t>There has been developed a number of robustness tools for RTP.
The tools are for different use cases and real-time requirements.
<list style="hanging">
<t hangText="RFC 2198:">The <xref target="RFC2198">"RTP Payload
for Redundant Audio Data"</xref> provides functionalities to
provided redundant copies of audio or text payloads. These
redundant copies are sent together with an primary format in the
same RTP payload. This format relies on the RTP timestamp to
determine where data belongs in a sequence and therefore is
usually primarily suitable to be used with audio. However also
the <xref target="RFC4103">RTP Payload format for T.140</xref>
text format uses this format. The formats major property is that
it only preserves the timestamp of the redundant payloads, not
the original sequence number. Thus making it unusable for most
video formats. This format is also only suitable for media
formats that produce relatively small RTP payloads.</t>
<t hangText="RFC 5109:">The "RTP Payload Format for Generic
Forward Error Correction" <xref target="RFC5109"></xref>
provides an XOR based FEC of the whole or parts of a the packets
for a number of RTP packets. These FEC packets are sent in a
separate stream or as a redundant encoding using RFC 2198. This
FEC scheme has certain restrictions in the number of packets it
can protect. It is suitable for low to medium delay tolerant
applications with limited amount of RTP packets.</t>
<t hangText="RTP Retransmission:">The <xref target="RFC4588">RTP
retransmission scheme</xref> is used for semi-reliability of the
most important RTP packets in a media stream. The scheme is not
intended, nor suitable, to provide full reliability. It requires
the application to be quite delay tolerant as a minimum of one
round-trip time plus processing delay is required to perform an
retransmission. Thus it is mostly suitable for streaming
applications but may also be usable in certain other cases when
operating on networks with short RTT.</t>
<t hangText="RTP over TCP:">RFC 4571 <xref
target="RFC4571"></xref> defines how one sends RTP and RTCP
packet over conenction oriented transports like TCP. If one uses
TCP one gets reliability for all packets but loose some of the
real-time behavior that RTP was designed to provide. Issues with
TCP transport of real-time media include head of line blocking
and wasting resources on retransmission of already late data.
TCP is also limited to point-to-point connections which further
restricts its applicability.</t>
</list></t>
<t>There has also been discussion and also design of RTP payload
formats, e.g AMR and AMR-WB<xref target="RFC4867"></xref>,
supporting the unequal error detection provided by UDP-Lite <xref
target="RFC3828"></xref>. The idea is that by not having a checksum
over part of the RTP payload one can allow bit-errors from the lower
layers. By allowing bit-errors one can increase the efficiency of
some link layers, and also avoid unnecesary discards of data when
the payload and media codec could get at least some utility from the
data. The main issue is that one has no idea on the level of
bit-errors present in the unprotected part of the payload. Which
makes it hard or impossible to determine if one can design something
usable or not. Payload format designers are recommended against
considering features for unequal error detection unless very clear
requirements exist.</t>
<t>There also exist some management and monitoring extensions.<list
style="hanging">
<t hangText="RFC 2959:">The <xref target="RFC2959">RTP protocol
Management Information Database (MIB)</xref> that is used with
SNMP <xref target="RFC3410"></xref> to configure and retrieve
information about RTP sessions.</t>
<t hangText="RFC 3611:">The <xref target="RFC3611">RTCP Extended
Reports (RTCP XR)</xref> consist of a framework for reports sent
within RTCP. It can easily be extended by defining new report
formats in future. The report formats that are defined are
providing report information on; packet loss vectors, packet
duplication, packet reception times, RTCP statistics summary and
VoIP Quality. It also defines a mechanism that allows receivers
to calculate the RTT to other session participants when
used.</t>
<t hangText="RMONMIB:">The remote monitoring work group has
defined a <xref target="RFC3577">mechanism</xref> based on usage
of the MIB that can be an alternative to RTCP XR.</t>
</list></t>
<t>There has also been developed a number of transport optimizations
that are used in certain environments. They are all intended to be
transparent and not need special consideration by the RTP payload
format writer. Thus they are primarily listed here for informational
reasons and do not require deeper studies. <list style="hanging">
<t hangText="RFC 2508:">Compressing IP/UDP/RTP headers for slow
serial links <xref target="RFC2508">(CRTP)</xref> is the first
IETF developed RTP header compression mechanism. It provides
quite good compression however it has clear performance problems
when subject to packet loss or reordering between compressor and
decompressor.</t>
<t hangText="RFC 3095:">Is the base specification of the <xref
target="RFC3095">robust header compression (ROHC)
protocol</xref>. This solution was created as a result of CRTP's
lack of performance when subject to losses.</t>
<t hangText="RFC 3545:"><xref target="RFC3545">Enhanced
compressed RTP (E-CRTP)</xref> was developed to provide
extensions to CRTP that allows for better performance over links
with long RTTs, packet loss and/or reordering.</t>
<t hangText="RFC 4170:">Tunneling Multiplexed Compressed RTP
<xref target="RFC4170">(TCRTP)</xref> is a solution that allows
header compression within a tunnel carrying multiple multiplexed
RTP flows. This is primarily used in voice trunking.</t>
</list></t>
<t>There exist a couple of different security mechanisms that may be
used with RTP. All generic mechanisms need to be transparent for the
RTP payload format and nothing that needs special consideration. The
main reason that there exist different solutions is that different
applications have different requirements thus different solutions
have been developed. The main properties for a RTP security
mechanism are to provide confidentiality for the RTP payload,
integrity protection to detect manipulation of payload and headers,
and source authentication. Not all mechanism provides all of these
features which will need to be considered when used.</t>
<t><list style="hanging">
<t hangText="RTP Encryption:">Section 9 of RFC 3550 describes a
mechanism to provide confidentiality of the RTP and RTCP
packets, using per default DES encryption. It may use other
encryption algorithms if both end-points agree on it. This
mechanism is not recommend due to its weak security properties
of the used encryption algorithms. It also lacks integrity and
source authentication mechanisms.</t>
<t hangText="SRTP:">The profile for <xref
target="RFC3711">Secure RTP (SAVP)</xref> and the derived
profile (<xref target="RFC5124">SAVPF</xref>) is a solution that
provides confidentiality, integrity protection and partial
source authentication.</t>
<t hangText="IPsec:"><xref target="RFC4301">IPsec</xref> may
also be used to protect RTP and RTCP packet.</t>
<t hangText="TLS:"><xref target="RFC4346">TLS</xref> may also be
used to provide transport security between two end-point of the
TLS connection for a flow of RTP packets that are framed over
TCP.</t>
<t hangText="DTLS:"><xref target="RFC4347">Datagram TLS</xref>
is an alternative to TLS that allow TLS to be used over
datagrams, like UDP. Thus it has the potential for being used to
protect RTP over UDP. However the necessary signalling mechanism
for using it that has not yet been developed in any of the IETF
real-time media application signalling protocols.</t>
</list></t>
</section>
<t></t>
</section>
<t></t>
<section title="Important RTP details">
<t>This section does not remove the necessity of reading up on RTP.
However it does point out a couple of important details to remember
when designing the payload format.</t>
<section anchor="rtp-session" title="The RTP Session">
<t>The definition of the RTP session from RFC 3550 is:</t>
<t>"An association among a set of participants communicating with
RTP. A participant may be involved in multiple RTP sessions at the
same time. In a multimedia session, each medium is typically carried
in a separate RTP session with its own RTCP packets unless the
encoding itself multiplexes multiple media into a single data
stream. A participant distinguishes multiple RTP sessions by
reception of different sessions using different pairs of destination
transport addresses, where a pair of transport addresses comprises
one network address plus a pair of ports for RTP and RTCP. All
participants in an RTP session may share a common destination
transport address pair, as in the case of IP multicast, or the pairs
may be different for each participant, as in the case of individual
unicast network addresses and port pairs. In the unicast case, a
participant may receive from all other participants in the session
using the same pair of ports, or may use a distinct pair of ports
for each.</t>
<t>The distinguishing feature of an RTP session is that each
maintains a full, separate space of SSRC identifiers (defined next).
The set of participants included in one RTP session consists of
those that can receive an SSRC identifier transmitted by any one of
the participants either in RTP as the SSRC or a CSRC (also defined
below) or in RTCP. For example, consider a three-party conference
implemented using unicast UDP with each participant receiving from
the other two on separate port pairs. If each participant sends RTCP
feedback about data received from one other participant only back to
that participant, then the conference is composed of three separate
point-to-point RTP sessions. If each participant provides RTCP
feedback about its reception of one other participant to both of the
other participants, then the conference is composed of one
multi-party RTP session. The latter case simulates the behavior that
would occur with IP multicast communication among the three
participants.</t>
<t>The RTP framework allows the variations defined here, but a
particular control protocol or application design will usually
impose constraints on these variations."</t>
<t></t>
</section>
<section title="RTP Header">
<t>The RTP header contains two fields that require additional
specification by the RTP payload format, namely the RTP Timestamp
and the marker bit. Certain RTP payload formats also uses the RTP
sequence number to realize certain functionalities. The payload type
is used to indicate the used payload format.</t>
<t><list style="hanging">
<t hangText="Marker bit:">A single bit normally used to provide
important indications. In audio it is normally used to indicate
the start of an talk burst. This to enable jitter buffer
adaptation prior to this with minimal audio quality impact. In
video the marker bit is normally used to indicate the last
packet part of an frame. This enables an decoder to finish
decoding the picture, where it otherwise may need to wait for
the next packet to explicitly know that.</t>
<t hangText="Timestamp:">The RTP timestamp indicate the time
instance the media belongs to. For discrete media, like video it
normally indicates when the media (frame) was sampled. For
continuous media it normally indicates the first time instance
the media present in the payload represents. For audio this is
the sampling time of the first sample. All RTP payload formats
must specify the meaning of the timestamp value and which clock
rates that are allowed. Note that clock rates below 1000 Hz is
not appropriate due to RTCP measurements function that in that
case lose resolution.</t>
<t hangText="Sequence number:">The sequence number are
monotonically increasing and set as packets are sent. That
property is used in many payload formats to recover the order of
everything from the whole stream down to fragments of ADUs and
the order they shall be decoded.</t>
<t hangText="Payload Type:">Commonly the same payload type is
used for a media stream for the whole duration of a session.
However in some cases it may be required to change the payload
format or its configuration during the session. The payload type
is used to indicate on a per packet basis which format is used.
Thus certain major configuration information can be bound to a
payload type value by out-of-band signalling. Examples of this
would be video decoder configuration information.</t>
<t hangText="SSRC:">The Sender Source ID is normally not used by
a payload format other than identifying the RTP timestamp and
sequence number space a packet belongs to, allowing the
simultaneously reception of multiple senders. However there are
certain of the mechanisms the make RTP robuster that are RTP
payloads that have used multiple SSRCs and bound them together
to correctly separate original data and repair or redundant
data.</t>
</list>The remaining fields are commonly not influencing the RTP
payload format. The padding bit is worth clarifying as it indicates
that one or more bytes are appended after the RTP payload. This
padding must be removed by a receiver before payload format
processing can occur. Thus it is completely separate from any
padding that may occur within the payload format itself.</t>
</section>
<section title="RTP Multiplexing">
<t>RTP has three multiplexing points that are used for different
purposes. A proper understanding of this is important to correctly
utilized them.</t>
<t>The first one is separation of media streams of different types,
which is accomplished using different RTP sessions. So for example
in the common multi-media session with audio and video, RTP
multiplex audio and video on different RTP sessions. To achieve this
separation, transport level functionalities are use, normally UDP
port numbers. Different RTP sessions are also used to realize
layered scalability as it allows a receiver to select one or more
layers for multicasted RTP sessions simply by joining the multicast
groups the desired layers are transported over. This also allows
different Quality of Service (QoS) be applied to different
media.</t>
<t>The next point is separation of different sources within a RTP
session. Here RTP uses the SSRC (Sender Source) which identifies
individual sources. An example of individual sources in audio RTP
session, would be different microphones, independent of if they are
from the same host or different hosts. For each SSRC a unique RTP
sequence number and timestamp space is used.</t>
<t>The third multiplexing point is the RTP headers payload type
field. The payload type identifies what format the content in the
RTP payload has. This includes different payload format
configurations, different codecs, and also usage of robustness
mechanisms like the one described in <xref target="RFC2198">RFC
2198</xref>.</t>
</section>
<section title="RTP Synchronization">
<t>There are several types of synchronization and we will here
describe how RTP handles the different types:<list style="hanging">
<t hangText="Intra media:">The synchronization within a media
stream from a source is accomplished using the RTP timestamp
field. Each RTP packet carry the RTP timestamp that specifies
the media contained in this packets position in relation to
other media on the time line. This is especially useful in cases
of discontinues transmissions. Discontinues can also be caused
by the network and with extensive losses the RTP timestamp tells
the receiver how much later than previously received media the
media shall be played out.</t>
<t hangText="Inter media:">As applications commonly has a desire
to use several media types at the same time there exist a need
to synchronize also the different medias from the same source.
This puts two requirements on RTP; possibility to determine
which media is from the same source and if they should be
synchronized with each other; and the functionality to
facilitate the synchronization itself.</t>
</list></t>
<t>The first part of Inter media synchronization is to determine
which SSRCs in each session that should be synchronized with each
other. This is accomplished by comparing the RTCP SDES CNAME field.
SSRCs with the same CNAME in different RTP session should be
synchronized.</t>
<t>The actual RTCP mechanism for inter media synchronization is
based on that each media stream provide a position on the media
specific time line (measured in RTP timestamp ticks) and a common
reference time line. The common reference time line is in RTCP
expressed as an wall clock time in the Network Time Protocol (NTP)
format. It is important to notice that the wall clock time is not
required to be synchronized between hosts, for example by using
<xref target="RFC1305">NTP</xref> . It can even have nothing at all
to do with the actual time, for example the host system's uptime can
be used for this purpose. The important factor is that all media
streams from a particular source that are being synchronized uses
the same reference clock to derive there relative RTP timestamp time
scales.</t>
<t>In <xref format="counter" target="rtcp-synch">the below
Figure</xref> it is depicted how if one receives RTCP Sender Report
(SR) packet P1 in one media stream and RTCP SR packet P2 in the
other session, then one can calculate the corresponding RTP
timestamp values for any arbitrary point in time T. However to be
able to do that it is also required to know the RTP timestamp rates
for each media currently used in the sessions</t>
<figure anchor="rtcp-synch" title="RTCP Synchronization">
<preamble></preamble>
<artwork><![CDATA[TS1 --+---------------+------->
| |
P1 |
| |
NTP ---+-----+---------T------>
| |
P2 |
| |
TS2 ---------+---------+---X-->]]></artwork>
<postamble></postamble>
</figure>
<t>Lets assume that media 1 uses a RTP Timestamp clock rate of 16
kHz, and media 2 a rate of 90 kHz. Then the TS1 and TS2 for point T
can be calculated in the following way: TS1(T) = TS1(P1) + 16000 *
(NTP(T)-NTP(P1)) and TS2(T) = TS2(P2) + 90000 * (NTP(T)-NTP(P2)).
This calculation is useful as it allows to generate a common
synchronization point for which all time values are provided
(TS1(T), TS2(T) and T). So when one like to calculate at which NTP
time the TS present in packet X corresponds to one can do that in
the following way: NTP(X) = NTP(T) + (TS2(X) - TS2(T))/90000.</t>
</section>
</section>
<section title="Signalling Aspects">
<t>RTP payload formats are used in the context of application
signalling protocols such as <xref target="RFC3261">SIP</xref> using
<xref target="RFC4566">SDP</xref> with <xref
target="RFC3264">Offer/Answer</xref>, <xref
target="RFC2326">RTSP</xref> or <xref target="RFC2326">SAP</xref>.
These examples all uses SDP to indicate which and how many media
streams that are desired to be used in the session and their
configuration. To be able to declare or negotiate which media format
and RTP payload packetization the payload format must be given an
identifier. In addition to the identifier many payload formats also
have the need to carry further configuration information out-of-band
in regards to the RTP payloads prior to the media transport
session.</t>
<t>The above examples of session establishing protocols all use SDP,
however also other session description formats may be used. For
example there have been discussion on a new Session Description format
within IETF (SDP-NG). To prevent locking the usage of RTP to SDP based
out-of-band signalling, the payload formats are identified using an
separate definition format for the identifier and parameters. That
format is the Media Type.</t>
<section title="Media Types">
<t><xref target="RFC4288">Media types</xref> was originally created
for identifying media formats included in email. Media types are
today also used in <xref target="RFC2616">HTTP</xref>, <xref
target="RFC4975">MSRP</xref> and many other protocols to identify
arbitrary content carried within the protocols. Media types also
provide a media hierarchy that fits RTP payload formats well. Media
type names are two-part and consist of content type and sub-type
separated with a slash, e.g. "audio/PCMA" or "video/h263-2000". It
is important to choose the correct content-type when creating the
media type identifying an RTP payload format. However in most cases
there is little doubt what content type the format belongs to.
Guidelines for choosing the correct media type and registration
rules are present in <xref target="RFC4288">RFC 4288</xref>. The
additional rules for media types for RTP payload formats are present
in <xref target="RFC4855">RFC 4855</xref>.</t>
<t>Media types are allowed any number of parameters which are
divided into two groups, required and optional parameters. They are
always on the form name=value. There exist no restriction on how the
value is defined from media types perspective, except that
parameters must have value. However the carrying of media types in
SDP etc. has resulted in the following restrictions that needs to be
followed to make media types for RTP payload format usable:</t>
<t><list style="numbers">
<t>Arbitrary binary content in the parameters are allowed but
needs to be encoded so that they can be placed within text based
protocols. <xref target="RFC4648"> Base64</xref> is recommended,
but for shorter content BASE16 may be more appropriate as it is
simpler to interpret by humans. This needs to be explicitly
stated when defining a media type parameter with binary
value.</t>
<t>The end of the value needs to be easily found when parsing a
message. Thus parameter values that are continuous and non
interrupted by common text separators, such as space and
semi-colon are recommended. If that is not possible some type of
escaping should be used. Usage of " (double quote) is
recommended.</t>
<t>A common representation form of the media type and its
parameters is on a single line. In those cases the media type is
followed by a semi-colon separated list of the parameter value
pair, e.g. audio/amr octet-align=0; mode-set=0,2,5,7;
mode-change-period=2.</t>
</list></t>
</section>
<section title="Mapping to SDP">
<t>As <xref target="RFC4566">SDP</xref> is so commonly used as an
out-of-band signalling channel, a mapping of the media type exist.
The details on how to map the media type and its parameters into SDP
are described in <xref target="RFC4855">RFC 4855</xref>. However
this is not sufficient to explain how certain parameter shall be
interpreted for example in the context of <xref
target="RFC3264">Offer/Answer negotiation</xref>.</t>
<section anchor="OA-sdp" title="The Offer/Answer Model">
<t>The Offer/Answer (O/A) model allows SIP to negotiate media
formats and which payload formats and their configuration is used
in a session. However O/A does not define a default behavior and
instead points out the need to define how parameters behave. To
make things even more complex the direction of media within a
session do have impact on these rules, thus some cases may require
description separately for peers that are send only, receiver only
or both senders and receivers as identified by the SDP attributes
a=sendonly, a=recvonly, and a=sendrecv. In addition any usage of
multicast puts a further limitations as the same media stream is
delivered to all participants. If those restrictions are to
limiting also to be used in unicast then separate rules for
unicast and multicast will be required.</t>
<t>The most common O/A interpretation and the simplest is for
declarative parameters, i.e. the sending entity can declare a
value and that has no direct impact on the other agents values.
This declared value applies to all media that are going to be sent
to the declaring entity. For example most video codecs has level
parameter which tells the other participants the highest
complexity the video decoder supports. The level parameter can be
declared independently by two participants in a unicast session as
it will be the media sender responsibility to transmit a video
stream that fulfills the limitation the other has declared.
However in multicast it will be necessary to send a stream that
follows the limitation of the weakest receiver, i.e. the one that
has supports the lowest level. To simplify the negotiation in
these cases it is common to require any answerer to a multicast
session to take a yes or no approach to parameters.</t>
<t>"Negotiated" parameters are another type of parameters, for
which both sides needs to agree on their values. Such parameter
requires that the answerer either accept as they are offered or
remove the payload type the parameter belonged to. The removal of
the payload type from the answer indicates to the offerer the lack
of support. An unfortunate implications of the need to use
complete payload types to indicate each configuration possible to
achieve interoperability, is that the number of payload types
necessary can quickly grow big. This is one reason to keep the
total number of set of capabilities that may be implemented
limited.</t>
<t>The most problematic type of parameters are those that relates
with the transmission the entity performs. They do not really fit
the O/A model but can be shoe-horned in. Example of such
parameters can be found in the <xref target="RFC3984">H.264 video
code's payload format</xref>, where the name of all parameters
with this property starts sprop-. The issue that exist is that
they declare properties for a media stream one don't yet know if
the other party accept. The best one can make of the situation is
to explain the assumption that the other party will accept the
same reception parameter as the offerer of the session. If the
answerer needs to change any declarative parameter then the
offerer may be required to make an new offer to update the
parameter values for its outgoing media stream.</t>
<t>Another issue to consider is the sendonly media streams in
offers. For all parameters that relates to what one accepts to
receive those don't have any meaning other than provide a template
for the answering entity. It is worth pointing out in the
specification that these provides recommended set of parameter
values by the sender. Note that sendonly streams in answers will
need to indicate the offerers parameters to ensure that the
offerer can match the answer to the offer.</t>
<t>A further issue with offer/answer which complicates things is
that it is allowed to renumber the payload types between offer and
answer. This is not recommended but allowed for support of
gateways to the ITU conferencing suit. Which means that answers
for payload types needs to be possible to bind to the ones in the
offer even when the payload type number has been changed, and some
of the proposed payload types have been removed. This must
normally be done based on configurations offered, thus negotiated
parameters becomes vital.</t>
</section>
<section anchor="dec-sdp" title="Declarative usage in RTSP and SAP">
<t><xref target="RFC2974">SAP (Session Announcement
Protocol)</xref> is used for announcing multicast sessions.
Independently of the usage of <xref target="RFC3569">Source
Specific Multicast (SSM)</xref> or Any-Source Multicast (ASM), the
SDP provided by SAP applies to all participants. All media that is
sent to the session must follow the media stream definition as
specified by the SDP. Thus enabling everyone to receive the
session if they support the configuration. Here SDP provides a one
way channel with no possibility to affect the configuration
defined by SDP that the session creator has decided upon. Any RTP
Payload format that requires parameters for the send direction and
which needs individual values per implementation or instance will
fail in a SAP session for a multicast session allowing anyone to
send.</t>
<t><xref target="RFC2326">Real-Time Streaming Protocol
(RTSP)</xref> allows the negotiation of transport parameters for
media streams part of a streaming session between a server and
client. RTSP has divided the transport parameters from the media
configuration. SDP is commonly used for media configuration in
RTSP and is sent to the client prior to session establishment,
either through the usage of the DESCRIBE method or an out-of-band
channel like HTTP, email etc. The SDP is used to determine which
media streams and what formats are being used before the session
establishment.</t>
<t>Thus both SAP and RTSP uses SDP to configure receivers and
senders with a predetermined configuration including the payload
format and any of its parameters of a media stream. Thus all
parameters are used in a declarative fashion. This can result in
different treatment of parameters between offer/answer and
declarative usage in RTSP and SAP. This will then need to be
pointed out by the payload format specification.</t>
</section>
</section>
</section>
<section title="Transport Characteristics">
<t>The general channel characteristics that RTP flows are experiencing
are documented in Section 3 of <xref target="RFC2736">RFC2736</xref>.
Below additional information is discussed.</t>
<section title="Path MTU">
<t>At the time of writing the most common IP Maximum Transmission
Unit (MTU) of used link layers is 1500 bytes (Ethernet data
payload). However there exist links with both smaller MTU and much
larger MTUs. Certain parts of Internet do already today support IP
MTU of 9000 bytes or more. There is an slow ongoing evolution
towards larger MTU sizes. This should be considered in the design,
especially in regards to features such as aggregation of
independently decodable data units.</t>
</section>
</section>
</section>
<section title="Specification Process">
<t>This section discusses the recommended process to produce an RTP
payload format in the described venues. This is to document the best
current practice on how to get a well designed and specified payload
format as quickly as possible. For specifications that are proprietary
or defined by other standards bodies than IETF the primary milestone is
registration of the RTP payload format name. However there is also the
issue of ensuring best possible quality of any specification.</t>
<section title="IETF">
<t>Specification in IETF is recommended for all standardized media
formats. The main reason is to provide an openly available RTP payload
format specification that also has been reviewed by people experienced
with RTP Payload formats. This also assumes that the AVT WG exist.</t>
<section title="Steps from Idea to Publication">
<t>There are a number of steps that an RTP payload format should go
through from the initial idea until it is published. This also
documents the process that the AVT working group applies when
working with RTP payload formats.<list style="numbers">
<t>Idea: Determined the need for an RTP payload format as an
IETF specification.</t>
<t>Initial effort: Using this document as guideline one should
be able to get started on the work. If one's media codec doesn't
fit any of the common design patterns or one has problems
understanding what the most suitable way forward is, then one
should contact the AVT working group and/or the WG chairs. The
goal of this stage is to have an initial individual draft. This
draft needs to focus on the introduction parts that describe the
real-time media format and the basic idea on how to packetize
it. All the details are not required to be filled in. However
security chapter is not something that one should skip even
initially. It is important to consider already from the start
any serious security risks that needs to be solved. This step is
completed when one has a draft that is sufficient detailed for a
first review by the WG. The less confident one is of the
solution, the less work should be spent on details, instead
concentrate on the codec properties and what is required to make
it work.</t>
<t>Submission of first version. When one has performed the above
one submits the draft as an individual draft. This can be done
at any time except the 3 weeks (current deadline at the time of
writing, consult current announcements) prior to an IETF
meeting. When the IETF draft announcement has been sent out on
the draft announcement list, forward it to the AVT WG and
request that it is reviewed. In the email outline any issues the
authors currently have with the design.</t>
<t>Iterative improvements: Taking the feedback into account one
updates the draft and try resolve any issues. New revision of
the draft can be submitted at any time. It is recommended to do
it whenever one has made major updates or have new issues that
are easiest to discuss in the context of a new draft
version.</t>
<t>Becoming WG document: Due to that the definition of RTP
payload formats are part of the AVT's charter, RTP payload
formats that are going to be published as standards track RFCs
needs to become WG documents. Becoming WG document means that
the chairs are responsible for administrative handling, like
publication requests. However be aware that making a document
into a WG document changes the formal ownership and
responsibility from the individual authors to the WG. The
initial authors will continue being document editor, unless
unusual circumstances occur. The AVT WG accepts new RTP payload
formats based on their suitability and document maturity. The
document maturity is a requirement to ensure that there are
dedicated document editors and that there exist a good
solution.</t>
<t>Iterative improvements: The updates and review cycles
continues until the draft the has reached the maturity suitable
for publication.</t>
<t>WG last call: WG last call of at least 2 weeks are always
performed for payload formats in the AVT WG. The authors request
WG last call for a draft when they think it i mature enough for
publication. The chairs perform a review to check if they agree
with the authors assessment. If the chairs agree on the
maturity, the WG last call is announced on the WG mailing list.
If there are issues raised these needs to be addressed with an
updated draft version. For any more substantial updates of
draft, a new WG last call is announced for the updated version.
Minor changes, like editorial on can be progressed without an
additional WG last call.</t>
<t>Publication Requested: For WG documents the chairs request
publication of the draft. After this the approval and
publication process described in <xref target="RFC2026">RFC
2026</xref> are performed. The status after the publication has
been requested can be tracked using the IETF data tracker.
Documents do not expire as normal after publication has been
requested. In addition any submission of document updates
requires the approval of WG chair(s). The authors are commonly
asked to address comments or issues raised by the IESG. The
authors also review the document prior to publication as an RFC
to ensure its correctness.</t>
</list></t>
</section>
<section title="WG meetings">
<t>WG meetings are for discussing issues, not presentations. This
means that most RTP payload format should never need to be discussed
in a WG meeting. RTP payload formats that would be discussed are
either controversial issues that failed to be resolved on the
mailing list, or includes new design concepts worth a general
discussion.</t>
<t>There exist no requirement to present or discuss a draft at a WG
meeting before it becoming published as an RFC. Thus even authors
that lack the possibility to go to WG meetings should be able to
successfully specify an RTP payload format in IETF. WG meetings may
only become required if the draft get stuck in a serious debate that
isn't easily resolved.</t>
</section>
<section title="Draft Naming">
<t>To simplify the work of the AVT WG chairs and its WG members a
specific draft file naming convention shall be used for RTP payload
formats. Individual submissions shall be named draft-<lead author
family name>-avt-rtp-<descriptive name>-<version>.
The WG documents shall be named according to this template:
draft-ietf-avt-rtp-<descriptive name>-<version>. The
inclusion of "avt" in the draft filename ensures that the search for
"avt-" will find all AVT related drafts. Inclusion of "rtp" tells us
that it is an RTP payload format draft. The descriptive name should
be as short as possible while still describe what the payload format
is for. It is recommended to use the media format or codec acronym.
Please note that the version must start at 00 and is increased by
one for each submission to the IETF secretary of the draft. No
version numbers may be skipped.</t>
</section>
<section title="How to speed up the process">
<t>There a number of ways of losing a lot of time in the above
process. This section discuss what to do and what to avoid.<list
style="symbols">
<t>Do not only update the draft to the meeting deadline. An
update to each meeting automatically limits the draft to 3
updates per year. Instead ignore the meeting schedule and
publish new versions as soon as possible.</t>
<t>Try to avoid requesting review when people are busy, like the
weeks before a meeting. Review should be asked at all possible
times and it is actually more likely that people has more time
for them directly after a meeting.</t>
<t>Perform draft updates quickly. A common mistake is that the
authors lets the draft slip. By performing updates to the draft
text directly after getting resolution on an issue, speeds
things up. This as it minimizes the delay that the author has
direct control over. Waiting for reviews, responses from area
directors and chairs, etc can be much harder to speed up.</t>
<t>Failing to take the human nature into account. It happens
that people forget or needs to be reminded about tasks. Send
people you are waiting for a kindly reminder if things takes
longer than expected. To avoid annoying people ask for a time
estimate from people when they expect to fulfill the requested
task.</t>
<t>Not enough review. It is common that documents take a long
time and many iterations because not enough review is performed
in each iteration. To improve the amount of review you get on
your own document, trade review time with other document
authors. Make a deal with some other document authors that you
will review his draft(s) if he reviews yours. Even inexperience
reviewers can help with language, editorial or clarity issues.
Try also approaching the more experienced people in the WG and
get them to commit to a review. The WG chairs cannot, even if
desirable, be expected to review all versions. Due to workload
the chairs may need to concentrate on key points in a draft
evolution, like initial submissions, if ready to become WG
document and WG last call.</t>
</list></t>
</section>
</section>
<section title="Other Standards bodies">
<t>Other standard bodies may define RTP payload in their own
specifications. When they do this they are strongly recommend to
contact the AVT WG chairs and request review of the work. It is
recommended that at least two review steps are performed. One early in
the process when more fundamental issues easily can be resolved
without abandoning a lot of effort. Then when nearing completion, but
while still possible to update the specification as second review
should be scheduled. In that pass the quality can be assessed and
hopefully no updates are needed. Using this procedure can avoids both
conflicting definitions and serious mistakes, like breaking certain
aspects of the RTP model.</t>
<t>RTP payload Media Types may be registered in the standards tree by
other standard bodies. The requirements on the organization are
outlined in the media types registration document (<xref
target="RFC4855">RFC 4855</xref> and <xref target="RFC4288">RFC
4288</xref>). This registration requires a request to the IESG, which
ensures that the registration template is acceptable. To avoid last
minute problems with these registration the registration template must
be sent for review both to the AVT WG and the media types list
(ietf-types@iana.org) and is something that should be included in the
IETF reviews of the payload format specification.</t>
<t>Registration of the RTP payload name is something that is required
to avoid name collision in the future. Do also note that "x-" names
are not suitable for any documented format as they have the same
problem with name collision and can't be registered. The list of
already registered media types can be found at IANA
(http://www.iana.org).</t>
</section>
<section title="Propreitary and Vendor Specific">
<t>Proprietary RTP payload formats are commonly specified when the
real-time media format is proprietary and not intended to be part of
any standardized system. However there exist many reasons why also
proprietary formats should be correctly documented and
registered;<list style="symbols">
<t>Usage in standardized signalling environment such as SIP/SDP.
RTP needs to be configured regarding used RTP profiles, payload
formats and their payload types. To accomplish this there is an
need for registered names to ensure that the names do not collide
with other formats.</t>
<t>Sharing with business partners. As RTP payload formats are used
for communication, situations where business partners like to
support one proprietary format often arises. Having a well written
specification of the format will save time and money for both one
selves and ones partner, as interoperability will much easier to
accomplish.</t>
<t>To ensure interoperability between different implementations on
different platforms.</t>
</list></t>
<t>To avoid name collisions there is a central register keeping tracks
of the registered Media Type names used by different RTP payload
formats. When it comes to proprietary formats they should be
registered in the vendors own tree. All vendor specific registrations
uses sub-type names that start with "vnd.<vendor-name>". All
names that uses names in the vendors own trees are not required to be
registered with IANA. However registration is recommended if used at
all in public environments.</t>
</section>
</section>
<section title="Designing Payload Formats">
<t>The best summary of payload format design is KISS (Keep It Simple,
Stupid). A simple payload format makes it easy to review for
correctness, implement, and have low complexity. Unfortunately
contradicting requirements sometime makes it hard to do things simple.
Complexity issues and problems that occur for RTP payload formats
are:</t>
<t><list style="hanging">
<t hangText="Too many configurations:">Contradicting requirements
results in that one configuration for each conceivable case is
created. Such contradicting requirements are often between
functionality and bandwidth. This has two big negatives. First all
configurations needs to be implemented. Secondly the using
application must select the most suitable configuration. Selecting
the best configuration can be very difficult and in negotiating
applications, this can create interoperability problems. The
recommendation is to try to select a very limited (preferable one)
configuration that preforms the most common case well and is capable
of handling the other cases, but maybe less well.</t>
<t hangText="Hard to implement:">Certain payload formats may become
difficult to implement both correctly and efficient. This needs to
be considered in the design.</t>
<t hangText="Interaction with general mechanisms:">Special solutions
may create issues with deployed tools for RTP, like tools for
robuster transport of RTP. For example the requirement of non broken
sequence space creates issues with using both payload type switching
and interleaving any mechanism for media independent resilience
within the stream.</t>
</list></t>
<t></t>
<section title="Features of RTP payload formats">
<t>There are number of common features in RTP payload formats. There
are no general requirement to support these features, instead their
applicability must be considered for each payload format. It might in
fact be that certain features are not even applicable.</t>
<section title="Aggregation">
<t>Aggregation allows for the inclusion of multiple ADUs within the
same RTP payload. This is commonly supported for codec that produce
ADUs of sizes smaller than the IP MTU. Do remember that the MTU may
be significantly larger than 1500 bytes, 9000 bytes is available
today and a MTU of 64k may be available in the future. Many speech
codecs have the property of ADUs of a few fixed sizes. Video
encoders generally may produce ADUs of quite flexible size. Thus the
need for aggregation may be less. However in certain use cases the
possibility to aggregate multiple ADUs especially for different
playback times are useful.</t>
<t>The main disadvantage of aggregation is the extra delay
introduced, due to buffering until sufficient amount of ADUs have
been collected and reduced robustness against packet loss. It also
introduces buffering requirements on the receiver.</t>
</section>
<section title="Fragmentation">
<t>If the real-time media format has the property that it may
produce ADUs that are larger than common MTUs sizes then
fragmentation support should be considered. An RTP Payload format
may always fall back on IP fragmentation, however as discussed in
RFC 2736 this have some drawbacks. The usage of RTP payload format
level fragmentation, does primarily allow for more efficient usage
of RTP packet loss recovery mechanisms. However it may in some cases
also allow usage of the partial ADU by doing media specific
fragmentation at media specific boundaries.</t>
</section>
<section title="Interleaving and Transmission Re-Scheduling">
<t>Interleaving has been implemented in a number of payload formats
to allow for less quality reduction when packet loss occurs. When
losses are bursty and several consecutive packets are lost, the
impact on quality can be quite severe. Interleaving is used to
convert that burst loss to several spread out individual losses. It
can also be used when several ADUs are aggregated in the same
packets. A loss of an RTP packet with several ADUs in the payload
has the same affect as a burst loss if the ADUs would have been
transmitted in individual packets. To reduce the burstiness of the
loss, the data present in an aggregated payload may be interleaved,
thus spread the loss over a longer time period.</t>
<t>A requirement for doing interleaving within an RTP payload format
is the aggregation of multiple ADUs. For formats that don't use
aggregation there is still the possibility to implement an
transmission order re-scheduling mechanism. That have the effect
that packets transmitted next to each other originates from
different points in the media stream. This can be used to mitigate
burst losses, which may be useful if one transmit packets with small
intervals. However it may also be used to transmit more significant
data earlier in combination with RTP retransmission to allow for
more graceful degradation and increased possibilities to receive the
most important data, e.g. Intra frames of video.</t>
<t>The drawbacks of interleaving is the significantly increased
transmission buffering delay, making it mostly useless for low delay
applications. It also creates significant buffering requirements on
the receiver. That buffering also is problematic as it is usually
difficult to indicate when a receiver may start consume data and
still avoid buffer underrun caused by the interleaving mechanism
itself. The transmission re-scheduling is only useful in a few
specific cases, like in streaming with retransmissions. This must be
weighted against the complexity of these schemes.</t>
</section>
<section title="Media Back Channels">
<t>A few RTP payload format have implemented back channels within
the media format. Those have been for specific features, like the
<xref target="RFC4867">AMR</xref> codec mode request (CMR) field.
The CMR field is used in gateway operations to circuit switched
voice to allow an IP terminal to react to the CS networks need for a
specific encoder mode. A common property for the media back channels
is the need to have this signalling in direct relation to the media
or the media path.</t>
<t>If back channels are considered for an RTP payload format they
should be for specific mechanism and which can't be easily satisfied
by more generic mechanisms within RTP or RTCP.</t>
</section>
<section title="Scalability">
<t>There exist some codecs that supports some type of scalability,
i.e. where additional data can be used to improve media stream
properties, but the additional data isn't required for decoding.
This quality improvements has been so far been in a number of
different types:</t>
<t><list style="hanging">
<t hangText="Temporal:">For video codecs increased frame rate is
one way to improve the quality. Audio codecs could provide
increase sampling rate.</t>
<t hangText="Spatial:">Video codecs with scalability may
increase the resolution or image size.</t>
<t hangText="Quality:">The perceived quality of the media stream
can be improved without affecting the temporal or spatial
properties of the media. This is usually done by improving the
signal to noise ration within the content.</t>
</list>Codecs that support scalability are at the time of writing
this having a bit of revival. It has been realized that getting the
need functionality for the media stream in the RTP framework is
quite challanging. The author hopes to be able to provide some
lessons from this work in this document in the future.</t>
</section>
<section title="High Packet Rates">
<t>Some media codecs requires high packet rates, and in these cases
the RTP sequence number wraps to quickly. As rule of thumd, the
sequence number space must not be possible to wrap in less than 2
minutes (TCP maximum segement lifetime). If that may occur then the
payload format should specify a extended sequence number field to
allow the receiver to determine where a specific payload belongs in
the sequence also in the face of extensive reordering. The RTP
payload format for uncompressed video <xref target="RFC4175"></xref>
can be used as an example for such a field.</t>
</section>
</section>
<t></t>
</section>
<section title="Current Trends in Payload Format Design">
<t>This section provides a few examples of payload formats that is worth
noting for good design in general or specific details.</t>
<section title="Audio Payloads">
<t>The <xref target="RFC4867">AMR</xref>, <xref
target="RFC4867">AMR-WB</xref>, <xref target="RFC3558">EVRC</xref>,
<xref target="RFC3558">SMV</xref> payload format are all quite
similar. They are all for frame based audio codecs and use a table of
content structure. Each frame has a table of contents entry that
indicate the type of the frame and if additional frames are present.
This is quite flexible but produces unnecessary overhead if the ADU is
fixed size and when aggregating multiple ones they are commonly of the
same type. In that case a solution like that in <xref
target="RFC4352">AMR-WB+</xref> maybe more suitable.</t>
<t>AMR-WB+ does contain one less good feature which is depending on
the media codec itself. The media codec produces a large range of
different frame lengths in time perspective. The RTP timestamp rate is
selected to the very unusual value of 72 kHz despite that output
normally is at sample rate 48kHz. This timestamp rate is the smallest
found value that would make all of the frames the codec could produce
results in integer frame length in RTP timestamp ticks. That way a
receiver can always correctly place the frames in relation to any
other frame, also at frame length changes. The down side is that the
decoder output for certain frame lengths are in fact partial samples.
Resulting in that the output in samples from the codec will vary from
frame to frame, potentially making implementation more difficult.</t>
<t>The RTP payload format for MIDI <xref target="RFC4695"></xref>
contains some interesting features. MIDI is an audio format sensitive
to packet losses, as the loss of a note off command will result in
that a note will be stuck in an on state. To counter this a recovery
journal is defined that provides a summarized state that allows the
receiver to recover from packet losses quickly. It also uses RTCP and
the reported highest sequence number to be able to prune the state the
recovery journal needs to contain. These features appears limited in
applicability for media formats that are highly stateful and primarily
uses symbolic media representations.</t>
</section>
<section title="Video">
<t>The definition of RTP payload formats for video has seen an
evolution from the early ones such as H.261 towards the latest for
VC-1 and H.264.</t>
<t>The H.264 RTP payload format <xref target="RFC3984"></xref> can be
seen as a smorgasbord of functionality, some pretty advanced as the
interleaving. The reason for this was to ensure that the majority of
applications considered by the ITU-T and MPEG that can be supported by
RTP was supported. This has created a payload format that rarely is
implemented in its completness. Despite that no major issues with
interoperability has been reported. However, there are common
complaints about its complexity.</t>
<t>The RTP payload format for uncompressed video <xref
target="RFC4175"></xref> is basically required to be mentioned in this
context as it contains a special feature not commonly seen in RTP
payload formats. Due to the high bit-rate and thus packet rate of
uncompressed video (gigabits rather than megabits) the payload format
include a field to extend the RTP sequence number as the normal 16-bit
one can wrap in below a second. It also specifies a registry of
different color sub-sampling that can be re-used in other video RTP
payload formats.</t>
</section>
<section title="Text">
<t>There would be overstating that there exist a trend in text payload
formats as only a single format actually carrying a text format has
been standardized in IETF, namely T.140 <xref
target="RFC4103"></xref>. The 3GPP Timed Text format <xref
target="RFC4396"></xref> could be considered to be text, despite it in
the end was registered as a video format. This is decorated text,
usable for subtitles and other embelishments of video which is why it
ended up being registered as video format. However, it has many of the
properties that text formats in generally have.</t>
<t>The RTP payload format for T.140 was designed with high reliability
in mind as real-time text commonly are a extremely low-bit rate
application. Thus, it recommends the use of RFC 2190 with many
redundancy generations. However, the format failed to provide a text
block specific sequence number and relies instead of the RTP one to
detection loss. This makes detection of missing text blocks
unecessarily difficult and hinders the deployement with other
robustness mechanisms that would switch the payload type as that may
result in erronous error marking in the T.140 text stream.</t>
</section>
</section>
<section title="Important Specification Sections">
<t>There a number of sections in the payload format draft that needs
some special considerations. These include security and IANA
considerations.</t>
<section anchor="sec-consideration" title="Security Consideration">
<t>All Internet drafts requires a Security Consideration section. The
security consideration section in an RTP payload format needs to
concentrate on the security properties this particular format has.
Some payload format has very little specific issues or properties and
can fully fall back on the general RTP and used profile's security
considerations. Due to that these are always applicable a reference to
these are normally placed first in the security consideration
section.</t>
<t>The security issues of confidentiality, integrity protection and
source authentication are common issues for all payload formats. These
should be solved by payload external mechanism and does not need any
special consideration in the payload format except for an reminder on
these issues. A suitable stock text to inform people about this is
included in the template.</t>
<t>Potential security issues with an RTP payload format and the media
encoding that needs to be considered are:</t>
<t><list style="numbers">
<t>That the decoding of the payload format or its media shows
substantial non-uniformity, either in output or in complexity to
perform the decoding operation. For example a generic
non-destructive compression algorithm may provide an output of
almost infinite size for a very limited input. Thus consuming
memory or storage space out of proportion with what the receiving
application expected causing some sort of disruption, i.e. a
denial of service attack on the receiver by preventing that host
to produce any good put. Certain decoding operations may also have
variable consumption of amount of processing needed to perform
such operations dependent on the input. This may also be a
security risk if that processing load is possible to raise
significantly from nominal simply by designing a malicious input
sequence. If such potential exist this must be expressed in the
security consideration section to make implementers aware of the
need to take precautions against such behavior.</t>
<t>The inclusion of active content in the media format or its
transport. With active content means scripts etc that allows an
attacker to perform potentially arbitrary operations on the
receiver. Most active content have limited possibility to access
the system or perform operations outside a protected sandbox.
However if active content may be included the potential risk must
be noted. It is also strongly recommend that references to any
security model applicable for such content is referenced.</t>
<t>Some media formats allows for the carrying of "user data", or
types of data which is not known at the time of the specification
of the payload format. Such data may be a security risk and should
be mentioned.</t>
</list>Suitable stock text for the security consideration is
provided in the template. However the authors do need to actively
consider any security issues from the start. Failure to address these
issues is blocking approval and publication.</t>
</section>
<section title="Congestion Control">
<t>RTP and its profiles do discuss congestion control. Congestion
control is an important issue in any usage in non-dedicated networks.
For that reason all RTP payload formats are recommended to discuss the
possibilities that exist to regulate the bit-rate of the transmissions
using the described RTP payload format. Some formats may have limited
or step wise regulation of bit-rate. Such limiting factor should be
discussed.</t>
</section>
<section anchor="iana-consideration" title="IANA Consideration">
<t>Due to that all RTP Payload format contains a Media Type
specification they also need an IANA consideration section. The media
type name must be registered and this is done by requesting that IANA
register that media name. When that registration request is written it
shall also be requested that the media type is included under the "RTP
Payload Format MIME types" list part of the RTP registry.</t>
<t>In addition to the above request for media type registration some
payload formats may have parameters where in the future new parameter
values needs to be added. In these cases a registry for that parameter
must be created. This is done by defining the registry in the IANA
consideration section. <xref target="RFC5226">BCP 26 (RFC 5226)</xref>
provides guidelines to writing such registries. Care should be taken
when defining the policy for new registrations.</t>
<t>Before writing a new registry it is worth checking the existing
ones in the IANA "MIME Media Type Sub-Parameter Registries". For
example video formats needing a media parameter expressing color
sub-sampling may be able to reuse those defined for <xref
target="RFC4175">video/raw</xref>.</t>
</section>
<t></t>
</section>
<section title="Authoring Tools">
<t>This section informs and recommends some tools that may be used.
Don't be pressured to follow these recommendation. There exist a number
of alternatives. But these suggestion is worth checking out before
deciding that the field is greener somewhere else.</t>
<section title="Editing Tools">
<t>There is many choices when it comes to tools to choose for
authoring Internet drafts. However in the end they needs to be able to
produce a draft that conforms to the Internet drafts requirements. If
you don't have any previous experience with authoring Internet drafts
XML2RFC do have some advantages. It helps creating a lot of the
necessary boiler plate in accordance with the latest rules. Thus
reducing the effort. It also speeds up the publication after approval
as the RFC-editor can use the source XML document to quicker produce
the RFC.</t>
<t>Another common choice is to use Microsoft Word and a suitable
template, see <xref target="RFC3285"></xref> to produce the draft and
print that using the generic text printer. It has some advantage when
it comes to spell checking and change bars. However Word may also
produce some problems, like changing formating, inconsistent result
between what one sees in the editor and in the generated text
document, at least according to the authors personal experience.</t>
</section>
<section title="Verification Tools">
<t>There are few tools that are very good to know about when writing
an draft. These help check and verify parts of ones work. These tools
can be found at http://tools.ietf.org.</t>
<t><list style="symbols">
<t>ID Nits checker. It checks that the boiler plate and some other
things that are easily verifiable by machine is okay in your
draft. Always use it before submitting a draft to avoid direct
refusal in the submission step.</t>
<t>ABNF Parser and verification. Used to check that your ABNF
parses correctly and warns about loose ends, like undefined
symbols. However the actual content can only be verified by humans
knowing what it intends to describe.</t>
<t>RFC diff. A diff tool that is optimized for drafts and RFC. For
example it doesn't point out that the foot and header has moved in
relation to the text on every page.</t>
</list></t>
</section>
</section>
<section title="Open Issues">
<t>This document currently has a few open issues that needs resolving
before publication:</t>
<t><list style="symbols">
<t>Should any procedure for the future when the AVT WG is closed be
described?</t>
<t>The section of current examples of good work needs to be filled
in.</t>
<t>Consider mention RFC-errata</t>
</list></t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
<t>Note to RFC Editor: this section may be removed on publication as an
RFC.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>As this is an informational document on the writing of drafts
intended to be RFCs there is no direct security considerations. However
the document does discuss the writing of security consideration sections
and what should be particular considered when specifying RTP payload
formats.</t>
</section>
<section title="RFC Editor Consideration">
<t>Note to RFC Editor: This section may be removed after carrying out
all the instructions of this section.</t>
<t></t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The author would like to thank the invididuals that has provied input
to this document. These individuals include: John Lazzaro.</t>
</section>
</middle>
<back>
<references title="Informative References">
&rfc1305;
&rfc2026;
&rfc2198;
&rfc2326;
&rfc2360;
&rfc2418;
&rfc2508;
&rfc2616;
&rfc2736;
&rfc2959;
&rfc2974;
&rfc3095;
&rfc3261;
&rfc3264;
&rfc3285;
<?rfc include='reference.RFC.3410'?>
&rfc3545;
&rfc3550;
&rfc3551;
&rfc3558;
&rfc3569;
&rfc3577;
&rfc3611;
&rfc3711;
<?rfc include='reference.RFC.3828'?>
&rfc3978;
&rfc3979;
&rfc3984;
&rfc4103;
&rfc4170;
&rfc4175;
&rfc4288;
&rfc4301;
&rfc4346;
&rfc4347;
&rfc4352;
<?rfc include='reference.RFC.4396'?>
&rfc4566;
<?rfc include='reference.RFC.4571'?>
&rfc4585;
&rfc4588;
<?rfc include='reference.RFC.4648'?>
&rfc4677;
<?rfc include='reference.RFC.4695'?>
<?rfc include='reference.RFC.4855'?>
<?rfc include='reference.RFC.4867'?>
<?rfc include='reference.RFC.4975'?>
<?rfc include='reference.RFC.5124'?>
<?rfc include='reference.RFC.5109'?>
<?rfc include='reference.RFC.5226'?>
<reference anchor="CSP-RTP">
<front>
<title>RTP: Audio and Video for the Internet</title>
<author fullname="Perkins" initials="" surname="Colin ">
<organization>Addison-Wesley, ISBN 0-672-32249-8</organization>
</author>
<date month="June" year="2003" />
</front>
</reference>
<reference anchor="MACOSFILETYPES">
<front>
<title>Mac OS: File Type and Creator Codes, and File Formats</title>
<author fullname="Apple Computer, Inc.">
<organization>Apple Knowledge Base Article
55381<http://www.info.apple.com/kbnum/n55381></organization>
</author>
<date year="1993" />
</front>
</reference>
<reference anchor="RFC-ED">
<front>
<title>RFC Editorial Guidelines and Procedures</title>
<author fullname="RFC-Editor">
<organization>http://www.rfc-editor.org/policy.html</organization>
</author>
<date day="11" month="July" year="2008" />
</front>
</reference>
</references>
<section title="RTP Payload Format Template">
<t>This section contains a template for writing an RTP payload format in
form as a Internet draft. Text within [...] are instructions and must be
removed. Some text proposals that are included are conditional. "..." is
used to indicate where further text should be written.</t>
<section title="Title">
<t>[The title shall be descriptive but as compact as possible. RTP is
allowed and recommended abbreviation in the title]</t>
<t>RTP Payload format for ...</t>
</section>
<section title="Front page boilerplate">
<t>Status of this Memo</t>
<t>[Insert the IPR notice boiler plate from BCP 79 that applies to
this draft.]</t>
<t>[Insert the current Internet Draft document explanation. At the
time of publishing it was:]</t>
<t>Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet- Drafts.</t>
<t>Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."</t>
<t>[Insert the ID list and shadow list reference. At the time of
publishing it was:]</t>
<t>The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.</t>
<t>The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.</t>
<t>[Optionally: Select either of these paragraphs depending on draft
status]</t>
<t>This document is an individual submission to the IETF. Comments
should be directed to the authors.</t>
<t>This document is a submission of the IETF AVT WG. Comments should
be directed to the AVT WG mailing list, avt@ietf.org.</t>
</section>
<section title="Abstract">
<t>[An payload format abstract should mention the capabilities of the
format, for which media format is used, and a little about that codec
formats capabilities. Any abbreviation used in the payload format must
be spelled out here except the very well known like RTP. No references
are allowed, no use of RFC 2119 language either.]</t>
</section>
<section title="Table of Content">
<t>[All drafts over 15 pages in length must have an Table of
Content.]</t>
</section>
<section title="Introduction">
<t>[The introduction should provide a background and overview of the
payload formats capabilities. No normative language in this section,
i.e. no MUST, SHOULDS etc.]</t>
</section>
<section title="Conventions, Definitions and Acronyms">
<t>[Define conventions, definitions and acronyms used in the document
in this section. The most common definition used in RTP Payload
formats are the RFC 2119 definitions of the upper case normative
words, e.g. MUST and SHOULD.]</t>
<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 RFC 2119.</t>
</section>
<section title="Media Format Background">
<t>[The intention of this section is to enable reviewers and persons
to get an overview of the capabilities and major properties of the
media format. It should be kept short and concise and is not a
complete replacement for reading the media format specification.]</t>
</section>
<section title="Payload format">
<t>[Overview of payload structure]</t>
<section title="RTP Header Usage">
<t>[RTP header usage needs to be defined. The fields that absolutely
need to be defined are timestamp and marker bit. Further field may
be specified if used. All the rest should be left to their RTP
specification definition]</t>
<t>The remaining RTP header fields are used as specified in RFC
3550.</t>
</section>
<section title="Payload Header">
<t>[Define how the payload header, if it exist, is structured and
used.]</t>
</section>
<section title="Payload Data">
<t>[The payload data, i.e. what the media codec has produced.
Commonly done through reference to media codec specification which
defines how the data is structured. Rules for padding may need to be
defined to bring data to octet alignment.]</t>
</section>
</section>
<section title="Payload Examples">
<t>[One or more examples are good to help ease the understanding of
the RTP payload format.]</t>
</section>
<section title="Congestion Control Considerations">
<t>[This section is to describe the possibility to vary the bit-rate
as a response to congestion. Below is also a proposal for an initial
text that reference RTP and profiles definition of congestion
control.]</t>
<t>Congestion control for RTP SHALL be used in accordance with <xref
target="RFC3550">RFC 3550</xref>, and with any applicable RTP profile;
e.g., <xref target="RFC3551">RFC 3551</xref>. An additional
requirement if best-effort service is being used is: users of this
payload format MUST monitor packet loss to ensure that the packet loss
rate is within acceptable parameters.</t>
</section>
<section title="Payload Format Parameters">
<t>This RTP payload format is identified using the ... media type
which is registered in accordance with <xref target="RFC4855">RFC
4855</xref> and using the template of <xref target="RFC4288">RFC
4288</xref>.</t>
<section anchor="media-type" title="Media Type Definition">
<t>[Here the media type registration template from RFC 4288 is
placed and filled out. This template is provided with some common
RTP boilerplate.]</t>
<t>Type name:</t>
<t>Subtype name:</t>
<t>Required parameters:</t>
<t>Optional parameters:</t>
<t>Encoding considerations:</t>
<t>This media type is framed and binary, see section 4.8 in <xref
target="RFC4288">RFC4288</xref>.</t>
<t>Security considerations:</t>
<t>Interoperability considerations:</t>
<t>Published specification:</t>
<t>Applications that use this media type:</t>
<t>Additional information:</t>
<t>Magic number(s):</t>
<t>File extension(s):</t>
<t>Macintosh file type code(s):</t>
<t>Person & email address to contact for further
information:</t>
<t>Intended usage: (One of COMMON, LIMITED USE or OBSOLETE.)</t>
<t>Restrictions on usage:</t>
<t>[The below text is for media types that is only defined for RTP
payload formats. There exist certain media types that are defined
both as RTP payload formats and file transfer. The rules for such
types are documented in <xref target="RFC4855">RFC 4855</xref>.]</t>
<t>This media type depends on RTP framing, and hence is only defined
for transfer via RTP [RFC3550]. Transport within other framing
protocols is not defined at this time.</t>
<t>Author:</t>
<t>Change controller:</t>
<t>IETF Audio/Video Transport working group delegated from the
IESG.</t>
<t>(Any other information that the author deems interesting may be
added below this line.)</t>
<t>[From RFC 4288: Some discussion of Macintosh file type codes and
their purpose can be found in <xref target="MACOSFILETYPES"></xref>.
Additionally, please refrain from writing "none" or anything similar
when no file extension or Macintosh file type is specified, lest
"none" be confused with an actual code value.]</t>
</section>
<section title="Mapping to SDP">
<t>The mapping of the above defined payload format media type and
its parameters SHALL be done according to Section 3 of <xref
target="RFC4855">RFC 4855</xref>.</t>
<t>[More specific rules only need to be included if some parameter
does not match these rules.]</t>
<section title="Offer/Answer Considerations">
<t>[Here write your offer/answer consideration section, please see
Section <xref target="OA-sdp"></xref> for help.]</t>
</section>
<section title="Declarative SDP Considerations">
<t>[Here write your considerations for declarative SDP, please see
Section <xref target="dec-sdp"></xref> for help.]</t>
</section>
</section>
</section>
<section title="IANA Considerations">
<t>This memo requests that IANA registers [insert media type name
here] as specified in <xref target="media-type"></xref>. The media
type is also requested to be added to the IANA registry for "RTP
Payload Format MIME types"
(http://www.iana.org/assignments/rtp-parameters).</t>
<t>[See Section <xref target="iana-consideration"></xref> and consider
if any of the parameter needs a registered name space.]</t>
</section>
<section title="Securtiy Considerations">
<t>[See Section <xref target="sec-consideration"></xref>]</t>
<t>RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the <xref
target="RFC3550">RTP specification</xref> , and in any applicable RTP
profile. The main security considerations for the RTP packet carrying
the RTP payload format defined within this memo are confidentiality,
integrity and source authenticity. Confidentiality is achieved by
encryption of the RTP payload. Integrity of the RTP packets through
suitable cryptographic integrity protection mechanism. Cryptographic
system may also allow the authentication of the source of the payload.
A suitable security mechanism for this RTP payload format should
provide confidentiality, integrity protection and at least source
authentication capable of determining if an RTP packet is from a
member of the RTP session or not.</t>
<t>Note that the appropriate mechanism to provide security to RTP and
payloads following this memo may vary. It is dependent on the
application, the transport, and the signalling protocol employed.
Therefore a single mechanism is not sufficient, although if suitable
the usage of <xref target="RFC3711">SRTP</xref> is recommended. Other
mechanism that may be used are <xref target="RFC4301">IPsec</xref> and
<xref target="RFC4346">TLS</xref> (RTP over TCP), but also other
alternatives may exist.</t>
<t>[Fill in here any further potential security threats]</t>
</section>
<section title="References">
<t>[References must be classified as either normative or informative
and added to the relevant section. References should use descriptive
reference tags.]</t>
<section title="Normative References">
<t>[Normative references are those that are required to be used to
correctly implement the payload format.]</t>
</section>
<section title="Informative References">
<t>[All other references.]</t>
</section>
</section>
<section title="Author Addresses">
<t>[All Authors need to include their Name and email addresses as a
minimal. Commonly also surface mail and possibly phone numbers are
included.]</t>
</section>
<section title="IPR Notice">
<t>[Use the appropriate boilerplate from Section 5 of <xref
target="RFC3979">BCP 79</xref>.]</t>
</section>
<section title="Copyright Notice">
<t>[Use the boilerplate from Section 5.4 and 5.5 of <xref
target="RFC3978">BCP 78</xref>.]</t>
</section>
</section>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 03:15:00 |