InGroup with OnHook and customer_phone as CID not working

[GaD]

Hello everyone

I am currently experiencing some issues with inbound campaigns that have On-Hook agents in Vicidial. I am selecting the option that the On-Hook CID be CUSTOMER_PHONE. It happens that when the call comes in it rings the agent's phone but when the agent picks up the call it hangs up after a few seconds. I do not even hear the Agent Alert telling the agent what ingroup the call is coming from. I've tried several options and only RA_AGENT_PHONE seems to work, all other will just hang up the call after close to three seconds. Not sure what may be causing the issue. The logs are not saying much. I've looked into the agi log and I can't figure it out.

Here is my setup:
Vici version: 2.14-858a | Build: 220513-0819 | SVN Version: 3604 | DB Schema: 1661 | Asterisk version: 13.38.2-vici

[williamconley]

1) Note that you have specified when the customer_phone as CID, but not mentioned at all whether that setting is related to the problem. Does the problem occur when you have NOT set the customer phone as the CID?

2) Are the agent phones Vicidial/Asterisk SIP phones, or external phones such as Cell phones?

3) Does CLI output in asterisk show an error for this recording? (which would kill the call, of course).

[GaD]

When I use the GENERIC and the RA_AGENT_PHONE seetings in the On-Hook CID field of the Ingroup, it works, but when I chose the CUSTOMER_PHONE, CUSTOMER_PHONE_RINGAGENT and CUSTOMER_PHONE_INGROUP. Now that I recall, I'm not sure what happens when I chose the INGROUP option.

I am using a locally installed Viciphone and I've also used a softphone as well.

The CLI output of asterisk does vary some. It changes when it hangs up the call:
CUSTOMER_PHONE:

Code: Select all

[Jun 18 10:17:38] VERBOSE[21970][C-0000022d] res_agi.c: <Local/010*128*000*061*2001@default-00000112;1>AGI Script agi-VDAD_local_optimize.agi completed, returning 0
[Jun 18 10:17:38] VERBOSE[21970][C-0000022d] pbx.c: Executing [138331*78*Y6181017120000000079*mafren*2001@default:2] Wait("Local/010*128*000*061*2001@default-00000112;1", "2") in new stack
[Jun 18 10:17:38] VERBOSE[21973][C-0000022c] res_rtp_asterisk.c: 0x7feda802ac80 -- Strict RTP learning after ICE completion
[Jun 18 10:17:38] VERBOSE[2246] res_rtp_asterisk.c: 0x7feda802ac80 -- Strict RTP learning after remote address set to: X.X.X.X:50490
[Jun 18 10:17:38] VERBOSE[21973][C-0000022c] res_rtp_asterisk.c: 0x7feda802ac80 -- Strict RTP switching to RTP target address X.X.X.X:50490 as source
[Jun 18 10:17:39] VERBOSE[21969] manager.c: Manager 'sendcron' logged off from 127.0.0.1
[Jun 18 10:17:40] VERBOSE[21970][C-0000022d] pbx.c: Executing [138331*78*Y6181017120000000079*mafren*2001@default:3] Hangup("Local/010*128*000*061*2001@default-00000112;1", "") in new stack  <-----HERE

RA_AGENT_PHONE

Code: Select all

[Jun 18 10:09:27] VERBOSE[20711][C-00000223] res_agi.c: <Local/010*128*000*061*2001@default-0000010d;1>AGI Script agi-VDAD_local_optimize.agi completed, returning 0
[Jun 18 10:09:27] VERBOSE[20711][C-00000223] pbx.c: Executing [138331*77*Y6181009200000000078*mafren*2001@default:2] Wait("Local/010*128*000*061*2001@default-0000010d;1", "2") in new stack
[Jun 18 10:09:27] VERBOSE[20717] manager.c: Manager 'sendcron' logged on from 127.0.0.1
[Jun 18 10:09:27] VERBOSE[20713][C-00000222] bridge_channel.c: Channel SIP/2001-000000e2 left 'simple_bridge' basic-bridge <3b9e4872-596f-4e55-8568-45b1c8bc72b0>   <---- AND FROM HERE ON
[Jun 18 10:09:27] VERBOSE[20713][C-00000222] pbx.c: Executing [8331*77*Y6181009200000000078*mafren*2001@default:1] Playback("SIP/2001-000000e2", "sip-silence") in new stack 

At the AGI server logs, the RA_AGENT_PHONE calls upon the agi-VDAD_RINGALL.agi

Code: Select all

|INSERT INTO vicidial_manager values('','','2022-06-18 10:09:20','NEW','N','10.128.0.61','','Originate','RA_mafren_88402270','Exten: 138331*77*Y6181009200000000078*mafren*2001','Context: default','Channel: Local/010*128*000*061*2001@default','Priority: 1','Callerid: RA_mafren_88402270','Timeout: 14000','','','','')|
2022-06-18 10:09:20|10:09:26|agi-VDAD_ALL_inbound.agi|NNNNN No available balance agent found
--- THINGS CHANGE HERE ---
2022-06-18 10:09:27|agi-VDAD_RINGALL.agi|AGI Environment Dump:  <---HERE
2022-06-18 10:09:27|agi-VDAD_RINGALL.agi| -- accountcode = 2001

But the CUSTOMER_PHONE will loop again into looking for available agents, it seems:

Code: Select all

|INSERT INTO vicidial_manager values('','','2022-06-18 10:17:12','NEW','N','10.128.0.61','','Originate','88402270','Exten: 138331*78*Y6181017120000000079*mafren*2001','Context: default','Channel: Local/010*128*000*061*2001@default','Priority: 1','Caller
id: 88402270','Timeout: 14000','','','','')|
2022-06-18 10:17:12|10:17:37|agi-VDAD_ALL_inbound.agi|NNNNN No available balance agent found
--- THINGS CHANGE HERE ---
2022-06-18 10:17:12|10:17:38|agi-VDAD_ALL_inbound.agi|0|0|SELECT count(*) FROM vicidial_auto_calls where status = 'LIVE' and campaign_id = 'FirstIn' and call_time < "2022-06-18 10:17:12" and lead_id != '79' and queue_priority >= '0'  and agent_only='';| <--- HERE
2022-06-18 10:17:12|10:17:38|agi-VDAD_ALL_inbound.agi|0|SELECT count(*) FROM vicidial_inbound_callback_queue where icbq_status IN('LIVE','SENDING') and group_id='FirstIn' and call_date < "2022-06-18 10:17:12" and lead_id != '79' and queue_priority >= '0
';|

You can find some logs here if you'd like to take a look: https://drive.google.com/drive/folders/ ... sp=sharing

[williamconley]

Have you upgraded this server since buildout?

What is the value for the asterisk version in /etc/astguiclient.conf?

Note that if you installed (or upgraded) this server with "11" or "13" rather than "11.X" or "13.x" in the asterisk version you will need to re-install vicidial and use the sample conf scripts option to use the correct asterisk configuration files during the install. Note that any customized .conf files will need to be re-customized.

The installer expects the ".X" and without it will default to asterisk 1.4 conf files which are not compatible, the result is then that several values are incorrect AND the wrong scripts are requested during certain operations, thus leading to "odd" situations such as this one.

[JakeBelieve]

I just ran into a problem similar to this when building some ON-HOOK Remote Agents. I would notice that the only settings in IN-GROUP on hook CID and on hook CID# that would actually connect through correctly was showing "UNKNOWN" as the Caller ID on the remote agent's phone. Since I wanted it to show the customer Caller ID and I could change those settings in the In-Group to make this happen, the customer caller ID would then show up but then the call would have an error. Either it would request you enter a passcode or it would say "You're the only person in this conference", either of which would not connect the audio from the calls together.

So my problem was that, I could either have the customer caller-id pass through correctly OR I could have the phone call pass correctly with UNKNOWN as the caller ID.

I changed my dial plan/carrier settings/so many other more complicated settings. Then today took another look at the CAMPAIGN settings (thinking it wouldn't have much to do with the campaign since it was an inbound phone cal controlled by the in-group. I found my solution.

If I went into CAMPAIGN settings and changed 'THREE WAY CALL OUTBOUND CALLER ID" from CAMPAIGN, to CUSTOMER. Then as long as in my In-Group Settings for On-Hook CID was set to "GENERIC", then my On-Hook CID # was set to "CUSTOMER", this combination of campaign setting + in-group settings allowed the call to pass perfectly from multiple carriers and display the customer's caller ID perfectly.

It wasn't until I started thinking of the call as a 3 way call to the remote agent that this thought even crossed my mind. I saw other people having this problem and need to track down those threads and post this. Even though this may be common sense to a lot of people, I never had to change my Campaign settings I thought previously. But I didn't do a ton of On Hook Remote Agents in the past. Hope this helps some people! Thanks - Jake

[williamconley]

Here's your new challenge: If those "Remote Agents" are being accessed via PSTN (actual phones, be they cell or landline) the you are passing your calls through an actual telephone carrier. Carriers now FROWN GREATLY on spoofed callerIDs. In fact, your final carrier will GRADE your oubound call based on whether you own the DID matching the CID you are making and whether you have confirmed ownership (eg: another carrier owns it but you've demonstrated ownership) or whether they have NO evidence you own the number or whether NOBODY owns the number. Since these are likely real numbers with real people assigned, you are likely getting a "C" grade. And your agent(s) cell phone companies do not pass C graded calls.

If the agents were using SIP phones in their cell phones (lots of apps for that) you could bypass the cell company's policies.

Otherwise you must either find a different signalling method (text? some other app?) to send the CID information so the agent will have record of it ... or settle for calling them with your Owned DID as a CID.