Cisco - IOS Technologies - Quality - Compressed Real-Time Transport Protocol

Compressed Real-Time Transport Protocol

RTP is the Internet-standard protocol for the transport of real-time data, including audio and video. The compression algorithm defined in this document draws heavily upon the design of TCP/IP header compression as described in RFC 1144. It can be used for media on demand as well as interactive services such as Internet telephony. RTP consists of a data part and a control part, called RTCP. The data part of RTP is a thin protocol that provides support for applications with real-time properties such as continuous media (for example, audio and video), including timing reconstruction, loss detection, and content identification. RTCP provides support for real-time conferencing of groups of any size within an Internet. This support includes source identification and support for gateways such as audio and video bridges as well as multicast-to-unicast translators. It offers QoS feedback from receivers to the multicast group, as well as support for the synchronization of different media streams.

Compressed Real-Time Transport Protocol, or CRTP, is used on a link-by-link basis to compress the IP/UDP/RTP from 40 bytes to 2–4 bytes most of the time. In a packet voice environment when framing speech samples every 20 milliseconds, this scenario generates a payload of 20 bytes. The total packet size comprises an IP header (20 bytes), a UDP header (8 bytes), and an RTP header (12 bytes) combined with a payload of 20 bytes. It is evident that the size of the header is twice the size of the payload. When generating packets every 20 milliseconds on a slow link, the header consumes a large portion of the bandwidth. To avoid the unnecessary consumption of available bandwidth, CRTP is used on a link-by-link basis. This compression scheme reduces the IP/UDP/RTP header to 2 bytes most of the time when no UDP checksums are being sent, or 4 bytes when UDP checksums are used.

In TCP header compression, the first factor-of-two reduction in data rate comes from the fact that half of the bytes in the IP and TCP headers remain constant over the life of the connection. For RTP header compression, some of the same techniques may be applied. However, the big gain comes from the fact that although several fields change in every packet, the difference from packet to packet is often constant and, therefore, the second-order difference is zero. By maintaining both the uncompressed header and the first-order differences in the session state shared between the compressor and the decompressor, all that must be communicated is an indication that the second-order difference was zero. In that case, the decompressor can reconstruct the original header without any loss of information, simply by adding the first-order differences to the saved, uncompressed header as each compressed packet is received. Just as TCP/IP header compression maintains shared state for multiple, simultaneous TCP connections, this IP/UDP/RTP compression must maintain state for multiple session contexts. A session context is defined by the combination of the IP source and destination addresses, the UDP source and destination ports, and the RTP synchronization source (SSRC) field. A compressor implementation might use a hash function on these fields to index a table of stored session contexts. The compressed packet carries a small integer, called the session context identifier, or CID, to indicate which session context that packet should be interpreted in.

The decompressor can use the CID to index its table of stored session contexts. CRTP can compress the 40 bytes of header down to 2–4 bytes most of the time. At times, the IP/UDP/RTP header cannot be compressed, because of a change in a field that is normally constant. For example, if a particular field (such as the payload type field) changes, then an uncompressed header must be sent. CRTP should be used on any WAN interface where bandwidth is a concern and there is a high portion of RTP traffic. The range of port numbers used in Cisco’s implementation is 16384 plus four times the number of available channels on the device.