rohc team mailing list archive

[Didier Barvaux <question253632@xxxxxxxxxxxxxxxxxxxxx>]

Question #253632 on rohc changed:
https://answers.launchpad.net/rohc/+question/253632

    Status: Open => Needs information

Didier Barvaux requested more information:
Hello,

For the ROHC_STATUS_BAD_CRC return code, the documentation reads "The action failed due to a CRC failure":
http://rohc-lib.org/support/documentation/API/rohc-doc-1.7.0/group__rohc.html#ga358488d70240d6e229cf3880bdf7d804

A CRC failure means that the ROHC decompressor decompressed one ROHC
packet, but the resulting uncompressed packet did not match the original
uncompressed packet. The CRC is used to detect the decompression
problems.

According to RFC 3095 §5.3.2.2.3 (http://tools.ietf.org/html/rfc3095#section-5.3.2.2.3), decompression problems may be caused by several  things:
>   A mismatch in the CRC can be caused by one or more of:
>   1. residual bit errors in the current header
>   2. a damaged context due to residual bit errors in previous headers
>   3. many consecutive packets being lost between compressor and
>      decompressor (this may cause the LSBs of the SN in compressed
>      packets to be interpreted wrongly, because the decompressor has
>      not moved the interpretation interval for lack of input -- in
>      essence, a kind of context damage).

Any of the 3 hypothesis seem to be possible in your case. Is your
communication channel between the ROHC compressor and your ROHC
decompressor lossy? May it damage the ROHC packets? May it re-order
them?

Regards,
Didier

-- 
You received this question notification because you are a member of ROHC
Team, which is an answer contact for rohc.