Unable to start 3-way with inbound call.

[Two8nine]

Vicidial version: 2.14-694a
Vicidial build: 181005-1738
Asterisk version: 13.21.1-vici

Hi, I suspect this is just a config issue, but hoping for some pointers.

We do primarily Outbound work, but have recently started some inbound.

Both outbound and inbound require us the ability to engage in 3-way calls with a third party.

We have no issues doing this with outbound calls, but I have not been able to get it working with Inbound calls.

What I struggle to understand is there are no indications of a problem, and it seems to work. Here are two examples of API responses.

Agent ready in campaign, Agent manually dials customer, Agent initiates 3-way while connected:

agent_status output:
INCALL,M2201208270002292928,2292928,195100,3,AGENT NAME,AGENTS,1,LOGIN,,PHONE NUMBER,,8600065
transfer command sent:
SUCCESS: transfer_conference function set - DIAL_WITH_CUSTOMER||PHONE NUMBER|NO|102|M2201208270002292928|

Call then rings and all is well.

--------------------------------------

Agent ready in campaign, customer calls into ingroup, call connects, Agent attempts to start 3-way:

agent_status output:
INCALL,Y2201209590002292959,2292959,195100,11,AGENT NAME,AGENTS,1,LOGIN,,PHONE NUMBER,WELCOME_POOL,8600067
transfer command sent:
SUCCESS: transfer_conference function set - DIAL_WITH_CUSTOMER||PHONE NUMBER|NO|102|Y2201209590002292959|

---------------------------------------

Despite similar outputs, in the second case, nothing happens. The agent web interface lists the call as placed, but the call never rings for anyone.

[williamconley]

Installation method could be an important factor in this issue. Please remember to post it on all threads.

I do see what appears to be an audio file request (welcome pool?) which may or may not invoke a different process and if that process fails it may actually kill the script. Try looking at the Asterisk Console (in the Asterisk Screen: "screen -r asterisk") during an attempt to see if any perl errors pop up in an agi script. Those errors are not visible anywhere else and that is arguably why Asterisk is running in a screen: To expose those perl errors which are not available or stored anywhere else.

The asterisk manager script is responsible for processing those requests once created. The asterisk manager table should have information on the progress of the call as it happens.

Happy Hunting!