draft-ietf-avt-rtp-howto-02.txt   draft-ietf-avt-rtp-howto-03.txt 
Audio Video Transport Working M. Westerlund Audio Video Transport Working M. Westerlund
Group Ericsson Group Ericsson
Intended status: Informational Intended status: Informational
Expires: January 10, 2008 Expires: August 28, 2008
How to Write an RTP Payload Format How to Write an RTP Payload Format
draft-ietf-avt-rtp-howto-02.txt draft-ietf-avt-rtp-howto-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 10, 2008. This Internet-Draft will expire on August 28, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document contains information on how to best write an RTP This document contains information on how to best write an RTP
payload format. Reading tips, design practices, and practical tips payload format. Reading tips, design practices, and practical tips
on how to quickly and with good results produce an RTP payload format on how to quickly and with good results produce an RTP payload format
specification. A template is also included with instructions that specification. A template is also included with instructions that
can be used when writing an RTP payload format. can be used when writing an RTP payload format.
Table of Contents Table of Contents
skipping to change at page 2, line 30 skipping to change at page 2, line 30
2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Preparations . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Preparations . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Recommend Reading . . . . . . . . . . . . . . . . . . . . 8 3.1. Recommend Reading . . . . . . . . . . . . . . . . . . . . 8
3.1.1. IETF Process and Publication . . . . . . . . . . . . . 8 3.1.1. IETF Process and Publication . . . . . . . . . . . . . 8
3.1.2. RTP . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.2. RTP . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Important RTP details . . . . . . . . . . . . . . . . . . 13 3.2. Important RTP details . . . . . . . . . . . . . . . . . . 13
3.2.1. The RTP Session . . . . . . . . . . . . . . . . . . . 13 3.2.1. The RTP Session . . . . . . . . . . . . . . . . . . . 13
3.2.2. RTP Header . . . . . . . . . . . . . . . . . . . . . . 14 3.2.2. RTP Header . . . . . . . . . . . . . . . . . . . . . . 14
3.2.3. RTP Multiplexing . . . . . . . . . . . . . . . . . . . 15 3.2.3. RTP Multiplexing . . . . . . . . . . . . . . . . . . . 15
3.2.4. RTP Synchronization . . . . . . . . . . . . . . . . . 15 3.2.4. RTP Synchronization . . . . . . . . . . . . . . . . . 16
3.3. Signalling Aspects . . . . . . . . . . . . . . . . . . . . 17 3.3. Signalling Aspects . . . . . . . . . . . . . . . . . . . . 17
3.3.1. Media Types . . . . . . . . . . . . . . . . . . . . . 17 3.3.1. Media Types . . . . . . . . . . . . . . . . . . . . . 17
3.3.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . 18 3.3.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . 18
3.4. Transport Characteristics . . . . . . . . . . . . . . . . 21 3.4. Transport Characteristics . . . . . . . . . . . . . . . . 21
3.4.1. Path MTU . . . . . . . . . . . . . . . . . . . . . . . 21 3.4.1. Path MTU . . . . . . . . . . . . . . . . . . . . . . . 21
4. Specification Process . . . . . . . . . . . . . . . . . . . . 22 4. Specification Process . . . . . . . . . . . . . . . . . . . . 22
4.1. IETF . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.1. IETF . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.1. Steps from Idea to Publication . . . . . . . . . . . . 22 4.1.1. Steps from Idea to Publication . . . . . . . . . . . . 22
4.1.2. WG meetings . . . . . . . . . . . . . . . . . . . . . 24 4.1.2. WG meetings . . . . . . . . . . . . . . . . . . . . . 24
skipping to change at page 3, line 4 skipping to change at page 3, line 4
4.1.4. How to speed up the process . . . . . . . . . . . . . 24 4.1.4. How to speed up the process . . . . . . . . . . . . . 24
4.2. Other Standards bodies . . . . . . . . . . . . . . . . . . 25 4.2. Other Standards bodies . . . . . . . . . . . . . . . . . . 25
4.3. Propreitary and Vendor Specific . . . . . . . . . . . . . 26 4.3. Propreitary and Vendor Specific . . . . . . . . . . . . . 26
5. Designing Payload Formats . . . . . . . . . . . . . . . . . . 27 5. Designing Payload Formats . . . . . . . . . . . . . . . . . . 27
5.1. Features of RTP payload formats . . . . . . . . . . . . . 27 5.1. Features of RTP payload formats . . . . . . . . . . . . . 27
5.1.1. Aggregation . . . . . . . . . . . . . . . . . . . . . 27 5.1.1. Aggregation . . . . . . . . . . . . . . . . . . . . . 27
5.1.2. Fragmentation . . . . . . . . . . . . . . . . . . . . 28 5.1.2. Fragmentation . . . . . . . . . . . . . . . . . . . . 28
5.1.3. Interleaving and Transmission Re-Scheduling . . . . . 28 5.1.3. Interleaving and Transmission Re-Scheduling . . . . . 28
5.1.4. Media Back Channels . . . . . . . . . . . . . . . . . 29 5.1.4. Media Back Channels . . . . . . . . . . . . . . . . . 29
6. Current Trends in Payload Format Design . . . . . . . . . . . 30 5.1.5. Scalability . . . . . . . . . . . . . . . . . . . . . 29
6.1. Audio Payloads . . . . . . . . . . . . . . . . . . . . . . 30 5.1.6. High Packet Rates . . . . . . . . . . . . . . . . . . 30
6.2. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.3. Text . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7. Important Specification Sections . . . . . . . . . . . . . . . 31 6. Current Trends in Payload Format Design . . . . . . . . . . . 31
7.1. Security Consideration . . . . . . . . . . . . . . . . . . 31 6.1. Audio Payloads . . . . . . . . . . . . . . . . . . . . . . 31
7.2. Congestion Control . . . . . . . . . . . . . . . . . . . . 32 6.2. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.3. IANA Consideration . . . . . . . . . . . . . . . . . . . . 32 6.3. Text . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
8. Authoring Tools . . . . . . . . . . . . . . . . . . . . . . . 33 7. Important Specification Sections . . . . . . . . . . . . . . . 33
8.1. Editing Tools . . . . . . . . . . . . . . . . . . . . . . 33 7.1. Security Consideration . . . . . . . . . . . . . . . . . . 33
8.2. Verification Tools . . . . . . . . . . . . . . . . . . . . 33 7.2. Congestion Control . . . . . . . . . . . . . . . . . . . . 34
7.3. IANA Consideration . . . . . . . . . . . . . . . . . . . . 34
9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 34 8. Authoring Tools . . . . . . . . . . . . . . . . . . . . . . . 35
8.1. Editing Tools . . . . . . . . . . . . . . . . . . . . . . 35
8.2. Verification Tools . . . . . . . . . . . . . . . . . . . . 35
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 36
11. Security Considerations . . . . . . . . . . . . . . . . . . . 36 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
12. RFC Editor Consideration . . . . . . . . . . . . . . . . . . . 37 11. Security Considerations . . . . . . . . . . . . . . . . . . . 38
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38 12. RFC Editor Consideration . . . . . . . . . . . . . . . . . . . 39
14. Informative References . . . . . . . . . . . . . . . . . . . . 39 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40
Appendix A. RTP Payload Format Template . . . . . . . . . . . . . 44 14. Informative References . . . . . . . . . . . . . . . . . . . . 41
A.1. Title . . . . . . . . . . . . . . . . . . . . . . . . . . 44
A.2. Front page boilerplate . . . . . . . . . . . . . . . . . . 44
A.3. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . 45
A.4. Table of Content . . . . . . . . . . . . . . . . . . . . . 45
A.5. Introduction . . . . . . . . . . . . . . . . . . . . . . . 45
A.6. Conventions, Definitions and Acronyms . . . . . . . . . . 45
A.7. Media Format Background . . . . . . . . . . . . . . . . . 45
A.8. Payload format . . . . . . . . . . . . . . . . . . . . . . 45
A.8.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . 46
A.8.2. Payload Header . . . . . . . . . . . . . . . . . . . . 46
A.8.3. Payload Data . . . . . . . . . . . . . . . . . . . . . 46
A.9. Payload Examples . . . . . . . . . . . . . . . . . . . . . 46
A.10. Congestion Control Considerations . . . . . . . . . . . . 46
A.11. Payload Format Parameters . . . . . . . . . . . . . . . . 46
A.11.1. Media Type Definition . . . . . . . . . . . . . . . . 46
A.11.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . 48
A.12. IANA Considerations . . . . . . . . . . . . . . . . . . . 48
A.13. Securtiy Considerations . . . . . . . . . . . . . . . . . 48
A.14. References . . . . . . . . . . . . . . . . . . . . . . . . 49
A.14.1. Normative References . . . . . . . . . . . . . . . . . 49
A.14.2. Informative References . . . . . . . . . . . . . . . . 49
A.15. Author Addresses . . . . . . . . . . . . . . . . . . . . . 49
A.16. IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . 49
A.17. Copyright Notice . . . . . . . . . . . . . . . . . . . . . 50
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 51 Appendix A. RTP Payload Format Template . . . . . . . . . . . . . 46
Intellectual Property and Copyright Statements . . . . . . . . . . 52 A.1. Title . . . . . . . . . . . . . . . . . . . . . . . . . . 46
A.2. Front page boilerplate . . . . . . . . . . . . . . . . . . 46
A.3. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . 47
A.4. Table of Content . . . . . . . . . . . . . . . . . . . . . 47
A.5. Introduction . . . . . . . . . . . . . . . . . . . . . . . 47
A.6. Conventions, Definitions and Acronyms . . . . . . . . . . 47
A.7. Media Format Background . . . . . . . . . . . . . . . . . 47
A.8. Payload format . . . . . . . . . . . . . . . . . . . . . . 47
A.8.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . 48
A.8.2. Payload Header . . . . . . . . . . . . . . . . . . . . 48
A.8.3. Payload Data . . . . . . . . . . . . . . . . . . . . . 48
A.9. Payload Examples . . . . . . . . . . . . . . . . . . . . . 48
A.10. Congestion Control Considerations . . . . . . . . . . . . 48
A.11. Payload Format Parameters . . . . . . . . . . . . . . . . 48
A.11.1. Media Type Definition . . . . . . . . . . . . . . . . 48
A.11.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . 50
A.12. IANA Considerations . . . . . . . . . . . . . . . . . . . 50
A.13. Securtiy Considerations . . . . . . . . . . . . . . . . . 50
A.14. References . . . . . . . . . . . . . . . . . . . . . . . . 51
A.14.1. Normative References . . . . . . . . . . . . . . . . . 51
A.14.2. Informative References . . . . . . . . . . . . . . . . 51
A.15. Author Addresses . . . . . . . . . . . . . . . . . . . . . 51
A.16. IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . 51
A.17. Copyright Notice . . . . . . . . . . . . . . . . . . . . . 52
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 53
Intellectual Property and Copyright Statements . . . . . . . . . . 54
1. Introduction 1. Introduction
RTP [RFC3550] payload formats define how a specific real-time data RTP [RFC3550] payload formats define how a specific real-time data
format is structured in the payload of an RTP packet. A real-time format is structured in the payload of an RTP packet. A real-time
data format without a payload format specification can't be data format without a payload format specification can't be
transported using RTP. This creates an interest from many transported using RTP. This creates an interest from many
individuals/organizations with media encoders or other types of real- individuals/organizations with media encoders or other types of real-
time data to define RTP payload formats. The specification of a well time data to define RTP payload formats. The specification of a well
designed RTP payload format is non-trivial and requires knowledge of designed RTP payload format is non-trivial and requires knowledge of
skipping to change at page 9, line 28 skipping to change at page 9, line 28
RFC 2606: When writing examples using DNS names in Internet drafts, RFC 2606: When writing examples using DNS names in Internet drafts,
those name shall be using the example.com, example.net, and those name shall be using the example.com, example.net, and
example.org domains. example.org domains.
RFC 3849: Defines the range of IPv6 unicast addresses (2001: RFC 3849: Defines the range of IPv6 unicast addresses (2001:
DB8::/32) that should be used in any examples. DB8::/32) that should be used in any examples.
RFC 3330: Defines the range of IPv4 unicast addresses reserved for RFC 3330: Defines the range of IPv4 unicast addresses reserved for
documentation and examples: 192.0.2.0/24. documentation and examples: 192.0.2.0/24.
RFC 4234: Augmented Backus-Naur Form (ABNF) is often used when RFC 5234: Augmented Backus-Naur Form (ABNF) is often used when
writing text field specifications. Not that commonly used in RTP writing text field specifications. Not that commonly used in RTP
payload formats but may be useful when defining Media Type payload formats but may be useful when defining Media Type
parameters of some complexity. parameters of some complexity.
3.1.2. RTP 3.1.2. RTP
The recommended reading for RTP consist of several different parts; The recommended reading for RTP consist of several different parts;
design guidelines, the RTP protocol, profiles, robustness tools, and design guidelines, the RTP protocol, profiles, robustness tools, and
media specific recommendations. media specific recommendations.
skipping to change at page 10, line 9 skipping to change at page 10, line 9
Then it is suitable to learn more about the RTP protocol, by studying Then it is suitable to learn more about the RTP protocol, by studying
the RTP specification RFC 3550 [RFC3550] and the existing profiles. the RTP specification RFC 3550 [RFC3550] and the existing profiles.
As a complement to the standards document there exist a book totally As a complement to the standards document there exist a book totally
dedicated to RTP [CSP-RTP]. There exist several profiles for RTP dedicated to RTP [CSP-RTP]. There exist several profiles for RTP
today, but all are based on the "RTP Profile for Audio and Video today, but all are based on the "RTP Profile for Audio and Video
Conferences with Minimal Control" (RFC 3551) [RFC3551] (abbreviated Conferences with Minimal Control" (RFC 3551) [RFC3551] (abbreviated
AVP). The other profiles that one should known about are Secure RTP AVP). The other profiles that one should known about are Secure RTP
(SAVP) [RFC3711], "Extended RTP Profile for RTCP-based Feedback" (SAVP) [RFC3711], "Extended RTP Profile for RTCP-based Feedback"
[RFC4585] and "Extended Secure RTP Profile for RTCP-based Feedback [RFC4585] and "Extended Secure RTP Profile for RTCP-based Feedback
(RTP/SAVPF)" [I-D.ietf-avt-profile-savpf]. It is important to (RTP/SAVPF)" [RFC5124]. It is important to understand RTP and the
understand RTP and the AVP profile in detail. For the other profiles AVP profile in detail. For the other profiles it is sufficient to
it is sufficient to have an understanding on what functionality they have an understanding on what functionality they provided and the
provided and the limitations they create. limitations they create.
There has been developed a number of robustness tools for RTP. The There has been developed a number of robustness tools for RTP. The
tools are for different use cases and real-time requirements. tools are for different use cases and real-time requirements.
RFC 2198: The "RTP Payload for Redundant Audio Data" [RFC2198] RFC 2198: The "RTP Payload for Redundant Audio Data" [RFC2198]
provides functionalities to provided redundant copies of audio or provides functionalities to provided redundant copies of audio or
text payloads. These redundant copies are sent together with an text payloads. These redundant copies are sent together with an
primary format in the same RTP payload. This format relies on the primary format in the same RTP payload. This format relies on the
RTP timestamp to determine where data belongs in a sequence and RTP timestamp to determine where data belongs in a sequence and
therefore is usually primarily suitable to be used with audio. therefore is usually primarily suitable to be used with audio.
However also the RTP Payload format for T.140 [RFC4103] text However also the RTP Payload format for T.140 [RFC4103] text
format uses this format. The formats major property is that it format uses this format. The formats major property is that it
only preserves the timestamp of the redundant payloads, not the only preserves the timestamp of the redundant payloads, not the
original sequence number. Thus making it unusable for most video original sequence number. Thus making it unusable for most video
formats. This format is also only suitable for media formats that formats. This format is also only suitable for media formats that
produce relatively small RTP payloads. produce relatively small RTP payloads.
RFC 2733: The "An RTP Payload Format for Generic Forward Error RFC 5109: The "RTP Payload Format for Generic Forward Error
Correction" provides an XOR based FEC over a number of RTP Correction" [RFC5109] provides an XOR based FEC of the whole or
packets. These FEC packets are sent in a separate stream or as a parts of a the packets for a number of RTP packets. These FEC
redundant encoding using RFC 2198. This FEC scheme has certain packets are sent in a separate stream or as a redundant encoding
restrictions in the number of packets it can protect. It is using RFC 2198. This FEC scheme has certain restrictions in the
suitable for low to medium delay tolerant applications with number of packets it can protect. It is suitable for low to
limited amount of RTP packets. medium delay tolerant applications with limited amount of RTP
packets.
RTP Retransmission: The RTP retransmission scheme [RFC4588] is used RTP Retransmission: The RTP retransmission scheme [RFC4588] is used
for semi-reliability of the most important RTP packets in a media for semi-reliability of the most important RTP packets in a media
stream. The scheme is not intended, nor suitable, to provide full stream. The scheme is not intended, nor suitable, to provide full
reliability. It requires the application to be quite delay reliability. It requires the application to be quite delay
tolerant as a minimum of one round-trip time plus processing delay tolerant as a minimum of one round-trip time plus processing delay
is required to perform an retransmission. Thus it is mostly is required to perform an retransmission. Thus it is mostly
suitable for streaming applications but may also be usable in suitable for streaming applications but may also be usable in
certain other cases when operating on networks with short RTT. certain other cases when operating on networks with short RTT.
skipping to change at page 12, line 37 skipping to change at page 12, line 38
features which will need to be considered when used. features which will need to be considered when used.
RTP Encryption: Section 9 of RFC 3550 describes a mechanism to RTP Encryption: Section 9 of RFC 3550 describes a mechanism to
provide confidentiality of the RTP and RTCP packets, using per provide confidentiality of the RTP and RTCP packets, using per
default DES encryption. It may use other encryption algorithms if default DES encryption. It may use other encryption algorithms if
both end-points agree on it. This mechanism is not recommend due both end-points agree on it. This mechanism is not recommend due
to its weak security properties of the used encryption algorithms. to its weak security properties of the used encryption algorithms.
It also lacks integrity and source authentication mechanisms. It also lacks integrity and source authentication mechanisms.
SRTP: The profile for Secure RTP (SAVP) [RFC3711] and the derived SRTP: The profile for Secure RTP (SAVP) [RFC3711] and the derived
profile (SAVPF [I-D.ietf-avt-profile-savpf]) is a solution that profile (SAVPF [RFC5124]) is a solution that provides
provides confidentiality, integrity protection and partial source confidentiality, integrity protection and partial source
authentication. authentication.
IPsec: IPsec [RFC4301] may also be used to protect RTP and RTCP IPsec: IPsec [RFC4301] may also be used to protect RTP and RTCP
packet. packet.
TLS: TLS [RFC4346] may also be used to provide transport security TLS: TLS [RFC4346] may also be used to provide transport security
between two end-point of the TLS connection for a flow of RTP between two end-point of the TLS connection for a flow of RTP
packets that are framed over TCP. packets that are framed over TCP.
DTLS: Datagram TLS [RFC4347] is an alternative to TLS that allow TLS DTLS: Datagram TLS [RFC4347] is an alternative to TLS that allow TLS
skipping to change at page 17, line 51 skipping to change at page 17, line 51
example there have been discussion on a new Session Description example there have been discussion on a new Session Description
format within IETF (SDP-NG). To prevent locking the usage of RTP to format within IETF (SDP-NG). To prevent locking the usage of RTP to
SDP based out-of-band signalling, the payload formats are identified SDP based out-of-band signalling, the payload formats are identified
using an separate definition format for the identifier and using an separate definition format for the identifier and
parameters. That format is the Media Type. parameters. That format is the Media Type.
3.3.1. Media Types 3.3.1. Media Types
Media types [RFC4288] was originally created for identifying media Media types [RFC4288] was originally created for identifying media
formats included in email. Media types are today also used in HTTP formats included in email. Media types are today also used in HTTP
[RFC2616], MSRP [I-D.ietf-simple-message-sessions] and many other [RFC2616], MSRP [RFC4975] and many other protocols to identify
protocols to identify arbitrary content carried within the protocols. arbitrary content carried within the protocols. Media types also
Media types also provide a media hierarchy that fits RTP payload provide a media hierarchy that fits RTP payload formats well. Media
formats well. Media type names are two-part and consist of content type names are two-part and consist of content type and sub-type
type and sub-type separated with a slash, e.g. "audio/PCMA" or separated with a slash, e.g. "audio/PCMA" or "video/h263-2000". It
"video/h263-2000". It is important to choose the correct content- is important to choose the correct content-type when creating the
type when creating the media type identifying an RTP payload format. media type identifying an RTP payload format. However in most cases
However in most cases there is little doubt what content type the there is little doubt what content type the format belongs to.
format belongs to. Guidelines for choosing the correct media type Guidelines for choosing the correct media type and registration rules
and registration rules are present in RFC 4288 [RFC4288]. The are present in RFC 4288 [RFC4288]. The additional rules for media
additional rules for media types for RTP payload formats are present types for RTP payload formats are present in RFC 4855 [RFC4855].
in RFC 4855 [RFC4855].
Media types are allowed any number of parameters which are divided Media types are allowed any number of parameters which are divided
into two groups, required and optional parameters. They are always into two groups, required and optional parameters. They are always
on the form name=value. There exist no restriction on how the value on the form name=value. There exist no restriction on how the value
is defined from media types perspective, except that parameters must is defined from media types perspective, except that parameters must
have value. However the carrying of media types in SDP etc. has have value. However the carrying of media types in SDP etc. has
resulted in the following restrictions that needs to be followed to resulted in the following restrictions that needs to be followed to
make media types for RTP payload format usable: make media types for RTP payload format usable:
1. Arbitrary binary content in the parameters are allowed but needs 1. Arbitrary binary content in the parameters are allowed but needs
to be encoded so that they can be placed within text based to be encoded so that they can be placed within text based
protocols. Base64 [RFC3548] is recommended, but for shorter protocols. Base64 [RFC4648] is recommended, but for shorter
content BASE16 may be more appropriate as it is simpler to content BASE16 may be more appropriate as it is simpler to
interpret by humans. This needs to be explicitly stated when interpret by humans. This needs to be explicitly stated when
defining a media type parameter with binary value. defining a media type parameter with binary value.
2. The end of the value needs to be easily found when parsing a 2. The end of the value needs to be easily found when parsing a
message. Thus parameter values that are continuous and non message. Thus parameter values that are continuous and non
interrupted by common text separators, such as space and semi- interrupted by common text separators, such as space and semi-
colon are recommended. If that is not possible some type of colon are recommended. If that is not possible some type of
escaping should be used. Usage of <"> is recommended. escaping should be used. Usage of " (double quote) is
recommended.
3. A common representation form of the media type and its parameters 3. A common representation form of the media type and its parameters
is on a single line. In those cases the media type is followed is on a single line. In those cases the media type is followed
by a semi-colon separated list of the parameter value pair, e.g. by a semi-colon separated list of the parameter value pair, e.g.
audio/amr octet-align=0; mode-set=0,2,5,7; mode-change-period=2. audio/amr octet-align=0; mode-set=0,2,5,7; mode-change-period=2.
3.3.2. Mapping to SDP 3.3.2. Mapping to SDP
As SDP [RFC4566] is so commonly used as an out-of-band signalling As SDP [RFC4566] is so commonly used as an out-of-band signalling
channel, a mapping of the media type exist. The details on how to channel, a mapping of the media type exist. The details on how to
skipping to change at page 26, line 48 skipping to change at page 26, line 48
both one selves and ones partner, as interoperability will much both one selves and ones partner, as interoperability will much
easier to accomplish. easier to accomplish.
o To ensure interoperability between different implementations on o To ensure interoperability between different implementations on
different platforms. different platforms.
To avoid name collisions there is a central register keeping tracks To avoid name collisions there is a central register keeping tracks
of the registered Media Type names used by different RTP payload of the registered Media Type names used by different RTP payload
formats. When it comes to proprietary formats they should be formats. When it comes to proprietary formats they should be
registered in the vendors own tree. All vendor specific registered in the vendors own tree. All vendor specific
registrations uses names that start with "vnd.<vendor-name>". All registrations uses sub-type names that start with "vnd.<vendor-
names that uses names in the vendors own trees are not required to be name>". All names that uses names in the vendors own trees are not
registered with IANA. However registration is recommended if used at required to be registered with IANA. However registration is
all in public environments. recommended if used at all in public environments.
5. Designing Payload Formats 5. Designing Payload Formats
The best summary of payload format design is KISS (Keep It Simple, The best summary of payload format design is KISS (Keep It Simple,
Stupid). A simple payload format makes it easy to review for Stupid). A simple payload format makes it easy to review for
correctness, implement, and have low complexity. Unfortunately correctness, implement, and have low complexity. Unfortunately
contradicting requirements sometime makes it hard to do things contradicting requirements sometime makes it hard to do things
simple. Complexity issues and problems that occur for RTP payload simple. Complexity issues and problems that occur for RTP payload
formats are: formats are:
skipping to change at page 28, line 9 skipping to change at page 28, line 9
of sizes smaller than the IP MTU. Do remember that the MTU may be of sizes smaller than the IP MTU. Do remember that the MTU may be
significantly larger than 1500 bytes, 9000 bytes is available today significantly larger than 1500 bytes, 9000 bytes is available today
and a MTU of 64k may be available in the future. Many speech codecs and a MTU of 64k may be available in the future. Many speech codecs
have the property of ADUs of a few fixed sizes. Video encoders have the property of ADUs of a few fixed sizes. Video encoders
generally may produce ADUs of quite flexible size. Thus the need for generally may produce ADUs of quite flexible size. Thus the need for
aggregation may be less. However in certain use cases the aggregation may be less. However in certain use cases the
possibility to aggregate multiple ADUs especially for different possibility to aggregate multiple ADUs especially for different
playback times are useful. playback times are useful.
The main disadvantage of aggregation is the extra delay introduced, The main disadvantage of aggregation is the extra delay introduced,
due to buffering until sufficient amount of ADUs have been collected. due to buffering until sufficient amount of ADUs have been collected
It also introduces buffering requirements on the receiver. and reduced robustness against packet loss. It also introduces
buffering requirements on the receiver.
5.1.2. Fragmentation 5.1.2. Fragmentation
If the real-time media format has the property that it may produce If the real-time media format has the property that it may produce
ADUs that are larger than common MTUs sizes then fragmentation ADUs that are larger than common MTUs sizes then fragmentation
support should be considered. An RTP Payload format may always fall support should be considered. An RTP Payload format may always fall
back on IP fragmentation, however as discussed in RFC 2736 this have back on IP fragmentation, however as discussed in RFC 2736 this have
some drawbacks. The usage of RTP payload format level fragmentation, some drawbacks. The usage of RTP payload format level fragmentation,
does primarily allow for more efficient usage of RTP packet loss does primarily allow for more efficient usage of RTP packet loss
recovery mechanisms. However it may in some cases also allow usage recovery mechanisms. However it may in some cases also allow usage
skipping to change at page 30, line 5 skipping to change at page 29, line 27
[RFC4867] codec mode request (CMR) field. The CMR field is used in [RFC4867] codec mode request (CMR) field. The CMR field is used in
gateway operations to circuit switched voice to allow an IP terminal gateway operations to circuit switched voice to allow an IP terminal
to react to the CS networks need for a specific encoder mode. A to react to the CS networks need for a specific encoder mode. A
common property for the media back channels is the need to have this common property for the media back channels is the need to have this
signalling in direct relation to the media or the media path. signalling in direct relation to the media or the media path.
If back channels are considered for an RTP payload format they should If back channels are considered for an RTP payload format they should
be for specific mechanism and which can't be easily satisfied by more be for specific mechanism and which can't be easily satisfied by more
generic mechanisms within RTP or RTCP. generic mechanisms within RTP or RTCP.
5.1.5. Scalability
There exist some codecs that supports some type of scalability, i.e.
where additional data can be used to improve media stream properties,
but the additional data isn't required for decoding. This quality
improvements has been so far been in a number of different types:
Temporal: For video codecs increased frame rate is one way to
improve the quality. Audio codecs could provide increase sampling
rate.
Spatial: Video codecs with scalability may increase the resolution
or image size.
Quality: The perceived quality of the media stream can be improved
without affecting the temporal or spatial properties of the media.
This is usually done by improving the signal to noise ration
within the content.
Codecs that support scalability are at the time of writing this
having a bit of revival. It has been realized that getting the need
functionality for the media stream in the RTP framework is quite
challanging. The author hopes to be able to provide some lessons
from this work in this document in the future.
5.1.6. High Packet Rates
Some media codecs requires high packet rates, and in these cases the
RTP sequence number wraps to quickly. As rule of thumd, the sequence
number space must not be possible to wrap in less than 2 minutes (TCP
maximum segement lifetime). If that may occur then the payload
format should specify a extended sequence number field to allow the
receiver to determine where a specific payload belongs in the
sequence also in the face of extensive reordering. The RTP payload
format for uncompressed video [RFC4175] can be used as an example for
such a field.
6. Current Trends in Payload Format Design 6. Current Trends in Payload Format Design
This section provides a few examples of payload formats that is worth This section provides a few examples of payload formats that is worth
noting for good design in general or specific details. noting for good design in general or specific details.
6.1. Audio Payloads 6.1. Audio Payloads
The AMR [RFC4867], AMR-WB [RFC4867], EVRC [RFC3558], SMV [RFC3558] The AMR [RFC4867], AMR-WB [RFC4867], EVRC [RFC3558], SMV [RFC3558]
payload format are all quite similar. They are all for frame based payload format are all quite similar. They are all for frame based
audio codecs and use a table of content structure. Each frame has a audio codecs and use a table of content structure. Each frame has a
table of contents entry that indicate the type of the frame and if table of contents entry that indicate the type of the frame and if
additional frames are present. This is quite flexible but produces additional frames are present. This is quite flexible but produces
unnecessary overhead if the ADU is fixed size and when aggregating unnecessary overhead if the ADU is fixed size and when aggregating
multiple ones they are commonly of the same type. In that case a multiple ones they are commonly of the same type. In that case a
solution like that in AMR-WB+ [RFC4352] maybe more suitable. solution like that in AMR-WB+ [RFC4352] maybe more suitable.
AMR-WB+ does contain one less good feature which is depending on the
media codec itself. The media codec produces a large range of
different frame lengths in time perspective. The RTP timestamp rate
is selected to the very unusual value of 72 kHz despite that output
normally is at sample rate 48kHz. This timestamp rate is the
smallest found value that would make all of the frames the codec
could produce results in integer frame length in RTP timestamp ticks.
That way a receiver can always correctly place the frames in relation
to any other frame, also at frame length changes. The down side is
that the decoder output for certain frame lengths are in fact partial
samples. Resulting in that the output in samples from the codec will
vary from frame to frame, potentially making implementation more
difficult.
The RTP payload format for MIDI [RFC4695] contains some interesting The RTP payload format for MIDI [RFC4695] contains some interesting
features. MIDI is an audio format sensitive to packet losses, as the features. MIDI is an audio format sensitive to packet losses, as the
loss of a note off command will result in that a note will be stuck loss of a note off command will result in that a note will be stuck
in an on state. To counter this a recovery journal is defined that in an on state. To counter this a recovery journal is defined that
provides a summarized state that allows the receiver to recover from provides a summarized state that allows the receiver to recover from
packet losses quickly. It also uses RTCP and the reported highest packet losses quickly. It also uses RTCP and the reported highest
sequence number to be able to prune the state the recovery journal sequence number to be able to prune the state the recovery journal
needs to contain. These features appears limited in applicability needs to contain. These features appears limited in applicability
for media formats that are highly stateful and primarily uses for media formats that are highly stateful and primarily uses
symbolic media representations. symbolic media representations.
6.2. Video 6.2. Video
To be written 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.
The H.264 RTP payload format [RFC3984] can be seen as a smorgasbord
of functionality, some pretty advanced as the interleaving. The
reason for this was to ensure that the majority of applications
considered by the ITU-T and MPEG that can be supported by RTP was
supported. This has created a payload format that rarely is
implemented in its completness. Despite that no major issues with
interoperability has been reported. However, there are common
complaints about its complexity.
The RTP payload format for uncompressed video [RFC4175] is basically
required to be mentioned in this context as it contains a special
feature not commonly seen in RTP payload formats. Due to the high
bit-rate and thus packet rate of uncompressed video (gigabits rather
than megabits) the payload format include a field to extend the RTP
sequence number as the normal 16-bit one can wrap in below a second.
It also specifies a registry of different color sub-sampling that can
be re-used in other video RTP payload formats.
6.3. Text 6.3. Text
To be written There would be overstating that there exist a trend in text payload
formats as only a single format actually carrying a text format has
been standardized in IETF, namely T.140 [RFC4103]. The 3GPP Timed
Text format [RFC4396] could be considered to be text, despite it in
the end was registered as a video format. This is decorated text,
usable for subtitles and other embelishments of video which is why it
ended up being registered as video format. However, it has many of
the properties that text formats in generally have.
The RTP payload format for T.140 was designed with high reliability
in mind as real-time text commonly are a extremely low-bit rate
application. Thus, it recommends the use of RFC 2190 with many
redundancy generations. However, the format failed to provide a text
block specific sequence number and relies instead of the RTP one to
detection loss. This makes detection of missing text blocks
unecessarily difficult and hinders the deployement with other
robustness mechanisms that would switch the payload type as that may
result in erronous error marking in the T.140 text stream.
7. Important Specification Sections 7. Important Specification Sections
There a number of sections in the payload format draft that needs There a number of sections in the payload format draft that needs
some special considerations. These include security and IANA some special considerations. These include security and IANA
considerations. considerations.
7.1. Security Consideration 7.1. Security Consideration
All Internet drafts requires a Security Consideration section. The All Internet drafts requires a Security Consideration section. The
skipping to change at page 34, line 18 skipping to change at page 37, line 5
before publication: before publication:
o Should any procedure for the future when the AVT WG is closed be o Should any procedure for the future when the AVT WG is closed be
described? described?
o The section of current examples of good work needs to be filled o The section of current examples of good work needs to be filled
in. in.
o Consider mention RFC-errata o Consider mention RFC-errata
o Add text on extended sequence number field to allow high data
applications to use RTP when normal sequence number wraps to
quickly.
10. IANA Considerations 10. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
11. Security Considerations 11. Security Considerations
As this is an informational document on the writing of drafts As this is an informational document on the writing of drafts
skipping to change at page 39, line 10 skipping to change at page 41, line 10
Note to RFC Editor: This section may be removed after carrying out Note to RFC Editor: This section may be removed after carrying out
all the instructions of this section. all the instructions of this section.
13. Acknowledgements 13. Acknowledgements
14. Informative References 14. Informative References
[CSP-RTP] Colin , "RTP: Audio and Video for the Internet", [CSP-RTP] Colin , "RTP: Audio and Video for the Internet",
June 2003. June 2003.
[I-D.ietf-avt-profile-savpf]
Ott, J. and E. Carrara, "Extended Secure RTP Profile for
RTCP-based Feedback (RTP/SAVPF)",
draft-ietf-avt-profile-savpf-10 (work in progress),
March 2007.
[I-D.ietf-simple-message-sessions]
Campbell, B., "The Message Session Relay Protocol",
draft-ietf-simple-message-sessions-19 (work in progress),
February 2007.
[I-D.rfc-editor-rfc2223bis] [I-D.rfc-editor-rfc2223bis]
Reynolds, J. and R. Braden, "Instructions to Request for Reynolds, J. and R. Braden, "Instructions to Request for
Comments (RFC) Authors", draft-rfc-editor-rfc2223bis-08 Comments (RFC) Authors", draft-rfc-editor-rfc2223bis-08
(work in progress), July 2004. (work in progress), July 2004.
[MACOSFILETYPES] [MACOSFILETYPES]
Apple Knowledge Base Article Apple Knowledge Base Article
55381<http://www.info.apple.com/kbnum/n55381>, "Mac OS: 55381<http://www.info.apple.com/kbnum/n55381>, "Mac OS:
File Type and Creator Codes, and File Formats", 1993. File Type and Creator Codes, and File Formats", 1993.
skipping to change at page 41, line 5 skipping to change at page 42, line 42
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet- "Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002. Standard Management Framework", RFC 3410, December 2002.
[RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and [RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and
P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with
High Delay, Packet Loss and Reordering", RFC 3545, High Delay, Packet Loss and Reordering", RFC 3545,
July 2003. July 2003.
[RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 3548, July 2003.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003. July 2003.
[RFC3558] Li, A., "RTP Payload Format for Enhanced Variable Rate [RFC3558] Li, A., "RTP Payload Format for Enhanced Variable Rate
Codecs (EVRC) and Selectable Mode Vocoders (SMV)", Codecs (EVRC) and Selectable Mode Vocoders (SMV)",
skipping to change at page 42, line 26 skipping to change at page 44, line 13
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006. (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006. Security", RFC 4347, April 2006.
[RFC4352] Sjoberg, J., Westerlund, M., Lakaniemi, A., and S. Wenger, [RFC4352] Sjoberg, J., Westerlund, M., Lakaniemi, A., and S. Wenger,
"RTP Payload Format for the Extended Adaptive Multi-Rate "RTP Payload Format for the Extended Adaptive Multi-Rate
Wideband (AMR-WB+) Audio Codec", RFC 4352, January 2006. 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.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP)
and RTP Control Protocol (RTCP) Packets over Connection- and RTP Control Protocol (RTCP) Packets over Connection-
Oriented Transport", RFC 4571, July 2006. Oriented Transport", RFC 4571, July 2006.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
July 2006. July 2006.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006. 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 [RFC4677] Hoffman, P. and S. Harris, "The Tao of IETF - A Novice's
Guide to the Internet Engineering Task Force", RFC 4677, Guide to the Internet Engineering Task Force", RFC 4677,
September 2006. September 2006.
[RFC4695] Lazzaro, J. and J. Wawrzynek, "RTP Payload Format for [RFC4695] Lazzaro, J. and J. Wawrzynek, "RTP Payload Format for
MIDI", RFC 4695, November 2006. MIDI", RFC 4695, November 2006.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload [RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, February 2007. Formats", RFC 4855, February 2007.
[RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, [RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie,
"RTP Payload Format and File Storage Format for the "RTP Payload Format and File Storage Format for the
Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband
(AMR-WB) Audio Codecs", RFC 4867, April 2007. (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.
Appendix A. RTP Payload Format Template Appendix A. RTP Payload Format Template
This section contains a template for writing an RTP payload format in This section contains a template for writing an RTP payload format in
form as a Internet draft. Text within [...] are instructions and form as a Internet draft. Text within [...] are instructions and
must be removed. Some text proposals that are included are must be removed. Some text proposals that are included are
conditional. "..." is used to indicate where further text should be conditional. "..." is used to indicate where further text should be
written. written.
A.1. Title A.1. Title
skipping to change at page 52, line 7 skipping to change at page 54, line 7
Torshamgatan 23 Torshamgatan 23
Stockholm, SE-164 80 Stockholm, SE-164 80
SWEDEN SWEDEN
Phone: +46 8 7190000 Phone: +46 8 7190000
Fax: +46 8 757 55 50 Fax: +46 8 757 55 50
Email: magnus.westerlund@ericsson.com Email: magnus.westerlund@ericsson.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 36 change blocks. 
104 lines changed or deleted 196 lines changed or added

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