In what situation will the rand change when decompressing

Asked by qingbaibai on 2012-06-26

hello,

In what situation will the rand change when decompressing. The compressor codes a packet in type UOR-2-ID with extension 0 and rand is 0. However, the decompressor deompresses the packet as type UOR-2-RTP with extension 0 because the rand is 1. The last packet is UOR-2-ID too and it is decompreeed right and the rand is 0.

Question information

Language:
English Edit question
Status:
Solved
For:
rohc Edit question
Assignee:
No assignee Edit question
Solved by:
Didier Barvaux
Solved:
2012-06-29
Last query:
2012-06-29
Last reply:
2012-06-28

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

qingbaibai (sunqing-cztz) said : #2

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.

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.

The behaviour "IPv4 + context(RND)=0 => UOR-2-ID" at compressor is expected. The behaviour "UOR-2* + context(RND)=1 => try to decode UOR-2-RTP" at decompressor is expected too. What may be unexpected is that the contexts at compressor and decompressor are not in sync (0 at compressor, 1 at decompressor). It may occur if there was some packet loss/damage. Is it the case?

If the contexts are in sync, you should have one of the 4 following scenarios:

1/ Scenario "RND=0 and no change":
      - at compressor: IPv4 + context(RND)=0 => UOR-2-ID
      - at decompressor: IPv4 + context(RND)=0 => UOR-2-ID

2/ Scenario "RND=1 and no change":
      - at compressor: IPv4 + context(RND)=1 => UOR-2-RTP
      - at decompressor: IPv4 + context(RND)=1 => UOR-2-RTP

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

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

Regards,
Didier Barvaux

qingbaibai (sunqing-cztz) said : #4

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