Support for Multiple TTS and ASR Vendors

southernchic · ‎10-30-2018

We currently have our Voice Gateway configured (and working) using one TTS and ASR server from one vendor.

We would like to add another TTS and ASR server from a second vendor. Is this possible (I think so)?

Here is the part of our config that contains the TTS/ASR entries.

ip host asr-en-us 10.240.4.144
ip host tts-en-us 10.240.4.144

!
voice class uri TTS sip
pattern tts@10.240.4.144
!
voice class uri ASR sip
pattern asr@10.240.4.144

ivr asr-server sip:asr@10.240.4.144
ivr tts-server sip:tts@10.240.4.144

Do we just make a copy these entries, specifying the IP address of the new TTS/ASR server?

And do we change asr-en-us and tts-en-us to something else (maybe asr-en-GB and tts-en-GB) ? If so does that mean we specify xml:lang="en-GB" in our VXML ?

Thanks in advance for any help you can provide!

bill.king1 · ‎10-31-2018

Just my $.02, but you may be better off having certain VXML gateways use the one vendor and other gateways use the other vendor, and not try to combine/mix them. Even if you get it to work, it might not be supported by Cisco, unless you're just adding additional entries (much like a primary/backup type setup) and not truly trying to load balance them.

In addition, keep in mind that some of this configuration is different/not available in the Virtual Voice Browser that you have to go to in the future.

Again, just my $.02, others may feel differently.

southernchic · ‎10-31-2018

Thanks for your $.02 :)

This is meant to be a temporary solution until we no longer have a need for the second vendor. Hopefully 6 months or so.

We need to control which vendor gets used from our custom VXML code. So we won't be trying to load balance them.

Just trying to figure out how to do this.

Brian Harber · ‎11-01-2018

I tend to agree that separating these functions out are going to allow you a level of operational safety. And with the advent of the VVB why not just virtualize and segregate these functions?

southernchic · ‎11-01-2018

Thanks for your suggestion. This has potential for a long term solution, but for now we need to quickly circumvent a problem that should hopefully be fixed early next year.