[SIPForum-discussion] Jitter measurement.

Thu Mar 14 10:18:31 UTC 2013

Also, its mentioned in RFC 1889 that
   The jitter field of the reception report is
   measured in timestamp units and expressed as an unsigned integer, but
   the jitter estimate is kept in a floating point. As each data packet
   arrives, the jitter estimate is updated:

However, in the sample calculation following that, it is computed as

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

If we use the above line, how will rr->jitter become a timestamp unit. Will it not remain in milli-seconds?
Should it not be something like ((u_int32) s->jitter) / 0.000125  (depending on the codec, assuming here we use A-law codec where clock frequency 1/8000 = 0.0000125)

Thanks,
Badri.

From: Badri Ranganathan
Sent: 13 March 2013 10:16
To: 'Pravat Singh'
Cc: discussion at sipforum.org
Subject: RE: [SIPForum-discussion] Jitter measurement.

Hi pravat/all,

During jitter calculation for a RTCP RR packet, at the final stage we sample the estimate as -

   rr->jitter = s->jitter >> 4; in case we have the jitter estimate calculations as floating point value.
   Or
   rr->jitter = (u_int32) s->jitter; in case we have jitter estimate calculation as a integer value.

Does anyone know the reason behind sampling the last jitter estimate in a RTP packet for a RTCP packet? Why not simply copy the latest jitter value in a RTP packet into the RTCP RR report as that is what the RTCP RR is meant to contain.

The entire calculation below -

       int transit = arrival - r->ts;
       int d = transit - s->transit;
       s->transit = transit;
       if (d < 0) d = -d;
       s->jitter += (1./16.) * ((double)d - s->jitter);

   When a reception report block (to which rr points) is generated for
   this member, the current jitter estimate is returned:

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

   Alternatively, the jitter estimate can be kept as an integer, but
   scaled to reduce round-off error. The calculation is the same except
   for the last line:

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

   In this case, the estimate is sampled for the reception report as:

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

Thanks,
Badri.

From: Pravat Singh [mailto:pravat.kumar at gmail.com]
Sent: 05 September 2011 17:10
To: Badri Ranganathan
Subject: Re: [SIPForum-discussion] Jitter measurement.

Thanks. As I don't know about your product positioning but RTCP is optional and some of the voip phones RTCP may not be enabled. If you are analyzing jitter somewhere in the middle of the network then relying on RTCP report always would be something to think about.

Regards,
Pravat

On Mon, Aug 29, 2011 at 1:28 PM, Badri Ranganathan <badri at arcatech.com<mailto:badri at arcatech.com>> wrote:
Thanks pravat.
Will this be done in the RTCP by default ?

Cheers,
Badri.

From: Pravat Singh [mailto:pravat.kumar at gmail.com<mailto:pravat.kumar at gmail.com>]
Sent: 28 August 2011 18:37
To: Badri Ranganathan
Subject: Re: [SIPForum-discussion] Jitter measurement.

Jitter is calculated as below.
J=J+(|D(i-1,i)|-J)/16
where
D(i,j)=(Rj-Ri)-(Sj-Si)=(Rj-Sj)-(Ri-Si)
All the variable definations and these informations are available in RFC 1889. One more important thing is while calculating jitter if the silence suppression is enabled then the jitter calculation should be reset after the begining of first packet of the talk sprut. Procedure is the same as how you started the calulation from the begining means check the conjugative 3 packets.

Hope this answers your question.

Regards,
Pravat Singh
Nokia Siemens Networks

On Tue, Aug 16, 2011 at 4:00 PM, Badri Ranganathan <badri at arcatech.com<mailto:badri at arcatech.com>> wrote:
Hi,

Can anyone tell me how "jitter" is "measured" ?

>From what I could gather from the internet -

<<=========================

Jitter is defined as a statistical variance of the RTP data packet inter-arrival time. In the Real Time Protocol, jitter is measured in timestamp units. For example, if you transmit audio sampled at the usual 8000 Hertz, the unit is 1/8000 of a second.

In RFC1889, I can see this definition under RTCP sender reports -

interarrival jitter: 32 bits

An estimate of the statistical variance of the RTP data packet interarrival time, measured in timestamp units and expressed as an unsigned integer. The interarrival jitter J is defined to be the mean deviation (smoothed absolute value) of the difference D in packet spacing at the receiver compared to the sender for a pair of packets. As shown in the equation below, this is equivalent to the difference in the "relative transit time" for the two packets; the relative transit time is the difference between a packet's RTP timestamp and the receiver's clock at the time of arrival, measured in the same units.

===========================>>

Here it says its measured in timestamp units. Cant understand this explanation much. Why cant it be expressed in milliseconds ?

Thanks,
Badri.

-----Original Message-----
From: discussion-bounces at sipforum.org<mailto:discussion-bounces at sipforum.org> [mailto:discussion-bounces at sipforum.org<mailto:discussion-bounces at sipforum.org>] On Behalf Of Steve Underwood
Sent: 13 August 2011 08:58
To: Rohan Almeida
Cc: discussion at sipforum.org<mailto:discussion at sipforum.org>
Subject: Re: [SIPForum-discussion] SIP Faxing

A key question is 15% of what kind of calls fail? If you are talking
about a public FAX server, open to all, you might well see 15% to 20% of
failed calls from wrong numbers, voice calls to FAX numbers, etc. If you
are making test calls into a well controlled server and get 15%
failures, that pretty nasty. You should be getting less than 1%
failures, even if the calls are sending tens of pages each.

Steve

On 08/13/2011 01:14 PM, Rohan Almeida wrote:
> 15% failure is too high. 2-10 % is on an average is acceptable.
> but again the fault might not be only in your system. the interconnect
> devices might also be the cause.
>
> On Tue, Aug 9, 2011 at 9:52 AM, Greg Settle <gsettle at opentext.com<mailto:gsettle at opentext.com>
> <mailto:gsettle at opentext.com<mailto:gsettle at opentext.com>>> wrote:
>
>     What is the topology?
>
>     SIP trunk - SBC/gateway - fax server?  If yes, who is the SIP trunk
>     provider?  Do they support T.38 FoIP?
>     T1/PRI - gateway - fax server?  If yes, which gateway(s) is involved?
>     Support for T.38?
>
>     Assuming a fax server is involved?  If yes, which fax server?
>
>     Generally, if T.38 FoIP is supported among all endpoints, and proper
>     testing was done to verify configuration among the components, SIP
>     faxing failure rates should remain low.  15% failure rate is high, and
>     points to weak links in the topology where FoIP standards (T.38)
>     are not
>     being met.  Attached is a document which may assist.
>     Greg
>
>     -----Original Message-----
>     From: discussion-bounces at sipforum.org<mailto:discussion-bounces at sipforum.org>
>     <mailto:discussion-bounces at sipforum.org<mailto:discussion-bounces at sipforum.org>>
>     [mailto:discussion-bounces at sipforum.org<mailto:discussion-bounces at sipforum.org>
>     <mailto:discussion-bounces at sipforum.org<mailto:discussion-bounces at sipforum.org>>] On Behalf Of Steve Underwood
>     Sent: Monday, August 08, 2011 9 <tel:2011%209>:47 AM
>     To: discussion at sipforum.org<mailto:discussion at sipforum.org> <mailto:discussion at sipforum.org<mailto:discussion at sipforum.org>>
>     Subject: Re: [SIPForum-discussion] SIP Faxing
>
>     On 08/04/2011 09:40 PM, Melissa Parsons wrote:
>     >
>     > Hello,
>     >
>     > Can anyone tell me what an acceptable failure rate would be when
>     > faxing over SIP? Currently we are averaging around 15%. This
>     number is
>
>     > high I would expect it to be somewhat higher than traditional faxing
>     > but not this high.
>     >
>     > Thank you,
>     >
>     > *Melissa Parsons*|Enterprise Systems Engineer
>     >
>     > *MarineMax, Inc.* ( 727.531.1700 <tel:%28%20727.531.1700> office
>     | (727.524-3954 <tel:%28727.524-3954> fax
>     >
>     > 18167 US Hwy. 19 N. Clearwater, Florida 33764 <tel:33764>
>     >
>     >
>     That's vague. Are you using A-law or u-law? Are you using G.726?
>     Are you
>
>     using T.38? Pretty much anything else you might use will give 0
>     success
>     rate, so I assume its one of those. The failure rate you get will
>     depend
>
>     on many factors. A high packet loss rate is a disaster for FAX. High
>     jitter levels for the packet delivery time can be too. T.38
>     implementations are quite variable in their behaviour, and not always
>     that compatible. Many quirks in the SIP signalling arrangements
>     exist in
>
>     various implementations, too. At the end of the day you'll get
>     somewhere
>
>     between 0 and 100% success, depending on all these factors. Between
>     servers in large data centres, connected straight on to the internet's
>     backbone you might be able to send FAXes all week without an error. In
>     really bad tributaries of the internet you might get a near 100%
>     failure
>
>     rate.
>
>     Regards,
>     Steve
>     _______________________________________________
>     This is the SIP Forum discussion mailing list
>     TO UNSUBSCRIBE, or edit your delivery options, please visit
>     http://sipforum.org/mailman/listinfo/discussion
>     Post to the list at discussion at sipforum.org<mailto:discussion at sipforum.org>
>     <mailto:discussion at sipforum.org<mailto:discussion at sipforum.org>>
>
>     _______________________________________________
>     This is the SIP Forum discussion mailing list
>     TO UNSUBSCRIBE, or edit your delivery options, please visit
>     http://sipforum.org/mailman/listinfo/discussion
>     Post to the list at discussion at sipforum.org<mailto:discussion at sipforum.org>
>     <mailto:discussion at sipforum.org<mailto:discussion at sipforum.org>>
>
>

_______________________________________________
This is the SIP Forum discussion mailing list
TO UNSUBSCRIBE, or edit your delivery options, please visit http://sipforum.org/mailman/listinfo/discussion
Post to the list at discussion at sipforum.org<mailto:discussion at sipforum.org>

__________ Information from ESET Smart Security, version of virus signature database 6380 (20110815) __________