Subject: [rohc] suggestion for future RTP profile

From: Alan Kennington <[email-masked]>
Date: Tue, 24 Jun 2003 02:11:32 +0930

I guess most people have no interest in changes to the RTP compression
any more, but anyway here is an idea for improved compression in the future.

While implementing profile 0x0001, I have found that it would be much
better to have two different numbers instead of TS-stride.
The values would be:

TS-scale  = the scale to apply to the TS before applying LSB encoding

TS-slope  = the rate of change of TS with respect to SN when the TS field
	    is not sent at all.

At present, these are always the same number. 
To give an example of the problem, I have been watching some audio/RTP traffic 
(GSM 06.10) which has usually 4 audio frames per packet.
Therefore normally I have
 
frame time  = 160 cycles at 8 kHz = 20 mSec
packet time = 640 cycles at 8 kHz = 80 mSec.

However, the code often skips a frame and makes the TS value change
by 480, 800 or 960 cycles.
Then the value of TS-stride = 640 is invalid.
In fact, because of the W-LSB algorithm, I must send the absolute
32-bit TS value for several packets after this codec clock skip.
This causes a noticeable degradation of ROHC compression performance.

Now suppose I use TS-stride = 160 instead. Then I can use the
4-bit or 6-bit compressed, scaled TS value for just the one strange packet.
But if I use TS-stride = 160, then it is wrong for the implicit 0-bit
TS field in the UO-0 packet, for example, because 640 does not equal 160.
Therefore I can never use UO-0 packets in this case.

So what I really need is TS-stride = 640 for the default TS step if the 
TS field is not sent explicitly, e.g. in UO-0.
But I want TS-stride = 160 for the scale when I send LSB encoding.

The solution to this is to have two different fields: TS-scale and TS-slope.
Then TS-slope is used for 0-bit TS encoding, and TS-scale is used
for k-bit W-LSB encoding for k > 0. Then I would put:

TS-scale = 160
TS-slope = 640

It would be very easy to include this idea in the packet format for
IR packets for profile 0x0001 because there are 3 reserved bits in
the same octet as the TIS and TSS fields. (RFC 3095, 5.7.7.6, page 102.)
The extension 3 format is probably a bit more difficult. 

This idea could be incorporated into the next version of 0x0001 !!

Cheers,
Alan Kennington.

--------------------------------------------------------------------
    name: Dr. Alan Kennington
 website: http://www.topology.org/
    city: Adelaide, South Australia
  coords: 138.59 E, 34.88 S
timezone: UTC+0930 http://www.topology.org/site/timezone.html
 pgp-key: http://www.topology.org/ak/key_ak2.asc

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