rohc 1.5.1 does not compress VoIP

Asked by Florent Bertero on 2013-01-18

Hello team,

I am using rohc 1.5.1 on 2 servers Centos 4.x and 5.x.
I installed from sources following your wiki and tunnel is up with data transfer OK.

It seems to be working fine but I need rohc to compress RTP flow, so I set up a tunnel on 2 asterisks and created a sip trunk in this rohc tunnel.

Here is the command I use:
/opt/rohc/sbin/rohctunnel rohc0 remote "public ip 1" local 192.168.1.50 port 5000 3> /opt/rohc/comp_stats 4> /opt/rohc/decomp_stats &
and:
/opt/rohc/sbin/rohctunnel rohc0 remote "public ip 2" local "public ip 1" port 5000 3> /opt/rohc/comp_stats 4> /opt/rohc/decomp_stats &
I use local IP on server 1 because it is behind a router.

It is up and sip calls (g729) connect.

However, I need to verify rohc's compression rate.
Thus, I used 2 different tools to monitore bandwidth: iftop and a router calculating BP stats.

My problem is that a call going through rohc takes as much BP as a non compressed one (about 30kb/s).
I tried up to 3 calls and no difference were noticed.

Compression logs during call shows that it is working:
206 O-mode SO 60 28 36 4 0

FYI, asterisk trunks are set with "canreinvite=no" to be sure that RTP goes through the tunnel and not directly to the public IP.

Does anyone have an idea?

Thanks in advance
Florent

Question information

Language:
English Edit question
Status:
Answered
For:
rohc Edit question
Assignee:
No assignee Edit question
Last query:
2013-01-23
Last reply:
2013-01-23

Hello Florent,

> I am using rohc 1.5.1 on 2 servers Centos 4.x and 5.x.
> I installed from sources following your wiki and tunnel is up
> with data transfer OK.
>
> It seems to be working fine but I need rohc to compress
> RTP flow, so I set up a tunnel on 2 asterisks and created a
> sip trunk in this rohc tunnel.

Fine. Please note that the tunnel application is for testing purposes
only. Do not use it on production.

> However, I need to verify rohc's compression rate.
> Thus, I used 2 different tools to monitore bandwidth: iftop and
> a router calculating BP stats.
>
> My problem is that a call going through rohc takes as much BP
> as a non compressed one (about 30kb/s).
> I tried up to 3 calls and no difference were noticed.
>
> Compression logs during call shows that it is working:
> 206 O-mode SO 60 28 36 4 0

The logs show that ROHC compression is effective. On packet #206,
you saved 24 bytes for example. It could probably be better if you
configure the ROHC library to detect your RTP streams among all UDP
streams.

How do you compute the bandwidth rate with iftop and your router?
My guess is that you take into account the IP/UDP headers of the
tunnel in your computation.

As said before, the tunnel application is not for production use, but
only for testing. The overall gain (ROHC compression then IP/UDP
encapsulation) is not that great!

Regards,
Didier

Florent Bertero (flo-bertero) said : #2

Hello Didier,

Thanks for your quick reply.

I use iftop and my router as 2 different tools to mesure outgoing bandwith in 2 different cases.
    - When the tunnel is up and my call goes through the tunnel.
    - When the tunnel is down and my call goes directly to my voip switch.
In those 2 situations, I get the same results.

How can I tell my library to use RTP profiles?

Apart from the tunnel, what other way to compress rtp do I have?

Thanks again for your help.

Rgds
Florent

> To: <email address hidden>
> From: <email address hidden>
> Subject: Re: [Question #219552]: rohc 1.5.1 does not compress VoIP
> Date: Sun, 20 Jan 2013 09:31:04 +0000
>
> Your question #219552 on rohc changed:
> https://answers.launchpad.net/rohc/+question/219552
>
> Status: Open => Answered
>
> Didier Barvaux proposed the following answer:
> Hello Florent,
>
> > I am using rohc 1.5.1 on 2 servers Centos 4.x and 5.x.
> > I installed from sources following your wiki and tunnel is up
> > with data transfer OK.
> >
> > It seems to be working fine but I need rohc to compress
> > RTP flow, so I set up a tunnel on 2 asterisks and created a
> > sip trunk in this rohc tunnel.
>
> Fine. Please note that the tunnel application is for testing purposes
> only. Do not use it on production.
>
>
> > However, I need to verify rohc's compression rate.
> > Thus, I used 2 different tools to monitore bandwidth: iftop and
> > a router calculating BP stats.
> >
> > My problem is that a call going through rohc takes as much BP
> > as a non compressed one (about 30kb/s).
> > I tried up to 3 calls and no difference were noticed.
> >
> > Compression logs during call shows that it is working:
> > 206 O-mode SO 60 28 36 4 0
>
> The logs show that ROHC compression is effective. On packet #206,
> you saved 24 bytes for example. It could probably be better if you
> configure the ROHC library to detect your RTP streams among all UDP
> streams.
>
> How do you compute the bandwidth rate with iftop and your router?
> My guess is that you take into account the IP/UDP headers of the
> tunnel in your computation.
>
> As said before, the tunnel application is not for production use, but
> only for testing. The overall gain (ROHC compression then IP/UDP
> encapsulation) is not that great!
>
> Regards,
> Didier
>
> --
> If this answers your question, please go to the following page to let us
> know that it is solved:
> https://answers.launchpad.net/rohc/+question/219552/+confirm?answer_id=0
>
> If you still need help, you can reply to this email or go to the
> following page to enter your feedback:
> https://answers.launchpad.net/rohc/+question/219552
>
> You received this question notification because you asked the question.

> I use iftop and my router as 2 different tools to mesure
> outgoing bandwith in 2 different cases.
> - When the tunnel is up and my call goes through the tunnel.
> - When the tunnel is down and my call goes directly to my voip
> switch.
> In those 2 situations, I get the same results.

If you monitor your SIP/RTP streams with iftop, they'll appear as uncompressed because iftop monitors the streams before they got compressed. You can monitor the UDP/5000 stream generated by the tunnel instead, however the IP/UDP encapsulation added by the tunnel will not give you accurate numbers about the ROHC compression.

> How can I tell my library to use RTP profiles?

The ROHC library provides 2 ways to tell it that one UDP stream is one RTP stream:
 - a list of UDP ports configured with rohc_comp_add_rtp_port() [1]
 - a callback function called for every UDP packet and defined with rohc_comp_set_rtp_detection_cb() [2]

These functions are not available on the 1.5.x versions. They will be shipped with the to-be-released 1.6.0 version. Use the main dev branch in the meantime.

[1] http://bazaar.launchpad.net/~didier-barvaux/rohc/main/view/head:/src/comp/rohc_comp.c#L1368
[2] http://bazaar.launchpad.net/~didier-barvaux/rohc/main/view/head:/src/comp/rohc_comp.c#L1157

> Apart from the tunnel, what other way to compress rtp do I have?

The ROHC library is a library, so it is intended to be used in other programs. The library itself does not provide a standalone program (except the tunnel tool for testing purposes).

Regards,
Didier

Florent Bertero (flo-bertero) said : #4

Hello Didier,

Thanks for your answer and sorry for my late reply.

I now get the idea.

One last question though, what software would you advice me to use to implement the library?
Of course, any tutorial would be greatly appreciated :)

Thanks again,
Rgds
Florent Bertero

> To: <email address hidden>
> From: <email address hidden>
> Subject: Re: [Question #219552]: rohc 1.5.1 does not compress VoIP
> Date: Sun, 20 Jan 2013 18:01:18 +0000
>
> Your question #219552 on rohc changed:
> https://answers.launchpad.net/rohc/+question/219552
>
> Status: Open => Answered
>
> Didier Barvaux proposed the following answer:
> > I use iftop and my router as 2 different tools to mesure
> > outgoing bandwith in 2 different cases.
> > - When the tunnel is up and my call goes through the tunnel.
> > - When the tunnel is down and my call goes directly to my voip
> > switch.
> > In those 2 situations, I get the same results.
>
> If you monitor your SIP/RTP streams with iftop, they'll appear as
> uncompressed because iftop monitors the streams before they got
> compressed. You can monitor the UDP/5000 stream generated by the tunnel
> instead, however the IP/UDP encapsulation added by the tunnel will not
> give you accurate numbers about the ROHC compression.
>
>
> > How can I tell my library to use RTP profiles?
>
> The ROHC library provides 2 ways to tell it that one UDP stream is one RTP stream:
> - a list of UDP ports configured with rohc_comp_add_rtp_port() [1]
> - a callback function called for every UDP packet and defined with rohc_comp_set_rtp_detection_cb() [2]
>
> These functions are not available on the 1.5.x versions. They will be
> shipped with the to-be-released 1.6.0 version. Use the main dev branch
> in the meantime.
>
> [1] http://bazaar.launchpad.net/~didier-barvaux/rohc/main/view/head:/src/comp/rohc_comp.c#L1368
> [2] http://bazaar.launchpad.net/~didier-barvaux/rohc/main/view/head:/src/comp/rohc_comp.c#L1157
>
>
> > Apart from the tunnel, what other way to compress rtp do I have?
>
> The ROHC library is a library, so it is intended to be used in other
> programs. The library itself does not provide a standalone program
> (except the tunnel tool for testing purposes).
>
> Regards,
> Didier
>
> --
> If this answers your question, please go to the following page to let us
> know that it is solved:
> https://answers.launchpad.net/rohc/+question/219552/+confirm?answer_id=2
>
> If you still need help, you can reply to this email or go to the
> following page to enter your feedback:
> https://answers.launchpad.net/rohc/+question/219552
>
> You received this question notification because you asked the question.

> One last question though, what software would you advice
> me to use to implement the library?
> Of course, any tutorial would be greatly appreciated :)

OpenVPN could be a great candidate. Some time ago, I started to
modify OpenVPN to add support for ROHC. Please find the patches
there: http://barvaux.org/~didier/#projects

This is work in progress, so be careful when using it. There are some
remaining problems such as correct MTU handling.

Regards,
Didier

Can you help with this problem?

Provide an answer of your own, or ask Florent Bertero for more information if necessary.

To post a message you must log in.