[asterisk-dev] definition of RTP jitter - potential bug in Asterisk

[Stanisław Pitucha]

2009/9/3 John Todd <jtodd at digium.com>:
>   Can you open a bug on this?  I don't want this to get lost.

I posted a bug link in the 2'nd mail in this thread.

>   But let me ask a few questions: What does "jitter" even measure?  I
> had interpreted jitter to mean the difference (via some smoothing
> mechanism) in milliseconds between the delays of subsequent packets in
> a uni-directional stream.  Why would frequency, or any codec-layer
> computation be involved in this determination?

Well - as you write in your post, jitter depends on 2 values (when
calculating the D function as in RFC 1889 6.3.1). "Si is the RTP
timestamp from packet i, and Ri is the time of arrival in RTP
timestamp units". The RTP timestamp is incremented by the number of
bytes of RTP data sent in every packet. In that case it will usually
be incremented by 160 for a typical alaw call. Since we're using RTP
timestamps the whole time, it's going to be 8000 RTP units / second
(for that alaw call).
If you stick to calculating the value in units specified in the RFC,
you get the jitter in those units and you don't have to care about the
"real time" at all. S is the "perfect" time for arrival, R is the
arrival timestamp. The rate only matters for presenting the result in
ms. But the jitter of 1 unit (byte) for a codec at 8kHz is different
in real time than the one for a codec at 16kHz.

Asterisk is calculating D not based on the timestamps, but time, so
the result is in time too. In res_rtp_.../calc_rxstamp():

   tv->tv_sec = rtp->rxcore.tv_sec + timestamp / 8000;
   tv->tv_usec = rtp->rxcore.tv_usec + (timestamp % 8000) * 125;
(time = time + timestamp/rate which means time + time)

Which is ok for a/ulaw and less ok for other codecs.

   current_time = (double)now.tv_sec + (double)now.tv_usec/1000000;
   transit = current_time - dtv;

You're using the real time and not the timestamps for jitter, so you
get jitter in real world time assuming rate=8000.

You can check the value with Wireshark - there was a very nice post
describing how the jitter is calculated on their ML (can't find the
link now unfortunately). If you multiply by the current rate instead,
the results match.

So I see 2 solutions. You can either leave the calculation as is and
multiply by rate to get the result in units (the one that should be in
the rtcp packet), or change the code to get:

tv = time*rate + timestamp
...
transit = current_time*rate - dtv

and then rxjitter will be in rtp units.

-- 
Kind regards,

Stanisław Pitucha, Gradwell Voip Engineer

T: 01225 800 831 | F: 01225 800 801 | E: stan at gradwell.net | www.gradwell.com

Gradwell – Internet for Business People
Phone Services | Business Broadband | Email & Website Hosting

Can switching to VoIP today put some change in your pocket?
Registered Address: 26 Cheltenham Street, Bath, BA2 3EX, UK. Company
Number: 3673235