Introducción
Este documento describe un problema encontrado al usar el flujo de llamadas completo de CVP con la función de conexión de transferencia de AT&T ( DTMF *8).
Prerequisites
Requirements
Cisco recomienda que tenga conocimiento sobre estos temas:
- CVP versión 8.5
- Intelligent Contact Manager (ICM)
- Servicios AT&T Transfer Connect
Componentes Utilizados
La información que contiene este documento se basa en las siguientes versiones de software y hardware.
- ICM 8.5
- CVP 8.5
- CUBE versión 151-3.T4
- Conexión de AT&T Transfer
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). If your network is live, make sure that you understand the potential impact of any command.
Síntomas
Si el cliente realiza una llamada y la llamada se enruta a Cisco Unified Contact Center Enterprise (UCCE) a través de CVP, la llamada se transfiere de nuevo a un número externo en la red de AT&T (servicio de conexiones de transferencia). Cuando ocurre el problema, escuchas estas indicaciones de AT&T:
Espere, por favor
Sentimos que no se haya podido completar la llamada. Intente llamar de nuevo
Descripción de la causa/problema
En un flujo de llamadas completo de CVP, se recibe una llamada en CVP, CVP recibe la etiqueta DTM *8 seguida de 500 milisegundos (MS) pausados y un número 1800. CVP envía el DTMF a Cisco Unified Border Element (CUBE) y el gateway envía impulsos con los dígitos a la red de AT&T. Sin embargo, la llamada no se transfiere y el cliente escucha Lamentamos que no se pueda completar la llamada. Intente llamar de nuevo.
Paso 1. La persona que llama realiza una llamada desde la red telefónica pública conmutada (PSTN).
Paso 2. La puerta de enlace de entrada (IGW) recibe la llamada de PSTN; en este caso, CUBE es la puerta de enlace de entrada.
Paso 3. El IGW envía un mensaje SIP INVITE al CVP a través de un servidor proxy SIP.
Paso 4. CVP envía una solicitud de nueva llamada al ICM.
Paso 5. El ICM ejecuta el script de routing y envía una etiqueta de unidad de respuesta de voz (VRU) al CVP.
Paso 6. CVP envía un mensaje SIP INVITE a través del servidor proxy SIP al gateway XML de voz (VXML GW).
Paso 7. VXML GW ejecuta el script de bootstrap y envía una solicitud HTTP a CVP.
Paso 8. El CVP envía una instrucción de solicitud al ICM.
Paso 9. El ICM cancela el segmento VRU y envía la etiqueta DTMF al CVP. CVP termina el segmento VRU con VXML GW.
Paso 10. CVP envía el DTMF a IGW (CUBE).
Paso 11. IGW (CUBE) envía el DTMF a la red de AT&T.
Paso 12. La red de AT&T envía DTMF **7 La red no recibió o no puede reconocer el número marcado. Para escenarios de buen caso, CVP envía DTMF **6 y el cliente escucha, espere después de Espere.
Verificación
Paso 1. Configuración de CVP.
En el archivo sip.properties, en la carpeta de configuración, es necesario agregar la función SIP.ExternalTransferWait y establecerla en 1000 (1 segundo). Después de esto, reinicie el servidor de llamadas CVP.
Paso 2. Registros del servidor de llamadas de CVP.
Recopile seguimientos de CVP con Select com.dynamicSoft.DsLibs.DsUALibs establecido en el nivel Debug.
En los registros de CVP, confirme que CVP envía mensajes de información SIP al gateway de entrada (CUBE) para cada DTMF:
Por ejemplo, el tono "*" enviado a IGW (CUBE) desde CVP.
264788: 10.1.1.1: Nov 25 2013 12:28:25.362 -0800: %CVP_8_5_SIP-7-CALL: {Thrd=pool-1-thread-197-SIP-61173} 409D1D04-4D6B11E3-8E94E199-7280FCFD: Starting an external transfer with label: DTMF*8,,,,,18YYNXXXXXX
2059160: 10.1.1.1: Nov 25 2013 12:28:25.362 -0800: %_Connection-7-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.Connection: Sending Message (NB): INFO sip:5123809981@10.1.2.2:5060 SIP/2.0
Via: SIP/2.0/TCP 10.1.1.1:5060;branch=z9hG4bKa74MS0n9A4oRWinVIAjXSA~~47394
Max-Forwards: 70
To: <sip:5123809981@10.1.2.2>;tag=658DC428-11DA
From: <sip:5008007435000@10.1.1.11>;tag=dsefb53fdb
Call-ID: 409D1D04-4D6B11E3-8E94E199-7280FCFD@10.1.2.2
CSeq: 1 INFO
Content-Length: 26
Contact: <sip:10.1.1.1:5060;transport=udp>
Content-Type: application/dtmf-relay
Signal=*
Duration=100
Paso 3. Recopilar registros de gateway de entrada (CUBE).
debug ccsip message
debug voip rtp session name event
El relay DTMF negociado en el tramo PSTN (AT&T) es RTP-NTE usando el tipo de carga útil 100.
El relay DTMF negociado en el tramo CVP es sip-info y rtp-net usando el tipo de carga útil 101.
En los registros, se puede ver que el gateway de entrada (CUBE) recibe todos los dígitos del CVP mediante el mensaje de información SIP y lo envía a la PSTN (AT&T)
Por ejemplo, CUBE envía el dígito 7 a la red PSTN/AT&T
289591: Nov 15 22:20:52.244: s=DSP d=VoIP payload 0x64 ssrc 0x149A460E sequence 0xBD4 timestamp 0x2B700
289592: Nov 15 22:20:52.244: Pt:100 Evt:7 Pkt:0A 00 00 <Snd>>>
289593: Nov 15 22:20:52.244: s=DSP d=VoIP payload 0x64 ssrc 0x149A460E sequence 0xBD5 timestamp 0x2B700
289594: Nov 15 22:20:52.244: Pt:100 Evt:7 Pkt:0A 00 00 <Snd>>>
289595: Nov 15 22:20:52.244: s=DSP d=VoIP payload 0x64 ssrc 0x149A460E sequence 0xBD6 timestamp 0x2B700
Paso 4. Recopila la captura de paquetes en el gateway y confirma los requisitos de AT&T.
Requerimientos:
Tiempo de espera entre dígitos = 3 segundos
Para la señalización DTMF a la red, la VRU de la parte redireccionadora (CVP en este caso y CUBE) debe enviar tonos DTMF con una duración mínima de 80 ms de dígitos y 80 ms de silencio entre dígitos.
Se debe aplicar una pausa de al menos 350 ms entre *T y el número de redirección o código SD. (Los límites inferior y superior son de 300 ms a 11 s.)
Análisis de captura de paquetes
En las llamadas buenas, después de que CUBE envíe el último dígito a AT&T, AT&T envía el DTMF "* 6" alrededor de 500 MS
Tiempo entre dígitos enviados a AT&T = 200 MS
Tiempo desde DTMF *8 enviado y el primer dígito = 400 MS
Duración del evento - Longitud del dígito = 100 MS
Llamada incorrecta:
AT&T envía el DTMF **7, 6 segundos después de haber recibido el último dígito
Tiempo entre dígitos enviados a AT&T = 200 MS
Tiempo desde DTMF *8 enviado y el primer dígito = 400 MS
Duración del evento - Longitud del dígito = 100 MS
No hay diferencia entre las llamadas buenas y las malas en la captura de paquetes.
Resolución
Dado que los DTMF enviados a AT&T para las llamadas buenas y malas tienen las mismas propiedades y temporizadores, pero en algunos escenarios los DTMF no se reconocen, las pruebas se realizan agregando pausas antes de un grupo específico de dígitos y la combinación que resuelve el problema es:DTMF*8,,,,,1,,8YY,,,NXX,,XXXX,,,". Esto se cambia en el script ICM.