← Back to team overview

rohc team mailing list archive

Re: UDP/RTP compression

 

Hello Vikram,

> I am interested in pursuing a header compression technique with a 
> profile corresponding to UDP/RTP only. This profile is not part of
> the existing library.

Welcome aboard :)

> Could someone please provide an outline as to how i might proceed on 
> developing a UDP/RTP compression scheme using the existing library ?

Before starting with development in the ROHC library, you first have to
define how you want to compress your UDP/RTP headers. You probably want
to base your compression profile on the existing IP/UDP/RTP profile
defined in RFC 3095, but omit the parts that are specific to the IP
header.

It would mean that your UDP/RTP profile got 3 modes (U-mode, O-mode,
R-mode, see RFC 3095 and [1] in library doc, R-mode is not implemented
in library yet) and 3 states (IR, FO, SO, see RFC 3095 and [2] in
library doc).

It would also mean that your UDP/RTP profile got several packet types
(see RFC 3095 and [3] in source code of the current dev branch):
 - IR packet (see [4] in library doc) without IP parts in static and
   dynamic chains.
 - IR-DYN packet (see [5] in library doc) without IP parts in dynamic
   chain.
 - UO-0 packet (see [6] in library doc) unchanged.
 - UO-1-* packets (see [7] in library doc):
    - UO-1 in library is reserved for non-RTP profiles, so your profile
      should not use it.
    - UO-1-RTP in library is reserved for RTP profiles and does not
      contain any bit of IP header, so your profile could use it.
    - UO-1-ID should not be used by your profile since it contains 5
      bits of IP-ID and your profile does not compress the IP header.
    - UO-1-TS does not contain any bit of IP header, so your profile
      could use it.
 - UOR-2-* packets (see [8] in library doc):
    - UOR-2 in library is reserved for non-RTP profiles, so your profile
      should not use it.
    - UOR-2-RTP in library is reserved for RTP profiles and does not
      contain any bit of IP header, so your profile could use it.
    - UOR-2-ID should not be used by your profile since it contains 5
      bits of IP-ID and your profile does not compress the IP header.
    - UOR-2-TS does not contain any bit of IP header, so your profile
      could use it.
 - The UOR-2-* packets may contain an optional extension of 3 types:
    - Extension 0 for RTP profiles (see [9] in library doc) may contain
      some bits of IP header if T = 0 in the UOR-2-* packet. As only
      the forbidden UOR-2-ID packet has T = 0, your profile could use
      the extension 0 unconditionally.
    - Extension 1 for RTP profiles (see [10] in library doc) may contain
      some bits of IP header if T = 0 or T = 1 in the UOR-2-* packet. As
      only the UOR-2-RTP packet has not T = 0 or T = 1, your profile
      could use the extension 0 only with the UOR-2-RTP packet.
    - To be continued with extensions 2 and 3 (see [11] and [12] in
      library doc)...

I probably forget one or two things, but the main points are presented
above.


Once your compression profile is well defined, you could start creating
new compression and decompression profiles in the ROHC library.

The source code of the library is separated into 3 parts:
 - the src/common/ directory contains the code that is shared among
   compression and decompression profiles.
 - the src/comp/ directory contains the code of compression profiles.
 - the src/decomp/ directory contains the code of decompression
   profiles.

The rohc_comp.[ch] and rohc_decomp.[ch] files define the public API of
the ROHC library and the core functions.

The c_generic.[ch] and d_generic.[ch] files contain the code that is
shared among all the IP-based profiles. The name 'generic' is confusing
and should probably be replaced by 'ip_based' in the future.

The profiles that use the IP-based source code are:
 - IP-only: c_ip.[ch] for compression and d_ip.[ch] for decompression
 - IP/UDP: c_udp.[ch] for compression and d_udp.[ch] for decompression
 - IP/UDP-Lite: c_udp_lite.[ch] for compression and d_udp_lite.[ch] for
   decompression
 - IP/UDP/RTP: c_rtp.[ch] for compression and d_rtp.[ch] for
   decompression

Your profile is not IP-based since you chose not to compress the IP
header, so you can not directly inherit the methods defined in
the [cd]_generic.[ch] files.

The Uncompressed profile is the only profile implemented in the ROHC
library that is not an IP-based profile and does not use the
[cd]_generic.[ch] files. It is implemented in the c_uncompressed.[ch]
for compression and d_uncompressed.[ch] for decompression.


A compression profile should define a structure of type c_profile (see
[13] in library doc). The documentation should be self-sufficient to
describe the different parameters and callbacks. If not, you should
take a look at the already-defined profiles (the Uncompressed
profile is quite simple to start). If existing profiles are not
sufficient, send your questions on this mailing list.

If your compression profile wants to store some profile-specific
information in the compression context, it should store that
information in memory area and make the 'specific' pointer of the
c_context structure point on it (see [14] in library doc). Your profile
is responsible of allocation/destruction of that memory area.


A decompression profile should define a structure of type d_profile
(see [15] in library doc). The documentation should be self-sufficient
to describe the different parameters and callbacks. If not, look at the
already-defined profiles and ask questions on this ML.

If your decompression profile wants to store some profile-specific
information in the decompression context, it should store that
information in memory area and make the 'specific' pointer of the
d_context structure point on it (see [16] in library doc). Your profile
is responsible of allocation/destruction of that memory area.


ROHC is complex. I advice you to develop your new profile step by step.
First step might be "handling compression and decompression of IR
packets in U-mode and IR state only". Second step might be "adding
support for IR-DYN packets" and so on.

Last but not least, please start developing with the main development
branch [17] of the ROHC library, not the 1.2.x nor 1.3.x branches. All
the links below are for the 1.3.0 release and are not accurate for the
development branch. The doc of the dev branch is not available online.
To generate up-to-date documentation for the dev branch, follow the
instructions of the INSTALL file [18].


I hope that I answered your question :) If not, ask for more
explanations on this mailing list.

Regards,
Didier Barvaux


Links:
[1] ROHC modes in library doc:
http://www.tech.viveris.com/docs/rohc/rohc_8h.html#5e65ec1d142b4bffe4a5f6f124ad1a65
[2] ROHC states in library doc:
http://www.tech.viveris.com/docs/rohc/rohc__comp_8h.html#5c495ea15124ee17df903d96449a35ae
[3] The different types of ROHC packets in source code:
http://bazaar.launchpad.net/~didier-barvaux/rohc/main/annotate/head:/src/common/rohc_packets.h
[4] IR packet in library doc:
http://www.tech.viveris.com/docs/rohc/c__generic_8c.html#711c77e15f1717a26f796cdfcdd9242b
[5] IR-DYN packet in library doc:
http://www.tech.viveris.com/docs/rohc/c__generic_8c.html#9489d4e9fb5fb79318b4a93b1ce8bed4
[6] UO-0 packet in library doc:
http://www.tech.viveris.com/docs/rohc/c__generic_8c.html#d359824f597a71646374a290d3b610a0
[7] UO-1-* packets in library doc:
http://www.tech.viveris.com/docs/rohc/c__generic_8c.html#7196b51dc8cc5fec085d78c39573c317
[8] UOR-2-* packets in library doc:
http://www.tech.viveris.com/docs/rohc/c__generic_8c.html#1294f1b67a4d607f503ef432dd604853
[9] EXT0 for UOR-2-* packets in library doc:
http://www.tech.viveris.com/docs/rohc/c__generic_8c.html#1d96e202b1b771c70e3ebe2959c5e9f6
[10] EXT1 for UOR-2-* packets in library doc:
http://www.tech.viveris.com/docs/rohc/c__generic_8c.html#71519b2f432efc5d9d42a03f2e84dc49
[11] EXT2 for UOR-2-* packets in library doc:
http://www.tech.viveris.com/docs/rohc/c__generic_8c.html#5e436a72b4d044f8c7132e3d1fbb8d5d
[12] EXT3 for UOR-2-* packets in library doc:
http://www.tech.viveris.com/docs/rohc/c__generic_8c.html#af9e4b50f5de071cd1bacbce9af5fbec
[13] struct c_profile in library doc:
http://www.tech.viveris.com/docs/rohc/structc__profile.html
[14] parameter named 'specific' of struct c_context in library doc:
http://www.tech.viveris.com/docs/rohc/structc__context.html
[15] struct d_profile in library doc:
http://www.tech.viveris.com/docs/rohc/structd__profile.html
[16] parameter named 'specific' of struct d_context in library doc:
http://www.tech.viveris.com/docs/rohc/structd__context.html
[17] rohc-main branch:
https://code.launchpad.net/~didier-barvaux/rohc/main
[18] instructions for up-to-date documentation:
http://bazaar.launchpad.net/~didier-barvaux/rohc/main/annotate/head:/INSTALL#L32

Attachment: signature.asc
Description: PGP signature


Follow ups

References