Solución de problemas de error de validación de capacidad de gateway de devolución de llamada de cortesía (CCB) de CVP

Introducción

Este documento describe cómo resolver un problema de CCB del portal de voz del cliente (CVP) cuando la persona que llama no recibe una oferta de CCB porque se ha excedido la capacidad del gateway troncal.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• CVP
• Llamada de cortesía de Cisco CVP

Componentes Utilizados

La información que contiene este documento se basa en estas versiones de software:

• Servidor CVP 10.5
• Unified Contact Center Enterprise (UCCE) 10.5

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.

Antecedentes

Antes de que se solucione el problema de capacidad de la gateway, es importante entender el proceso de validación del tronco en CCB. Básicamente, el proceso primero determina el número de llamadas de la tabla Callback_current con EventTypeID en (21,22,23);   Pendiente, En curso y Provisional para gateways y ubicaciones específicas.

En segundo lugar, en la misma tabla Callback_current, determine el número de llamadas completadas con causa conectada:   EventTypeID = 24 (completado) y CauseID = 27 (conectado).

Finalmente, el proceso agrega estos dos valores y los compara con el número de troncos configurados en el servicio Survivability.tcl.

Si el resultado supera el umbral de enlaces configurado, el proceso devuelve un error (retorno 1); de lo contrario, devuelve ok (retorno 0).

En resumen, la fórmula para validar los trunks utilizados para CCB es:

Troncales CCB < (tabla Callback_current con EventTypeID en (21,22,23); Pendiente, En curso, Provisional para gateways específicos) + tabla Callback_current de EventTypeID = 24 (Completed) e CauseID = 27 (Connected)

Si el valor de troncales CCB es menor, la validación falla.

Síntomas

Una llamada entrante no recibe la oferta de CCB. La llamada pasa directamente a la cola independientemente del tiempo de espera estimado (EWT)

Troubleshoot

Paso 1. Recopilar registros de actividad de la aplicación CallbackEntry del servidor de lenguaje de marcado extensible de voz (VXML).

Paso 2. Busque en los registros de actividad cualquier llamada en la que la validación no sea ninguna:

Validate_02,data,result,none

Lo que significa que la validación no pasó. Obtenga el GUID para esta llamada.  Filtre la llamada por la actividad llamada y busque una llamada como este ejemplo:

start,parameter,callid=BBBBAAAACCCCDDDDEEEEFFFFAAAABBBB

Paso 3. Recopilar registros de informes de CVP para el servidor de informes. Busque el mismo callid en los registros de informes de CVP.

ValidateHandler:ValidateHandler.exec: ValidateHandler GUID=BBBBAAAACCCCDDDDEEEEFFFFAAAABBBB results:none validation status bitmask=0x00000103  

Paso 4. Convierta el número de máscara de bits en binario. Utilice una calculadora de programadores: 0001 00000011

Paso 5. Compruebe la máscara de bits de la guía de informes CVP para las tablas CCB. Debería ver que la validación falla debido a "EXCEED_CAPACITY_GW".

Paso 6. Limite el problema a una cola específica. Compruebe CCB Servelet desde el servidor de informes de CVP para determinar si hay alguna cola o colas específicas en las que no se ofrece CCB. Abra un explorador web y escriba.

http://{Dirección IP del servidor de informes}:8000/cvp/CallbackServlet?method=Diag

Este es un ejemplo de una cola donde se ofrece CCB:

Este es un ejemplo de una cola donde no se ofrece CCB

Paso 7.  Compruebe si las colas las atiende un gateway específico. Compruebe la configuración del gateway (parámetros de la aplicación Survivability).

application
 service new-call flash:bootstrap.vxml
 !
 service survivability flash:survivability.tcl
  paramspace callfeature med-inact-det enable
  param ccb id:10.201.198.21;loc:CALO;trunks:512

Paso 8. Si la configuración es correcta, compruebe la información almacenada en la base de datos del servidor de informes (Informix) para determinar el número de llamadas en esta gateway y ubicación específicas. Puede comprobar por el ID de CCB (10.201.198.21 en este caso) o la ubicación (CALO en este ejemplo).

Paso 9. En el servidor de informes, acceda a la base de datos de Informix.

Abra un mensaje CMD y escriba: dbacces

Vaya a connection > connect .

Seleccionar instancia cvp

type username cvp_dbadmin

escribir contraseña

seleccione base de datos callback@cvp

salir y desplazarse a Idiomas de consulta

Paso 10. Ejecute la consulta:

Seleccione count(*) de callback_current donde location == "CALO";

Paso 11. Si el valor es igual o superior al valor de enlace troncal configurado en el gateway para las ubicaciones, esta es la razón por la que falla la validación, ya que se ha alcanzado el número máximo de enlaces troncales permitidos en la tabla Callback_Current.

Nota:  Como se indica en la guía de informes de CVP, la tabla Devolución de llamada es una vista de dos tablas: Callback_Current y Callback_Historical. Las dos tablas son idénticas. Cada 30 minutos, los datos de las llamadas completadas se extraen de Callback_Pending y se mueven a Callback_Historical.

Paso 12. Si el valor del enlace troncal por ubicación ha alcanzado sus límites en la tabla Callback_Current y no hay devoluciones de llamada en la cola, esto indica que hay un problema al mover los registros de devolución de llamada de Callback_Current a la tabla Callback_Historical.

Paso 13. Asegúrese de que CVPCallbackArchive se está ejecutando en Tareas programadas (Servidor de informes de CVP). Vaya a Inicio -> Programas -> Accesorios -> Herramientas del sistema -> Tarea programada.

.

Paso 14. Si esta tarea CVPCallbackArchive se completa, asegúrese de que el código de salida es (0x0).

Paso 15. Si los pasos 13 y 14 están bien, pero sigue sin haber datos en la tabla Callback_Historical, tendrá que determinar por qué no se agrega la información a la base de datos. Compruebe la integridad de la información almacenada en la tabla actual e histórica.  Ejecute esta consulta en la ventana informix dbaccess CMD:

Select  count (*) from callback_current where surrogateid in (select surrogateid from callback_historical);

Paso 16.  Si el recuento es 1 o superior, significa que la clave principal de la tabla actual ya existe en la tabla histórica y que la información no se agrega a la base de datos. En la mayoría de estos escenarios, una condición de anticipación hace que los registros duplicados entren en la tabla callback_current.

La asignación de GUID a id sustituto se produce en la tabla de colas. En situaciones en las que la llamada pasa de la espera de devolución de llamada al script de cola de devolución de llamada, parece haber una ventana en la que el trabajo de archivo mueve los registros del actual al historial y la aplicación introduce un nuevo registro en la tabla actual con el mismo id. de sustitución.  Este problema está relacionado con este CDETS CSCuq86400

Solución

Paso 1. Acceder a la base de datos Informix. Abra un mensaje CMD y escriba: dbacces

Paso 2. Navegue hasta connection > connect y seleccione cvp instance. Escriba el nombre de usuario cvp_dbadmin y la contraseña

Paso 3. Seleccione callback@cvp database exit y navegue hasta Query Languages

Paso 4. Ejecute estos comandos:

delete from callback_current where surrogateid in (select surrogateid from callback_historical);

Si hay un error de tabla temporal, haga lo siguiente:

tabla de descarte t1;

Paso 5. Ejecute el procedimiento sp que mueve la información de la tabla de devolución de llamada actual a la histórica desde la ventana de idioma de consulta dbaccess.

EXECUTE PROCEDURE sp_arch_callback();

Paso 6. Compruebe que no hay tantos registros en la tabla actual como antes.

Seleccione count(*) de callback_current donde location == "CALO";

Solución permanente

Paso 1. Navegue hasta Cisco\CVP\informix_frag y abra sp_arch_callback.sql en un editor de texto.

Paso 2. Quite los comentarios de esta línea al principio del archivo: —drop procedure sp_arch_callback;   (quitar: al principio de la línea).

Paso 3. Agregue esta línea: delete from callback_current where surrogated in (seleccione surrogateid de callback_historical) ; después de

create procedure sp_arch_callback() line.

Paso 4. Guarde el archivo.

Paso 5. Este es un ejemplo de cómo debería verse la primera parte del archivo.

{*********************************************************************************
Stored procedure to move completed calls out of the active table into the
historical table.
*********************************************************************************}
drop procedure sp_arch_callback;
create procedure sp_arch_callback()

DEFINE p_ageoff INTEGER;

-- delete any duplicates found in current table.

 

delete from callback_current where surrogateid in (select surrogateid from callback_historical);

 

 

Probar solución final

Paso 1.  Abra una indicación de CMD y ejecute el comando: dbschema 

dbschema -d callback -f sp_arch_callback

Nota: Si tiene un problema de autorización al ejecutar el comando dbschema, inicie sesión como cvp_dbadmin en el servidor de informes e inténtelo una vez más.

Paso 2. Desde el resultado, asegúrese de que se ejecute el comando Delete from.