Subject: RE: [AVT] questions about jitter

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 26 Oct 2004 10:55:34 +0200

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.

Y(J)S

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Randell Jesup <[email-masked]>
Date: 27 Oct 2004 16:01:55 -0400

"Yaakov Stein" <[email-masked]> writes:
>RFC 3550 states that the jitter SHOULD be calculated continuously as each
>calculation, although it can be computed recursively using buffers.
>
>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
[email-masked]

---

From: Colin Perkins <[email-masked]>
Date: Wed, 27 Oct 2004 21:42:31 +0100

> having to communicate in any way with the jitter buffer.

And there's RFC 3611 if you need more detailed statistics.

-- 
Colin Perkins
http://csperkins.org/

---

From: "Alan Clark" <[email-masked]>
Date: Thu, 28 Oct 2004 07:59:24 -0400

>having to communicate in any way with the jitter buffer.

This is one reason that the RFC3611 VoIP metrics:-

(a) tightens up the definition of "lost"
(b) reports discarded packets, i.e. a packet is either usable, lost or
discarded
(c) reports discards rather than jitter, as it is a more concrete measure of
what happened as a result of jitter

The whole problem becomes a little more complex when you assume that jitter
is a time variant process, which it generally is.  What is the meaning of a
short term average jitter measure when the jitter level is not constant?

With regard to the relationship between jitter level and jitter buffer
size - this also is a more complex problem in practice as jitter is
typically heavily time varying and jitter buffers are often dynamic.

AS mentioned in an earlier posting to AVT - there is an interesting (free)
tool on the www.voiptroubleshooter.com web site - on the "online diagnosis"
page.  This uses a time series model as a basis for generating a sequence of
packet delays and exports these to a log file for analysis if needed.

Alan