Outboud AGI scripts?

[tbenson]

So I have a client who is required to call and notify his customers of things like due dates and other various things related to their accounts. Allowing them the option to reach a customer service rep if they think due dates are incorrect etc. Although he is also required to allow them to opt out, and if a number is incorrect for a client, obviously allow someone the option of DNC, and then they will review the DNC's for validity.

The agi-VDADinbound_NI_DNC_CIDlookup.agi script looks like a wonderful option for this, however specifically labeled inbound and knowing the CID wouldnt be received in the PRI/VoIP since were calling outbound. I suppose ${EXTEN} or ${EXTEN:1} should be a valid replacement in the script for CID, but wasnt sure if who wrote it could comment more on the 'inbound' aspect of the script. Also wanted to check and see if someone had an outbound AGI examples for any purpose? That way I can see what variables are being used in the AGI for outbound, in case more then CID should be altered.

[Op3r]

Hello

I think what you need was the broadcast script.

You can just modify it to suite your needs. But you also have to have a scheduler script for it or so I think.

[tbenson]

Looked at broadcast and it appears to be dealing with CID, i see CIDlead_id, but appears to be setting that based on CID information. This is intended to be an unattended autodial to inform clients of information. The audio is generated from various database lookups from the application database (companies main application for customer information). But I would prefer to stick all this into an AGI to handle updating the records in vici.

I am sort of under the gun for quite a few projects currently tied into this an about 10 other customized campaigns. The DBA side for selects and getting the data along with custom dialplan and context menu's is taking up most of my available time. Is anyone out there versed in AGI and VICI, and interested in setting up a basic outbound AGI script that does the NI and DNC like agi-VDADinbound_NI_DNC_CIDlookup.agi? If so contact me and lets discuss timeline and pricing.

[tbenson]

I have been thinking this over and think I may have come up with a fairly simple solution (until someone points out any issues).

What if during the outbound call that is being placed the customer presses 1. During this I add a step to SetVAR(CID=${EXTEN}:1), wouldnt this set the variable for caller ID so that when I pass the next line to AGI(agi-VDADcloser_inboundCIDlookup.agi) that it finds the Extension we dialed as the CID, and thus the agi-VDADcloser_inboundCIDlookup.agi will find the correct phone number when it does the lookup?

Does anyone have a comment on this? Been wondering if inbound CID and outbound CID use the same variable and just assume to send or receive the variable based on the call direction? Does it set a slightly different variable name depending on the inbound?

Going to test this tomorrow in any case, just hoping to save time if anyone else out there has tried something similar, or if I am totally lost in thought.

[mflorell]

Interesting idea, it should work in theory because inbound and outbound CID do use the same variables in those different scripts.

[tbenson]

Just implemented the hack. Took a few tries as the extension changes from the outbound DID to the internal system extension the unattended is routed to. Although just had to store the variable seperately in the outbound dial, and then inherit it as CID on the extension that needs it before hitting an AGI.

Also solves a few other financial institution requirements that we attempted to use safe harbour to resolve, but couldnt route the call information up after the safe harbour extension was accessed.

[mflorell]

It would be great if you could post your solution in more detail if you have a few minutes.

One interesting new feature I just added in SVN trunk is the ability to send dropped calls from inbound and outbound campaigns and in-groups into a different selected in-group with full lead information going into the new in-group. This way the call is still set at dropped in it's original setting before it is sent to the overflow in-group.