In-Group redirect for a Survey Call Menu

All installation and configuration problems and questions

Moderators: gerski, enjay, williamconley, Op3r, Staydog, gardo, mflorell, MJCoate, mcargile, Kumba, Michael_N

In-Group redirect for a Survey Call Menu

Postby RBecker » Thu Feb 15, 2024 3:11 pm

Hey all,
I've been following the guide in the Manager Manual to setup an outbound survey campaign, and I want to have the callers redirected to a call menu to present additional options after the first survey question is answered. I've got the outbound survey dial working and properly redirecting into the call menu, but trying to go from that call menu to an in-group while passing lead data through is giving me trouble. With our standard DIDs from our switch, we use the CIDLOOKUPRC method to search for a lead in the campaign's lists, and this is working great. However, when doing this in the call menu, with a route set to INGROUP and the lookup options configured, it's not working. It seems like when the calls is being passed over from the survey campaign, the caller ID is being replaced by what I believe is the Caller Code instead (the Vxxxxxx display that shows in call logs), which causes the CIDLOOKUP methods to not work. I've also tried this with ANILOOKUP and gotten the same results. With CIDLOOKUPRC, a new lead is inserted with a phone number of the Caller Code, and with ANILOOKUP, a new lead is inserted with a blank phone number. Hoping I'm just missing something here about how to pass the actual caller ID through and someone could show me where that's at.

SVN Version 3766, admin.php version 2.14-897a build 230927-0857
Managed & Dedicated ViciDial Hosting | VoIP Trunking and Termination | https://www.dial-fusion.com/
Main Cluster: 21 Agent Servers | Dedicated DB and Separate Reports Server | 2 Web Servers | HAProxy Load Balancing | Dedicated Archive Server
RBecker
 
Posts: 42
Joined: Mon Aug 30, 2021 3:05 pm

Re: In-Group redirect for a Survey Call Menu

Postby njr » Fri Feb 16, 2024 2:34 pm

In the call menu, have you tried setting the in-group handle method to CLOSER?
I have a similar but not quite the same situation and this worked for me. (For reference, that part that is different is that I'm tracking abandons and have a dummy/intake in-group with a zero second drop and that one has the Action Transfer CID set to CUSTOMERCLOSER, so I'm not sure if that's making the difference or not.)
Vicibox 11 from .iso installed/set up by Vicidial | Vicidial 2.14-900a Build: 231115-1636 | Asterisk 16.30.0-vici | 10-server cluster (1 primary DB, 1 primary web, 8 asterisk) in Colo DC | OpenSIPS on web as LB | 10x Dell R740XD
njr
 
Posts: 14
Joined: Fri Dec 08, 2023 1:41 pm

Re: In-Group redirect for a Survey Call Menu

Postby RBecker » Mon Feb 19, 2024 12:22 pm

Unfortunately this didn't work. I got a new lead inserted with no lead information filled in, so it's definitely not matching the existing record like it's supposed to. I have a feeling this has more to do with how the survey campaign is passing the call to the call menu, so I'm going to keep looking into some options on the campaign side to see if I can find anything. Appreciate the suggestion nonetheless!
Managed & Dedicated ViciDial Hosting | VoIP Trunking and Termination | https://www.dial-fusion.com/
Main Cluster: 21 Agent Servers | Dedicated DB and Separate Reports Server | 2 Web Servers | HAProxy Load Balancing | Dedicated Archive Server
RBecker
 
Posts: 42
Joined: Mon Aug 30, 2021 3:05 pm

Re: In-Group redirect for a Survey Call Menu

Postby RBecker » Wed Feb 21, 2024 5:36 pm

I've been looking further into this and unfortunately still haven't arrived at a solution. I dove into the AGI scripts to see if I can either find where things are going wrong, or see if I can modify/adapt one of the scripts and some custom dialplan code to do what I want. I've tried routing through DIDs, routing through extensions directly, making it appear like it was an inbound call from the carrier (through an extension in the trunkinbound context), all to no avail. However, when I was looking at the AGI debug log, I noticed something interesting. When it's placing the call it's properly showing the caller ID, but somewhere that isn't logged, at least not that I'm seeing, is causing it to be replaced and making it not work. Here are some relevant AGI log lines:

Code: Select all
2024-02-21 16:30:22|agi-VDAD_ALL_outbound.agi|Perl Environment Dump:
2024-02-21 16:30:22|agi-VDAD_ALL_outbound.agi|0|SURVEYCAMP-----LB-----V2211630140127092449
2024-02-21 16:30:22|agi-VDAD_ALL_outbound.agi|callerID changed: V2211630140127092449 <----- seems normal, probably it setting to the caller code so it can track the call properly. Or is this wrong?
2024-02-21 16:30:22|agi-VDAD_ALL_outbound.agi|AGI Environment Dump:
2024-02-21 16:30:22|agi-VDAD_ALL_outbound.agi| -- accountcode =
2024-02-21 16:30:22|agi-VDAD_ALL_outbound.agi| -- arg_1 = SURVEYCAMP-----LB-----V2211630140127092449
2024-02-21 16:30:22|agi-VDAD_ALL_outbound.agi| -- callerid = XXXXXX8844 <----- proper outbound CID for this campaign
2024-02-21 16:30:22|agi-VDAD_ALL_outbound.agi| -- calleridname = V2211630140127092449
2024-02-21 16:30:22|agi-VDAD_ALL_outbound.agi| -- callingani2 = 0
2024-02-21 16:30:22|agi-VDAD_ALL_outbound.agi| -- callingpres = 0
2024-02-21 16:30:22|agi-VDAD_ALL_outbound.agi| -- callingtns = 0
2024-02-21 16:30:22|agi-VDAD_ALL_outbound.agi| -- callington = 0
2024-02-21 16:30:22|agi-VDAD_ALL_outbound.agi| -- channel = SIP/astpp2-outbound-00002617
2024-02-21 16:30:22|agi-VDAD_ALL_outbound.agi| -- context = default
2024-02-21 16:30:22|agi-VDAD_ALL_outbound.agi| -- dnid = unknown
2024-02-21 16:30:22|agi-VDAD_ALL_outbound.agi| -- enhanced = 0.0
2024-02-21 16:30:22|agi-VDAD_ALL_outbound.agi| -- extension = 8366
2024-02-21 16:30:22|agi-VDAD_ALL_outbound.agi| -- language = en
2024-02-21 16:30:22|agi-VDAD_ALL_outbound.agi| -- priority = 2
2024-02-21 16:30:22|agi-VDAD_ALL_outbound.agi| -- rdnis = unknown
2024-02-21 16:30:22|agi-VDAD_ALL_outbound.agi| -- request = agi-VDAD_ALL_outbound.agi
2024-02-21 16:30:22|agi-VDAD_ALL_outbound.agi| -- threadid = 140234183173888
2024-02-21 16:30:22|agi-VDAD_ALL_outbound.agi| -- type = SIP
2024-02-21 16:30:22|agi-VDAD_ALL_outbound.agi| -- uniqueid = 1708551014.35325
2024-02-21 16:30:22|agi-VDAD_ALL_outbound.agi| -- version = 13.38.2-vici
2024-02-21 16:30:22|agi-VDAD_ALL_outbound.agi|AGI Variables: |1708551014.35325|SIP/astpp2-outbound-00002617|8366|SIP|V2211630140127092449|V2211630140127092449|2|


trimmed some irrelevant lines of DB updates...

Code: Select all
2024-02-21 16:30:22|agi-VDAD_ALL_outbound.agi|interrupt_digit |0|   timeout |0|0|
2024-02-21 16:30:22|agi-VDAD_ALL_outbound.agi||UPDATE vicidial_list set  status='PM' where lead_id = '127092449';|
2024-02-21 16:30:22|agi-VDAD_ALL_outbound.agi|--    VDAD vicidial_list OPT_CODE update: |1|127092449|X|
2024-02-21 16:30:22|agi-VDAD_ALL_outbound.agi|--    VDAC posttime record: |1|20240221163124|V2211630140127092449|
2024-02-21 16:30:22|agi-VDAD_ALL_outbound.agi|callerID changed: "V2211630140127092449 <XXXXXX3285>" <-- proper caller ID display in the brackets
2024-02-21 16:30:22|agi-VDAD_ALL_outbound.agi||UPDATE vicidial_log FORCE INDEX(lead_id) set status='SVYCLM', end_epoch='1708551024', length_in_sec='2', term_reason='CALLER' where lead_id = '127092449' and uniqueid LIKE "1708551014%";|
2024-02-21 16:30:22|agi-VDAD_ALL_outbound.agi|--    VDAD vicidial_log update: SVYCLM|1|1708551014.35325|2|
2024-02-21 16:30:22|agi-VDAD_ALL_outbound.agi||UPDATE vicidial_list set status='SVYCLM' where lead_id = '127092449';|
2024-02-21 16:30:22|agi-VDAD_ALL_outbound.agi|--    VDAD vicidial_list update: SVYCLM|1|127092449
2024-02-21 16:30:22|agi-VDAD_ALL_outbound.agi|--    VDAC XFER status: |1|20240221163124|V2211630140127092449|
2024-02-21 16:30:22|agi-VDAD_ALL_outbound.agi|exiting the VDAD SURVEY app, transferring call to s CAMP161
2024-02-21 16:30:24|agi-VDAD_inbound_calltime_check.agi|Perl Environment Dump:
2024-02-21 16:30:24|agi-VDAD_inbound_calltime_check.agi|0|CALLMENU-----YES-----CAMP161-------------------------NO-----YES
2024-02-21 16:30:24|agi-VDAD_inbound_calltime_check.agi| -- accountcode =
2024-02-21 16:30:24|agi-VDAD_inbound_calltime_check.agi| -- arg_1 = CALLMENU-----YES-----CAMP161-------------------------NO-----YES
2024-02-21 16:30:24|agi-VDAD_inbound_calltime_check.agi| -- callerid = XXXXXX3285 <----- this is the proper lead caller ID I'd expect it to check for when doing the CIDLOOKUP
2024-02-21 16:30:24|agi-VDAD_inbound_calltime_check.agi| -- calleridname = V2211630140127092449
2024-02-21 16:30:24|agi-VDAD_inbound_calltime_check.agi| -- callingani2 = 0
2024-02-21 16:30:24|agi-VDAD_inbound_calltime_check.agi| -- callingpres = 0
2024-02-21 16:30:24|agi-VDAD_inbound_calltime_check.agi| -- callingtns = 0
2024-02-21 16:30:24|agi-VDAD_inbound_calltime_check.agi| -- callington = 0
2024-02-21 16:30:24|agi-VDAD_inbound_calltime_check.agi| -- channel = SIP/astpp2-outbound-00002617
2024-02-21 16:30:24|agi-VDAD_inbound_calltime_check.agi| -- context = CAMP161
2024-02-21 16:30:24|agi-VDAD_inbound_calltime_check.agi| -- dnid = unknown
2024-02-21 16:30:24|agi-VDAD_inbound_calltime_check.agi| -- enhanced = 0.0
2024-02-21 16:30:24|agi-VDAD_inbound_calltime_check.agi| -- extension = s
2024-02-21 16:30:24|agi-VDAD_inbound_calltime_check.agi| -- language = en
2024-02-21 16:30:24|agi-VDAD_inbound_calltime_check.agi| -- priority = 2
2024-02-21 16:30:24|agi-VDAD_inbound_calltime_check.agi| -- rdnis = unknown
2024-02-21 16:30:24|agi-VDAD_inbound_calltime_check.agi| -- request = agi-VDAD_inbound_calltime_check.agi
2024-02-21 16:30:24|agi-VDAD_inbound_calltime_check.agi| -- threadid = 140234183173888
2024-02-21 16:30:24|agi-VDAD_inbound_calltime_check.agi| -- type = SIP
2024-02-21 16:30:24|agi-VDAD_inbound_calltime_check.agi| -- uniqueid = 1708551014.35325
2024-02-21 16:30:24|agi-VDAD_inbound_calltime_check.agi| -- version = 13.38.2-vici
2024-02-21 16:30:24|agi-VDAD_inbound_calltime_check.agi|AGI Variables: |1708551014.35325|SIP/astpp2-outbound-00002617|s|SIP|V2211630140127092449|
2024-02-21 16:30:24|agi-VDAD_inbound_calltime_check.agi|+++++ INBOUND CALL VDCL STARTED : |CALLMENU|V2211630140127092449-|2024-02-21 16:30:24
2024-02-21 16:30:24|agi-VDAD_inbound_calltime_check.agi||INSERT INTO vicidial_outbound_ivr_log (uniqueid,caller_code,event_date,campaign_id,lead_id,menu_id,menu_action) values('1708551014.35325','V2211630140127092449','2024-02-21 16:30:24','161','127092449','CAMP161','')|
2024-02-21 16:30:24|agi-VDAD_inbound_calltime_check.agi|--    VOIL insert: |1|1708551014.35325|V2211630140127092449|161|127092449|CAMP161|
2024-02-21 16:30:24|agi-VDAD_inbound_calltime_check.agi||UPDATE vicidial_auto_calls SET last_update_time='20240221164024',status='IVR' where callerid='V2211630140127092449';|
2024-02-21 16:30:24|agi-VDAD_inbound_calltime_check.agi|--    VAC update: |1|1708551014.35325|V2211630140127092449|20240221164024|


another snip, this time I tried to route the call in the call menu using the setting EXTENSION, set to 99909*23536***DID (23536 being the proper DID ID), in context trunkinbound. The call passed through to the In-Group like I expected, but it still failed the lookup. See below where even though it has the proper "callerid" filled in in the inbound AGI, the lookup search was perofmed on the caller code instead.

Code: Select all
2024-02-21 16:30:28|16:30:28|agi-VDAD_ALL_inbound.agi| -- accountcode =
2024-02-21 16:30:28|16:30:28|agi-VDAD_ALL_inbound.agi| -- callerid = XXXXXX3285
2024-02-21 16:30:28|16:30:28|agi-VDAD_ALL_inbound.agi| -- calleridname = V2211630140127092449
2024-02-21 16:30:28|16:30:28|agi-VDAD_ALL_inbound.agi| -- callingani2 = 0
2024-02-21 16:30:28|16:30:28|agi-VDAD_ALL_inbound.agi| -- callingpres = 0
2024-02-21 16:30:28|16:30:28|agi-VDAD_ALL_inbound.agi| -- callingtns = 0
2024-02-21 16:30:28|16:30:28|agi-VDAD_ALL_inbound.agi| -- callington = 0
2024-02-21 16:30:28|16:30:28|agi-VDAD_ALL_inbound.agi| -- channel = SIP/astpp2-outbound-00002617
2024-02-21 16:30:28|16:30:28|agi-VDAD_ALL_inbound.agi| -- context = default
2024-02-21 16:30:28|16:30:28|agi-VDAD_ALL_inbound.agi| -- dnid = unknown
2024-02-21 16:30:28|16:30:28|agi-VDAD_ALL_inbound.agi| -- enhanced = 0.0
2024-02-21 16:30:28|16:30:28|agi-VDAD_ALL_inbound.agi| -- extension = 99909*23536***DID
2024-02-21 16:30:28|16:30:28|agi-VDAD_ALL_inbound.agi| -- language = en
2024-02-21 16:30:28|16:30:28|agi-VDAD_ALL_inbound.agi| -- priority = 2
2024-02-21 16:30:28|16:30:28|agi-VDAD_ALL_inbound.agi| -- rdnis = unknown
2024-02-21 16:30:28|16:30:28|agi-VDAD_ALL_inbound.agi| -- request = agi-VDAD_ALL_inbound.agi
2024-02-21 16:30:28|16:30:28|agi-VDAD_ALL_inbound.agi| -- threadid = 140234183173888
2024-02-21 16:30:28|16:30:28|agi-VDAD_ALL_inbound.agi| -- type = SIP
2024-02-21 16:30:28|16:30:28|agi-VDAD_ALL_inbound.agi| -- uniqueid = 1708551014.35325
2024-02-21 16:30:28|16:30:28|agi-VDAD_ALL_inbound.agi| -- version = 13.38.2-vici
2024-02-21 16:30:28|16:30:28|agi-VDAD_ALL_inbound.agi|AGI Variables: |1708551014.35325|SIP/astpp2-outbound-00002617|99909*23536***DID|SIP|V2211630140127092449|
2024-02-21 16:30:28|16:30:28|agi-VDAD_ALL_inbound.agi|+++++ INBOUND CALL VDCL STARTED : |161TEXT|V2211630140127092449-999161TEXT|2024-02-21 16:30:28
2024-02-21 16:30:28|16:30:28|agi-VDAD_ALL_inbound.agi|   Answering call: - SIP/astpp2-outbound-00002617|START
2024-02-21 16:30:28|16:30:28|agi-VDAD_ALL_inbound.agi|VDAD vicidial_list search |V2211630140127092449|SELECT lead_id,called_count,list_id from vicidial_list where phone_number='V2211630140127092449' and list_id IN('1611')  order by last_local_call_time desc limit 1;| <----- this is wrong as it's using the caller code lookup instead of the phone number
2024-02-21 16:30:28|16:30:28|agi-VDAD_ALL_inbound.agi|VDAD vicidial_list insert |128720367|1611|SELECT LAST_INSERT_ID() LIMIT 1;|


In the agi-VDAD_ALL_inbound.agi script, I found this snippet that sets the phone_number to the $callerid value, which really seems like this should be right, but for some reason it's being overriden:

Code: Select all
if ( ($call_handle_method =~ /^CID/) || ($call_handle_method =~ /^VID/) )
   {
   if (length($callerid)>0) {$phone_number = $callerid;}
      else {$phone_number = '';}
   if (length($calleridname)>0) {$VLcomments = $calleridname;}
      else {$VLcomments = '';}
   }


Really at a loss here and hoping someone else might have some ideas.
Managed & Dedicated ViciDial Hosting | VoIP Trunking and Termination | https://www.dial-fusion.com/
Main Cluster: 21 Agent Servers | Dedicated DB and Separate Reports Server | 2 Web Servers | HAProxy Load Balancing | Dedicated Archive Server
RBecker
 
Posts: 42
Joined: Mon Aug 30, 2021 3:05 pm


Return to Support

Who is online

Users browsing this forum: No registered users and 259 guests