draft-ietf-avt-rtp-howto-05.txt   draft-ietf-avt-rtp-howto-06.txt 
Audio Video Transport Working M. Westerlund Audio Video Transport Working M. Westerlund
Group Ericsson Group Ericsson
Intended status: Informational Intended status: Informational
Expires: March 15, 2009 Expires: September 3, 2009
How to Write an RTP Payload Format How to Write an RTP Payload Format
draft-ietf-avt-rtp-howto-05 draft-ietf-avt-rtp-howto-06
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 March 15, 2009. This Internet-Draft will expire on September 3, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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 4, line 8 skipping to change at page 4, line 8
A.10. Congestion Control Considerations . . . . . . . . . . . . 49 A.10. Congestion Control Considerations . . . . . . . . . . . . 49
A.11. Payload Format Parameters . . . . . . . . . . . . . . . . 49 A.11. Payload Format Parameters . . . . . . . . . . . . . . . . 49
A.11.1. Media Type Definition . . . . . . . . . . . . . . . . 49 A.11.1. Media Type Definition . . . . . . . . . . . . . . . . 49
A.11.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . 51 A.11.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . 51
A.12. IANA Considerations . . . . . . . . . . . . . . . . . . . 51 A.12. IANA Considerations . . . . . . . . . . . . . . . . . . . 51
A.13. Securtiy Considerations . . . . . . . . . . . . . . . . . 51 A.13. Securtiy Considerations . . . . . . . . . . . . . . . . . 51
A.14. References . . . . . . . . . . . . . . . . . . . . . . . . 52 A.14. References . . . . . . . . . . . . . . . . . . . . . . . . 52
A.14.1. Normative References . . . . . . . . . . . . . . . . . 52 A.14.1. Normative References . . . . . . . . . . . . . . . . . 52
A.14.2. Informative References . . . . . . . . . . . . . . . . 52 A.14.2. Informative References . . . . . . . . . . . . . . . . 52
A.15. Author Addresses . . . . . . . . . . . . . . . . . . . . . 53 A.15. Author Addresses . . . . . . . . . . . . . . . . . . . . . 53
A.16. IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . 53
A.17. Copyright Notice . . . . . . . . . . . . . . . . . . . . . 53
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 54 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 54
Intellectual Property and Copyright Statements . . . . . . . . . . 55
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 8, line 33 skipping to change at page 8, line 33
3.1.1. IETF Process and Publication 3.1.1. IETF Process and Publication
For newcomers 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 [RFC5378] 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
chairs and participants. chairs and participants.
It is important to note that the RFC series contains documents of It is important to note that the RFC series contains documents of
several different classifications; standards track, informational, several different classifications; standards track, informational,
experimental, best current practice (BCP), and historic. The experimental, best current practice (BCP), and historic. The
standard tracks contains documents of three different maturity standard tracks contains documents of three different maturity
classifications, proposed, draft and Internet Standard. A standards classifications, proposed, draft and Internet Standard. A standards
track document must start as proposed, after proved interoperability track document must start as proposed, after proved interoperability
skipping to change at page 14, line 35 skipping to change at page 14, line 35
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 lose due to RTCP measurements function that in that case lose
resolution. resolution. Also RTP payload formats that has a timestamp
definition which results in that no or little correlation between
the media time instance and its transmission time result in that
the RTCP jitter calculation becomes unusable due to the sender
side introduced errors. It should be noted if the payload format
has this property or not.
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
skipping to change at page 31, line 25 skipping to change at page 31, line 25
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 AMR-WB+ does contain one less good feature which is depending on the
media codec itself. The media codec produces a large range of media codec itself. The media codec produces a large range of
different frame lengths in time perspective. The RTP timestamp rate different frame lengths in time perspective. The RTP timestamp rate
is selected to the very unusual value of 72 kHz despite that output is selected to the very unusual value of 72 kHz despite that output
normally is at sample rate 48kHz. This timestamp rate is the normally is at sample rate of 48kHz. This timestamp rate is the
smallest found value that would make all of the frames the codec smallest found value that would make all of the frames the codec
could produce results in integer frame length in RTP timestamp ticks. could produce results in integer frame length in RTP timestamp ticks.
That way a receiver can always correctly place the frames in relation 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 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 that the decoder output for certain frame lengths are in fact partial
samples. Resulting in that the output in samples from the codec will samples. Resulting in that the output in samples from the codec will
vary from frame to frame, potentially making implementation more vary from frame to frame, potentially making implementation more
difficult. difficult.
The RTP payload format for MIDI [RFC4695] contains some interesting The RTP payload format for MIDI [RFC4695] contains some interesting
skipping to change at page 33, line 18 skipping to change at page 33, line 18
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
security consideration section in an RTP payload format needs to security consideration section in an RTP payload format needs to
concentrate on the security properties this particular format has. concentrate on the security properties this particular format has.
Some payload format has very little specific issues or properties and Some payload format has very little specific issues or properties and
can fully fall back on the general RTP and used profile's security can fully fall back on the general RTP and used profile's security
considerations. Due to that these are always applicable a reference considerations. Due to that these are always applicable, a reference
to these are normally placed first in the security consideration to these are normally placed first in the security consideration
section. section. There is suggested text in the template below.
The security issues of confidentiality, integrity protection and The security issues of confidentiality, integrity protection and
source authentication are common issues for all payload formats. source authentication are common issues for all payload formats.
These should be solved by payload external mechanism and does not These should be solved by payload external mechanism and does not
need any special consideration in the payload format except for an need any special consideration in the payload format except for an
reminder on these issues. A suitable stock text to inform people reminder on these issues. A suitable stock text to inform people
about this is included in the template. about this is included in the template.
Potential security issues with an RTP payload format and the media Potential security issues with an RTP payload format and the media
encoding that needs to be considered are: encoding that needs to be considered are:
skipping to change at page 44, line 18 skipping to change at page 44, line 18
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 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
G. Fairhurst, "The Lightweight User Datagram Protocol G. Fairhurst, "The Lightweight User Datagram Protocol
(UDP-Lite)", RFC 3828, July 2004. (UDP-Lite)", RFC 3828, July 2004.
[RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78,
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.
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text
Conversation", RFC 4103, June 2005. Conversation", RFC 4103, June 2005.
skipping to change at page 47, line 5 skipping to change at page 46, line 8
Real-time Transport Control Protocol (RTCP)-Based Feedback Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, February 2008. (RTP/SAVPF)", RFC 5124, February 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5378] Bradner, S. and J. Contreras, "Rights Contributors Provide
to the IETF Trust", BCP 78, RFC 5378, November 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
[The title shall be descriptive but as compact as possible. RTP is [The title shall be descriptive but as compact as possible. RTP is
allowed and recommended abbreviation in the title] allowed and recommended abbreviation in the title]
RTP Payload format for ... RTP Payload format for ...
A.2. Front page boilerplate A.2. Front page boilerplate
Status of this Memo Status of this Memo
[Insert the IPR notice boiler plate from BCP 79 that applies to this [Insert the IPR notice and copyright boiler plate from BCP 78 and 79
draft.] that applies to this draft.]
[Insert the current Internet Draft document explanation. At the time [Insert the current Internet Draft document explanation. At the time
of publishing it was:] of publishing it was:]
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 53, line 11 skipping to change at page 54, line 5
A.14.2. Informative References A.14.2. Informative References
[All other references.] [All other references.]
A.15. Author Addresses A.15. Author Addresses
[All Authors need to include their Name and email addresses as a [All Authors need to include their Name and email addresses as a
minimal. Commonly also surface mail and possibly phone numbers are minimal. Commonly also surface mail and possibly phone numbers are
included.] included.]
A.16. IPR Notice
[Use the appropriate boilerplate from Section 5 of BCP 79 [RFC3979].]
A.17. Copyright Notice
[Use the boilerplate from Section 5.4 and 5.5 of BCP 78 [RFC3978].]
Author's Address Author's Address
Magnus Westerlund Magnus Westerlund
Ericsson Ericsson
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
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 16 change blocks. 
28 lines changed or deleted 31 lines changed or added

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