Setting up custom routing extension for auto-dial campaign

[tchristeas]

Hello,

I've setup an agentless auto-dial campaign (dial method: RATIO) and I'm running into issues when I set the routing extension to a value other than the standard 8368, 8369. Calls go out when I use 8368 or 8369. I created a user, a remote agent and phone = 83961. I added the custom dialplan inside extensions.conf

[custom_nudial]
; === Custom AMD Routing for EarlyCure_38 ===
exten => 83691,1,Set(CAMPAIGN_ID=EARLYCURE_38)
same => n,AGI(agi://127.0.0.1:4577/call_log)
same => n,Playback(sip-silence)
same => n,AMD(2000,2000,1000,5000,120,50,4,256)
same => n,AGI(VD_amd.agi,${EXTEN})
same => n,AGI(agi-VDAD_ALL_outbound.agi,NORMAL-----LB-----${CONNECTEDLINE(name)})
; Route based on AMD result + campaign_id
same => n,GotoIf($["${AMDSTATUS}"="HUMAN"]?amd-route,8368,1)
same => n,GotoIf($["${AMDSTATUS}"="MACHINE"]?amd-route,8369,1)
same => n,Goto(amd-route,8369,1) ; fallback to machine

With a softphone, I can place a call into extension 83691. I can even initiate an outbound call via the Asterisk CLI. However when I let the campaign attempt to place the outbound call I can see the following in the real time screen, I can see the following 1 calls being placed, 1 calls ringing. I can confirm when I am running CLI with sip debug enabled that no calls are being placed or attempted. I suspect that it has to do with the remote agent setup. The way I understand it, is for agentless campaigns you need to setup a remote agent to allow VICI to place the outbound calls. Any suggestions would be greatly appreciated.


Server info....
Vicibox 11.0.1 from .iso (ViciBox_v11.x86_64-11.0.1.iso) | Vicidial: 2.14-710c BUILD: 240830-1112 |Asterisk: 16.30.0-vici Single Server | No Digium/Sangoma Hardware | No Extra Software After Installation |

Bare metal server with the following
32 GB Ram
500 GB disk space
Intel(R) Xeon(R) E-2236 CPU @ 3.40GHz
12 CPU(s)

[williamconley]

You have placed the custom Routing Extension somewhere other than [default]. Move it to [default] directly. In fact, find the existing Routing Extension for 8368 and put it below that one directly in the .conf file. (do not use your own [context] at all! leave any [contexts] off!)

But ... WHY are you using a custom Routing Extension?

Note that the admin custom dialplan entry for a server or "System" does not make the dialplan available to the base/core vicidial coding. That is meant to be segregated from whatever you cooky IT guys cook up to protect you from yourselves. Which returns me to the question above: Why do you need a custom Routing Extension?

[tchristeas]

Thanks for the quick reply... Basically I have several dozen outbound auto dial campaigns that I am migrating to our Vicidial server.... The way I understand it works is you have to create a campaign where dialing type = RATIO and then you have to setup a remote agent and assign it to the campaign (in this case I created a remote agent = 83691). I also have the following setup at the campaign level...

Routing Extensions: 8369 (since I need to be able to separate live/human from answering machine)
AMD Type: AMD
AMD Send to Action: Y

I created the dialplan for one of my auto dial campaigns and I basically need to integrate that with my auto dial campaign. In other words an outbound call goes out... After executing the 8369 dialplan entry route the call to the correct campaign dialplan and execute the call flow within the dialplan. Hope that makes sense.

Regards
Ted

[williamconley]

OK: If you want an 'agentless remote agent' campaign, you need only create a remote agent with an external extension that successfully dials whoever is getting these calls. Assign that "remote user" to the campaign in question (it's a dropdown in the remote user) and activate the remote user (status: active). It is not necessary to create a custom anything or edit any configuration files.

Note that dialing "83691" does not call any phone in any country in the US. Plus having remote agent whose ID is 83691 would not actually DIAL 83691, it would dial whatever the external extension is for remote agent 83691, and that should be (if in the us) a 10 digit US phone number plus the dial prefix (used to choose the Carrier) and "1" eg if the carrier's dial prefix is 9: external extension "913522690000". Plus, of course, the remote user id should match a USER. There's no reason for that user ID/remote user ID to be 8369### anything. Try 1000. That's a nice user ID and remote user id.

External extensions include individuals on cell phones, call center inbound DIDs (which would be assisted with "number of lines" above 1 to account for the actual agents in that call center) or even AI or 3rd party menuing systems. Any of these still require that your Carrier (admin->carriers) be configured to route the call to the external extension in question. If you can dial the number from a registered SIP phone (in admin->phones), then your "external extension" should also work EXCEPT of course for calling other extensions. Those must be extensions configured with the correct "exten context" and "phone context" to be reached just like a carrier. Generally "default" (which is of course the default for a new phone when added).

Of course, if you are an asterisk person and capable of creating a sip->sip server link (or iax, of course) and want to dial some other pattern on another system: The carrier entry would change but not much else. And you should still include the dial prefix to allow multiple outbound routes in the future (in case you want to send calls to other call centers and don't want to have to rethink the configuration when the time comes).

Step one: configure and test a SIP phone.
Step two: configure and test a carrier to call external extensions from the sip phone
Step three: configure and test a campaign/list with the LOGGED IN AGENT using the previous sip phone and a user.
Step four: configure a remote agent.
Step five: log out of the sip phone/user and change the remote agent to "active".

Of course, the best way to do this (really) is to start age page one of the Vicidial manager's manual (free and paid versions available on EFLO.net) and DO NOT SKIP ANY PAGES. When you get to the point that everything works, you can stop. But do not skip. If you screw it up, delete everything and start over (yes: i even recommend reinstalling from the .ISO: it's free, you'll be much more comfortable with the system when you get it working, the "Magic!" will be gone and it'll just be configuration options that you are very familiar with).