Cisco Cisco IOS Software Release 12.0(33)S

If you try to change the encapsulation on FR interface with IPHC configured to encapsulation on 
which IPHC is not supported, IPHC configurations will be removed from the FR subinterfaces.

If interface level IPHC configuration is done before enabling IPHC at slot level, IPHC will remain 
disabled at interface level and will be enabled only after IHPC at slot level configurations are 
successful.

CISCO/Original IP Header Compression format does not support negotiation of IPHC parameters 
(like max-header size/compression-connections/max-period etc.) between peer interfaces 
(connected back to back). So the user should make sure that IPHC configuration parameters match 
on both sides for the feature to work correctly.

FRF.20 is not supported currently on Cisco 12000 Series Router.

MLFR, IETF FR, and IETF SNAP encapsulation format do not support IPHC Over FR.

Cisco 12000 Series Routers do not support TCP compression, but supports cTCP packets 
decompression as the peer devices can send compressed TCP packets.

The real-time transport protocol, RTP, as described in RFC 1889, is used to carry real-time data for voice 
and video applications. For a typical VoIP application, the payload portion of the packet can be much 
smaller than the headers. For example, using the G.729 Codec, the payload is 20 bytes but the IP/ 
UDP/RTP header is 40 bytes. It is inefficient to send the IP/UDP/RTP header on a slow link without 
compressing it. The IPHC feature addresses this inefficiency. The basic idea behind IPHC is that 
although several fields in the IP/ UDP/RTP header change from packet to packet, typically, the difference 
in these fields from packet to packet is constant. The compression scheme capitalizes on this 
characteristic. RFC 2508 describes the function of IPHC.

Following steps provide details for compressing, decompressing, and reconstructing an original packet:

When a new flow (like a VoIP phone conversation) is established over a link with IPHC enabled, the 
device at the transmitting end (compressor) sends a full header (FH) packet followed by compressed 
packets to the receiving end (decompressor). 

The compressor and the decompressor maintain a copy of the uncompressed header and the 
difference between the previous packet and the current packet. This data is referred to as the session 
state and is identified by a session context ID. 

The context ID is added to the packet payload as it is compressed. 

When the decompressor receives the compressed packet, it can completely reconstruct the packet 
header by adding the saved first-order difference to the saved uncompressed header. 

In a typical case, the IPHC algorithm enables the IP/UDP/RTP header to be compressed to two bytes 
(four bytes if UDP checksums are being sent).

This section explains the following procedures:

 (required)

 (required)

 (optional)