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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:asterisk-users- > [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]:1] NoOp("SIP/edge1-09baf358", "local_ssrc = 891055531") in new stack -- Executing [EMAIL PROTECTED]:2] NoOp("SIP/edge1-09baf358", "local_lostpackets = 1215") in new stack -- Executing [EMAIL PROTECTED]:3] NoOp("SIP/edge1-09baf358", "local_jitter = 3") in new stack -- Executing [EMAIL PROTECTED]:4] NoOp("SIP/edge1-09baf358", "local_count = 1124") in new stack -- Executing [EMAIL PROTECTED]:5] NoOp("SIP/edge1-09baf358", "remote_ssrc = 59917798") in new stack -- Executing [EMAIL PROTECTED]:6] NoOp("SIP/edge1-09baf358", "remote_lostpackets = 1") in new stack -- Executing [EMAIL PROTECTED]:7] NoOp("SIP/edge1-09baf358", "remote_jitter = 0") in new stack -- Executing [EMAIL PROTECTED]:8] NoOp("SIP/edge1-09baf358", "remote_count = 1123") in new stack -- Executing [EMAIL PROTECTED]: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.
_______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
