Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering
RFC 3545
Document | Type | RFC - Proposed Standard (July 2003; No errata) | |
---|---|---|---|
Authors | Patrick Ruddy , Bruce Thompson , Stephen Casner , Thima Koren , John Geevarghese | ||
Last updated | 2013-03-02 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3545 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Allison Mankin | ||
IESG note | 07 was Last Called - it had clarification fixes. | ||
Send notices to | <csp@csperkins.org>, <magnus.westerlund@ericsson.com> |
Network Working Group T. Koren Request for Comments: 3545 Cisco Systems Category: Standards Track S. Casner Packet Design J. Geevarghese Motorola India Electronics Ltd. B. Thompson P. Ruddy Cisco Systems July 2003 Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document describes a header compression scheme for point to point links with packet loss and long delays. It is based on Compressed Real-time Transport Protocol (CRTP), the IP/UDP/RTP header compression described in RFC 2508. CRTP does not perform well on such links: packet loss results in context corruption and due to the long delay, many more packets are discarded before the context is repaired. To correct the behavior of CRTP over such links, a few extensions to the protocol are specified here. The extensions aim to reduce context corruption by changing the way the compressor updates the context at the decompressor: updates are repeated and include updates to full and differential context parameters. With these extensions, CRTP performs well over links with packet loss, packet reordering and long delays. Koren, et al. Standards Track [Page 1] RFC 3545 Enhanced Compressed RTP (CRTP) July 2003 Table of Contents 1. Introduction ................................................. 2 1.1. CRTP Operation ......................................... 4 1.2. How do contexts get corrupted? ......................... 4 1.3. Preventing context corruption .......................... 5 1.4. Specification of Requirements .......................... 5 2. Enhanced CRTP ................................................ 5 2.1. Extended COMPRESSED_UDP packet ......................... 6 2.2. CRTP Headers Checksum .................................. 11 2.3. Achieving robust operation ............................. 13 2.3.1. Examples ....................................... 15 3. Negotiating usage of enhanced-CRTP ........................... 18 4. Security Considerations ...................................... 18 5. Acknowledgements ............................................. 19 6. References ................................................... 19 6.1. Normative References ................................... 19 6.2. Informative References ................................. 20 7. Intellectual Property Rights Notice .......................... 20 8. Authors' Addresses ........................................... 21 9. Full Copyright Statement ..................................... 22 1. Introduction RTP header compression (CRTP) as described in RFC 2508 was designed to reduce the header overhead of IP/UDP/RTP datagrams by compressing the three headers. The IP/UDP/RTP headers are compressed to 2-4 bytes most of the time. CRTP was designed for reliable point to point links with short delays. It does not perform well over links with high rate of packet loss, packet reordering and long delays. An example of such a link is a PPP session that is tunneled using an IP level tunneling protocol such as L2TP. Packets within the tunnel are carried by an IP network and hence may get lost and reordered. The longer the tunnel, the longer the round trip time. Another example is an IP network that uses layer 2 technologies such as ATM and Frame Relay for the access portion of the network. Layer 2 transport networks such as ATM and Frame Relay behave like point to point serial links in that they do not reorder packets. In addition, Frame Relay and ATM virtual circuits used as IP access technologies often have a low bit rate associated with them. These virtual circuits differ from low speed serial links in that they may span a larger physical distance than a point to point serial link. Speed ofShow full document text