Deploy and modify a static VXML page

[MikeHMirt]

Hello

    We are interested in developing and deploying a static VXML page to use for testing.   Once the static page is deployed we would like to edit the page using a standard editor, and have the updates active for subsequent calls.  The page will be setup for no caching.

   The goal of using the static page is to quickly alter page behaviors for validation testing with ASR, and TTS.

  1) Can we develop and deploy a static VXML page without using Cisco Call Studio?

  2) Using a standard editor can we modify the static vxml page on the VXMLServer, and have the updates loaded for subsequent calls?

Appreciate any advice you can share.

[Gerry O'Rourke · Accepted solution]

Michael,

Yes you could technically.

You would have to configure the correct URL in your ICM script  to point to the VXML static content and this could hosted on the web server where you host your audio files (which is often on the CVP Call/VXML server).

Note: teh static VXML would NOT hosted on the VXML Tomcat server (port 7000) which is where the CVP Studio VXML apps are located.

I have some sample static VXML scripts that I used to use for testing many years ago and they are located here:

http://orourke.tv/vxml/testapplications/

Using Static VXML would need to be tested and to make sure no errors in it, but the VXML Gateways support VXML 2.1, so there should be no issue there, but don't expect Cisco support.

However, I would NOT go with this approach, even if it would be technically possible.

I would use a CVP Studio App to create a dedicated test app.

This is what I do in production content centres and I can test which CVP server I am on, what VXML Gateway i am on, and test each of the VXML servers, media servers etc. (by pressing 1, 2).

And I am sure you could do similar for testing ASR server A, ASR server B etc.

There should be no need for creating static VXML and CVP Studio is much easier to use.

Gerry

[MikeHMirt]

Gerry

      Thank you for the feedback.  The driving force behind our need for static pages is we are integrating CVP to a new MRCP-v2 server providing ASR & TTS.   The static pages will be used by the MRCP developers to quickly test various parameter settings, which can be quickly altered by editing the static vxml pages directly on the VXMLServer.

    We do have some follow on questions if you can help:

      1) Do we have to invoke our static vxml page from an ICM script or can we have the arriving call mapped directly to the

           vxml page?

      2) If we use a CVP studio application for our testing is it possible to use the "SubDialog Invoke" element to invoke a

           static vxml page?

           If using "SubDialog Invoke" is possible to invoke a static vxml page do we need to store our static pages under our

           application structure on the VXMLServer, and what format is the "URI" in the "SubDialog Invoke" to refer to the

           static page?   A few tests so far are giving us the impression the URI is suppose to point to a studio application and

           not a static page.

Appreciate your time and help.

[janinegraves]

You can definitely use the subdialog invoke to call a static vxml page,

and it can be served up by IIS or Tomcat.

If you want it served up by IIS, configure the subdialog invoke element

with:

URI: http://serverNameOrIP/subdirectory/pagename.vxml

LocalApp: false

You don't need to pass or retrieve parameters unless you want to.

Then put your vxml page in your

c:\inetpub\wwwroot\subdirectory\pagename.vxml

However - I think that when I did this the gateway did cache the vxml

page and didn't check for newer versions each time it was called.

[janinegraves]

FYI, you could probably get around the caching of the page by using IIS

Manager to set the expiration of files in your subdirectory to something

very short or configure that directory to never be cached. This isn't

recommended for audio files, but here it would make sense.

You could also store your vxml page under VXMLServer/Tomcat/webapps/CVP

directory if you like. Then the URL would be something like:

URI: http://servername:7000/CVP/subdirectory/pagename.vxml

Local App: false

Then store the page in

VXMLServer/Tomcat/webapps/CVP/subdirectory/pagename.vxml

But again - the gateway usually caches static vxml pages, and it's

harder to configure expiration headers for Tomcat apps.

[MikeHMirt]

Hi Janine

     Excellent detail. We were able to load our static pages.  One final question based on your previous answer. 

Since the static page is configured in the "SubDialog Invoke element as Local App : False.  If the static page references

audio files do the audio files need to be placed within the same folder as the static page, and if so can they be referenced using the URI   http://servername:7000/CVP/subdirectory/audio1.wav    ?

[janinegraves]

The audio files will be retrieved by the gateway, so they could be

anywhere.

If they're going to be served by IIS, then access them as

http://IP/en-us/app/myprompts/filename.wav

and put them in the c:\inetput\wwwroot\en-us\app\myprompts folder.

Or if you want them served by Tomcat, the access them as

http://servername:7000/CVP/subdirectory/audio1.wav

<http://servername:7000/CVP/subdirectory/pagename.vxml>

and put them into the

C:\Cisco\CVP\VXMLServer\Tomcat\webapps\subdirectory folder

However, be careful because if you're setting that subdirectory to NOT

be cached, then the audio files in that directory also won't be cached.

[MikeHMirt]

Thanks Janine.   For this test approach we've set cache to expire on the VXMLGateway after 60 seconds.

[janinegraves]

Let me know what you find works/doesn't work with MRCP v2 - I'd be

interested in knowing.

Good luck.

[ptindall]

Maybe people are unaware but by default the gateway http client won't cache if you include a query string on any of your URLs.  So, just adding ?nocache=true or any dummy query string should do the job very simply.  Configuring "http client cache query" changes that behaviour so everything will be cached but that's normally undesirable behaviour.

[janinegraves]

Good to know, thanks Paul!