draft-ietf-avt-rtp-howto-00.txt   draft-ietf-avt-rtp-howto-01.txt 
Audio Video Transport Working M. Westerlund Audio Video Transport Working M. Westerlund
Group Ericsson Group Ericsson
Expires: November 4, 2006 Intended status: Informational
Expires: June 18, 2007
How to Write an RTP Payload Format How to Write an RTP Payload Format
draft-ietf-avt-rtp-howto-00.txt draft-ietf-avt-rtp-howto-01.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 34 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 November 4, 2006. This Internet-Draft will expire on June 18, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
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
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Preparations . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Recommend Reading . . . . . . . . . . . . . . . . . . . . 7 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. IETF Process and Publication . . . . . . . . . . . . . 7 2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.2. RTP . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Important RTP details . . . . . . . . . . . . . . . . . . 11
3.2.1. The RTP Session . . . . . . . . . . . . . . . . . . . 11
3.2.2. RTP Header . . . . . . . . . . . . . . . . . . . . . . 12
3.2.3. RTP Multiplexing . . . . . . . . . . . . . . . . . . . 13
3.2.4. RTP Synchronization . . . . . . . . . . . . . . . . . 14
3.3. Signalling Aspects . . . . . . . . . . . . . . . . . . . . 15
3.3.1. Media Types . . . . . . . . . . . . . . . . . . . . . 16
3.3.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . 16
3.4. Transport Characteristics . . . . . . . . . . . . . . . . 19
3.4.1. Path MTU . . . . . . . . . . . . . . . . . . . . . . . 19
4. Specification Process . . . . . . . . . . . . . . . . . . . . 20 3. Preparations . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. IETF . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.1. Recommend Reading . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Steps from Idea to Publication . . . . . . . . . . . . 20 3.1.1. IETF Process and Publication . . . . . . . . . . . . . 8
4.1.2. WG meetings . . . . . . . . . . . . . . . . . . . . . 22 3.1.2. RTP . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.3. Draft Naming . . . . . . . . . . . . . . . . . . . . . 22 3.2. Important RTP details . . . . . . . . . . . . . . . . . . 12
4.1.4. How to speed up the process . . . . . . . . . . . . . 22 3.2.1. The RTP Session . . . . . . . . . . . . . . . . . . . 12
4.2. Other Standards bodies . . . . . . . . . . . . . . . . . . 23 3.2.2. RTP Header . . . . . . . . . . . . . . . . . . . . . . 13
4.3. Propreitary and Vendor Specific . . . . . . . . . . . . . 24 3.2.3. RTP Multiplexing . . . . . . . . . . . . . . . . . . . 14
3.2.4. RTP Synchronization . . . . . . . . . . . . . . . . . 15
3.3. Signalling Aspects . . . . . . . . . . . . . . . . . . . . 16
3.3.1. Media Types . . . . . . . . . . . . . . . . . . . . . 17
3.3.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . 18
3.4. Transport Characteristics . . . . . . . . . . . . . . . . 20
3.4.1. Path MTU . . . . . . . . . . . . . . . . . . . . . . . 20
5. Designing Payload Formats . . . . . . . . . . . . . . . . . . 25 4. Specification Process . . . . . . . . . . . . . . . . . . . . 22
5.1. Features of RTP payload formats . . . . . . . . . . . . . 25 4.1. IETF . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1.1. Aggreagation . . . . . . . . . . . . . . . . . . . . . 25 4.1.1. Steps from Idea to Publication . . . . . . . . . . . . 22
5.1.2. Fragmentation . . . . . . . . . . . . . . . . . . . . 26 4.1.2. WG meetings . . . . . . . . . . . . . . . . . . . . . 24
5.1.3. Interleaving and Transmission Re-Scheduling . . . . . 26 4.1.3. Draft Naming . . . . . . . . . . . . . . . . . . . . . 24
5.1.4. Media Back Channels . . . . . . . . . . . . . . . . . 27 4.1.4. How to speed up the process . . . . . . . . . . . . . 24
4.2. Other Standards bodies . . . . . . . . . . . . . . . . . . 25
4.3. Propreitary and Vendor Specific . . . . . . . . . . . . . 26
6. Current Trends in Payload Format Design . . . . . . . . . . . 28 5. Designing Payload Formats . . . . . . . . . . . . . . . . . . 27
6.1. Audio Payloads . . . . . . . . . . . . . . . . . . . . . . 28 5.1. Features of RTP payload formats . . . . . . . . . . . . . 27
6.2. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.1.1. Aggreagation . . . . . . . . . . . . . . . . . . . . . 27
6.3. Text . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.1.2. Fragmentation . . . . . . . . . . . . . . . . . . . . 28
5.1.3. Interleaving and Transmission Re-Scheduling . . . . . 28
5.1.4. Media Back Channels . . . . . . . . . . . . . . . . . 29
6. Current Trends in Payload Format Design . . . . . . . . . . . 30
6.1. Audio Payloads . . . . . . . . . . . . . . . . . . . . . . 30
6.2. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.3. Text . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7. Important Specification Sections . . . . . . . . . . . . . . . 29 7. Important Specification Sections . . . . . . . . . . . . . . . 31
7.1. Security Consideration . . . . . . . . . . . . . . . . . . 29 7.1. Security Consideration . . . . . . . . . . . . . . . . . . 31
7.2. Congestion Control . . . . . . . . . . . . . . . . . . . . 30 7.2. Congestion Control . . . . . . . . . . . . . . . . . . . . 32
7.3. IANA Consideration . . . . . . . . . . . . . . . . . . . . 30 7.3. IANA Consideration . . . . . . . . . . . . . . . . . . . . 32
8. Authoring Tools . . . . . . . . . . . . . . . . . . . . . . . 31 8. Authoring Tools . . . . . . . . . . . . . . . . . . . . . . . 33
8.1. Editing Tools . . . . . . . . . . . . . . . . . . . . . . 31 8.1. Editing Tools . . . . . . . . . . . . . . . . . . . . . . 33
8.2. Verification Tools . . . . . . . . . . . . . . . . . . . . 31 8.2. Verification Tools . . . . . . . . . . . . . . . . . . . . 33
9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 32 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 34
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
11. Security Considerations . . . . . . . . . . . . . . . . . . . 34 11. Security Considerations . . . . . . . . . . . . . . . . . . . 36
12. RFC Editor Consideration . . . . . . . . . . . . . . . . . . . 35 12. RFC Editor Consideration . . . . . . . . . . . . . . . . . . . 37
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38
14. Informative References . . . . . . . . . . . . . . . . . . . . 36 14. Informative References . . . . . . . . . . . . . . . . . . . . 39
Appendix A. RTP Payload Format Template . . . . . . . . . . . . . 40 Appendix A. RTP Payload Format Template . . . . . . . . . . . . . 43
A.1. Title . . . . . . . . . . . . . . . . . . . . . . . . . . 40 A.1. Title . . . . . . . . . . . . . . . . . . . . . . . . . . 43
A.2. Front page boilerplate . . . . . . . . . . . . . . . . . . 40 A.2. Front page boilerplate . . . . . . . . . . . . . . . . . . 43
A.3. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . 41 A.3. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . 44
A.4. Table of Content . . . . . . . . . . . . . . . . . . . . . 41 A.4. Table of Content . . . . . . . . . . . . . . . . . . . . . 44
A.5. Introduction . . . . . . . . . . . . . . . . . . . . . . . 41 A.5. Introduction . . . . . . . . . . . . . . . . . . . . . . . 44
A.6. Conventions, Definitions and Acronyms . . . . . . . . . . 41 A.6. Conventions, Definitions and Acronyms . . . . . . . . . . 44
A.7. Media Format Background . . . . . . . . . . . . . . . . . 41 A.7. Media Format Background . . . . . . . . . . . . . . . . . 44
A.8. Payload format . . . . . . . . . . . . . . . . . . . . . . 41 A.8. Payload format . . . . . . . . . . . . . . . . . . . . . . 44
A.8.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . 41 A.8.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . 45
A.8.2. Payload Header . . . . . . . . . . . . . . . . . . . . 42 A.8.2. Payload Header . . . . . . . . . . . . . . . . . . . . 45
A.8.3. Payload Data . . . . . . . . . . . . . . . . . . . . . 42 A.8.3. Payload Data . . . . . . . . . . . . . . . . . . . . . 45
A.9. Payload Examples . . . . . . . . . . . . . . . . . . . . . 42 A.9. Payload Examples . . . . . . . . . . . . . . . . . . . . . 45
A.10. Congestion Control Considerations . . . . . . . . . . . . 42 A.10. Congestion Control Considerations . . . . . . . . . . . . 45
A.11. Payload Format Parameters . . . . . . . . . . . . . . . . 42 A.11. Payload Format Parameters . . . . . . . . . . . . . . . . 45
A.11.1. Media Type Definition . . . . . . . . . . . . . . . . 42 A.11.1. Media Type Definition . . . . . . . . . . . . . . . . 45
A.11.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . 44 A.11.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . 47
A.12. IANA Considerations . . . . . . . . . . . . . . . . . . . 44 A.12. IANA Considerations . . . . . . . . . . . . . . . . . . . 47
A.13. Securtiy Considerations . . . . . . . . . . . . . . . . . 44 A.13. Securtiy Considerations . . . . . . . . . . . . . . . . . 47
A.14. References . . . . . . . . . . . . . . . . . . . . . . . . 45 A.14. References . . . . . . . . . . . . . . . . . . . . . . . . 48
A.14.1. Normative References . . . . . . . . . . . . . . . . . 45 A.14.1. Normative References . . . . . . . . . . . . . . . . . 48
A.14.2. Informative References . . . . . . . . . . . . . . . . 45 A.14.2. Informative References . . . . . . . . . . . . . . . . 48
A.15. Author Addresses . . . . . . . . . . . . . . . . . . . . . 45 A.15. Author Addresses . . . . . . . . . . . . . . . . . . . . . 48
A.16. IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . 45 A.16. IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . 48
A.17. Copyright Notice . . . . . . . . . . . . . . . . . . . . . 45 A.17. Copyright Notice . . . . . . . . . . . . . . . . . . . . . 49
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 46 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 50
Intellectual Property and Copyright Statements . . . . . . . . . . 47 Intellectual Property and Copyright Statements . . . . . . . . . . 51
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 5, line 13 skipping to change at page 6, line 13
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 or
parts of a media. It is scoped in RTP by the RTP session and a 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 communicating RTP Session: An association among a set of participants
with RTP. The distinguishing feature of an RTP session is that communicating with RTP. The distinguishing feature of an RTP
each maintains a full, separate space of SSRC identifiers. See session is that each maintains a full, separate space of SSRC
also Section3.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.
2.2. Acronyms 2.2. Acronyms
ABNF Augmented Backus-Naur Form ABNF: Augmented Backus-Naur Form
ADU Application Data Unit ADU: Application Data Unit
ALF Application Level Framing ALF: Application Level Framing
ASM Any-Source Multicast ASM: Any-Source Multicast
AVT: Audio Video Transport AVT: Audio Video Transport
BCP Best Current Practice BCP: Best Current Practice
ID: Internet Draft ID: Internet Draft
MTU Maximum Transmission Unit MTU: Maximum Transmission Unit
WG: Working Group WG: Working Group
QoS: Quality of Service QoS: Quality of Service
RFC: Request For Comment RFC: Request For Comment
RTP: Real-time Transport Protocol RTP: Real-time Transport Protocol
RTCP: RTP Control Protocol RTCP: RTP Control Protocol
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 part 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
skipping to change at page 7, line 25 skipping to change at page 8, line 25
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 basically
everything listed below does an author need to be aware of. everything listed below does an author need to be aware of.
3.1.1. IETF Process and Publication 3.1.1. IETF Process and Publication
To understand the IETF process an draft author should start by For newcommers to IETF it is strongly recommended that one reads the
reading RFC 2026 [RFC2026] that describes the standards process of "Tao of the IETF" [RFC4677] that goes through most things that one
IETF. In addition an author needs to understands the IETF rules and needs to know about the IETF. It contains information about history,
rights associated with copyright and IPR documented in BCP 78 organisational structure, how the WG and meetings work and many more
[RFC3978] and BCP 79 [RFC3979]. In RFC 2418 [RFC2418] is the WG details.
process, the relation between the IESG and the WG, and the
responsibilities of WG chairs and participants described. 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
associated with copyright and IPR documented in BCP 78 [RFC3978] and
BCP 79 [RFC3979]. RFC 2418 [RFC2418] describes the WG process, the
relation between the IESG and the WG, and the responsibilities of WG
chairs and participants.
It is important to note that the RFC series 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
of all the features it can be moved to draft standard, and final when of all the features it can be moved to draft standard, and final when
further experience has been gathered it can be moved to Internet further experience has been gathered it can be moved to Internet
standard. As the content of the RFCs are not allowed to be changed, standard. As the content of the RFCs are not allowed to be changed,
skipping to change at page 8, line 5 skipping to change at page 9, line 10
important to both consider the Category field in the header and check important to both consider the Category field in the header and check
if the RFC one is reading or going to reference is the latest and if the RFC one is reading or going to reference is the latest and
valid. One way of checking the current status of an RFC is to use valid. One way of checking the current status of an RFC is to use
the RFC-editor's RFC search engine, which displays the current status the RFC-editor's RFC search engine, which displays the current status
and which if any RFCs that updates or obsolete it. and which if any RFCs that updates or obsolete it.
Before starting to write an draft one should also read the Internet Before starting to write an draft one should also read the Internet
Draft writing guidelines Draft writing guidelines
(http://www.ietf.org/ietf/1id-guidelines.txt), the ID checklist (http://www.ietf.org/ietf/1id-guidelines.txt), the ID checklist
(http://www.ietf.org/ID-Checklist.html) and "Instructions to Request (http://www.ietf.org/ID-Checklist.html) and "Instructions to Request
for Comments (RFC) Authors" [rfc2223bis]. for Comments (RFC) Authors" [I-D.rfc-editor-rfc2223bis]. Another
document that can be useful is the "Guide for Internet Standards
Writers" [RFC2360].
There are also a number of documents to consider in process of There are also a number of documents to consider in process of
writing of drafts intended to become RFCs. These are important when writing of drafts intended to become RFCs. These are important when
writing certain type of text. writing certain type of text.
RFC 2606: When writing examples using DNS names in Internet drafts, RFC 2606: When writing examples using DNS names in Internet drafts,
those name shall be using the example.com, example.net, and those name shall be using the example.com, example.net, and
example.org domains. example.org domains.
RFC 3849: Defines the range of IPv6 unicast addresses (2001:DB8::/32) RFC 3849: Defines the range of IPv6 unicast addresses (2001:
that should be used in any examples. DB8::/32) that should be used in any examples.
RFC 3330: Defines the range of IPv4 unicast addresses reserved for RFC 3330: Defines the range of IPv4 unicast addresses reserved for
documentation and examples: 192.0.2.0/24. documentation and examples: 192.0.2.0/24.
RFC 4234: Augmented Backus-Naur Form (ABNF) is often used when RFC 4234: Augmented Backus-Naur Form (ABNF) is often used when
writing text field specifications. Not that commonly used in RTP writing text field specifications. Not that commonly used in RTP
payload formats but may be useful when defining Media Type payload formats but may be useful when defining Media Type
parameters of some complexity. parameters of some complexity.
3.1.2. RTP 3.1.2. RTP
skipping to change at page 8, line 49 skipping to change at page 10, line 8
loss. loss.
Then it is suitable to learn more about the RTP protocol, by studying Then it is suitable to learn more about the RTP protocol, by studying
the RTP specification RFC 3550 [RFC3550] and the existing profiles. the RTP specification RFC 3550 [RFC3550] and the existing profiles.
As a complement to the standards document there exist a book totally As a complement to the standards document there exist a book totally
dedicated to RTP [CSP-RTP]. There exist several profiles for RTP dedicated to RTP [CSP-RTP]. There exist several profiles for RTP
today, but all are based on the "RTP Profile for Audio and Video today, but all are based on the "RTP Profile for Audio and Video
Conferences with Minimal Control" (RFC 3551) [RFC3551] (abbreviated Conferences with Minimal Control" (RFC 3551) [RFC3551] (abbreviated
AVP). The other profiles that one should known about are Secure RTP AVP). The other profiles that one should known about are Secure RTP
(SAVP) [RFC3711], "Extended RTP Profile for RTCP-based Feedback" (SAVP) [RFC3711], "Extended RTP Profile for RTCP-based Feedback"
[rfc-avpf] and "Extended Secure RTP Profile for RTCP-based Feedback [RFC4585] and "Extended Secure RTP Profile for RTCP-based Feedback
(RTP/SAVPF)" [rfc-savpf]. It is important to understand RTP and the (RTP/SAVPF)" [I-D.ietf-avt-profile-savpf]. It is important to
AVP profile in detail. For the other profiles it is sufficient to understand RTP and the AVP profile in detail. For the other profiles
have an understanding on what functionality they provided and the it is sufficient to have an understanding on what functionality they
limitations they create. provided and the limitations they create.
There has been developed a number of robustness tools for RTP. The There has been developed a number of robustness tools for RTP. The
tools are for different use cases and real-time requirements. tools are for different use cases and real-time requirements.
RFC 2198: The "RTP Payload for Redundant Audio Data" [RFC2198] RFC 2198: The "RTP Payload for Redundant Audio Data" [RFC2198]
provides functionalities to provided redundant copies of audio or provides functionalities to provided redundant copies of audio or
text payloads. These redundant copies are sent together with an text payloads. These redundant copies are sent together with an
primary format in the same RTP payload. This format relies on the primary format in the same RTP payload. This format relies on the
RTP timestamp to determine where data belongs in a sequence and RTP timestamp to determine where data belongs in a sequence and
therefore is usually primarily suitable to be used with audio. therefore is usually primarily suitable to be used with audio.
skipping to change at page 9, line 31 skipping to change at page 10, line 38
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 tolerable applications with
limited amount of RTP packets. limited amount of RTP packets.
RTP Retransmission: The RTP retransmission scheme [rtp-rtx] 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 tolerable as a minimum of a 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 cases when operating on networks with short RTT. certain other cases when operating on networks with short RTT.
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 to configure and retrieve
information about RTP sessions. 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
skipping to change at page 10, line 17 skipping to change at page 11, line 28
RMONMIB: The remote monitoring work group has defined a mechanism RMONMIB: The remote monitoring work group has defined a mechanism
[RFC3577] based on usage of the MIB that can be an alternative to [RFC3577] based on usage of the MIB that can be an alternative to
RTCP XR. RTCP XR.
There has also been developed a number of transport optimizations There has also been developed a number of transport optimizations
that are used in certain environments. They are all intended to be that are used in certain environments. They are all intended to be
transparent and not need special consideration by the RTP payload transparent and not need special consideration by the RTP payload
format writer. Thus they are primarily listed here for informational format writer. Thus they are primarily listed here for informational
reasons and do not require deeper studies. reasons and do not require deeper studies.
RFC 2508: Compressing IP/UDP/RTP headers for slow serial links (CRTP) RFC 2508: Compressing IP/UDP/RTP headers for slow serial links
[RFC2508] is the first IETF developed RTP header compression (CRTP) [RFC2508] is the first IETF developed RTP header
mechanism. It provides quite good compression however it has compression mechanism. It provides quite good compression however
clear performance problems when subject to packet loss between it has clear performance problems when subject to packet loss or
compressor and decompressor. reordering between compressor and decompressor.
RFC 3095: Is the base specification of the robust header compression RFC 3095: Is the base specification of the robust header compression
(ROHC) protocol [RFC3095]. This solution was created as a result (ROHC) protocol [RFC3095]. This solution was created as a result
of CRTP's lack of performance when subject to losses. of CRTP's lack of performance when subject to losses.
RFC 3545: Enhanced compressed RTP (E-CRTP) [RFC3545] was also RFC 3545: Enhanced compressed RTP (E-CRTP) [RFC3545] was developed
developed to provide extensions to CRTP that allows for better to provide extensions to CRTP that allows for better performance
performance over links with long RTTs, packet loss and/or over links with long RTTs, packet loss and/or reordering.
reordering.
RFC 4170: Tunneling Multiplexed Compressed RTP (TCRTP) [RFC4170] is a RFC 4170: Tunneling Multiplexed Compressed RTP (TCRTP) [RFC4170] is
solution that allows header compression within a tunnel carrying a solution that allows header compression within a tunnel carrying
multiple multiplexed RTP flows. This is primarily used in voice multiple multiplexed RTP flows. This is primarily used in voice
trunking. trunking.
There exist a couple of different security mechanisms that may be There exist a couple of different security mechanisms that may be
used with RTP. All generic mechanisms need to be transparent for the used with RTP. All generic mechanisms need to be transparent for the
RTP payload format and nothing that needs special consideration. The RTP payload format and nothing that needs special consideration. The
main reason that there exist different solutions is that different main reason that there exist different solutions is that different
applications have different requirements thus different solutions applications have different requirements thus different solutions
have been developed. The main properties for a RTP security have been developed. The main properties for a RTP security
mechanism are to provide confidentiality for the RTP payload, mechanism are to provide confidentiality for the RTP payload,
skipping to change at page 11, line 13 skipping to change at page 12, line 17
features which will need to be considered when used. features which will need to be considered when used.
RTP Encryption: Section 9 of RFC 3550 describes a mechanism to RTP Encryption: Section 9 of RFC 3550 describes a mechanism to
provide confidentiality of the RTP and RTCP packets, using per provide confidentiality of the RTP and RTCP packets, using per
default DES encryption. It may use other encryption algorithms if default DES encryption. It may use other encryption algorithms if
both end-points agree on it. This mechanism is not recommend due both end-points agree on it. This mechanism is not recommend due
to its weak security properties of the used encryption algorithms. to its weak security properties of the used encryption algorithms.
It also lacks integrity and source authentication mechanisms. It also lacks integrity and source authentication mechanisms.
SRTP: The profile for Secure RTP (SAVP) [RFC3711] and the derived SRTP: The profile for Secure RTP (SAVP) [RFC3711] and the derived
profile (SAVPF [rfc-savpf]) is a solution that provides profile (SAVPF [I-D.ietf-avt-profile-savpf]) is a solution that
confidentiality, integrity protection and partial source provides confidentiality, integrity protection and partial source
authentication. authentication.
IPsec: IPsec may also be used to protect RTP and RTCP packet. IPsec: IPsec [RFC4301] may also be used to protect RTP and RTCP
packet.
TLS: TLS may also be used to provide transport security between two TLS: TLS [RFC4346] may also be used to provide transport security
end-point of the TLS connection for a flow of RTP packets that are between two end-point of the TLS connection for a flow of RTP
framed over TCP. packets that are framed over TCP.
DTLS: Datagram TLS [RFC4347] is an alternative to TLS that allow TLS
to be used over datagrams, like UDP. Thus it has the potential
for being used to protoect RTP over UDP. However the necessary
signalling mechanism for using it that has not yet been developed
in any of the IETF real-time media application signalling
protocols.
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.
3.2.1. The RTP Session 3.2.1. The RTP Session
The definition of the RTP session from RFC 3550 is: The definition of the RTP session from RFC 3550 is:
skipping to change at page 12, line 48 skipping to change at page 14, line 16
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 loose
resolution. resolution.
Sequence number: The sequence number are monotonically increasing and Sequence number: The sequence number are monotonically increasing
set as packets are sent. That property is used in many payload and set as packets are sent. That property is used in many
formats to recover the order of everything from the whole stream payload formats to recover the order of everything from the whole
down to fragments of ADUs and the order they shall be decoded. stream down to fragments of ADUs and the order they shall be
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.
skipping to change at page 15, line 7 skipping to change at page 16, line 24
the host system's uptime can be used for this purpose. The important the host system's uptime can be used for this purpose. The important
factor is that all media streams from a particular source that are factor is that all media streams from a particular source that are
being synchronized uses the same reference clock to derive there being synchronized uses the same reference clock to derive there
relative RTP timestamp time scales. relative RTP timestamp time scales.
In the below Figure (Figure 1) it is depicted how if one receives In the below Figure (Figure 1) it is depicted how if one receives
RTCP Sender Report (SR) packet P1 in one media stream and RTCP SR RTCP Sender Report (SR) packet P1 in one media stream and RTCP SR
packet P2 in the other session, then one can calculate the packet P2 in the other session, then one can calculate the
corresponding RTP timestamp values for any arbitrary point in time T. corresponding RTP timestamp values for any arbitrary point in time T.
However to be able to do that it is also required to know the RTP However to be able to do that it is also required to know the RTP
timestamp rates for each media currently used in the sessions. timestamp rates for each media currently used in the sessions
(preamble)
TS1 --+---------------+-------> TS1 --+---------------+------->
| | | |
P1 | P1 |
| | | |
NTP ---+-----+---------T------> NTP ---+-----+---------T------>
| | | |
P2 | P2 |
| | | |
TS2 ---------+---------+---X--> TS2 ---------+---------+---X-->
(postamble)
Figure 1: RTCP Synchronization Figure 1: RTCP Synchronization
Lets assume that media one uses a RTP Timestamp clock rate of 16000 Lets assume that media 1 uses a RTP Timestamp clock rate of 16 kHz,
Hz, and media 2 a rate of 90 kHz. Then the TS1 and TS2 for point T and media 2 a rate of 90 kHz. Then the TS1 and TS2 for point T can
can be calculated in the following way: TS1(T) = TS1(P1) + 16000 * be calculated in the following way: TS1(T) = TS1(P1) + 16000 *
(NTP(T)-NTP(P1)) and TS2(T) = TS2(P2) + 90000 * (NTP(T)-NTP(P2)). (NTP(T)-NTP(P1)) and TS2(T) = TS2(P2) + 90000 * (NTP(T)-NTP(P2)).
This calculation is useful as it allows to generate a common This calculation is useful as it allows to generate a common
synchronization point for which all time values are provided (TS1(T), synchronization point for which all time values are provided (TS1(T),
TS2(T) and T). So when one like to calculate at which NTP time the TS2(T) and T). So when one like to calculate at which NTP time the
TS present in packet X corresponds to one can do that in the TS present in packet X corresponds to one can do that in the
following way: NTP(X) = NTP(T) + (TS2(X) - TS2(T))/90000. following way: NTP(X) = NTP(T) + (TS2(X) - TS2(T))/90000.
3.3. Signalling Aspects 3.3. Signalling Aspects
RTP payload formats are used in the context of application signalling RTP payload formats are used in the context of application signalling
protocols such as SIP [RFC3261] using SDP [sdp-new] with Offer/Answer protocols such as SIP [RFC3261] using SDP [RFC4566] with Offer/Answer
[RFC3264], RTSP [RFC2326] or SAP [RFC2326]. These examples all uses [RFC3264], RTSP [RFC2326] or SAP [RFC2326]. These examples all uses
SDP to indicate which and how many media streams that are desired to SDP to indicate which and how many media streams that are desired to
be used in the session and their configuration. To be able to be used in the session and their configuration. To be able to
declare or negotiate which media format and RTP payload packetization declare or negotiate which media format and RTP payload packetization
the payload format must be given an identifier. In addition to the the payload format must be given an identifier. In addition to the
identifier many payload formats also have the need to carry further identifier many payload formats also have the need to carry further
configuration information out-of-band in regards to the RTP payloads configuration information out-of-band in regards to the RTP payloads
prior to the media transport session. prior to the media transport session.
The above examples of session establishing protocols all use SDP, The above examples of session establishing protocols all use SDP,
however also other session description formats may be used. For however also other session description formats may be used. For
example there have been discussion on a new Session Description example there have been discussion on a new Session Description
format within IETF (SDP-NG). To prevent locking the usage of RTP to format within IETF (SDP-NG). To prevent locking the usage of RTP to
SDP based out-of-band signalling, the payload formats are identified SDP based out-of-band signalling, the payload formats are identified
using an separate definition format for the identifier and using an separate definition format for the identifier and
parameters. That format is the Media Type. parameters. That format is the Media Type.
3.3.1. Media Types 3.3.1. Media Types
Media types [RFC4288] was originally created for identifying media Media types [RFC4288] was originally created for identifying media
formats included in email. Media types are today also used in HTTP, formats included in email. Media types are today also used in HTTP
MSRP and many other protocols to identify arbitrary content carried [RFC2616], MSRP [I-D.ietf-simple-message-sessions] and many other
within the protocols. Media types also provide a media hierarchy protocols to identify arbitrary content carried within the protocols.
that fits RTP payload formats well. Media type names are two-part Media types also provide a media hierarchy that fits RTP payload
and consist of content type and sub-type separated with a slash, e.g. formats well. Media type names are two-part and consist of content
"audio/PCMA" or "video/h263-2000". It is important to choose the type and sub-type separated with a slash, e.g. "audio/PCMA" or
correct content-type when creating the media type identifying an RTP "video/h263-2000". It is important to choose the correct content-
payload format. However in most cases there is little doubt what type when creating the media type identifying an RTP payload format.
content type the format belongs to. Guidelines for choosing the However in most cases there is little doubt what content type the
correct media type and registration rules are present in RFC 4288 format belongs to. Guidelines for choosing the correct media type
[RFC4288]. The additional rules for media types for RTP payload and registration rules are present in RFC 4288 [RFC4288]. The
formats are present in RFC XXXX. [rfc3555bis] additional rules for media types for RTP payload formats are present
in RFC XXXX [I-D.ietf-avt-rfc3555bis].
Media types are allowed any number of parameters which are divided Media types are allowed any number of parameters which are divided
into two groups, required and optional parameters. They are always into two groups, required and optional parameters. They are always
on the form name=value. There exist no restriction on how the value on the form name=value. There exist no restriction on how the value
is defined from media types perspective, except that parameters must is defined from media types perspective, except that parameters must
have value. However the carrying of media types in SDP etc. has have value. However the carrying of media types in SDP etc. has
resulted in the following restrictions that needs to be followed to resulted in the following restrictions that needs to be followed to
make media types for RTP payload format usable: make media types for RTP payload format usable:
1. Arbitrary binary content in the parameters are allowed but needs 1. Arbitrary binary content in the parameters are allowed but needs
to be encoded so that they can be placed within text based to be encoded so that they can be placed within text based
protocols. Base64 [RFC3548] is recommended, but for shorter protocols. Base64 [RFC3548] is recommended, but for shorter
content BASE16 may be more appropriate as it is simpler to content BASE16 may be more appropriate as it is simpler to
interpret by humans. This needs to be explicitly stated when interpret by humans. This needs to be explicitly stated when
defining a media type parameter with binary content. defining a media type parameter with binary value.
2. The end of the value needs to be easily found when parsing a 2. The end of the value needs to be easily found when parsing a
message. Thus parameter values that are continuous and non message. Thus parameter values that are continuous and non
interrupted by common text separators, such as space and semi- interrupted by common text separators, such as space and semi-
colon are recommended. If that is not possible some type of colon are recommended. If that is not possible some type of
escaping should be used. Usage of <"> is recommended. escaping should be used. Usage of <"> is recommended.
3. A common representation form of the media type and its parameters 3. A common representation form of the media type and its parameters
is on a single line. In those cases the media type is followed is on a single line. In those cases the media type is followed
by a semi-colon separated list of the parameter value pair, e.g. by a semi-colon separated list of the parameter value pair, e.g.
audio/amr octet-align=0; mode-set=0,2,5,7; mode-change-period=2. audio/amr octet-align=0; mode-set=0,2,5,7; mode-change-period=2.
3.3.2. Mapping to SDP 3.3.2. Mapping to SDP
As SDP [sdp-new] 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
YYYY [rfc3555bis]. However this is not sufficient to explain how XXXX [I-D.ietf-avt-rfc3555bis]. However this is not sufficient to
certain parameter shall be interpreted for example in the context of explain how certain parameter shall be interpreted for example in the
Offer/Answer negotiation [RFC3264]. context of 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 21, line 8 skipping to change at page 23, line 8
any serious security risks that needs to be solved. This step is any serious security risks that needs to be solved. This step is
completed when one has a draft that is sufficient detailed for a completed when one has a draft that is sufficient detailed for a
first review by the WG. The less confident one is of the first review by the WG. The less confident one is of the
solution, the less work should be spent on details, instead solution, the less work should be spent on details, instead
concentrate on the codec properties and what is required to make concentrate on the codec properties and what is required to make
it work. it work.
3. Submission of first version. When one has performed the above 3. Submission of first version. When one has performed the above
one submits the draft as an individual draft. This can be done one submits the draft as an individual draft. This can be done
at any time except the 3 weeks (current deadline at the time of at any time except the 3 weeks (current deadline at the time of
writing, consult current announcements) just before an IETF writing, consult current announcements) prior to an IETF meeting.
meeting. When the IETF draft announcement has been sent out on When the IETF draft announcement has been sent out on the draft
the draft announcement list, forward it to the AVT WG and request announcement list, forward it to the AVT WG and request that it
that it is reviewed. In the email outline any issues the authors is reviewed. In the email outline any issues the authors
currently have with the design. currently have with the design.
4. Iterative improvements: Taking the feedback into account one 4. Iterative improvements: Taking the feedback into account one
updates the draft and try resolve any issues. New revision of updates the draft and try resolve any issues. New revision of
the draft can be submitted at any time. It is recommended to do the draft can be submitted at any time. It is recommended to do
it whenever one has made major updates or have new issues that it whenever one has made major updates or have new issues that
are easiest to discuss in the context of a new draft version. are easiest to discuss in the context of a new draft version.
5. Becoming WG document: Due to that the definition of RTP payload 5. Becoming WG document: Due to that the definition of RTP payload
formats are part of the AVT's charter, RTP payload formats that formats are part of the AVT's charter, RTP payload formats that
skipping to change at page 21, line 39 skipping to change at page 23, line 39
AVT WG accepts new RTP payload formats based on their suitability AVT WG accepts new RTP payload formats based on their suitability
and document maturity. The document maturity is a requirement to and document maturity. The document maturity is a requirement to
ensure that there are dedicated document editors and that there ensure that there are dedicated document editors and that there
exist a good solution. exist a good solution.
6. Iterative improvements: The updates and review cycles continues 6. Iterative improvements: The updates and review cycles continues
until the draft the has reached the maturity suitable for until the draft the has reached the maturity suitable for
publication. publication.
7. WG last call: WG last call of at least 2 weeks are always 7. WG last call: WG last call of at least 2 weeks are always
performed for AVT WG documents. The authors request WG last call performed for payload formats in the AVT WG. The authors request
for a draft when they think it i mature enough for publication. WG last call for a draft when they think it i mature enough for
The chairs perform a review to check if they agree with the publication. The chairs perform a review to check if they agree
authors assessment. If the chairs agree on the maturity, the WG with the authors assessment. If the chairs agree on the
last call is announced on the WG mailing list. If there are maturity, the WG last call is announced on the WG mailing list.
issues raised these needs to be addressed with an updated draft If there are issues raised these needs to be addressed with an
version. For any more substantial updates of draft, a new WG updated draft version. For any more substantial updates of
last call is announced for the updated version. Minor changes, draft, a new WG last call is announced for the updated version.
like editorial on can be progressed without an additional WG last Minor changes, like editorial on can be progressed without an
call. additional WG last call.
8. Publication Requested: For WG documents the chairs request 8. Publication Requested: For WG documents the chairs request
publication of the draft. After this the approval and publication of the draft. After this the approval and
publication process described in RFC 2026 [RFC2026] are publication process described in RFC 2026 [RFC2026] are
performed. The status after the publication has been requested performed. The status after the publication has been requested
can be tracked using the IETF data tracker. Documents do not can be tracked using the IETF data tracker. Documents do not
expire as normal after publication has been requested. In expire as normal after publication has been requested. In
addition any submission of document updates requires the approval addition any submission of document updates requires the approval
of WG chair(s). The authors are commonly asked to address of WG chair(s). The authors are commonly asked to address
comments or issues raised by the IESG. The authors also review comments or issues raised by the IESG. The authors also review
skipping to change at page 24, line 11 skipping to change at page 26, line 11
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 3555 [RFC3555]
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 should 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
with name collision and can't be registered. The list of already with name collision and can't be registered. The list of already
registered media types can be found at IANA (http://www.iana.org). registered media types can be found at IANA (http://www.iana.org).
4.3. Propreitary and Vendor Specific 4.3. Propreitary and Vendor Specific
skipping to change at page 24, line 48 skipping to change at page 26, line 48
both one selves and ones partner, as interoperability will much both one selves and ones partner, as interoperability will much
easier to accomplish. easier to accomplish.
o To ensure interoperability between different implementations on o To ensure interoperability between different implementations on
different platforms. different platforms.
To avoid name collisions there is a central register keeping tracks To avoid name collisions there is a central register keeping tracks
of the registered Media Type names used by different RTP payload of the registered Media Type names used by different RTP payload
formats. When it comes to proprietary formats they should be formats. When it comes to proprietary formats they should be
registered in the vendors own tree. All vendor specific registered in the vendors own tree. All vendor specific
registrations uses names that start with "vnd.vendor-name". All registrations uses names that start with "vnd.<vendor-name>". All
names that uses names in the vendors own trees are not required to be names that uses names in the vendors own trees are not required to be
registered with IANA. However registration is recommended if used at registered with IANA. However registration is recommended if used at
all in public environments. all in public environments.
5. Designing Payload Formats 5. Designing Payload Formats
The best summary of payload format design is KISS (Keep It Simple, The best summary of payload format design is KISS (Keep It Simple,
Stupid). A simple payload format makes it easy to review for Stupid). A simple payload format makes it easy to review for
correctness, implement, and have low complexity. Unfortunately correctness, implement, and have low complexity. Unfortunately
contradicting requirements sometime makes it hard to do things contradicting requirements sometime makes it hard to do things
skipping to change at page 26, line 19 skipping to change at page 28, line 19
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
fallback on IP fragmentation, however as discussed in RFC 2736 this fallback on IP fragmentation, however as discussed in RFC 2736 this
have some drawbacks. The usage of RTP payload format level have some drawbacks. The usage of RTP payload format level
fragmentation, does primarily allow for more efficient usage of RTP fragmentation, does primarily allow for more efficient usage of RTP
packet loss recovery mechanisms. packet loss recovery mechanisms. However it may in some cases also
allow usage of the partial ADU by doing media specific fragmentation
at media specific boundaries.
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 and data is allow for less quality reduction when packet loss occurs. When
aggregated. A loss of an RTP packet with several ADUs in the payload losses are bursty and several consecutive packets are lost, the
impact on quality can be quite severe. Interleaving is used to
convert that burst loss to several spread out individual losses. It
can also be used when several ADUs are aggregated in the same
packets. A loss of an RTP packet with several ADUs in the payload
has the same affect as a burst loss if the ADUs would have been has the same affect as a burst loss if the ADUs would have been
transmitted in individual packets. To reduce the burstiness of the transmitted in individual packets. To reduce the burstiness of the
loss, the data present in an aggregated payload may be interleaved, loss, the data present in an aggregated payload may be interleaved,
thus spread the loss over a longer time period. thus spread the loss over a longer time period.
A requirement for doing interleaving within an RTP payload format is A requirement for doing interleaving within an RTP payload format is
the aggregation of multiple ADUs. For formats that don't use the aggregation of multiple ADUs. For formats that don't use
aggregation there is still the possibility to implement an aggregation there is still the possibility to implement an
transmission order re-scheduling mechanism. That have the effect transmission order re-scheduling mechanism. That have the effect
that packets transmitted next to each other originates from different that packets transmitted next to each other originates from different
skipping to change at page 28, line 12 skipping to change at page 30, line 12
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
To be written The AMR [RFC3267], AMR-WB [RFC3267], EVRC [RFC3558], SMV [RFC3558]
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
table of contents entry that indicate the type of the frame and if
additional frames are present. This is quite flexible but produces
unnecessary overhead if the ADU is fixed size and when aggregating
multiple ones they are commonly of the same type. In that case a
solution like that in AMR-WB+ [RFC4352] maybe more suitable.
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 30, line 5 skipping to change at page 32, line 5
significantly from nominal simply by designing a malicious input significantly from nominal simply by designing a malicious input
sequence. If such potential exist this must be expressed in the sequence. If such potential exist this must be expressed in the
security consideration section to make implementers aware of the security consideration section to make implementers aware of the
need to take precautions against such behavior. need to take precautions against such behavior.
2. The inclusion of active content in the media format or its 2. The inclusion of active content in the media format or its
transport. With active content means scripts etc that allows an transport. With active content means scripts etc that allows an
attacker to perform potentially arbitrary operations on the attacker to perform potentially arbitrary operations on the
receiver. Most active content have limited possibility to access receiver. Most active content have limited possibility to access
the system or perform operations outside a protected sandbox. the system or perform operations outside a protected sandbox.
However if active content may be included the potential must be However if active content may be included the potential risk must
noted. It is also strongly recommend that references to any be noted. It is also strongly recommend that references to any
security model applicable for such content is referenced. security model applicable for such content is referenced.
3. Some media formats allows for the carrying of "user data", or 3. Some media formats allows for the carrying of "user data", or
types of data which is not known at the time of the specification types of data which is not known at the time of the specification
of the payload format. Such data may be a security risk and of the payload format. Such data may be a security risk and
should be mentioned. should be mentioned.
Suitable stock text for the security consideration is provided in the Suitable stock text for the security consideration is provided in the
template. However the authors do need to actively consider any template. However the authors do need to actively consider any
security issues from the start. Failure to address these issues is security issues from the start. Failure to address these issues is
skipping to change at page 34, line 10 skipping to change at page 36, line 10
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
11. Security Considerations 11. Security Considerations
As this is an informational document on the writing of drafts As this is an informational document on the writing of drafts
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 for consideration sections and what should be particular considered when
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 Please replace all References to RFC XXXX with the RFC number that
the update of RFC 3555 [rfc3555bis] receives. 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]
Ott, J. and E. Carrara, "Extended Secure RTP Profile for
RTCP-based Feedback (RTP/SAVPF)",
draft-ietf-avt-profile-savpf-09 (work in progress),
October 2006.
[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]
Campbell, B., "The Message Session Relay Protocol",
draft-ietf-simple-message-sessions-18 (work in progress),
December 2006.
[I-D.rfc-editor-rfc2223bis]
Reynolds, J. and R. Braden, "Instructions to Request for
Comments (RFC) Authors", draft-rfc-editor-rfc2223bis-08
(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.
[RFC1305] Mills, D., "Network Time Protocol (Version 3) [RFC1305] Mills, D., "Network Time Protocol (Version 3)
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.
skipping to change at page 36, line 34 skipping to change at page 40, line 5
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", [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. 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,
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
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
Headers for Low-Speed Serial Links", RFC 2508, Headers for Low-Speed Serial Links", RFC 2508,
February 1999. February 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP [RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP
Payload Format Specifications", BCP 36, RFC 2736, Payload Format Specifications", BCP 36, RFC 2736,
December 1999. December 1999.
[RFC2959] Baugher, M., Strahm, B., and I. Suconick, "Real-Time [RFC2959] Baugher, M., Strahm, B., and I. Suconick, "Real-Time
Transport Protocol Management Information Base", RFC 2959, Transport Protocol Management Information Base", RFC 2959,
October 2000. October 2000.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000. Announcement Protocol", RFC 2974, October 2000.
skipping to change at page 37, line 52 skipping to change at page 41, line 29
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 [RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP
Payload Formats", RFC 3555, July 2003. Payload Formats", RFC 3555, July 2003.
[RFC3558] Li, A., "RTP Payload Format for Enhanced Variable Rate
Codecs (EVRC) and Selectable Mode Vocoders (SMV)",
RFC 3558, July 2003.
[RFC3569] Bhattacharyya, S., "An Overview of Source-Specific [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.
skipping to change at page 38, line 44 skipping to change at page 42, line 26
[RFC4175] Gharai, L. and C. Perkins, "RTP Payload Format for [RFC4175] Gharai, L. and C. Perkins, "RTP Payload Format for
Uncompressed Video", RFC 4175, September 2005. Uncompressed Video", RFC 4175, September 2005.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005. Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[rfc-avpf] [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
Joerg, "Extended RTP Profile for RTCP-based Feedback (RTP/ (TLS) Protocol Version 1.1", RFC 4346, April 2006.
AVPF)", August 2004.
[rfc-savpf] [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Joerg, "Extended Secure RTP Profile for RTCP-based Security", RFC 4347, April 2006.
Feedback (RTP/SAVPF)", July 2004.
[rfc2223bis] [RFC4352] Sjoberg, J., Westerlund, M., Lakaniemi, A., and S. Wenger,
Reynolds, K., "Instructions to Request for Comments (RFC) "RTP Payload Format for the Extended Adaptive Multi-Rate
Authors", August 2004. Wideband (AMR-WB+) Audio Codec", RFC 4352, January 2006.
[rfc3555bis] [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Casner, L., "MIME Type Registration of RTP Payload Description Protocol", RFC 4566, July 2006.
Formats", October 2005.
[rtp-rtx] Jose, "RTP Retransmission Payload Format", March 2005. [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
July 2006.
[sdp-new] Perkins, "SDP: Session Description Protocol", July 2005. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006.
[RFC4677] Hoffman, P. and S. Harris, "The Tao of IETF - A Novice's
Guide to the Internet Engineering Task Force", RFC 4677,
September 2006.
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 42, line 12 skipping to change at page 45, line 16
[RTP header usage needs to be defined. The fields that absolutely [RTP header usage needs to be defined. The fields that absolutely
need to be defined are timestamp and marker bit. Further field may need to be defined are timestamp and marker bit. Further field may
be specified if used. All the rest should be left to their RTP be specified if used. All the rest should be left to their RTP
specification definition] specification definition]
The remaining RTP header fields are used as specified in RFC 3550. The remaining RTP header fields are used as specified in RFC 3550.
A.8.2. Payload Header A.8.2. Payload Header
[Define how the payload header if it exist are structured and used.] [Define how the payload header, if it exist, is structured and used.]
A.8.3. Payload Data A.8.3. Payload Data
[The payload data, i.e. what the media codec has produced. Commonly [The payload data, i.e. what the media codec has produced. Commonly
done through reference to media codec specification which defines how done through reference to media codec specification which defines how
the data is structured. Rules for padding may need to be defined to the data is structured. Rules for padding may need to be defined to
bring data to octet alignment.] bring data to octet alignment.]
A.9. Payload Examples A.9. Payload Examples
skipping to change at page 42, line 42 skipping to change at page 45, 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 [rfc3555bis] and using the is registered in accordance with RFC XXXX [I-D.ietf-avt-rfc3555bis]
template of RFC 4288 [RFC4288]. and using the 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 43, line 41 skipping to change at page 46, 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 [rfc3555bis].] types are documented in RFC 3555bis [I-D.ietf-avt-rfc3555bis].]
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 44, line 18 skipping to change at page 47, line 22
[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 XXXX
[rfc3555bis]. [I-D.ietf-avt-rfc3555bis].
[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 44, line 49 skipping to change at page 48, line 4
[See Section Section 7.3 and consider if any of the parameter needs a [See Section Section 7.3 and consider if any of the parameter needs a
registered name space.] registered name space.]
A.13. Securtiy Considerations A.13. Securtiy Considerations
[See Section Section 7.1] [See Section Section 7.1]
RTP packets using the payload format defined in this specification RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the RTP are subject to the security considerations discussed in the RTP
specification [4], and in any applicable RTP profile. The main specification [RFC3550] , and in any applicable RTP profile. The
security considerations for the RTP packet carrying the RTP payload main security considerations for the RTP packet carrying the RTP
format defined within this memo are confidentiality, integrity and payload format defined within this memo are confidentiality,
source authenticity. Confidentiality is achieved by encryption of integrity and source authenticity. Confidentiality is achieved by
the RTP payload. Integrity of the RTP packets through suitable encryption of the RTP payload. Integrity of the RTP packets through
cryptographic integrity protection mechanism. Cryptographic system suitable cryptographic integrity protection mechanism. Cryptographic
may also allow the authentication of the source of the payload. A system may also allow the authentication of the source of the
suitable security mechanism for this RTP payload format should payload. A suitable security mechanism for this RTP payload format
provide confidentiality, integrity protection and at least source should provide confidentiality, integrity protection and at least
authentication capable of determining if an RTP packet is from a source authentication capable of determining if an RTP packet is from
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 [RFC2246] (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]
skipping to change at page 46, line 13 skipping to change at page 50, line 13
[Use the boilerplate from Section 5.4 and 5.5 of BCP 78 [RFC3978].] [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 4048287 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
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
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 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 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
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 47, line 29 skipping to change at page 51, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 77 change blocks. 
227 lines changed or deleted 292 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/