← Back to team overview

rohc team mailing list archive

Re: [Question #229419]: What protocol number should be for RTP header compression


Question #229419 on rohc changed:

    Status: Open => Answered

Didier Barvaux proposed the following answer:

> I'm trying to use ROHC lib to compress RTP headers. It seems I can NOT
> compress RTP headers only because I got the error "skip profile
> 'RTP/Compressor' because it only support IPv4 or IPv6". I have to combine
> RTP/UDP/IP headers together.

Yes, that's right. The RTP profile does not compress RTP headers alone.
The name is a shorcut. The profile compresses IP/UDP/RTP streams in
fact. More especially, it compresses IPv4/UDP/RTP, IPv4/IPv4/UDP/RTP,

> Which protocol number should I use for RTP compressor? If this protocol
> number is set as 17 (for UDP), then RTP headers won't get compressed.
> RTP protocol is not an assigned number.

Yes, that's right again. The RTP protocol is above the UDP protocol, so
the protocol number in the IP header is set to the UDP one (17).
Indentifying one RTP stream among other UDP streams is not an easy task.
It cannot be identified by the UDP ports since the ports are not well-
known but dynamically defined by another control protocol such as SIP.

The ROHC library defines 2 ways to identify RTP streams from other UDP streams:
1/ a fixed list of UDP ports (if the port is in the list, the UDP stream is handled as one RTP stream, be it RTP or not),
2/ a user-defined callback that may parse the packet to be compressed (ie. its IP header, UDP header and UDP payload) and decide whether the UDP packet is a RTP packet or not.

The 2nd option is not available before the 1.6.0 release.

> I found the reason that RTP profile was skipped because the port 1286
> is not in the list of reserved ports for RTP. Looks like there is no a rigid
> definitions of assigned port numbers in RFC3095. So I added this number
> in the rtp port list. The result is not expected. Headers are not
> compressed at all. Can you please look at the log below and see what
> happened?

They seems recognized as RTP. They seems also compressed. What seems
wrong to you?

If you are bothered by the length of the resulting ROHC packet, you
shouldn't. The ROHC compression scheme is designed as described in [1].
The first packets of a stream require more information that next ones.
They may even be larger than the uncompressed packets! Please compress
more IP/UDP/RTP packets of the same stream. You'll see that some bytes
are saved on every packets after a while.


[1] http://rohc-lib.org/wiki/doku.php?id=rohc-protocol#main_principles

You received this question notification because you are a member of ROHC
Team, which is an answer contact for rohc.