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: rohc-bounces at ietf.org [mailto:rohc-bounces at ietf.org]On Behalf Of
Lars-Erik Jonsson (LU/EAB)
Sent: den 15 april 2005 09:03
To: Kapoor, Rohit
Cc: rohc at ietf.org; hjin at qualcomm.com
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: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
_______________________________________________
Rohc mailing list
Rohc at ietf.org
https://www1.ietf.org/mailman/listinfo/rohc