Hi,
As discussed over the last email, I am creating this bug tracker for the issue I faces for RTP profile decompression.
1- When using RTP profile, a single erroneous packet desynchronises
the decompressor and the decompresser is unable to decompress all the
proceeding packets till the next IR packet arrives.
2- If instead of sending the erroneous packet, it is forced to get lost in the
channel and never arrives at the decompresser, the decompresser is
able to decompress all the proceeding packets arriving without any
problem.
3- While scrutinising, I found that in case of the arrival of the
erroneous packet at the decompresser, the decompresser increments the
"ts_scaled", which should not be incremented until a packet with
correct CRC arrives , as per the standards. This leads to the wrong
calculated CRC values (in do_decode_uo0_and_uo1()) for the next
arriving packets.
4- When using only IP/UDP profile, this problem does not appear, and
the decompresser is able to decompress the packets proceeding
erroneous packet since "ts_scaled" is not involved in this case.
All these facts lead to the conclusion that there is something wrong
at the decompresser side with RTP profile or more specifically with
"ts_sc_decomp.c".
For UO0-*, UO1-* and UOR-2-* packets, the decompression
context is updated with values deduced from a ROHC packet that fails CRC
check. The context should not be updated. For IR and IR-DYN packets, it
seems that the CRC is checked before any context update, so IR and
IR-DYN packets should be bug-free.
I would really appreciate if you can fix the bug and send me the updated patch.
Thanks,
regards,
Jawad
Versions 1.2.x are affected.