Re: [AVT] questions about jitter

[Randell Jesup <rjesup at wgate.com>]

"Yaakov Stein" <yaakov_s at rad.com> writes:
>RFC 3550 states that the jitter SHOULD be calculated continuously as each
>data packet i is received. The standard deviation is basically a block
>calculation, although it can be computed recursively using buffers.
>
>The method proposed in the RFC is a simple 1-lag IIR smoothing filter
>with an empirically set decay time. Although I personally
>wouldn't have used the wording "optimal first-order estimator",
>it certainly is the most straightforward way to compute a time-averaged
>jitter value.
>
>In any case, why do you want to compute PDV if your problem is packet loss
>rate ?  The jitter is an additional characteristic, and shouldn't directly
>effect "network quality" (e.g. perceived audio quality) unless there are
>large PDV swings, causing jitter buffer over- or under-flow and hence
>"internal" packet loss.

        Jitter is relevant to audio quality on it's own, separately from
packet loss - it affects (strongly) the minimum amount of jitter buffer
required to avoid underflow losses, and that delay affects call quality in
an interactive stream.  

"Packet loss" in RTCP _should_ be "packets lost or arriving out-of-order
too late to be played" which is essentially the post-jitter-buffer loss
rate.  So a post-jitter loss rate of 0% may still have horrid quality if
the jitter buffer average depth has to be 500ms to achieve that loss rate
(note: the jitter value in reported RTCP wouldn't be 500ms in this case).

Note that RFC 3550 RTCP defines "loss" in a very weird way; it allows very
late packets to not be considered "lost", and it counts duplicates as
multiple separate packets (so if you lose packet N, and get two of packet
N+1, that's considered 0 loss!!!)  Also, since loss is based on the last
packet received (packet N), if the previous packet (N-1) arrives
out-of-order (but in time to be played) after the RTCP is sent, the RTCP
will show that as a loss, and in the next RTCP an extra packet will
be counted (and yes, this can lead to negative loss rates).

So for many uses, while amusing, the RTCP data on loss (and probably
jitter) is close to worthless, and certainly has to be taken as at best
fuzzy data.  Post-jitter data (handling late packets, duplicates, etc) is
more useful in most cases.  I'm sure part of the reason it's defined this
way is so an RTP stack can calculate the loss & jitter simply without
having to communicate in any way with the jitter buffer.

-- 
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team
rjesup at wgate.com


_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt