In what situation will the rand change when decompressing

Hi qingbaibai,

The RND flag may change in extension 3, more especially in the IP header flags. The packet will be parsed as UOR-2-ID (or UOR-2-RTP), and if it contains a RND flag whose value is different from the one stored in context, then the packet will be reparsed as UOR-2-RTP (or UOR-2-ID).

Last week I found that there are some problems in the library related to the above algorithm for streams with double IP headers. I have yet to analyze the problem and report it on the bugtracker. Did you find a problem on that part too?

Regards,
Didier

hello,
I only test VoIP streams which include only one IP header. And in my test, the packet is coded as UOR-2-ID and the RND is 0. But it is decoded as UOR-2-RTP and the RND is analysed as 1. I don;t know why the RND changes. Thank you.

> To: <email address hidden>
> From: <email address hidden>
> Subject: Re: [Question #201484]: In what situation will the rand change when decompressing
> Date: Tue, 26 Jun 2012 13:31:08 +0000
>
> Your question #201484 on rohc changed:
> https://answers.launchpad.net/rohc/+question/201484
>
> Status: Open => Answered
>
> Didier Barvaux proposed the following answer:
> Hi qingbaibai,
>
> The RND flag may change in extension 3, more especially in the IP header
> flags. The packet will be parsed as UOR-2-ID (or UOR-2-RTP), and if it
> contains a RND flag whose value is different from the one stored in
> context, then the packet will be reparsed as UOR-2-RTP (or UOR-2-ID).
>
> Last week I found that there are some problems in the library related to
> the above algorithm for streams with double IP headers. I have yet to
> analyze the problem and report it on the bugtracker. Did you find a
> problem on that part too?
>
> Regards,
> Didier
>
> --
> If this answers your question, please go to the following page to let us
> know that it is solved:
> https://answers.launchpad.net/rohc/+question/201484/+confirm?answer_id=0
>
> If you still need help, you can reply to this email or go to the
> following page to enter your feedback:
> https://answers.launchpad.net/rohc/+question/201484
>
> You received this question notification because you asked the question.

Thanks Didier Barvaux, that solved my question.

Hi Didier Barvaux.
Thanks for the excellent explanation. However i have a doubt regarding the 3rd bullet.

/ Scenario "RND=0 and change to RND=1":
      - at compressor: IPv4 + context(RND): 0 -> 1 => UOR-2-RTP + extension 3 with packet(RND)=1
      - at decompressor: IPv4 + context(RND)=0 => UOR-2-ID
      - when parsing extension 3, packet(RND)=1 is found, and packet is re-parsed as UOR-2-RTP

Can you please highlight or share the reference in the source code where we compute the ip_id correctly?

Here is my understanding:
a. when 1st packet received with RND bit 1, then we have to compute and store the id_offset_ref as curr_ip_id - curr_SN
b. when 2nd packet is received with RND bit toggled to 0, then we hv to use the id_ref computed at step 1 and compute the current ip_id as id_offset_ref + curr_SN.

pls correct my algorithm if you think there are any mistakes.

Thanks
Sankar

I wanted to know the clarification in the context of decompressor , but not the compressor. Sorry for missing out this information in my earlier comment.

Thanks
Sankar

Hi,

> Thanks for the excellent explanation. However i have a doubt
> regarding the 3rd bullet.
>
> 3/ Scenario "RND=0 and change to RND=1":
> - at compressor: IPv4 + context(RND): 0 -> 1 => UOR-2-RTP
> + extension 3 with packet(RND)=1
> - at decompressor: IPv4 + context(RND)=0 => UOR-2-ID
> - when parsing extension 3, packet(RND)=1 is found, and
> packet is re-parsed as UOR-2-RTP
>
> Can you please highlight or share the reference in the source code where we compute the ip_id correctly?

a/ When parsing extension 3, the library checks for changed RND: http://bazaar.launchpad.net/~didier-barvaux/rohc/main/view/head:/src/decomp/d_generic.c#L7041
b/ In such case, the parsing of the UOR-2* packet is stopped because it has to be reparsed with different asumptions: http://bazaar.launchpad.net/~didier-barvaux/rohc/main/view/head:/src/decomp/d_generic.c#L5712
c/ The correct type of UOR-2* packet is detected here, then packet is parsed again (please note the 2 calls to parse_uor2(): http://bazaar.launchpad.net/~didier-barvaux/rohc/main/view/head:/src/decomp/d_generic.c#L5938

The Offset IP-ID is always decoded the same way from bits extracted from the packet: http://bazaar.launchpad.net/~didier-barvaux/rohc/main/view/head:/src/decomp/d_generic.c#L8547

> Here is my understanding:
>
> a. when 1st packet received with RND bit 1, then we have to
> compute and store the id_offset_ref as curr_ip_id - curr_SN
> b. when 2nd packet is received with RND bit toggled to 0, then
> we hv to use the id_ref computed at step 1 and compute the
> current ip_id as id_offset_ref + curr_SN.
>
> pls correct my algorithm if you think there are any mistakes.

I do not understand your algorithm. Scenario 3 is about RND
changing from 0 to 1, not from 1 to 0. Are you talking about
scenario 4 instead?

For a/, the random IP-ID value is recorded as the new reference
by a call to ip_id_offset_set_ref() in the update_context() function
that is called once a packet is successfully decompressed.

For b/, if RND=0, then some bits of IP-ID offset are transmitted.
They must be used to compute the new IP-ID offset (see the
description of the W-LSB algorithm in RFC 3095). Once the new
IP-ID Offset is decoded, the new IP-ID value can be decoded from
the IP-ID offset and the decoded SN (see the description of the
Offset IP-ID algorithm in RFC 3095). The Offset IP-ID decoded at
step a/ is not used.

I hope that my explanations were clear enough. Do not hesitate to
ask additional questions if you need to.

Regards,
Didier