Subject: [rohc] RFC 3095: TS encoding/decoding in extension 3, profile 0x0001

From: Alan Kennington <[email-masked]>
Date: Fri, 27 Jun 2003 02:37:44 +0930

This is a question which is relevant to interoperability, but which does not
seem to be answered in RFC 3095 or the ROCH implementer's guide, version 3. 
Maybe this question should be answered in the next version
of the ROHC implementer's guide.

RFC 3095, 5.7.5, p.85 says this about coding of TS in extension 3:

-----------------------------------------------------
      TS: Variable number of bits of TS, encoded according to
          section 4.5.6.  See the beginning of section 5.7.
-----------------------------------------------------

RFC 3095, 4.5.6, p.35-36 describes how to encode a 29-bit value in
1 to 4 octets.

The ROHC Implementer's Guide, version 3, says this:

-----------------------------------------------------
4.2.1.  Encoding of TS values

   RTP Timestamp values (TS) are always encoded using W-LSB encoding,
   both when sent scaled and when sent unscaled. For TS values sent in
   Extension 3, W-LSB encoded values are sent using the self-describing
   variable-length format (section 4.5.6), and this applies to both
   scaled and unscaled values.
-----------------------------------------------------

Scenario:
Suppose TS is unscaled and TS = 0x80000000.
The lower 29 bits of TS are 0x00000000 = 0.
Therefore the variable-length encoding gives a 1-octet encoding as 0x00.
The remaining 3 bits (1, 0, 0) must now go in the main header,
e.g. in a UOR-2 header.

Question:
How should the decompressor interpret the 3 bits 100 (binary) 
and the variable-length value 0x00 ?

Either:
1.	The decompressor may say that this value is 
	100 0000000 binary, because the 0x00 is a 7-bit zero.
Or:
2.	The decompressor may say that all TS values in extension 3
	must represent 29 bits, and therefore the value is
	100 00000 00000000 00000000 00000000 (binary).

W-LSB encoded TS > 0x1ffffff is unlikely, but it is not impossible.
My suggestion is that interpretation 2 should be adopted.
Is it obvious from RFC 3095 that this must be so?

Cheers,
Alan Kennington.

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