Introducción
Este documento describe cómo resolver problemas la Conmutación por falla del servidor del texto a voz (TTS) en la empresa unificada del Centro de contacto con la integración completa porta de la configuración de la Voz de Cisco (CVP) y del servidor TTS.
Requisitos
Cisco recomienda que tenga conocimiento sobre estos temas:
- Servidor del CVP de Cisco
- Gateway de la Voz XML de Cisco
Componentes Utilizados
La información en este documento se basa en la versión de software:
- Servidor 10.0 del CVP de Cisco y arriba
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.
Problema
Conmutación por falla del servidor TTS que no trabaja en el gateway de la Voz XML
Cuando usted integra el gateway VXML con el solo servidor TTS, el TTS funcionó bien. Sin embargo, después de agregar el segundo servidor TTS como el servidor de backup refiriendo a la guía de configuración del CVP, los 2 problemas siguientes suceden,
Problema 1. Incluso la llamada que va al servidor primario TTS para el trabajar.
Problema 2. La función de la Conmutación por falla todavía no trabaja cuando era el servidor primario apaga para probar la Conmutación por falla.
Configuración de gateway VXML para el servidor primario TTS
el IP nos recibe TTS-EN-10.34.4.16
sorbo del TTS-servidor del ivr: tts@tts-en-us
uri TTS de la clase de la Voz
modelo tts@tts-en-us del sorbo *
voip de la voz de dial-peer 6
uri TTS del destino
destino de la sesión ipv4:10.34.4.16
Session Protocol sipv2
DTMF-retransmisión RTP-NTE
codificador-decodificador g711ulaw
ningún vad
voip de la voz de dial-peer 8
uri TTS del destino
destino de la sesión ipv4:10.34.4.17
Session Protocol sipv2
DTMF-retransmisión RTP-NTE
codificador-decodificador g711ulaw
preferencia 2
ningún vad
Solución
1. Para el primer problema, mientras que usa la configuración de servidor independiente TTS, la configuración highlighed no utiliza Nombre del servidor sino el IP Address del servidor TTS, que funcionó muy bien, después de cambiarlo al Nombre del servidor para la prueba de la Redundancia que fue indicado por la guía de configuración del CVP, el SORBO invita fue al servidor TTS, mientras que se volvió la AUTORIZACIÓN 200, la pila del protocolo IP de la sesión del gateway intenta resolver el campo del contacto que nos tiene TTS-EN-como la porción del host de URI,
2376927: 11 de febrero 04:15:14.411: //1082767/5C5538F2934F/SIP/Msg/ccsipDisplayMsg:
Recibido:
AUTORIZACIÓN SIP/2.0 200
Vía: SIP/2.0/UDP 10.34.252.169:5060;branch=z9hG4bK10178DBF2
Contacto: <sip:tts@tts-en-us:5060>
Algunos gatewayes que ejecutan cierto IOS no pueden resolverlo, que causó la transacción del SORBO terminada,
2377045: 11 de febrero 04:15:15.866: //-1/xxxxxxxxxxxx/SIP/Error/sip_dns_type_a_query:
TECLEE la interrogación A fallada para TTS-EN-nosotros
Usted necesita actualizar el software de gateway than15.5.1T posterior para reparar este problema, después de actualizar el tipo que la interrogación A DNS para el servidor primario tiene éxito puesto que fue configurada ya localmente en el gateway con el IP nos recibe TTS-EN-comando xxxx.
2. Para el segundo problema, mientras que usted nos utiliza TTS-EN-como la porción del host en el SORBO URI para el servidor TTS. Se resalta en el ejemplo de configuración, la llamada falla cuando es el servidor primario apaga para probar la Conmutación por falla.
De los debugs, el SORBO invita fue al segundo servidor TTS con el mismo nombre TTS-EN-nosotros que la porción del host de URI,
2375794: 11 de febrero 04:15:06.807: //1082767/5C5538F2934F/SIP/Msg/ccsipDisplayMsg:
Enviado:
INVITE a sip:tts@tts-en-us:5060 SIP/2.0
Vía: SIP/2.0/UDP 10.34.252.169:5060;branch=z9hG4bK10178DBF2
TELECONTROL-PARTIDO-ID: <sip:18621113335@10.34.252.169>;party=calling;screen=yes;privacy=off
Desde: sip:18621113335@10.2.14.16;tag=B3C09626-14B0
A: sorbo: tts@tts-en-us
Fecha: Casese, el 11 de febrero de 2015 04:15:06 GMT
ID de llamada: 6513BA51-B0DB11E4-BC2DD2C9-B1F3BEBE@10.34.252.169
Soportado: el temporizador, recurso-prioridad, substituye, SDP-anat
MINUTO-SE: 1800
Cisco-Guid: 1549089010-2967146980-2471471116-0231221760
Agente de usuario: Cisco-SIPGateway/IOS-15.2.4.M7
Permita: INVITE, LAS OPCIONES, ADIÓS, CANCELACIÓN, ACK, PRACK, ACTUALIZACIÓN, REFIÉRASE, INSCRIBA, NOTIFIQUE, INFORMACIÓN, REGISTRO
CSeq: 101 INVITE
MAX-Adelante: 70
Grupo fecha/hora: 1423628106
Contacto: <sip:18621113335@10.34.252.169:5060>
Expira: 60
Permitir-eventos: teléfono-evento
Tipo de contenido: aplicación/sdp
Contenido-disposición: sesión; handling=required
Contenido-longitud: 365
Mientras que el gateway hizo la resolución de nombre del servidor para el campo del contacto en la AUTORIZACIÓN 200, Nombre del servidor se resuelve siempre a la dirección IP 10.34.4.16 del servidor primario, puesto que lo mismo Nombre del servidor se pueden resolver solamente a un IP Address en la configuración de gateway.
2375799: 11 de febrero 04:15:06.861: //1082767/5C5538F2934F/SIP/Msg/ccsipDisplayMsg:
Recibido:
AUTORIZACIÓN SIP/2.0 200
Vía: SIP/2.0/UDP 10.34.252.169:5060;branch=z9hG4bK10178DBF2
Contacto: <sip:tts@tts-en-us:5060>
A: <sip:tts@tts-en-us>;tag=676efd0c
Desde: <sip:18621113335@10.2.14.16>;tag=B3C09626-14B0
ID de llamada: 6513BA51-B0DB11E4-BC2DD2C9-B1F3BEBE@10.34.252.169
CSeq: 101 INVITE
Permita: INVITE, ACK, CANCELACIÓN, LAS OPCIONES, ADIÓS, ACTUALIZACIÓN
Tipo de contenido: aplicación/sdp
Contenido-longitud: 281
v=0
o=JMRCPServer 392 392 EN IP4 10.34.252.169
s=-
c=IN IP4 10.34.4.17
t=0 0
m=audio 13512 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendonly
a=mid:1
m=application 2550 TCP/MRCPv2 1
a=setup: pasivo
a=connection: nuevo
a=channel:54DAD731207C127D6F474D257DE77@speechsynth
a=cmid:1
Entonces el mensaje ACK será enviado a 10.34.4.16 pero 10.34.4.17, esto causa el servidor secundario TTS que envía las 4-5 épocas adicionales de la AUTORIZACIÓN 200, después esas la terminación de la transacción del SORBO puesto que el servidor secundario TTS nunca recibe el ACK que fue enviado al servidor primario TTS en 10.34.4.16.
Pues la guía siguiente revela los detalles del escenario soportado para TTS/ASR redundante en el entorno del CVP UCCE, este escenario no se soporta sin el motor del control de la aplicación (ACE) o ningún otro balanceador soportado de la carga.
Guía de diseño para el CVP
Redundancia y Conmutación por falla para el CVP unificado
Esta sección describe los mecanismos de la Redundancia y de la Conmutación por falla para el ASR, el TTS, los media, y los servidores VXML en la solución unificada del CVP.
Redundancia para las aplicaciones del servidor VXML
Las aplicaciones del servidor VXML confían en el valor por defecto configurado del gateway para los servidores ASR y TTS, que permiten solamente un nombre o una dirección IP de solo host que se especificarán para cada uno. Esto diferencia de las aplicaciones basadas las microaplicaciones unificadas del CVP, que soportan los relanzamientos automáticos a backup específicamente Nombrado ASR y a los servidores TTS.
Utilice esta configuración en el gateway si usted está utilizando los servidores del matiz o de Scansoft ASR/TTS:
el IP nos recibe ASR-EN-10.10.10.1
el IP nos recibe TTS-EN-10.10.10.2
permiso del rtpsetup del cliente del mrcp
ASR-servidor rtsp://asr-en-us/recognizer del ivr
TTS-servidor rtsp://tts-en-us/synthesizer del ivr
agrupamiento de memoria 15000 del caché del cliente HTTP
archivo 500 del memoria ocult0 de caché del cliente HTTP
memoria pronto 15000 del ivr
el prompt del ivr no fluyó ninguno
el tiempo de espera agotado del cliente del mrcp conecta 5
mensaje 5 del tiempo de espera agotado del cliente del mrcp
el tiempo de espera agotado del cliente del rtsp conecta 10
mensaje 10 del tiempo de espera agotado del cliente del rtsp
memoria 500 del árbol del vxml
tiempo de inactividad 10 de la conexión cliente HTTP
ninguna conexión cliente HTTP persistente
El URL configurado por los comandos antedichos del ivr define la blanco predeterminada del gateway para los servicios ASR y TTS, y está en efecto para todas las llamadas manejadas por ese gateway. Usted puede reemplazarlo dinámicamente en su aplicación del servidor VXML poblando las propiedades com.cisco.asr-server o com.cisco.tts-server del VoiceXML del patentado Cisco.
Nota |
Para que la Conmutación por falla ASR/TTS funcione al usar las aplicaciones de encargo VXML, usted requiere un motor del control de la aplicación (ACE) o cualquier otro balanceador soportado de la carga.
|
Redundancia para las aplicaciones Micro-APP-basadas
Cuando el ACE se utiliza para los servidores ASR o TTS, el servicio IVR desempeña una importante función en implementar un mecanismo de la Conmutación por falla para los servidores de medios, los servidores ASR/TTS y las aplicaciones micro-APP-basadas. Hasta dos de cada tales servidores se soportan, y el servicio IVR orquestra las recomprobaciones y la Conmutación por falla entre ellas.
Nota
Nota |
Este mecanismo de redundancia está solamente disponible para las microaplicaciones unificadas del CVP.
|
Nota |
Para la información sobre configurar el IVR mantenga para acomodar la Conmutación por falla, ven la guía de administración para el Cisco Unified Customer Voice Portal.
|
De la declaración antedicha, si usted despliega la aplicación personalizada VXML, la aplicación del servidor VXML tiene que utilizar ACE/CSS para alcanzar la configuración de failover, sólo el CVP micro-APP puede utilizar el mecanismo de la Conmutación por falla del CVP usando,
Al intentar conectar con un servidor ASR/TTS, el servicio IVR:
- Vuelve a enviar la petición que la cantidad de veces definió en el campo de las tentativas de la recomprobación del servidor ASR/TTS de la configuración de servicio IVR.
- Si la conexión no es acertada después de que el número especificado de tentativas, y el campo de reserva de los servidores del uso ASR/TTS de la configuración de servicio IVR se fije al sí (el valor por defecto), el servicio IVR hace la misma cantidad de intentos para conectar con un servidor del respaldo ASR/TTS antes de fallar y de generar un error.
Note: El respaldo ASR y los servidores TTS se definen en el gateway como el asr-<locale>-backup y tts-<locale>-backup.
Defectos
Además, los defectos siguientes fueron clasifiados para el defecto y la nueva función del documento para la mejora,
Cisco BugID CSCut02530
CVP doc. de la actualización para aclarar el soporte de la Conmutación por falla ASR/TTS con la aduana VXML
Bug externamente encontrado del moderado (Sev3): N-nuevo
Cisco BugID CSCut02493
Conmutación por falla ASR/TTS no funcional para las aplicaciones de encargo VXML
Bug externamente encontrado de la mejora (Sev6): N-nuevo