That % allocation
* Why?
I was need to ask about the media server (the server that we place our media on it), this server IP address: where I have to place its IP address?
There are three totally separate cases we have to deal with. Let's examine them.
1. Microapps
2. CVP VXML (Audium) applications
3. Playing WAV files from within the CVP VXML applications.
1. Microapps
The CVP Call Server has a retry mechanism built in that you want to make use of. The way this works is when the Call Server builds the VXML page for Play Media, Menu, Get Digit etc. prompts and passes this to the IOS Voice Browser for rendering, it detects a bad fetch at the voice gateway and rebuilds the page in a special way and resubmits it.
When the Call Server builds the page for the first time, it takes whatever is in the media_server ECC variable, the app or sys media_lib ECC variable depending on the config of the microapp, and the locale ECC variable and builds a URL to the WAV file. If the media_server does not start with http:// it is prepended, so don't supply this in that variable. Basically we will get for the full URL of the prompt aaa.wav
http://///aaa.wav
This goes over to the gateway. If you have the IP address in the it works just fine and dandy. So you may think this is correct. But the problem occurs if the Web server dishing up WAV files is down.
The Call Server detects the bad fetch failure at the gateway and rebuilds the URL like this:
http://-backup///aaa.wav
Lets say say locale=en-us and app_media_lib=app, which are the defaults.
If you used the IP address (say A.B.C.D) for the ECC variable, then you will get http://A.B.C.D-backup/en-us/app/aaa.wav, and that's not going anywhere good.
But remember who has to play the VXML - it's the gateway. So we could use a keyword in the ECC variable and have the "ip host" table resolve the keyword. Normally we see Cisco documentation use the keyword "media", but it could be anything. So if we set the ECC variable media_server to "media" then the URL created is
http://media/en-us/app/aaa.wav
and if the voice gateway has
ip host media A.B.C.D
then the call will resolve to the Web server A.B.C.D and all is just as before. But now examine the failure case. The Call Server does its usual trick of appending the "-backup" and turns the URL into
http://media-backup/en-us/app/aaa.wav
and if we have another entry in the "ip host" table
ip host media-backup W.X.Y.Z
we have just achieved fault tolerance on microapps.
In order to spread the load across your Web servers, configure one gateway with
ip host media A.B.C.D
ip host media-backup W.X.Y.Z
and the other gateway with
ip host media W.X.Y.Z
ip host media-backup A.B.C.D
Always do your gateways in pairs like this at the branch offices.
2. CVP VXML (Audium) applications
For CVP VXML applications, you are going to set the ECC variable media_server using a different keyword - say "cvpvxml" in the form
http://cvpvxml:7000/CVP
app_media_lib MUST be "..", the locale should not be defined (the deafult of en-us wil be used) and the microapp is GS,Server,V. Assume the ToExtVXML[0] variable is "application=MyApp". The Call Server munges this all together in exactly the same way as above
-backup//
and comes up with
http://cvpvxml:7000/CVP/en-us/../Server?application=MyApp
The ".." cancels the locale en-us, so we have
http://cvpvxml:7000/CVP/Server?application=MyApp
Now if the ip host table has an entry
ip host cvpvxml L.M.N.O
then we get http://L.M.N.O:7000/CVP/Server?application=MyApp
and we are off to the races. If for some reason the VXML server is not running, a bad fetch is returned, and the Call Server is notified and it rebuilds the URL and resubmits teh VXML page. It looks for a colon in the media_server and inserts the "-backup" before that, so it deals with this case nicely and we get
http://cvpvxml-backup:7000/CVP/Server?application=MyApp
and now a second entry in the ip host table
ip host cvpvxml-backup E.F.G.H
takes us to http://E.F.G.H:7000/CVP/Server?application=MyApp
Cisco say that you should catch the failure of the Run External Script on the GS,Server,V and retry, but I have not found that necessary. Again, you want to configure your gateways in pairs to distribute the load across the VXML servers. Almost always you are going to have a pair of gateways at the branch office, so it will work out for you.
If you have ONLY coresident Call Server/VXML servers you can use the trick described in the CVP 7.x SRND on page 12-2 using the Call Routing client name as the media_server and defining that on the gateway in the ip host table. Be aware of the restrictions on the characters allowed.
This only works if all Call Servers have VXML servers. But it's a nice feature that could work for you, because the Gatekeeper will only send the call to a Call Server that's on-line, so at least we know the box is up. Doesn't mean that VXML is up, but it's a start.
3. Playing WAV files from within the CVP VXML applications.
When Playing WAV files from within the CVP VXML applications. Normally you set the default audio path in your Studio app to something like, the follwing, using an IP address of the Web server
http://S.T.U.V/en-us/app/myapp/
and then each audio element lists just a WAV file like aaa.wav
If the IIS at S.T.U.V is down, there is a failure and you cannot recover. The -backup is a feature of the CVP Call Server, and not the VXML Server.
If your Media Servers are all co-resident with your Call Servers, you can use the trick described in the SRND 12-2 to redefine the default media path with an Application Modifier using substitution.
Using a CSS
If you are using a CSS for your Web server and CVP VXML server you would adopt a slightly different strategy on the gateway, but your ICM scripting would remain as above. Say the VIP (virtual IP address) for the Web servers is J.K.L.M and the VIP for the CVP VXML Servers is R.S.T.U, then the ip host table would look like
ip host media J.K.L.M
ip host media-backup J.K.L.M
ip host cvpvxml R.S.T.U
ip host cvpvxml-backup R.S.T.U
In your Studio apps you can just define the default audio path to the VIP and fault tolerance is achieved.
The CSS is far and away the best way, as load balances as well as building fault tolerance.
Regards,
Geoff
