Subject: [rohc] RFC 3095 question: TS wraparound interpretation interval

From: Alan Kennington <[email-masked]>
Date: Wed, 18 Jun 2003 00:11:17 +0930

Here's another area of RFC 3095 which seems a little unclear.
Therefore I think this also deserves to be in the ROHC implementer's guide
in more detail. This issue does affect interoperability, although admittedly
the TS wraparound is rare. For 8 kHz timer for audio, I make it
2^32/8000/3600 = 149.13 hours. For 90 kHz video, I make it:
2^32/90000/3600 = 13.256 hours. So I guess no one's really going to notice.
However, I want to know how to do it correctly. So...

There are two cases where there is possible ambiguity - positive
wraparound (case A) and negative wraparound (case B).

Case A:
vref >= vmax + p - 2^k + 2

Case B:
vref <= p - 1.

Here "vref" is the reference value, which is an earlier value of the
scaled 32-bit TS field. "vmax" = floor((2^32 - 1)/TS-scale) is the maximum
value of the scaled 32-bit TS field.

Now suppose the decompressor receives the value x = (v modulo 2^k),
where v is the current scaled TS field in the IP header which the
compressor must transmit. Then the decompressor normally does this to
recover the value of v:

    v = vref - p + ((x - vref + p) modulo 2^k).

This value v may be greater than vmax in case A.

Question 1:
If the above calculation for "v" give me a number greater than vmax,
is the decompressor always justified in interpreting the value of
v as v = x?

It seems to me logical that this must be so if I wanted an optimal protocol.
In other words, if I can't interpret the value in the interpretation
interval [vref - p, vmax], then I should interpret it in the interval
[0, 2^k - 1], because that is what the RTP source will probably do next.

Now look at case B.
In this case I may have a negative wraparound because the rule

    v = vref - p + ((x - vref + p) modulo 2^k)

may give me a negative number v < 0.

Question 2:
If the calculation of v by the decompressor gives a negative number 
in case B, am I always justified in interpreting the value v
in the interval [vmax - 2^k + 1, vmax]?

I see nothing about negative wraparound in RFC 3095.
However, the scaled TS may go backwards even when TS = 0.
It seems logical to do the same thing with negative and positive
wraparounds.

When I interpret ambiguous parts of RFC 3095, I always try to
make an interpretation which gives me the best protocol.
But this is not necessarily the same as everyone else's interpretation.

I would like to propose that the above TS wraparound rules be
included in the ROHC implementer's guide.
What is the procedure for proposing changes to the ROHC implementer's guide? 

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