rohc team mailing list archive
-
rohc team
-
Mailing list archive
-
Message #00755
Re: [Question #223442]: Interpretation of the exception, repair of CRC failure
Question #223442 on rohc changed:
https://answers.launchpad.net/rohc/+question/223442
Status: Open => Answered
Didier Barvaux proposed the following answer:
Elisabeth,
Here is my understanding of the § 5.3.2.2.3 of RFC 3095 [1] and the way the
ROHC library behaves.
According to the RFC, upon CRC failure:
1/ attempt a correction (there are 2 different algorithms that may be used),
2/ if correction fails in Full Context state, drop the damaged packet, then:
a/ if the frequency of CRC failures on all decompressed packets is low, do
nothing (no NACK, no state change).
b/ if the frequency is too high, send a NACK if in O- or R-mode, then
change for the Static Context state.
c/ drop all received packets until one of IR, IR-DYN or UOR-2 packet is received.
3/ if correction fails in Static Context state, drop the damaged packet, then:
a/ if the frequency of CRC failures on IR, IR-DYN and UOR-2 packets is low, do
nothing (no NACK, no state change).
b/ if the frequency is too high, send a STATIC-NACK if in O- or R-mode,
then change for the No Context state.
c/ drop all received packets until one IR packet is received.
4/ if correction fails in No Context state, drop the damaged packet, then:
a/ send a STATIC-NACK if in O- or R-mode,
b/ drop all received packets until one IR packet is received.
The ROHC library conforms to the RFC with the following limitations:
a/ the correction is never attempted [2],
b/ a frequency algorithm is used, but it is not the one described in the RFC [3].
c/ the negative ACKs are sent, but NACK is sent instead of STATIC-NACK in the
Static Context.
So, to answer your question: no, IR packet is not always required. If the
decompressor was in the Full Context state when several CRC failures
occurred, the decompressor goes in the Static Context state. The next
UOR-2 packet is able to put the decompressor back in the Full Context
state.
I didn't understand your second question "Just found that the todo list
presented further details about this topic, i.e. that it is related to the
decompressor state changes and to SN wrap around". Please rephrase
it if you need an answer on that part ;-)
Regards,
Didier
[1] http://tools.ietf.org/html/rfc3095#section-5.3.2.2.3
[2] In fact, correction upon CRC failure was attempted in versions < 1.4.0,
starting with 1.4.0 the feature was removed because the code was difficult
to maintain and made some code refactoring very difficult. The feature
remains to be added again.
[3] see the open bug https://bugs.launchpad.net/rohc/+bug/902465
--
You received this question notification because you are a member of ROHC
Team, which is an answer contact for rohc.