Resolución de problemas del marcador de salida basado en IVR

Introducción

Este documento describe el marcador saliente IVR-basado e incluye una configuración de gateway del SORBO de la muestra, los análisis del registro del gateway del SORBO y del motor del Cisco Unified Contact Center Express (UCCX), y las limitaciones del marcador saliente IVR-basado.

En UCCX 8.5, presentaron a un tipo nuevo de marcador saliente: la respuesta de voz interactiva (IVR) - Marcador saliente basado. A diferencia del marcador saliente de un más viejo avance, no se utiliza ningún agente para hacer la llamada de salida. UCCX conecta directamente con un gateway del Session Initiation Protocol (SIP) en la empresa del cliente para marcar los contactos salientes. Cuando el gateway detecta una Voz o un Contestador automático viva, la llamada se reorienta a un activador UCCX limitado a un grupo de control de la llamada de salida. Terminado una vez en el puerto saliente del Integración de telefonía de computadora (CTI), la aplicación asociada al activador se ejecuta como normal.

Información sobre la Función

En las versiones UCCX anterior de 8.5, solamente el marcador saliente del avance existieron. Este marcador utilizó el control de llamada de tercero vía el Java Telephony Application Programming Interface (JTAPI) /CTI para dar instrucciones el teléfono del agente para hacer la llamada. La llamada fue hecha después de que un agente validara una reserva saliente. La interacción entre el cliente y servidor para las reservas salientes era realizada vía el CTI.

Con certeza utilice los casos (tales como recordatorios de la cita y aplicaciones IVR del autoservicio), el avance que el marcador saliente no era un buen ajuste. Para hacer una llamada a un número en el DialingList, un agente fue atado encima de mientras que la llamada fue puesta. Eso significó que el agente fue ocupado para cada llamada de salida, incluso si el número conmutado público de la red de telefonía (PSTN) era inválido, ocupado o dado lugar a un Contestador automático. Este nivel elevado de utilización del agente era una desventaja importante del marcador saliente del avance para estos casos del uso.

Flujo IVR-basado de la llamada de salida

Para los mismos casos del uso (los recordatorios de la cita y las aplicaciones IVR del autoservicio) en el marcador saliente IVR-basado, un agente se pudo nunca implicar en el flujo de llamada. Éste es el flujo de llamada para el marcador saliente IVR-Basar:

1. El marcador saliente IVR determina el número de contactos para marcar (según lo definido en el algoritmo) y utiliza el SIP para poner las llamadas de salida a través del gateway de voz.
2. El gateway de voz detecta el contacto NON-vivo con sus capacidades del análisis del progreso de la llamada (CPA) y envía el estatus del contacto NON-vivo al marcador. El marcador pone al día la información de estatus del contacto en la base de datos de la configuración.
3. El gateway de voz detecta el contacto vivo con sus capacidades CPA y envía el estatus del contacto vivo al marcador. El marcador pone al día la información de estatus del contacto en la base de datos de la configuración y también envía un SORBO refiere el mensaje al gateway del SORBO, que, a su vez, transfiere la llamada al punto de ruta configurado CTI en el administrador de las Comunicaciones unificadas de Cisco (CUCM).
4. El CUCM transfiere la llamada a un puerto IVR en el servidor de Cisco UCCX.
5. El subsistema IVR asocia la llamada a la aplicación IVR asociada a la campaña. El motor comienza la ejecución de la aplicación y una sesión IVR ocurre entre la aplicación IVR para la campaña en UCCX y el Contacto del cliente.

Tipos IVR-basados del marcador

Hay dos tipos de marcadores salientes IVR-Basar, profético y progresivo. Puesto que UCCX transfiere solamente una llamada a un puerto IVR para ejecutar un script cuando se detecta una Voz viva (o el Contestador automático configurable), es razonable asumir que no cada contacto saliente requiere un puerto. Para equilibrar la ocasión que un puerto CTI es necesario contra la probabilidad que el Ring No Answer (RNA), las situaciones ocupadas y del número no válido existe, los marcadores proféticos y progresivos modifican el número de llamadas de salida que se hagan en un momento contra el número de puertos salientes configurados CTI.

Un marcador saliente IVR-basado profético tiene estas características:

• La cantidad de líneas para cada puerto se puede ajustar, sobre la base del porcentaje de llamadas del abandono.
• No hay intervención manual necesaria.
• La meta es marcar bastantes líneas para mantener los puertos IVR ocupados pero para no exceder el Máximo configurado del porcentaje de llamadas del abandono.

Un marcador saliente IVR-basado progresivo tiene estas características:

• Usted puede especificar un número fijo de líneas que se marquen siempre para cada puerto saliente disponible IVR.
• La cantidad de líneas se puede poner al día más adelante.
• Si hay tres líneas para cada puerto y el número dedicado de puertos para saliente es tres, después se marcan nueve llamadas (3x3).
• Una llamada abandonada ocurre cuando un cliente contesta al teléfono, pero no hay puerto disponible indicar al cliente.
• Usted puede definir las configuraciones predeterminadas.

Componentes del marcador con UCCX

Todas las funciones y subsistemas internos se resumen para explicar este nuevo marcador saliente IVR-basado. Los componentes del sistema en el nuevo marcador, como la tabla del motor y de DialingList, son lo mismo que en el marcador saliente del avance, con las Extensiones (como más valores del callStatus y del callResult) agregadas.

Información de la función del gateway

Para soportar la detección de Voz viva, el Contestador automático y los tonos especiales de información (SIÉNTESE), el gateway deben soportar la característica CPA. Utilice el Cisco Feature Navigator para determinar las versiones del ^{® del} Cisco IOS del gateway que soportan el marcador SIP y el CPA; utilice “búsqueda por la búsqueda de la característica” para el “soporte de la utilidad para el marcador del SORBO y el análisis del progreso de la llamada.”

¿Cómo el CPA trabaja?

Hay tres funciones primarias en el CPA:

• Detección del Contestador automático (AMD)
• Fax/detección del módem
• Contestador automático que termina la detección del tono

Hay algoritmos complejos implementados para hacer estas distinciones, pero, de una punta funcional del soporte:

• Se espera que una respuesta viva del partido sea un saludo corto, entonces un período de silencio.
  Ejemplo: “Hola” + silencio
  Ejemplo: “Hola, residencia de Johnson” + silencio
• Se espera que un Contestador automático sea un saludo más largo, entonces ningún silencio.
  Ejemplo: “Usted ha alcanzado la residencia del Miller, deja por favor un mensaje después de la señal acústica”
• Se espera que un Contestador automático que termina el tono detecta sea detección del Contestador automático, después del silencio, entonces un tono terminal.
• Un fax detecta es reconocimiento del tono del fax.

La capacidad de hacer estas distinciones pudo ser difícil, así que usted puede ser que necesite ajustar los parámetros de temporización para optimizar la configuración.

Otro factor a considerar es que los proveedores del teléfono celular pudieron tener diversos grados de retardo entre la presentación de una llamada a ellos, ubicación de la célula, y la presentación de la llamada a la célula sí mismo.

Esto es un ejemplo del cálculo implicado:

1. UCCX envía un SORBO invita al gateway (el T1)
2. El gateway envía una configuración de llamada ISDN al proveedor de servicio y sobre el proveedor de la célula (el T2)
3. El teléfono celular no suena y comienza su ningún temporizador de la respuesta (el T3)
4. El temporizador de la célula RNA expira y adelante al voicemail (el t4)

Si usted asume que el temporizador RNA para la célula es 15 segundos, la cantidad real de tiempo que llevaría para una llamada una célula para remitir al voicemail es (T1 + T2 + T3 + 15). El T1 + el T2 + el T3 podrían ser perceptiblemente más altos que la cantidad de tiempo que toma para presentar una llamada a la línea horizonte o al otro dispositivo de la NON-célula.

Así, cuando usted no define el ningún límite del anillo de la respuesta para una campaña, el período de tiempo necesita ser de largo bastante alcanzar el sistema de correo de voz para los teléfonos celulares; ésta sería la conducta deseada, por ejemplo, para una campaña prevista para dejar un mensaje.

Note: El CPA es funciones del gateway; a diferencia del Cisco Unified Contact Center Enterprise (UCCE), el CPA no se puede dar vuelta con./desc. en UCCX. Mientras que el CPA se puede apagar en el gateway, Cisco no recomienda esto. Para más información, refiera a la descripción de Analyis del progreso de la llamada.

La selección de códigos del gateway del IOS está fuera del alcance de este documento. El código del gateway debe soportar el CPA y SORBER el marcador para utilizar el marcador saliente IVR-basado. El Cisco Feature Navigator puede ayudarle a encontrar las versiones del IOS que cumplen los requisitos de la función. Asegúrese siempre que su versión del IOS sea compatible con todos los componentes que obren recíprocamente con este gateway.

Troubleshooting

Note: Use la Command Lookup Tool (clientes registrados solamente) para obtener más información sobre los comandos usados en esta sección.

Para resolver problemas un IVR saliente, determine si el gateway, el CUCM o el UCCX es culpables. El troubleshooting es más fácil una vez que usted aísla el problema a un componente específico. Es útil recoger esta información de los componentes del sistema

Para el gateway, funcione con estos comandos:

1. show tech
2. haga el debug de los ccsips messages
3. debug voip ccapi inout
4. haga el debug de ISDN q931 (o el debug similar para capturar la señalización del lado PSTN)
5. haga el debug del hpi todo del voip (resolver problemas el CPA)
6. haga el debug del vtsp todo del voip (resolver problemas el CPA)

Para UCCX, revise los archivos del registro y la configuración:

1. Archivos del registro MIVR con el debugging SS_OB y XDebug1 - XDebug3 habilitado
2. Archivos del registro JTAPI (resolver problemas la falla de llamada referida)
3. Configuración de gateway del SORBO del AppAdmin UCCX

Para el CUCM, configuraciones del estudio:

1. CallManager detallado
2. CTIManager detallado
3. La configuración del tronco del SORBO que señala al gateway utilizó para el IVR saliente

Análisis de datos

El gateway del SORBO debe contener la configuración necesaria no sólo para rutear los pedidos de llamada de UCCX al PSTN, pero también para manejar la transferencia de esas llamadas al activador UCCX señalado para saliente. Esta configuración de gateway del SORBO debe tener:

1. Dial peer de entrada para hacer juego las peticiones entrantes del SORBO de UCCX.
2. Dial-peer de salida (VoIP o servicio de telefonía del llano viejo [POTS]) para rutear las llamadas al PSTN.
3. Dial-peer de salida (VoIP) para rutear la llamada (referida) reorientada al cluster CUCM que se integra con UCCX.

El servidor CUCM se debe configurar para recibir los pedidos de llamada entrantes del SORBO del gateway del SORBO (las llamadas referidas) y para rutear las peticiones por consiguiente al activador UCCX y a los puertos del grupo de Control de llamadas UCCX CTI.

Configuración de gateway del SORBO de la muestra

Éste es un ejemplo de una configuración de gateway del SORBO con las notaciones. La conectividad PSTN en este ejemplo es la Interfaz de velocidad primaria ISDN (PRI).

Note: Soportan a otros tipos de conectividad PSTN de la multiplexación de división de tiempo (TDM), pero el Cisco Unified Border Element (CUBO) no se soporta. Vea el bug Cisco ID CSCui62525 y CSCuf44826 para más información sobre el soporte del CUBO. Las conexiones múltiples al TDM PSTN se soportan para rutear diversas clases de llamadas (local, larga distancia, internacionales) a los diversos trunks o proveedores.

RyanIVRRouter#show run
Building configuration...

Controlador T1 configurado para ISDN PRI

!
controller T1 0/0/0
 cablelength long 0db
 pri-group timeslots 1-24
!

Interfaz serial configurada para ISDN PRI

!
interface Serial0/0/0:23
 no ip address
 encapsulation hdlc
 isdn switch-type primary-ni
 isdn incoming-voice voice
 no cdp enable
!

Puerto de voz para rutear las llamadas de salida al PSTN

!
voice-port 0/0/0:23
!

VoIP dial-peer de entrada

Pedidos de llamada entrantes de este SORBO de las correspondencias de dial-peer de UCCX. Si no configuran a un VoIP dial-peer de entrada, corresponden con al dial-peer por default (dial-peer 0). Es mejor práctica definir y hacer juego a un VoIP dial-peer de entrada. Este dial-peer notifica el gateway de la retransmisión del codificador-decodificador, del protocolo y del Multifrecuencia de tono dual (DTMF) que se utilizará en la pierna entrante del SORBO de UCCX.

Este las correspondencias de dial-peer todas SORBO entrante invitan con un Digital Number Identification Service (DNIS) a ese comienzo con 717 y ése es 10 dígitos de largo. En este ejemplo, todos los contactos marcados por UCCX están en el código de área 717 y tienen números de teléfono 10 dígitos de largo.

!
dial-peer voice 100 voip
 description -- Outbound Calls From UCCX -- 
 session protocol sipv2
 incoming called-number 717.......
 dtmf-relay rtp-nte
 codec g711ulaw
!

POTS dial peer

Este dial-peer rutea las llamadas al PSTN sobre el PRI configurado previamente. Es la dial peer saliente para los pedidos de llamada que vienen de UCCX y el dial-peer de salida para el VoIP dial-peer 100 antedicho. Este dial-peer también sirve como dial peer de entrada para las llamadas que vienen del PSTN para las para pruebas. En el flujo de llamada saliente del marcador UCCX, este dial-peer no se corresponde con como dial peer de entrada.

!
dial-peer voice 10 pots
 description -- POTS Dial Peer To/From PSTN Simulator --
 destination-pattern 717.......
 incoming called-number .
 direct-inward-dial
 port 0/0/0:23
 forward-digits all
!

VoIP dial-peer de salida

Este dial-peer sirve como el dial-peer de salida necesario por el gateway del SORBO para rutear las llamadas al cluster CUCM destinado para el activador UCCX. Se detecta este dial-peer es utilizado por el gateway para rutear REFER enviado por UCCX cuando está vivo expresa (o Contestador automático si existe la configuración). Este dial-peer define el protocolo, el relé dtmf, el codificador-decodificador y la dirección IP del nodo CUCM donde el gateway del SORBO debe rutear la llamada reorientada. Con objeto de la Redundancia y el Equilibrio de carga, los dial-peer múltiples de este tipo pudieron existir. Podrían ser divididos a los pedidos de ruta a los Nodos múltiples CUCM en el cluster o ser aprovisionado a rutear reorienta con certeza los activadores a diversos Nodos CUCM.

En este ejemplo, los activadores UCCX para las campañas salientes IVR-Basar son 2001 y 2002.

!
dial-peer voice 102 voip
 description -- Redirect Calls to UCCX 90 --
 destination-pattern 200[1-2]
 session protocol sipv2
 session target ipv4:14.10.166.15
 incoming called-number 200[1-2]
 dtmf-relay rtp-nte
 codec g711ulaw
!

La muestra IVR-basó el análisis de traza de la llamada de salida

Ésta es una análisis detallado de un registro de la Mensajería del ejemplo entre el gateway del SORBO, UCCX y el PSTN.

La inicial INVITA de UCCX da instrucciones el gateway para hacer una llamada al número PSTN. La INVITACIÓN contiene el ID de llamada, que se puede utilizar para seguir todos los mensajes asociados a esta llamada, y el protocolo session description (SDP) (parámetros de los media).

Lo que es más importante, la INVITACIÓN incluye los parámetros que el gateway debe utilizar para completar el CPA. Estos parámetros se configuran en las páginas de AppAdmin UCCX, pero no son utilizados por UCCX. Bastante, se envían en la INVITACIÓN al gateway y son utilizados por el gateway para configurar los procesadores de señales digitales (DSPs) para el CPA para esta llamada. Como consecuencia, estos parámetros se envían al gateway sobre por llamada una base y se pueden cambiar en cualquier momento del AppAdmin.

UCCX envía estos atributos de la configuración CPA al gateway para cada llamada:

Los Valores configurables se presentan en el AppAdmin en la página de la configuración de gateway del SORBO.

Received: 
INVITE sip:7175551212@14.10.153.56:5060;transport=udp SIP/2.0
...
Call-ID: 134401919546410@14.10.166.16
...
Content-Type: multipart/mixed;boundary=unique_boundary

--unique_boundary
Content-Type: application/sdp
Content-Disposition: session;handling=required

v=0
o=Cisco-UCCX 1608 1 IN IP4 14.10.166.16
s=SIP Call
c=IN IP4 0.0.0.0
t=0 0
m=audio 12345 RTP/AVP 0 
a=rtpmap:0 PCMU/8000
a=ptime:20
--unique_boundary
Content-Type: application/x-cisco-cpa
Content-Disposition: signal;handling=optional

Events=FT,Asm,AsmT,Sit
CPAMinSilencePeriod=375
CPAAnalysisPeriod=2500
CPAMaxTimeAnalysis=3000
CPAMinValidSpeechTime=112
CPAMaxTermToneAnalysis=15000
--unique_boundary--

Mientras que la llamada está procesando a través del dial-peers del gateway, UCCX se envía un mensaje '100 Trying.

Sent: 
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 14.10.166.16:5065;branch=z9hG4bKEsF4FAHPTVliP0ozE1BcOQ~~17
From: <sip:9195551212@14.10.166.16>;tag=dsa994554a
To: <sip:7175551212@14.10.153.56>
Date: Fri, 03 Aug 2012 18:38:46 GMT
Call-ID: 134401919546410@14.10.166.16
CSeq: 100 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0

Cuando la llamada de salida hace juego a un dial-peer de salida, se envía al PSTN usando el protocolo configurado TDM. En este caso, se utiliza un PRI:

Aug  3 18:38:46.559: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8  callref = 0x008D 
	Bearer Capability i = 0x8090A2 
		Standard = CCITT 
		Transfer Capability = Speech  
		Transfer Mode = Circuit 
		Transfer Rate = 64 kbit/s 
	Channel ID i = 0xA98397 
		Exclusive, Channel 23 
	Calling Party Number i = 0x2180, '9195551212' 
		Plan:ISDN, Type:National
 	Called Party Number i = 0xA1, '7175551212' 
		Plan:ISDN, Type:National

Los progresos de la llamada y la señalización se intercambia entre el PSTN y el gateway. Se notifica el gateway que el teléfono PSTN está sonando con el mensaje QUE ALERTA.

Aug  3 18:38:46.595: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8  callref = 0x808D 
	Channel ID i = 0xA98397 
		Exclusive, Channel 23

Aug  3 18:38:46.603: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8  callref = 0x808D 
    Progress Ind i = 0x8188 - In-band info or appropriate now available

El gateway envía un progreso de 183 sesiones de nuevo a UCCX para notificar UCCX que el teléfono PSTN está sonando. Esto incluye el SDP para la negociación de medios de los tonos de recepción de llamada.

Sent: 
SIP/2.0 183 Session Progress
...
Call-ID: 134401919546410@14.10.166.16
...
--uniqueBoundary
Content-Type: application/sdp
Content-Disposition: session;handling=required

v=0
o=CiscoSystemsSIP-GW-UserAgent 7343 9805 IN IP4 14.10.153.56
s=SIP Call
c=IN IP4 14.10.153.56
t=0 0
m=audio 32330 RTP/AVP 0 101 19
c=IN IP4 14.10.153.56
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:19 CN/8000
a=ptime:20
...
--uniqueBoundary
Content-Type: application/x-cisco-cpa
Content-Disposition: signal;handling=optional

event=enabled
--uniqueBoundary--

La llamada está conectada en la pierna TDM como el teléfono PSTN contestó a la llamada. El gateway envía una confirmación en el CONNECT_ACK.

Aug  3 18:38:49.207: ISDN Se0/0/0:23 Q931: RX <- CONNECT pd = 8  callref = 0x808D

Aug  3 18:38:49.211: ISDN Se0/0/0:23 Q931: TX -> CONNECT_ACK pd = 8  callref = 0x008D

El gateway notifica UCCX que la llamada está conectada con una AUTORIZACIÓN 200. UCCX ACK esto, de acuerdo con del SORBO RFC. La AUTORIZACIÓN 200 también contiene el SDP para la negociación de medios, pero no es utilizada por UCCX.

Sent: 
SIP/2.0 200 OK
...
Call-ID: 134401919546410@14.10.166.16
...
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 271

v=0
o=CiscoSystemsSIP-GW-UserAgent 7343 9805 IN IP4 14.10.153.56
s=SIP Call
c=IN IP4 14.10.153.56
t=0 0
m=audio 32330 RTP/AVP 0 101 19
c=IN IP4 14.10.153.56
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:19 CN/8000
a=ptime:20

Received: 
ACK sip:7175551212@14.10.153.56:5060 SIP/2.0
...
Call-ID: 134401919546410@14.10.166.16
...

El gateway detecta el progreso de la llamada con el CPA y notifica UCCX del progreso de la llamada con una serie de mensajes de actualización. UCCS ACK esto, de acuerdo con del SORBO RFC.

En este ejemplo de una actualización del SORBO, “se detecta” el evento y el estatus es “CpaS”.

• CpaS indica que el CPA ha comenzado.
• Cuando se detecta un Contestador automático, el estatus es “Asm.”
• Cuando se califica el tono del Contestador automático, el estatus es “AsmT.”

Esta tabla enumera los códigos de estado x-Cisco-CPA usados en los mensajes de actualización del SORBO:

Sent: 
UPDATE sip:9195551212@14.10.166.16:5065;transport=udp SIP/2.0
...
Call-ID: 134401919546410@14.10.166.16
...
Content-Type: application/x-cisco-cpa
Content-Disposition: signal;handling=optional
Content-Length: 26

event=detected
status=CpaS

Received: 
SIP/2.0 200 Ok
...
Call-ID: 134401919546410@14.10.166.16
...

UCCX envía una notificación al gateway para reorientar la llamada al activador asignado a esta campaña saliente. El gateway ACK esto.

Received: 
REFER sip:7175551212@14.10.153.56:5060 SIP/2.0
...
Call-ID: 134401919546410@14.10.166.16
...
Refer-To: <sip:2001@14.10.153.56>
...

Sent: 
SIP/2.0 202 Accepted
...
Call-ID: 134401919546410@14.10.166.16
...

El gateway debe rutear esta llamada al nuevo destino como cualquier proceso de llamada normal a través del dial-peers en el gateway.

Aug  3 18:39:07.275: //60/7120520F060E/CCAPI/ccCallSetupRequest:
   Destination=, Calling IE Present=FALSE, Mode=0,
   Outgoing Dial-peer=102, Params=0x31BDB494, Progress Indication=NULL(0)

La llamada es ruteada por el gateway basado sobre la configuración en el dial-peer de salida correspondido con para el destino contenido dentro del REFERIR.

Sent: 
INVITE sip:2001@14.10.166.15:5060 SIP/2.0
...
Call-ID: 5789DBCB-DCD111E1-8081ADFE-F735B3DC@14.10.153.56
...
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 270

v=0
o=CiscoSystemsSIP-GW-UserAgent 5187 301 IN IP4 14.10.153.56
s=SIP Call
c=IN IP4 14.10.153.56
t=0 0
m=audio 25002 RTP/AVP 0 101 19
c=IN IP4 14.10.153.56
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:19 CN/8000
a=ptime:20

Análisis del registro de la muestra MIVR

Este snippets de un registro MIVR proporciona una descripción de la llamada de una perspectiva UCCX. Permita a estos niveles de debug para capturar la información correcta:

• SS_OB - Debug,XD1,XD2,XD3
• SS_RM - Debug,XDebug1
• CFG_MGR - Debug,XDebug1 (si el problema está con los expedientes de marca de la lista)
  

135533948: Aug 20 21:34:54.631 EDT %MIVR-CFG_MGR-7-UNK:ConfigManagerImpl-getAll():CIR
[0]=ConfigImportRecord[schema=DialingListConfig#2,time=2012-08-20 21:34:42.0,
recordId=239,implClass=class com.cisco.crs.outbound.DialingListConfig,desc=,
values=[239, 2, 1662760, NAME, TEST777, 9785551212, , , 343, true, -1, true, -1, true, , 
2012-08-20 21:34:42.0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, null, null, null, null],evalues=null]
//Import the record from the dialing list. In this case, the recordID=239


135533949: Aug 20 21:34:54.632 EDT %MIVR-CFG_MGR-7-UNK:ConfigManagerImpl-getAll():con
figObjs[0]=DialingListConfig[schema=DialingListConfig#2,time=2012-08-20 21:34:42.0,
recordId=239,desc=,recordID=0,dialingListID=239,campaignID=2,accountNumber=1662760,
firstName=NAME,lastName=TEST777,phone01=9785551212,phone02=,phone03=,gmtZonePhone01=343,
dstPhone01=true,gmtZonePhone02=-1,dstPhone02=true,gmtZonePhone03=-1,dstPhone03=true,
callbackNumber=,callbackDateTime=2012-08-20 21:34:42.0,callStatus=1,callResult=0,
callResult01=0,callResult02=0,callResult03=0,lastNumberDialed=0,callsMadeToPhone01=0,
callsMadeToPhone02=0,callsMadeToPhone03=0,numMissedCallback=0,isRetries=false]
//RecordID=239; campaignID=2

Note: Puesto que pudo haber campañas múltiples al mismo tiempo, es importante prestar la atención al campaignID y al recordID.

B-7-UNK:CMgrUtil: getPhoneNumber: callStatus=2callResult=0lastNumDialed=0

135534103: Aug 20 21:34:55.424 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getPhoneNumber: 
   callStatus=2callResult=0lastNumDialed=0
135534104: Aug 20 21:34:55.424 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getUnformattedPhoneNumber: 
   dlcID:239
135534105: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getFormattedPhoneNumber: 
   phoneNum=9785551212
135534106: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getFormattedPhoneNumber: 
   intPrefix= localAreaCode = 416 lenAreaCode = 3 include lac = true dialingPrefix = 9 
   longDistPrefix = 91
135534107: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil.getFormattedPhoneNumber(): 
   domestic number
135534108: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil.getFormattedPhoneNumber(): 
   long distance number
135534109: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:numToDial=9919785551212
135534110: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getUnformattedPhoneNumber: 
   dlcID:239
135534111: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil.getTimeZoneId - 
   phoneNum=9785551212
135534112: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getGmtOffset: 
   DST observed=true
135534113: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil.getTimeZoneId - 
   phoneNum=9785551212

//Based on the Campaign config, the phone number is modified accordingly. In a failed call 
scenario, you might want to verify what the number is after the formatting is done. Look 
for 'MIVR-SS_OB-7-UNK:numToDial=' which gives you the actual number to be dialed.

135534128: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:OutboundIVRContactsRequestor: 
Contacts returned from CampaignMgr for campaignID:2 are [OutboundContactInfo: dlc:239 
(phoneNumber:9919785551212 unformattedPhoneNumber:9785551212 timezone -240 
callStartTime 0 answeringMachine false ) ]
//phoneNumber:9919785551212; unformattedPhoneNumber:9785551212. 

Aquí están los phoneNumbers formatados y sin formato:

135534131: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:IVRDialer:findValidContact() - 
processing contact in queue OutboundContactInfo: dlc:239 (phoneNumber:9919785551212 
unformattedPhoneNumber:9785551212 timezone -240 callStartTime 0 answeringMachine false )

El SORBO que señala el comienzo:

SIP-9919785551212  INVITE sip:9919785551212@10.10.10.7:5060;transport=udp SIP/2.0

SIP-9919785551212  SIP/2.0 100 Trying

SIP-9919785551212  SIP/2.0 183 Session Progress

SIP-9919785551212  SIP/2.0 200 OK

Verifique la dirección de estos mensajes en el gateway con la Mensajería del gateway explicada previamente.

135534720: Aug 20 21:34:58.809 EDT %MIVR-SS_OB-7-UNK:ProcessAccepted: DialerSipCall-68, 
State=CONTACTING, fromDN=8005553434, toDN=9919785551212, 
callId=134551289542668@10.10.10.5 sending
 
SIP-9919785551212  ACK sip:9919785551212@10.10.10.7:5060 SIP/2.0

135534722: Aug 20 21:34:58.810 EDT %MIVR-SS_OB-7-UNK:OnConnectionCompleted DialerSipCall-68,
State=ACTIVE, fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5 
notify 
com.cisco.wf.subsystems.outbound.SIPAdapterCallListenerImpl@1b91fa4.onConnectionCompleted()
//The initial SIP signalling is completed

135534723: Aug 20 21:34:58.810 EDT %MIVR-SS_OB-7-UNK:SIPAdapterCallListenerImpl.
onConnectionCompleted post OutboundPlaceGWCallRespMsg: GWCall:  dlcID: 239, csqID: -1, 
contactNumToDial:9919785551212false, dialerType:IVR_DIALER, DialerSipCall-68, State=ACTIVE, 
fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5, status=OK
//The outbound subsystem posts the 'Place call' request to the gateway

135534724: Aug 20 21:34:58.810 EDT %MIVR-SS_OB-7-UNK:OutboundDialerProcessor:Processing msg: 
OutboundPlaceGWCallRespMsg: GWCall:  dlcID: 239, csqID: -1, 
contactNumToDial:9919785551212false, dialerType:IVR_DIALER, DialerSipCall-68, State=ACTIVE, 
fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5, 
status=OK135534725: Aug 20 21:34:58.810 EDT 
%MIVR-SS_OB-7-UNK:IVRDialer:ProcessOutboundPlaceGWCallRespMsg: 
OutboundPlaceGWCallRespMsg: GWCall:  dlcID: 239, csqID: -1, 
contactNumToDial:9919785551212false, dialerType:IVR_DIALER, 
DialerSipCall-68, State=ACTIVE, fromDN=8005553434, toDN=9919785551212, 
callId=134551289542668@10.10.10.5, status=OK
//The OutboundPlaceCall request is processed by the Outbound Dialer, then by the IVR 
Dialer processes
135534728: Aug 20 21:34:58.810 EDT %MIVR-SS_OB-7-UNK:CampaignStatistics:
incrementAttemptedCalls() for phoneNumber=9919785551212 to 1
135534729: Aug 20 21:34:58.810 EDT %MIVR-SS_OB-7-UNK:HalfHourCampaignData:
incrementAttemptedCalls() by 1. Total attempted calls = 1
//Since this is the first time the record is dialled out, the total attempted calls = 1

El gateway envía un mensaje de actualización del SORBO junto con el mensaje CPA. El software CPA se ejecuta en el gateway y analiza el Real-Time Transport Protocol (RTP) de la Parte llamada. Esto ayuda a distinguir entre la Voz y el Contestador automático en el extremo de la Parte llamada. Usted puede identificar un mensaje de actualización del SORBO CPA de su tipo de contenido de “application/x-cisco-cpa”.

SIP-9919785551212  UPDATE sip:8005553434@10.10.10.5:5060;transport=udp SIP/2.0
SIP-9919785551212  Via: SIP/2.0/UDP 10.10.10.7:5060;branch=z9hG4bK2362542
SIP-9919785551212  Max-Forwards: 69
SIP-9919785551212  To: <sip:8005553434@10.10.10.5>;tag=dsaf56bbcc
SIP-9919785551212  From: <sip:9919785551212@10.10.10.7>;tag=3D33950C-948
SIP-9919785551212  Call-ID: 134551289542668@10.10.10.5
SIP-9919785551212  CSeq: 102 UPDATE
SIP-9919785551212  Content-Length: 26
SIP-9919785551212  Date: Tue, 21 Aug 2012 01:34:58 GMT
SIP-9919785551212  User-Agent: Cisco-SIPGateway/IOS-15.2.4.M1
SIP-9919785551212  Supported: timer,resource-priority,replaces,sdp-anat
SIP-9919785551212  Timestamp: 1345512899
SIP-9919785551212  Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
    NOTIFY, INFO, REGISTER
SIP-9919785551212  Contact: <sip:9919785551212@10.10.10.7:5060>
SIP-9919785551212  Min-SE: 1800
SIP-9919785551212  Content-Type: application/x-cisco-cpa
SIP-9919785551212  Content-Disposition: signal;handling=optional
SIP-9919785551212  
SIP-9919785551212  event=detected
SIP-9919785551212  status=CpaS

SIP-9919785551212  UPDATE sip:8005553434@10.10.10.5:5060;transport=udp SIP/2.0
SIP-9919785551212  Via: SIP/2.0/UDP 10.10.10.7:5060;branch=z9hG4bK23714F6
SIP-9919785551212  Max-Forwards: 69
SIP-9919785551212  To: <sip:8005553434@10.10.10.5>;tag=dsaf56bbcc
SIP-9919785551212  From: <sip:9919785551212@10.10.10.7>;tag=3D33950C-948
SIP-9919785551212  Call-ID: 134551289542668@10.10.10.5
SIP-9919785551212  CSeq: 103 UPDATE
SIP-9919785551212  Content-Length: 163
SIP-9919785551212  Date: Tue, 21 Aug 2012 01:34:58 GMT
SIP-9919785551212  User-Agent: Cisco-SIPGateway/IOS-15.2.4.M1
SIP-9919785551212  Supported: timer,resource-priority,replaces,sdp-anat
SIP-9919785551212  Timestamp: 1345512902
SIP-9919785551212  Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
    NOTIFY, INFO, REGISTER
SIP-9919785551212  Contact: <sip:9919785551212@10.10.10.7:5060>
SIP-9919785551212  Min-SE: 1800
SIP-9919785551212  Content-Type: application/x-cisco-cpa
SIP-9919785551212  Content-Disposition: signal;handling=optional
SIP-9919785551212  
SIP-9919785551212  event=detected
SIP-9919785551212  status=LV
SIP-9919785551212  pickupT=320
SIP-9919785551212  maxActGlitchT=0
SIP-9919785551212  numActGlitch=0
SIP-9919785551212  valSpeechT=20
SIP-9919785551212  maxPSSGlitchT=0
SIP-9919785551212  numPSSGlitch=0
SIP-9919785551212  silenceP=0
SIP-9919785551212  termToneDetT=0
SIP-9919785551212  noiseTH=1000
SIP-9919785551212  actTh=32000

//This shows that Low Volume is detected. Now, based on the Campaign setting 'Handle Low 
Volume as Voice,' this call is handled accordingly

135535726: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:OnCPAStatus DialerSipCall-68, 
State=ACTIVE, fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5 
notify com.cisco.wf.subsystems.outbound.SIPAdapterCallListenerImpl@1b91fa4.onCPAStatus
(status=LowVolume)
135535727: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:SIPAdapterCallListenerImpl.onCPAStatus 
post OutboundUpdateGWCallStatusMsg: GWCall:  dlcID: 239, csqID: -1, 
contactNumToDial:9919785551212false, dialerType:IVR_DIALER, DialerSipCall-68, State=ACTIVE, 
fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5, status=LowVolume
135535728: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:OutboundDialerProcessor:Processing msg: 
OutboundUpdateGWCallStatusMsg: GWCall:  dlcID: 239, csqID: -1, 
contactNumToDial:9919785551212false, dialerType:IVR_DIALER, DialerSipCall-68, State=ACTIVE, 
fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5, status=LowVolume
135535729: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:IVRDialer:
ProcessOutboundUpdateGWCallStatusMsg: OutboundUpdateGWCallStatusMsg: GWCall:  dlcID: 239, 
csqID: -1, contactNumToDial:9919785551212false, dialerType:IVR_DIALER, DialerSipCall-68, 
State=ACTIVE, fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5, 
status=LowVolume
135535730: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:IVRDialer:
ProcessOutboundUpdateGWCallStatusMsg(): Low Volume detected
135535731: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:IVRDialer:
ProcessOutboundUpdateGWCallStatusMsg(): Handle Low Volume as Voice is true
135535732: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:IVRDialer:
ProcessOutboundUpdateGWCallStatusMsg(): PostingOutboundIVRUpdateContactMsg with 
callstatus = 3(Closed), callresult = 1(Low Volume) for dlcID = 239

Problemas Comunes

No se envía ningún CPA del gateway a UCCX

Después de que la llamada esté conectada con el llamador PSTN, no se devuelve ningunos mensajes a UCCX por el gateway para indicar que se ha completado el CPA y que ha resultado una llamada (viven la Voz, ocupados, Contestador automático, y así sucesivamente). Aseegurese la versión de IOS en los soportes de gateway CPA. Investigue el gateway para verificar el CPA está actuando correctamente.

La llamada no se reorienta a UCCX después de que esté vivo expresa detectado

Verifique el gateway tiene un dial-peer que hace juego el Número marcado del activador UCCX (DN) asignado a la campaña. Verifique que una llamada del gateway pueda rutear a ese punto de ruta/activador CTI en CUCM.

El Retries no se marca

Similar a los servicios repetidos en el marcador saliente del avance, si las llamadas que reciben el RNA u ocupado no se revisan, verifique que estos expedientes estén marcados correctamente como recomprobación en la tabla de DialingList. Verifique de los registros MIVR que el intento de llamada se esté haciendo en el tiempo especificado del servicio repetido o de la recomprobación.

El DTMF no trabaja cuando está conectado con el script IVR

Verifique que el DTMF esté negociado correctamente entre CUCM y el gateway y que corresponden con al dial-peers Nombrado (el dial-peer 0 no contiene la configuración del relé dtmf). UCCX soporta solamente el DTMF fuera de banda vía el JTAPI, así que algunos tipos de gateway y flujos de llamada pudieron requerir un Media Termination Point (MTP) ser invocado para completar el DTMF que intertrabajaba. Investigue el gateway para verificar el gateway y CUCM están procesando correctamente las peticiones y la negociación DTMF.

Información Relacionada

• Soporte Técnico y Documentación - Cisco Systems

Historial de revisiones