Subject: RE: [rohc] RE:

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Tue, 6 Dec 2005 10:06:53 +0100

Hi Klaus,

Some precisions on my previous mail, inserted inline.
I think that I misunderstood your question actually.
Sorry about that. 

Regards,

/Ghyslain

[email-masked] wrote:
>> Sorry, my question was imprecise.
>> If I understood right, the timer-based transmission needs that
>> timestamp bits are sent. ImplGuide:
>>    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).
>> 
>> The smallest packet with TS bits is a type-1 packet, so if I use
>> timer-based compression, I can not use 1-byte type-0 packets, right?
> 
> [GHPE] Correct, that's right.

[GHPE] I think I have interpreted your question is a different manner
than it was intended to. I thought that you meant that timer-based
decompression was not used for packet type 0, but actually you wrote the
other way around "if timer-based compression is used (i.e. TIME_STRIDE >
0), the compressor cannot send PT-0". If this is what you really meant,
then I believe that this statement is not correct.

[GHPE] What I meant to agree with is that when the compressor has set
TIME_STRIDE > 0, meaning that it wants to use timer-based compression,
it is still possible to use 1-byte type-0 packets when no TS bits need
to be sent (TS behaves linearly with respect to SN). Otherwise when TS
bits need to be sent, obviously packet type 0 cannot be used. But that
surely was too trivial an answer ...

[GHPE] So more specifically ... my understanding is that when the
compressor has conveyed TIME_STRIDE > 0 to the decompressor, and when
the decompressor has sent its clock resolution in a feedback, then the
compressor can use timer-based compression. Packets with timer-based
compressed TS bits will be decompressed according to timer-based
compression as in rfc3095 section 4.5.4. Packets with no TS bits (i.e.
packet type 0), the TS is decompressed using TS_STRIDE only, based on
the SN (i.e. the decompressor does not use timer-based decompression in
that case).

[GHPE] See also the ROHC Implementer's guide section 4.8. I think that
what you were after is somewhere in the following text:

4.8.  Using timer-based compression

   Timer-based compression of the RTP timestamp, as described in section
   4.5.4, may 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. The compressor turns
   on timer-based compression by setting TIME_STRIDE to a value > 0, but
   that can be done first after the decompressor has declared its clock
   resolution, which is done by sending a CLOCK feedback option for any
   CID on the channel.

[GHPE] Let me know if is does not make more sense.
 
>> So if timer-based compression is on, at least a 2-bytes packet must
>> be sent.
> 
> [GHPE] Right again.

[GHPE] Here I made the same misinterpretation to your question.  See
above.
 
>> But if after a silent suppression the TS follows SN linear again,
>> there is from my point of view no need to continue with timer-based
>> compression, sending TS-bits. The decompressor can infer the TS from
>> the SN. Is this right?
> 
> [GHPE] If you mean that there is no need to send compressed
> TS bits when the TS behaves as a linear function of the SN,
> then I believe that you're right again.
> 

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