CMR-verbetering in CUCM 12.5

Inleiding

Dit document beschrijft de verbeteringen in de Call Management Records (CMR) op Cisco Unified Communications Manager (CUCM) 12.5.

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

• CUCM versie 12.5
• Call Details Record inschakelen (CDR) en CMR op CallManager

Gebruikte componenten

De informatie in dit document is gebaseerd op Cisco Call Manager versie 12.5

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk levend is, zorg er dan voor dat u de mogelijke impact van om het even welke opdracht begrijpt.

Achtergrondinformatie 

 CUCM produceert twee soorten records, die geschiedenis van gesprekken en diagnostische informatie opslaan:

• Gegevens van de vraag - de gegevensbestanden bevatten informatie over elke vraag die door CallManager wordt verwerkt.
• Call Management Records - Gegevens bevatten de Quality of Service (QoS) of diagnostische informatie over de oproep, ook wel aangeduid als diagnostische records.

Zowel CDR's als CMR's worden samen CDR-gegevens genoemd. De gegevens van CDR verstrekken een verslag van alle oproepen die door gebruikers van het CallManager systeem zijn gemaakt of ontvangen. CDR-gegevens zijn vooral nuttig om de factureringsgegevens te genereren; het kan echter ook worden gebruikt voor het volgen van de bellers , het vaststellen van bepaalde soorten problemen en het plannen van de capaciteit .

CMR's bevatten informatie over de hoeveelheid gegevens die wordt verzonden en ontvangen, jitter, latentie en verloren pakketten. Aanvankelijk werd CMR voor interne gesprekken gegenereerd, nu kan CUCM CMR voor oproepen via SIP-stam genereren.

SIP Trunk ontvangt de callstatistieken in P-RTP-Stat header in het BYE-bericht of in de 200 OK-berichten (reactie op BYE-bericht) van CUBE of IOS-gateway. Deze statistieken omvatten pakketten die in real-time Transport Protocol (RTP) worden verzonden of ontvangen, totale bytes die worden verzonden of ontvangen, het totale aantal pakketten dat wordt verloren, vertragingsjitter, ronde-trip vertraging, en vraagduur worden verzonden.

Het formaat van P-RTP-Stat Kop:

P-RTP-STAAT: PS=<Packets Sent>, OS=<Octets verzonden>, PR=<Packets Recd>, OF=<Octets Recd>, PL=<Packets Lost>, JI=<Jitter>, LA=<round Trip Delay in ms>, DU=<Call Durving in seconden>

Het is het formaat van de rapportage van CUBE/SIP IOS gateway RTP-statistieken. Ondersteuning van CUCM SIP Trunk voor CMR is beperkt tot dat formaat van RTP-statistieken.

• Nadat BYE of 200OK voor BYE is ontvangen, verlaagt SIPCdPC de kop van de P-RTP-Stat en vult hij de corresponderende CMR-velden op basis van Key waardenparen in de kop van de P-RTP-Stat.

• SIPCdPC stuurt de diagnostische opname naar EnvProcescdr met bevolkte CMR-gegevens en EnvProcescdr maakt een plat bestand en dumpt CMR-gegevens erin.

• Er worden geen nieuwe velden aan de CMR toegevoegd als onderdeel van deze functie. Bestaande vorm moet worden gehandhaafd.

• Alle velden in de CMR die niet relevant zijn voor metriek aan de boomkant (zoals DirectoryNumber etc.) die op nul moeten worden gelaten, net zo voor metriek die niet van CUBE is ontvangen (bijv. varVQMetrics of videometriek) die op nul moeten worden gelaten. 

• Als de P-RTP-Stat header niet ontvangen is van het CUBE-bericht voor BYE of van 200 OK (reactie op BYE), wordt er geen CMR-record geschreven voor SIPTrunk.

  

Voorwaarden uit CUBE om deze functie te ondersteunen / Call statistics te verstrekken:

• Cisco IOS release 15.1(3)T of een latere release moet worden geïnstalleerd op uw Cisco Unified border-element.
• Cisco IOS XE release 3.3S of een latere release moet worden geïnstalleerd en op uw Cisco ASR 1000 Series router worden uitgevoerd.

Configuraties

Stap 1. CMR is ingeschakeld via Call Manager-serviceparameters onder:

1. Navigeren in om Systeem > Service Parameter.
   
   
2. Selecteer een server uit het vervolgkeuzevenster en selecteer vervolgens de Call Manager-service

Stap 2. Stel de Call Diagnostics Enabled parameter in op:

1. Alleen ingeschakeld als CDR-enabled Flag waar is (genereer CMR-s alleen als de CDR-enabled Flag-parameter op True is ingesteld).
   
   

2. Ingeschakeld ongeacht CDR-enabled vlag (genereert CMR-s zonder rekening te houden met de instelling in de CDR-enabled-parameter voor Vlag).

Overtrek-analyse 

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

De bovenstaande CMR-gegevens worden naar het bestand geduwd in de onderstaande opslagplaats/cm/cdr_opslagplaats/verwerkt/<huidige datum>/

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

cmr_StandAloneCluster_01_201902051047_0

dir count = 0, file count = 1

Verifiëren

Van cli kunt u controleren of CMR gegenereerd is of niet. Er is een map voor elke datum die is gemaakt in de bestandsindeling <yyymdd>

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

cmr_StandAloneCluster_01_201902051047_0

dir count = 0, file count = 1

Problemen oplossen

 P-RTP-Stat header wordt ontvangen in BYE/200OK, maar CMR-gegevens worden niet gegenereerd

<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

Werken:

Controleer of Call Diagnostics Enabled SP is ingeschakeld.

P-RTP-Stat Kop is aanwezig maar CMR is niet opgenomen

<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

Reden:

Aangezien numberPacketsSent en numberPacketsGet allebei ongeldig zijn, worden de gegevens van CMR niet in het bestand voor SIP Trunk gedumpt.

CMR-gegevens worden gegenereerd vanuit de kop van de P-RTP-positie, maar sommige waarden worden onjuist opgenomen

<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

Reden:

Aangezien PS- en PR-waarden buiten bereik zijn (waarden groter dan 2^32-1), worden deze buiten bereik gehouden waarden vervangen door max-waarde, d.w.z. 2^32-1(4294967295).

Toegestane toetsen en bereik van waarden in de P-RTP-Stat header 

Functiebeperkingen

Dit kenmerk wordt niet ondersteund voor de aanloopstromen van KMO's:

• Na het ontvangen van callstatistics van CUBE/IOS GW op MKB, zal CUCM CMR (vooropgesteld dat CMR is ingeschakeld) genereren voor boomstamzijde, maar het zal niet in staat zijn om callstatistieken naar andere knooppunten in uitgaande BYE of 200OK voor BYE door te sturen.
• Steekproef:
  Phone1 > CUBE/IOS GW> MKB > CUCM1 > Phone2
  Voor het bovengenoemde callscenario zal KMO de CMR genereren voor de hoofdzijde die wijst op CUBE. Deze statistieken worden niet naar bladknooppunten doorgestuurd. Voor Phone2 zal CMR op bladknooppunt worden geregistreerd.