issues with a survey campaign

[dransiksapoc]

Install method: goautodial 3.3/centos 5.x repo (the servers are managed remotely)

vicidial version: 2.9-441a

installed on a 7 box cluster: 5 Asterisk/1 web/1 database

dial plan/extension (one of 5 using 5 sip accounts from the same provider, identical setup, just different users/secrets

Code: Select all

[CP1]
disallow=all
allow=ulaw
type=friend
dtmfmode=rfc2833
context=trunkinbound
qualify=yes
insecure=very
nat=yes
host=dialer.sip.commpeak.com
username=xxxxxxxxxxxxx
secret=xxxxxxxxxx

[vitel-inbound1]
type=friend
dtmfmode=auto
host=xxxxxxxx
context=trunkinbound
allow=all
insecure=port,invite
canreinvite=no

[vitel-inbound2]
type=friend
dtmfmode=auto
host=xxxxxxxxxx
context =trunkinbound
allow=all
insecure=port,invite
canreinvite=no

[vitel-outbound]=undefined
type=friend
dtmfmode=auto
host=xxxxxxx
allow=all
canreinvite=no


Code: Select all

exten => _9XXXXXXXXXXX.,1,AGI(agi://127.0.0.1:4577/call_log)
exten => _9XXXXXXXXXXX.,2,Dial(SIP/${EXTEN:12}@CP1,,tTo)
exten => _9XXXXXXXXXXX.,3,Hangup


I followed the poundteam manual for a cluster setup and it worked pretty well given I was using a goautodial install, had to make some small tweaks because of certain default settings goautodial installs with. That being said I did a full install on all the boxes to start, tested and they worked normally then did the clustering and turned off unnecessary services on all the boxes. One thing of note that I've not fixed yet is that my webserver acting as my audiostore isn't replicating uploaded audios to the asterisk server, I had to do that manually and I've not got back to it since as doing it manually solved the problem albeit temporarily.

The system as it stands it setup to make 6 CPS on a 500 Channel limit and does it well, I wanted to make it possible to run 500 calls in the campaign so I set the remote agents lines field from tiny int to int.

Bottom line everything seems to be working properly except in my issue here with the survey campaign. I tested and everything seemed to work and right before we went in to a production test I realized a number of people were pressing 1 yet we weren't seeing them pop on to the couple test agents we had on. So I did more testing, turns out you get "I'm sorry this is not a valid extension" played as the prospective client. Strangely it seemed to work when agents first logged in and then quit working after the first call they took. Then again logging out and then back in again didn't seem to fix it either so I'm not sure it seems pretty random now, but definitely leaning to mostly not working. Here are examples of a working transfer and the mostly non working ones. Any insight would be most appreciated, I'll be digging in to it, but help pointing me on to things I've not looked at would be a life saver.

working

Code: Select all

[Jun 29 07:18:29] VERBOSE[5346] pbx.c:     -- Executing [8366@default:3] AGI("SIP/CP3-00000006", "agi-VDAD_ALL_outbound.agi,SURVEYCAMP-----LB") in new stack
[Jun 29 07:18:29] VERBOSE[5346] res_agi.c:     -- Launched AGI Script /var/lib/asterisk/agi-bin/agi-VDAD_ALL_outbound.agi
[Jun 29 07:18:30] VERBOSE[5346] res_agi.c:     -- Playing 'sip-silence' (escape_digits=) (sample_offset 0)
[Jun 29 07:18:30] VERBOSE[5346] res_agi.c:     -- Playing 'go_broadcast' (escape_digits=1238) (sample_offset 0)
[Jun 29 07:18:30] VERBOSE[5322] res_agi.c:     -- <Local/916027996165@default-00000005;2>AGI Script agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16-----ANSWER-----11-----0 completed, returning 0
[Jun 29 07:18:30] VERBOSE[5322] pbx.c:   == Spawn extension (default, 916027996165, 2) exited non-zero on 'Local/916027996165@default-00000005;2'
[Jun 29 07:18:38] DTMF[5346] channel.c: DTMF begin '1' received on SIP/CP3-00000006
[Jun 29 07:18:38] DTMF[5346] channel.c: DTMF begin ignored '1' on SIP/CP3-00000006
[Jun 29 07:18:38] DTMF[5346] channel.c: DTMF end '1' received on SIP/CP3-00000006, duration 270 ms
[Jun 29 07:18:38] DTMF[5346] channel.c: DTMF end passthrough '1' on SIP/CP3-00000006
[Jun 29 07:18:38] VERBOSE[5346] res_agi.c:     -- <SIP/CP3-00000006>AGI Script agi-VDAD_ALL_outbound.agi completed, returning 0
[Jun 29 07:18:38] VERBOSE[5346] pbx.c:     -- Executing [069*060*115*250*8600051@default:1] Goto("SIP/CP3-00000006", "default,8600051,1") in new stack
[Jun 29 07:18:38] VERBOSE[5346] pbx.c:     -- Goto (default,8600051,1)
[Jun 29 07:18:38] VERBOSE[5346] pbx.c:     -- Executing [8600051@default:1] MeetMe("SIP/CP3-00000006", "8600051,F") in new stack
[Jun 29 07:18:42] VERBOSE[5346] pbx.c:   == Spawn extension (default, 8600051, 1) exited non-zero on 'SIP/CP3-00000006'
[Jun 29 07:18:42] VERBOSE[5346] pbx.c:     -- Executing [h@default:1] AGI("SIP/CP3-00000006",


not working

Code: Select all

[Jun 29 07:44:55] VERBOSE[10297] pbx.c:     -- Executing [8366@default:3] AGI("SIP/CP3-00000191", "agi-VDAD_ALL_outbound.agi,SURVEYCAMP-----LB") in new stack
[Jun 29 07:44:55] VERBOSE[10297] res_agi.c:     -- Launched AGI Script /var/lib/asterisk/agi-bin/agi-VDAD_ALL_outbound.agi
[Jun 29 07:44:55] VERBOSE[10297] res_agi.c:     -- Playing 'sip-silence' (escape_digits=) (sample_offset 0)
[Jun 29 07:44:55] VERBOSE[10297] res_agi.c:     -- Playing 'go_broadcast' (escape_digits=1238) (sample_offset 0)
[Jun 29 07:44:56] VERBOSE[10282] res_agi.c:     -- <Local/916027996165@default-00000190;2>AGI Script agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16-----ANSWER-----13-----0 completed, returning 0
[Jun 29 07:44:56] VERBOSE[10282] pbx.c:   == Spawn extension (default, 916027996165, 2) exited non-zero on 'Local/916027996165@default-00000190;2'
[Jun 29 07:45:03] DTMF[10297] channel.c: DTMF begin '1' received on SIP/CP3-00000191
[Jun 29 07:45:03] DTMF[10297] channel.c: DTMF begin ignored '1' on SIP/CP3-00000191
[Jun 29 07:45:03] DTMF[10297] channel.c: DTMF end '1' received on SIP/CP3-00000191, duration 270 ms
[Jun 29 07:45:03] DTMF[10297] channel.c: DTMF end passthrough '1' on SIP/CP3-00000191
[Jun 29 07:45:03] VERBOSE[10297] res_agi.c:     -- <SIP/CP3-00000191>AGI Script agi-VDAD_ALL_outbound.agi completed, returning 0
[Jun 29 07:45:03] VERBOSE[10297] pbx.c:     -- Sent into invalid extension '069*060*114*195*8300' in context 'default' on SIP/CP3-00000191
[Jun 29 07:45:03] VERBOSE[10297] pbx.c:     -- Executing [i@default:1] Playback("SIP/CP3-00000191", "invalid") in new stack
[Jun 29 07:45:03] VERBOSE[10297] file.c:     -- <SIP/CP3-00000191> Playing 'invalid.gsm' (language 'en')


Again thanks and let me know if you want to see anything else.

[dransiksapoc]

So admittedly I'm tired but...."Sent into invalid extension '069*060*114*195*8300'" I can see that's wrong....why would it be trying to send to an extension on an IP that doesn't even have asterisk turned on?

*update* so I see both the webservers and db IP's as having references to conferences in the conferences table. By removing the DB reference's to both would that effectively stop the attempt to transfer to those servers?

[williamconley]

So admittedly I'm tired but...."Sent into invalid extension '069*060*114*195*8300'" I can see that's wrong....why would it be trying to send to an extension on an IP that doesn't even have asterisk turned on?

*update* so I see both the webservers and db IP's as having references to conferences in the conferences table. By removing the DB reference's to both would that effectively stop the attempt to transfer to those servers?

Never seen that before, but 8300 is not an agent's extension or a meetme room. You'll need to find the screen/function that made the decision to send it there.

Screens are available via "screen -list" and then "screen -r XXXXXX" replace the X's with the name of a screen. Ctrl-A Ctrl-D to exit the screen session (be careful while viewing a screen, you're in the mind of Vicidial and any thoughts you type while in there will confuse it ... and definitely avoid Ctrl-C which would stop the brain).

Logs are in /var/log/astguiclient. Somehow the decision-making process is deciding to send the call to that location. It could be a dropped call scenario ... and the 8300 is merely the method of the drop. And if you manually clustered this old version of Vicidial ... wow.

Maybe you should look at upgrading to the latest version. Perhaps you found an old flawed release and it's already been fixed.

PS: Probably better to revise the original post if there have been no new posts. I thought your ticket had been responded to already, and moved on to other "Unanswered" posts. The BBS system believed yours to be answered, since there was a second post ...

[dransiksapoc]

going to go ahead and dig in to it today. Will also seriously consider an update to vici. My cluster definitely isn't working as well as I would like. Load Balancing only kind of seems to work, it looks like it overloads (not badly but not they way I would like) above the channel limit I've set for each box, at 100 but looking like it's actually dialing closer to 150. Also after running a good test today after a couple of hours it plain just quit trying to use all but 3 of the asterisk servers and the 3rd rarely despite setting the campaign to 500 on the remote agent...... Digging in to the logs now to find out what actually happened but yeah, willing to bet based on your "wow" this may be residual issues of the version.

[dransiksapoc]

Maybe I looked in completely the wrong place but as far as I can tell the vicidial version is not that old is it not?

[mflorell]

The version you are using is over a year old, but the problem might also be that you are using GoAutoDial/CentOS, which we never recommend using.

We have Vicidial clusters on older versions running over a million calls a day in Survey campaigns across 20 dialers with no issues, but they are all vicibox/OpenSuSE on SuperMicro hardware.

[williamconley]

My opinion is always the same in this "well, that's odd ..." scenario.

Reinstall a fresh new copy of Vicibox's latest .iso image. Then bring in JUST the leads from the old server (export and then import with the command line lead loader) to avoid any infection of weird problems from the old system.

Now you have all your leads in a fresh server with the latest code that's been tested by hundreds of call centers across the globe. Yep, you'll have to re-build your users and campaigns, but life goes on.

Just a wee bit of advice, but note that it was given by someone who maintains a LOT of Vicidial servers and we really try to avoid "freaky" problems. Kumba makes that easy by giving us a free installer that gives us easy access to the latest code. We don't have daily problems with servers, they ... just run.