Subject: Clarification on timer-based compression (was: Re: [rohc] New Draft for Support of Reordering and Constant IP-ID)

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Tue, 19 Apr 2005 11:37:32 +0200

To follow up on this question, I suggest adding the following section
to the implementer's guide:

4.8. Using timer-based compression
   
   Timer-based compression of the RTP timestamp, as described in
   section 4.5.4, can be used to reduce the number of transmitted
   timestamp bits (bytes) needed when the timestamp can not be
   inferred from the SN. It should thus be noted that timer-based
   compression has no influence on decompression of packets where
   no timestamp bits are sent, in that case the timestamp is just
   linearly inferred from the SN (see section 4.2 of this document).

   Whether to use timer-based compression or not is controlled by
   the TIME_STRIDE control field, which can be set either by an IR,
   an IR-DYN, or by a compressed packet with extension 3. Setting
   TIME_STRIDE to a value > 0 enables timer-based compression.

Any comments on this?

/L-E

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Lars-Erik Jonsson (LU/EAB)
> Sent: den 15 april 2005 09:03
> To: Kapoor, Rohit
> Cc: [email-masked]; [email-masked]
> Subject: RE: [rohc] New Draft for Support of Reordering and Constant
> IP-ID
> 
> 
> Rohit,
> 
> I'll try to clarify, hopefully I have corrently understood 
> your question.
> 
> First of all, timer-based compression has to be turned on by setting
> the TIME_STRIDE to a value > 0. So, if it is turned on, transmitted
> TS bits should always be interpreted as scaled TS bits, with the 
> assumption that the decompressor makes use of timer-based estimation,
> i.e. the transmitted bits might not themselves be enough to decompress
> the TS correctly (MSB requires a timer-based estimation).
> 
> However, if NO BITS are transmitted, this means that TS do follow SN
> linearly as a function of TS_STRIDE, i.e.:
>    TS_SCALED(n) = TS_SCALED(n-1) + SN(n) - SN(n-1)
> 
> Timer-based compression is used to be able to reduce the 
> number of extra
> bits (bytes) needed WHEN TS DOES NOT FOLLOW SN, i.e. instead of having
> to send two or three extra bytes after a silence period, one byte will
> be enough. When no TS bits are sent, timer-based compression has no
> impact on decompression.
> 
> Did that answer the question? Interpretation two is thus correct!
> 
> I guess it might make sense to write a few words about this in the
> implementer's guide, a new section 4.8 on timer-based compression?
> What do others think?
> 
> BR
> /L-E
> 
> 
> > -----Original Message-----
> > From: Kapoor, Rohit [mailto:[email-masked]]
> > Sent: den 14 april 2005 21:26
> > To: Lars-Erik Jonsson (LU/EAB)
> > Cc: [email-masked]
> > Subject: RE: [rohc] New Draft for Support of Reordering and Constant
> > IP-ID
> > 
> > 
> > Lars-Erik,
> > 
> > Thanks.
> > 
> > I also have a slight confusion in the interpretation of the 
> > RFC that you may be able to clarify. Assume that for some
> > time the compressor is using timer-based compression to
> > compress RTP timestamp and uses UO-1-TS packets. Now, if
> > the compressor decides to send a UO-0 packet, how does
> > the decompressor infer the RTP timestamp from this packet?
> > UO-0 could either mean that "jitter is 0" (since no
> > timestamp bits are present) or the decompressor could
> > infer timestamp from RTP SN. Which interpretation will
> > the decompressor follow? Or is sending a UO-0 packet not
> > "legal" when compressing TS using timer-based compression?
> > 
> > The following paragraph in the RFC says something which seems 
> > to support the second interpretation.
> > 
> > On page 58
> >    If RTP Timestamp and IP Identification fields are not 
> >    included in the received header, they are supposed to be
> >    calculated from the sequence number.  The IP Identifier
> >    usually increases by the same delta as the sequence number
> >    and the timestamp by the same delta times a fixed value. 
> >    See chapters 4.5.3 and 4.5.5 for details about how these
> >    fields are encoded in compressed headers.
> > 
> > 
> > Thanks,
> > Rohit
> 
> _______________________________________________
> 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: Kristofer Sandlund <[email-masked]>
Date: Tue, 19 Apr 2005 13:56:53 +0200

Hi L-E,

If we're going to provide clarifying text on this topic, I think we should also 
point out that the TIME_STRIDE cannot be set to a non-zero value before the 
clock resolution on the channel has been set by feedback. So, maybe a change like:

 >    TIME_STRIDE to a value > 0 enables timer-based compression.

NEW:
      Whether to use timer-based compression or not is controlled by
      the TIME_STRIDE and the decompressor's clock resolution. A non-zero
      TIME_STRIDE indicates timer-based compression is being used, but
      setting TIME_STRIDE to a non-zero value can only be done after the
      decompressor has declared its clock resolution. The clock resolution
      is declared by sending a CLOCK feedback for any CID on the channel.
      After the resoution is known, the TIME_STRIDE can be set either
      by an IR, an IR-DYN, or by a compressed packet with extension 3.

Or something along those lines, feel free to improve that, it turned out to be 
not-so-great text. But I think you know what I'm trying to say...

BR,
	Kristofer Sandlund, Effnet AB