some questions

Asked by regulararmy on 2015-05-14

hello Didier,
      Thank you for your lib 1.5.1,now I make use of it for my postgraduate studying,However,I find some questions for it.
       Firstly, in the uncomp profile,According to the RFC protocols, we should make the ACK feedback only by type 1 format,and we do not send the error feedback,is it right?
       secondly,if I open the feedback (decomp = rohc_alloc_decompressor(compressor)),and make it communicate with other ROHC code, However,the opposite entity(only enble the uncomp profile) always gives feedbacks with cid = 0,and always gives compress packets with cid = 1.However, for the uncomp profile,According to the RFC protocols, we can only use the CID = 1 for our context in compressor? if so, why the feedback packet in it indicating cid = 0.
       thirdly,if I open the colse feedback in your lib, there are a lot of errors :" non-IR packet received in No Context state", why? under the circumstances ,we should open the feedback to tell another rohc entity to backspacing to IR state? but if I open feedbcak, it seems not ok. maybe there are some bug in your lib.? please reply to me as soon as possible, Thank you very much.

best regards.

Question information

Language:
English Edit question
Status:
Solved
For:
rohc Edit question
Assignee:
No assignee Edit question
Solved by:
regulararmy
Solved:
2017-05-28
Last query:
2017-05-28
Last reply:
2015-05-28

Hello,

> Thank you for your lib 1.5.1,now I make use of it for my postgraduate studying.
> However,I find some questions for it.

Version 1.5.1 is quite old. You should update to version 1.7.0.

> Firstly, in the uncomp profile,According to the RFC protocols, we should make
> the ACK feedback only by type 1 format and we do not send the error feedback,
> is it right?

Yes, you're right. It was mentioned in ticket #1263693 [1]. I changed that in the master branch at [2]. Follow instructions at [3] to build the library from the GIT repository.

[1] https://bugs.launchpad.net/rohc/+bug/1263693
[2] https://github.com/didier-barvaux/rohc/commit/38df0d19c5a0a23007da013df31b984604676763
[3] https://rohc-lib.org/wiki/doku.php?id=library-install-sources#native_build_on_unix-like_systems

> secondly,if I open the feedback (decomp = rohc_alloc_decompressor(compressor)),
> and make it communicate with other ROHC code, However,the opposite entity
> (only enble the uncomp profile) always gives feedbacks with cid = 0,and always
> gives compress packets with cid = 1.However, for the uncomp profile,According
> to the RFC protocols, we can only use the CID = 1 for our context in compressor?
>if so, why the feedback packet in it indicating cid = 0.

I'm not sure to understand what's your problem. Do you mean that the Uncompressed profile can use only CID = 1 ?

> thirdly,if I open the colse feedback in your lib, there are a lot of errors :" non-IR
> packet received in No Context state", why? under the circumstances we should
> open the feedback to tell another rohc entity to backspacing to IR state? but if
> I open feedbcak, it seems not ok. maybe there are some bug in your lib.?

The "non-IR packet received in No Context state" warning is printed by the ROHC decompressor when it receives a ROHC packet that is not an IR packet while running in the the operational state called "No Context". This means that the decompressor transited downward from the state "Static Context" or "Full Context" to the "No Context" because of (normally repeated) CRC failures.

In such a case, if the decompressor runs in O-mode, it shall send a negative feedback of type NACK or STATIC-NACK to the remote associated compressor. They are several ways to send feedback to the remote associated compressor:
 * interspersed in a ROHC channel among other ROHC packets,
 * piggybacked with a ROHC packet in a ROHC channel,
 * sent alone in a dedicated ROHC feedback channel).

When the remote associated ROHC compressor receives the feedback, it identifies the ROHC channel (with the CID found in the feedback packet) then acts in consequence:
 * in case of a NACK, transit downward to First Order state (FO), then send only IR, IR-DYN and UOR-2 packets.
 * in case of a STATIC-NACK, transit downward to Initialisation & Refresh state (IR), then send only IR and IR-DYN packets.

The network RTT between the decompressor and its remote associated compressor may introduce some latency between:
 * the time at which the decompressor sends the feedback,
 * the time at which the compressor receives it and starts sending the correct packet formats,
 * and the time at which the decompressor receives the correct packet formats.
Maybe you experience such a case?

The remaining part of your question is quite difficult to understand. What do you mean by "open the feedback" ? I'm not sure if you understand fully the way feedbacks are transmitted from decompressor to compressor. Please read:
 * https://tools.ietf.org/html/rfc3759#section-2
 * https://tools.ietf.org/html/rfc3759#section-6.2
Try to use the vocabulary defined in RFC. It would ease the communication.

Regards,
Didier

regulararmy (regulararmy) said : #2

Thank you .