Inbound works in test then doesn't in production...

[dransiksapoc]

Long story short my inbound works when I first start a survey campaign, I can call inbound dids and it transfers to me. One agent, myself, logged in. When I go in to production I see agents waiting and inbound calls sitting in the queue, at first a couple may actually transfer to an agent, but literally just in the first couple of minutes and then it doesn't transfer any in at all.....from a client perspective they get the default music on hold until they hang up. I don't really know where to begin to start debugging this one, hopping a couple of you may point me in the right direction. The CLI show's everything, I believe, as normal. Just the calls don't transfer to the agents.

Running up to 500 channels on the remote agent on 5 asterisk boxes setup to cap at 100 each at 6 CPS.

I have 190+ DID's all pointing to one asterisk box, all working in testing.

Trunkinbound is the context on all 5 separate carrier entries on the boxes.

Ingroup was created and I have all agents "selected" by default in admin to automatically be blended and part of that ingroup.

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.

[Acidshock]

What is your default option for the survey and its timeout? What do you have your options set to on the survey?

[williamconley]

First of all I don't see the connection based on your description of Inbound and Survey Campaign. Survey campaigns are outbound ... and in no way connected to "inbound".

Second: I've noted that Call Priority has caused challenges in the past. If any of your call priorities are set to above Zero, other calls will often get "stuck" waiting for them, even though they will never arrive for whatever reason (like AMD, Survey, etc).

[dransiksapoc]

Thanks for the response, didn't have a chance to post back (enjoyed a long weekend) figured it out and it was absolutely a priority issue with agentdirect defaulting at 99, although I fixed it not by dropping the priority of AD and instead bumped the priority of the inbound group to 99. Yeah the survey was of no relevance just being thorough in the post. When I'm at a complete loss and post, I try to include all of the variables I can think of.

[williamconley]

Thanks for the response, didn't have a chance to post back (enjoyed a long weekend) figured it out and it was absolutely a priority issue with agentdirect defaulting at 99, although I fixed it not by dropping the priority of AD and instead bumped the priority of the inbound group to 99. Yeah the survey was of no relevance just being thorough in the post. When I'm at a complete loss and post, I try to include all of the variables I can think of.

Entirely understandable.

Advice: Change all priorities to Zero. Trust me.