Amélioration CMR dans CUCM 12.5

Introduction

Ce document décrit les améliorations apportées aux Call Management Records (CMR) sur Cisco Unified Communications Manager (CUCM) 12.5.

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• CUCM version 12.5
• Activer CDR (Call Details Record) et CMR sur CallManager

Components Used

Les renseignements contenus dans ce document se fondent sur la version 12.5 de Cisco Call Manager.

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. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales 

 CUCM produit deux types d'enregistrements, qui stockent l'historique des appels et les informations de diagnostic :

• Enregistrements détaillés des appels : les enregistrements de données contiennent des informations sur chaque appel traité par CallManager.
• Enregistrements de gestion des appels : les enregistrements de données contiennent les informations de qualité de service (QoS) ou de diagnostic relatives à l'appel, également appelées enregistrements de diagnostic.

Les CDR et les CMR ensemble sont appelés données CDR. Les données CDR fournissent un enregistrement de tous les appels passés ou reçus par les utilisateurs du système CallManager. Les données CDR sont principalement utiles pour générer les enregistrements de facturation ; cependant, il peut également être utilisé pour suivre l'activité des appels, diagnostiquer certains types de problèmes et planifier la capacité.

Les CMR contiennent des informations sur la quantité de données envoyées et reçues, la gigue, la latence et les paquets perdus. Initialement, le CMR a été généré pour les appels internes, CUCM peut désormais générer le CMR pour les appels sur la ligne principale SIP.

SIP Trunk reçoit les statistiques d'appel dans l'en-tête P-RTP-Stat dans le message BYE ou dans les messages 200 OK (réponse au message BYE) de CUBE ou de la passerelle IOS. Ces statistiques incluent les paquets RTP (Real-time Transport Protocol) envoyés ou reçus, le nombre total d'octets envoyés ou reçus, le nombre total de paquets perdus, la gigue de délai, le délai aller-retour et la durée des appels.

Format de l'en-tête P-RTP-Stat :

P-RTP-Stat : PS=<Paquets envoyés>, OS=<Octets envoyés>, PR=<Paquets reçus>, OR=<Octets reçus>, PL=<Paquets perdus>, JI=<Instabilité>, LA=<Délai de trajet arrondi en ms>, DU=<Durée de l'appel en secondes>

Il s'agit du format des rapports de statistiques RTP de passerelle CUBE/SIP IOS. Le côté liaison SIP CUCM pour la prise en charge CMR est limité à ce format de statistiques RTP.

• Après réception de BYE ou 200OK pour BYE, SIPCdpc analyse l'en-tête P-RTP-Stat et remplit les champs CMR correspondants en fonction des paires de valeurs clés dans l'en-tête P-RTP-Stat.

• SIPCdpc envoie l'enregistrement de diagnostic à EnvProcessCdr avec des données CMR renseignées, et EnvProcessCdr crée un fichier plat et y déverse les données CMR.

• Aucun nouveau champ n'est ajouté au CMR dans le cadre de cette fonctionnalité. Format existant à conserver.

• Tous les champs dans le CMR qui ne sont pas pertinents pour les mesures côté liaison (comme DirectoryNumber, etc.) doivent être laissés à la valeur null, de même pour les mesures non reçues de CUBE (par exemple varVQMetrics ou les mesures vidéo) doivent être laissés à la valeur null. 

• Si l'en-tête P-RTP-Stat n'est pas reçu du message CUBE for BYE ou 200 OK (réponse à BYE), aucun enregistrement CMR n'est écrit pour le SIPTrunk.

  

Prérequis de CUBE pour prendre en charge cette fonctionnalité / fournir des statistiques d'appel :

• La version 15.1(3)T ou une version ultérieure de Cisco IOS doit être installée et doit être exécutée sur votre Cisco Unified Border Element.
• La version 3.3S ou ultérieure de Cisco IOS XE doit être installée et doit être exécutée sur votre routeur de la gamme Cisco ASR 1000.

Configurations

Étape 1. CMR est activé via les paramètres du service Call Manager sous :

1. Accéder à System > Service Parameter.
   
   
2. Sélectionnez un serveur dans la liste déroulante, puis sélectionnez le service Call Manager.

Étape 2. Définissez le paramètre Call Diagnostics Enabled sur :

1. Activé uniquement lorsque l'indicateur CDR activé a la valeur True (générer des CMR uniquement lorsque le paramètre de service CDR activé est défini sur True).
   
   

2. Activé indépendamment de l'indicateur CDR activé (génère des CMR sans tenir compte du paramètre du service CDR activé).

Analyse de suivi 

** Incoming BYE from Gateway :



00802148.002 |16:17:01.297 |AppInfo  |//SIP/SIPUdp/wait_SdlDataInd: Incoming SIP UDP message size 539 from 10.106.97.143:[49193]:

[151,NET]

BYE sip:2000@10.106.97.132:5060 SIP/2.0

Via: SIP/2.0/UDP 10.106.97.143:5060;branch=z9hG4bKB41E87

From: <sip:7001@10.106.97.143>;tag=7780842C-12C9

To: <sip:2000@10.106.97.132>;tag=23~30c1033e-90ea-45e0-b1da-eec4a4bfbd�6e-21411553

Date: Tue, 05 Feb 2019 10:03:29 GMT

Call-ID: 1F09F649-286411E9-81B2A4AF-FAF6B880@10.106.97.143

User-Agent: Cisco-SIPGateway/IOS-15.5.3.M5

Max-Forwards: 70

Timestamp: 1549361022

CSeq: 103 BYE

Reason: Q.850;cause=16

P-RTP-Stat: PS=300,OS=48000,PR=365,OR=58400,PL=0,JI=0,LA=0,DU=7

Content-Length: 0





** Post SIPDisconnect Indication, SIPCdpc collects the data



00802151.000 |16:17:01.297 |SdlSig   |SIPDisconnInd                          |active                         |SIPCdpc(1,100,180,5)             |SIPD(1,100,181,1)                |1,100,255,1.62^10.106.97.143^*           |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0]  CcbId= 2�3 --TransType=2 --TransSecurity=0 PeerAddr = 10.106.97.143:49193 Sip_disc_cause= 200 cause=16 isReasonHdrVal= T

00802151.001 |16:17:01.297 |AppInfo  |(isHeldOrHolding): holder=0,holdee=0,mh=0

00802151�.002 |16:17:01.297 |AppInfo  |SIPCdpc(5) - collect_proxyMetricsData: Filling the Audio diagnostic record for the CMR coming from proxy ...

00802151.003 |16:17:01.297 |AppInfo  |SIPCdpc(5) - collect_proxyMetricsData: Audio diagnostics: pktSend = 300, pktSendOct = 48000, pktRec = 365, pktRecOct = 58400, pktLoss = 0, jitter = 0, delay = 0

 

** SIPCdpc sends the data to CDR process to generate CMR



00802193.000 |16:17:01.315 |SdlSig   |DbDiagnosticsReq                       |wait                           |EnvProcessCdr(1,100,6,1)         |SIPCdpc(1,100,180,5)             |1,100,255,1.62^10.106.97.143^*           |[T:N-H:0,N:0,L:0,V:0,Z:0,D:0]  globalCallId: 5 nodeId: 1 directoryNum:  dateTime: 1549363621 numberPa�cketsSent: 300 numberOctetsSent: 48000 numberPacketsReceived: 365 numberOctetsReceived: 58400 numberPacketsLost: 0 jitter: 0 latency: 0 varVQMetrics:





00802252.001 |16:17:01.621 |AppInfo  |EnvProcessCdr::wait_DbDiagnosticsReq

00802252.002 |16:17:01.621 |AppInfo  |EnvProcessCdr::wait_DbDiagnosticsReq DETAILED Entries 2, Inserts 2, ZeroCalls 0

00802252.003 |16:17:01.621 |AppInfo  |EnvProcessCdr::outputCmrData CMR data - 2,1,5,1,"2000",21411554,1549363621,2967,59340,0,0,0,0,0,"1e44e506-9a5d-4f0a-af2c-de23a7405123","","StandAloneCluster","SEPeeeeeeeeeeee","",,"",,,,,,,,,,"","","",,,,,,,,,,"",""

Les données CMR ci-dessus sont insérées dans le fichier dans le référentiel ci-dessous activelog/cm/cdr_storage/processing/<date du jour>/

admin:file list activelog cm/cdr_repository/processed/20190205/*

cmr_StandAloneCluster_01_201902051047_0

dir count = 0, file count = 1

Vérification

À partir de cli, vous pouvez vérifier si CMR est généré ou non. Pour chaque date, un dossier est créé au format <yyyyymmdd>

admin:file list activelog cm/cdr_repository/processed/20190205/*

cmr_StandAloneCluster_01_201902051047_0

dir count = 0, file count = 1

Dépannage

 L'en-tête P-RTP-Stat est reçu dans BYE/200OK, mais les données CMR ne sont pas générées

<Sample BYE message >

00802148.002 |16:17:01.297 |AppInfo  |//SIP/SIPUdp/wait_SdlDataInd: Incoming SIP UDP message size 539 from 10.106.97.143:[49193]:

[151,NET]

BYE sip:2000@10.106�.97.132:5060 SIP/2.0

Via: SIP/2.0/UDP 10.106.97.143:5060;branch=z9hG4bKB41E87

From: <sip:7001@10.106.97.143>;tag=7780842C-12C9

To: <sip:2000@10.106.97.132>;tag=23~30c1033e-90ea-45e0-b1da-eec4a4bfbd�6e-21411553

Date: Tue, 05 Feb 2019 10:03:29 GMT

Call-ID: 1F09F649-286411E9-81B2A4AF-FAF6B880@10.106.97.143

User-Agent: Cisco-SIPGateway/IOS-15.5.3.M5

Max-Forwards: 70

Timestamp: 1549361022

CSeq:� 103 BYE

Reason: Q.850;cause=16

P-RTP-Stat: PS=300,OS=48000,PR=365,OR=58400,PL=0,JI=0,LA=0,DU=7

Content-Length: 0

Solution de contournement:

Vérifiez si Call Diagnostics Enabled SP est activé.

L'en-tête P-RTP-Stat est présent mais CMR n'est pas enregistré

<Sample BYE message >

BYE sip:45002@10.77.29.45:5062 SIP/2.0

Via: SIP/2.0/UDP 10.77.22.123:5062;branch=z9hG4bK-11920-1-7

From: sipp <sip:sipp@10.77.22.123:5062>;tag=1

To: sut <sip:45002@10.77.29.45:5062>;tag=2085~b5883d68-042a-4a73-adc3-6be8a5f9f263-24253136

Call-ID: 1-15504@10.77.22.123

CSeq: 1 BYE

Allow-Events: presence, kpml

Contact: sip:sipp@10.77.22.123:5062

Content-Length: 0

P-RTP-Stat: PS=nodata, OS=nodata, PR=nodata, OR=nodata, PL=1, JI=3, LA=0.03, DU=76

Motif :

Puisque numberPacketsSent et numberPacketsReceived ne sont pas valides, les données CMR ne sont pas vidées dans le fichier de la ligne principale SIP.

Les données CMR sont générées à partir de l'en-tête P-RTP-Stat mais certaines valeurs sont mal enregistrées

<Sample BYE message >

BYE sip:45002@10.77.29.45:5062 SIP/2.0

Via: SIP/2.0/UDP 10.77.22.123:5062;branch=z9hG4bK-11920-1-7

From: sipp <sip:sipp@10.77.22.123:5062>;tag=1

To: sut <sip:45002@10.77.29.45:5062>;tag=2085~b5883d68-042a-4a73-adc3-6be8a5f9f263-24253136

Call-ID: 1-15504@10.77.22.123

CSeq: 1 BYE

Allow-Events: presence, kpml

Contact: sip:sipp@10.77.22.123:5062

Content-Length: 0

P-RTP-Stat: PS=4294967298, OS=1234, PR=4294967298, OR=1233, PL=1, JI=3, LA=0.03, DU=76

Motif :

Puisque les valeurs PS et PR sont hors limites (valeurs supérieures à 2^32-1), ces valeurs hors limites sont remplacées par une valeur maximale, c'est-à-dire 2^32-1(4294967295).

Clés autorisées et plage de valeurs dans l'en-tête P-RTP-Stat 

Limitations des fonctionnalités

Cette fonctionnalité n'est pas prise en charge pour les flux d'appels PME :

• Dès réception des statistiques d'appels de CUBE/IOS GW sur SME, CUCM génère le CMR (sous réserve que CMR soit activé) pour le côté liaison, mais il ne pourra pas transférer les statistiques d'appels vers d'autres noeuds dans BYE sortant ou 200OK pour BYE.
• Exemple de flux d'appels :
  Téléphone1 » CUBE/IOS GW » PME » CUCM1 » Téléphone2
  Pour le scénario d'appel ci-dessus, SME générera le CMR pour le côté de liaison pointant vers CUBE . Ces statistiques ne seront pas transmises au noeud leaf. Pour Phone2, CMR sera enregistré sur le noeud leaf.