Understanding Provider Fallback for TTS

The TTS prompt requests can originate from VXML documents. VXML documents can use a property to specify a particular TTS provider. However, users have the option of not using this property.

In response to a TTS prompt request, the Provider Fallback goes through the following possible steps:

  1. With a VXML document, the system first tries the provider explicitly chosen (from the Cisco Unified CCX application or the VXML property). A provider can satisfy the request if (a) it is in service AND (b) the language-gender attributes requested by the prompt are supported by the provider.

    Each provider has a fallback mechanism to match the language-gender attributes. If the language specified is country specific such as en_US and the provider does not support it, it then checks if the base language, for example, 'en' is supported. For a detailed description of how gender attributed is matched, see Understanding Gender Fallback for MRCP TTS.

  2. If the explicitly specified provider fails to match the request, OR if no provider is specified explicitly, the system uses the “Default TTS Provider” configured on the system parameters Cisco Unified CCX Application Administration web page.

  3. If the System default provider fails to match the request, the system tries out all the providers configured through the TTS Cisco Unified CCX Application Administration web page. These providers are tried out in an indeterministic order.

  4. If all the configured TTS providers fail, the system falls back on the CiscoSSMLLite provider. This provider however is only capable of playing out wav file prompts specified through the “audio” element in SSML and VXML. If the prompt request contains any text, an application exception is thrown and the caller gets a system error.