Sending RTP across a rohctunnel

Asked by Dan Benson on 2012-04-19

All,

First let me start by saying this is a very organized effort and the code your writing is excellent, thank you much for it.

I am interested in compressing headers for RTP traffic between two SIP servers and I thought I could do this using the rohctunnel but it seems I have no benefit. While I see the traffic in the traces and the calls flow just fine, I see no bandwidth savings if I compare a call in the ROHC tunnel to a call outside of the tunnel.

I seem not to match the RTP profile but I am getting matched on the UDP profile but no drop in bandwidth used.

Might someone have a second to point out what I am doing wrong?

Thanks much in advance.

db

Question information

Language:
English Edit question
Status:
Answered
For:
rohc Edit question
Assignee:
No assignee Edit question
Last query:
2012-04-19
Last reply:
2013-01-20

Hello,

> First let me start by saying this is a very organized effort and
> the code your writing is excellent, thank you much for it.

:-)

> I am interested in compressing headers for RTP traffic between
> two SIP servers and I thought I could do this using the rohctunnel
> but it seems I have no benefit. While I see the traffic in the traces
> and the calls flow just fine, I see no bandwidth savings if I compare
> a call in the ROHC tunnel to a call outside of the tunnel.
>
> I seem not to match the RTP profile but I am getting matched on
> the UDP profile but no drop in bandwidth used.
>
> Might someone have a second to point out what I am doing wrong?

The ROHC library does not detect RTP streams on the fly. It relies on
a static list of UDP ports that are considered as RTP. This is not very
reliable nor convenient. This will be reworked in the near future,
someone is working on this topic.

Currently the list can be modified in source code. For the 1.3.x branch, see
http://bazaar.launchpad.net/~didier-barvaux/rohc/1.3.x/view/head:/src/common/rohc.h#L402
For the trunk, see http://bazaar.launchpad.net/~didier-barvaux/rohc/main/view/head:/src/comp/c_rtp.c#L40

You have to re-build the library for the change to take effect.

Notes:
 - The ROHC tunnel application is not ready for production use. However it is very
    useful for testing.
 - The ROHC tunnel application uses UDP to encapsulate ROHC packets, this is a
    great choice for easy testing, but not the best choice for best performances.
    IP encapsulation would be better (8 bytes less for every packet).

Regards,
Didier

Hi,

Indeed, ROHC has not been designed to work end to end (e.g. between to SIP
clients/servers/proxies) but rather on link layers with reduced bandwidth
(or congestion issues).
Be also aware that if you use IP encapsulation, you may also have some
issues related to QoS, if you're using a classifier that works on UDP
ports. This may be a complex feature to save only few bytes (RTP + UDP -
ROHC header)

Best regards

C├ędric

2012/4/19 Didier Barvaux <email address hidden>

> Question #194142 on rohc changed:
> https://answers.launchpad.net/rohc/+question/194142
>
> Status: Open => Answered
>
> Didier Barvaux proposed the following answer:
> Hello,
>
> > First let me start by saying this is a very organized effort and
> > the code your writing is excellent, thank you much for it.
>
> :-)
>
> > I am interested in compressing headers for RTP traffic between
> > two SIP servers and I thought I could do this using the rohctunnel
> > but it seems I have no benefit. While I see the traffic in the traces
> > and the calls flow just fine, I see no bandwidth savings if I compare
> > a call in the ROHC tunnel to a call outside of the tunnel.
> >
> > I seem not to match the RTP profile but I am getting matched on
> > the UDP profile but no drop in bandwidth used.
> >
> > Might someone have a second to point out what I am doing wrong?
>
> The ROHC library does not detect RTP streams on the fly. It relies on
> a static list of UDP ports that are considered as RTP. This is not very
> reliable nor convenient. This will be reworked in the near future,
> someone is working on this topic.
>
> Currently the list can be modified in source code. For the 1.3.x branch,
> see
>
> http://bazaar.launchpad.net/~didier-barvaux/rohc/1.3.x/view/head:/src/common/rohc.h#L402
> For the trunk, see
> http://bazaar.launchpad.net/~didier-barvaux/rohc/main/view/head:/src/comp/c_rtp.c#L40
>
> You have to re-build the library for the change to take effect.
>
> Notes:
> - The ROHC tunnel application is not ready for production use. However it
> is very
> useful for testing.
> - The ROHC tunnel application uses UDP to encapsulate ROHC packets, this
> is a
> great choice for easy testing, but not the best choice for best
> performances.
> IP encapsulation would be better (8 bytes less for every packet).
>
>
> Regards,
> Didier
>
> --
> You received this question notification because you are a member of ROHC
> Team, which is an answer contact for rohc.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~rohc
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~rohc
> More help : https://help.launchpad.net/ListHelp
>

Raman Gupta (ramangupta16) said : #3

> It relies on a static list of UDP ports that are considered as RTP. This is not very
> reliable nor convenient. This will be reworked in the near future,
> someone is working on this topic.

In which release this is likely to be done? I would suggest ROHC library gets these configuration parameters from some config file or XML file as input.

> > It relies on a static list of UDP ports that are considered as RTP. This is not very
> > reliable nor convenient. This will be reworked in the near future,
> > someone is working on this topic.
>
> In which release this is likely to be done? I would suggest ROHC library gets
> these configuration parameters from some config file or XML file as input.

This is done in latest versions of the main branch (revision 552 or later). The
mechanism uses a user-defined function callback. That callback is set with the
rohc_comp_set_rtp_detection_cb() function. The callback shall return true if
it detects that the UDP stream is one RTP stream, false otherwise.

The function is to set the callback is defined there:
http://bazaar.launchpad.net/~didier-barvaux/rohc/main/view/head:/src/comp/rohc_comp.c#L1145

An example os use is there:
http://bazaar.launchpad.net/~didier-barvaux/rohc/main/revision/552/test/functional/rtp_detection/test_rtp_callback.c#test/functional/rtp_detection/test_rtp_callback.c

Regards,
Didier

Raman Gupta (ramangupta16) said : #5

Will this new RTP-UDP port verification callback 'rohc_comp_set_rtp_detection_cb' become available in 1.5.2?

Raman,

> Will this new RTP-UDP port verification callback
> 'rohc_comp_set_rtp_detection_cb' become available in 1.5.2?

No, it won't. The rule is to add new API functions only on X.Y.0 releases.
The rohc_comp_set_rtp_detection_cb() function will be first released
in the 1.6.0 version.

Regards,
Didier

Can you help with this problem?

Provide an answer of your own, or ask Dan Benson for more information if necessary.

To post a message you must log in.