RE: [AVT] questions about jitter

["Romascanu, Dan \(Dan\)" <dromasca at avaya.com>]

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

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