For microapps I simply use ip host mediaserver = CVP1 IP and ip host mediaserver-backup = CVP2 IP and set media_server var = "mediaserver" and RunExtScript failsover and sue the backup mediaserver in case of an issue.
But for CVP Studio Projects, I set audio_path = mediaserver/CVP/app/en-gb for e.g. and this works - as in Studio projects can resolve mediaserver = CVP1 IP.
But in case CVP1 is down, mediaserver-backup = CVP2 does not gets resolved automaticaly and call fails at play audio.
How to get Studio projects audio prompts to use mediaserver-backup please?
Thanks & Regards,
above are redundancy mechanism that CVP call server IVR service uses to fetch media.
if mediaserver is not available, it automatically appends mediaserver-backup and try to fetch file from there.(this is there for asr tts also,)
so this mechanism will work well for your most of the microapps, as they all use CVP call servers IVR service to create VXML page and serves gateway.
coming to audium script, it is loaded on VXML server so VXML server is responsible for creating VXML page and serving to VG and there is no such mechanism like this in VXML server,
you have to completely rely on load balancer like ACE to achieve redundancy.
i hope this answers your query correctly.
~please rate if helpful
You can accomplish a failover like this for Studio apps without a load balancer. In your Studio app, create Hotevent elements to catch the "error.badfetch" and "error.badfetch.http" events. Or, you can create a single Error element from a CVP Subdialog Return. In these cases you can send the call back to ICM, update the media server to "mediaserver-backup", and send the call back into your Studio script.
If you're clever about it, you can even return information about the last successful Studio step execution to ICM, and pass that back into the second Studio script run to start where you left off (in the case of a media server failure mid-script).
One more thing about using Hotevents vs. using the Error element here... With the Hotevents, you should be able to update your path and return to your normal Studio script execution without exiting out to ICM.
well, how many times you will be catching hot events?
this approach is not feasible say in studio application has 20 pages, and customer has to travel very large IVR menu.
this looks good in agent greeting kind of application
where agent wants to listen their current greeting, if greeting does not exist then http.bedfetch can be catched and asked agent to record new greeting.
i had used hot events with ASR/TTS (e.g tts.resource.unavailable) and it was not impressive.
after multiple hot events occurring on same call, it made my application to fail completely.
My point was, you don't absolutely have to have a load balancer. Yes, the logic within the app becomes more complicated, so as app size increases it becomes more worthwhile to load balance instead.
You can update a session variable throughout the app to keep track of the last position (perhaps names of Page Connectors for simplicity), and then do some logic after the Hotevent to go back to the right page based on the session variable value.
I would think that in a relatively stable network, most of your callers that experience the media server backup failover scenario would do so at the beginning of a call.