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 of
Show full document text