Compressed Real Time Transfer Protocol
One of the simplest techniques for reducing delay is to simply send less data. The basic principle is that less data require less time to send. Voice over IP traffic uses the Real-Time Transport Protocol (RTP) as defined by RFC 1890. RTP is a session-layer protocol which rides on top of UDP and provides hooks for real-time streaming applications such as voice and video. The RTP header is 8 bytes and when combined with an 8-byte UDP header and a 20-byte IP header, RTP traffic consumes 40 bytes
Page 65
before the payload is even added. This is significant when compared to the average voice payload of 20 bytes. The 40 bytes of overhead is not significant over LANs, but adds significant delay when transmitted over low-speed serial links. To address this problem, an algorithm for compressing RTP was developed using techniques introduced in RFC 1144—TCP/IP header compression. CRTP takes advantage of the following RTP characteristics:
1. RTP header fields change at a constant rate
2. The IP source and destination address are constant for an RTP session
3. The UDP source and destination ports are constant for an RTP session
4. The RTP synchronization source (SSRC) is constant for an RTP session
Based on the first characteristic, the first-order derivative for the field is a constant, which means the second-order derivative is zero. Using this knowledge, routers can set up shortcuts to eliminate the transmission of certain fields. The receiving router needs to store the original header and the first-order differential for each field. As long as there are no changes to the rate of change of the field (first-order derivative), the receiving router can simply add the stored constant for each in subsequent packets. The sending router also must store both the original header and the first-order differential and continuously calculate the second-order differential on successive packets. As long as the second-order differential remains zero, there is no need to signal the receiving router.
Based on characteristics 2, 3, and 4 there is no need to continually send the same data. These values can be stored in a lookup table and referenced using a hashing function. The hashing function will produce a small integer which can be used in place of the full IP/UDP/RTP headers. The sending router computes this integer and transmits it in place of the normal IP/UDP/RTP header. Upon receipt of a CRTP packet, the router simply runs the integer through the hashing function, which references the associated IP/UDP/RTP header for the session and attaches the full header to the packet for forwarding.
The combination of these functions allows the 40-byte IP/UDP/RTP header to be reduced significantly. The compressed header will be 2 bytes unless UDP checksums are used, in which case it will be 4 bytes. The details of CRTP can be found at
ftp://www.ietf.org/internet-drafts/draft-ietf-avt-crtp-05.txt
Page 66
It is important to remember that CRTP operates on a link-by-link basis only and that both ends must have CRTP enabled to function properly. Cisco allows for the configuration of a passive mode in which the router will compress outgoing packets only after receiving a compressed packet on that interface. Cisco does not recommend using CRTP on serial links running at greater than 2 Mbps. Also, CRTP is restricted to HDLC, PPP, frame relay, and ISDN interfaces.
Continue reading here: Traffic Shaping
Was this article helpful?