Looking for a CVP application that can place an outbound call

[carlos.trivino]

Hi there,

I'm working on an IVR application in CVP that as part of a identification validation process ask the caller for a phone number at which the caller can be reached at. Once the CVP IVR app captures the telephone number, the application should end the call and then right after should dial out the telephone number gathered previously. Has anyone done this before? The CVP model we have is Comprehensive.

Thanks in advance,

Carlos A Trivino

[rguvvala]

Hi Carlos,

You can use form element to collect the input and transfer element to place an outbound call.

Example:

More Info on Transfer element:

The

Transfer

voice element performs a call transfer to a phone number specified by a configuration setting. Depending on how the voice browser is configured, the call transfer can be a bridge transfer or a blind transfer. For a bridge transfer, the voice browser makes an outbound call while maintaining the original call and acts as a bridge between the two calls. The advantage of this is that once the secondary call ends, the original call can still continue with the IVR. The disadvantage is that two separate phone lines are used. For a blind transfer, the voice browser makes an outbound call and when connected, links the original call to the new caller through the use of a telephony switch. At this point, the voice browser (and as a result VXML Server) is no longer in control of the call. Blind transfers involve only one line.

For your setup you should use blind transfer.

[janinegraves]

I think that if the VXML Server app hangs up on the caller, then the ICM

script will also end, and so the call flow will end.

To me, it sounds like you'd want to use the Personal Callback

functionality of the Outbound Dialer.

I don't know much about the dialer, but you should google that

functionality - I bet it's what you'd need to use.

[ptindall]

Quite a few possibilities but it really depends on what you want to do with the call once it's been returned.

• Use the AgentRequest API if you want an agent to be on the call.  Submit a request using the standard REST client element or use a custom element (you can find one on @tindallpaul Twitter feed).
• Use the outbound dialer and add an entry via the Outbound API using the standard REST client element.
• Use Courtesy Callback and configure it so the callback is made immediately (if that indeed is the requirement).
• Use the custom MakeCall element in the CVP Standalone Outbound sample on DevNet.  Add an entry to a dialing list and use CVP in standalone mode to make the callback.

[carlos.trivino]

Thanks Paul, what I want to do with the call is once the IVR dials back and the caller answers the call the IVR will continue serving the caller offering a two options: 1. Activate a card (more data will be asked to the caller to complete the activation process) or 2. Talk to an agent (in which the call will be transferred to skill).

I've been looking at the Courtesy Call back logic ( the different CVP scripts) and there is a check to determine whether a particular call is a candidate for a call back. So to your point of configure call back to be made immediately, how can this particular step be skipped? Also, I understand that CCB works under the premise that the call is in queue so that real EWT time is tracked, so, how to skip all those steps to make a call back if the call is not in a queue but rather is on CVP being self-served?

Thanks again Paul.

Carlos.

[ptindall]

Carlos,

To use the standard CCB script as the starting point, to invoke an immediate callback, the following should do it:

• Set the Max Expected Wait Time to zero so callbacks are always offered.
• Set the Reconnect Time to something high (e.g. 300) so callback becomes eligible long before EWT is reached.
• Set EWT that is passed from the ICM script to something small (try zero).

You are the one that specifies what EWT value is passed from the ICM script so you can set it to anything you want.  Although the call must be in queue for the call to pass the checks, just queue it and make sure your initial VRU script is non-interruptible (which should be the case anyway in the sample).  Alternatively, you can queue the call but set a Consider-If expression to block it from ever going to the target.

I think that should achieve what you're asking.

Paul

[k-martell]

Carlos,

     So you can do this by using the Cisco Courtesy Callback nodes. You can use the Intercept Caller Hangup node to allow the caller to hang up or you can hang up on the caller and keep the VRU leg alive. Then you can use the Reconnect Caller node to get the caller back on the phone. This will not only allow you to verify the caller, it will also allow you to keep the same trunk and maintain a continuous call data and logging.

[carlos.trivino]

Thanks Martell, so you mean that in my CVP app I can use the Courtesy Callback nodes to disconnect the caller, then dial out to reconnect the caller back and then continue offer the caller with self-served options? Is this supported by Cisco? If this is the case it seems a very good option.

Thanks.

Carlos.

[k-martell]

Correct, this would be using the CCB nodes but without invoking any CCB logic. So you wouldn't really be going into the CCB call flow. As Paul mentions below you can use the CCB scripts as a reference to how the nodes I am describing work. I will try and mock up what I am describing and post it here in a few.

I would recommend putting some qualifiers in the retry loop so you don't kill your resources on failed attempts, but something like this should do what you are looking to do.

[k-martell]

[k-martell]

You may have to play with the outbound dial string to match your particular needs.

[k-martell]

okay, so it looks like I have to do  a bit more testing. Like Paul did state, we will have to get the CCB engine involved to some extent. I am trying to get this working in my lab now. I will post more as I test.

[carlos.trivino]

Thanks Paul and Martell. Yes, as you said Martell it looks like we have to use the actual CCB engine to make it work. The lab I have access to currently doesn't have CCB configured yet (I think there is some tcl scripts related stuff that has to happen at the VXML gateway level so that CCB works) so it is going to take some time to get that done.

In the mean time, I want to be sure I understand Paul's steps. Currently in my IVR (CVP app) we determine that the verification process needs to call back the caller. Therefore, we ask the caller for the phone number he wants to be called back.

So as per Paul:

1. My IVR terminates the call once the phone number is entered by the caller. My IVR returns the control back to ICM.

2. Once in ICM, the code has to invoke the ICM CCB script as it were a normal CCB process.

3. In there I have to queue the call to a dummy skill, making sure that the initial VRU script is non-interruptible. Also, I have to set EWT that is passed from the ICM script to something small (e.g.:  zero).

4. In the CVP CCB scripts the config has to be set like:

• Set the Max Expected Wait Time to zero so callbacks are always offered.
• Set the Reconnect Time to something high (e.g. 300) so callback becomes eligible long before EWT is reached.

5. I think that at this point the call will be added to the CCB database table as it were eligible for CCB.

As soon as CCB is properly configured in the lab I have access to, I'll give it a try.

If there is something I misunderstood or is incorrect, please feel free to correct me.

Thanks again Paul and Martell.

Regards,

Carlos.

[ptindall]

It's slightly different but you're on the right lines:

1. Queue the call (necessary for CCB mechanism to accept the call)
2. Invoke the Callback Entry app (non-interruptible in your case as you don't want it to route)
3. In that app (modified as required) get the caller's number, do whatever validation on that number you need to, and add the callback.
4. Return to ICM with outcome that the callback is added.
5. Invoke the Callback Engine app (also non-interruptible) and because of the parameter settings we discussed previously, the callback should be attempted immediately.
6. Once the caller is back on the line, you will return to ICM again and you can invoke the core IVR dialogue with the caller.  Either remove the call from the queue and eventually add it to your real queue when it needs to go to an agent, or simple use an interruptible VRU script when you're ready to allow it to route.   Cancelling the first (dummy) queuing and re-queuing is probably better as it won't skew queuing data for the real queue if that is important to you.

[carlos.trivino]

Thanks Paul, this makes things clearer.

This is truly appreciated.

Regards,

Carlos.