Asynchronous CVP VXML Application trigger and interruptible

[humayunsami]

I have a VXML application in which I am using java classes to check updates from the UCCE for multiple events. I need this application to play asynchronously so I can play another VXML application which has queue prompts. This is how the scenario will work.

Asynchronous VXML Application A (continuous to loop and check for updates) > calls or triggers second application VXML Application B (contains multiple prompts) while application A is still in progress.

The prompts should continue to play in order and when the prompt end and the application that is awaiting updates should trigger the prompt application again.

In ccx scripts we had the functionality to trigger second application asynchronously as shown in example below.

The below example continuous to loop asynchronously and check for updates but plays prompt from second application.

Can this be done with CVP VXML scripts? If yes, which element should i use to do this job.

[ptindall · Accepted solution]

If I understand the requirement correctly then you might want to try this custom element.  It allows you to detect a response asynchronously from a back-end web server while playing something to the caller and optionally detecting caller DTMF input.

Async HTTP Request - Box

Just use the custom Java element as normal, load the TCL onto the gateway and create a new service "service cvp_httpreq flash:cvp_httpreq.tcl".

As it's currently coded, the client-side TCL expects to receive plain text HTTP response containing either "null" or a semi-colon delimited string of key:value pairs.  If it receives null, the HTTP request is reissued.  Otherwise it returns back to VoiceXML and the key:value pairs are written to element data.

A DTMF input pattern can be matched while waiting but something that doesn’t work right now is the caller input initial digit timeout.

Normal custom element caveats apply -- not part of the CVP product and not TAC supported.

Paul

(If interested, follow @tindallpaul for notifications of anything new coming off the workbench)

[humayunsami]

Hello ptindall - i just came to download this file (Async HTTP Request - Box) do you still have it handy. Looks like it was removed. thanks again

[ptindall]

Yes, the expiry policy on publicly accessible Box links changed but you can access it here ---

https://app.box.com/s/4349vfildznbpy00jnwoian97q4d0uwj for the VVB version

https://app.box.com/s/3r1s7x7lcin1px0peyl9urqssymd886d for original IOS VB version which is extended by the VVB version

[humayunsami]

thanks for the quick response. I will ping you if I run into problems. thanks again. cheers

[shayanahmad96]

Hi Paul, hope you are doing well. I have been working on your Async HTTP Request custom element for the past few weeks now. You've done an amazing job here and its doing the needful as you described above. Let me give some context to what i am trying to achieve. I have a cherry picking solution setup where i am playing media server prompts to the customer in queue while i communicate with my HTTP server through this element waiting for an agent to become available which is then sent back by my HTTP server. During this time if a customer enters DTMF that should also be accepted and the application should exit this element. I have tested this design out and its working as expected. However, i have certain confusions and questions that will help me understand better and further complete my design. These are as follows:

1) There is some additional data that i need to send over to the HTTP server from the element. From what i can see, currently a basic HTTP request is sent over from the tcl app to my HTTP server after an initial handoff between this custom element and the tcl app. I need to send over some additional session data variables to my HTTP server for some calculations. Is it possible to send these as part of the handoff between the element and tcl app, and then as part of the HTTP request to be sent to the HTTP server?

2)I also wanted to ask you if you foresee any caveats with the aspect of load. Once we can achieve what i mentioned in my first question, we would like to test this solution out under load. We are building this out for an environment where 20 Calls per second can be expected. Can there be any potential issues or caveats with applying this design to such an enviroment?

3)One more question i had was around enhanced logging. Since i will be applying this design to an extensive environment is it possible to have additional logging added by this element to the CVP end. Along with this, could we add more logging to the voice gateway as well for the TCL app running there. Extra logging would be extremely beneficial for us to troubleshoot in such an environment.

4)You have mentioned : "As the cvp_gwfeature helper service is inserted into the incoming call signalling path via the ingress gateway incoming dial-peer, it cannot co-exist with survivability.tcl in the same call". Does this mean that we need to create a separate signaling dial peer for vvb based architecture?

Ill wait for your responses to these questions. Thanks for the help!

[david.macias]

Did you really mean to say 20 calls per second? That's a ton of calls!

david

[shayanahmad96]

Hi David, yes i did mean that we have an extensive enviroment. 

[ptindall]

Good to hear you have it working and finding it useful.  I'll attempt to answer your questions --

1.  The HTTP GET request made by the TCL app uses the URL you provide in the Studio element settings.  You can include a query string on that URL so additional data can be passed end to end via the URL query params using either static values or variable substitution.  Just as if you were using the same URL in a browser, ensure you don't include any spaces in the query params.

2.  Regarding load on the ingress gateway you should definitely do some comparative load testing.  However, if you consider what the mechanism is doing, I wouldn't expect you to notice a huge difference between calls with and without the mechanism invoked.  The SIP INFO messages that are sent should be pretty minimal in terms of additional SIP signalling.  Once the call is performing the async HTTP long poll the audio path is disconnected between gateway and VVB and that will reduce load.  Playing the media to the caller will add some back.  The TCL app footprint on the gateway should be less than using standard survivability.tcl on the call so, on balance and in theory, the impact should be small. 

3.  The CVP element activity is logged to application activity logs as normal and includes results returned from the HTTP operation.   I'm not sure what additional logging would really be that valuable but clearly more could be added.   Similarly, it is a simple thing to add more debug output into the TCL app if needed.

4.  Yes, you will have to use a different incoming dial peer config for calls that need to make use of this capability. As it stands currently, you will have to choose between survivability.tcl and cvp_gwfeature.tcl on the ingress dial peer.  I do have a mechanism that allows switching dynamically between TCL apps on demand so you can get the benefits of using both without having to combine everything into one single dogs breakfast of a TCL app but unfortunately I haven't implemented it yet for this particular application.  For now, you have to run without survivability.tcl functionality.

Hope that helps.

Paul

[shayanahmad96]

Hi Paul,

Thank you for all your responses above they have proved to be very helpful. I had a few followup questions to this after testing further. These are as follows:

1) Could you explain the mechanism that allows switching dynamically between the TCL apps and is it possible for us to utilize that mechanism here?

2) Why has survivability.tcl been removed? Is it because we have to use cvp_gwfeature.tcl in the signaling dial peer ?

3) Since it was mentioned that the provided TCL will replace the Survivability.tcl so what impact would this have on the queued calls as survivability is a key component.

4) Due to survivability.tcl being removed, will Courtesy Call back service be impacted ? if that is the case, what would be the impact ?

Thanks again for all your help so far. I look forward to your response.

[ptindall]

1. The mechanism allows a CVP app to swap the TCL app that is currently active in the call signalling path.  In very simple terms, it requires communication from CVP to the currently active app, telling it to terminate gracefully and handoff the active call legs to a different TCL app.    It is possible in principle to use it but it's not something I've implemented yet for these TCL apps; it requires some coding to add the capability.
2. Architecturally, both TCL apps have to sit in the same place in the call signalling path.
   
   
3. You lose the added functionality that explicitly relies on survivability.tcl -- fallback on call failures, media inactivity handling, courtesy callback, a number of additional transfer options and some legacy voice interface capability.   You regain the capability to do many custom things that were rendered impossible when the VVB was introduced.  With the IOS VB, there was no such conflict as the helper TCL app wasn't needed.
   
   
4. The impact is you can't use courtesy callback.  That is one of the main reasons behind the dynamic TCL app swapping approach.

Now, in conclusion, something you should be mindful of --

Regarding any additional follow-up, be aware that I was recently "workforce-realigned" out of my job so won't be picking up messages on this channel in the same capacity.   If you don't get a response to something, that is why.   Feel free to try other channels.

Paul

[shayanahmad96]

Hi Paul,

Hope you are doing well. I had one question in reference to DTMF inputs. Currently, as it stands we can provide a pattern in the element and if we enter the same pattern DTMF is matched and call comes out of the element. I want to modify it to be able to come out on multiple patterns rather than a single i.e. customer can press 1 or 2 for different results. Going through your TCL script i have not been able to pinpoint where you are comparing the digits collected with the pattern specified.

Seems to me that based on status cd_005 you put the entered digits in the variable "rx_dtmf" after which you log that the digit pattern has been matched and return the string. The function above this that enables digit collection does set a variable called "match_dtmf" but should we not compare match_dtmf with rx_dtmf to know that the pattern has been matched? I dont see where this is happening in your script. 

Would appreciate if you can clarify this for me. As always thank you for all your help.

[therealptindall]

There isn't code that explicitly matches digit input; the required pattern match is passed into the leg collectdigits command and that operation only completes if there's a successful match or a timeout / hangup.  There's no need for the TCL app to check the digits; it just has to pass them back to the Studio app.   If you need to use multiple patterns for digit string matching then these have to be added to the digit patterns array passed into leg collectdigits.  However, before you get to that part, the Studio custom element settings will also need to be modified to allow multiple pattern settings as well as the encoding/decoding of the digit pattern match parameter in the messaging between the Java and TCL code to contain a list of values rather than a single one.

Paul