[asterisk-users] Measuring Jitter in Asterisk

[Douglas Garstang]

I also just plugged a NoOp(${CHANNEL}) in the output. It does not matter
WHICH channel hangs up the call. The ${CHANNEL} variable is always set
to the second, outgoing call leg.

What does this mean? Why is that the case?

 

 

 

________________________________

From: asterisk-users-bounces at lists.digium.com
[mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of Douglas
Garstang
Sent: Thursday, August 09, 2007 12:47 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] Measuring Jitter in Asterisk

 

> -----Original Message-----

> From: asterisk-users-bounces at lists.digium.com [mailto:asterisk-users-

> bounces at lists.digium.com] On Behalf Of John Todd

> Sent: Wednesday, August 08, 2007 5:08 PM

> To: Asterisk Users Mailing List - Non-Commercial Discussion

> Subject: Re: [asterisk-users] Measuring Jitter in Asterisk

> 

> At 3:33 PM -0700 2007/8/3, Douglas Garstang wrote:

> >  > At 12:31 PM -0700 2007/8/3, Douglas Garstang wrote:

> >>  >

> >>  >How can I objectively measure jitter in Asterisk on a SIP
channel?

> >>  >

> >>  >I don't just want to turn the new 1.4 jitter buffer on. I want to

> >>  >measure jitter.

> >>  >

> >>  >Thanks,

> >>  >Doug.

> >>

> >>  You could look at the txjitter and rxjitter values (and other
values)

> >>  stored in the CHANNEL() function, and those values you're looking
for

> >>  were previously known as RTPAUDIOQOS.  Or is this not sufficient?

> >

> >Are txjitter and rxjitter working reliably? These calls are going to
be

> >placed from AMI and bridged together. Do you think the variables
would

> >be correctly set for each leg of the call?

> >

> >Doug.

> 

> I think the best way to determine this would be to compare the

> numbers provided by CHANNEL() versus the numbers provided by

> something with a little more reliability, such as wireshark, in a

> controlled set of circumstances.

> 

> Please post your results here - it would be an interesting test.

 

No comparisons yet, but I may not need to.

I'm not feeling too confident with the figures in Asterisk to begin
with.

 

I had an Asterisk box, bridging two channels, where the media was going
to two different ITSP's. 

Upon hangup of the call, I was printing out the QoS stats available with
the CHANNEL(rtpqos) command. That seems to be what's implemented in
Asterisk 1.4.8.

 

    h => {

        Noop(local_ssrc         = ${CHANNEL(rtpqos,audio,local_ssrc)});

        Noop(local_lostpackets  =
${CHANNEL(rtpqos,audio,local_lostpackets)});

        Noop(local_jitter       =
${CHANNEL(rtpqos,audio,local_jitter)});

        Noop(local_count        = ${CHANNEL(rtpqos,audio,local_count)});

        Noop(remote_ssrc        = ${CHANNEL(rtpqos,audio,remote_ssrc)});

        Noop(remote_lostpackets =
${CHANNEL(rtpqos,audio,remote_lostpackets)});

        Noop(remote_jitter      =
${CHANNEL(rtpqos,audio,remote_jitter)});

        Noop(remote_count       =
${CHANNEL(rtpqos,audio,remote_count)});

        Noop(rtt                = ${CHANNEL(rtpqos,audio,rtt)});

    }

 

When the call is hung up, I only see the output from this once. I'd
never thought about it before, but when you hang up a call, where two
channels are bridged, the hangup extension only gets called once for the
call, not once for each channel. Correct?

 

So, my output looked like this...

 

Connected to Asterisk 1.4.8 currently running on a1 (pid = 30914)

Verbosity is at least 3

a1*CLI> show channels

Channel              Location             State   Application(Data)


SIP/edge1-09bad778   (None)               Up      Bridged
Call(SIP/edge1-09baf35

SIP/edge1-09baf358   13033372500 at Outbound Up
Dial(SIP/edge1/13033372500|60|

2 active channels

1 active call

  == Spawn extension (Outbound, 13033372500, 2) exited non-zero on
SIP/edge1-09baf358'

    -- Executing [h at Outbound:1] NoOp("SIP/edge1-09baf358", "local_ssrc
= 891055531") in new stack

    -- Executing [h at Outbound:2] NoOp("SIP/edge1-09baf358",
"local_lostpackets  = 1215") in new stack

    -- Executing [h at Outbound:3] NoOp("SIP/edge1-09baf358", "local_jitter
= 3") in new stack

    -- Executing [h at Outbound:4] NoOp("SIP/edge1-09baf358", "local_count
= 1124") in new stack

    -- Executing [h at Outbound:5] NoOp("SIP/edge1-09baf358", "remote_ssrc
= 59917798") in new stack

    -- Executing [h at Outbound:6] NoOp("SIP/edge1-09baf358",
"remote_lostpackets = 1") in new stack

    -- Executing [h at Outbound:7] NoOp("SIP/edge1-09baf358",
"remote_jitter      = 0") in new stack

    -- Executing [h at Outbound:8] NoOp("SIP/edge1-09baf358", "remote_count
= 1123") in new stack

    -- Executing [h at Outbound:9] NoOp("SIP/edge1-09baf358", "rtt
= 0") in new stack

 

So, what do the totals represent? We're getting stats for two channels
added together it seems. Is local_jitter local jitter on both channels?
If so, it's completely useless. We need to be able to see stats for EACH
CHANNEL, otherwise they mean nothing.

 

Also, rtt is always 0. Man... the internet is fast today. Also,
local_lostpackets looks bogus. It's always some huge number, larger than
local_count.

 

Don't know if it's relevant, but this Asterisk box sent the call to an
edge router, than would sent the call onto the ITSP, and then drop out
of the RTP path. This Asterisk box was in the media, but the edge router
was not.

 

Doug.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20070809/a0fbf0e5/attachment.htm