What is needed for RoHC with SIP?

Hello Rolf,

> I would like to use RoHC to reduce bandwith requirements on SIP calls on
> smartphones. I suppose i would need this library on the SIP client and the
> SIP registrar/proxy/rtpproxy server. I did not find any implementation on
> either end. Does anyone know of an existing SIP phone /server having this?

There is none as far as I know.

> If not, does this library have everything for such a use case?

Yes, it should. If something is missing, it could be added.

Regards,
Didier

Hi,

You should have a look at SigComp instead. It has been designed to reduce the signaling overhead by using compression of the XML part of the SIP sig messages.
Using ROHC for that purpose implies that your 2 end points are able to communicate using ROHC packets, that is not straighforward (use of IP tunneling is not really useful if your objective is to reduce overhead) . In addition, the main part of the overhead is due to the rich text part (plain text XML) and not the header part.

Best regards

Cédric

Cédric,

> Using ROHC for that purpose implies that your 2 end points are able to communicate using
> ROHC packets, that is not > straighforward (use of IP tunneling is not really useful if your
> objective is to reduce overhead) . In addition, the main part of the overhead is due to the
> rich text part (plain text XML) and not the header part.

You're right for the modifications of the 2 end points and for the overhead in the signalling packets (SIP). However, for data packets (RTP), the overhead is still the header part. For those packets, ROHC may be interesting even if IP tunneling is required.

Gain for ROHC without tunneling:
 - non-compressed IPv4/UDP/RTP packet = 20-byte IPv4 header + 8-byte UDP header
    + 12-byte RTP header + 40-byte audio data = 80 bytes
 - ROHC-compressed IPv4/UDP/RTP packet = 1-byte ROHC header + 40-byte audio
    data = 41 bytes
 = 49% gain

Gain for ROHC with IPv4 tunneling:
 - non-compressed IPv4/UDP/RTP packet = 20-byte IPv4 header + 8-byte UDP header
    + 12-byte RTP header + 40-byte audio data = 80 bytes
 - ROHC-compressed IPv4/UDP/RTP packet in IPv4 tunnel = 20-byte IPv4 header for
    tunnel + 1-byte ROHC header + 40-byte audio data = 61 bytes
 = 24% gain

A 24% gain is still interesting, but the IPv4 tunnel degrades the compression gain.

We may group several ROHC packets together (packing) to reduce the overhead
introduced by the IPv4 tunnel:
 - 4 non-compressed IPv4/UDP/RTP packet = 4 * (20-byte IPv4 header + 8-byte UDP header
    + 12-byte RTP header + 40-byte audio data) = 320 bytes
 - 4 ROHC-compressed IPv4/UDP/RTP packet in IPv4 tunnel = 20-byte IPv4 header for
    tunnel + 4 * (1-byte for packing + 1-byte ROHC header + 40-byte audio data) = 188 bytes
 = 41% gain

A 41% gain is definitely interesting :)

Regards,
Didier

Yes for the user plane it has to be considered. Be careful however if you
want toi group pk, since it Will have impacts on the perf (jitter and delay
)
Br
Cédric
Le 5 mai 2012 13:55, "Didier Barvaux" <email address hidden>
a écrit :

> Question #195843 on rohc changed:
> https://answers.launchpad.net/rohc/+question/195843
>
> Didier Barvaux posted a new comment:
> Cédric,
>
> > Using ROHC for that purpose implies that your 2 end points are able to
> communicate using
> > ROHC packets, that is not > straighforward (use of IP tunneling is not
> really useful if your
> > objective is to reduce overhead) . In addition, the main part of the
> overhead is due to the
> > rich text part (plain text XML) and not the header part.
>
> You're right for the modifications of the 2 end points and for the
> overhead in the signalling packets (SIP). However, for data packets
> (RTP), the overhead is still the header part. For those packets, ROHC
> may be interesting even if IP tunneling is required.
>
> Gain for ROHC without tunneling:
> - non-compressed IPv4/UDP/RTP packet = 20-byte IPv4 header + 8-byte UDP
> header
> + 12-byte RTP header + 40-byte audio data = 80 bytes
> - ROHC-compressed IPv4/UDP/RTP packet = 1-byte ROHC header + 40-byte audio
> data = 41 bytes
> = 49% gain
>
> Gain for ROHC with IPv4 tunneling:
> - non-compressed IPv4/UDP/RTP packet = 20-byte IPv4 header + 8-byte UDP
> header
> + 12-byte RTP header + 40-byte audio data = 80 bytes
> - ROHC-compressed IPv4/UDP/RTP packet in IPv4 tunnel = 20-byte IPv4
> header for
> tunnel + 1-byte ROHC header + 40-byte audio data = 61 bytes
> = 24% gain
>
> A 24% gain is still interesting, but the IPv4 tunnel degrades the
> compression gain.
>
> We may group several ROHC packets together (packing) to reduce the overhead
> introduced by the IPv4 tunnel:
> - 4 non-compressed IPv4/UDP/RTP packet = 4 * (20-byte IPv4 header +
> 8-byte UDP header
> + 12-byte RTP header + 40-byte audio data) = 320 bytes
> - 4 ROHC-compressed IPv4/UDP/RTP packet in IPv4 tunnel = 20-byte IPv4
> header for
> tunnel + 4 * (1-byte for packing + 1-byte ROHC header + 40-byte audio
> data) = 188 bytes
> = 41% gain
>
> A 41% gain is definitely interesting :)
>
>
> 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
>

Didier and Cedric, thank you for your explanations, i am really grateful for your effort.
If i understand this right, then the best would be to use SIGCOMP and ROHC together to get a low bandwith SIP communication, SIGCOMP for the signalling (XML) part and ROHC for the IP, UDP, RTP and TCP header part?
I not really understand the relationship between RHOC and SIGCOMP yet and their possible combined usage.
Here http://www.cse.iitb.ac.in/~sri/students/#priyesh, i saw the effect and an implementation of SIGCOMP and i think this could be done with a reasonable amount of work, but i would really like get an understanding of the possibilities to get the maximum out of these concepts.
Regards, Rolf

Rolf,

> If i understand this right, then the best would be to use SIGCOMP and ROHC
> together to get a low bandwith SIP communication, SIGCOMP for the signalling
> (XML) part and ROHC for the IP, UDP, RTP and TCP header part?

You're right.

> I not really understand the relationship between RHOC and SIGCOMP yet and
> their possible combined usage. Here http://www.cse.iitb.ac.in/~sri/students/#priyesh,
> i saw the effect and an implementation of SIGCOMP and i think this could be done with
> a reasonable amount of work, but i would really like get an understanding of the possibilities
> to get the maximum out of these concepts.

SIGCOMP compresses the payload of the SIP packets. ROHC compresses the IPv4, IPv6, UDP,
UDP-Lite, RTP, TCP headers. There are 2 different ways to reduce bandwidth usage. There are
not incompatible: you can use SIGCOMP to compress the payloads of the IP/UDP/SIP packets
and ROHC for the headers of the IP/UDP/SIP and IP/UDP/RTP packets.

The ROHC compression of the IP/UDP/SIP packets will not be very interesting because headers
are small in comparison to payloads (unless SIGCOMP is very efficient on the payload).

Regards,
Didier

SigComp will only compress the SIP signaling (data part not the header
part) between for example the client and the SIP proxy, whereas ROHC will
compress the RTP flows (only the header part) based on the classifier
configuration

Best regards
Cédric

2012/5/5 rolf <email address hidden>

> Question #195843 on rohc changed:
> https://answers.launchpad.net/rohc/+question/195843
>
> rolf posted a new comment:
> Didier and Cedric, thank you for your explanations, i am really grateful
> for your effort.
> If i understand this right, then the best would be to use SIGCOMP and ROHC
> together to get a low bandwith SIP communication, SIGCOMP for the
> signalling (XML) part and ROHC for the IP, UDP, RTP and TCP header part?
> I not really understand the relationship between RHOC and SIGCOMP yet and
> their possible combined usage.
> Here http://www.cse.iitb.ac.in/~sri/students/#priyesh, i saw the effect
> and an implementation of SIGCOMP and i think this could be done with a
> reasonable amount of work, but i would really like get an understanding of
> the possibilities to get the maximum out of these concepts.
> Regards, Rolf
>
> --
> 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
>

Didier,

>There are not incompatible: you can use SIGCOMP to compress the payloads of the IP/UDP/SIP packets
>and ROHC for the headers of the IP/UDP/SIP and IP/UDP/RTP packets.

So both could be used at the same time. What are the caveats? CPU power of a mobile?

Cédric,
> SigComp will only compress the SIP signaling
According to the work mentioned above, this reduced the size of the SIP signalling part up to 90% and helps to speed up the connection time in a wireless setup in the order of 15%.
Now what would be the gain if ROHC with a 41% gain for a packet would be added?

Best regards,
Rolf

Rolf,

> > There are not incompatible: you can use SIGCOMP to compress the payloads of the IP/UDP/SIP packets
> > and ROHC for the headers of the IP/UDP/SIP and IP/UDP/RTP packets.
>
> So both could be used at the same time. What are the caveats? CPU power of a mobile?

Yes, CPU power. Maybe a little bit of latency due to computing, but that's probably negligible.

> > SigComp will only compress the SIP signaling
> > According to the work mentioned above, this reduced the size of the SIP signalling part up to
> > 90% and helps to speed up the connection time in a wireless setup in the order of 15%.
>
> Now what would be the gain if ROHC with a 41% gain for a packet would be added?

No gain for connection time. Gain for bandwidth for sure.

Regards,
Didier