Error de la validación de la capacidad del gateway del servicio repetido de la cortesía del CVP del Troubleshooting (CCB)

Introducción

Este documento describe cómo resolver problemas un problema porta de la voz del cliente (CVP) CCB cuando el llamador no consigue una oferta CCB porque la capacidad del gateway del trunk se ha excedido.

Prerrequisitos

Requisitos

Cisco recomienda que tenga conocimiento sobre estos temas:

• CVP
• Servicio repetido de la cortesía del CVP de Cisco

Componentes Utilizados

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

• Servidor 10.5 del CVP
• Empresa unificada del Centro de contacto (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). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.

Antecedentes

Antes de que se resuelva problemas el problema de capacidad del gateway, es importante entender el proceso de validación del trunk en el CCB. Básicamente, el proceso primero determina el número de llamadas de la tabla de Callback_current con EventTypeID adentro (21,22,23);   Pendiente, Inprogress, provisionales para los gatewayes específicos y las ubicaciones.

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

Finalmente el proceso agrega estos dos valores y compara con el número de trunks configurados bajo servicio Survivability.tcl.

Si el resultado está sobre el umbral de los trunks configurado, el proceso envía detrás un error (la vuelta 1), si no devuelve la autorización (vuelta 0).

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

Links troncales CCB < (tabla de Callback_current con EventTypeID adentro (21,22,23); Pendiente, Inprogress, provisionales para los gatewayes específicos) + tabla de Callback_current de EventTypeID = 24 (completado), y CauseID = 27 (conectado)

Si el valor de los links troncales CCB es más bajo la validación falla.

Síntomas

Una llamada entrante no consigue la oferta CCB. La llamada va directamente a hacer cola cueste lo que cueste el tiempo de espera estimado (EWT)

Troubleshooting

Paso 1. Recoja los registros de actividad de la aplicación de CallbackEntry del servidor del Lenguaje de marcado extensible de la Voz (VXML).

Paso 2. Busque dentro de los registros de actividad para cualquier llamada donde no está ninguna la validación:

Validate_02,data,result,none

Cuál significa que la validación no pasó. Obtenga el GUID para esta llamada.  Filtre la llamada por el callid de la actividad y busque un callid como este ejemplo:

start,parameter,callid=BBBBAAAACCCCDDDDEEEEFFFFAAAABBBB

Paso 3. Recoja el CVP que señala los registros para el servidor de la información. Encuentre el mismo callid en el CVP que señala los registros.

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

Paso 4. Convierta el número del bitmask al binario. Utilice una calculadora del programador: 0001 00000011

Paso 5. Marque el bitmask del guía de informes del CVP para las tablas CCB. Usted debe ver que la validación falla debido a “EXCEED_CAPACITY_GW”.

Paso 6. Estreche el problema abajo a una cola específica. Marque el CCB Servelet del CVP que señala el servidor para determinar si hay algunas colas específicas donde el CCB no se ofrece. Abra un buscador Web y un tipo.

http:// {que señala IP del servidor Address}:8000/cvp/CallbackServlet?method=Diag

Éste es un ejemplo de una cola donde se ofrece el CCB:

Éste es un ejemplo de una cola donde el CCB no se ofrece

Paso 7.  Marque si las colas son servidas por un gateway específico. Marque la configuración de gateway (parámetros de aplicación de la supervivencia).

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 está correcta, marque la información salvada en la base de datos del servidor de la información (Informix) para determinar el número de llamadas en este gateway y ubicación específicos. Usted puede marcar por la identificación CCB (10.201.198.21 en este caso) o el locattion (CALO en este ejemplo).

Paso 9. En el servidor de la información, base de datos Informix del acceso.

Abra un prompt del CMD y teclee: dbacces

Navegue a la conexión > conectan

Seleccione el caso del cvp

teclee el cvp_dbadmin del nombre de usuario

teclee la contraseña

seleccione la base de datos de callback@cvp

salga y navegue a los Lenguajes de consulta

Paso 10. Funcione con la interrogación:

Seleccione la cuenta (*) de callback_current donde el == “CALO” de la ubicación;

Paso 11. Si el valor es lo mismo o más arriba que el valor del trunk configurado en el gateway para las ubicaciones, ésta es la razón por la que el validatidation falla, puesto que los números máximos de trunks permitidos se han alcanzado en la tabla de Callback_Current.

Note:  Según lo referido al guía de informes del CVP, la tabla del servicio repetido es una vista de dos tablas: Callback_Current y Callback_Historical. Las dos tablas son idénticas. Cada 30 minutos, los datos para las llamadas completadas se tiran de Callback_Pending y se mueven a Callback_Historical.

Paso 12. Si el valor del trunk por la ubicación ha alcanzado sus límites en la tabla de Callback_Current y no hay servicios repetidos en la cola que éste indica que hay un problema en la mudanza de los expedientes del servicio repetido desde Callback_Current a la tabla de Callback_Historical.

Paso 13. Asegúrese de que CVPCallbackArchive se esté ejecutando bajo tareas del horario (CVP que señala el servidor). Navegue al Start (Inicio) > Programs (Programas) > Accessories (Accesorios) - > las herramientas de sistema - > tarea programada.

.

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

Paso 15. Si el paso 13 y 14 está muy bien, pero aún ningunos datos en la tabla de Callback_Historical, usted necesitará determinar porqué la información no se agrega en la base de datos. Marque la integridad de la información salvada en la corriente y la tabla histórica.  Funcione con esta interrogación en la ventana CMD de los dbaccess del informix:

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

Paso 16.  Si la cuenta es 1 o más alta, significa que la Clave primaria en la tabla actual existe ya en la tabla histórica y la información no está agregada en la base de datos. En la mayoría de estos escenarios, una condición de carrera hace los expedientes duplicados ingresar en la tabla callback_current.

El GUID a la asignación del surrogateid sucede en la tabla de la cola. En las situaciones adonde la llamada se mueve desde la espera del servicio repetido al script de la cola del servicio repetido, parece haber una ventana donde el trabajo del archivo mueve los expedientes desde la corriente al historial y la aplicación ingresa un registro nuevo en la tabla actual con el mismo surrogateid.  Este problema se relaciona con este CDETS CSCuq86400

Solución

Paso 1. Base de datos Informix del acceso. Abra un prompt del CMD y teclee: dbacces

Paso 2. Navegue a la conexión > conectan el caso selecto del cvp. Teclee el cvp_dbadmin del nombre de usuario y teclee la contraseña

Paso 3. Seleccione la salida de la base de datos de callback@cvp y navegue a los Lenguajes de consulta

Paso 4. Funcione con estos comandos:

borre de callback_current donde surrogateid adentro (surrogateid selecto de callback_historical);

Si hay un error de la tabla temporal haga:

caiga el T1 de la tabla;

Paso 5. Funcione con el procedimiento SP que mueve la información desde actual a la tabla histórica del servicio repetido de los dbaccess de la ventana del Lenguaje de consulta.

EJECUTE el sp_arch_callback() del PROCEDIMIENTO;

Paso 6. Marque que no hay tantos expedientes en la tabla actual como antes.

Seleccione la cuenta (*) de callback_current donde el == “CALO” de la ubicación;

Solución permanente

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

Paso 2. Uncomment esta línea al principio del archivo: --sp_arch_callback del procedimiento del descenso;   (quite -- al principio de la línea).

Paso 3. Agregue esta línea: borre de callback_current donde sustituido adentro (surrogateid selecto de callback_historical); después

cree la línea del sp_arch_callback() del procedimiento.

Paso 4. Salve el archivo.

Paso 5. Esto es un ejemplo en cómo la primera parte del archivo debe parecer.

{*********************************************************************************
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);

 

 

Solución del final de una prueba

Paso 1. Abra un prompt del CMD y funcione con el comando: dbschema 

dbschema - servicio repetido d - sp_arch_callback f

Note: Si usted tiene un problema de la autorización al funcionar con el comando del dbschema, el login como cvp_dbadmin en el servidor de la información y el intento una vez más.

Paso 2. De la salida, asegúrese de que la cancelación del comando esté ejecutada.