Guidelines for Writers of RTP Payload Format Specifications
RFC 2736
Document | Type |
RFC - Best Current Practice
(December 1999; No errata)
Updated by RFC 8088
Also known as BCP 36
|
|
---|---|---|---|
Last updated | 2013-03-02 | ||
Stream | IETF | ||
Formats | plain text pdf html bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 2736 (Best Current Practice) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group M. Handley Request for Comments: 2736 ACIRI BCP: 36 C. Perkins Category: Best Current Practice UCL December 1999 Guidelines for Writers of RTP Payload Format Specifications Status of this Memo This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This document provides general guidelines aimed at assisting the authors of RTP Payload Format specifications in deciding on good formats. These guidelines attempt to capture some of the experience gained with RTP as it evolved during its development. 1. Introduction This document provides general guidelines aimed at assisting the authors of RTP [9] Payload Format specifications in deciding on good formats. These guidelines attempt to capture some of the experience gained with RTP as it evolved during its development. The principles outlined in this document are applicable to almost all data types, but are framed in examples of audio and video codecs for clarity. 2. Background RTP was designed around the concept of Application Level Framing (ALF), first described by Clark and Tennenhouse [2]. The key argument underlying ALF is that there are many different ways an application might be able to cope with misordered or lost packets. These range from ignoring the loss, to re-sending the missing data (either from a buffer or by regenerating it), and to sending new data which supersedes the missing data. The application only has this choice if the transport protocol is dealing with data in "Application Data 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 unit of error recovery. The key property of a transport protocol for ADUs is that each ADU contains sufficient information to be processed by the receiver immediately. An example is a video stream, wherein the compressed video data in an ADU must be capable of being decompressed regardless of whether previous ADUs have been received. Additionally the ADU must contain "header" information detailing its position in the video image and the frame from which it came. Although an ADU need not be a packet, there are many applications for which a packet is a natural ADU. Such ALF applications have the great advantage that all packets that are received can be processed by the application immediately. RTP was designed around an ALF philosophy. In the context of a stream of RTP data, an RTP packet header provides sufficient information to be able to identify and decode the packet irrespective of whether it was received in order, or whether preceding packets have been lost. However, these arguments only hold good if the RTP payload formats are also designed using an ALF philosophy. Note that this also implies smart, network aware, end-points. An application using RTP should be aware of the limitations of the underlying network, and should adapt its transmission to match those limitations. Our experience is that a smart end-point implementation can achieve significantly better performance on real IP-based networks than a naive implementation. 3. Channel Characteristics We identify the following channel characteristics that influence the best-effort transport of RTP over UDP/IP in the Internet: o Packets may be lost o Packets may be duplicated o Packets may be reordered in transit o Packets will be fragmented if they exceed the MTU of the underlying network The loss characteristics of a link may vary widely over short time 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 rare occurrence, relying on IP fragmentation is a bad design strategy as it significantly increases the effective loss rate of a network and decreases goodput. This is because if one fragment is lost, the remaining fragments (which have used up bottleneck bandwidth) will then need to be discarded by the receiver. It also puts additional load on the routers performing fragmentation and on the end-systems re-assembling the fragments.Show full document text