CMR-Erweiterung in CUCM 12.5

Einführung

Dieses Dokument beschreibt die Verbesserungen bei Call Management Records (CMR) für Cisco Unified Communications Manager (CUCM) 12.5.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• CUCM-Version 12.5
• Aktivieren von Call Details Record (CDR) und CMR im CallManager

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf Cisco Call Manager Version 12.5.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Hintergrundinformationen 

 CUCM erstellt zwei Arten von Datensätzen, die Anrufsverlaufs- und Diagnoseinformationen speichern:

• Datensätze mit Anrufdetails - Datensätze mit Daten zu jedem Anruf, der von CallManager verarbeitet wird.
• Call Management Records (Anrufverwaltungsdatensätze): Datensätze enthalten Quality of Service (QoS) oder Diagnoseinformationen zu einem Anruf, auch als Diagnosedatensätze bezeichnet.

Sowohl CDRs als auch CMRs werden zusammen als CDR-Daten bezeichnet. CDR-Daten enthalten einen Datensatz aller Anrufe, die von Benutzern des CallManager-Systems getätigt oder empfangen wurden. CDR-Daten sind vor allem für die Erstellung der Abrechnungsdatensätze nützlich. Sie kann jedoch auch zur Nachverfolgung der Anrufaktivität, zur Diagnose bestimmter Probleme und zum Kapazitätsplan verwendet werden.

CMRs enthalten Informationen zur gesendeten und empfangenen Datenmenge, zu Jitter, Latenz und verlorenen Paketen. Zunächst wurde CMR für interne Anrufe generiert, jetzt kann CUCM CMR für Anrufe über einen SIP-Trunk generieren.

Der SIP-Trunk empfängt die Anrufstatistiken im P-RTP-Stat-Header der BYE-Nachricht oder der 200 OK-Nachrichten (Antwort auf BYE-Nachricht) vom CUBE- oder IOS-Gateway. Diese Statistiken umfassen gesendete oder empfangene Real-Time Transport Protocol (RTP)-Pakete, gesendete oder empfangene Bytes insgesamt, die Gesamtzahl verlorener Pakete, Verzögerungsjitter, Round-Trip-Verzögerung und Anrufdauer.

Das Format des P-RTP-Stat-Headers:

P-RTP-STAT: PS=<gesendete Pakete>, OS=<Gesendete Oktette>, PR=<Empfangene Pakete>, ODER=<Octets Recd>,PL=<Verlorene Pakete>, JI=<Jitter>, LA=<Round-Trip-Verzögerung in ms>, DU=<Anrufdauer in Sekunden>

Es ist das Format der CUBE/SIP IOS-Gateway-RTP-Statistik-Berichte. Die CUCM SIP-Trunk-Seite für die CMR-Unterstützung ist auf das Format der RTP-Statistik beschränkt.

• Nachdem BYE oder 200OK für BYE empfangen wurde, analysiert SIPCdpc den P-RTP-Stat-Header und füllt die entsprechenden CMR-Felder basierend auf Schlüsselwertepaaren im P-RTP-Stat-Header aus.

• SIPCdpc sendet den Diagnosedatensatz an EnvProcessCdr mit ausgefüllten CMR-Daten, und EnvProcessCdr erstellt eine flache Datei und gibt CMR-Daten in diese aus.

• Im Rahmen dieser Funktion werden dem CMR keine neuen Felder hinzugefügt. Vorhandenes Format beizubehalten.

• Alle Felder im CMR, die nicht für Trunk-seitige Metriken (z. B. DirectoryNumber usw.) relevant sind, müssen auf NULL belassen werden. Dies gilt auch für Metriken, die nicht von CUBE empfangen wurden (z. B. varVQMetrics oder Video-Metriken), um auf Null zu bleiben. 

• Wenn der P-RTP-Stat-Header nicht von der CUBE für BYE-Nachricht oder 200 OK (Antwort auf BYE) empfangen wird, wird kein CMR-Datensatz für SIPTrunk geschrieben.

  

Voraussetzung von CUBE für die Unterstützung dieser Funktion/Bereitstellung von Anrufstatistiken:

• Cisco IOS Release 15.1(3)T oder eine neuere Version muss auf Ihrem Cisco Unified Border Element installiert und ausgeführt werden.
• Cisco IOS XE Release 3.3S oder eine höhere Version muss auf Ihrem Cisco Router der Serie ASR 1000 installiert und ausgeführt werden.

Konfigurationen

Schritt 1: CMR wird über Call Manager-Dienstparameter unter aktiviert:

1. Navigieren zu System > Service Parameter.
   
   
2. Wählen Sie aus dem Dropdown-Feld einen Server aus, und wählen Sie dann den Call Manager-Service aus.

Schritt 2: Stellen Sie den Parameter Call Diagnostics Enabled (Anrufdiagnose aktiviert) wie folgt ein:

1. Nur aktiviert, wenn CDR Enabled Flag True ist (CMRs nur generieren, wenn der Service-Parameter für CDR Enabled Flag auf True festgelegt ist).
   
   

2. Aktiviert unabhängig vom CDR Enabled Flag (Generiert CMRs ohne Rücksicht auf die Einstellung im Service-Parameter CDR Enabled Flag).

Ablaufverfolgungsanalyse 

** 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","",,"",,,,,,,,,,"","","",,,,,,,,,,"",""

Die oben genannten CMR-Daten werden in die Datei im folgenden Repository aktivelog/cm/cdr_repository/processing/<current date>/ übertragen.

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

cmr_StandAloneCluster_01_201902051047_0

dir count = 0, file count = 1

Überprüfung

Über die CLI können Sie überprüfen, ob CMR generiert wird oder nicht. Für jedes Datum gibt es einen im Format <jjjjjmmtt> erstellten Ordner.

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

cmr_StandAloneCluster_01_201902051047_0

dir count = 0, file count = 1

Fehlerbehebung

 Der P-RTP-Stat-Header wird in BYE/200OK empfangen, aber CMR-Daten werden nicht generiert.

<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

Problemumgehung:

Überprüfen Sie, ob Call Diagnostics Enabled SP aktiviert ist.

Der P-RTP-Stat-Header ist vorhanden, aber der CMR ist nicht aufgezeichnet.

<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

Grund:

Da numberPacketsSent und numberPacketsReceived beide ungültig sind, werden CMR-Daten nicht für einen SIP-Trunk in die Datei geladen.

CMR-Daten werden aus dem P-RTP-Stat-Header generiert, aber einige Werte sind falsch aufgezeichnet

<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

Grund:

Da PS- und PR-Werte außerhalb des zulässigen Bereichs liegen (Werte größer als 2^32-1), werden diese Werte außerhalb des Bereichs durch einen Maximalwert ersetzt, d. h. 2^32-1(4294967295).

Zulässige Schlüssel und Wertebereiche im Header P-RTP-Stat 

Einschränkungen bei Funktionen

Diese Funktion wird für KMU-Anrufe nicht unterstützt:

• Beim Empfang von Anrufstatistiken von CUBE/IOS GW für KMU generiert CUCM CMR (sofern CMR aktiviert ist) für die Trunk-Seite, kann jedoch keine Anrufstatistiken an andere Knoten in ausgehendem BYE oder 200OK für BYE weiterleiten.
• Beispiel für einen Anruffluss:
  Telefon1 > CUBE/IOS GW> SME >> CUCM1 > Telefon2
  Für das obige Anrufszenario generiert SME den CMR für den Trunk-seitigen Verweis auf CUBE. Diese Statistiken werden nicht an einen Leaf-Knoten weitergeleitet. Bei Phone2 wird CMR auf Leaf-Knoten aufgezeichnet.