Subject: RE: [rohc] Timer-based compression

From: "Sarkar, Biplab" <[email-masked]>
Date: Thu, 5 Jan 2006 12:55:18 +0530

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: Kavitha KR <[email-masked]>
Date: Thu, 5 Jan 2006 13:38:58 +0530

Hi Biplab,

The explanation given for TIME_STRIDE field in "Sec 5.7.5-Extension 
Formats-RTP header flags and fields" is this:

TIME_STRIDE: 
Predicted time interval in milliseconds between
changes in the RTP Timestamp. Also an indication that the
compressor desires to perform timer-based compression of the RTP

It seems sending of TIME_STRIDE field by the compressor means that it 
"actually" wants to perform Timer Based Compression and not a 
mere "capability indication".

BR,
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

01/05/2006 12:55 PM

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

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

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.

To
<[email-masked]> 
cc
 
Subject

All, 
  
I have a query. 
  
How does the decompressor know “from” which packet onward it would be 
  
Thanks 
Biplab 

______________________________________________________________________
"This email message and any attachments are confidential information of 
Starent Networks, Corp. The information transmitted may not be used to 
create or change any contractual obligations of Starent Networks, Corp. 
Any review, retransmission, dissemination or other use of, or taking of 
any action in reliance upon this e-mail and its attachments by persons or 
entities other than the intended recipient is prohibited. If you are not 
the intended recipient, please notify the sender immediately -- by 
replying to this message or by sending an email to 
[email-masked] -- and destroy all copies of this message 
and any attachments without reading or disclosing their contents. Thank 
you." 
______________________________________________________________________