vicidial.org

Here is the scenario:
Agent receives inbound call, Agent makes sale, Agent makes outbound call to third party(this creates a defacto conference call with the agent on mute). Third party hangs up, agent is reconnected with inbound caller. This does not work on inbound calls. It does work on outbound calls. What is causing the inbound feature not to work?


; ****************************** Custom Feature ******************************
custom_feature1 => *1#,callee,Macro,somemacro,default
custom_feature2 => *2#,callee,Macro,somemacro,default

# Start of file. /etc/asterisk/extensions.conf

[from_sip_dp]
exten => xxxYYYZZZZ,1,NoOp()
same => n,Set(DYNAMIC_FEATURES=custom_feature1#custom_feature2) ; use # to activate multiple features
same => n,Dial(SIP/voip-provider1/${EXTEN},,)
same => n,HangUp()

# End of file. /etc/asterisk/extensions.conf

Updated information.

When the agent logs in Vicidial creates a conference. When a call comes in another channel is created. (that is a total of three). The 3rd channel is not addressed in the dynamic_feature which is why the custom feature will not work in vici. This works in Asterisk outside of Vici. I do not believe Vici was made to address New York state regulations regarding third party verification.

dajaz27 wrote:Here is the scenario:
Agent receives inbound call, Agent makes sale, Agent makes outbound call to third party(this creates a defacto conference call with the agent on mute). Third party hangs up, agent is reconnected with inbound caller. This does not work on inbound calls. It does work on outbound calls. What is causing the inbound feature not to work?


; ****************************** Custom Feature ******************************
custom_feature1 => *1#,callee,Macro,somemacro,default
custom_feature2 => *2#,callee,Macro,somemacro,default

# Start of file. /etc/asterisk/extensions.conf

[from_sip_dp]
exten => xxxYYYZZZZ,1,NoOp()
same => n,Set(DYNAMIC_FEATURES=custom_feature1#custom_feature2) ; use # to activate multiple features
same => n,Dial(SIP/voip-provider1/${EXTEN},,)
same => n,HangUp()

# End of file. /etc/asterisk/extensions.conf

There is a "transfer-conf" button in Vicidial's agent interface. That's what you should be using for this feature. And then you don't need the custom code. There are instructions in both the Agent manual and the Manager's manual that will help you through it.

William once again you point out the obvious however, That is not the problem nor the solution. The problem is we need to transfer the customer/ create a conference call in which the customer and the third party are on a call with the in house agent on mute(or channel muted). The "transfer-conf" button was not made for that nor will it work for those purposes. Thanks for the help anyway. This is truly a custom feature issue. Neither Vicidial nor Asterisk were made for this functionality out of the box.

It will work for those purposes. The agent simply pushes the mute button after the 3-way call starts, just like he does now.

For those who may follow the wrong proceedure and find themselves in violation of New York Law. The agent can not be on the phone (muted or otherwise) during 3rd party verification. Yes William Just like you I live in Florida where our regulations are different. But If you do business in New York. The TPV law must be followed. Now back to the original issue:

1. Take inbound call from customer (1st conference call begins)
2. Transfer the inbound customer call to Third Party Verification to an outside company.
3. Maintain control of the Second conference between the TPV(Third Party verification company and customer without any sound on the agent end).
4. Bring the customer back to the 1St conference once the TPV conference is over.

This works on outbound calling. Not inbound.

Probably simpler to create a whole new function for this, perhaps a special new type of Transfer Group or Modified Park Call (which would route the call to the 3rd party verifier, cold transfer, breaking the agent off until the 3rd party line terminates ... then putting the agent back).

We've also had to create a "view 3rd party calls" real time screen for one client who routinely transfers calls in this fashion (lots of them, to various places) and wanted to keep an eye on what was happening (not listen, just view status).

And there are agi script methods to control calls in this fashion, but keeping them compatible with Vicidial to maintain control of both the Agent and the Prospect while "watching" status of the 3rd party, that's the challenge. Not something I'd be able to solve here, as it will likely take several hours to build with a lot of testing.

If what you say is true, however, it may be a Necessary add-on for Vicidial in the future. Interesting.

Another possibility would be to include a full-on external transfer (warm or cold) followed by release, but with a special script sending the call back to the originating agent via AGENTDIRECT upon termination of the 3rd party verifier AND a watchdog script to generate a direct call to the client if they hang up, so the call can not be "lost" easily.