voice browser IP address (again on purpose)

[paracleitos]

Hello team,

this issue has been already discussed in this forum as the subject: Voice Browser machine information  23-04-2004 06:17:34 PM and was replied by "joe".

I need to open the same topic again. The answer in forum is correct though it doesn't solve the problem. The goal is:

How do I pass the IP address of the voice browser to the vxml server? Or how do I pass any other information to the java code in Tomcat that generates vxml for the voice browser?

The suggested solution is this: "configure the voice browser to pass the IP address as an HTTP parameter on the initial request"

Unfortunately I have to ask how to do it, because the solution seems not to be TAC supported in the standalone deployment model.

If I want to set some additional variable and pass the voice browser address as a session variable e.g. var2

I get into trouble with the default voice browser TCL script. In the standalone deploymet model I have in fact two scripts,

the basic standalone *.tcl script and the vxml script. You start with the TCL script which performs handoff to the vxml script.

The initial TCL script has a few parameters like the VXML IP addresses etc. The only optional parameter is DNIS which you can

use to override the default IOS provided DNIS. Unfortunately this is a static overwrite, either the static value from parameter or the default IOS provided.

The TCL by default assigns the var1 variable to $destination and performs the handoff to the vxml script

set handoffMsg "CALLID=$callident|APP=$CVPSelfServiceApp|PORT=$CVPSelfServicePort|PRIMARY=$CVPPrimaryServer|BACKUP=$CVPBackupServer|survive=$survive|PROTOCOL=$protocol|var1=$destination|TCLVERSION=$tclscriptversion"

So whatever was in var2 ... var4 would be anyway thrown away. Why?

If you look at the vxml script that receives the handoff - it already counts on getting var1-var4 because you can get them set as return variables.

I can imagine creating 3 new params to the TCL script Pvar2-Pvar4 and changing the handoffMsg to ....var1=$dnis|var2=$Pvar2|var3=$Pvar3,var4=$Pvar4   (also take care about variable scope)

but this is NOT TAC supported. I can very well understand why the TAC guys want the people to use the TCL scripts unchanged,

because they can spend years troubleshooting some messed voice browsers.

But as "joe" suggested in his reply - pass a session variable to Tomcat, I don't see a way how to do that.

The client is quite strict about the policy and they don't want me to use some custom code. So do you see some way how to

do it some official way? I think the Tomcat server must have the client address somewhere inside of the internal

java. The question is how much it exposes this information to the audium & Co.

thanks for your time

Radek

[ptindall · Accepted solution]

There's a couple of ways to get data from the gateway into a CVP standalone app. 

The first is pretty dirty but a simple hack that works -- simply overload the dnis override param.  For example, if you set the following on the TCL service, you'll get var1, var2, etc as session variables as you can see in the log extract.

param dnis 1234|var2=2222|var3=3333|var4=4444

Activity log --

AgentRequestAPI,08/07/2015 00:40:01.611,,start,newcall,

AgentRequestAPI,08/07/2015 00:40:01.611,,start,ani,447740449595

AgentRequestAPI,08/07/2015 00:40:01.611,,start,areacode,NA

AgentRequestAPI,08/07/2015 00:40:01.611,,start,exchange,NA

AgentRequestAPI,08/07/2015 00:40:01.611,,start,dnis,651963499

AgentRequestAPI,08/07/2015 00:40:01.611,,start,uui,NA

AgentRequestAPI,08/07/2015 00:40:01.611,,start,iidigits,NA

AgentRequestAPI,08/07/2015 00:40:01.611,,start,parameter,tclversion=CVP_9_0_1_0_0_0_670

AgentRequestAPI,08/07/2015 00:40:01.611,,start,parameter,callid=E76D343E3BC211E5801A001B0CFAA768

AgentRequestAPI,08/07/2015 00:40:01.611,,start,parameter,vxmlversion=CVP_9_0_1_0_0_0_670

AgentRequestAPI,08/07/2015 00:40:01.611,,start,parameter,var3=3333

AgentRequestAPI,08/07/2015 00:40:01.611,,start,parameter,var4=4444

AgentRequestAPI,08/07/2015 00:40:01.611,,start,parameter,var1=1234

AgentRequestAPI,08/07/2015 00:40:01.611,,start,parameter,var2=2222

AgentRequestAPI,08/07/2015 00:40:01.611,CVP Subdialog Start_01,enter,

The second way is a bit more versatile and that is to use a custom element to make a request back to the gateway, handoff the call from VoiceXML to TCL  and invoke a TCL command that was configured in the element settings.  For example "info hostname" will return the gateway hostname.   The same approach can retrieve custom parameters configured on the service.   I do have an element that will do this but it needs a quick tidy up before publishing.   If anyone's interested then let me know.

Hope that helps.

Paul

[paracleitos]

Dear Paul,

thank you very much for the answer. I like the simple solution very much!!

The idea of sending the call back and performing a handout to another application sounds quite complicated. It is of course a way how to keep the existing voice browser TCL script and allowing the information to be passed. I leave it with you, I'd consider a small change to the existing voice browser a more simple way.

Anyway I really very much appretiate your help.

thanks Radek 

[ptindall]

If the quick and dirty method does what you need, then stick with it.  It is definitely simple and doesn't require any customisations or add-ons at all.  However, like any parameter injection hack it does risk no longer working if the parameter handling in the standard TCL app is modified.  I think you're probably pretty safe on that one though.

For the alternative approach, I have just published a custom element here for anyone interested -- https://cisco.box.com/cvp-dotclcmd. 

It allows you to execute a TCL command from a Call Studio application, for example, to retrieve config data from the VoiceXML gateway.  It's purely an add-on and doesn't require any of the standard components to be customised.

Paul