InGroups Call Handling Method that prompts for vendor_id

[aouyar]

User the callerid for identifying clients is not very reliable. A client has asked for a solution where the callers can be asked for an ID Number using an IVR, before the calls are passed to an InGroup. The ID Number could be used to search the user in vicidial lists, and when a Webform is used the external applications can use the ID Number to retrieve the information for the calling user.

The IVR can map the number entered by the calling user to the vendor_lead_code field of lead and this field can be used for searching the user in vicidial lists or in webforms.

I have developed a small patch to agi-VDAD_ALL_inbound.agi that implements two new Call Handle Methods similar to CID and ANI. Both methods implement the variants to search leads in All the System (LOOKUP), One List (LOOKUPRL) and Campaign Lists (LOOKUPRC), so a total of 8 new Call Handle Methods are available.

VIDPROMPT / VIDPROMPTLOOKUP / VIDPROMPTLOOKUPRL, VIDPROMPTLOOKUPRC
VIDPROMPT methods prompt the user for ID Number using an IVR before routing the call to the InGroup.

VID, VIDLOOKUP, VIDLOOKUPRL, VIDLOOKUPRC
VID methods do NOT prompt the user for ID Number. The ID Number must be passed to the AGI script as the 12th parameter. The VID methods are for interfacing with external IVRs. The methods are developed specifically for the following scenario: One can develop external IVR applications which prompt the caller for ID Number and possibly a secret to query external databases for authentication and routing information. The external IVR can determine to which InGroup the call must be routed based on ID Number. The InGroup and the ID Number can be passed to AGI script as parameters.

You can check the following issue in Mantis for the patch:
http://www.vicidial.org/VICIDIALmantis/view.php?id=269

I would be glad to have comments on the patch and I would like to propose it for inclusion in 2.2.

[mflorell]

This is similar to the reason we used the 10DIGITID feature for a couple of clients, this would prompt the caller for a 10-digit ID and then fill it in one of the fields for their CRM to use.

Do you have an example of an AGI IVR application and/or a Call Menu setup that will feed into this new functionality?

[aouyar]

I never figured out how to used 10DIGITID functionality, and I wanted to have the possibility of LOOKUP with vendor_lead_code.

You will need three new sound prompts that are documented in the code to try the functionality:
# ; please-enter-id-number - "Please enter your ID Number followed by #.
# ; id-number - "Your ID number is"
# ; confirm-id-number - "Press 1 if it is correct. Press 2 to repeat entry."

I have some Spanish prompts recorded at a client site, but I think you will need some English prompts for Vicidial.

Here is an example from extensions-vicidial.conf which was generated by a Call Menu using Route:AGI:
exten => 3,1,AGI(agi-VDAD_ALL_inbound_sapian.agi,VIDPROMPT-----LB-----GENERAL-----IVR_Principal-----Closer-----park----------999-----57-----TESTMAN)

I just pasted the following text to the Route:AGI in the administration interface:
agi-VDAD_ALL_inbound_sapian.agi,VIDPROMPT-----LB-----GENERAL-----IVR_Principal-----Closer-----park----------999-----57-----TESTMAN

It would be much easier to use the functionality with a very simple modification to the Call Menu section of the Administration Interface. By adding VIDPROMPT, VIDPROMPTLOOKUP, VIDPROMPTLOOKUPRL, VIDPROMPTLOOKUPRC to the "Handle Method Select Box" of Route:InGroup, it will simply work like the other methods.

I would not recommend to add VID, VIDLOOKUP, VIDLOOKUPRL, VIDLOOKUPRC to the interface, because they are designed to be used from external scripts. I will try to explain it with the following scenario:
- You have an external IVR that prompts the user for user, pass, etc. and authenticates user by querying an external database.
- The external IVR determines to which InGroup the call should be passed to. The external IVR sets the XINGROUP y XIDNUM channel variables.
- The call is passed to the correct InGroup using the following dialplan excerpt:
exten => 1,1,AGI(agi-VDAD_ALL_inbound_sapian.agi,VIDLOOKUPRC-----LB-----${XINGROUP}-----AUTH_IVR-----Closer-----park----------999-----57-----TESTMAN----------${XIDNUM})

[mflorell]

Do you allow calls through without a VID match, or would they be hung up?

[aouyar]

When the client does not enter a ID Number or when the ID Number is too short, a new lead is added. (The same behavior with CIDLOOKUP, when there is no match or when CallerID is too short add new lead.)

The agent can detect the situation, because the Vendor ID is 0 or it is too short. In fact the agent is supposed to verify the identity of the caller anyway. (Am I speaking with Mr. ... ) In this case the agent can fill in the Vendor ID manually after asking it to the client.

The web form that is used must open a search page when vendor_id is 0 or when vendor_id cannot be found.

You can try the AGI without overriding the existing one. Just copy it with another name to the agi-bin folder. At the moment I have the AGI installed in a client site, but using a different name so that it would not affect the other InGroups while I am doing modifications.

In fact the dialplan examples I have sent you were set to launch this modified version: agi-VDAD_ALL_inbound_sapian.agi If you decide to overwrite the standard AGI, you dialplan examples have to be modified to use agi-VDAD_ALL_inbound.agi.

[mflorell]

Functionality has been added to SVN trunk. I changed a few things and added default recordings as well.

[aouyar]

Hi Matt,

I am really glad that the code was accepted into Trunk.

I had never figured out how to access the pin entered by the user in XDIGITID methods, the change in agi-VDAD_ALL_inbound.agi for passing it in the fronter field solves the issue.

All the changes in agi-VDAD_ALL_inbound.agi for VID methods were included in the update. It seems like you did some tidying up for fixing the coding style a bit, but most of the diff between the two versions is due to tabs. If there is anything I can do so that you wouldn't have to fix the tabs later on, just let me know.

The changes you made to Admin Interface is just what was needed for making the feature easier to use, but there is a small typo error in the help text for VIDPROMPT methods; there are multiple occurences of 'attampt' instead of 'attempt'.

One last question: Is there any special reason why ANILOOKUP and ANILOOKUPRL are permitted, but ANILOOKUPRC is not included in the selection list?

Thank you

[mflorell]

Thanks for pointing out the spelling errors, those will be fixed in the next commit.

As for the ANI* methods, I have not seen anyone use them in over 3 years, which is probably why I never added them. They are to be used with inbound calls coming in on old RBS T1 circuits where you receive *ANI*DNIS (*7275551212*1234) with the inbound call and no callerID information.