Subject: RE: [rohc] Interpretation intervals for TS encoding

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Thu, 1 Jun 2006 15:53:52 +0200

Hi Endre,

It strikes me that the text that you are addressing in
draft-ietf-rohc-rtp-impl-guide-19.txt is rather old, it probably comes
from a version prior to this draft becoming a WG draft. Therefore I
think it is sound to revisit it.

I think that this sums up to answering to the following:

1) When does the HD start using TB decoding
2) What happens to the interpretation interval during
   transitions between Scaled TS encoding and TB encoding?
   (i.e. does the HC have to send more bit or some reason?)

My understanding is that if the answer to 1) is clear, than 2) is
irrelevant as, as you wrote yourself, the compressor will use a
reference that it has confidence that the decompressor has, and it will
use the correct interpretation interval as per section 4.3.

The answer to 1) is also clear, as you wrote yourself again, i.e. the
decompressor uses TB decoding as soon as it sees TIME_STRIDE>0, as per
section 5.7:

   TS: The compressed RTP Timestamp value.

      If value(TIME_STRIDE) > 0, timer-based compression of the RTP
      Timestamp is used (see section 4.5.4).

So, as a result of your comment, my proposal is to remove the last
paragraph in the text of section 4.3, i.e.:

   Since two different p-values are used, the compressor must take this
   into account throughout the process of enabling timer-based
   compression (see section 4.8 of this document). During transition
   from window-based compression to timer-based compression, it is thus
   necessary that the compressor keep k large enough to cover both
   interpretation intervals.

as it is not relevant (besides that it was in itself rather unclear in
its own magical ways!).

Thanks

/Ghyslain

Endre Szalai (IJ/ETH) wrote:
> Hi ROHCers,
> 
> reading the "Corrections and Clarifications to RFC 3095"
> (draft-ietf-rohc-rtp-impl-guide-19.txt) document, the last paragraph 
> of section 4.3 is not really clear for me.
> 
> "Since two different p-values are used, the compressor must take this

> into account throughout the process of enabling timer-based  
> compression (see section 4.8 of this document).
> During transition  from window-based compression to timer-based 
> compression, it is thus  necessary that the compressor keep k large 
> enough to cover both  interpretation intervals."
> 
> When the HC wants to use timer based compression, it will start 
> sending a positive TIME_STRIDE value (after of course a valid CLOCK 
> option is propagated from the HD). If the HD receives such a packet, 
> it will switch to timer based compression immediately. This means, 
> that the HD will use the value for "p" as specified in section 4.5.4 
> in RFC 3095) when decompressing received TS bits (if any), and not the

> "p"
> value for the W-LSB encoding.
> 
> Why and how the HC should consider the "p" value for W-LSB encoding in

> this case ?
> 
> The HC keeps track of all possible references the HD may have, and the

> HC will simply apply timer based compression with the proper "p" 
> value. Since HD will use the same "p" value (TIME_STRIDE > 0), how 
> could the 2 different interpretation intervals interfere ?
> 
> Could someone give a clarification on this (maybe an example) ?
> 
> Thanks,
> Endre
> 
> ==========================================================
> Endre Szalai            wired  > +36  1 437 7796
> Software Developer      mobile > +36 30 343 7061
> Conformance Center      fax    > +36  1 437 7576
> ERICSSON Hungary (ETH)  mail   > [email-masked]
> ==========================================================
> 
> 
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Mon, 12 Jun 2006 11:21:46 +0200

Ghyslain, Endre, others,

I fully agree with your conclusions.

This paragraph originates from the initial individual version
of this draft, dated November 2001. It had its own section
called "4.2.  Transition to timer-based compression", but the
text was later incorporated into the section about
interpretation intervals (added in rev 02, Oct 2002).

When now looking into this again, I agree with the conclusion
that 1) is clear from section 5.7 of RFC 3095. It is a mystery
to me how and why anyone would interpret this differently.

>From the mail archive we can find some discussions with
interpretations in line with the questioned paragraph in the
implementer's guide, but without arguments *why* that
should be needed (see thread titled "What is p value for TS?"
from September-October 2002).

So, I agree with the suggestion to remove this paragraph from
section 4.3 of the current draft. Since I have not seen any
objections, I will do this change to the draft right now.

/L-E

> draft-ietf-rohc-rtp-impl-guide-19.txt is rather old, it probably
> comes from a version prior to this draft becoming a WG draft.
> Therefore I think it is sound to revisit it.
> 
>    (i.e. does the HC have to send more bits for some reason?)
> 
> reference that it has confidence that the decompressor has,
> and it will use the correct interpretation interval as per
> section 4.3.
> 
> The answer to 1) is also clear, as you wrote yourself again, i.e.
> the decompressor uses TB decoding as soon as it sees
> TIME_STRIDE>0, as per section 5.7: 
> 
>       If value(TIME_STRIDE) > 0, timer-based compression of the
>       RTP Timestamp is used (see section 4.5.4).
> 
> So, as a result of your comment, my proposal is to remove the
> last paragraph in the text of section 4.3, i.e.:
> 
>    Since two different p-values are used, the compressor must
>    take this into account throughout the process of enabling
>    timer-based compression (see section 4.8 of this document).
>    During transition from window-based compression to timer-
>    based compression, it is thus necessary that the compressor
>    keep k large enough to cover both interpretation intervals. 
> 
> as it is not relevant (besides that it was in itself rather
> unclear in its own magical ways!). 
> 
> Thanks
> 
> /Ghyslain
>