Dial Results Question

[shardman]

Asterisk Version: 1.4.21.2
Vicidial Version: 2.2.0-206
OS: openSUSE 11.1
Kernel: 2.6.27.21-vicidial
T1 Card: 4x Verizon PRI on Sangoma A104

I was analyzing some of my dial result data and I had a few questions about my results. Here is a sample of my figures for a day of dialing. These are coming from vicidial_log table. I assume this is the place to look for the STATUS type results, versus something like the call_log table.

STATUS - COUNT - TYPE
AA - 12444 - System
B - 971 - System
DC - 614 - Agent
DROP - 274 - System
LMTC - 434 - Agent
N - 2347 - Agent
RPC - 275 - Agent
THRDP - 139 - Agent
TTSP - 7 - Agent
WRN - 410 - Agent

Not many surprises from me, it is collections lists and older debt. But I was curious about noanswers. My agents are getting passed calls that they are dispoing N (noanswer) but I'm not seeing NA (noanswer autodial) which I believe is the system noanswer. I was thinking I would see some Ns but I would expect quite a few NAs as well. My dial timeout is set to 26, so I am wondering if this is a factor... i.e. this is causing some other status to populate instead of NA, or if for some reason these might not be ending up anywhere... or worst case if all noanswers are getting passed to the agent for some reason. Also curious if something else seems out of the ordinary here... i.e. another system status is missing that should probably have had some hits. Just trying to make sure all the little things are as they should be. Any insight into this would be welcome.

[mflorell]

NAs are handled by the dialer and are not sent to agents. in the NA status are ring-no-answers, some disconnects and line congestion calls. If you want further breakdown of NAs you would need to use a system that can do Call Progress Analysis like the Sangoma CPD, but that is a licensed solution that costs money per port to use.

[shardman]

Yes that is what I thought was included in NA. I am just looking for NA statuses in the vicidial_log table or in the list information screen and not finding any which seems odd to me. Hope that makes sense.

[shardman]

I noticed today I have leads flagged as called but the STATUS remains as NEW and no entry appears in the vicidial_log table denoting an attempt. I could theorize that this might be related to my having no NA statused leads after a lengthy dial session. Can you think of a scenario that would cause this to occur?

[mflorell]

Calls that show attempts but stay as NEW are usually invalid phone numbers that could not be dialed in the dialplan as you have it set.

[shardman]

I could definitely see that for a few records but revisiting this today there are way too many. It is half my dial attempts today across 270 different area codes. 98% of them look like valid telephone numbers to me.

I have manually dialed random ones through the Vicidial web interface and I am getting a variety of results (disconnects, answering machines, no answers, people, etc). Am I correct in assuming that if the number is dialing manually that it should dial also for autodial and not be considered an invalid-to-dial number?

I still seem to think this may be related to the reason I am seeing not a single NA (noanswer autodial) over thousands and thousands of dial attempts. I know I should have a lot of these.

I have a feeling something is awry somewhere in my system, just not sure which direction the symptoms point in. I haven't done any modifications to my dialplan since receiving the system, only general frontend configuration (setting up campaigns, users, etc), plugging in 4 LD T1s, updating the IP address, etc.

Maybe it helps to know that I am using AMD -- it is a neccessity for us because 60%+ leads result in answering machines.

[shardman]

Was looking at the screenlog output and searching for some of these calls. Here are some of the output lines, I might be missing something, I only copied the lines that explicitly contained the phone number. Xd out the last 7 digits.

[I edited this to add a couple lines I was missing on the output...]

grep -n '702XXXXXXX' screenlog.0

321744:[Jul 10 10:07:03] -- Executing [91702XXXXXXX@default:1] AGI("Local/91702XXXXXXX@default-034f,2", "agi://127.0.0.1:4577/call_log") in new stack
321746:[Jul 10 10:07:03] -- Executing [91702XXXXXXX@default:2] Dial("Local/91702XXXXXXX@default-034f,2", "Zap/g1/1702XXXXXXX||To") in new stack
321748:[Jul 10 10:07:03] -- Called g1/1702XXXXXXX
321797:[Jul 10 10:07:03] -- Zap/15-1 is proceeding passing it to Local/91702XXXXXXX@default-034f,2
321798:[Jul 10 10:07:03] -- Zap/15-1 is making progress passing it to Local/91702XXXXXXX@default-034f,2
322431:[Jul 10 10:07:30] == Spawn extension (default, 91702XXXXXXX, 2) exited non-zero on 'Local/91702XXXXXXX@default-034f,2'
322432:[Jul 10 10:07:30] -- Executing [h@default:1] DeadAGI("Local/91702XXXXXXX@default-034f,2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----0-----CANCEL----------") in new stack

646320:[Jul 10 15:24:50] -- Executing [91702XXXXXXX@default:1] AGI("Local/91702XXXXXXX@default-ea53,2", "agi://127.0.0.1:4577/call_log") in new stack
646324:[Jul 10 15:24:50] -- Executing [91702XXXXXXX@default:2] Dial("Local/91702XXXXXXX@default-ea53,2", "Zap/g1/1702XXXXXXX||To") in new stack
646326:[Jul 10 15:24:50] -- Called g1/1702XXXXXXX
646351:[Jul 10 15:24:52] -- Zap/14-1 is proceeding passing it to Local/91702XXXXXXX@default-ea53,2
646352:[Jul 10 15:24:52] -- Zap/14-1 is making progress passing it to Local/91702XXXXXXX@default-ea53,2
646793:[Jul 10 15:25:17] == Spawn extension (default, 91702XXXXXXX, 2) exited non-zero on 'Local/91702XXXXXXX@default-ea53,2'
646794:[Jul 10 15:25:17] -- Executing [h@default:1] DeadAGI("Local/91702XXXXXXX@default-ea53,2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----0-----CANCEL----------") in new stack


grep -n '567XXXXXXX' screenlog.0

272748:[Jul 10 09:40:47] -- Executing [91567XXXXXXX@default:1] AGI("Local/91567XXXXXXX@default-990b,2", "agi://127.0.0.1:4577/call_log") in new stack
272750:[Jul 10 09:40:47] -- Executing [91567XXXXXXX@default:2] Dial("Local/91567XXXXXXX@default-990b,2", "Zap/g1/1567XXXXXXX||To") in new stack
272752:[Jul 10 09:40:47] -- Called g1/1567XXXXXXX
272762:[Jul 10 09:40:47] -- Zap/1-1 is proceeding passing it to Local/91567XXXXXXX@default-990b,2
272763:[Jul 10 09:40:47] -- Zap/1-1 is making progress passing it to Local/91567XXXXXXX@default-990b,2
273893:[Jul 10 09:41:13] == Spawn extension (default, 91567XXXXXXX, 2) exited non-zero on 'Local/91567XXXXXXX@default-990b,2'
273894:[Jul 10 09:41:13] -- Executing [h@default:1] DeadAGI("Local/91567XXXXXXX@default-990b,2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----0-----CANCEL----------") in new stack

646461:[Jul 10 15:24:56] -- Executing [91567XXXXXXX@default:1] AGI("Local/91567XXXXXXX@default-46ef,2", "agi://127.0.0.1:4577/call_log") in new stack
646463:[Jul 10 15:24:56] -- Executing [91567XXXXXXX@default:2] Dial("Local/91567XXXXXXX@default-46ef,2", "Zap/g1/1567XXXXXXX||To") in new stack
646465:[Jul 10 15:24:56] -- Called g1/1567XXXXXXX
646504:[Jul 10 15:24:57] -- Zap/29-1 is proceeding passing it to Local/91567XXXXXXX@default-46ef,2
646505:[Jul 10 15:24:57] -- Zap/29-1 is making progress passing it to Local/91567XXXXXXX@default-46ef,2
646962:[Jul 10 15:25:23] == Spawn extension (default, 91567XXXXXXX, 2) exited non-zero on 'Local/91567XXXXXXX@default-46ef,2'
646963:[Jul 10 15:25:23] -- Executing [h@default:1] DeadAGI("Local/91567XXXXXXX@default-46ef,2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----0-----CANCEL----------") in new stack

[mflorell]

Do you have the 'h' exten in every context of your dialplan?

[shardman]

I haven't done any dialplan editing myself sans the automatic editing that occurs using the web gui to create extensions (in extensions-vicidial.conf).

Just to save the spam of posting my entire dialplan I compared it to extensions.conf.sample-1.4 in docs and I will just note the differences since there are only a couple.


At the very top in the [globals] context my dialplan has this line:
TRUNKX=Zap/g1 ; 2nd trunk interface
Versus the sample which has this line:
TRUNKX=Zap/g2 ; 2nd trunk interface

My dialplan has this context that isn't in the sample:
[test]
exten => _X.,1,Meetme(8600900)




Here is my extensions-vicidial.conf:
; WARNING- THIS FILE IS AUTO-GENERATED BY VICIDIAL, ANY EDITS YOU MAKE WILL BE LOST


[vicidial-auto]
exten => h,1,DeadAGI(agi://127.0.0.1:4577/call_log--HVcauses ... ----------)

; Local Server: 192.168.10.10
exten => _192*168*010*010*.,1,Goto(default,${EXTEN:16},1)

exten => 101,1,Dial(IAX2/101)
exten => 101,2,Voicemail,u101
[...repeat the iax extensions...]



I don't see anything unusual about them but here are zaptel/zapata conf files:

====ZAPTEL.CONF====
#autogenerated by /usr/sbin/wancfg_zaptel do not hand edit
#autogenrated on 2009-06-25
#Zaptel Channels Configurations
#For detailed Zaptel options, view /etc/zaptel.conf.bak
loadzone=us
defaultzone=us

#Sangoma A104 port 1 [slot:4 bus:2 span:1] <wanpipe1>
span=1,0,0,esf,b8zs
bchan=1-23
hardhdlc=24

#Sangoma A104 port 2 [slot:4 bus:2 span:2] <wanpipe2>
span=2,0,0,esf,b8zs
bchan=25-47
hardhdlc=48

#Sangoma A104 port 3 [slot:4 bus:2 span:3] <wanpipe3>
span=3,0,0,esf,b8zs
bchan=49-71
hardhdlc=72

#Sangoma A104 port 4 [slot:4 bus:2 span:4] <wanpipe4>
span=4,0,0,esf,b8zs
bchan=73-95
hardhdlc=96


ZAPATA.CONF
;autogenerated by /usr/sbin/wancfg_zaptel do not hand edit
;autogenrated on 2009-06-25
;Zaptel Channels Configurations
;For detailed Zaptel options, view /etc/asterisk/zapata.conf.bak

[trunkgroups]

[channels]
context=default
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
relaxdtmf=yes
rxgain=0.0
txgain=0.0
group=1
callgroup=1
pickupgroup=1
immediate=no

;Sangoma A104 port 1 [slot:4 bus:2 span:1] <wanpipe1>
switchtype=national
context=trunkinbound
group=1
signalling=pri_cpe
channel =>1-23

;Sangoma A104 port 2 [slot:4 bus:2 span:2] <wanpipe2>
switchtype=national
context=trunkinbound
group=1
signalling=pri_cpe
channel =>25-47

;Sangoma A104 port 3 [slot:4 bus:2 span:3] <wanpipe3>
switchtype=national
context=trunkinbound
group=1
signalling=pri_cpe
channel =>49-71

;Sangoma A104 port 4 [slot:4 bus:2 span:4] <wanpipe4>
switchtype=national
context=trunkinbound
group=1
signalling=pri_cpe
channel =>73-95

[mflorell]

Could you post the first 4 digits of the phone numbers that still show as NEW?

[shardman]

SELECT DISTINCT LEFT(phone_number,4)
FROM `vicidial_list`
WHERE called_count > 0
AND STATUS = 'NEW'
ORDER BY LEFT(phone_number,4)

Records Total = 1839

Here are the first 25 / last 25:

2012
2013
2014
2015
2016
2017
2018
2019
2022
2023
2024
2025
2026
2027
2028
2029
2032
2033
2034
2035
2036
2037
2038
2039
2052
9787
9788
9789
9792
9794
9795
9796
9797
9798
9799
9852
9853
9854
9855
9856
9857
9858
9891
9892
9893
9894
9895
9896
9897
9898

[mflorell]

Well, nothing glaringly wrong there, are any of there phone numbers not 10 digits?

[shardman]

All my leads have 10 digit numbers as it is the only way the source collections software will store them.

[mflorell]

On existing client systems we only see NEW with called_count records on non-existant numbers or if a client has not set the call_log exten right before the Dial line. If those two things are not the issue I don't think we've ever had a problem on a properly configured system.