draft-ietf-avt-rtp-howto-04.txt   draft-ietf-avt-rtp-howto-05.txt 
Audio Video Transport Working M. Westerlund Audio Video Transport Working M. Westerlund
Group Ericsson Group Ericsson
Intended status: Informational Intended status: Informational
Expires: January 12, 2009 Expires: March 15, 2009
How to Write an RTP Payload Format How to Write an RTP Payload Format
draft-ietf-avt-rtp-howto-04 draft-ietf-avt-rtp-howto-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 12, 2009. This Internet-Draft will expire on March 15, 2009.
Abstract Abstract
This document contains information on how to best write an RTP This document contains information on how to best write an RTP
payload format. Reading tips, design practices, and practical tips payload format. Reading tips, design practices, and practical tips
on how to quickly and with good results produce an RTP payload format on how to quickly and with good results produce an RTP payload format
specification. A template is also included with instructions that specification. A template is also included with instructions that
can be used when writing an RTP payload format. can be used when writing an RTP payload format.
Table of Contents Table of Contents
skipping to change at page 2, line 30 skipping to change at page 2, line 30
2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Preparations . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Preparations . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Recommend Reading . . . . . . . . . . . . . . . . . . . . 8 3.1. Recommend Reading . . . . . . . . . . . . . . . . . . . . 8
3.1.1. IETF Process and Publication . . . . . . . . . . . . . 8 3.1.1. IETF Process and Publication . . . . . . . . . . . . . 8
3.1.2. RTP . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.2. RTP . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Important RTP details . . . . . . . . . . . . . . . . . . 13 3.2. Important RTP details . . . . . . . . . . . . . . . . . . 13
3.2.1. The RTP Session . . . . . . . . . . . . . . . . . . . 13 3.2.1. The RTP Session . . . . . . . . . . . . . . . . . . . 13
3.2.2. RTP Header . . . . . . . . . . . . . . . . . . . . . . 14 3.2.2. RTP Header . . . . . . . . . . . . . . . . . . . . . . 14
3.2.3. RTP Multiplexing . . . . . . . . . . . . . . . . . . . 15 3.2.3. RTP Multiplexing . . . . . . . . . . . . . . . . . . . 15
3.2.4. RTP Synchronization . . . . . . . . . . . . . . . . . 15 3.2.4. RTP Synchronization . . . . . . . . . . . . . . . . . 16
3.3. Signalling Aspects . . . . . . . . . . . . . . . . . . . . 17 3.3. Signalling Aspects . . . . . . . . . . . . . . . . . . . . 17
3.3.1. Media Types . . . . . . . . . . . . . . . . . . . . . 17 3.3.1. Media Types . . . . . . . . . . . . . . . . . . . . . 17
3.3.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . 18 3.3.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . 18
3.4. Transport Characteristics . . . . . . . . . . . . . . . . 21 3.4. Transport Characteristics . . . . . . . . . . . . . . . . 21
3.4.1. Path MTU . . . . . . . . . . . . . . . . . . . . . . . 21 3.4.1. Path MTU . . . . . . . . . . . . . . . . . . . . . . . 21
4. Specification Process . . . . . . . . . . . . . . . . . . . . 22 4. Specification Process . . . . . . . . . . . . . . . . . . . . 22
4.1. IETF . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.1. IETF . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.1. Steps from Idea to Publication . . . . . . . . . . . . 22 4.1.1. Steps from Idea to Publication . . . . . . . . . . . . 22
4.1.2. WG meetings . . . . . . . . . . . . . . . . . . . . . 24 4.1.2. WG meetings . . . . . . . . . . . . . . . . . . . . . 24
skipping to change at page 3, line 17 skipping to change at page 3, line 17
6. Current Trends in Payload Format Design . . . . . . . . . . . 31 6. Current Trends in Payload Format Design . . . . . . . . . . . 31
6.1. Audio Payloads . . . . . . . . . . . . . . . . . . . . . . 31 6.1. Audio Payloads . . . . . . . . . . . . . . . . . . . . . . 31
6.2. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 31 6.2. Video . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.3. Text . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 6.3. Text . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
7. Important Specification Sections . . . . . . . . . . . . . . . 33 7. Important Specification Sections . . . . . . . . . . . . . . . 33
7.1. Security Consideration . . . . . . . . . . . . . . . . . . 33 7.1. Security Consideration . . . . . . . . . . . . . . . . . . 33
7.2. Congestion Control . . . . . . . . . . . . . . . . . . . . 34 7.2. Congestion Control . . . . . . . . . . . . . . . . . . . . 34
7.3. IANA Consideration . . . . . . . . . . . . . . . . . . . . 34 7.3. IANA Consideration . . . . . . . . . . . . . . . . . . . . 34
8. Authoring Tools . . . . . . . . . . . . . . . . . . . . . . . 35 8. Authoring Tools . . . . . . . . . . . . . . . . . . . . . . . 36
8.1. Editing Tools . . . . . . . . . . . . . . . . . . . . . . 35 8.1. Editing Tools . . . . . . . . . . . . . . . . . . . . . . 36
8.2. Verification Tools . . . . . . . . . . . . . . . . . . . . 35 8.2. Verification Tools . . . . . . . . . . . . . . . . . . . . 36
9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 36 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 37
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
11. Security Considerations . . . . . . . . . . . . . . . . . . . 38 11. Security Considerations . . . . . . . . . . . . . . . . . . . 39
12. RFC Editor Consideration . . . . . . . . . . . . . . . . . . . 39 12. RFC Editor Consideration . . . . . . . . . . . . . . . . . . . 40
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41
14. Informative References . . . . . . . . . . . . . . . . . . . . 41 14. Informative References . . . . . . . . . . . . . . . . . . . . 42
Appendix A. RTP Payload Format Template . . . . . . . . . . . . . 46 Appendix A. RTP Payload Format Template . . . . . . . . . . . . . 47
A.1. Title . . . . . . . . . . . . . . . . . . . . . . . . . . 46 A.1. Title . . . . . . . . . . . . . . . . . . . . . . . . . . 47
A.2. Front page boilerplate . . . . . . . . . . . . . . . . . . 46 A.2. Front page boilerplate . . . . . . . . . . . . . . . . . . 47
A.3. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . 47 A.3. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . 48
A.4. Table of Content . . . . . . . . . . . . . . . . . . . . . 47 A.4. Table of Content . . . . . . . . . . . . . . . . . . . . . 48
A.5. Introduction . . . . . . . . . . . . . . . . . . . . . . . 47 A.5. Introduction . . . . . . . . . . . . . . . . . . . . . . . 48
A.6. Conventions, Definitions and Acronyms . . . . . . . . . . 47 A.6. Conventions, Definitions and Acronyms . . . . . . . . . . 48
A.7. Media Format Background . . . . . . . . . . . . . . . . . 47 A.7. Media Format Background . . . . . . . . . . . . . . . . . 48
A.8. Payload format . . . . . . . . . . . . . . . . . . . . . . 47 A.8. Payload format . . . . . . . . . . . . . . . . . . . . . . 48
A.8.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . 48 A.8.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . 49
A.8.2. Payload Header . . . . . . . . . . . . . . . . . . . . 48 A.8.2. Payload Header . . . . . . . . . . . . . . . . . . . . 49
A.8.3. Payload Data . . . . . . . . . . . . . . . . . . . . . 48 A.8.3. Payload Data . . . . . . . . . . . . . . . . . . . . . 49
A.9. Payload Examples . . . . . . . . . . . . . . . . . . . . . 48 A.9. Payload Examples . . . . . . . . . . . . . . . . . . . . . 49
A.10. Congestion Control Considerations . . . . . . . . . . . . 48 A.10. Congestion Control Considerations . . . . . . . . . . . . 49
A.11. Payload Format Parameters . . . . . . . . . . . . . . . . 48 A.11. Payload Format Parameters . . . . . . . . . . . . . . . . 49
A.11.1. Media Type Definition . . . . . . . . . . . . . . . . 48 A.11.1. Media Type Definition . . . . . . . . . . . . . . . . 49
A.11.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . 50 A.11.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . 51
A.12. IANA Considerations . . . . . . . . . . . . . . . . . . . 50 A.12. IANA Considerations . . . . . . . . . . . . . . . . . . . 51
A.13. Securtiy Considerations . . . . . . . . . . . . . . . . . 50 A.13. Securtiy Considerations . . . . . . . . . . . . . . . . . 51
A.14. References . . . . . . . . . . . . . . . . . . . . . . . . 51 A.14. References . . . . . . . . . . . . . . . . . . . . . . . . 52
A.14.1. Normative References . . . . . . . . . . . . . . . . . 51 A.14.1. Normative References . . . . . . . . . . . . . . . . . 52
A.14.2. Informative References . . . . . . . . . . . . . . . . 51 A.14.2. Informative References . . . . . . . . . . . . . . . . 52
A.15. Author Addresses . . . . . . . . . . . . . . . . . . . . . 51 A.15. Author Addresses . . . . . . . . . . . . . . . . . . . . . 53
A.16. IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . 51 A.16. IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . 53
A.17. Copyright Notice . . . . . . . . . . . . . . . . . . . . . 52 A.17. Copyright Notice . . . . . . . . . . . . . . . . . . . . . 53
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 53 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 54
Intellectual Property and Copyright Statements . . . . . . . . . . 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 9, line 9 skipping to change at page 9, line 9
that either updates or replaces the old one. Therefore it is that either updates or replaces the old one. Therefore it is
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 the RFC editoral (http://www.ietf.org/ID-Checklist.html) and the RFC editorial
guidelines and procedures [RFC-ED]. Another document that can be guidelines and procedures [RFC-ED]. Another document that can be
useful is the "Guide for Internet Standards Writers" [RFC2360]. 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.
skipping to change at page 10, line 45 skipping to change at page 10, line 45
medium delay tolerant applications with limited amount of RTP medium delay tolerant applications with limited amount of RTP
packets. packets.
RTP Retransmission: The RTP retransmission scheme [RFC4588] is used RTP Retransmission: The RTP retransmission scheme [RFC4588] is used
for semi-reliability of the most important RTP packets in a media for semi-reliability of the most important RTP packets in a media
stream. The scheme is not intended, nor suitable, to provide full stream. The scheme is not intended, nor suitable, to provide full
reliability. It requires the application to be quite delay reliability. It requires the application to be quite delay
tolerant as a minimum of one round-trip time plus processing delay tolerant as a minimum of one round-trip time plus processing delay
is required to perform an retransmission. Thus it is mostly is required to perform an retransmission. Thus it is mostly
suitable for streaming applications but may also be usable in suitable for streaming applications but may also be usable in
certain other cases when operating on networks with short RTT. certain other cases when operating on networks with short round
trip times (RTT).
RTP over TCP: RFC 4571 [RFC4571] defines how one sends RTP and RTCP RTP over TCP: RFC 4571 [RFC4571] defines how one sends RTP and RTCP
packet over conenction oriented transports like TCP. If one uses packet over connection oriented transports like TCP. If one uses
TCP one gets reliability for all packets but loose some of the TCP one gets reliability for all packets but loose some of the
real-time behavior that RTP was designed to provide. Issues with real-time behavior that RTP was designed to provide. Issues with
TCP transport of real-time media include head of line blocking and TCP transport of real-time media include head of line blocking and
wasting resources on retransmission of already late data. TCP is wasting resources on retransmission of already late data. TCP is
also limited to point-to-point connections which further restricts also limited to point-to-point connections which further restricts
its applicability. its applicability.
There has also been discussion and also design of RTP payload There has also been discussion and also design of RTP payload
formats, e.g AMR and AMR-WB[RFC4867], supporting the unequal error formats, e.g AMR and AMR-WB[RFC4867], supporting the unequal error
detection provided by UDP-Lite [RFC3828]. The idea is that by not detection provided by UDP-Lite [RFC3828]. The idea is that by not
having a checksum over part of the RTP payload one can allow bit- having a checksum over part of the RTP payload one can allow bit-
errors from the lower layers. By allowing bit-errors one can errors from the lower layers. By allowing bit-errors one can
increase the efficiency of some link layers, and also avoid increase the efficiency of some link layers, and also avoid
unnecesary discards of data when the payload and media codec could unnecessary discards of data when the payload and media codec could
get at least some utility from the data. The main issue is that one get at least some utility from the data. The main issue is that one
has no idea on the level of bit-errors present in the unprotected has no idea on the level of bit-errors present in the unprotected
part of the payload. Which makes it hard or impossible to determine part of the payload. Which makes it hard or impossible to determine
if one can design something usable or not. Payload format designers if one can design something usable or not. Payload format designers
are recommended against considering features for unequal error are recommended against considering features for unequal error
detection unless very clear requirements exist. detection unless very clear requirements exist.
There also exist some management and monitoring extensions. There also exist some management and monitoring extensions.
RFC 2959: The RTP protocol Management Information Database (MIB) RFC 2959: The RTP protocol Management Information Database (MIB)
skipping to change at page 12, line 44 skipping to change at page 12, line 45
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 [RFC5124]) is a solution that provides profile (SAVPF [RFC5124]) is a solution that provides
confidentiality, integrity protection and partial source confidentiality, integrity protection and partial source
authentication. authentication.
IPsec: IPsec [RFC4301] may also be used to protect RTP and RTCP IPsec: IPsec [RFC4301] may also be used to protect RTP and RTCP
packet. packet.
TLS: TLS [RFC4346] may also be used to provide transport security TLS: TLS [RFC5246] may also be used to provide transport security
between two end-point of the TLS connection for a flow of RTP between two end-point of the TLS connection for a flow of RTP
packets that are framed over TCP. packets that are framed over TCP.
DTLS: Datagram TLS [RFC4347] is an alternative to TLS that allow TLS DTLS: Datagram TLS [RFC4347] is an alternative to TLS that allow TLS
to be used over datagrams, like UDP. Thus it has the potential to be used over datagrams, like UDP. Thus it has the potential
for being used to protect RTP over UDP. However the necessary for being used to protect RTP over UDP. However the necessary
signalling mechanism for using it that has not yet been developed signalling mechanism for using it that has not yet been developed
in any of the IETF real-time media application signalling in any of the IETF real-time media application signalling
protocols. protocols.
skipping to change at page 29, line 49 skipping to change at page 29, line 49
or image size. or image size.
Quality: The perceived quality of the media stream can be improved Quality: The perceived quality of the media stream can be improved
without affecting the temporal or spatial properties of the media. without affecting the temporal or spatial properties of the media.
This is usually done by improving the signal to noise ration This is usually done by improving the signal to noise ration
within the content. within the content.
Codecs that support scalability are at the time of writing this Codecs that support scalability are at the time of writing this
having a bit of revival. It has been realized that getting the need having a bit of revival. It has been realized that getting the need
functionality for the media stream in the RTP framework is quite functionality for the media stream in the RTP framework is quite
challanging. The author hopes to be able to provide some lessons challenging. The author hopes to be able to provide some lessons
from this work in this document in the future. from this work in this document in the future.
5.1.6. High Packet Rates 5.1.6. High Packet Rates
Some media codecs requires high packet rates, and in these cases the Some media codecs requires high packet rates, and in these cases the
RTP sequence number wraps to quickly. As rule of thumd, the sequence RTP sequence number wraps to quickly. As rule of thumb, the sequence
number space must not be possible to wrap in less than 2 minutes (TCP number space must not be possible to wrap in less than 2 minutes (TCP
maximum segement lifetime). If that may occur then the payload maximum segment lifetime). If that may occur then the payload format
format should specify a extended sequence number field to allow the should specify a extended sequence number field to allow the receiver
receiver to determine where a specific payload belongs in the to determine where a specific payload belongs in the sequence also in
sequence also in the face of extensive reordering. The RTP payload the face of extensive reordering. The RTP payload format for
format for uncompressed video [RFC4175] can be used as an example for uncompressed video [RFC4175] can be used as an example for such a
such a field. field.
6. Current Trends in Payload Format Design 6. Current Trends in Payload Format Design
This section provides a few examples of payload formats that is worth This section provides a few examples of payload formats that is worth
noting for good design in general or specific details. noting for good design in general or specific details.
6.1. Audio Payloads 6.1. Audio Payloads
The AMR [RFC4867], AMR-WB [RFC4867], EVRC [RFC3558], SMV [RFC3558] The AMR [RFC4867], AMR-WB [RFC4867], EVRC [RFC3558], SMV [RFC3558]
payload format are all quite similar. They are all for frame based payload format are all quite similar. They are all for frame based
skipping to change at page 32, line 8 skipping to change at page 32, line 8
The definition of RTP payload formats for video has seen an evolution The definition of RTP payload formats for video has seen an evolution
from the early ones such as H.261 towards the latest for VC-1 and from the early ones such as H.261 towards the latest for VC-1 and
H.264. H.264.
The H.264 RTP payload format [RFC3984] can be seen as a smorgasbord The H.264 RTP payload format [RFC3984] can be seen as a smorgasbord
of functionality, some pretty advanced as the interleaving. The of functionality, some pretty advanced as the interleaving. The
reason for this was to ensure that the majority of applications reason for this was to ensure that the majority of applications
considered by the ITU-T and MPEG that can be supported by RTP was considered by the ITU-T and MPEG that can be supported by RTP was
supported. This has created a payload format that rarely is supported. This has created a payload format that rarely is
implemented in its completness. Despite that no major issues with implemented in its completeness. Despite that no major issues with
interoperability has been reported. However, there are common interoperability has been reported. However, there are common
complaints about its complexity. complaints about its complexity.
The RTP payload format for uncompressed video [RFC4175] is basically The RTP payload format for uncompressed video [RFC4175] is basically
required to be mentioned in this context as it contains a special required to be mentioned in this context as it contains a special
feature not commonly seen in RTP payload formats. Due to the high feature not commonly seen in RTP payload formats. Due to the high
bit-rate and thus packet rate of uncompressed video (gigabits rather bit-rate and thus packet rate of uncompressed video (gigabits rather
than megabits) the payload format include a field to extend the RTP than megabits) the payload format include a field to extend the RTP
sequence number as the normal 16-bit one can wrap in below a second. sequence number as the normal 16-bit one can wrap in below a second.
It also specifies a registry of different color sub-sampling that can It also specifies a registry of different color sub-sampling that can
be re-used in other video RTP payload formats. be re-used in other video RTP payload formats.
6.3. Text 6.3. Text
There would be overstating that there exist a trend in text payload There would be overstating that there exist a trend in text payload
formats as only a single format actually carrying a text format has formats as only a single format actually carrying a text format has
been standardized in IETF, namely T.140 [RFC4103]. The 3GPP Timed been standardized in IETF, namely T.140 [RFC4103]. The 3GPP Timed
Text format [RFC4396] could be considered to be text, despite it in Text format [RFC4396] could be considered to be text, despite it in
the end was registered as a video format. This is decorated text, the end was registered as a video format. This is decorated text,
usable for subtitles and other embelishments of video which is why it usable for subtitles and other embellishments of video which is why
ended up being registered as video format. However, it has many of it ended up being registered as video format. However, it has many
the properties that text formats in generally have. of the properties that text formats in generally have.
The RTP payload format for T.140 was designed with high reliability The RTP payload format for T.140 was designed with high reliability
in mind as real-time text commonly are a extremely low-bit rate in mind as real-time text commonly are a extremely low-bit rate
application. Thus, it recommends the use of RFC 2190 with many application. Thus, it recommends the use of RFC 2190 with many
redundancy generations. However, the format failed to provide a text redundancy generations. However, the format failed to provide a text
block specific sequence number and relies instead of the RTP one to block specific sequence number and relies instead of the RTP one to
detection loss. This makes detection of missing text blocks detection loss. This makes detection of missing text blocks
unecessarily difficult and hinders the deployement with other unnecessarily difficult and hinders the deployment with other
robustness mechanisms that would switch the payload type as that may robustness mechanisms that would switch the payload type as that may
result in erronous error marking in the T.140 text stream. result in erroneous error marking in the T.140 text stream.
7. Important Specification Sections 7. Important Specification Sections
There a number of sections in the payload format draft that needs There a number of sections in the payload format draft that needs
some special considerations. These include security and IANA some special considerations. These include security and IANA
considerations. considerations.
7.1. Security Consideration 7.1. Security Consideration
All Internet drafts requires a Security Consideration section. The All Internet drafts requires a Security Consideration section. The
skipping to change at page 34, line 5 skipping to change at page 34, 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 risk must RFC 4855 [RFC4855] has a requirement that this is noted in the
be noted. It is also strongly recommend that references to any media types registration if the payload format contains active
security model applicable for such content is referenced. content or not. If the payload format has active content it is
strongly recommend that references to any security model
applicable for such content is referenced. A boiler plate text
for no is included in the template which must be changed if the
format actual carries active content.
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
blocking approval and publication. blocking approval and publication.
skipping to change at page 40, line 7 skipping to change at page 41, line 7
consideration sections and what should be particular considered when consideration sections and what should be particular considered when
specifying RTP payload formats. specifying RTP payload formats.
12. RFC Editor Consideration 12. RFC Editor Consideration
Note to RFC Editor: This section may be removed after carrying out Note to RFC Editor: This section may be removed after carrying out
all the instructions of this section. all the instructions of this section.
13. Acknowledgements 13. Acknowledgements
The author would like to thank the invididuals that has provied input The author would like to thank the individuals that has provided
to this document. These individuals include: John Lazzaro. input to this document. These individuals include: John Lazzaro.
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.
[MACOSFILETYPES] [MACOSFILETYPES]
Apple Knowledge Base Article Apple Knowledge Base Article
55381<http://www.info.apple.com/kbnum/n55381>, "Mac OS: 55381<http://www.info.apple.com/kbnum/n55381>, "Mac OS:
File Type and Creator Codes, and File Formats", 1993. File Type and Creator Codes, and File Formats", 1993.
skipping to change at page 43, line 44 skipping to change at page 44, line 44
[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.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006. Security", RFC 4347, April 2006.
[RFC4352] Sjoberg, J., Westerlund, M., Lakaniemi, A., and S. Wenger, [RFC4352] Sjoberg, J., Westerlund, M., Lakaniemi, A., and S. Wenger,
"RTP Payload Format for the Extended Adaptive Multi-Rate "RTP Payload Format for the Extended Adaptive Multi-Rate
Wideband (AMR-WB+) Audio Codec", RFC 4352, January 2006. Wideband (AMR-WB+) Audio Codec", RFC 4352, January 2006.
[RFC4396] Rey, J. and Y. Matsui, "RTP Payload Format for 3rd [RFC4396] Rey, J. and Y. Matsui, "RTP Payload Format for 3rd
Generation Partnership Project (3GPP) Timed Text", Generation Partnership Project (3GPP) Timed Text",
RFC 4396, February 2006. RFC 4396, February 2006.
skipping to change at page 46, line 5 skipping to change at page 46, line 7
Correction", RFC 5109, December 2007. Correction", RFC 5109, December 2007.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
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
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
Appendix A. RTP Payload Format Template Appendix A. RTP Payload Format Template
This section contains a template for writing an RTP payload format in This section contains a template for writing an RTP payload format in
form as a Internet draft. Text within [...] are instructions and form as a Internet draft. Text within [...] are instructions and
must be removed. Some text proposals that are included are must be removed. Some text proposals that are included are
conditional. "..." is used to indicate where further text should be conditional. "..." is used to indicate where further text should be
written. written.
A.1. Title A.1. Title
skipping to change at page 47, line 25 skipping to change at page 48, line 25
references are allowed, no use of RFC 2119 language either.] references are allowed, no use of RFC 2119 language either.]
A.4. Table of Content A.4. Table of Content
[All drafts over 15 pages in length must have an Table of Content.] [All drafts over 15 pages in length must have an Table of Content.]
A.5. Introduction A.5. Introduction
[The introduction should provide a background and overview of the [The introduction should provide a background and overview of the
payload formats capabilities. No normative language in this section, payload formats capabilities. No normative language in this section,
i.e. no MUST, SHOULDS etc.] i.e. no MUST, SHOULDs etc.]
A.6. Conventions, Definitions and Acronyms A.6. Conventions, Definitions and Acronyms
[Define conventions, definitions and acronyms used in the document in [Define conventions, definitions and acronyms used in the document in
this section. The most common definition used in RTP Payload formats this section. The most common definition used in RTP Payload formats
are the RFC 2119 definitions of the upper case normative words, e.g. are the RFC 2119 definitions of the upper case normative words, e.g.
MUST and SHOULD.] MUST and SHOULD.]
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
RFC-editor note: RFCXXXX is to be replaced by the RFC number this
specification recieves when published.
A.7. Media Format Background A.7. Media Format Background
[The intention of this section is to enable reviewers and persons to [The intention of this section is to enable reviewers and persons to
get an overview of the capabilities and major properties of the media get an overview of the capabilities and major properties of the media
format. It should be kept short and concise and is not a complete format. It should be kept short and concise and is not a complete
replacement for reading the media format specification.] replacement for reading the media format specification.]
A.8. Payload format A.8. Payload format
[Overview of payload structure] [Overview of payload structure]
skipping to change at page 49, line 21 skipping to change at page 50, line 21
Optional parameters: Optional parameters:
Encoding considerations: Encoding considerations:
This media type is framed and binary, see section 4.8 in RFC4288 This media type is framed and binary, see section 4.8 in RFC4288
[RFC4288]. [RFC4288].
Security considerations: Security considerations:
Please see security consideration in RFCXXXX
Interoperability considerations: Interoperability considerations:
Published specification: Published specification:
Applications that use this media type: Applications that use this media type:
Additional information: Additional information:
Magic number(s): Magic number(s):
skipping to change at page 51, line 21 skipping to change at page 52, line 23
payload. A suitable security mechanism for this RTP payload format payload. A suitable security mechanism for this RTP payload format
should provide confidentiality, integrity protection and at least should provide confidentiality, integrity protection and at least
source authentication capable of determining if an RTP packet is from source authentication capable of determining if an RTP packet is from
a member of the RTP session or not. a member of the RTP session or not.
Note that the appropriate mechanism to provide security to RTP and Note that the appropriate mechanism to provide security to RTP and
payloads following this memo may vary. It is dependent on the payloads following this memo may vary. It is dependent on the
application, the transport, and the signalling protocol employed. application, the transport, and the signalling protocol employed.
Therefore a single mechanism is not sufficient, although if suitable Therefore a single mechanism is not sufficient, although if suitable
the usage of SRTP [RFC3711] is recommended. Other mechanism that may the usage of SRTP [RFC3711] is recommended. Other mechanism that may
be used are IPsec [RFC4301] and TLS [RFC4346] (RTP over TCP), but be used are IPsec [RFC4301] and TLS [RFC5246] (RTP over TCP), but
also other alternatives may exist. also other alternatives may exist.
[Fill in here any further potential security threats] This RTP payload format and its media decoder do not exhibit any
significant non-uniformity in the receiver-side computational
complexity for packet processing, and thus are unlikely to pose a
denial-of-service threat due to the receipt of pathological data.
Nor does the RTP payload format contain any active content.
[The previous paragraph may need editing due to the format breaking
either of the statements. Fill in here any further potential
security threats]
A.14. References A.14. References
[References must be classified as either normative or informative and [References must be classified as either normative or informative and
added to the relevant section. References should use descriptive added to the relevant section. References should use descriptive
reference tags.] reference tags.]
A.14.1. Normative References A.14.1. Normative References
[Normative references are those that are required to be used to [Normative references are those that are required to be used to
 End of changes. 34 change blocks. 
70 lines changed or deleted 88 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/