“How to calcualte the ip_id on decompressor side when RND bit toggles from 1 to 0”.

See https://answers.launchpad.net/rohc/+question/201484#comment-7

yes i mistakenly copy pasted the bullet 3. my question is about RND =1 to RND =0 transition itself.

"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."

Thanks again Barvaux:
Here are my followup question:
1. For b/..can you point me to the code for reference?
2. If the offset IP-ID decoded at step a is not used then why do we need to compute or store the IP id offset when packet with RND bit set to 1 arrives?

Rgds
Sankar Malladi

> yes i mistakenly copy pasted the bullet 3. my question is
> about RND =1 to RND =0 transition itself.

OK.

> 1. For b/..can you point me to the code for reference?

The ip_id_offset_decode() [1] does the job. It is called [2] by
decode_ip_values_from_bits() [3] that is itself called by
decode_values_from_bits() [4] to decode all bits extracted from
the ROHC header.

[1] http://bazaar.launchpad.net/~didier-barvaux/rohc/main/view/head:/src/common/ip_id_offset_decode.c#L100
[2] http://bazaar.launchpad.net/~didier-barvaux/rohc/main/view/head:/src/decomp/d_generic.c#L8547
[3] http://bazaar.launchpad.net/~didier-barvaux/rohc/main/view/head:/src/decomp/d_generic.c#L8547
[4] http://bazaar.launchpad.net/~didier-barvaux/rohc/main/view/head:/src/decomp/d_generic.c#L8214

> 2. If the offset IP-ID decoded at step a is not used then why do
> we need to compute or store the IP id offset when packet with
> RND bit set to 1 arrives?

For W-LSB decoding: https://tools.ietf.org/html/rfc3095#section-4.5.2

Regards,
Didier

Hi

Code flow is now clear to me. The only part still am not able to completely understand is the following part:
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.

For some reason WLSB encoding has been really tough for me to understand and then learn. May be am slow at understanding. But it would be much appreciated if you can share some real example / live packet decoding for b/ . I will be really grateful to you.

Thanks
Sankar

For an example, please build the main branch, then run the following test program:

  $ SED=sed AWK=gawk ./test/functional/rtp_uor2_disambiguation/test_rtp_uor2_disambiguation_ipv4rnd1_ipv4rnd0_uor2id.sh verbose verbose

Then read the traces, especially the ones for packet #7:

...
[d_rtp.c:421 rtp_detect_packet_type()] UOR-2* packet disambiguation: no IPv4 header with context(RND) = 0, so try parsing as UOR-2-RTP, and fallback on UOR-2-ID/TS later if value(RND) = 0 in packet
[d_generic.c:4009 d_generic_decode()] decode packet as 'UOR-2 (RTP)'
[d_generic.c:5413 parse_uor2()] 6 TS bits = 0x0
[d_generic.c:5416 parse_uor2()] M flag = 0
[d_generic.c:5419 parse_uor2()] 6 SN bits = 0x1a
[d_generic.c:5528 parse_uor2()] CRC-7 found in packet = 0x1d
[d_generic.c:5532 parse_uor2()] extension is present = 1
[d_generic.c:5566 parse_uor2()] first byte of extension = 0xde
[d_generic.c:6866 parse_extension3()] decode UOR-2* extension 3
[d_generic.c:6928 parse_extension3()] S = 0, R-TS = 1, Tsc = 1, I = 1, ip = 1, rtp = 0, ip2 = 0
[d_generic.c:6956 parse_extension3()] inner IP header flags field is present in EXT-3 = 0x04
[d_generic.c:7003 parse_extension3()] 7 bits of TS found in EXT-3 = 0x1a
[d_generic.c:7424 parse_inner_header_flags()] header flags: TOS = 0, TTL = 0, PR = 0, IPX = 0, NBO = 1, RND = 0
[d_generic.c:7465 parse_inner_header_flags()] DF = 0
[d_generic.c:7049 parse_extension3()] RND changed for outer IP header (1 -> 0)
[d_generic.c:7152 parse_extension3()] at least one RND changed and it makes our choice of packet type wrong, we must reparse the UOR-2* packet with a different packet type
[d_generic.c:5718 parse_uor2()] packet needs to be reparsed because RND changed in extension 3
[d_generic.c:5959 decode_uor2()] packet needs to be reparsed with different assumptions for packet type
[d_generic.c:5970 decode_uor2()] change for packet UOR-2-ID (T = 0)
[d_generic.c:5472 parse_uor2()] 5 IP-ID bits for IP header #1 = 0x0
[d_generic.c:5493 parse_uor2()] M flag = 0
[d_generic.c:5496 parse_uor2()] 6 SN bits = 0x1a
[d_generic.c:5528 parse_uor2()] CRC-7 found in packet = 0x1d
[d_generic.c:5532 parse_uor2()] extension is present = 1
[d_generic.c:5566 parse_uor2()] first byte of extension = 0xde
[d_generic.c:6866 parse_extension3()] decode UOR-2* extension 3
[d_generic.c:6928 parse_extension3()] S = 0, R-TS = 1, Tsc = 1, I = 1, ip = 1, rtp = 0, ip2 = 0
[d_generic.c:6956 parse_extension3()] inner IP header flags field is present in EXT-3 = 0x04
[d_generic.c:7003 parse_extension3()] 7 bits of TS found in EXT-3 = 0x1a
[d_generic.c:7424 parse_inner_header_flags()] header flags: TOS = 0, TTL = 0, PR = 0, IPX = 0, NBO = 1, RND = 0
[d_generic.c:7465 parse_inner_header_flags()] DF = 0
[d_generic.c:7049 parse_extension3()] RND changed for outer IP header (1 -> 0)
[d_generic.c:7193 parse_extension3()] 16 bits of outer IP-ID in EXT3 = 0x136f
[d_rtp.c:784 rtp_parse_uo_remainder()] UDP checksum not present
[d_generic.c:6050 decode_uor2()] ROHC payload (length = 0 bytes) starts at offset 8
[d_generic.c:8269 decode_values_from_bits()] decoded SN = 26 / 0x1a (nr bits = 6, bits = 26 / 0x1a)
[d_generic.c:8323 decode_values_from_bits()] 20 packets seem to have been lost, damaged, or failed to be decompressed (SN jumped from 0x5 to 0x1a)
[d_generic.c:8447 decode_ip_values_from_bits()] decoded outer TOS/TC = 0
[d_generic.c:8460 decode_ip_values_from_bits()] decoded outer TTL/HL = 64
[d_generic.c:8474 decode_ip_values_from_bits()] decoded outer protocol/NH = 17
[d_generic.c:8490 decode_ip_values_from_bits()] decoded outer NBO = 1
[d_generic.c:8503 decode_ip_values_from_bits()] decoded outer RND = 0
[d_generic.c:8516 decode_ip_values_from_bits()] decoded outer SID = 0
[d_generic.c:8564 decode_ip_values_from_bits()] decoded outer IP-ID = 0x1389 (rnd = 0, nbo = 1, sid = 0, nr bits = 16, bits = 0x136f)
...

Regards,
Didier

HI Didier
Thanks again. Finally all my confusion boils down to one of the below conclusions either 1 or 2. pls confirm.

1. The offset IP-ID encoding in RFC 3095 section 4.5.5
"When receiving a compressed packet m, the decompressor calculates
      Offset_ref = ID_ref - SN_ref, where ID_ref and SN_ref are the
      values of IP-ID and RTP SN in the reference header, respectively."

so here ID_ref is nothing but the IP ID that decompresser decoded successfully in the previous packet?
but then it conflicts with the statement "The Offset IP-ID decoded at step a/ is not used."

2. [d_generic.c:7193 parse_extension3()] 16 bits of outer IP-ID in EXT3 = 0x136f
Does this mean, the IP ID has to be sent in the EXT 3 FIELDs when RND changed to 0 so that we donot need to look at the ip id decompressor decoded in prev packet?

> 1. The offset IP-ID encoding in RFC 3095 section 4.5.5
> "When receiving a compressed packet m, the decompressor calculates
> Offset_ref = ID_ref - SN_ref, where ID_ref and SN_ref are the
> values of IP-ID and RTP SN in the reference header, respectively."
>
> so here ID_ref is nothing but the IP ID that decompresser decoded
> successfully in the previous packet? but then it conflicts with the
> statement "The Offset IP-ID decoded at step a/ is not used."

This one is not correct.

> 2. [d_generic.c:7193 parse_extension3()] 16 bits of outer IP-ID in
> EXT3 = 0x136f
> Does this mean, the IP ID has to be sent in the EXT 3 FIELDs when
> RND changed to 0 so that we donot need to look at the ip id
> decompressor decoded in prev packet?

The trace is not fully accurate. One should read: "16 bits of
W-LSB-encoded IP-ID Offset for outer IP header in EXT3 = 0x136f".
So, a/ the library W-LSB-decodes the 0x136f value to retrieve the Offset
IP-ID, then b/ the library adds the Offset IP-ID to the current SN to
retrieve the decoded IP-ID value.

Regards,
Didier

Thanks Didier. I am going to need some more time to analyze and get back.
I am going to conclude this discussion with one last question:
"16 bits of W-LSB-encoded IP-ID Offset for outer IP header in EXT3 = 0x136f".
where does this 0x136f come from? From the compressor in the compressed packet in EXT3 fields?

P.S : Thanks so much of your valuable time, it has been really helpful throughout with out feeling restless at all...Really appreciate your patience.
Thanks
Sankar

> Thanks Didier. I am going to need some more time to analyze
> and get back.
> I am going to conclude this discussion with one last question:
> "16 bits of W-LSB-encoded IP-ID Offset for outer IP header in
>EXT3 = 0x136f". where does this 0x136f come from? From the
> compressor in the compressed packet in EXT3 fields?

Yes. See https://tools.ietf.org/html/rfc3095#page-85 for the format
of the extension 3.

> P.S : Thanks so much of your valuable time, it has been really helpful
> throughout with out feeling restless at all...Really appreciate your patience.

You're welcome :)

Regards,
Didier