[RoHCv1.2.0] RoHC Fields for CRC Calculation

Asked by Orville Andrade on 2009-10-23

Hi All,

In RoHCv1.2.0 code I find that for compressed packets (UOR-*, UO-*....) the CRC is being computed over the entire 'uncompressed header' rather then following the guidelines provided in section5.9 (of RFC3095) for CRC coverage and computation. RFC3095 mentions that for CRC-3 & CRC-7 the uncompressed header should be divided in 'CRC-Static' and 'CRC-Dynamic' fields and the CRC should be computed. This is not followed in the RoHCv1.2.0 code.

Is the method of CRC Computation is the RoHCv1.2.0 code correct??
Orville Andrade

Question information

English Edit question
rohc Edit question
No assignee Edit question
Last query:
Last reply:

This question was reopened

Launchpad Janitor (janitor) said : #1

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

Open the question again because it requires further analysis from the ROHC Team.

Thank you very much for your precise code review
You're right : in the case of UO0 packets, the CRC is calculated taking into account the complete IP header

in comp/c_generic.c:
f_byte |= crc_calculate(CRC_TYPE_3, ip_get_raw_data(ip), ip_get_hdrlen(ip) +
                                (nr_of_ip_hdr > 1 ? ip_get_hdrlen(ip2) : 0) +

since ip_get_raw_data points to the original IP header

This does not change the behavior of the compression/decompression, but will affect
1- the performance (the computation complexity is slightly lower following the guidelines)
2- interoperability (the CRC calculated by the compressor of ROHC lib will be different from an other ROHC implementation)

Are you interested to submit a patch ?

For information, Cédric opened a new bug for this problem. See https://bugs.launchpad.net/rohc/+bug/481572

Jacques Orford (protocols) said : #5

This requirement of the RFC is a bit surprising to me. I would think that the extra code to look at only the CRC-DYNAMIC octets will offset the savings in the CRC computations themselves, esp. in IPv4. But so it is. Maybe as this change is made in the code, the impact on performance could be observed.

Interoperability is mentioned above. Has any interop testing been done with this implementation? If so, against what other implementation(s)?

alienjerry (lyl) said : #6

I have meet the question too .The lib can't decmpress IP/UDP/RTP packets case of CRC failure.where can I get the patch?

regulararmy (regulararmy) said : #7

up to now,which lib version has been modified for this? it seems not.?


The library was modified in 2010 to be conform to CRC-STATIC / CRC-DYNAMIC. The fix was first released in the 1.3.0 release in March 2010.

You may look at the related code at different locations:
* https://github.com/didier-barvaux/rohc/blob/master/src/comp/rohc_comp_rfc3095.c#L6084
* https://github.com/didier-barvaux/rohc/blob/master/src/common/crc.h#L477

All library releases since the 1.3.0 releases support CRC-STATIC / CRC-DYNAMIC, except for the "Note" found in §5.9.2 of RFC 3095 (https://tools.ietf.org/html/rfc3095#section-5.9.2) :
   Note: Whenever the CRC-STATIC fields change, the new saved CRC state
   after 1) is compared with the old state. If the states are
   identical, the CRC cannot catch the error consisting in the
   decompressor not having updated the static context. In U/O-mode the
   compressor SHOULD then for a while use packet types with another CRC
   length, for which there is a difference in CRC state, to ensure error

This check and the consequence on the packet type decision are not implemented yet. It is planned for the future release 2.4.0 : https://rohc-lib.org/developer/roadmap/#roadmap-main-branch

Didier Barvaux

Can you help with this problem?

Provide an answer of your own, or ask Orville Andrade for more information if necessary.

To post a message you must log in.