Re: [rohc] Doubt regarding the Static chain termination for Profile0x004

["Gurushant" <[e-mail]>]

Hello Klaus, 

Thanks, that confirms my understanding.

Thanks & Best Regards
Gurushant.

-----Original Message-----
From: Klaus Warnke [mailto:[e-mail]]
Sent: Wednesday, March 10, 2010 4:08 PM
To: [e-mail]
Cc: [e-mail]
Subject: Re: [rohc] Doubt regarding the Static chain termination for
Profile0x004


Hello Gurushant,

At Wed, 10 Mar 2010 15:23:03 +0530,
Gurushant wrote:
> Dear All, 
> 
> Can one help on the below issue?
> 
> Thanks & Best Regards
> Gurushant
> 
>> Hello Simon,
>> I have doubt related to static chain termination. The RFC 3843 ,sec
>> 3.1 mentions that "The decompressor must store this indication in
>> the context for correct decompression of subsequent headers. Note
>> that the IP version field in decompressed headers must be restored
>> to its original value"
>> 
>> May I request to elaborate more on this reference, i.e. how the
>> subsequent header version is restored to original value?

If you don't remenber in the decompressor context, how many IP headers
are in the chain, you could not restore the original chain. In all
other profiles it is clear, because there are at most two IP
headers. It was sufficient to remember tunnel or not. If you are
using, for example, the RTP profile, after the one/two IP headers the
RTP header must follow. So there you need no extra information in the
decompressor context. But in this profile, the count of the IP headers
is not fixed, therefore you have to remember its termination to know
where the UDP/RTP headers are following (in RTP profile).

To restore the original version value, you have to clear the MSB:

* 0xC for IPv4 back to 0x4
* 0xE for IPv6 back to 0x6

That means, you should not put the 0xC/0xE value in the version field
of the reconstructed IP header in case of decompression the last IP
header in the chain.

Was this your question?

> Thanks & Best Regards
> Gurushant

Gruss, Klaus