What is the ROHC protocol?

The RObust Header Compression (ROHC) protocol aims at reducing bandwidth usage on network links with limited capacity or expensive costs, such as mobile networks or satellite links. It defines a lossless compression scheme for network headers. It does not act on the network payload in any way.

The ROHC protocol is able to compress IPv4, IPv6, UDP, UDP-Lite, ESP, RTP and TCP headers of Internet packets.

Table of content:

Main principles

The ROHC protocol compresses only network headers. It leaves the network payload unchanged.

Only headers are compressed

The ROHC protocol takes advantage of the information redundancy in the different headers of:

Intra- and inter-packets redundancy

Redundant information is transmitted in first packets only (and eventually at regular interval of time later on). Next packets contain variable information only, eg. identifiers or sequence numbers. Theses fields are furthermore transmitted in a adequate compressed form to save some more bits. This behaviour is similar to video compression mechanisms that define reference frames, then compute deltas from the last reference frame for every frame.

For better performances, the packets must be classified into streams before being compressed. This is a requirement to take advantage of inter-packet redundancy. The classification algorithm is not defined by the ROHC protocol itself but left to the implementations.

Classification of incoming packets

Once a stream of packets was identified, it is compressed according to the compression profile that fits best. A compression profile defines the way to compress the different fields in the network headers. Several compression profiles are available: Uncompressed, IP-only, IP/UDP, IP/UDP-Lite, IP/ESP, IP/UDP/RTP, IP/UDP-Lite/RTP and IP/TCP.


The ROHC protocol is standardized by the IETF. A Working Group was formed to specify a "common compression protocol platform". Several RFCs were published to define the ROHC framework and a number of compression profiles. The RFCs are listed on the right side of the page.

The IANA is in charge of ROHC protocol identifiers assignments for ROHC profiles.

The IANA also assigned the Internet protocol number 142 to the ROHC protocol.

The IEEE maintains the registry of Ethernet/802.3 protocol identification. The ROHC protocol is registered with value 0x22F1.


A ROHC compressor parses uncompressed packets, associate them to a stream, builds the corresponding ROHC packets and transmits them to its associated ROHC decompressor at the other end of the network link.

A ROHC decompressor parses ROHC packets transmitted by its associated ROHC compressor, decodes the packet fields according to the ROHC algorithms and then builds the corresponding uncompressed packets.

One compressor is associated with only one decompressor. One decompressor is associated with only one compressor.

ROHC compressor/decompressor association

Both the compressor and the decompressor store some information bits for every network stream they handle. This information is called a stream context. The compressor and the decompressor do not store the same data in their context. The compressor uses uses its contexts to associate a received packet to a stream and to detect the fields that change over time. The decompressor uses its contexts to retrieve the fields that are not transmitted in all the packets.

Modes of operation

The ROHC protocol proposes 3 modes of operations:

In U-mode, packets are transmitted in one direction only: from the compressor to the decompressor. This is useful for network links with no or undesirable return path. In order to handle potential decompression errors, the compressor sends periodic refreshes of the stream context to the decompressor.

ROHC Unidirectional mode

The O-mode works the same way as the U-mode. However feedback packets are transmitted by the decompressor on the return path for reporting errors or acknowledging successful decompression to the compressor.

ROHC Bidirectional Optimistic mode

The R-mode makes use feedback information too. However it is stricter than the O-mode for context updates.

ROHC Bidirectional Reliable mode

Both the compressor and the decompressor starts in U-mode. They may then operate a transition to O-mode if a usable return link is available and the decompressor sends to the compressor a positive acknowledgement with O-mode specified. The transition to R-mode is achieved the same way.

Compressor/decompressor states

The notion of compressor/decompressor states is orthogonal to the operational modes. Whatever the mode is, both the compressor and the decompressor work in one of their three states. They are basically finite state machines. Every incoming packet may cause the compressor/decompressor to change its internal state. Every state refers to a defined behaviour and compression level.

The compressor's state machine defines the following three states:

ROHC compressor's states

Transitions between the above states occur when the compressor:

The decompressor's state machine defines the following three states:

ROHC decompressor's states

Transitions between the above states occur when the decompressor:

Packet types

The Uncompressed profile defines the following ROHC packets:

The IP/UDP/RTP profile defines the following ROHC packets:

The IP-only, non-RTP IP/UDP and IP/ESP profiles define the following ROHC packets:

Other profiles may define other packets. Please refers to the related RFCs for more details.

Encoding schemes

The IP-only, IP/UDP, IP/ESP and IP/UDP/RTP profiles uses the following schemes in order to efficiently compress the various header fields:

Least Significant Bits (LSB)
Transmit only the k least significant bits of the field value. Used for header fields that are usually subject to small changes. The decompressor computes the uncompressed value from a reference value and the transmitted bits according to an interpretation interval around the reference value that depends of the field behaviour.
Window-based Least Significant Bits (W-LSB)
LSB algorithm modified to achieve robustness. Indeed the LSB algorithm fails to decode the correct value if the reference value at decompressor is not the same as at compressor. To achieve robustness, a sliding window of the successive reference values is maintained at compressor. The number of k least significant bits to transmit to decompressor is then computed such that no matter which reference value the decompressor uses (if in window) the correct value is decoded.
Scaled RTP Timestamp
A compression scheme defined for the RTP Timestamp (TS). The TS value does not increase by an arbitrary value from packet to packet. It increases by a multiple of some unit that depends on the audio/video sample rate and frame duration. The compressor can therefore transmit only the multiplication factor once the increment unit is known at the decompressor.
Timer-based RTP Timestamp
A scheme that compresses RTP Timestamp (TS) further than the Scaled RTP  Timestamp. If the sampling rate of the source is constant, then the TS value closely approximates a linear function of the time of day. So, by using a local clock the decompressor can obtain an approximation of the scaled TS in the header to be decompressed by considering its arrival time. Some LSB bits of scaled TS are transmitted in the packets to refine the approximation and handle jitter.
Offset IP-ID
A compression scheme dedicated to IPv4 Identification field. The RTP SN increases by one from one packet to another. If the IP-ID behaves similarly, it is more efficient to transmit the offset between the two values instead of the IP-ID itself.
Self-describing variable-length (SDVL)
Not really a compression scheme, SDVL is a field format that transmits values between 0 and 536 870 911 in a minimal number of bytes. Only 1 byte is used for values up to 127, 2 bytes for values up to 16 383… The first bits of the field are used to encode the field length, hence the scheme's name.
List encoding
List encoding is used to transmit in an efficient way different types of lists. They are used for CSRC lists in RTP packets and extension header chains in IP packets.

Other profiles may define other encoding schemes. Please refers to the related RFCs for more details.

A step further…

This page is only an introduction to the ROHC protocol, not a full explanation of every small details. For more information, read the RFCs listed on the right side of the page.

If you speak French, you may also be interested in the following talks about ROHC:

You may ask questions about the ROHC protocol and the ROHC RFCs on the mailing list of the ROHC Working Group at the IETF or on the mailing list of the ROHC library's project.


Next major release: 2.4.0 Git branch roadmap

Current stable release: 2.3.1 download release notes

Previous stable release: 2.2.0 download release notes


ROHC version 1 (standards):

ROHC version 1 (informational):

ROHC version 2 (standards):

ROHC version 2 (informational):

Lower layers:


back to top