rohc team mailing list archive

[Yakir Matusovsky <yakir.matusovsky@xxxxxxxxxxx>]

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" <didier@xxxxxxxxxxx> 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