RE: [rohc] New Draft for Support of Reordering and Constant IP-ID

["Lars-Erik Jonsson \(LU/EAB\)" <lars-erik.jonsson at ericsson.com>]

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:rkapoor at qualcomm.com]
> Sent: den 14 april 2005 21:26
> To: Lars-Erik Jonsson (LU/EAB)
> Cc: hjin at qualcomm.com
> 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
Rohc at ietf.org
https://www1.ietf.org/mailman/listinfo/rohc