Subject: RE: [AVT] questions about jitter

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 28 Oct 2004 10:53:14 +0200

>         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.  

Of course the absolute amount of delay is important in interactive
systems, but (assuming that echo is not an issue)
perhaps not as important as was once thought.

In any case, there is a trade-off between the effect of jitter buffer
minimum delay and packet-loss degradation.
I suggest consulting ITU-T P.1010 and G.1020 on this issue.

In addition, modern methods of processing audio packets
can greatly reduce the minimal delay as compared to
static jitter buffer mechanisms.

Y(J)S

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

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Thu, 28 Oct 2004 14:52:02 +0200

> >
> > 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.
> 
> And there's RFC 3611 if you need more detailed statistics.
> 
> -- 
> Colin Perkins
> http://csperkins.org/
> 
>

I've run into similar issues when doing RAQMON and trying to refer RFC 3550 for some of the metrics to measure application QoS. At the end of the day we had to define new or supplementary metrics for jitter, loss and discards, and differentiate between the network and application layer metrics. It looks like RFC 3550 is in need of a revision on this respect.  

Regards,

Dan