Nope. I did not enable it in features and I do set arrival time before
compress4. I now see that I should have enabled it but that wouldn't have
helped me much as I'd originally intended this for traffic moving in O-Mode.
From reading the lib code, I see this is done only for U-Mode, which makes
sense. Correct? Anyway, my O-Mode sessions do get stuck sometimes, e.g. when
opening a remote SSH/TCP and doing e.g. "top" every sec in it. Originally, I
thought to quickly try that "time refresh" to maybe find why the contexts get
stuck(?) in this state.
Regards,
Yakir
On 8/06/18, 8:25 PM, "Didier Barvaux" <did...@barvaux.org> wrote:
Yakir,
> Making my concerns more real, I am pinging here seeing the IR first
> time only.
> [...]
> Didn’t the IR being sent message after 12s and my
> CHANGE_TO_FO_TIME is 6000, CHANGE_TO_IR_TIME is 12000.
>
> Init call of _ROHC_COMP_SET_PERIODIC_REFRESHES_TIME_ happens after the
> following init sequence of calls,
> [...]
Do you enable the ROHC_COMP_FEATURE_TIME_BASED_REFRESHES feature with
rohc_comp_set_features() ?
Do you set the rohc_buf.time attribute of the uncompressed packet that
you give as the 2nd argument to rohc_compress4() ? The rohc_buf.time
is the time of arrival of the packet, expressed in seconds and
nanoseconds.
This timestamp is used to determine if the delay since last IR packet
is expired or not.
Regards,
Didier
_______________________________________________
Mailing list: https://launchpad.net/~rohc
Post to : rohc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~rohc
More help : https://help.launchpad.net/ListHelp
