rohc team mailing list archive
-
rohc team
-
Mailing list archive
-
Message #01885
Re: [Question #264189]: Outer IP ID Issue
Question #264189 on rohc changed:
https://answers.launchpad.net/rohc/+question/264189
Status: Open => Needs information
Didier Barvaux requested more information:
Thank you for the logs. I have built a fake RTP stream with the elements
from the logs. I reproduce the CRC failure that you encounter. The
packet reordering that occurs between the compressor and the
decompressor is the root of your problem.
Indeed the ROHC protocol is not designed to handle packet reordering between compressor and decompressor. It is stated in RFC 3095, §4.1:
The channel between compressor and decompressor is required to
maintain packet ordering, i.e., the decompressor must receive
packets in the same order as the compressor sent them.
(Reordering before the compression point, however, is dealt with,
i.e., there is no assumption that the compressor will only receive
packets in sequence.)
See https://tools.ietf.org/html/rfc3095#section-4.1 for the full text. Please note that packet reordering before the compressor or after the decompressor is perfectly handled by the ROHC protocol.
As a consequence, the following may be expected:
packet N is received and successfully decompressed
packet N+2 is received and successfully decompressed
packet N+1 is received and failed to be decompressed (CRC failure)
next packets may be successfully decompressed or not depending on the RTP stream
The ROHC protocol defines a way to better recover from CRC failures. It
is called "Actions upon CRC failure" (see §5.3.2.2.3, §5.3.2.2.4 and
§5.3.2.2.5 in RFC 3095,
https://tools.ietf.org/html/rfc3095#section-5.3.2.2.3). This mechanism
is implemented by the ROHC library. According to your logs, it is
enabled and tries to correct the decompression problem.
However, the correction upon CRC failure fails: RTP SN is corrected but
not the IPv4 IP-ID. I think that I identified the problem. The mechanism
described in the RFC is applied on the RTP SN but not on the IP-ID. I
didn't apply it to IP-ID when I implemented the mechanism, because the
RFC don't say to do so, but it makes sense. So, I have written a patch
that does exactly that. Please apply it to the ROHC library sources, re-
build it, re-install it, test the new setup, then report me
success/failure.
Please find the patch there: http://pastebin.com/JDvJQrx1
Regards,
Didier
--
You received this question notification because you are a member of ROHC
Team, which is an answer contact for rohc.