As per Relevance of the word practice, we have this rfc below:
Network Working Group M.
Request for Comments: 2736
BCP: 36 C.
Category: Best Current Practice
December 1999
Guidelines for Writers of RTP Payload Format
Status of this
This document specifies an Internet Best Current Practices for
Internet Community, and requests discussion and suggestions
improvements. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document provides general guidelines aimed at assisting
authors of RTP Payload Format specifications in deciding on
formats. These guidelines attempt to capture some of the
gained with RTP as it evolved during its development
1.
This document provides general guidelines aimed at assisting
authors of RTP [9] Payload Format specifications in deciding on
formats. These guidelines attempt to capture some of the
gained with RTP as it evolved during its development
The principles outlined in this document are applicable to almost
data types, but are framed in examples of audio and video codecs
clarity
2.
RTP was designed around the concept of Application Level
(ALF), first described by Clark and Tennenhouse [2]. The key
underlying ALF is that there are many different ways an
might be able to cope with misordered or lost packets. These
from ignoring the loss, to re-sending the missing data (either from
buffer or by regenerating it), and to sending new data
supersedes the missing data. The application only has this choice
the transport protocol is dealing with data in "Application
Units" (ADUs). An ADU contains data that can be processed out-of
Handley & Perkins Best Current Practice [Page 1]
RFC 2736 Guidelines for Writers of RTP Payload Formats December 1999
order with respect to other ADUs. Thus the ADU is the minimum
of error recovery
The key property of a transport protocol for ADUs is that each
contains sufficient information to be processed by the
immediately. An example is a video stream, wherein the
video data in an ADU must be capable of being decompressed
of whether previous ADUs have been received. Additionally the
must contain "header" information detailing its position in the
image and the frame from which it came
Although an ADU need not be a packet, there are many applications
which a packet is a natural ADU. Such ALF applications have
great advantage that all packets that are received can be
by the application immediately
RTP was designed around an ALF philosophy. In the context of
stream of RTP data, an RTP packet header provides
information to be able to identify and decode the packet
of whether it was received in order, or whether preceding
have been lost. However, these arguments only hold good if the
payload formats are also designed using an ALF philosophy
Note that this also implies smart, network aware, end-points.
application using RTP should be aware of the limitations of
underlying network, and should adapt its transmission to match
limitations. Our experience is that a smart end-point
can achieve significantly better performance on real IP-
networks than a naive implementation
3. Channel
We identify the following channel characteristics that influence
best-effort transport of RTP over UDP/IP in the Internet
o Packets may be
o Packets may be
o Packets may be reordered in
o Packets will be fragmented if they exceed the MTU of
underlying
The loss characteristics of a link may vary widely over short
intervals
Handley & Perkins Best Current Practice [Page 2]
RFC 2736 Guidelines for Writers of RTP Payload Formats December 1999
Although fragmentation is not a disastrous phenomenon if it is a
occurrence, relying on IP fragmentation is a bad design strategy
it significantly increases the effective loss rate of a network
decreases goodput. This is because if one fragment is lost,
remaining fragments (which have used up bottleneck bandwidth)
then need to be discarded by the receiver. It also puts
load on the routers performing fragmentation and on the end-
re-assembling the fragments
In addition, it is noted that the transit time between two hosts
the Internet will not be constant. This is due to two effects -
jitter caused by being queued behind cross-traffic, and
changes. The former is possible to characterise and compensate
by using a playout buffer, but the latter is impossible to
and difficult to accommodate gracefully
4.
We identify the following requirements of RTP payload
specifications
+ A payload format should be devised so that the stream
transported is still useful even in the presence of a
amount of packet loss
+ Ideally all the contents of every packet should be possible to
decoded and played out irrespective of whether preceding
have been lost or arrive late
The first of these requirements is based on the nature of
Internet. Although it may be possible to engineer parts of
Internet to produce low loss rates through careful provisioning
the use of non-best-effort services, as a rule payload formats
not be designed for these special purpose environments.
formats should be designed to be used in the public Internet
best effort service, and thus should expect to see moderate
rates. For example, a 5% loss rate is not uncommon. We note
TCP steady state models [3][4][6] indicate that a 5% loss rate with
1KByte packet size and 200ms round-trip time will result in
achieving a throughput of around 180Kbit/s. Higher loss rates
smaller packet sizes, or a larger RTT are required to constrain
to lower data rates. For the most part, it is such TCP traffic
is producing the background loss that many RTP flows must co-
with. Without explicit congestion notification (ECN) [8], loss
be considered an intrinsic property of best-effort parts of
Internet
Handley & Perkins Best Current Practice [Page 3]
RFC 2736 Guidelines for Writers of RTP Payload Formats December 1999
When payload formats do not assume packet loss will occur,
should state this explicitly up front, and they will be
special purpose payload formats, unsuitable for use on the
Internet without special support from the network infrastructure
The second of these requirements is more explicit about how
should cope with loss. If an RTP payload format is
designed, every packet that is actually received should be useful
Typically this implies the following guidelines are adhered to
+ Packet boundaries should coincide with codec frame boundaries
Thus a packet should normally consist of one or more
codec frames
+ A codec's minimum unit of data should never be packetised so
it crosses a packet boundary unless it is larger than the MTU
+ If a codec's frame size is larger than the MTU, the payload
must not rely on IP fragmentation. Instead it must define its
fragmentation mechanism. Such mechanisms may involve codec
specific information that allows decoding of fragments
Alternatively they might allow codec-independent packet-
forward error correction [5] to be applied that cannot be
with IP-level fragmentation
In the abstract, a codec frame (i.e., the ADU or the minimum
unit that has semantic meaning when handed to the codec) can be
arbitrary size. For PCM audio, it is one byte. For GSM audio,
frame corresponds to 20ms of audio. For H.261 video, it is a
of Blocks (GOB), or one twelfth of a CIF video frame
For PCM, it does not matter how audio is packetised, as the ADU
is one byte. For GSM audio, arbitrary packetisation would split
20ms frame over two packets, which would mean that if one packet
lost, partial frames in packets before and after the loss
meaningless. This means that not only were the bits in the
packet lost, but also that additional bits in neighboring
that used bottleneck bandwidth were effectively also lost because
receiver must throw them away. Instead, we would packetise GSM
including several complete GSM frames in a packet; typically four
frames are included in current implementations. Thus every
received can be decoded because even in the presence of loss,
incomplete frames are received
The H.261 specification allows GOBs to be up to 3KBytes long
although most of the time they are smaller than this. It might
thought that we should insert a group of blocks into a packet when
fits, and arbitrarily split the GOB over two or more packets when
Handley & Perkins Best Current Practice [Page 4]
RFC 2736 Guidelines for Writers of RTP Payload Formats December 1999
GOB is large. In the first version of the H.261 payload format,
is what was done. However, this still means that there
circumstances where H.261 packets arrive at the receiver and must
discarded because other packets were lost - a loss multiplier
that we wish to avoid. In fact there are smaller units than GOBs
the H.261 bit-stream called macroblocks, but they are
identifiable without parsing from the start of the GOB. However,
we provide a little additional information at the start of
packet, we can reinstate information that would normally be found
parsing from the start of the GOB, and we can packetise H.261
splitting the data stream on macroblock boundaries. This is a
obvious packetisation for H.261 than the GOB packetisation, but
does mean that a slightly smarter depacketiser at the receiver
reconstruct a valid H.261 bitstream from a stream of RTP packets
has experienced loss, and not have to discard any of the data
arrived
An additional guideline concerns codecs that require the
state machine to keep step with the encoder state machine.
audio codecs such as LPC or GSM are of this form. Typically they
loss tolerant, in that after a loss, the predictor
decay, so that after a certain amount of time, the predictor
induced by the loss will disappear. Most codecs designed
telephony services are of this form because they were designed
cope with bit errors without the decoder predictor state
remaining incorrect. Just packetising these formats so that
consist of integer multiples of codec frames may not be optimal,
although the packet received immediately after a packet loss can
decoded, the start of the audio stream produced will be
(and hence distort the signal) because the decoder predictor is
out of step with the encoder. In principle, all of the decoder'
internal state could be added using a header attached to the start
every packet, but for lower bit-rate encodings, this state is
substantial that the bit rate is no longer low. However,
compromise can usually be found, where a greatly reduced form
decoder state is sent in every packet, which does not recreate
encoders predictor precisely, but does reduce the magnitude
duration of the distortion produced when the previous packet is lost
Such compressed state is, by definition, very dependent on the
in question. Thus we recommend
+ Payload formats for encodings where the decoder contains
data-driven state that attempts to track encoder state
normally consider including a small additional header that
the most critical elements of this state to reduce
after packet loss
Handley & Perkins Best Current Practice [Page 5]
RFC 2736 Guidelines for Writers of RTP Payload Formats December 1999
A similar issue arises with codec parameters, and whether or not
should be included in the payload format. An example is with a
that has a choice of huffman tables for compression. The codec
use either huffman table 1 or table 2 for encoding and the
needs to know this information for correct decoding. There are
number of ways in which this kind of information can be conveyed
o Out of band signalling, prior to media transmission
o Out of band signalling, but the parameter can be changed mid
session. This requires synchronization of the change in the
stream
o The change is signaled through a change in the RTP payload
field. This requires mapping the parameter space into
payload type values and signalling this mapping out-of-band
to media transmission
o Including the parameter in the payload format. This allows
adapting the parameter in a robust manner, but makes the
format less efficient
Which mechanism to use depends on the utility of changing
parameter in mid-session to support application layer adaptation
However, using out-of-band signalling to change a parameter in mid
session is generally to be discouraged due to the problem
synchronizing the parameter change with the media stream
4.1. RTP Header
Many RTP payload formats require some additional header
to be carried in addition to that included in the fixed RTP
header. The recommended way of conveying this information is in
payload section of the packet. The RTP header extension should not
used to convey payload specific information ([9], section 5.3)
this is inefficient in its use of bandwidth; requires the
of a new RTP profile or profile extension; and makes it difficult
employ FEC schemes such as, for example, [7]. Use of an RTP
extension is only appropriate for cases where the extension
question applies across a wide range of payload types
4.2. Header
Designers of payload formats should also be aware of the needs of
header compression [1]. In particular, the compression
functions best when the RTP timestamp increments by a constant
between consecutive packets. Payload formats which rely on
packets out of order, such that the timestamp increment is
Handley & Perkins Best Current Practice [Page 6]
RFC 2736 Guidelines for Writers of RTP Payload Formats December 1999
constant, are likely to compress less well than those which
packets in order. This has most often been an issue when
payload formats for FEC information, although some video codecs
rely on out-of-order transmission of packets at the expense
reduced compression. Although in some cases such out-of-
transmission may be the best solution, payload format designers
encourage to look for alternative solutions where possible
5.
Designing packet formats for RTP is not a trivial task. Typically
detailed knowledge of the codec involved is required to be able
design a format that is resilient to loss, does not introduce
magnification effects due to inappropriate packetisation, and
not introduce unnecessary distortion after a packet loss. We
that considerable effort should be put into designing packet
that are well tailored to the codec in question. Typically
requires a very small amount of processing at the sender
receiver, but the result can be greatly improved quality
operating in typical Internet environments
Designers of new codecs for use with RTP should consider making
output of the codec "naturally packetizable". This implies that
codec should be designed to produce a packet stream, rather than
bit-stream; and that that packet stream contains the minimal
of redundancy necessary to ensure that each packet is
decodable with minimal loss of decoder predictor tracking. It
recognised that sacrificing some small amount of bandwidth to
greater robustness to packet loss is often a worthwhile tradeoff
It is hoped that, in the long run, new codecs should be
which can be directly packetised, without the trouble of designing
codec-specific payload format
It is possible to design generic packetisation formats that do
pay attention to the issues described in this document, but
formats are only suitable for special purpose networks where
loss can be avoided by careful engineering at the network layer,
are not suited to current best-effort networks
6. Security
The guidelines in this document result in RTP payload formats
are robust in the presence of real world network conditions
Designing payload formats for special purpose networks that
negligable loss rates will normally result in slightly
compression, but produce formats that are more fragile,
rendering them easier targets for denial-of-service attacks
Handley & Perkins Best Current Practice [Page 7]
RFC 2736 Guidelines for Writers of RTP Payload Formats December 1999
Designers of payload formats should pay close attention to
security issues that might arise from poor implementations of
formats, and should be careful to specify the correct behaviour
anomalous conditions arise. Examples include how to process
field values, and conditions when there are mismatches between
fields and actual data. Whilst the correct action will normally
to discard the packet, possible such conditions should be brought
the attention of the implementor to ensure that they are
properly
The RTP specification covers encryption of the payload. This
should not normally be dealt with by payload formats themselves
However, certain payload formats spread information about
particular application data unit over a number of packets, or rely
packets which relate to a number of application data units. Care
be taken when changing the encryption of such streams, since
payload formats may constrain the places in a stream where it
possible to change the encryption key without exposing
data
Designers of payload formats which include FEC should be aware
the automatic addition of FEC in response to packet loss may
network congestion, leading to a worsening of the problem which
use of FEC was intended to solve. Since this may, at its worst
constitute a denial of service attack, designers of such
formats should take care that appropriate safeguards are in place
prevent abuse
Authors'
Mark
AT&T Center for Internet Research at ICSI
International Computer Science Institute
1947 Center Street, Suite 600,
Berkeley, CA 94704,
EMail: mjh@aciri.
Colin
Dept of Computer Science
University College London
Gower Street
London WC1E 6BT, UK
EMail: C.Perkins@cs.ucl.ac.
Handley & Perkins Best Current Practice [Page 8]
RFC 2736 Guidelines for Writers of RTP Payload Formats December 1999
This document is based on experience gained over several years
many people, including Van Jacobson, Steve McCanne, Steve Casner
Henning Schulzrinne, Thierry Turletti, Jonathan Rosenberg
Christian Huitema amongst others
[1] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers
Low-Speed Serial Links", RFC 2508, February 1999.
[2] D. Clark and D. Tennenhouse, "Architectural Considerations
a New Generation of Network Protocols" Proc ACM Sigcomm 90.
[3] J. Mahdavi and S. Floyd. "TCP-friendly unicast rate-based
control". Note sent to end2end-interest mailing list, Jan 1997.
[4] M. Mathis, J. Semske, J. Mahdavi, and T. Ott. "The macro-
behavior of the TCP congestion avoidance algorithm".
Communication Review, 27(3), July 1997.
[5] J. Nonnenmacher, E. Biersack, Don Towsley, "Parity-Based
Recovery for Reliable Multicast Transmission", Proc ACM
[6] J. Padhye, V. Firoiu, D. Towsley, J. Kurose, "Modeling
Throughput: A Simple Model and its Empirical Validation", Proc
ACM Sigcomm 1998.
[7] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M.,
Bolot, J.C., Vega-Garcia, A. and S. Fosse-Parisis, "RTP
for Redundant Audio Data", RFC 2198, September 1997.
[8] Ramakrishnan, K. and S. Floyd, "A Proposal to add
Congestion Notification (ECN) to IP", RFC 2481, January 1999.
[9] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson
"Real-Time Transport Protocol", RFC 1889, January 1996.
Handley & Perkins Best Current Practice [Page 9]
RFC 2736 Guidelines for Writers of RTP Payload Formats December 1999
Full Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Handley & Perkins Best Current Practice [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
