Subject: [AVTCORE] RFC3550: RTP Jitter value calculation

From: Nataraja Hosahalli <[email-masked]>
Date: Wed, 26 Mar 2014 12:55:58 +0000

Dear avtcore members,

I have a query on the RTP RFC 3550 which looks be an issue in RFC to me, please help by provide your expert advice.

RFC 3556 specifies 2 formulae for calculating RTP jitter in section 3.8. Couples of the RTCP RFC implementations are following these formulae.

          Section 3.8/ RFC 3550

      int transit = arrival - r->ts;

      int d = transit - s->transit;

      s->transit = transit;

      if (d < 0) d = -d;

One calculation option proposed,

        s->jitter += (1./16.) * ((double)d - s->jitter);

        rr->jitter = (u_int32) s->jitter;

other calculation option proposed
        s->jitter += d - ((s->jitter + 8) >> 4);

        rr->jitter = s->jitter >> 4;

RFC 3550 says both formulae are same. But if I look with sample numbers I see that the second formulae may not be appropriate.
The result of the formula "s->jitter += d - ((s->jitter + 8) >> 4)" LHS always keep increasing infinitely and could not be a reflecting an average value of jitter.

For example, in an hypothetical case if d = 2 each time, Jitter will be 2, 4, 6, 8, ... ever increasing, with the second formula.
Whereas with the first formulae each time it will be corrected towards d by fraction of 1/16. That is If d=2, rr->jitter will  be near to 2 in long run.

I request your opinion on this.

Thanks in advance.

Regards,
Nataraj

[1 (Custom) (2)]<http://www.dspg.com/>
[dsp_mal signature-Tali_180613-14]<mailto:[email-masked]>[dsp_mal signature-Tali_180613-15]<http://www.dspg.com/>[dsp_mal signature-Tali_180613-16]<https://www.facebook.com/#!/DSPGroup2013>[dsp_mal signature-Tali_180613-17]<http://www.linkedin.com/company/6894?trk=tyah>

Nataraja Hosahalli

Phone: +91 80 4024 8408
Mobile: +91 99860 25262

______________________________________________________________________
DSP Group, Inc. automatically scans all emails and attachments using MessageLabs Email Security System.
_____________________________________________________________________

---

From: Kevin Gross <[email-masked]>
Date: Wed, 26 Mar 2014 07:52:29 -0600

The formula looks basically correct. You need to look at the settling value
for rr->jitter, not s->jitter (which is a state variable). In your example,
s->jitter will settle at 32 and the correct value (2) will be reported for
rr->jitter.

I think the accuracy of the reporting could be improved by changing the
second line to:

        rr->jitter = (s->jitter + 8) >> 4;

Kevin Gross - AVA Networks

On Wed, Mar 26, 2014 at 6:55 AM, Nataraja Hosahalli <
[email-masked]> wrote:

>  Dear avtcore members,
>
>
>
> I have a query on the RTP RFC 3550 which looks be an issue in RFC to me,
> please help by provide your expert advice.
>
>
>
> RFC 3556 specifies 2 formulae for calculating RTP jitter in section 3.8.
> Couples of the RTCP RFC implementations are following these formulae.
>
>
>
>           Section 3.8/ RFC 3550
>
> RFC 3550 says both formulae are same. But if I look with sample numbers I
> see that the second formulae may not be appropriate.
>
> The result of the formula "*s->jitter += d - ((s->jitter + 8) >> 4)" *LHS
> always keep increasing infinitely and could not be a reflecting an average
> value of jitter.
>
>
>
> For example, in an hypothetical case if d = 2 each time, Jitter will be 2,
> 4, 6, 8, ... ever increasing, with the second formula.
>
> Whereas with the first formulae each time it will be corrected towards d
> by fraction of 1/16. That is If d=2, rr->jitter will  be near to 2 in long
> run.
>
>
>
>  <http://www.dspg.com/>
>  <[email-masked]>[image:
> dsp_mal signature-Tali_180613-15] <http://www.dspg.com/>[image: dsp_mal
> signature-Tali_180613-16] <https://www.facebook.com/#!/DSPGroup2013>[image:
> dsp_mal signature-Tali_180613-17]<http://www.linkedin.com/company/6894?trk=tyah>
>
> *Nataraja Hosahalli*
>
>
>
> Phone: +91 80 4024 8408
>
> Mobile: +91 99860 25262
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>
>

---

From: Stephen Casner <[email-masked]>
Date: Wed, 26 Mar 2014 07:56:09 -0700 (PDT)

Nataraja,

s->jitter is a scaled integer value holding the actual value times 16.
If the input is a constat d = 2, then the value we are looking for
s->jitter to settle on is 32.  All of the values 2,4,6,8 are
fractional values which become 0 in rr->jitter.  You did not carry
your example sequence far enough.

                                                        -- Steve

---

From: Nataraja Hosahalli <[email-masked]>
Date: Wed, 26 Mar 2014 16:20:42 +0000

Hi Kevin,

Yes you are right. I ran both the formulae and also your improved formula for 500 times with constant d value, the value rr->jitter is converging near to average delay d after couple of iterations (~100 for d=2 for example).
However your new formula below is resulting to more accurate average.
rr->jitter = (s->jitter + 8) >> 4;
Older formula is almost always lagging by nearly 1 ms (0.5 ms floating value) with the average delay.

May be your new formula can be updated in RFC.

Thank you.

Regards,
Nataraj

From: Kevin Gross [mailto:[email-masked]]
Sent: Wednesday, 26 March, 2014 7:22 PM
To: Nataraja Hosahalli
Cc: [email-masked]
Subject: Re: [AVTCORE] RFC3550: RTP Jitter value calculation

The formula looks basically correct. You need to look at the settling value for rr->jitter, not s->jitter (which is a state variable). In your example, s->jitter will settle at 32 and the correct value (2) will be reported for rr->jitter.

I think the accuracy of the reporting could be improved by changing the second line to:

On Wed, Mar 26, 2014 at 6:55 AM, Nataraja Hosahalli <[email-masked]<mailto:[email-masked]>> wrote:
Dear avtcore members,

          Section 3.8/ RFC 3550

      s->transit = transit;

      if (d < 0) d = -d;

Thanks in advance.

Regards,
Nataraj

Nataraja Hosahalli

Phone: +91 80 4024 8408<tel:%2B91%2080%204024%208408>
Mobile: +91 99860 25262<tel:%2B91%2099860%2025262>

_______________________________________________
Audio/Video Transport Core Maintenance
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/avt

---

From: Stephen Casner <[email-masked]>
Date: Wed, 26 Mar 2014 10:26:14 -0700 (PDT)

On Wed, 26 Mar 2014, Nataraja Hosahalli wrote:

> Hi Kevin,
>
> Yes you are right. I ran both the formulae and also your improved
> formula for 500 times with constant d value, the value rr->jitter is
> converging near to average delay d after couple of iterations (~100
> for d=2 for example).

That difference in accuracy is unimportant because the value is not
intended to be interpreted quantitatively.  This is an important
paragraph from RFC 3550:

   The interarrival jitter field provides a second short-term measure of
   network congestion.  Packet loss tracks persistent congestion while
   the jitter measure tracks transient congestion.  The jitter measure
   may indicate congestion before it leads to packet loss.  The
   interarrival jitter field is only a snapshot of the jitter at the
   time of a report and is not intended to be taken quantitatively.
   Rather, it is intended for comparison across a number of reports from
   one receiver over time or from multiple receivers, e.g., within a
   single network, at the same time.  To allow comparison across
   receivers, it is important the the jitter be calculated according to
   the same formula by all receivers.

The integer calculation was kept as simple as possible for use in
environments with constrained processing power.  In a modern DSP with
fast floating point calculations, this is not an issue, but 30-40
years ago we had to use fixed-point arithmetic in our array processors
and early DSPs.  The jitter calculation using a scaled value is an
example of that.

                                                        -- Steve

---

From: Kevin Gross <[email-masked]>
Date: Thu, 27 Mar 2014 15:35:54 -0600

For the purpose of comparing reports from multiple receivers, you want the
receivers to be using the same formula. The way it is currently specified,
integer and floating point implementations will give approximately the same
answer. My proposed "improvement" would produce different answers for
integer implementations. We don't want to do this.