Subject: RE: [rohc] Timer-based compression

From: Kavitha KR <[email-masked]>
Date: Thu, 5 Jan 2006 14:05:18 +0530

Hi,

There could be 4 cases for switching from scaled TS compression to Timer 
based compression of RTP TS.

Scenario 1 : Decompressor initializes and compressor accepts
=====================================================
Packet flow with scaled timestamp compression going on.................
D => send feedback with CLOCK option
C => send TIME_STRIDE information (timer based compression starts here)
Further packet flow continues with timer based 
compression..................

Scenario 2: Compressor initializes and decompressor accepts
=====================================================
Packet flow with scaled timestamp compression going on.................
C=> send TIME_STRIDE information (timer based compression starts here)
D=> send feedback with CLOCK option
Further packet flow continues with timer based 
compression..................

Scenario 3: Decompressor initializes and compressor rejects
=====================================================
Packet flow with scaled timestamp compression going on.................
D => send feedback with CLOCK option
C=> No TIME_STRIDE info is sent (indicates not wanting to switch to Timer 
Based)
Further packet flow continues with scaled timestamp 
compression..................

Scenario 4: Compressor initializes and decompressor rejects
=====================================================
Packet flow with scaled timestamp compression going on.................
C =>send TIME_STRIDE information 
D=> send feedback with CLOCK option set to zero (means no desire to do 
timer based compression)
Further packet flow continues with scaled timestamp 
compression..................

For various compressor and decompressor implementations to interoperate, 
this may be the minimum set to be taken care.

=================================================
When your work speaks for itself, get out of the way.
-- Thomas 'Wayne' Brazell
=================================================
Kavitha K.R.,
L&T Infotech,
Bangalore.

( ) L&T Infotech Proprietary & Confidential
( ) L&T Infotech Confidential
(+) L&T Infotech Internal Use only
( ) General Business Information

"Kristofer Sandlund \(LU/EAB\)" <[email-masked]> 
01/05/2006 01:26 PM

To
"Sarkar, Biplab" <[email-masked]>, "Kavitha KR" 
<[email-masked]>
cc
<[email-masked]>
Subject
RE: [rohc] Timer-based compression

Hi,

Implementer's guide section 4.3:

   Before timer-based compression can be used, the decompressor will
   have to inform the compressor (on a per-channel basis) about its
   clock resolution. Further, the compressor has to send (on a per-
   context basis) a non-zero TIME_STRIDE to the decompressor.

   When the compressor is confident that the decompressor has received
   the TIME_STRIDE value, it can switch to timer-based compression.
   During this transition from window-based compression to timer-based
   compression, it is necessary that the compressor keep k large enough
   to cover both interpretation intervals. 

So the procedure is:
0) TIME_STRIDE starts out as zero
1) CLOCK option is sent by decompressor and received by compressor
2) Compressor decides that it wants to use timer-based compression.
   If so, the compressor sends a non-zero TIME_STRIDE
3) Compressor repeats time-stride until it is _confident_ that the
   decompressor has correctly received the new TIME_STRIDE. Note that
   these packet are already encoded with timer-based compression since
   they contain a time-stride that is non-zero.
4) All packets sent after this that contain an encoded timestamp are
   assumed to be using timer-based compression.

The timer-based compression initialization seems to be the most frequent
question on this list, but I don't know how to improve the text in the 
impl-guide any further. I thought it was quite clear now, but obviously 
it still isn't good enough. Do you have any suggestions on how to 
improve it further?

BR,
                 Kristofer

[email-masked] <mailto:[email-masked]> wrote:

> Hi Kavitha,
> 
> 
> 
> I believe with the UOR-2+ext-3 the compressor says that it
> "can" support "timer-based" compression. If the decompressor
> supports this, it can send an ACK with the CLOCK option. Once
> the compressor gets the CLOCK-opt from the decompressor it
> can change to the "timer-based" compression. But it doesn't
> let the decompressor know precisely when to start expecting
> packets compressed with "timer-based" compression.  There has
> to be some way to tell the decompressor that the current
> packet is compressed with the "timer-based" compression algo.
>  I don't see any flags for this in the RFC. One has to
> consider the number of packets on transit before deciding to
> change the compression algorithm after the initial negotiation.
> 
> 
> 
> Thanks
> 
> Biplab
> 
> 
> 
> ________________________________
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Kavitha KR Sent: Thursday, January 05, 2006 12:37 PM
> To: [email-masked]
> Subject: Re: [rohc] Timer-based compression
> 
> 
> 
> 
> Hi,
> 
> Compressor can be made to send an UOR-2 packet with ext-3 or
> IR/IR-DYN packet with TIS=1 and TIME_STRIDE value before it
> begins to do Timer based Compression of TS.  It is a way to
> indicate timer-based compression of TS to the decompressor.
> (Refer RFC 3095 Sec 5.7.5  Extension Formats)
> 
> Kavitha K.R.,
> L&T Infotech,
> Bangalore.
> 
> ( ) L&T Infotech Proprietary & Confidential
> ( ) L&T Infotech Confidential
> () L&T Infotech Internal Use only
> (+) General Business Information
> 
> 
> 
> "Sarkar, Biplab" <[email-masked]>
> Sent by: [email-masked]
> 
> 01/05/2006 11:41 AM
> 
> To
> 
> <[email-masked]>
> 
> cc
> 
> 
> 
> Subject
> 
> [rohc] Timer-based compression
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> All,
> 
> I have a query.
> 
> How does the decompressor know "from" which packet onward it
> would be getting packets encoded with
> timer-based-compression? Since the ACK from the decompressor
> which carries the CLOCK option might take some time to reach
> and get processed at the compressor; is there any way for the
> decompressor to know when to expect packets to be encoded
> with the timer-based compression method.
> 
> Thanks
> Biplab
> 
> ++++++++++++++++++++++++++++++++
> Biplab Sarkar
> Starent Networks, Bangalore
> ++++++++++++++++++++++++++++++++
> 
> 
> 
> ______________________________________________________________
> _______________________________________________________
> 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: "Lars-Erik Jonsson" <[email-masked]>
Date: Thu, 5 Jan 2006 09:40:47 +0100

Kavitha,

As said in the implementer's guide, "Before timer-based compression can
be used, the decompressor will have to inform the compressor (on a per-
channel basis) about its clock resolution."

This means only scenario 1 and 3 make sense. The compressor is not
allowed to start timer-based compression before the decompressor has
sent the clock resolution (i.e. the CLOCK option).

BR
/L-E

----- Original Message ----- 
From: "Kavitha KR" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, January 05, 2006 9:35 AM
Subject: RE: [rohc] Timer-based compression

> Scenario 1 : Decompressor initializes and compressor accepts

--------------------------------------------------------------------------------

---

From: Kavitha KR <[email-masked]>
Date: Thu, 5 Jan 2006 14:22:57 +0530

Hi L-E/Kristofer,

But, if we look at the explanation for CLOCK option in Sec 5.7.6.7 of 
3095, 

"The smallest clock resolution which can be indicated is 1
millisecond. The value zero has a special meaning: it indicates that
the decompressor cannot do timer-based compression of the RTP
Timestamp."

So even if there are impertinent Compressors (Scenario 2 and 4), 
Decompressors can still send CLOCK value zero and
choose not to do timer based decompression. Isn't it so ?

Regards,
Kavitha K.R.,
L&T Infotech,
Bangalore.

"Lars-Erik Jonsson" <[email-masked]> 
01/05/2006 02:10 PM

To
<[email-masked]>, "Kavitha KR" <[email-masked]>
cc

Subject
Re: [rohc] Timer-based compression

Kavitha,

BR
/L-E

---

From: "Lars-Erik Jonsson" <[email-masked]>
Date: Thu, 5 Jan 2006 09:58:15 +0100

The decompressor can also send a CLOCK option vith value zero, but
a compressor is still not allowed to start timer-based compression before
it has received the CLOCK option. The specifications do not allow that,
and one reason for that is the fact that the compressor can not know how
to compress with timer-based compression without knowing the clock
resolution.

/L-E

---

From: Kavitha KR <[email-masked]>
Date: Thu, 5 Jan 2006 14:57:52 +0530

Okay. Then this means only decompressor can initiate timer based 
decompression.
And for that it sends a feedback with CLOCK option.

If a decompressor does not want to do timer based compression, it would 
just not send a  CLOCK option at all.
Then when does the decompressor  send a CLOCK option with value zero ?
This 'special meaning' thing in CLOCK option (Sec 5.7.6.7)  looks a bit 
misleading.

BR,
Kavitha K.R.,
L&T Infotech,
Bangalore.

01/05/2006 02:28 PM

To
"Kavitha KR" <[email-masked]>, <[email-masked]>
cc

Subject

/L-E