PDF(18.5 KB) View with Adobe Reader on a variety of devices
ePub(76.3 KB) View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
Mobi (Kindle)(71.8 KB) View on Kindle device or Kindle app on multiple devices
Updated:February 21, 2017
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes how to troubleshoot the Text-To-Speech (TTS) server failover in the Unified Contact Center Enterprise with Cisco Voice Portal (CVP) comprehensive setup and TTS server integration.
Cisco recommends that you have knowledge of these topics:
Cisco CVP Server
Cisco Voice XML gateway
The information in this document is based on the software version:
Cisco CVP Server 10.0 and above
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
TTS Server Failover not working on the Voice XML Gateway
When you integrate the VXML gateway with single TTS server, the TTS functioned well. However, after adding the second TTS server as the backup server by referring to the CVP configuration guide, the following 2 issues happen,
Issue 1. Even the call going to the primary TTS server stops working.
Issue 2. The failover function still doesn't work when the primary server was shutdown for testing the failover.
VXML gateway configuration for the TTS primary Server
ip host tts-en-us 10.34.4.16
ivr tts-server sip:tts@tts-en-us
voice class uri TTS
sip pattern tts@tts-en-us*
dial-peer voice 6 voip
destination uri TTS
session target ipv4:10.34.4.16
session protocol sipv2
dial-peer voice 8 voip
destination uri TTS
session target ipv4:10.34.4.17
session protocol sipv2
1. For first issue, while using standalone TTS server setup, the highlighed configuration doesn't use the server name but ip address of the TTS server, which worked fine, after changing it to the server name for redundancy testing which was indicated by the CVP configuration guide, the SIP invite did go to the TTS server, while the 200 OK came back, the Gateway Session IP Protocol stack tries to resolve the contact field which has the tts-en-us as the host portion of the URI,
2376927: Feb 11 04:15:14.411: //1082767/5C5538F2934F/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 200 OK Via: SIP/2.0/UDP 10.34.252.169:5060;branch=z9hG4bK10178DBF2 Contact: <sip:tts@tts-en-us:5060>
Some gateways running certain IOS fails to resolve it, which caused the SIP transaction terminated,
2377045: Feb 11 04:15:15.866: //-1/xxxxxxxxxxxx/SIP/Error/sip_dns_type_a_query:
TYPE A query failed for tts-en-us
You need to upgrade the gateway software later than15.5.1T to fix this issue, after upgrading the type A DNS query for the primary server succeeds since it was already configured locally on the gateway with ip host tts-en-us xxxx command.
2. For the second issue, while you use the tts-en-us as the host portion in the SIP URI for the TTS server. It is highlighted in the example configuration, the call fails when the primary server is shutdown for testing the failover.
From the debugs, the SIP Invite did go to the second TTS server with the same name tts-en-us as the host portion of the URI,
While the gateway did the server name resolution for the Contact field in the 200 OK, the server name is always resolved to the primary server ip address 10.34.4.16, since the same server name can only be resolved to one ip address in the gateway configuration.
Then the ACK message will be sent to 10.34.4.16 but 10.34.4.17, this causes the secondary TTS server sending additional 4-5 times of 200 OK, after that the SIP transaction termination since the secondary TTS server never receives the ACK which was sent to the primary TTS server at 10.34.4.16.
As the following guide reveals the details of supported scenario for redundant TTS/ASR in UCCE CVP environment, this scenario is not supported without Application Control Engine (ACE) or any other supported load balancer.
Design Guide for CVP
Redundancy and Failover for Unified CVP
This section describes redundancy and failover mechanisms for ASR, TTS, Media, and VXML Servers in the Unified CVP solution.
Redundancy for VXML Server Applications
VXML Server applications rely on the gateway’s configured default for ASR and TTS servers, which allow only a single host name or IP address to be specified for each. This differs from the Unified CVP micro-applications based applications, which support automatic retries to specifically named backup ASR and TTS servers.
Use this configuration on the gateway if you are using Nuance or Scansoft ASR/TTS servers:
ip host asr-en-us 10.10.10.1 ip host tts-en-us 10.10.10.2
The URL configured by the above ivr commands defines the gateway's default target for ASR and TTS services, and is in effect for all calls handled by that gateway. You can override it dynamically in your VXML Server application by populating the Cisco-proprietary VoiceXML properties com.cisco.asr-server or com.cisco.tts-server.
For ASR/TTS failover to function when using Custom VXML Applications, you require either an Application Control Engine (ACE) or any other supported load balancer.
Redundancy for Micro-App-Based Applications
When ACE is used for ASR or TTS servers, the IVR Service plays a significant role in implementing a failover mechanism for Media Servers, ASR/TTS Servers and micro-app-based applications. Up to two of each such servers are supported, and the IVR Service orchestrates retries and failover between them.
This redundancy mechanism is only available for Unified CVP micro-applications.
For information about setting up the IVR Service to accommodate failover, see the Administration Guide for Cisco Unified Customer Voice Portal.
From the above statement, if you deploy customized VXML application, the VXML server application has to use ACE/CSS to achieve the failover configuration, only the CVP micro-app can use the CVP failover mechanism by using,
When attempting to connect to an ASR/TTS Server, the IVR Service:
Resends the request the number of times defined in the IVR Service Configuration's ASR/TTS Server Retry Attempts field.
If the connection is not successful after the specified number of attempts, and the IVR Service Configuration's Use Backup ASR/TTS Servers field is set to Yes (the default), the IVR Service makes the same number of attempts to connect to a backup ASR/TTS server before failing and generating an error.
Note: The backup ASR and TTS servers are defined on the gateway as asr-<locale>-backup and tts-<locale>-backup.
In addition, the following defects were filed for the document defect and new feature for enhancement,