Comment vérifier les

enregistrements CDR et CDR

actuels?
Posté sur 25 août 2014par Admin

Ce document s'applique au modèle d'appliance de Cisco Unified Communications

Manager (CUCM version 5.x et ultérieure).
Lecture recommandée
Il est fortement recommandé de lire le document « Comprendre le CDR (Call Detail Records)» à
l'emplacement suivant pour obtenir un bon historique des opérations CDR:
https://supportforums.cisco.com/docs/DOC-13842
Comment vérifier les enregistrements CDR actuels et la configuration CDR
À partir de la version CUCM 7.1.3, les utilisateurs reçoivent un message contextuel lorsqu'ils se connectent
à CAR (à partir de Cisco Unified Serviceability, accédez à Outils> Analyse et reporting CDR ). Le
message contextuel fournit une vue d'ensemble de la configuration CDR ainsi qu'une vue d'ensemble de
haut niveau du nombre d'enregistrements dans la base de données CDR.

Exemple de capture d'écran:

Les informations ci-dessus sont très utiles car vous pouvez voir la période couverte par les enregistrements
CDR. Dans l'exemple ci-dessus, les plus anciens CDR datent du 4 janvier et les derniers CDR datent du 5
janvier. Si vous essayez d'exécuter des rapports pour des jours qui ne sont pas inclus dans cette période (par
exemple: 3 janvier ou avant - ou - 5 janvier et plus tard), cela échouera car les données correspondantes ne
sont pas disponibles dans la base de données.

Avant CUCM 7.1.3, le message contextuel ci-dessus n'est pas disponible. Dans ce cas, un autre moyen de
vérifier les enregistrements en cours est:

Dans la page Analyse et génération de rapports CDR de Cisco Unified Communications Manager, accédez
à Système> Base de données> Purge manuelle, comme illustré dans la capture d'écran ci-dessous:

Sur la page suivante, cliquez sur Informations sur la table:

Une nouvelle fenêtre pop-up affiche:

Utilisation du journal des événements

Le journal des événements est un outil pratique pour vérifier l'état de la charge CDR.

Dans la page Analyse et génération de rapports CDR de Cisco Unified Communications Manager, accédez
à Système> Écrans de journal> Journal des événements,comme illustré dans la capture d'écran ci-
dessous:
Ensuite, sélectionnez le travail 'CDR Load' et spécifiez l'intervalle de recherche requis comme indiqué ci-
dessous:

La sortie du journal des événements est alors affichée:

Important:
Si une sauvegarde DRS démarre alors que le chargement du CDR est en cours, l'état de chargement du
CDR indique "Échec" dans la sortie du journal des événements. Dans ce cas, le statut "Échec" est
cosmétique. Reportez-vous à CSCsy90529 dans Bug Toolkit de Cisco pour plus de détails.
Dépanner: Impossible de rechercher les données CDR / Impossible
d'afficher les enregistrements CDR
Problème:

Je ne peux pas rechercher des enregistrements CDR ou générer des rapports pour une date particulière.

Approche:

(1) Vérifiez si le fanion CDR activé est activé dans les paramètres du service CallManager.

(2) CDR Load est-il activé? (À partir de l'outil CAR: Système -> Calendrier -> Chargement du
CDR). Cliquez ici pour les captures d'écran .
(3) En utilisant les journaux d'événements, vérifiez si le chargeur fonctionne correctement. Cliquez ici pour
les captures d'écran.

(4) Vérifiez les enregistrements actuels dans CDR comme expliqué ici. La date que vous recherchez se
situe-t-elle dans la plage entre les enregistrements les plus anciens et les plus récents? Très probablement,
la date particulière ne sera pas incluse dans cette plage.

(5) Cochez les dossiers «preserve» et «processed» sur l'éditeur pour les fichiers plats CDR. Cliquez ici pour
plus d'informations.

Si vous n'observez pas les fichiers dans l'emplacement 'preserve' ou 'processed' pour la date spécifique, cela
signifie que le problème ne réside pas dans l'éditeur. Soit les enregistrements CDR n'étaient pas générés par
le serveur qui traitait l'appel, soit cela pouvait signifier que le service Agent CDR sur ce serveur ne pouvait
pas transférer des fichiers plats à l'éditeur. Le «drapeau activé par CDR est-il activé dans le service
CallManager» a-t-il été activé à cette date particulière? Le service Agent CDR s'exécute-t-il sur le noeud
qui a traité l'appel?
 Pour la date particulière, si les fichiers CDR existent à l'emplacement 'preserve', mais pas à l'emplacement
'processed', cela signifie que les fichiers n'ont pas encore été traités.

(5) À quelle date les données de traitement de CDR Loader sont-elles utilisées? Vérifiez les
enregistrements actuels dans CDR comme expliqué ici. Attendez quelques minutes et vérifiez à nouveau les
enregistrements en cours dans CDR.

Les enregistrements totaux ont-ils changé entre les itérations?

-> Si oui, cela signifie que CDR Loader exécute et traite des données. La date du dernier enregistrement
fournira une indication du jour pour lequel les enregistrements sont en cours de traitement. Si la date que
vous recherchez tombe au-delà de la date la plus récente, vous devrez peut-être attendre un certain temps
pour que CDR Loader puisse traiter toutes les données menant à cette date.

-> Sinon, cela signifie que CDR Loader n'est peut-être pas en cours d'exécution (essayez de redémarrer le
service CAR Scheduler sur l'éditeur). Si aucun enregistrement supplémentaire n'est traité, définissez le
niveau de trace du service CAR Scheduler sur 'Debug', redémarrez le service CAR Scheduler, attendez 10
minutes, téléchargez les journaux CAR Scheduler via RTMT et engagez Cisco-TAC pour un dépannage
supplémentaire .

Dépanner: les fichiers CDR ne sont

pas transférés vers le serveur de
facturation
Problème:
Les fichiers plats CDR ne sont pas transférés vers le serveur de facturation.

Approche:
(1) Vérifiez que le serveur de facturation est correctement configuré (vérifiez l'adresse IP). À partir de la page
Cisco Unified Serviceability, accédez à Outils> Gestion CDR pour afficher les paramètres du serveur de
facturation.
(2) Vérifiez si vous pouvez exécuter une commande ping sur le serveur de facturation à partir de l'éditeur. À
partir de la CLI de l'éditeur, vous pouvez utiliser la commande suivante:
utils ping réseau abcd
où abcd est l'adresse IP du serveur de facturation
(3) Vérifiez si le service / logiciel FTP (ou SFTP) fonctionne sur le serveur de facturation.
(4) Vérifiez si le serveur de facturation manque d'espace disque.
(5) Vérifiez si le service CDR Respository Manager est en cours d'exécution sur le serveur de publication. Si ce
n'est pas le cas, démarrez le service CDR Repository Manager.
(6) Sur l'éditeur, vérifiez les répertoires 'preserve' et 'destinationX' (X peut être 1, 2 ou 3) pour les fichiers plats
CDR. Par exemple: si le transfert des fichiers CDR vers le serveur de facturation est interrompu à partir du 6
janvier, utilisez les commandes suivantes:
liste de fichiers activelog / cm / cdr_repository / preserve / 20110106
liste de fichiers activelog / cm / cdr_repository / destination1 /
20110106
(Si plusieurs serveurs de facturation sont configurés, l'emplacement sera similaire à ci-dessus, mais les
répertoires correspondants seront nommés destination2, destination3). Cet emplacement contient des liens
symboliques vers des fichiers sous preserve. Le service CDR Repository Manager utilise ces liens logiques
pour déterminer quels fichiers doivent être transférés au serveur de facturation.
 Si vous n'observez pas les fichiers dans les emplacements 'preserve' ou 'destinationX' pour la date
spécifique, cela signifie que le problème ne réside pas sur le serveur de publication. Soit les
enregistrements CDR n'étaient pas générés par le serveur qui traitait l'appel, soit cela pouvait signifier
 que le service Agent CDR sur ce serveur ne pouvait pas transférer des fichiers plats à l'éditeur. Le
«drapeau activé par CDR est-il activé dans le service CallManager» a-t-il été activé à cette date
particulière? Le service Agent CDR s'exécute-t-il sur le noeud qui a traité l'appel?
 Si vous observez des fichiers dans le répertoire 'preserve' pour la date spécifique, essayez de
redémarrer le service CDR Repository Manager sur le serveur de publication. Si le transfert de fichiers
vers le serveur de facturation ne commence pas, définissez le niveau de trace du service CDR
Repository Manager sur Déboguer, attendez 10 minutes, téléchargez les journaux CDR Repository
Manager via RTMT et engagez Cisco-TAC pour un dépannage supplémentaire.
Résoudre les problèmes: Alertes
CDRAgentSendFileFailed

Cette alerte est déclenchée lorsque l'agent CDR ne peut pas envoyer de fichiers CDR d'un nœud Cisco
Unified Communications Manager à un nœud de référentiel CDR dans le cluster Cisco Unified
Communications Manager. Cela se produit généralement lorsqu'un serveur abonné est incapable d'envoyer
les fichiers plats CDR à l'éditeur.

Approche:

- Y a-t-il eu des changements dans la connectivité réseau entre l'éditeur et l'abonné en raison du trafic SFTP
(port 22) qui peut être bloqué?

- Essayez de redémarrer le service Agent CDR sur le serveur Subsriber pour lequel l'alerte a été déclenchée.

- Si l'alerte persiste, modifiez le niveau de trace de débogage pour le service de l'agent CDR sur l'Abonné à
'Debug'. Attend 10 minutes. Téléchargez les journaux de service de l'agent CDR à l'aide de RTMT. Vérifiez
les erreurs dans le fichier. Vous devrez peut-être contacter le centre d'assistance technique Cisco pour
obtenir une assistance supplémentaire.

CDRFileDeliveryFailed

Cette alerte est déclenchée lorsque la livraison FTP / SFTP des fichiers CDR vers le serveur de facturation
externe échoue.

Approche:
Cette alarme indique qu'il existe des fichiers CDR à plat dans l'emplacement / cm / cdr_repository /
preserve / YYYYMMDD sur le serveur de publication. Cependant, le service CDR Repository Manager ne
peut pas transférer ces fichiers sur le serveur de facturation. Dépannez l'approche est la même
qu'ici. https://supportforums.cisco.com/docs/DOC-
14548#Troubleshoot_CDR_Files_not_being_transfered_to_billing_server
CDRHighWaterMarkExceeded

Cette alerte est déclenchée lorsque la limite supérieure des fichiers CDR est dépassée. Cela indique
également que certains fichiers CDR traités / délivrés avec succès ont été supprimés.

Cette alerte sera levée si la marque High Water Mark (HWM) configurée sur la page de gestion CDR est
dépassée. Pour accéder à la page Gestion des CDR, à partir de Cisco Unified Serviceability, accédez à
Outils> Gestion CDR.

Chaque fois que HWM est dépassé, CDR Repository Manager supprime les dossiers les plus anciens traités
un par un, jusqu'à ce que l'utilisation passe en dessous de la marque Low Water Mark (LWM). Aucune
action n'est requise pour cette alerte, sauf si l'alarme CDRMaximumDiskSpaceExceeded est également
observée.

CDRMaximumDiskSpaceExceeded

Cette alarme est déclenchée lorsque l'utilisation du disque des fichiers CDR dépasse l'allocation de disque
maximale. Cela indique également que certains fichiers non traités / non livrés ont été supprimés. Comme
expliqué dans la section 'CDRHighWaterMarkExceeded', chaque fois que HWM est dépassé, CDR
Repository Manager supprime les dossiers les plus anciens traités un par un, jusqu'à ce que l'utilisation
passe sous le Low Water Mark (LWM). Si tous les dossiers traités sont supprimés, mais que l'utilisation du
disque est supérieure à HWM et que le disque maximal est alloué sur la page Gestion du CDR, l'alarme
CDRMaximumDiskSpaceExceeded est lancée et CDR Repository Manager supprime les fichiers des
dossiers de sauvegarde les plus anciens jusqu'à ce que l'utilisation du disque HWM. Cette situation n'est pas
idéale car le système peut supprimer les fichiers CDR avant qu'ils ne soient transférés sur le serveur sftp ou
traités par le travail CDR Loader local.

Remarque - dans les scénarios de travail typiques, tous les fichiers plats CDR seront dans l'emplacement
«traité» par opposition à l'emplacement «préserver». Cela signifie que toutes les opérations pour ces
fichiers ont été effectuées.

Donc, l'aspect principal à dépanner est - pourquoi les dossiers de conservation contiennent des données
pour commencer? Est-ce parce que les fichiers CDR ne sont pas envoyés aux serveurs de facturation
configurés et / ou parce que les fichiers ne sont pas traités par le travail de chargement de CDR local sur le
serveur de publication?

Dépannez: nombreuses entrées dans tbl_billing_error

Problème:

Il y a de nombreuses entrées dans tbl_billing_error. Qu'est-ce qui le cause?

Approche:
Les commandes suivantes fonctionneront sur CUCM version 5.x, 6.x et 7.x. Pour CUCM 8.x et plus tard,
s'il vous plaît cliquez ici pour obtenir les commandes correspondantes.

Connectez-vous à l'interface de ligne de commande (CLI) de l'éditeur.

Vérifiez les codes d'erreur dans tbl_error_id_map. Triez la liste de sorte que les codes d'erreur qui
apparaissent le plus souvent soient répertoriés dans l'ordre décroissant.

admin: run sql select count (*) en tant que cnt, code_erreur de la voiture:
tbl_error_id_map groupe par error_code ordonné par cnt desc
cnt code_erreur
=== ==========
24 31110
14 31148

Vérifiez quels périphériques provoquent les erreurs:

admin: run sql select count (*) en tant que cnt, origdevicename de
voiture: tbl_billing_error où datetimeconnect = '0' groupe par
origdevicename ordre par cnt desc
cnt origdevicename
=== ===============
12 SEP000BFDCDB25A
9 SEP001BD52D292D
3 SEP001D45B64090

Dans l'exemple ci-dessus, les codes d'erreur sont:

31110: ce qui signifie que dateTimeConnect dans un enregistrement CDR n'est pas un nombre entier positif

et

31148: ce qui signifie que destDeviceName dans un enregistrement CDR est NULL

Les codes d'erreur ci-dessus impliquent que l'appel n'était pas connecté (c'est-à-dire qu'il n'était pas entré
dans un état connecté) mais un enregistrement CDR a néanmoins été créé pour celui-ci. Puisque l'appel
n'était pas connecté, ce n'est pas un appel "facturable". Par conséquent, l'enregistrement correspondant est
entré dans tbl_billing_error (par opposition à tbl_billing_data). Ce comportement est fréquemment observé
sur les systèmes où le paramètre de service CallManager: 'Appels journal CDR avec indicateur de durée
zéro' est activé. Si ce paramètre de service est entré, un enregistrement CDR sera généré pour les appels qui
n'ont jamais été connectés ou qui ont été connectés pendant moins d'une seconde. Scénarios les plus
courants qui provoquent de tels enregistrements CDR:

- Lorsqu'un utilisateur décroche puis raccroche sans passer d'appel.

- Lorsqu'un utilisateur effectue un transfert aveugle (l'appel de consultation ne se connecte pas avant la fin
du transfert).
- Appels On / Off MWI.
Si vous observez un grand nombre d'entrées dans tbl_billing_error en raison de l'un des scénarios ci-dessus,
vous pouvez désactiver le paramètre de service CallManager: 'Appels journaux CDR avec indicateur de
durée zéro'.
Une liste complète des codes d'erreur et des significations correspondantes est répertoriée ci-dessous:

Signification du code d'erreur:

31101: globalCallID_callManagerId du CDR <= 0

31102: globalCallID_callId du CDR <= 0

31103: OrigLegCallIdentifier du CDR <= 0

31105: dateTimeOrigination de CDR <= 0

31108: DestLegIdentifier du CDR <= 0

31110: dateTimeConnect CDR <= 0

31111: dateTimeDisconnect de CDR <= 0

31119: OriginalCalledPartyNumber du CDR est vide

31120: finalCalledPartyNumber du CDR est vide

31122: durée du CDR <0

31137: erreur Ldap du CDR lors de la récupération d'ID utilisateur ou ID de gestionnaire

31139: callingPartyNumber du CDR est vide

31147: origDeviceName du CDR est vide

31148: DestDeviceName du CDR est vide

31151: OrigCallTerminationOnBehalfOf du CDR <0

31152: destCallTerminationOnBehalfOf de CDR <0

31153: lastRedirectRedirectOnBehalfOf de CDR <0

31155: DestConversationId du CDR <0

31156: globalCallId_ClusterID de CDR est vide

** Commandes CLI correspondantes pour CUCM 8.0

Dans CUCM 8.0 et versions ultérieures, les tables tbl_billing_error et tbl_error_id_map ont
été consolidées. La syntaxe des commandes CLI a également légèrement changé par rapport à
la version précédente. Utilisez les commandes CLI suivantes de l'éditeur:
run sql car select count (*) comme cnt, error_codes de car:
tbl_billing_error groupe par error_codes ordonné par cnt desc

run sql car select count (*) en tant que cnt, origdevicename de
voiture: tbl_billing_error où datetimeconnect = '0' groupe par
origdevicename ordonné par cnt desc
Important:

CallManager génère toujours des données CDR pour les appels ayant une durée de 0 seconde et se
terminant en raison d'une condition d'erreur quelconque, quel que soit le paramètre du paramètre de service
Appels journaux CDR avec l'indicateur de durée zéro. Les appels vers des destinations occupées ou les
mauvais numéros de téléphone sont des exemples de ce type d'appel. La durée de ces appels est 0 car ils
n'ont jamais été connectés, mais leurs CDR sont générés de toute façon.

En bref - si un appel se termine anormalement, l'enregistrement CDR correspondant sera créé quel que soit
le réglage du paramètre de service Appels journal CDR avec zéro durée.
 Reporting: limitations importantes
Tous les rapports (rapports utilisateur, rapports système, rapports de périphériques) sont générés en
fonction des données de tbl_billing_data uniquement.

Pour les rapports CAR (Analyse CDR et rapports):

- Si le format CSV est sélectionné, la recherche de rapports est limitée à 20 000 enregistrements

- Si le format PDF est sélectionné, la recherche de rapports est limitée à 5 000 enregistrements

La limitation ci-dessus est documentée dans le Guide d'administration de Cisco Unified CDR Analysis and
Reporting. À moins que la version CUCM contienne le correctif pour CSCsm17901, le système n'affiche
aucune notification à l'utilisateur que les résultats du rapport peuvent ne pas être précis si les limites ci-
dessus sont enfreintes.

Considérez l'exemple suivant pour mieux comprendre ceci:

- Supposons que 1000 enregistrements sont renseignés dans tbl_billing_data chaque jour.

- Donc, pour le mois de janvier, il y aura 31000 enregistrements dans tbl_billing_data (1000
enregistrements par jour * 31 jours = 31000 enregistrements).

Disons qu'un rapport PDF est généré pour la période du 1er janvier au 10 janvier. Dans ce cas, la recherche
devrait idéalement s'étendre sur 10000 enregistrements (1000 enregistrements par jour * 10 jours = 10000
enregistrements). Cependant, un rapport PDF est limité à la recherche de seulement 5000
enregistrements. Dans ce cas, les résultats du rapport ne seront pas précis puisque le nombre total
d'enregistrements dans la période de recherche est supérieur à 5000! Cependant, si vous générez un rapport
CSV, les résultats du rapport seront précis puisque la recherche correspondante peut s'étendre jusqu'à
20000 enregistrements.

Conseils généraux
 Lorsque vous ajoutez des transformations appelantes et appelées à un modèle d'itinéraire ou un modèle
de traduction, CallManager enregistre les numéros transformés dans les CDR et affiche les numéros
transformés sur l'affichage du téléphone appelant. CallManager n'insère pas les transformations
spécifiées dans les détails du groupe de routage de la liste de routage (ou appliquées par une passerelle
de sortie individuelle) dans les CDR ou les restitue sur le périphérique appelant.
 L'utilisation de l'option Recherche CDR (sous Système -> CDR) va rechercher les enregistrements
dans tbl_billing_data et tbl_billing_error. Seuls les 100 premiers matchs seront affichés.
Liens utiles / Références
 Pour plus d'informations, reportez-vous au «Guide d'administration de l'analyse et de la création de
rapports Cisco Unified CDR» pour la version appropriée. Pour accéder au document:
- Accédez à: http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_guides_list.html

- Recherchez 'Cisco Unified CDR Analysis and Reporting Administration Guide' pour la version CUCM
appropriée

 Comprendre les CDR (un document sur les forums de support de Cisco)