draft-ietf-avt-rtp-howto-01.txt   draft-ietf-avt-rtp-howto-02.txt 
Audio Video Transport Working M. Westerlund Audio Video Transport Working M. Westerlund
Group Ericsson Group Ericsson
Intended status: Informational Intended status: Informational
Expires: June 18, 2007 Expires: January 10, 2008
How to Write an RTP Payload Format How to Write an RTP Payload Format
draft-ietf-avt-rtp-howto-01.txt draft-ietf-avt-rtp-howto-02.txt
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 June 18, 2007. This Internet-Draft will expire on January 10, 2008.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
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 26 skipping to change at page 2, line 26
1.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . 12 3.2. Important RTP details . . . . . . . . . . . . . . . . . . 13
3.2.1. The RTP Session . . . . . . . . . . . . . . . . . . . 12 3.2.1. The RTP Session . . . . . . . . . . . . . . . . . . . 13
3.2.2. RTP Header . . . . . . . . . . . . . . . . . . . . . . 13 3.2.2. RTP Header . . . . . . . . . . . . . . . . . . . . . . 14
3.2.3. RTP Multiplexing . . . . . . . . . . . . . . . . . . . 14 3.2.3. RTP Multiplexing . . . . . . . . . . . . . . . . . . . 15
3.2.4. RTP Synchronization . . . . . . . . . . . . . . . . . 15 3.2.4. RTP Synchronization . . . . . . . . . . . . . . . . . 15
3.3. Signalling Aspects . . . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . 20 3.4. Transport Characteristics . . . . . . . . . . . . . . . . 21
3.4.1. Path MTU . . . . . . . . . . . . . . . . . . . . . . . 20 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
4.1.3. Draft Naming . . . . . . . . . . . . . . . . . . . . . 24 4.1.3. Draft Naming . . . . . . . . . . . . . . . . . . . . . 24
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. Aggreagation . . . . . . . . . . . . . . . . . . . . . 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 6. Current Trends in Payload Format Design . . . . . . . . . . . 30
6.1. Audio Payloads . . . . . . . . . . . . . . . . . . . . . . 30 6.1. Audio Payloads . . . . . . . . . . . . . . . . . . . . . . 30
6.2. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.2. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.3. Text . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.3. Text . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7. Important Specification Sections . . . . . . . . . . . . . . . 31 7. Important Specification Sections . . . . . . . . . . . . . . . 31
7.1. Security Consideration . . . . . . . . . . . . . . . . . . 31 7.1. Security Consideration . . . . . . . . . . . . . . . . . . 31
skipping to change at page 3, line 30 skipping to change at page 3, line 30
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
11. Security Considerations . . . . . . . . . . . . . . . . . . . 36 11. Security Considerations . . . . . . . . . . . . . . . . . . . 36
12. RFC Editor Consideration . . . . . . . . . . . . . . . . . . . 37 12. RFC Editor Consideration . . . . . . . . . . . . . . . . . . . 37
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38
14. Informative References . . . . . . . . . . . . . . . . . . . . 39 14. Informative References . . . . . . . . . . . . . . . . . . . . 39
Appendix A. RTP Payload Format Template . . . . . . . . . . . . . 43 Appendix A. RTP Payload Format Template . . . . . . . . . . . . . 44
A.1. Title . . . . . . . . . . . . . . . . . . . . . . . . . . 43 A.1. Title . . . . . . . . . . . . . . . . . . . . . . . . . . 44
A.2. Front page boilerplate . . . . . . . . . . . . . . . . . . 43 A.2. Front page boilerplate . . . . . . . . . . . . . . . . . . 44
A.3. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . 44 A.3. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . 45
A.4. Table of Content . . . . . . . . . . . . . . . . . . . . . 44 A.4. Table of Content . . . . . . . . . . . . . . . . . . . . . 45
A.5. Introduction . . . . . . . . . . . . . . . . . . . . . . . 44 A.5. Introduction . . . . . . . . . . . . . . . . . . . . . . . 45
A.6. Conventions, Definitions and Acronyms . . . . . . . . . . 44 A.6. Conventions, Definitions and Acronyms . . . . . . . . . . 45
A.7. Media Format Background . . . . . . . . . . . . . . . . . 44 A.7. Media Format Background . . . . . . . . . . . . . . . . . 45
A.8. Payload format . . . . . . . . . . . . . . . . . . . . . . 44 A.8. Payload format . . . . . . . . . . . . . . . . . . . . . . 45
A.8.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . 45 A.8.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . 46
A.8.2. Payload Header . . . . . . . . . . . . . . . . . . . . 45 A.8.2. Payload Header . . . . . . . . . . . . . . . . . . . . 46
A.8.3. Payload Data . . . . . . . . . . . . . . . . . . . . . 45 A.8.3. Payload Data . . . . . . . . . . . . . . . . . . . . . 46
A.9. Payload Examples . . . . . . . . . . . . . . . . . . . . . 45 A.9. Payload Examples . . . . . . . . . . . . . . . . . . . . . 46
A.10. Congestion Control Considerations . . . . . . . . . . . . 45 A.10. Congestion Control Considerations . . . . . . . . . . . . 46
A.11. Payload Format Parameters . . . . . . . . . . . . . . . . 45 A.11. Payload Format Parameters . . . . . . . . . . . . . . . . 46
A.11.1. Media Type Definition . . . . . . . . . . . . . . . . 45 A.11.1. Media Type Definition . . . . . . . . . . . . . . . . 46
A.11.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . 47 A.11.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . 48
A.12. IANA Considerations . . . . . . . . . . . . . . . . . . . 47 A.12. IANA Considerations . . . . . . . . . . . . . . . . . . . 48
A.13. Securtiy Considerations . . . . . . . . . . . . . . . . . 47 A.13. Securtiy Considerations . . . . . . . . . . . . . . . . . 48
A.14. References . . . . . . . . . . . . . . . . . . . . . . . . 48 A.14. References . . . . . . . . . . . . . . . . . . . . . . . . 49
A.14.1. Normative References . . . . . . . . . . . . . . . . . 48 A.14.1. Normative References . . . . . . . . . . . . . . . . . 49
A.14.2. Informative References . . . . . . . . . . . . . . . . 48 A.14.2. Informative References . . . . . . . . . . . . . . . . 49
A.15. Author Addresses . . . . . . . . . . . . . . . . . . . . . 48 A.15. Author Addresses . . . . . . . . . . . . . . . . . . . . . 49
A.16. IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . 48 A.16. IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . 49
A.17. Copyright Notice . . . . . . . . . . . . . . . . . . . . . 49 A.17. Copyright Notice . . . . . . . . . . . . . . . . . . . . . 50
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 50 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 51
Intellectual Property and Copyright Statements . . . . . . . . . . 51 Intellectual Property and Copyright Statements . . . . . . . . . . 52
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 6, line 9 skipping to change at page 6, line 9
applicable. Following that there is a discussion on important applicable. Following that there is a discussion on important
sections in the RTP payload format specification itself, like sections in the RTP payload format specification itself, like
security and IANA considerations. This document ends with an security and IANA considerations. This document ends with an
appendix containing an template that can be used when writing RTP appendix containing an template that can be used when writing RTP
payload formats. payload formats.
2. Terminology 2. Terminology
2.1. Definitions 2.1. Definitions
Media Stream A sequence of RTP packets that together provides all or Media Stream: A sequence of RTP packets that together provides all
parts of a media. It is scoped in RTP by the RTP session and a or parts of a media. It is scoped in RTP by the RTP session and a
single sender source. single sender source.
RTP Session: An association among a set of participants RTP Session: An association among a set of participants
communicating with RTP. The distinguishing feature of an RTP communicating with RTP. The distinguishing feature of an RTP
session is that each maintains a full, separate space of SSRC session is that each maintains a full, separate space of SSRC
identifiers. See also Section (Section 3.2.1). identifiers. See also Section (Section 3.2.1).
RTP Payload Format: The RTP Payload format specifies how a specific RTP Payload Format: The RTP Payload format specifies how a specific
media format is put into the RTP Payloads. Thus enabling the media format is put into the RTP Payloads. Thus enabling the
format to be used in RTP sessions. format to be used in RTP sessions.
skipping to change at page 8, line 11 skipping to change at page 8, line 11
RTT: Round Trip Time RTT: Round Trip Time
SSM: Source Specific Multicast SSM: Source Specific Multicast
3. Preparations 3. Preparations
RTP is a complex real-time media delivery framework and it has a lot RTP is a complex real-time media delivery framework and it has a lot
of details to consider when writing an RTP payload format. There is of details to consider when writing an RTP payload format. There is
also important to have a good understanding of the media codec/format also important to have a good understanding of the media codec/format
so that all its important features and properties are considered. so that all its important features and properties are considered.
First when one has sufficient understanding of both part can one First when one has sufficient understanding of both parts can one
produce an RTP payload format of high quality. On top of this, one produce an RTP payload format of high quality. On top of this, one
needs to understand the process within IETF and especially the AVT WG needs to understand the process within IETF and especially the AVT WG
to quickly go from initial idea to a finished RFC. This and the next to quickly go from initial idea to a finished RFC. This and the next
section helps an author prepare himself in those regards. section helps an author prepare himself in those regards.
3.1. Recommend Reading 3.1. Recommend Reading
In the below sub sections there are a number of documents listed. In the below sub sections there are a number of documents listed.
Not all needs to be read in full detail. However basically Not all needs to be read in full detail. However, an author
everything listed below does an author need to be aware of. basically needs to be aware of everything listed below.
3.1.1. IETF Process and Publication 3.1.1. IETF Process and Publication
For newcommers to IETF it is strongly recommended that one reads the For newcomers to IETF it is strongly recommended that one reads the
"Tao of the IETF" [RFC4677] that goes through most things that one "Tao of the IETF" [RFC4677] that goes through most things that one
needs to know about the IETF. It contains information about history, needs to know about the IETF. It contains information about history,
organisational structure, how the WG and meetings work and many more organisational structure, how the WG and meetings work and many more
details. details.
The main part of the IETF process is defined in RFC 2026 [RFC2026]. The main part of the IETF process is defined in RFC 2026 [RFC2026].
In addition an author needs to understands the IETF rules and rights In addition an author needs to understands the IETF rules and rights
associated with copyright and IPR documented in BCP 78 [RFC3978] and associated with copyright and IPR documented in BCP 78 [RFC3978] and
BCP 79 [RFC3979]. RFC 2418 [RFC2418] describes the WG process, the BCP 79 [RFC3979]. RFC 2418 [RFC2418] describes the WG process, the
relation between the IESG and the WG, and the responsibilities of WG relation between the IESG and the WG, and the responsibilities of WG
skipping to change at page 10, line 35 skipping to change at page 10, line 35
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 2733: The "An RTP Payload Format for Generic Forward Error
Correction" provides an XOR based FEC over a number of RTP Correction" provides an XOR based FEC over a number of RTP
packets. These FEC packets are sent in a separate stream or as a packets. These FEC packets are sent in a separate stream or as a
redundant encoding using RFC 2198. This FEC scheme has certain redundant encoding using RFC 2198. This FEC scheme has certain
restrictions in the number of packets it can protect. It is restrictions in the number of packets it can protect. It is
suitable for low to medium delay tolerable applications with suitable for low to medium delay tolerant applications with
limited amount of RTP packets. 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
tolerable as a minimum of a 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.
RTP over TCP: RFC 4571 [RFC4571] defines how one sends RTP and RTCP
packet over conenction oriented transports like TCP. If one uses
TCP one gets reliability for all packets but loose some of the
real-time behavior that RTP was designed to provide. Issues with
TCP transport of real-time media include head of line blocking and
wasting resources on retransmission of already late data. TCP is
also limited to point-to-point connections which further restricts
its applicability.
There has also been discussion and also 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
unnecesary discards of data when the payload and media codec could
get at least some utility from the data. The main issue is that one
has no idea on the level of bit-errors present in the unprotected
part of the payload. Which makes it hard or impossible to determine
if one can design something usable or not. Payload format designers
are recommended against considering features for unequal error
detection unless very clear requirements exist.
There also exist some management and monitoring extensions. There also exist some management and monitoring extensions.
RFC 2959: The RTP protocol Management Information Database (MIB) RFC 2959: The RTP protocol Management Information Database (MIB)
[RFC2959] that is used with SNMP to configure and retrieve [RFC2959] that is used with SNMP [RFC3410] to configure and
information about RTP sessions. retrieve information about RTP sessions.
RFC 3611: The RTCP Extended Reports (RTCP XR) [RFC3611] consist of a RFC 3611: The RTCP Extended Reports (RTCP XR) [RFC3611] consist of a
framework for reports sent within RTCP. It can easily be extended framework for reports sent within RTCP. It can easily be extended
by defining new report formats in future. The report formats that by defining new report formats in future. The report formats that
are defined are providing report information on; packet loss are defined are providing report information on; packet loss
vectors, packet duplication, packet reception times, RTCP vectors, packet duplication, packet reception times, RTCP
statistics summary and VoIP Quality. It also defines a mechanism statistics summary and VoIP Quality. It also defines a mechanism
that allows receivers to calculate the RTT to other session that allows receivers to calculate the RTT to other session
participants when used. participants when used.
skipping to change at page 12, line 30 skipping to change at page 12, line 50
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
to be used over datagrams, like UDP. Thus it has the potential to be used over datagrams, like UDP. Thus it has the potential
for being used to protoect RTP over UDP. However the necessary for being used to protect RTP over UDP. However the necessary
signalling mechanism for using it that has not yet been developed signalling mechanism for using it that has not yet been developed
in any of the IETF real-time media application signalling in any of the IETF real-time media application signalling
protocols. protocols.
3.2. Important RTP details 3.2. Important RTP details
This section does not remove the necessity of reading up on RTP. This section does not remove the necessity of reading up on RTP.
However it does point out a couple of important details to remember However it does point out a couple of important details to remember
when designing the payload format. when designing the payload format.
skipping to change at page 14, line 13 skipping to change at page 14, line 30
that. that.
Timestamp: The RTP timestamp indicate the time instance the media Timestamp: The RTP timestamp indicate the time instance the media
belongs to. For discrete media, like video it normally indicates belongs to. For discrete media, like video it normally indicates
when the media (frame) was sampled. For continuous media it when the media (frame) was sampled. For continuous media it
normally indicates the first time instance the media present in normally indicates the first time instance the media present in
the payload represents. For audio this is the sampling time of the payload represents. For audio this is the sampling time of
the first sample. All RTP payload formats must specify the the first sample. All RTP payload formats must specify the
meaning of the timestamp value and which clock rates that are meaning of the timestamp value and which clock rates that are
allowed. Note that clock rates below 1000 Hz is not appropriate allowed. Note that clock rates below 1000 Hz is not appropriate
due to RTCP measurements function that in that case loose due to RTCP measurements function that in that case lose
resolution. resolution.
Sequence number: The sequence number are monotonically increasing Sequence number: The sequence number are monotonically increasing
and set as packets are sent. That property is used in many and set as packets are sent. That property is used in many
payload formats to recover the order of everything from the whole payload formats to recover the order of everything from the whole
stream down to fragments of ADUs and the order they shall be stream down to fragments of ADUs and the order they shall be
decoded. decoded.
Payload Type: Commonly the same payload type is used for a media Payload Type: Commonly the same payload type is used for a media
stream for the whole duration of a session. However in some cases stream for the whole duration of a session. However in some cases
it may be required to change the payload format or its it may be required to change the payload format or its
configuration during the session. The payload type is used to configuration during the session. The payload type is used to
indicate on a per packet basis which format is used. Thus certain indicate on a per packet basis which format is used. Thus certain
major configuration information can be bound to a payload type major configuration information can be bound to a payload type
value by out-of-band signalling. Examples of this would be video value by out-of-band signalling. Examples of this would be video
decoder configuration information. decoder configuration information.
SSRC: The Sender Source ID is normally not used by a payload format SSRC: The Sender Source ID is normally not used by a payload format
other than identifying the RTP timestamp and sequence number space other than identifying the RTP timestamp and sequence number space
a packet belongs to, allowing the simultaneously reception of a packet belongs to, allowing the simultaneously reception of
multiple senders. However there are certain of the RTP multiple senders. However there are certain of the mechanisms the
robustification mechanisms that are RTP payloads that have used make RTP robuster that are RTP payloads that have used multiple
multiple SSRCs and bound them together to correctly separate SSRCs and bound them together to correctly separate original data
original data and repair or robustification data. and repair or redundant data.
The remaining fields are commonly not influencing the RTP payload The remaining fields are commonly not influencing the RTP payload
format. The padding bit is worth clarifying as it indicates that one format. The padding bit is worth clarifying as it indicates that one
or more bytes are appended after the RTP payload. This padding must or more bytes are appended after the RTP payload. This padding must
be removed by a receiver before payload format processing can occur. be removed by a receiver before payload format processing can occur.
Thus it is completely separate from any padding that may occur within Thus it is completely separate from any padding that may occur within
the payload format itself. the payload format itself.
3.2.3. RTP Multiplexing 3.2.3. RTP Multiplexing
skipping to change at page 17, line 36 skipping to change at page 18, line 14
protocols to identify arbitrary content carried within the protocols. protocols to identify arbitrary content carried within the protocols.
Media types also provide a media hierarchy that fits RTP payload Media types also provide a media hierarchy that fits RTP payload
formats well. Media type names are two-part and consist of content 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 type and sub-type separated with a slash, e.g. "audio/PCMA" or
"video/h263-2000". It is important to choose the correct content- "video/h263-2000". It is important to choose the correct content-
type when creating the media type identifying an RTP payload format. type when creating the media type identifying an RTP payload format.
However in most cases there is little doubt what content type the However in most cases there is little doubt what content type the
format belongs to. Guidelines for choosing the correct media type format belongs to. Guidelines for choosing the correct media type
and registration rules are present in RFC 4288 [RFC4288]. The and registration rules are present in RFC 4288 [RFC4288]. The
additional rules for media types for RTP payload formats are present additional rules for media types for RTP payload formats are present
in RFC XXXX [I-D.ietf-avt-rfc3555bis]. 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
skipping to change at page 18, line 21 skipping to change at page 18, line 47
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
map the media type and its parameters into SDP are described in RFC map the media type and its parameters into SDP are described in RFC
XXXX [I-D.ietf-avt-rfc3555bis]. However this is not sufficient to 4855 [RFC4855]. However this is not sufficient to explain how
explain how certain parameter shall be interpreted for example in the certain parameter shall be interpreted for example in the context of
context of Offer/Answer negotiation [RFC3264]. Offer/Answer negotiation [RFC3264].
3.3.2.1. The Offer/Answer Model 3.3.2.1. The Offer/Answer Model
The Offer/Answer (O/A) model allows SIP to negotiate media formats The Offer/Answer (O/A) model allows SIP to negotiate media formats
and which payload formats and their configuration is used in a and which payload formats and their configuration is used in a
session. However O/A does not define a default behavior and instead session. However O/A does not define a default behavior and instead
points out the need to define how parameters behave. To make things points out the need to define how parameters behave. To make things
even more complex the direction of media within a session do have even more complex the direction of media within a session do have
impact on these rules, thus some cases may require description impact on these rules, thus some cases may require description
separately for peers that are send only, receiver only or both separately for peers that are send only, receiver only or both
skipping to change at page 25, line 23 skipping to change at page 25, line 23
authors lets the draft slip. By performing updates to the draft authors lets the draft slip. By performing updates to the draft
text directly after getting resolution on an issue, speeds things text directly after getting resolution on an issue, speeds things
up. This as it minimizes the delay that the author has direct up. This as it minimizes the delay that the author has direct
control over. Waiting for reviews, responses from area directors control over. Waiting for reviews, responses from area directors
and chairs, etc can be much harder to speed up. and chairs, etc can be much harder to speed up.
o Failing to take the human nature into account. It happens that o Failing to take the human nature into account. It happens that
people forget or needs to be reminded about tasks. Send people people forget or needs to be reminded about tasks. Send people
you are waiting for a kindly reminder if things takes longer than you are waiting for a kindly reminder if things takes longer than
expected. To avoid annoying people ask for a time estimate from expected. To avoid annoying people ask for a time estimate from
people when they expect to fullfill the requested task. people when they expect to fulfill the requested task.
o Not enough review. It is common that documents take a long time o Not enough review. It is common that documents take a long time
and many iterations because not enough review is performed in each and many iterations because not enough review is performed in each
iteration. To improve the amount of review you get on your own iteration. To improve the amount of review you get on your own
document, trade review time with other document authors. Make a document, trade review time with other document authors. Make a
deal with some other document authors that you will review his deal with some other document authors that you will review his
draft(s) if he reviews yours. Even inexperience reviewers can draft(s) if he reviews yours. Even inexperience reviewers can
help with language, editorial or clarity issues. Try also help with language, editorial or clarity issues. Try also
approaching the more experienced people in the WG and get them to approaching the more experienced people in the WG and get them to
commit to a review. The WG chairs cannot, even if desirable, be commit to a review. The WG chairs cannot, even if desirable, be
skipping to change at page 26, line 7 skipping to change at page 26, line 7
in the process when more fundamental issues easily can be resolved in the process when more fundamental issues easily can be resolved
without abandoning a lot of effort. Then when nearing completion, without abandoning a lot of effort. Then when nearing completion,
but while still possible to update the specification as second review but while still possible to update the specification as second review
should be scheduled. In that pass the quality can be assessed and should be scheduled. In that pass the quality can be assessed and
hopefully no updates are needed. Using this procedure can avoids hopefully no updates are needed. Using this procedure can avoids
both conflicting definitions and serious mistakes, like breaking both conflicting definitions and serious mistakes, like breaking
certain aspects of the RTP model. certain aspects of the RTP model.
RTP payload Media Types may be registered in the standards tree by RTP payload Media Types may be registered in the standards tree by
other standard bodies. The requirements on the organization are other standard bodies. The requirements on the organization are
outlined in the media types registration document (RFC 3555 [RFC3555] outlined in the media types registration document (RFC 4855 [RFC4855]
and RFC 4288 [RFC4288]). This registration requires a request to the and RFC 4288 [RFC4288]). This registration requires a request to the
IESG, which ensures that the registration template is acceptable. To IESG, which ensures that the registration template is acceptable. To
avoid last minute problems with these registration the registration avoid last minute problems with these registration the registration
template must be sent for review both to the AVT WG and the media template must be sent for review both to the AVT WG and the media
types list (ietf-types@iana.org) and is something that should be types list (ietf-types@iana.org) and is something that should be
included in the IETF reviews of the payload format specification. included in the IETF reviews of the payload format specification.
Registration of the RTP payload name is something that is required to Registration of the RTP payload name is something that is required to
avoid name collision in the future. Do also note that "x-" names are avoid name collision in the future. Do also note that "x-" names are
not suitable for any documented format as they have the same problem not suitable for any documented format as they have the same problem
skipping to change at page 27, line 14 skipping to change at page 27, line 14
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:
To many configurations: Contradicting requirements results in that Too many configurations: Contradicting requirements results in that
one configuration for each conceivable case is created. Such one configuration for each conceivable case is created. Such
contradicting requirements are often between functionality and contradicting requirements are often between functionality and
bandwidth. This has two big negatives. First all configurations bandwidth. This has two big negatives. First all configurations
needs to be implemented. Secondly the using application must needs to be implemented. Secondly the using application must
select the most suitable configuration. Selecting the best select the most suitable configuration. Selecting the best
configuration can be very difficult and in negotiating configuration can be very difficult and in negotiating
applications, this can create interoperability problems. The applications, this can create interoperability problems. The
recommendation is to try to select a very limited (preferable one) recommendation is to try to select a very limited (preferable one)
configuration that preforms the most common case well and is configuration that preforms the most common case well and is
capable of handling the other cases, but maybe less well. capable of handling the other cases, but maybe less well.
Hard to implement: Certain payload formats may become difficult to Hard to implement: Certain payload formats may become difficult to
implement both correctly and efficient. This needs to be implement both correctly and efficient. This needs to be
considered in the design. considered in the design.
Interaction with general mechanisms: Special solutions may create Interaction with general mechanisms: Special solutions may create
issues with deployed tools for RTP, like robustification tools. issues with deployed tools for RTP, like tools for robuster
For example the requirement of non broken sequence space creates transport of RTP. For example the requirement of non broken
issues with using both payload type switching and interleaving any sequence space creates issues with using both payload type
robustification mechanism within the stream. switching and interleaving any mechanism for media independent
resilience within the stream.
5.1. Features of RTP payload formats 5.1. Features of RTP payload formats
There are number of common features in RTP payload formats. There There are number of common features in RTP payload formats. There
are no general requirement to support these features, instead their are no general requirement to support these features, instead their
applicability must be considered for each payload format. It might applicability must be considered for each payload format. It might
in fact be that certain features are not even applicable. in fact be that certain features are not even applicable.
5.1.1. Aggreagation 5.1.1. Aggregation
Aggregation allows for the inclusion of multiple ADUs within the same Aggregation allows for the inclusion of multiple ADUs within the same
RTP payload. This is commonly supported for codec that produce ADUs RTP payload. This is commonly supported for codec that produce ADUs
of sizes smaller than the IP MTU. Do remember that the MTU may be 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. 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 support should be considered. An RTP Payload format may always fall
fallback on IP fragmentation, however as discussed in RFC 2736 this back on IP fragmentation, however as discussed in RFC 2736 this have
have some drawbacks. The usage of RTP payload format level some drawbacks. The usage of RTP payload format level fragmentation,
fragmentation, does primarily allow for more efficient usage of RTP does primarily allow for more efficient usage of RTP packet loss
packet loss recovery mechanisms. However it may in some cases also recovery mechanisms. However it may in some cases also allow usage
allow usage of the partial ADU by doing media specific fragmentation of the partial ADU by doing media specific fragmentation at media
at media specific boundaries. specific boundaries.
5.1.3. Interleaving and Transmission Re-Scheduling 5.1.3. Interleaving and Transmission Re-Scheduling
Interleaving has been implemented in a number of payload formats to Interleaving has been implemented in a number of payload formats to
allow for less quality reduction when packet loss occurs. When allow for less quality reduction when packet loss occurs. When
losses are bursty and several consecutive packets are lost, the losses are bursty and several consecutive packets are lost, the
impact on quality can be quite severe. Interleaving is used to impact on quality can be quite severe. Interleaving is used to
convert that burst loss to several spread out individual losses. It convert that burst loss to several spread out individual losses. It
can also be used when several ADUs are aggregated in the same 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 packets. A loss of an RTP packet with several ADUs in the payload
skipping to change at page 29, line 15 skipping to change at page 29, line 16
difficult to indicate when a receiver may start consume data and difficult to indicate when a receiver may start consume data and
still avoid buffer underrun caused by the interleaving mechanism still avoid buffer underrun caused by the interleaving mechanism
itself. The transmission re-scheduling is only useful in a few itself. The transmission re-scheduling is only useful in a few
specific cases, like in streaming with retransmissions. This must be specific cases, like in streaming with retransmissions. This must be
weighted against the complexity of these schemes. weighted against the complexity of these schemes.
5.1.4. Media Back Channels 5.1.4. Media Back Channels
A few RTP payload format have implemented back channels within the A few RTP payload format have implemented back channels within the
media format. Those have been for specific features, like the AMR media format. Those have been for specific features, like the AMR
[RFC3267] 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.
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 [RFC3267], AMR-WB [RFC3267], 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 contens 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.
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 that a note will be stuck
in an on state. To counter this a recovery journal is defined that
provides a summarized state that allows the receiver to recover from
packet losses quickly. It also uses RTCP and the reported highest
sequence number to be able to prune the state the recovery journal
needs to contain. These features appears limited in applicability
for media formats that are highly stateful and primarily uses
symbolic media representations.
6.2. Video 6.2. Video
To be written To be written
6.3. Text 6.3. Text
To be written To be written
7. Important Specification Sections 7. Important Specification Sections
skipping to change at page 34, line 16 skipping to change at page 34, line 16
This document currently has a few open issues that needs resolving This document currently has a few open issues that needs resolving
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 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
skipping to change at page 37, line 10 skipping to change at page 38, line 5
intended to be RFCs there is no direct security considerations. intended to be RFCs there is no direct security considerations.
However the document does discuss the writing of security However the document does discuss the writing of security
consideration sections and what should be particular considered when consideration sections and what should be particular considered when
specifying RTP payload formats. specifying RTP payload formats.
12. RFC Editor Consideration 12. RFC Editor Consideration
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.
Please replace all References to RFC XXXX with the RFC number that
the update of RFC 3555 [I-D.ietf-avt-rfc3555bis] receives.
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] [I-D.ietf-avt-profile-savpf]
Ott, J. and E. Carrara, "Extended Secure RTP Profile for Ott, J. and E. Carrara, "Extended Secure RTP Profile for
RTCP-based Feedback (RTP/SAVPF)", RTCP-based Feedback (RTP/SAVPF)",
draft-ietf-avt-profile-savpf-09 (work in progress), draft-ietf-avt-profile-savpf-10 (work in progress),
October 2006. March 2007.
[I-D.ietf-avt-rfc3555bis]
Casner, S., "Media Type Registration of RTP Payload
Formats", draft-ietf-avt-rfc3555bis-05 (work in progress),
October 2006.
[I-D.ietf-simple-message-sessions] [I-D.ietf-simple-message-sessions]
Campbell, B., "The Message Session Relay Protocol", Campbell, B., "The Message Session Relay Protocol",
draft-ietf-simple-message-sessions-18 (work in progress), draft-ietf-simple-message-sessions-19 (work in progress),
December 2006. 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 39, line 47 skipping to change at page 39, line 42
Specification, Implementation", RFC 1305, March 1992. Specification, Implementation", RFC 1305, March 1992.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996. 3", BCP 9, RFC 2026, October 1996.
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, Parisis, "RTP Payload for Redundant Audio Data", RFC 2198,
September 1997. September 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998. Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2360] Scott, G., "Guide for Internet Standards Writers", BCP 22, [RFC2360] Scott, G., "Guide for Internet Standards Writers", BCP 22,
RFC 2360, June 1998. RFC 2360, June 1998.
[RFC2418] Bradner, S., "IETF Working Group Guidelines and [RFC2418] Bradner, S., "IETF Working Group Guidelines and
Procedures", BCP 25, RFC 2418, September 1998. Procedures", BCP 25, RFC 2418, September 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
skipping to change at page 40, line 50 skipping to change at page 40, line 41
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[RFC3267] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie,
"Real-Time Transport Protocol (RTP) Payload Format and
File Storage Format for the Adaptive Multi-Rate (AMR) and
Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs",
RFC 3267, June 2002.
[RFC3285] Gahrns, M. and T. Hain, "Using Microsoft Word to create [RFC3285] Gahrns, M. and T. Hain, "Using Microsoft Word to create
Internet Drafts and RFCs", RFC 3285, May 2002. Internet Drafts and RFCs", RFC 3285, May 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 [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 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 3548, July 2003. 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.
[RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP
Payload Formats", RFC 3555, 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)",
RFC 3558, July 2003. RFC 3558, July 2003.
[RFC3569] Bhattacharyya, S., "An Overview of Source-Specific [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific
Multicast (SSM)", RFC 3569, July 2003. Multicast (SSM)", RFC 3569, July 2003.
[RFC3577] Waldbusser, S., Cole, R., Kalbfleisch, C., and D. [RFC3577] Waldbusser, S., Cole, R., Kalbfleisch, C., and D.
Romascanu, "Introduction to the Remote Monitoring (RMON) Romascanu, "Introduction to the Remote Monitoring (RMON)
Family of MIB Modules", RFC 3577, August 2003. Family of MIB Modules", RFC 3577, August 2003.
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control
Protocol Extended Reports (RTCP XR)", RFC 3611, Protocol Extended Reports (RTCP XR)", RFC 3611,
November 2003. November 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. 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.
[RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, [RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78,
RFC 3978, March 2005. RFC 3978, March 2005.
[RFC3979] Bradner, S., "Intellectual Property Rights in IETF [RFC3979] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3979, March 2005. Technology", BCP 79, RFC 3979, March 2005.
[RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund, [RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund,
M., and D. Singer, "RTP Payload Format for H.264 Video", M., and D. Singer, "RTP Payload Format for H.264 Video",
RFC 3984, February 2005. RFC 3984, February 2005.
skipping to change at page 42, line 39 skipping to change at page 42, line 29
[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.
[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)
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, [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.
[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
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.
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 45, line 46 skipping to change at page 46, line 46
Congestion control for RTP SHALL be used in accordance with RFC 3550 Congestion control for RTP SHALL be used in accordance with RFC 3550
[RFC3550], and with any applicable RTP profile; e.g., RFC 3551 [RFC3550], and with any applicable RTP profile; e.g., RFC 3551
[RFC3551]. An additional requirement if best-effort service is being [RFC3551]. An additional requirement if best-effort service is being
used is: users of this payload format MUST monitor packet loss to used is: users of this payload format MUST monitor packet loss to
ensure that the packet loss rate is within acceptable parameters. ensure that the packet loss rate is within acceptable parameters.
A.11. Payload Format Parameters A.11. Payload Format Parameters
This RTP payload format is identified using the ... media type which This RTP payload format is identified using the ... media type which
is registered in accordance with RFC XXXX [I-D.ietf-avt-rfc3555bis] is registered in accordance with RFC 4855 [RFC4855] and using the
and using the template of RFC 4288 [RFC4288]. template of RFC 4288 [RFC4288].
A.11.1. Media Type Definition A.11.1. Media Type Definition
[Here the media type registration template from RFC 4288 is placed [Here the media type registration template from RFC 4288 is placed
and filled out. This template is provided with some common RTP and filled out. This template is provided with some common RTP
boilerplate.] boilerplate.]
Type name: Type name:
Subtype name: Subtype name:
skipping to change at page 46, line 44 skipping to change at page 47, line 44
Person & email address to contact for further information: Person & email address to contact for further information:
Intended usage: (One of COMMON, LIMITED USE or OBSOLETE.) Intended usage: (One of COMMON, LIMITED USE or OBSOLETE.)
Restrictions on usage: Restrictions on usage:
[The below text is for media types that is only defined for RTP [The below text is for media types that is only defined for RTP
payload formats. There exist certain media types that are defined payload formats. There exist certain media types that are defined
both as RTP payload formats and file transfer. The rules for such both as RTP payload formats and file transfer. The rules for such
types are documented in RFC 3555bis [I-D.ietf-avt-rfc3555bis].] types are documented in RFC 4855 [RFC4855].]
This media type depends on RTP framing, and hence is only defined for This media type depends on RTP framing, and hence is only defined for
transfer via RTP [RFC3550]. Transport within other framing protocols transfer via RTP [RFC3550]. Transport within other framing protocols
is not defined at this time. is not defined at this time.
Author: Author:
Change controller: Change controller:
IETF Audio/Video Transport working group delegated from the IESG. IETF Audio/Video Transport working group delegated from the IESG.
skipping to change at page 47, line 21 skipping to change at page 48, line 21
[From RFC 4288: Some discussion of Macintosh file type codes and [From RFC 4288: Some discussion of Macintosh file type codes and
their purpose can be found in [MACOSFILETYPES]. Additionally, please their purpose can be found in [MACOSFILETYPES]. Additionally, please
refrain from writing "none" or anything similar when no file refrain from writing "none" or anything similar when no file
extension or Macintosh file type is specified, lest "none" be extension or Macintosh file type is specified, lest "none" be
confused with an actual code value.] confused with an actual code value.]
A.11.2. Mapping to SDP A.11.2. Mapping to SDP
The mapping of the above defined payload format media type and its The mapping of the above defined payload format media type and its
parameters SHALL be done according to Section 3 of RFC XXXX parameters SHALL be done according to Section 3 of RFC 4855
[I-D.ietf-avt-rfc3555bis]. [RFC4855].
[More specific rules only need to be included if some parameter does [More specific rules only need to be included if some parameter does
not match these rules.] not match these rules.]
A.11.2.1. Offer/Answer Considerations A.11.2.1. Offer/Answer Considerations
[Here write your offer/answer consideration section, please see [Here write your offer/answer consideration section, please see
Section Section 3.3.2.1 for help.] Section Section 3.3.2.1 for help.]
A.11.2.2. Declarative SDP Considerations A.11.2.2. Declarative SDP Considerations
skipping to change at page 48, line 21 skipping to change at page 49, line 21
payload. A suitable security mechanism for this RTP payload format payload. A suitable security mechanism for this RTP payload format
should provide confidentiality, integrity protection and at least should provide confidentiality, integrity protection and at least
source authentication capable of determining if an RTP packet is from source authentication capable of determining if an RTP packet is from
a member of the RTP session or not. a member of the RTP session or not.
Note that the appropriate mechanism to provide security to RTP and Note that the appropriate mechanism to provide security to RTP and
payloads following this memo may vary. It is dependent on the payloads following this memo may vary. It is dependent on the
application, the transport, and the signalling protocol employed. application, the transport, and the signalling protocol employed.
Therefore a single mechanism is not sufficient, although if suitable Therefore a single mechanism is not sufficient, although if suitable
the usage of SRTP [RFC3711] is recommended. Other mechanism that may the usage of SRTP [RFC3711] is recommended. Other mechanism that may
be used are IPsec [RFC4301] and TLS [RFC2246] (RTP over TCP), but be used are IPsec [RFC4301] and TLS [RFC4346] (RTP over TCP), but
also other alternatives may exist. also other alternatives may exist.
[Fill in here any further potential security threats] [Fill in here any further potential security threats]
A.14. References A.14. References
[References must be classified as either normative or informative and [References must be classified as either normative or informative and
added to the relevant section. References should use descriptive added to the relevant section. References should use descriptive
reference tags.] reference tags.]
skipping to change at page 51, line 7 skipping to change at page 52, 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 Internet Society (2006). Copyright (C) The IETF Trust (2007).
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 AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 50 change blocks. 
113 lines changed or deleted 155 lines changed or added

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