Payload Working Group M. Westerlund
Internet-Draft Ericsson
Intended status: Informational March 3, 2011
Expires: September 4, 2011
How to Write an RTP Payload Format
draft-ietf-payload-rtp-howto-00
Abstract
This document contains information on how to best write an RTP
payload format. It provides reading tips, design practices, and
practical tips on how to produce an RTP payload format specification
quickly and with good results. A template is also included with
instructions that can be used when writing an RTP payload format.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on September 4, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Westerlund Expires September 4, 2011 [Page 1]
Internet-Draft HOWTO: RTP Payload Formats March 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Preparations . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Recommend Reading . . . . . . . . . . . . . . . . . . . . 7
3.1.1. IETF Process and Publication . . . . . . . . . . . . . 7
3.1.2. RTP . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Important RTP details . . . . . . . . . . . . . . . . . . 12
3.2.1. The RTP Session . . . . . . . . . . . . . . . . . . . 12
3.2.2. RTP Header . . . . . . . . . . . . . . . . . . . . . . 13
3.2.3. RTP Multiplexing . . . . . . . . . . . . . . . . . . . 14
3.2.4. RTP Synchronization . . . . . . . . . . . . . . . . . 15
3.3. Signalling Aspects . . . . . . . . . . . . . . . . . . . . 17
3.3.1. Media Types . . . . . . . . . . . . . . . . . . . . . 17
3.3.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . 18
3.4. Transport Characteristics . . . . . . . . . . . . . . . . 21
3.4.1. Path MTU . . . . . . . . . . . . . . . . . . . . . . . 21
4. Specification Process . . . . . . . . . . . . . . . . . . . . 22
4.1. IETF . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.1. Steps from Idea to Publication . . . . . . . . . . . . 22
4.1.2. WG meetings . . . . . . . . . . . . . . . . . . . . . 24
4.1.3. Draft Naming . . . . . . . . . . . . . . . . . . . . . 24
4.1.4. How to speed up the process . . . . . . . . . . . . . 25
4.2. Other Standards bodies . . . . . . . . . . . . . . . . . . 25
4.3. Proprietary and Vendor Specific . . . . . . . . . . . . . 26
5. Designing Payload Formats . . . . . . . . . . . . . . . . . . 28
5.1. Features of RTP Payload Formats . . . . . . . . . . . . . 28
5.1.1. Aggregation . . . . . . . . . . . . . . . . . . . . . 28
5.1.2. Fragmentation . . . . . . . . . . . . . . . . . . . . 29
5.1.3. Interleaving and Transmission Re-Scheduling . . . . . 29
5.1.4. Media Back Channels . . . . . . . . . . . . . . . . . 30
5.1.5. Scalability . . . . . . . . . . . . . . . . . . . . . 30
5.1.6. High Packet Rates . . . . . . . . . . . . . . . . . . 31
6. Current Trends in Payload Format Design . . . . . . . . . . . 32
6.1. Audio Payloads . . . . . . . . . . . . . . . . . . . . . . 32
6.2. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.3. Text . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7. Important Specification Sections . . . . . . . . . . . . . . . 34
Westerlund Expires September 4, 2011 [Page 2]
Internet-Draft HOWTO: RTP Payload Formats March 2011
7.1. Media Format Description . . . . . . . . . . . . . . . . . 34
7.2. Security Considerations . . . . . . . . . . . . . . . . . 34
7.3. Congestion Control . . . . . . . . . . . . . . . . . . . . 35
7.4. IANA Considerations . . . . . . . . . . . . . . . . . . . 35
8. Authoring Tools . . . . . . . . . . . . . . . . . . . . . . . 37
8.1. Editing Tools . . . . . . . . . . . . . . . . . . . . . . 37
8.2. Verification Tools . . . . . . . . . . . . . . . . . . . . 37
9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 38
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
11. Security Considerations . . . . . . . . . . . . . . . . . . . 40
12. RFC Editor Considerations . . . . . . . . . . . . . . . . . . 41
13. Contributiors . . . . . . . . . . . . . . . . . . . . . . . . 42
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43
15. Informative References . . . . . . . . . . . . . . . . . . . . 44
Appendix A. RTP Payload Format Template . . . . . . . . . . . . . 49
A.1. Title . . . . . . . . . . . . . . . . . . . . . . . . . . 49
A.2. Front page boilerplate . . . . . . . . . . . . . . . . . . 49
A.3. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . 49
A.4. Table of Content . . . . . . . . . . . . . . . . . . . . . 49
A.5. Introduction . . . . . . . . . . . . . . . . . . . . . . . 50
A.6. Conventions, Definitions and Acronyms . . . . . . . . . . 50
A.7. Media Format Description . . . . . . . . . . . . . . . . . 50
A.8. Payload format . . . . . . . . . . . . . . . . . . . . . . 50
A.8.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . 50
A.8.2. Payload Header . . . . . . . . . . . . . . . . . . . . 50
A.8.3. Payload Data . . . . . . . . . . . . . . . . . . . . . 50
A.9. Payload Examples . . . . . . . . . . . . . . . . . . . . . 51
A.10. Congestion Control Considerations . . . . . . . . . . . . 51
A.11. Payload Format Parameters . . . . . . . . . . . . . . . . 51
A.11.1. Media Type Definition . . . . . . . . . . . . . . . . 51
A.11.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . 53
A.12. IANA Considerations . . . . . . . . . . . . . . . . . . . 53
A.13. Securtiy Considerations . . . . . . . . . . . . . . . . . 53
A.14. References . . . . . . . . . . . . . . . . . . . . . . . . 54
A.14.1. Normative References . . . . . . . . . . . . . . . . . 54
A.14.2. Informative References . . . . . . . . . . . . . . . . 54
A.15. Author Addresses . . . . . . . . . . . . . . . . . . . . . 54
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 55
Westerlund Expires September 4, 2011 [Page 3]
Internet-Draft HOWTO: RTP Payload Formats March 2011
1. Introduction
RTP [RFC3550] 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 in many individuals/
organizations with media encoders or other types of real-time data to
define RTP payload formats. However, the specification of a well-
designed RTP payload format is non-trivial and requires knowledge of
both RTP and the real-time data format.
This document is intended to help any author of an RTP payload format
make important design decisions, consider important features of RTP
and RTP security, etc. The document is also intended to be a good
starting point for any person with little experience in the IETF
and/or RTP to learn the necessary steps.
This document extends and updates the information that is available
in "Guidelines for Writers of RTP Payload Format Specifications"
[RFC2736]. Since that RFC was written, further experience has been
gained on the design and specification of RTP payload formats.
Several new RTP profiles have been defined, and robustness tools have
also been defined, and these need to be considered.
We also discuss the possible venues for defining an RTP payload
format, in IETF, by other standard bodies and proprietary ones.
1.1. Structure
This document has several different parts discussing different
aspects of the creation of an RTP payload format specification.
Section 3 discusses the preparations the author(s) should do before
starting to write a specification. Section 4 discusses the different
processes used when specifying and completing a payload format, with
focus on working inside the IETF. Section 5 discusses the design of
payload formats themselves in detail. Section 6 discusses current
design trends and provides good examples of practices that should be
followed when applicable. Following that Section 7 provides a
discussion on important sections in the RTP payload format
specification itself such as security and IANA considerations. This
document ends with an appendix containing a template that can be used
when writing RTP payload formats.
Westerlund Expires September 4, 2011 [Page 4]
Internet-Draft HOWTO: RTP Payload Formats March 2011
2. Terminology
2.1. Definitions
Media Stream: A sequence of RTP packets that together carry part or
all of the content of a specific medium (audio, video, text, or
data whose form and meaning are defined by a specific real-time
application) from a specific sender source within a given RTP
session.
RTP Session: An association among a set of participants
communicating with RTP. The distinguishing feature of an RTP
session is that each session maintains a full, separate space of
SSRC identifiers. See also Section (Section 3.2.1).
RTP Payload Format: The RTP payload format specifies how units of a
specific encoded medium are put into the RTP packet payloads and
how the fields of the RTP packet header are used, thus enabling
the format to be used in RTP sessions.
2.2. Acronyms
ABNF: Augmented Backus-Naur Form [RFC5234]
ADU: Application Data Unit
ALF: Application Level Framing
ASM: Any-Source Multicast
AVT: Audio Video Transport
BCP: Best Current Practice
ID: Internet Draft
IESG: Internet Engineering Steering Group
MTU: Maximum Transmission Unit
WG: Working Group
QoS: Quality of Service
RFC: Request For Comment
Westerlund Expires September 4, 2011 [Page 5]
Internet-Draft HOWTO: RTP Payload Formats March 2011
RTP: Real-time Transport Protocol
RTCP: RTP Control Protocol
RTT: Round Trip Time
SSM: Source Specific Multicast
Westerlund Expires September 4, 2011 [Page 6]
Internet-Draft HOWTO: RTP Payload Formats March 2011
3. Preparations
RTP is a complex real-time media delivery framework and it has a lot
of details that needs to be considered when writing an RTP payload
format. It is also important to have a good understanding of the
media codec/format so that all of its important features and
properties are considered. Only when one has sufficient
understanding of both parts one can produce an RTP payload format of
high quality. On top of this, one needs to understand the process
within IETF and especially the Working Group responsible for
standardizing payload formats (currently PAYLOAD) to go quickly from
initial idea stage to a finished RFC. This and the next section help
an author prepare himself in those regards.
3.1. Recommend Reading
The following sub-sections list a number of documents. Not all need
to be read in full detail. However, an author basically needs to be
aware of everything listed below.
3.1.1. IETF Process and Publication
Newcomers to the IETF are strongly recommended to read the "Tao of
the IETF" [RFC4677] that goes through most things that one needs to
know about the IETF. This contains information about history,
organisational structure, how the WG and meetings work and many more
details.
The main part of the IETF process is formally defined in RFC 2026
[RFC2026]. In addition an author needs to understands the IETF rules
and rights associated with copyright and IPR documented in BCP 78
[RFC5378] and BCP 79 [RFC3979]. RFC 2418 [RFC2418] describes the WG
process, the relation between the IESG and the WG, and the
responsibilities of WG chairs and participants.
It is important to note that the RFC series contain documents of
several different categories: standards track, informational,
experimental, best current practice (BCP), and historic. The
standard track contains documents of three different maturity
classifications, proposed, draft and Internet Standard. A standards
track document must start as proposed; after proof of the
interoperability of all of its features it can be moved to draft
standard; and finally when further experience has been gathered and
it has been widely deployed it can be moved to Internet Standard. As
the content of a given RFC is not allowed to change once published,
the only way to modify an RFC is to write and publish a new one that
either updates or replaces the old one. Therefore, whether reading
or referencing an RFC, it is important to consider both the Category
Westerlund Expires September 4, 2011 [Page 7]
Internet-Draft HOWTO: RTP Payload Formats March 2011
field in the document header and to check if the RFC is the latest on
the subject and still 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 RFC update or obsolete
it.
Before starting to write a 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 RFC editorial
guidelines and procedures [RFC-ED]. Another document that can be
useful is the "Guide for Internet Standards Writers" [RFC2360].
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.
RFC 2606: When writing examples using DNS names in Internet drafts,
those names shall be chosen from the example.com, example.net, and
example.org domains.
RFC 3849: Defines the range of IPv6 unicast addresses (2001:
DB8::/32) that should be used in any examples.
RFC 5737: Defines the ranges of IPv4 unicast addresses reserved for
documentation and examples: 192.0.2.0/24, 198.51.100.0/24, and
203.0.113.0/24.
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.
3.1.2. RTP
The recommended reading for RTP consist of several different parts;
design guidelines, the RTP protocol, profiles, robustness tools, and
media specific recommendations.
Any author of RTP payload formats should start by reading RFC 2736
[RFC2736] 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.
Westerlund Expires September 4, 2011 [Page 8]
Internet-Draft HOWTO: RTP Payload Formats March 2011
Then it is advisable to learn more about the RTP protocol, by
studying the RTP specification RFC 3550 [RFC3550] and the existing
profiles. As a complement to the standards document there exists a
book totally dedicated to RTP [CSP-RTP]. There exist several
profiles for RTP today, but all are based on the "RTP Profile for
Audio and Video Conferences with Minimal Control" (RFC 3551)
[RFC3551] (abbreviated AVP). The other profiles that one should know
about are Secure RTP (RTP/SAVP) [RFC3711], "Extended RTP Profile for
RTCP-based Feedback (RTP/AVPF)" [RFC4585] and "Extended Secure RTP
Profile for RTCP-based Feedback (RTP/SAVPF)" [RFC5124]. It is
important to understand RTP and the AVP profile in detail. For the
other profiles it is sufficient to have an understanding of what
functionality they provide and the limitations they create.
A number of robustness tools have been developed for RTP. The tools
are for different use cases and real-time requirements.
RFC 2198: The "RTP Payload for Redundant Audio Data" [RFC2198]
provides functionalities to transmit redundant copies of audio or
text payloads. These redundant copies are sent together with a
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 most suitable to be used with audio.
However, the RTP Payload format for T.140 [RFC4103] text format
also uses this format. The format's major property is that it
only preserves the timestamp of the redundant payloads, not the
original sequence number. This makes it unusable for most video
formats. This format is also only suitable for media formats that
produce relatively small RTP payloads.
RFC 5109: The "RTP Payload Format for Generic Forward Error
Correction (FEC)" [RFC5109] provides an XOR based FEC of the whole
or parts of 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.
RTP Retransmission: The RTP retransmission scheme [RFC4588] 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 in networks with short round-
trip times (RTT).
Westerlund Expires September 4, 2011 [Page 9]
Internet-Draft HOWTO: RTP Payload Formats March 2011
RTP over TCP: RFC 4571 [RFC4571] defines how one sends RTP and RTCP
packets over connection-oriented transports like TCP. If one uses
TCP, one gets reliability for all packets but loses 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.
There has also been both discussion and design of RTP payload
formats, e.g AMR and AMR-WB[RFC4867], supporting the unequal error
detection provided by UDP-Lite [RFC3828]. 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
unnecessary discarding of data when the payload and media codec can
get at least some benefit from the data. The main issue is that one
has no idea of the level of bit errors present in the unprotected
part of the payload. This 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.
There also exist some management and monitoring extensions.
RFC 2959: The RTP protocol Management Information Database (MIB)
[RFC2959] that is used with SNMP [RFC3410] to configure and
retrieve information about RTP sessions.
RFC 3611: The RTCP Extended Reports (RTCP XR) [RFC3611] consists of
a framework for reports sent within RTCP. It can easily be
extended by defining new report formats in the future. The report
formats that are defined in RFC3611 provide report information on
packet loss, packet duplication, packet reception times, RTCP
statistics summary and VoIP Quality. [RFC3611] also defines a
mechanism that allows receivers to calculate the RTT to other
session participants when used.
RMONMIB: The remote monitoring work group has defined a mechanism
[RFC3577] based on usage of the MIB that can be an alternative to
RTCP XR.
A number of transport optimizations have also been developed for use
in certain environments. They are all intended to be transparent and
do not require special consideration by the RTP payload format
writer. Thus they are primarily listed here for informational
reasons and do not require deeper studies.
Westerlund Expires September 4, 2011 [Page 10]
Internet-Draft HOWTO: RTP Payload Formats March 2011
RFC 2508: Compressing IP/UDP/RTP headers for slow serial links
(CRTP) [RFC2508] 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.
RFC 3095 & RFC 5795: This is the base specifications of the robust
header compression (ROHC) protocol version 1 [RFC3095] and version
2[RFC5795]. This solution was created as a result of CRTP's lack
of performance when compressed packets are subject to loss.
RFC 3545: Enhanced compressed RTP (E-CRTP) [RFC3545] was developed
to provide extensions to CRTP that allow for better performance
over links with long RTTs, packet loss and/or reordering.
RFC 4170: Tunneling Multiplexed Compressed RTP (TCRTP) [RFC4170] is
a solution that allows header compression within a tunnel carrying
multiple multiplexed RTP flows. This is primarily used in voice
trunking.
There exist a couple of different security mechanisms that may be
used with RTP. Generic mechanisms by definition are transparent for
the RTP payload format and do not need special consideration by the
format designer. The main reason that different solutions exist is
that different applications have different requirements thus
different solutions have been developed. For more discussion on this
please see [I-D.ietf-avt-srtp-not-mandatory]. 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 mechanisms provide
all of these features, a point which will need to be considered when
one of these mechanisms is used.
RTP Encryption: Section 9 of RFC 3550 describes a mechanism to
provide confidentiality of the RTP and RTCP packets, using default
DES encryption. It may use other encryption algorithms if both
end-points agree on one. This mechanism is not recommended due to
the weak security properties of the encryption algorithms used.
It also lacks integrity and source authentication capability.
SRTP: The profile for Secure RTP (SAVP) [RFC3711] and the derived
profile (SAVPF [RFC5124]) are a solution that provides
confidentiality, integrity protection and partial source
authentication.
Westerlund Expires September 4, 2011 [Page 11]
Internet-Draft HOWTO: RTP Payload Formats March 2011
IPsec: IPsec [RFC4301] may also be used to protect RTP and RTCP
packets.
TLS: TLS [RFC5246] may also be used to provide transport security
between two end-points of the TLS connection for a flow of RTP
packets that are framed over TCP.
DTLS: Datagram TLS [RFC4347] is an alternative to TLS that allows
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 mechanisms for using it have not been
developed yet in any of the IETF real-time media application
signalling protocols.
DTSL-SRTP: This combination of DTLS [RFC4347] and SRTP [RFC3711]
uses DTLS as mechanism to negotiate key material and cipher suits
for SRTP and SRTP to protect the actual media transported by RTP.
DTLS-SRTP is a recommended solution for point-to-point RTP
sessions. "Framework for Establishing a Secure Real-time
Transport Protocol (SRTP) Security Context Using Datagram
Transport Layer Security (DTLS)" [RFC5763] is the core document,
protocol extensions for DTLS are defined in [RFC5764].
3.2. Important RTP details
This section does not remove the necessity to read up on RTP.
However it does point out a few important details to remember when
designing a payload format.
3.2.1. The RTP Session
The definition of the RTP session from RFC 3550 is:
"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."
Westerlund Expires September 4, 2011 [Page 12]
Internet-Draft HOWTO: RTP Payload Formats March 2011
"The distinguishing feature of an RTP session is that each session
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."
"The RTP framework allows the variations defined here (RFC3550), but
a particular control protocol or application design will usually
impose constraints on these variations."
3.2.2. RTP Header
The RTP header contains a number of fields. Two fields always
require additional specification by the RTP payload format, namely
the RTP Timestamp and the marker bit. Certain RTP payload formats
also use the RTP sequence number to realize certain functionalities.
The payload type is used to indicate the used payload format. The
Sender Source Identifier (SSRC) is used to distinguish RTP packets
from multiple senders. Finally, [RFC5285] specifies how to extend
the RTP header to carry metadata relating to the payload when this is
desirable.
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 enables jitter buffer adaptation prior to
the beginning of the burst with minimal audio quality impact. In
video the marker bit is normally used to indicate the last packet
part of an frame. This enables a decoder to finish decoding the
picture, where it otherwise may need to wait for the next packet
to explicitly know that the frame is finished.
Timestamp: The RTP timestamp indicates the time instance the media
sample 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 the clock rates allowed.
Westerlund Expires September 4, 2011 [Page 13]
Internet-Draft HOWTO: RTP Payload Formats March 2011
Note that clock rates below 1000 Hz are not appropriate because it
will cause a too low resolution in the RTCP measurements. RTP
payload formats with a timestamp definition which results in no or
little correlation between the media time instance and its
transmission time cause the RTCP jitter calculation to become
unusable due to the errors introduced on the sender side. It
should be noted if the payload format has this property or not.
Sequence number: The sequence number is monotonically increasing and
is set as the packet is sent. This property is used in many
payload formats to recover the order of everything from the whole
stream down to fragments of application data units (ADUs) and the
order they need to be decoded.
Payload Type: 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. An example of this would be video decoder
configuration information. 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 necessary to change the payload format or
its configuration during the session.
SSRC: The Sender Source ID (SSRC) is normally not used by a payload
format other than to identify the RTP timestamp and sequence
number space a packet belongs to, allowing simultaneously
reception from multiple senders. However, some of the RTP
mechanisms for improving reslilance to packet loss uses multiple
SSRCs to separate original data and repair or redundant data.
Header extensions: Some payload formats may specify extensions to
the RTP packet header to carry metadata describing the actual
payload within the packet. One example is the transport of SMPTE
time-codes in the RTP header [RFC5484]. As [RFC5285] specifies,
header extensions must not contain information required in order
to decode the payload successfully.
The remaining fields do not commonly influence 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.
3.2.3. RTP Multiplexing
RTP has three multiplexing points that are used for different
purposes. A proper understanding of this is important to correctly
Westerlund Expires September 4, 2011 [Page 14]
Internet-Draft HOWTO: RTP Payload Formats March 2011
utilize them.
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
multiplexes audio and video in different RTP sessions. To achieve
this separation, transport-level functionalities are used, 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 multicast RTP sessions simply by joining the multicast
groups over which the desired layers are transported. This
separation also allows different Quality of Service (QoS) to be
applied to different media types.
The next multiplexing point is separation of different sources within
an RTP session. Here RTP uses the SSRC to identify individual
sources. An example of individual sources in an audio RTP session
would be different microphones, independently of whether they are
connected to the same host or different hosts. For each SSRC a
unique RTP sequence number and timestamp space is used.
The third multiplexing point is the RTP header 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 RFC 2198 [RFC2198].
3.2.4. RTP Synchronization
There are several types of synchronization and we will here describe
how RTP handles the different types:
Intra media: The synchronization within a media stream from a source
is accomplished using the RTP timestamp field. Each RTP packet
carries the RTP timestamp, which specifies the position in time of
the media payload contained in this packet relative to the content
of other RTP packets in the same RTP session. This is especially
useful in cases of discontinuous transmissions. Discontinuities
can be caused by network conditions; when extensive losses occur
the RTP timestamp tells the receiver how much later than
previously received media the present media should be played out.
Inter media: As applications commonly have a desire to use several
media types at the same time there exists a need to synchronize
also the different media from the same source. This puts two
requirements on RTP: the possibility to determine which media are
from the same source and if they should be synchronized with each
other; and the functionality to facilitate the synchronization
Westerlund Expires September 4, 2011 [Page 15]
Internet-Draft HOWTO: RTP Payload Formats March 2011
itself.
The first step in inter-media synchronization is to determine which
SSRCs in each session should be synchronized with each other. This
is accomplished by comparing the CNAME fields in the RTCP SDES
packets. SSRCs with the same CNAME in different RTP sessions should
be synchronized.
The actual RTCP mechanism for inter-media synchronization is based on
the idea that each media stream provides 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 expressed in
RTCP as a 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 NTP [RFC5905] .
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 use the same reference clock to derive
their relative RTP timestamp time scales.
Figure 1 illustrates 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
medium currently used in the sessions
TS1 --+---------------+------->
| |
P1 |
| |
NTP ---+-----+---------T------>
| |
P2 |
| |
TS2 ---------+---------+---X-->
Figure 1: RTCP Synchronization
Assume that medium 1 uses an RTP Timestamp clock rate of 16 kHz, and
medium 2 uses a clock rate of 90 kHz. Then 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 the implementation to
generate a common synchronization point for which all time values are
provided (TS1(T), TS2(T) and T). So when one wishes to calculate the
NTP time that the timestamp value present in packet X corresponds to
Westerlund Expires September 4, 2011 [Page 16]
Internet-Draft HOWTO: RTP Payload Formats March 2011
one can do that in the following way: NTP(X) = NTP(T) + (TS2(X) -
TS2(T))/90000.
3.3. Signalling Aspects
RTP payload formats are used in the context of application signalling
protocols such as SIP [RFC3261] using the Session Description
Protocol (SDP) [RFC4566] with Offer/Answer [RFC3264], RTSP [RFC2326]
or SAP [RFC2326]. These examples all use out-of-band signalling to
indicate which and how many media streams are desired to be used in
the session and how they are configured. To be able to declare or
negotiate the media format and RTP payload packetization, the payload
format must be given an identifier. In addition to the identifier
many payload formats have also the need to signal further
configuration information out-of-band for the RTP payloads prior to
the media transport session.
The above examples of session-establishing protocols all use SDP, but
other session description formats may be used. For example there was
discussion of a new XML-based session description format within IETF
(SDP-NG). In the event, the proposal did not get beyond the initial
protocol specification because of the enormous embedded base of SDP
implementations. However, to avoid locking the usage of RTP to SDP
based out-of-band signalling, the payload formats are identified
using a separate definition format for the identifier and associated
parameters. That format is the Media Type.
3.3.1. Media Types
Media types [RFC4288] are identifiers originally created for
identifying media formats included in email. In this usage they were
known as MIME types, where the expansion of the MIME acronym includes
the word "mail". The term "media type" was introduced to reflect a
broader usage, which includes HTTP [RFC2616], MSRP [RFC4975] 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 for media type names are provided in RFC 4288
[RFC4288]. The additional rules for media types for RTP payload
formats are provided in RFC 4855 [RFC4855].
Media types are allowed any number of parameters, which may be
required or optional for that media type. They are always specified
Westerlund Expires September 4, 2011 [Page 17]
Internet-Draft HOWTO: RTP Payload Formats March 2011
on the form "name=value". There exists no restrictions on how the
value is defined from media type's perspective, except that
parameters must have a value. However, the usage of media types in
SDP etc. has resulted in the following restrictions that need to be
followed to make media types usable for RTP identifying payload
formats:
1. Arbitrary binary content in the parameters is allowed but needs
to be encoded so that it can be placed within text based
protocols. Base64 [RFC4648] is recommended, but for shorter
content BASE16 (same reference) may be more appropriate as it is
simpler to interpret for humans. This needs to be explicitly
stated when defining a media type parameter with binary values.
2. The end of the value needs to be easily found when parsing a
message. Thus parameter values that are continuous and not
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 quote (") is recommended.
3. A common representation form for the media type and its
parameters is on a single line. In that case the media type is
followed by a semicolon-separated list of the parameter value
pairs, e.g.
audio/amr octet-align=0; mode-set=0,2,5,7; mode-change-period=2
3.3.2. Mapping to SDP
Since SDP [RFC4566] is so commonly used as an out-of-band signalling
protocol, a mapping of the media type into SDP exists. The details
on how to map the media type and its parameters into SDP are
described in RFC 4855 [RFC4855]. However this is not sufficient to
explain how certain parameters must be interpreted for example in the
context of Offer/Answer negotiation [RFC3264].
3.3.2.1. The Offer/Answer Model
The Offer/Answer (O/A) model allows SIP to negotiate which media
formats and payload formats are to be used in a session and how they
are to be configured. 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
has an impact on these rules, so that some cases may require separate
descriptions for media streams that are send-only, receive-only or
both sent and received as identified by the SDP attributes
a=sendonly, a=recvonly, and a=sendrecv. In addition the usage of
multicast adds further limitations as the same media stream is
Westerlund Expires September 4, 2011 [Page 18]
Internet-Draft HOWTO: RTP Payload Formats March 2011
delivered to all participants. If those multicast-imposed
restrictions are too limiting for unicast then separate rules for
unicast and multicast will be required.
The simplest and most common O/A interpretation is that a parameter
is defined to be declarative; i.e. the sending entity can declare a
value and that has no direct impact on the other agent's values.
This declared value applies to all media that are going to be sent to
the declaring entity. For example most video codecs have a 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's 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 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.
A "negotiated" parameter is a different case, for which both sides
need to agree on its value. Such a parameter requires that the
answerer either accept it as it is offered or remove the payload type
the parameter belonged to from its answer. The removal of the
payload type from the answer indicates to the offerer the lack of
support for the parameter values presented. An unfortunate
implication of the need to use complete payload types to indicate
each possible configuration so as to maximize the chances of
achieving interoperability, is that the number of necessary payload
types can quickly grow large. This is one reason to limit the total
number of sets of capabilities that may be implemented.
The most problematic type of parameters are those that relate to the
media the entity sends. They do not really fit the O/A model but can
be shoe-horned in. Examples of such parameters can be found in the
H.264 video codec's payload format [RFC3984], where the name of all
parameters with this property starts with "sprop-". The issue with
these parameters is that they declare properties for a media stream
that the other party may not accept. The best one can make of the
situation is to explain the assumption that the other party will
accept the same parameter value for the media it will receive as the
offerer of the session has proposed. If the answerer needs to change
any declarative parameter relating to streams it will receive then
the offerer may be required to make an new offer to update the
parameter values for its outgoing media stream.
Another issue to consider is the sendonly media streams in offers.
Parameters that relate to what the answering entity accepts to
Westerlund Expires September 4, 2011 [Page 19]
Internet-Draft HOWTO: RTP Payload Formats March 2011
receive have no meaning other than to provide a template for the
answer. It is worth pointing out in the specification that these
really provide a set of parameter values that the sender recommends.
Note that sendonly streams in answers will need to indicate the
offerer's parameters to ensure that the offerer can match the answer
to the offer.
A further issue with offer/answer which complicates things is that
the answerer 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 suite. This means that it must be
possible to bind answers for payload types to the payload types in
the offer even when the payload type number has been changed, and
some of the proposed payload types have been removed. This binding
must normally be done by matching the configurations originally
offered against those in the answer.
3.3.2.2. Declarative usage in RTSP and SAP
SAP (Session Announcement Protocol) [RFC2974] is used for announcing
multicast sessions. Independently of the usage of Source Specific
Multicast (SSM) [RFC3569] 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. This enables everyone to receive the session if they
support the configuration. Here SDP provides a one way channel with
no possibility to affect the configuration 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.
Real-Time Streaming Protocol (RTSP) [RFC2326] allows the negotiation
of transport parameters for media streams which are 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 use of the DESCRIBE method
or by means of an out-of-band channel like HTTP, email etc. The SDP
is used to determine which media streams and what formats are being
used prior to session establishment.
Thus both SAP and RTSP use SDP to configure receivers and senders
with a predetermined configuration for a media stream including the
payload format and any of its parameters. 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. Any such difference will need to be spelled out by the payload
Westerlund Expires September 4, 2011 [Page 20]
Internet-Draft HOWTO: RTP Payload Formats March 2011
format specification.
3.4. Transport Characteristics
The general channel characteristics that RTP flows experience are
documented in Section 3 of RFC2736 [RFC2736]. The discussion below
provides additional information.
3.4.1. Path MTU
At the time of writing this document the most common IP Maximum
Transmission Unit (MTU) in used link layers is 1500 bytes (Ethernet
data payload). However there exist both links with smaller MTUs and
links with much larger MTUs. Certain parts of the Internet already
today support an IP MTU of 9000 bytes or more. There is a 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.
Westerlund Expires September 4, 2011 [Page 21]
Internet-Draft HOWTO: RTP Payload Formats March 2011
4. Specification Process
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 defined
by standards bodies other than the IETF the primary milestone is
registration of the RTP payload format name. For proprietary media
formats the primary goal depends on whether interoperability is
desired at the RTP level. However there is also the issue of
ensuring best possible quality of any specification.
4.1. IETF
For all standardized media formats, it is recommended that the
payload format be specified in the IETF. The main reason is to
provide an openly available RTP payload format specification that has
been reviewed by people experienced with RTP payload formats. At the
time of writing, this work is done in the PAYLOAD Working Group (WG),
but that may change in the future.
4.1.1. Steps from Idea to Publication
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 PAYLOAD Working Group applies when
working with RTP payload formats.
Idea: Determined the need for an RTP payload format as an IETF
specification.
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
PAYLOAD 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 introductory parts that describe the real-time media
format and the basic idea on how to packetize it. Not all the
details are required to be filled in. However, the security
chapter is not something that one should skip even initially. It
is important to consider from the start any serious security risks
that need to be solved. The first step is completed when one has
a draft that is sufficiently 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 the packetization work.
Westerlund Expires September 4, 2011 [Page 22]
Internet-Draft HOWTO: RTP Payload Formats March 2011
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 PAYLOAD WG and request that
it be reviewed. In the email outline any issues the authors
currently have with the design.
Iterative improvements: Taking the feedback into account one
updates the draft and tries resolve issues. New revisions of the
draft can be submitted at any time (again excepting a buffer
period before meetings). It is recommended to submit a new
version whenever one has made major updates or has new issues that
are easiest to discuss in the context of a new draft version.
Becoming a WG document: Given that the definition of RTP payload
formats is part of the PAYLOAD WG's charter, RTP payload formats
that are going to be published as standards track RFCs need to
become WG documents. Becoming a WG document means that the chairs
are responsible for administrative handling, for example, issuing
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 editors, unless unusual circumstances
occur. The PAYLOAD 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 exists a good solution.
Iterative improvements: The updates and review cycles continue
until the draft has reached the level of maturity suitable for
publication.
WG Last Call: A WG Last Call of at least 2 weeks is always
performed for payload formats in the PAYLOAD WG. The authors
request WG last call for a draft when they think it is 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 need to be addressed with
an updated draft version. For any more substantial updates of the
draft, a new WG last call is announced for the updated version.
Minor changes, like editorial fixes, can be progressed without an
additional WG last call.
Westerlund Expires September 4, 2011 [Page 23]
Internet-Draft HOWTO: RTP Payload Formats March 2011
Publication Requested: For WG documents the chairs request
publication of the draft, after it has passed WG Last Call. After
this the approval and publication process described in RFC 2026
[RFC2026] are performed. The status after the publication has
been requested can be tracked using the IETF data tracker.
Documents do not expire as they normally do after publication has
been requested, so authors do not have to issue keep-alive
updates. 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
do one last review of the document immediately prior to its
publication as an RFC to ensure its correctness.
4.1.2. WG meetings
WG meetings are for discussing issues, not presentations. This means
that most RTP payload formats should never need to be discussed in a
WG meeting. RTP payload formats that would be discussed are either
those with controversial issues that failed to be resolved on the
mailing list, or those including new design concepts worth a general
discussion.
There exists no requirement to present or discuss a draft at a WG
meeting before it becomes published as an RFC. Thus even authors who
lack the possibility to go to WG meetings should be able to
successfully specify an RTP payload format in IETF. WG meetings may
become necessary only if the draft gets stuck in a serious debate
that cannot easily be resolved.
4.1.3. Draft Naming
To simplify the work of the PAYLOAD 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>-payload-rtp-<descriptive name>-<version>. The WG
documents shall be named according to this template:
draft-ietf-payload-rtp-<descriptive name>-<version>. The inclusion
of "payload" in the draft filename ensures that the search for
"payload-" will find all PAYLOAD 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 describing 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.
Westerlund Expires September 4, 2011 [Page 24]
Internet-Draft HOWTO: RTP Payload Formats March 2011
4.1.4. How to speed up the process
There a number of ways to lose a lot of time in the above process.
This section discusses what to do and what to avoid.
o Do not update the draft only for the meeting deadline. An update
to each meeting automatically limits the draft to three updates
per year. Instead, ignore the meeting schedule and publish new
versions as soon as possible.
o Try to avoid requesting reviews when people are busy, like the
weeks before a meeting. It is actually more likely that people
have time for them directly after a meeting.
o Perform draft updates quickly. A common mistake is that the
authors let the draft slip. By performing updates to the draft
text directly after getting resolution on an issue, things are
speeded up. This minimizes the delay that the author has direct
control over. The time taken for reviews, responses from area
directors and chairs, etc. can be much harder to speed up.
o Do not fail to take human nature into account. It happens that
people forget or need to be reminded about tasks. Send a kind
reminder to the people you are waiting for if things take longer
than expected. Ask people to estimate when they expect to fulfill
the requested task.
o Ensure there is 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 author that you
will review their draft if they review yours. Even inexperienced
reviewers can help with language, editorial or clarity issues.
Try also approaching the more experienced people in the WG and
getting 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, checking if a draft is ready
to become a WG document or ready for WG last call.
4.2. Other Standards bodies
Other standards bodies may define RTP payloads in their own
specifications. When they do this they are strongly recommended to
contact the PAYLOAD WG chairs and request review of the work. It is
recommended that at least two review steps are performed. The first
should be early in the process when more fundamental issues can be
Westerlund Expires September 4, 2011 [Page 25]
Internet-Draft HOWTO: RTP Payload Formats March 2011
easily resolved without abandoning a lot of effort. Then when
nearing completion, but while it is still possible to update the
specification, a second review should be scheduled. In that pass the
quality can be assessed and hopefully no updates will be needed.
Using this procedure can avoid both conflicting definitions and
serious mistakes, like breaking certain aspects of the RTP model.
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 (RFC 4855 [RFC4855]
and RFC 4288 [RFC4288]). This registration requires a request to the
IESG, which ensures that the filled-in registration template is
acceptable. To avoid last-minute problems with these registrations
the registration template must be sent for review both to the PAYLOAD
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.
Registration of the RTP payload name is something that is required to
avoid name collision in the future. 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 Web site
(http://www.iana.org).
4.3. Proprietary and Vendor Specific
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 are reasons why also proprietary
formats should be correctly documented and registered:
o Usage in a standardized signalling environment such as SIP/SDP.
RTP needs to be configured with the RTP profiles, payload formats
and their payload types being used. To accomplish this it is
desirable to have registered media type names to ensure that the
names do not collide with those of other formats.
o Sharing with business partners. As RTP payload formats are used
for communication, situations often arise where business partners
would like to support a proprietary format. Having a well written
specification of the format will save time and money for both
sides, as interoperability will be much easier to accomplish.
o To ensure interoperability between different implementations on
different platforms.
To avoid name collisions there is a central register keeping tracks
Westerlund Expires September 4, 2011 [Page 26]
Internet-Draft HOWTO: RTP Payload Formats March 2011
of the registered Media Type names used by different RTP payload
formats. When it comes to proprietary formats they should be
registered in the vendor's own tree. All vendor specific
registrations use sub-type names that start with "vnd.<vendor-name>".
Names in the vendor's own tree are not required to be registered with
IANA. However registration is recommended if the Media Type is used
at all in public environments.
If interoperability at the RTP level is desired, a payload type
specification should be standardized in the IETF following the
process described above. The IETF does not require full disclosure
of the codec when defining an RTP payload format to carry that codec,
but a description must be provided that is sufficient to allow the
IETF to judge whether the payload format is well designed. The Media
Type identifier assigned to a standardized payload format of this
sort will lie in the standards tree rather than the vendor tree.
Westerlund Expires September 4, 2011 [Page 27]
Internet-Draft HOWTO: RTP Payload Formats March 2011
5. Designing Payload Formats
The best summary of payload format design is KISS (Keep It Simple,
Stupid). A simple payload format is easier to review for
correctness, easier to implement, and has low complexity.
Unfortunately, contradictory requirements sometimes make it hard to
do things simply. Complexity issues and problems that occur for RTP
payload formats are:
Too many configurations: Contradictory requirements lead to the
result that one configuration is created for each conceivable
case. Such contradictory requirements are often between
functionality and bandwidth. This outcome has two big
disadvantages; First all configurations need to be implemented.
Second, the user 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 set of configurations (preferably one) that perform
well for the most common cases and are capable of handling the
other cases, but maybe not that well.
Hard to implement: Certain payload formats may become difficult to
implement both correctly and efficiently. This needs to be
considered in the design.
Interaction with general mechanisms: Special solutions may create
issues with deployed tools for RTP, such as tools for more robust
transport of RTP. For example, a requirement for a non-broken
sequence number space creates issues for mechanisms rellying on
payload type switching interleaving media-independent resilience
within a stream.
5.1. Features of RTP Payload Formats
There are a number of common features in RTP payload formats. There
is no general requirements to support these features; instead, their
applicability must be considered for each payload format. It may in
fact be that certain features are not even applicable.
5.1.1. Aggregation
Aggregation allows for the inclusion of multiple application data
units (ADUs) within the same RTP payload. This is commonly supported
for codecs that produce ADUs of sizes smaller than the IP MTU. Do
remember that the MTU may be significantly larger than 1500 bytes.
An MTU of 9000 bytes is available today and an MTU of 64k may be
available in the future. Many speech codecs have the property of
Westerlund Expires September 4, 2011 [Page 28]
Internet-Draft HOWTO: RTP Payload Formats March 2011
ADUs of a few fixed sizes. Video encoders may generally produce ADUs
of quite flexible sizes. Thus the need for aggregation may be less.
However in certain use cases the possibility to aggregate multiple
ADUs especially for different playback times is useful.
The main disadvantage of aggregation is the extra delay introduced
(due to buffering until a sufficient number of ADUs have been
collected at the sender) and reduced robustness against packet loss.
Aggregation also introduces buffering requirements at the receiver.
5.1.2. Fragmentation
If the real-time media format has the property that it may produce
ADUs that are larger than common MTU 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 has some
drawbacks. The usage of RTP payload format-level fragmentation
allows for more efficient usage of RTP packet loss recovery
mechanisms. However it may in some cases also allow earlier usage of
partial ADUs by doing media specific fragmentation at media specific
boundaries.
5.1.3. Interleaving and Transmission Re-Scheduling
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 packet
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.
A requirement for doing interleaving within an RTP payload format is
the aggregation of multiple ADUs. For formats that do not use
aggregation there is still a possibility of implementing a
transmission order re-scheduling mechanism. That has the effect that
the packets transmitted consecutively originate from different points
in the media stream. This can be used to mitigate burst losses,
which may be useful if one transmits packets at frequent 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 possibility to receive the most important
data, e.g. intra frames of video.
Westerlund Expires September 4, 2011 [Page 29]
Internet-Draft HOWTO: RTP Payload Formats March 2011
The drawback of interleaving is the significantly increased
transmission buffering delay, making it less useful for low-delay
applications. It may also create significant buffering requirements
on the receiver. That buffering is also 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. Transmission re-scheduling is only useful in a few specific
cases, as in streaming with retransmissions. The potential gains
must be weighted against the complexity of these schemes.
5.1.4. Media Back Channels
A few RTP payload formats have implemented back channels within the
media format. Those have been for specific features, like the AMR
[RFC4867] codec mode request (CMR) field. The CMR field is used in
the operation of gateways to circuit-switched voice to allow an IP
terminal to react to the circuit-switched network's need for a
specific encoder mode. A common motivation for media back channels
is the need to have signalling in direct relation to the media or the
media path.
If back channels are considered for an RTP payload format they should
be for a specific requirements which cannot be easily satisfied by
more generic mechanisms within RTP or RTCP.
5.1.5. Scalability
Some codecs support some type of scalability, i.e. where additional
data can be used to improve media stream properties, but the
additional data are not essential for decoding. The quality
improvements have so far been of a number of different types:
Temporal: For video codecs increased frame rate is one way to
improve the quality.
Spatial: Video codecs with scalability may increase the resolution
or image size. Audio codecs could provide increased sampling
rate.
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 ratios and
reducing the distortions within the content.
At the time of writing this document , codecs that support
scalability are having a bit of revival. It has been realized that
getting the needed functionality for the media stream into the RTP
framework is quite challenging. The author hopes to be able to
Westerlund Expires September 4, 2011 [Page 30]
Internet-Draft HOWTO: RTP Payload Formats March 2011
provide some lessons from this work in this document in the future.
5.1.6. High Packet Rates
Some media codecs require high packet rates, and in these cases the
RTP sequence number wraps too quickly. As rule of thumb, it must not
be possible to wrap the sequence number space in less than 2 minutes
(TCP maximum segment lifetime). If earlier wrapping may occur then
the payload format should specify an extended sequence number field
to allow the receiver to determine where a specific payload belongs
in the sequence, even in the face of extensive reordering. The RTP
payload format for uncompressed video [RFC4175] can be used as an
example for such a field.
Westerlund Expires September 4, 2011 [Page 31]
Internet-Draft HOWTO: RTP Payload Formats March 2011
6. Current Trends in Payload Format Design
This section provides a few examples of payload formats that are
worth noting for good design in general or specific details of their
design.
6.1. Audio Payloads
The AMR [RFC4867], AMR-WB [RFC4867], EVRC [RFC3558], SMV [RFC3558]
payload formats 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 indicates the type of the frame and if
additional frames are present. This is quite flexible but produces
unnecessary overhead if the ADU is of fixed size and if when
aggregating multiple ADUs they are commonly of the same type. In
that case a solution like that in AMR-WB+ [RFC4352] may be more
suitable.
AMR-WB+ does contain one less desirable feature which is dependent 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 have the very unusual value of 72 kHz despite the fact
that output normally is at a sample rate of 48kHz. The 72 kHz
timestamp rate is the smallest found value that would make all of the
frames the codec could produce result in an integer frame length in
RTP timestamp ticks. This way, a receiver can always correctly place
the frames in relation to any other frame, even when the frame length
changes. The downside is that the decoder outputs for certain frame
lengths is in fact partial samples. The result is that the output in
samples from the codec will vary from frame to frame, potentially
making implementation more difficult.
The RTP payload format for MIDI [RFC4695] contains some interesting
features. MIDI is an audio format sensitive to packet losses, as the
loss of a "note off" command will result in a note being 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 appear limited in applicability to
media formats that are highly stateful and primarily use symbolic
media representations.
6.2. Video
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.
Westerlund Expires September 4, 2011 [Page 32]
Internet-Draft HOWTO: RTP Payload Formats March 2011
The H.264 RTP payload format [RFC3984] can be seen as a smorgasbord
of functionality, some of it such as the interleaving being pretty
advanced. 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 are indeed supported. This has created a payload format that
rarely is fully implemented. Despite that, no major issues with
interoperability has been reported. However, complaints about its
complexity are common.
The RTP payload format for uncompressed video [RFC4175] must 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 includes a field to extend the RTP
sequence number since the normal 16-bit one can wrap in less than a
second. [RFC4175] also specifies a registry of different color sub-
samplings that can be re-used in other video RTP payload formats.
6.3. Text
It would be overstating things to say that there exists a trend in
text payload formats as only a single format text format has been
standardized in IETF, namely T.140 [RFC4103]. The 3GPP Timed Text
format [RFC4396] could be considered to be text, even though in the
end was registered as a video format. It was registered in that part
of the tree because it deals with decorated text, usable for
subtitles and other embellishments of video. However, it has many of
the properties that text formats generally have.
The RTP payload format for T.140 was designed with high reliability
in mind as real-time text commonly is an extremely low bit-rate
application. Thus, it recommends the use of RFC 2198 with many
generations of redundancy. However, the format failed to provide a
text block specific sequence number and relies instead of the RTP one
to detect loss. This makes detection of missing text blocks
unnecessarily difficult and hinders deployment with other robustness
mechanisms that would involve switching the payload type as that may
result in erroneous error marking in the T.140 text stream.
Westerlund Expires September 4, 2011 [Page 33]
Internet-Draft HOWTO: RTP Payload Formats March 2011
7. Important Specification Sections
A number of sections in the payload format draft that need some
special consideration. These include the Security and IANA
Considerations sections.
7.1. Media Format Description
The intention of this section is to enable reviewers and other
readers 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.
7.2. Security Considerations
All Internet drafts require a Security Considerations section. The
security considerations section in an RTP payload format needs to
concentrate on the security properties this particular format has.
Some payload formats have very few specific issues or properties and
can fully fall back on the security considerations for RTP in general
and those of the profile being used. Because those documents are
always applicable, a reference to these is normally placed first in
the security considerations section. There is suggested text in the
template below.
The security issues of confidentiality, integrity protection and
source authentication are common issue for all payload formats.
These should be solved by mechanisms external to the payload and do
not need any special consideration in the payload format except for
an reminder on these issues. Suitable stock text to inform people
about this is included in the template.
Potential security issues with an RTP payload format and the media
encoding that needs to be considered are:
1. 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
an infinite size for a very limited input, thus consuming memory
or storage space out of proportion with what the receiving
application expected. Such inputs can cause some sort of
disruption, i.e. a denial of service attack on the receiver side
by preventing that host from producing any goodput. Certain
decoding operations may also vary in the amount of processing
needed to perform those operations depending on the input. This
may also be a security risk if it is possible to raise processing
load significantly above nominal simply by designing a malicious
Westerlund Expires September 4, 2011 [Page 34]
Internet-Draft HOWTO: RTP Payload Formats March 2011
input sequence. If such potential attacks exist, this must be
made clear in the security considerations section to make
implementers aware of the need to take precautions against such
behavior.
2. The inclusion of active content in the media format or its
transport. "Active content" means scripts etc. that allow an
attacker to perform potentially arbitrary operations on the
receiver. Most active contents has limited possibility to access
the system or perform operations outside a protected sandbox.
RFC 4855 [RFC4855] has a requirement that it be noted in the
media types registration if the payload format contains active
content or not. If the payload format has active content it is
strongly recommended that references to any security model
applicable for such content are provided. A boilerplate text for
"no active content" is included in the template. This must be
changed if the format actually carries active content.
3. Some media formats allow for the carrying of "user data", or
types of data which are not known at the time of the
specification of the payload format. Such data may be a security
risk and should be mentioned.
Suitable stock text for the security considerations section is
provided in the template in the appendix. However, authors do need
to actively consider any security issues from the start. Failure to
address these issues may block approval and publication.
7.3. Congestion Control
RTP and its profiles do discuss congestion control. Congestion
control is an important issue in any usage in non-dedicated networks.
For that reason it is recommended that all RTP payload format
documents 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 factors should be discussed.
7.4. IANA Considerations
Since all RTP Payload formats contain a Media Type specification,
they also need an IANA Considerations 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 media types" list part of the RTP registry
(http://www.iana.org/assignments/rtp-parameters).
Westerlund Expires September 4, 2011 [Page 35]
Internet-Draft HOWTO: RTP Payload Formats March 2011
In addition to the above request for media type registration, some
payload formats may have parameters where in the future new parameter
values need to be added. In these cases a registry for that
parameter must be created. This is done by defining the registry in
the IANA Considerations section. BCP 26 (RFC 5226) [RFC5226]
provides guidelines to specifying such registries. Care should be
taken when defining the policy for new registrations.
Before specifying a new registry it is worth checking the existing
ones in the IANA "MIME Media Type Sub-Parameter Registries" list.
For example video formats needing a media parameter expressing color
sub-sampling may be able to reuse those defined for video/raw
[RFC4175].
Westerlund Expires September 4, 2011 [Page 36]
Internet-Draft HOWTO: RTP Payload Formats March 2011
8. Authoring Tools
This section provides information on and and recommends some tools
that may be used. Don't feel pressured to follow these
recommendations. There exist a number of alternatives. But these
suggestions are worth checking out before deciding that the field is
greener somewhere else.
8.1. Editing Tools
There are many choices when it comes to tools to choose for authoring
Internet drafts. However in the end they need to be able to produce
a draft that conforms to the Internet Draft requirements. If you
don't have any previous experience with authoring Internet drafts
XML2RFC does have some advantages. It helps by create a lot of the
necessary boiler plate in accordance with the latest rules, thus
reducing the effort. It also speeds up publication after approval as
the RFC-editor can use the source XML document to produce the RFC
more quickly.
Another common choice is to use Microsoft Word and a suitable
template, see [RFC5385] to produce the draft and print that to file
using the generic text printer. It has some advantages when it comes
to spell checking and change bars. However Word may also produce
some problems, like changing formatting, and inconsistent results
between what one sees in the editor and in the generated text
document, at least according to the authors' personal experience.
8.2. Verification Tools
There are a few tools that are very good to know about when writing a
draft. These help check and verify parts of one's work. These tools
can be found at http://tools.ietf.org.
o ID Nits checker. It checks that the boiler plate and some other
things that are easily verifiable by machine are okay in your
draft. Always use it before submitting a draft to avoid direct
refusal in the submission step.
o ABNF Parser and verification. Checks 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.
o RFC diff. A diff tool that is optimized for drafts and RFCs. For
example it does not point out that the footer and header have
moved in relation to the text on every page.
Westerlund Expires September 4, 2011 [Page 37]
Internet-Draft HOWTO: RTP Payload Formats March 2011
9. Open Issues
This document currently has a few open issues that needs resolving
before publication:
o Should any procedure for the future when the Payload WG is closed
be described?
o The section of current examples of good work needs to be filled
in.
o Consider mention RFC-errata
o Section on Scalability needs to be expanded.
Westerlund Expires September 4, 2011 [Page 38]
Internet-Draft HOWTO: RTP Payload Formats March 2011
10. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
Westerlund Expires September 4, 2011 [Page 39]
Internet-Draft HOWTO: RTP Payload Formats March 2011
11. Security Considerations
As this is an informational document about writing drafts that are
intended to become RFCs there are no direct security considerations.
However the document does discuss the writing of security
considerations sections and what should be particularly considered
when specifying RTP payload formats.
Westerlund Expires September 4, 2011 [Page 40]
Internet-Draft HOWTO: RTP Payload Formats March 2011
12. RFC Editor Considerations
Note to RFC Editor: This section may be removed after carrying out
all the instructions of this section.
Westerlund Expires September 4, 2011 [Page 41]
Internet-Draft HOWTO: RTP Payload Formats March 2011
13. Contributiors
The author would like to thank Tom Taylor for the editing pass of the
whole document and contributing text regarding proprietary RTP
payload formats.
Westerlund Expires September 4, 2011 [Page 42]
Internet-Draft HOWTO: RTP Payload Formats March 2011
14. Acknowledgements
The author would like to thank the individuals who have provided
input to this document. These individuals include John Lazzaro, Ali
C. Begen and Tom Taylor.
Westerlund Expires September 4, 2011 [Page 43]
Internet-Draft HOWTO: RTP Payload Formats March 2011
15. Informative References
[CSP-RTP] Perkins, C., "RTP: Audio and Video for the Internet",
June 2003.
[I-D.ietf-avt-srtp-not-mandatory]
Perkins, C. and M. Westerlund, "Why RTP Does Not Mandate a
Single Security Mechanism",
draft-ietf-avt-srtp-not-mandatory-07 (work in progress),
July 2010.
[MACOSFILETYPES]
Apple Knowledge Base Article
55381<http://www.info.apple.com/kbnum/n55381>, "Mac OS:
File Type and Creator Codes, and File Formats", 1993.
[RFC-ED] http://www.rfc-editor.org/policy.html, "RFC Editorial
Guidelines and Procedures", July 2008.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
Parisis, "RTP Payload for Redundant Audio Data", RFC 2198,
September 1997.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2360] Scott, G., "Guide for Internet Standards Writers", BCP 22,
RFC 2360, June 1998.
[RFC2418] Bradner, S., "IETF Working Group Guidelines and
Procedures", BCP 25, RFC 2418, September 1998.
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
Headers for Low-Speed Serial Links", RFC 2508,
February 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP
Payload Format Specifications", BCP 36, RFC 2736,
December 1999.
Westerlund Expires September 4, 2011 [Page 44]
Internet-Draft HOWTO: RTP Payload Formats March 2011
[RFC2959] Baugher, M., Strahm, B., and I. Suconick, "Real-Time
Transport Protocol Management Information Base", RFC 2959,
October 2000.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000.
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le,
K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
Compression (ROHC): Framework and four profiles: RTP, UDP,
ESP, and uncompressed", RFC 3095, July 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
[RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and
P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with
High Delay, Packet Loss and Reordering", RFC 3545,
July 2003.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003.
[RFC3558] Li, A., "RTP Payload Format for Enhanced Variable Rate
Codecs (EVRC) and Selectable Mode Vocoders (SMV)",
RFC 3558, July 2003.
[RFC3569] Bhattacharyya, S., "An Overview of Source-Specific
Multicast (SSM)", RFC 3569, July 2003.
[RFC3577] Waldbusser, S., Cole, R., Kalbfleisch, C., and D.
Westerlund Expires September 4, 2011 [Page 45]
Internet-Draft HOWTO: RTP Payload Formats March 2011
Romascanu, "Introduction to the Remote Monitoring (RMON)
Family of MIB Modules", RFC 3577, August 2003.
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control
Protocol Extended Reports (RTCP XR)", RFC 3611,
November 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
G. Fairhurst, "The Lightweight User Datagram Protocol
(UDP-Lite)", RFC 3828, July 2004.
[RFC3979] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3979, March 2005.
[RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund,
M., and D. Singer, "RTP Payload Format for H.264 Video",
RFC 3984, February 2005.
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text
Conversation", RFC 4103, June 2005.
[RFC4170] Thompson, B., Koren, T., and D. Wing, "Tunneling
Multiplexed Compressed RTP (TCRTP)", BCP 110, RFC 4170,
November 2005.
[RFC4175] Gharai, L. and C. Perkins, "RTP Payload Format for
Uncompressed Video", RFC 4175, September 2005.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
[RFC4352] Sjoberg, J., Westerlund, M., Lakaniemi, A., and S. Wenger,
"RTP Payload Format for the Extended Adaptive Multi-Rate
Wideband (AMR-WB+) Audio Codec", RFC 4352, January 2006.
[RFC4396] Rey, J. and Y. Matsui, "RTP Payload Format for 3rd
Generation Partnership Project (3GPP) Timed Text",
RFC 4396, February 2006.
Westerlund Expires September 4, 2011 [Page 46]
Internet-Draft HOWTO: RTP Payload Formats March 2011
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP)
and RTP Control Protocol (RTCP) Packets over Connection-
Oriented Transport", RFC 4571, July 2006.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
July 2006.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[RFC4677] Hoffman, P. and S. Harris, "The Tao of IETF - A Novice's
Guide to the Internet Engineering Task Force", RFC 4677,
September 2006.
[RFC4695] Lazzaro, J. and J. Wawrzynek, "RTP Payload Format for
MIDI", RFC 4695, November 2006.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, February 2007.
[RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie,
"RTP Payload Format and File Storage Format for the
Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband
(AMR-WB) Audio Codecs", RFC 4867, April 2007.
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC5109] Li, A., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, December 2007.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, February 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
Westerlund Expires September 4, 2011 [Page 47]
Internet-Draft HOWTO: RTP Payload Formats March 2011
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, July 2008.
[RFC5378] Bradner, S. and J. Contreras, "Rights Contributors Provide
to the IETF Trust", BCP 78, RFC 5378, November 2008.
[RFC5385] Touch, J., "Version 2.0 Microsoft Word Template for
Creating Internet Drafts and RFCs", RFC 5385,
February 2010.
[RFC5484] Singer, D., "Associating Time-Codes with RTP Streams",
RFC 5484, March 2009.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, May 2010.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust
Header Compression (ROHC) Framework", RFC 5795,
March 2010.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010.
Westerlund Expires September 4, 2011 [Page 48]
Internet-Draft HOWTO: RTP Payload Formats March 2011
Appendix A. RTP Payload Format Template
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.
A.1. Title
[The title shall be descriptive but as compact as possible. RTP is
allowed and recommended abbreviation in the title]
RTP Payload format for ...
A.2. Front page boilerplate
Status of this Memo
[Insert the IPR notice and copyright boiler plate from BCP 78 and 79
that applies to this draft.]
[Insert the current Internet Draft document explanation. At the time
of publishing it was:]
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
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."
A.3. Abstract
[A 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.]
A.4. Table of Content
[All drafts over 15 pages in length must have an Table of Content.]
Westerlund Expires September 4, 2011 [Page 49]
Internet-Draft HOWTO: RTP Payload Formats March 2011
A.5. Introduction
[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.]
A.6. Conventions, Definitions and Acronyms
[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.]
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.
RFC-editor note: RFCXXXX is to be replaced by the RFC number this
specification recieves when published.
A.7. Media Format Description
[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.]
A.8. Payload format
[Overview of payload structure]
A.8.1. RTP Header Usage
[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]
The remaining RTP header fields are used as specified in RFC 3550.
A.8.2. Payload Header
[Define how the payload header, if it exist, is structured and used.]
A.8.3. Payload Data
[The payload data, i.e. what the media codec has produced. Commonly
done through reference to media codec specification which defines how
Westerlund Expires September 4, 2011 [Page 50]
Internet-Draft HOWTO: RTP Payload Formats March 2011
the data is structured. Rules for padding may need to be defined to
bring data to octet alignment.]
A.9. Payload Examples
[One or more examples are good to help ease the understanding of the
RTP payload format.]
A.10. Congestion Control Considerations
[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.]
Congestion control for RTP SHALL be used in accordance with RFC 3550
[RFC3550], and with any applicable RTP profile; e.g., RFC 3551
[RFC3551]. 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.
A.11. Payload Format Parameters
This RTP payload format is identified using the ... media type which
is registered in accordance with RFC 4855 [RFC4855] and using the
template of RFC 4288 [RFC4288].
A.11.1. Media Type Definition
[Here the media type registration template from RFC 4288 is placed
and filled out. This template is provided with some common RTP
boilerplate.]
Type name:
Subtype name:
Required parameters:
Optional parameters:
Encoding considerations:
This media type is framed and binary, see section 4.8 in RFC4288
[RFC4288].
Security considerations:
Westerlund Expires September 4, 2011 [Page 51]
Internet-Draft HOWTO: RTP Payload Formats March 2011
Please see security consideration in RFCXXXX
Interoperability considerations:
Published specification:
Applications that use this media type:
Additional information:
Magic number(s):
File extension(s):
Macintosh file type code(s):
Person & email address to contact for further information:
Intended usage: (One of COMMON, LIMITED USE or OBSOLETE.)
Restrictions on usage:
[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 RFC 4855 [RFC4855].]
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.
Author:
Change controller:
IETF Audio/Video Transport working group delegated from the IESG.
(Any other information that the author deems interesting may be added
below this line.)
[From RFC 4288: Some discussion of Macintosh file type codes and
their purpose can be found in [MACOSFILETYPES]. 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.]
Westerlund Expires September 4, 2011 [Page 52]
Internet-Draft HOWTO: RTP Payload Formats March 2011
A.11.2. Mapping to SDP
The mapping of the above defined payload format media type and its
parameters SHALL be done according to Section 3 of RFC 4855
[RFC4855].
[More specific rules only need to be included if some parameter does
not match these rules.]
A.11.2.1. Offer/Answer Considerations
[Here write your offer/answer consideration section, please see
Section Section 3.3.2.1 for help.]
A.11.2.2. Declarative SDP Considerations
[Here write your considerations for declarative SDP, please see
Section Section 3.3.2.2 for help.]
A.12. IANA Considerations
This memo requests that IANA registers [insert media type name here]
as specified in Appendix A.11.1. 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).
[See Section Section 7.4 and consider if any of the parameter needs a
registered name space.]
A.13. Securtiy Considerations
[See Section Section 7.2]
RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the RTP
specification [RFC3550] , 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.
Note that the appropriate mechanism to provide security to RTP and
Westerlund Expires September 4, 2011 [Page 53]
Internet-Draft HOWTO: RTP Payload Formats March 2011
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 SRTP [RFC3711] is recommended. Other mechanism that may
be used are IPsec [RFC4301] and TLS [RFC5246] (RTP over TCP), but
also other alternatives may exist.
This RTP payload format and its media decoder do not exhibit any
significant non-uniformity in the receiver-side computational
complexity for packet processing, and thus are unlikely to pose a
denial-of-service threat due to the receipt of pathological data.
Nor does the RTP payload format contain any active content.
[The previous paragraph may need editing due to the format breaking
either of the statements. Fill in here any further potential
security threats]
A.14. References
[References must be classified as either normative or informative and
added to the relevant section. References should use descriptive
reference tags.]
A.14.1. Normative References
[Normative references are those that are required to be used to
correctly implement the payload format.]
A.14.2. Informative References
[All other references.]
A.15. Author Addresses
[All Authors need to include their Name and email addresses as a
minimal. Commonly also surface mail and possibly phone numbers are
included.]
Westerlund Expires September 4, 2011 [Page 54]
Internet-Draft HOWTO: RTP Payload Formats March 2011
Author's Address
Magnus Westerlund
Ericsson
Farogatan 6
SE-164 80 Kista
Sweden
Phone: +46 10 714 82 87
Email: magnus.westerlund@ericsson.com
Westerlund Expires September 4, 2011 [Page 55]
