Dépannage de l'échec de validation de capacité de la passerelle de rappel de courtoisie CVP

Introduction

Ce document décrit comment dépanner un problème CCB Customer Voice Portal (CVP) lorsque l'appelant ne reçoit pas d'offre CCB parce que la capacité de la passerelle d'agrégation a été dépassée.

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• CVP
• Rappel de courtoisie Cisco CVP

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de logiciel suivantes :

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

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Informations générales

Avant de résoudre le problème de capacité de la passerelle, il est important de comprendre le processus de validation de la liaison dans CCB. En fait, le processus détermine d'abord le nombre d'appels de la table Callback_current avec EventTypeID dans (21,22,23);   En attente, En cours, Provisoire pour des passerelles et des emplacements spécifiques.

Ensuite, à partir de la même table Callback_current, déterminez le nombre d'appels terminés avec cause connected :   EventTypeID = 24 (terminé) et CauseID = 27 (connecté).

Enfin, le processus ajoute ces deux valeurs et les compare au nombre de faisceaux configurés sous le service Survivability.tcl.

Si le résultat est supérieur au seuil de faisceaux configuré, le processus renvoie un échec (retour 1), sinon renvoie ok (retour 0).

En résumé, la formule de validation des faisceaux utilisés pour CCB est la suivante :

Trunks CCB < (tableau Callback_current avec EventTypeID dans (21,22,23); En attente, En cours, Provisoire pour des passerelles spécifiques) + Table Callback_current de EventTypeID = 24 (Terminé) et CauseID = 27 (Connecté)

Si la valeur des agrégations CCB est inférieure, la validation échoue.

Symptômes

Un appel entrant ne reçoit pas d'offre CCB. L'appel passe directement en file d'attente, quel que soit le temps d'attente estimé (EWT)

Dépannage

Étape 1 : collecte des journaux d’activité à partir de l’application CallbackEntry à partir du serveur VXML (Voice Extensible Markup Language)

Étape 2. Recherchez dans les journaux d’activité les appels pour lesquels la validation n’est pas possible :

Validate_02,data,result,none

Ce qui signifie que la validation n'a pas réussi. Obtenez le GUID de cet appel.  Filtrez l'appel en fonction de l'appelant de l'activité et recherchez un appelant comme dans l'exemple suivant :

start,parameter,callid=BBBBAAAACCCCDDDDEEEEFFFFAAAABBBB

Étape 3 : collecte des journaux de création de rapports CVP pour le serveur de rapports Recherchez le même callid dans les journaux de rapports CVP.

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

Étape 4. Convertissez le numéro du masque de bits en binaire. Utiliser une calculatrice programmeuse : 0001 00000011

Étape 5. Vérifiez le masque de bits du guide CVP Reporting pour les tables CCB. Vous devriez voir que la validation échoue à cause de "EXCEED_CAPACITY_GW".

Étape 6. Réduisez le problème à une file d’attente spécifique. Vérifiez le serveur CCB Servelet à partir du serveur CVP Reporting afin de déterminer s’il y a une ou plusieurs files d’attente spécifiques où CCB n’est pas offert. Ouvrez un navigateur Web et tapez.

http://{Adresse IP du serveur de rapports}:8000/cvp/CallbackServlet?method=Diag

Voici un exemple de file d'attente où CCB est offert :

Voici un exemple de file d'attente où CCB n'est pas offert

Étape 7.  Vérifiez si la ou les files d'attente sont desservies par une passerelle spécifique. Vérifiez la configuration de la passerelle (paramètres de l'application 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

Étape 8. Si la configuration est correcte, vérifiez les informations stockées dans la base de données Reporting Server (Informix) pour déterminer le nombre d'appels sur cette passerelle et cet emplacement spécifiques. Vous pouvez vérifier par l'ID CCB (10.201.198.21 dans ce cas) ou l'emplacement (CALO dans cet exemple).

Étape 9. Sur le serveur de rapports, accédez à la base de données Informix.

Ouvrez une invite CMD et tapez : bacces

Accédez à connection > connect

Sélectionner une instance cvp

tapez username cvp_dbadmin

mot de passe

sélectionnez callback@cvp database

quitter et naviguer jusqu'à Langues de requête

Étape 10. Exécutez la requête :

Sélectionnez count(*) dans callback_current où location == "CALO";

Étape 11. Si la valeur est égale ou supérieure à la valeur de liaison configurée dans la passerelle pour le ou les emplacements, c’est la raison pour laquelle la validation échoue, car le nombre maximal de liaisons autorisé a été atteint dans la table Callback_Current.

Remarque :  Comme indiqué dans le guide CVP Reporting, la table Callback est une vue de deux tables : Callback_Current et Callback_Historical. Les deux tables sont identiques. Toutes les 30 minutes, les données des appels terminés sont extraites de Callback_Pending et déplacées vers Callback_Historical.

Étape 12. Si la valeur de liaison par emplacement a atteint ses limites dans la table Callback_Current et qu'il n'y a aucun rappel dans la file d'attente, cela indique qu'il y a un problème dans le déplacement des enregistrements de rappel de Callback_Current vers la table Callback_Historical.

Étape 13. Assurez-vous que CVPCallbackArchive est en cours d’exécution sous Planifier des tâches (CVP Reporting Server). Accédez à Démarrer -> Programmes -> Accessoires -> Outils système -> Tâche planifiée.

.

Étape 14. Si cette tâche CVPCallbackArchive se termine, vérifiez que le code de sortie est (0x0).

Étape 15. Si les étapes 13 et 14 sont correctes, mais qu'il n'y a toujours aucune donnée dans la table Callback_Historical, vous devez déterminer pourquoi les informations ne sont pas ajoutées à la base de données. Vérifiez l'intégrité des informations stockées dans la table actuelle et historique.  Exécutez cette requête dans la fenêtre CMD d'informix dbaccess :

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

Étape 16.  Si le nombre est égal ou supérieur à 1, cela signifie que la clé primaire de la table actuelle existe déjà dans la table historique et que les informations ne sont pas ajoutées à la base de données. Dans la plupart de ces scénarios, une condition de concurrence entraîne l'entrée d'enregistrements en double dans la table callback_current.

Le mappage GUID vers ID de substitution se produit sur la table de file d'attente. Dans les situations où l'appel passe d'une attente de rappel à un script de file d'attente de rappel, il semble y avoir une fenêtre dans laquelle le travail d'archivage déplace les enregistrements de l'historique actuel vers l'historique et l'application entre un nouvel enregistrement dans la table actuelle avec le même ID de substitution.  Ce problème est lié à ce CDETS CSCuq86400

Solution

Étape 1 : accès à la base de données Informix Ouvrez une invite CMD et tapez : bacces

Étape 2. Accédez à connection > connect et sélectionnez cvp instance. Tapez username cvp_dbadmin et password

Étape 3. Sélectionnez callback@cvp database exit et accédez à Query Languages

Étape 4. Exécutez ces commandes :

delete from callback_current where surrogateid in (sélectionnez surrogateid dans callback_history);

En cas d'erreur de table temporaire, procédez comme suit :

supprimer la table t1 ;

Étape 5. Exécutez la procédure sp qui déplace les informations de la table de rappel actuelle vers la table de rappel historique à partir de la fenêtre de langage de requête dbaccess.

EXECUTE PROCEDURE sp_arch_callback();

Étape 6. Vérifiez que la table active ne contient pas autant d'enregistrements qu'auparavant.

Sélectionnez count(*) dans callback_current où location == "CALO";

Solution permanente

Étape 1. Accédez à Cisco\CVP\informix_frag et ouvrez sp_arch_callback.sql dans un éditeur de texte.

Étape 2. Décommentez cette ligne au début du fichier : —drop, procédure sp_arch_callback ;   (supprimer — au début de la ligne).

Étape 3. Ajoutez cette ligne : delete from callback_current where substituated in (sélectionner l'ID de substitution dans callback_history) ; suivant

créez la procédure sp_arch_callback() line.

Étape 4 : enregistrement du fichier

Étape 5. Voici un exemple de la façon dont la première partie du fichier devrait ressembler.

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

 

 

Solution Finale D'Essai

Étape 1.  Ouvrez une invite CMD et exécutez la commande suivante : dbschema 

dbschema -d callback -f sp_arch_callback

Remarque : si vous rencontrez un problème d'autorisation lors de l'exécution de la commande dbschema, connectez-vous en tant que cvp_dbadmin au serveur de rapports et réessayez.

Étape 2. À partir du résultat, vérifiez que la commande Delete from est exécutée.