Subject: RE: [rohc] Slope used to compress/decompress RTP Timestamp field

From: [email-masked]
Date: Mon, 5 Apr 2004 11:46:17 -0400

Hi Vick,

> I further assumed that "slope"
> for the TS field was labelled TS_STRIDE, which my following text
> focuses upon.

It becomes clear to me that this is the crux of the confusion. I've 
tried to explain the difference between slope and TS_STRIDE in the 
email below (in particular, please look at the end of email). Please 
let me know if you have comments on that.

http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg02042.html

Also, the text below (from section 5.7) indicates slope and TS_STRIDE
are two *independent* concepts, though they may have the same values
in certain cases.

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

      If value(Tsc) = 1, Scaled RTP Timestamp encoding is used before
      compression (see section 4.5.3), and default-slope(TS) = 1.

      If value(Tsc) = 0, the Timestamp value is compressed as-is, and
      default-slope(TS) = value(TS_STRIDE).

> While this has all been my personal interpretation the "slope" and
> TS_STRIDE is, I'm probably not alone in this since it should be also
> pointed out that this has not been an issue during the four interops
> taken place so far. While we never explicitly tested for this, it
> would almost certainly have popped up if there were situations where
> the compressor and decompressor were both independently trying to
> figure out deltas/slopes/strides for TS.

Could you explain how the TS is decompressed in your implementation
when the decompressor receives a Type 0 packet?

For certain cases, the two interpretation can yield the same result.
That may explain why the issue has not been raised. However, I didn't
have time to follow ROHC interops. So, I don't know the details. One 
thing I do know is that in Nokia's implementation (which I participated in
at beginning), scaling and compression (FO, SO, etc.) are two separate
steps. Unfortunately, Nokia's team were not able to participate in
all the four interops.

BR,
Zhigang

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

---

From: Vicknesan Ayadurai <[email-masked]>
Date: Wed, 7 Apr 2004 20:41:36 +0200 (CEST)

Hi Zhigang,

Thanks for attempting to clarify the issue. I actually have some
questions based on the the two examples you provided in another mail,
which I'll address seperately.

> when the decompressor receives a Type 0 packet?

Decompression is always based on a successfully decompressed reference
header (HDR_ref). The incoming Type 0 packet contains SN-bits (and no
TS bits). Hence,

a. SN_new = some f(SN_ref, SN-bits); /* obtain SN_new from SN-bits */

b. TS_new = TS_ref + (TS_STRIDE * (SN_new - SN_ref));

where TS_STRIDE would've been explicitly sent by the compressor
sometime earlier.

This usually works since the compressor should've determined that
there was no need to send any TS-bits, and hence, sent the Type 0
packet (at least it worked when we interop'd with Nokia's
implementation before :-)

Is this how you perceive the decompressor to respond to a PT-0 packet,
or is there an alternative method?

Regards,
vick