Subject: RE: [rohc] RFC 3095 question: TS wraparound interpretation interv al

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Tue, 9 Sep 2003 14:20:11 +0200

This is not really my stuff, I hope someone who was involved
in writing this (Zhigang, Micke, Anton??) can follow up, if needed.

Alan, can you be more precise on what is missing in 4.5.3? Short?

BR
/L-E

> -----Original Message-----
> From: Alan Kennington [mailto:[email-masked]]
> Sent: den 17 juni 2003 16:41
> To: ROHC mailing list
> Subject: [rohc] RFC 3095 question: TS wraparound 
> interpretation interval
> 
> 
> 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
> 

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