Miglioramento CMR in CUCM 12.5

Introduzione

Questo documento descrive i miglioramenti apportati a Call Management Records (CMR) su Cisco Unified Communications Manager (CUCM) 12.5.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• CUCM versione 12.5
• Abilita registrazione dettagli chiamata (CDR) e CMR su CallManager

Componenti usati

Le informazioni di questo documento si basano sulla versione 12.5 di Cisco Call Manager

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Premesse 

 CUCM genera due tipi di record, che memorizzano la cronologia delle chiamate e le informazioni di diagnostica:

• Call Detail Records: i record di dati contengono informazioni su ogni chiamata elaborata da CallManager.
• Record di gestione delle chiamate: i record di dati contengono le informazioni QoS (Quality of Service) o di diagnostica relative alla chiamata, definite anche record di diagnostica.

Sia i CDR che i CMR vengono definiti dati CDR. I dati CDR forniscono un record di tutte le chiamate effettuate o ricevute dagli utenti del sistema CallManager. I dati CDR sono utili principalmente per generare i record di fatturazione; può essere utilizzato anche per tenere traccia dell'attività delle chiamate, diagnosticare determinati tipi di problemi e pianificare la capacità.

Le CMR contengono informazioni sulla quantità di dati inviati e ricevuti, sull'instabilità, sulla latenza e sulla perdita di pacchetti. Inizialmente, la CMR è stata generata per le chiamate interne, ora CUCM può generare la CMR per le chiamate su trunk SIP.

SIP Trunk riceve le statistiche delle chiamate nell'intestazione P-RTP-Stat nel messaggio BYE o nei messaggi 200 OK (risposta al messaggio BYE) dal gateway CUBE o IOS. Queste statistiche includono i pacchetti RTP (Real-time Transport Protocol) inviati o ricevuti, il totale dei byte inviati o ricevuti, il numero totale dei pacchetti persi, la variazione di ritardo, il ritardo di andata e ritorno e la durata delle chiamate.

Formato dell'intestazione P-RTP-Stat:

P-RTP-Stat: PS=<Pacchetti inviati>, OS=<Ottetti inviati>, PR=<Pacchetti registrati>, OR=<Ottetti registrati>, PL=<Pacchetti persi>, JI=<Instabilità>, LA=<Ritardo andata e ritorno in ms>, DU=<Durata chiamata in secondi>

È il formato del report delle statistiche RTP del gateway CUBE/SIP IOS. Il lato Trunk SIP CUCM per il supporto CMR è limitato al formato delle statistiche RTP.

• Dopo la ricezione di BYE o 200OK per BYE, SIPCdpc analizza l'intestazione P-RTP-Stat e popola i campi CMR corrispondenti in base alle coppie di valori Key nell'intestazione P-RTP-Stat.

• SIPCdpc invia il record Diagnostic a EnvProcessCdr con i dati CMR popolati e EnvProcessCdr crea un file flat e vi scarica i dati CMR.

• Nessun nuovo campo viene aggiunto al CMR come parte di questa funzionalità. Formato esistente da mantenere.

• Tutti i campi nella CMR che non sono rilevanti per le metriche lato trunk (come DirectoryNumber, ecc.) devono essere lasciati su null, analogamente per le metriche non ricevute da CUBE (ad esempio varVQMetrics o metriche video) da lasciare su null. 

• Se l'intestazione P-RTP-Stat non viene ricevuta dal CUBE per il messaggio BYE o 200 OK (risposta a BYE), non vi sarà alcun record CMR scritto per SIPTrunk.

  

Prerequisito da CUBE per supportare questa funzionalità/fornire statistiche sulle chiamate:

• Cisco IOS release 15.1(3)T o successive deve essere installato e deve essere eseguito su Cisco Unified Border Element.
• Cisco IOS XE release 3.3S o successive deve essere installato e deve essere eseguito sul router Cisco ASR serie 1000.

Configurazioni

Passaggio 1. La funzione CMR è abilitata tramite i parametri del servizio Call Manager in :

1. Passa a Sistema > Parametro servizio.
   
   
2. Selezionare un server dalla casella a discesa, quindi selezionare il servizio Gestione chiamate

Passaggio 2. Impostare il parametro Diagnostica chiamata abilitata su:

1. Abilitato Solo quando il flag CDR abilitato è impostato su True (genera CMR solo quando il parametro del servizio Flag CDR abilitato è impostato su True).
   
   

2. Abilitato indipendentemente dal flag CDR abilitato (genera CMR senza tenere conto dell'impostazione nel parametro del servizio Flag Abilitato CDR).

Analisi traccia 

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

I dati CMR sopra riportati vengono inseriti nel file nel repository sottostante activelog/cm/cdr_repository/processed/<current date>/

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

cmr_StandAloneCluster_01_201902051047_0

dir count = 0, file count = 1

Verifica

Dalla CLI, è possibile verificare se CMR è stato generato o meno. Per ogni data è presente una cartella creata nel formato <aaaammgg>

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

cmr_StandAloneCluster_01_201902051047_0

dir count = 0, file count = 1

Risoluzione dei problemi

 L'intestazione P-RTP-Stat viene ricevuta in BYE/200OK, ma i dati CMR non vengono generati

<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

Soluzione temporanea:

Verificare se l'SP Diagnostica chiamata abilitata è abilitato.

Intestazione P-RTP-Stat presente ma CMR non registrato

<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

Motivo:

Poiché sia numberPacketsSent che numberPacketsReceived non sono validi, i dati CMR non vengono immessi nel file per SIP Trunk.

I dati CMR sono generati dall'intestazione P-RTP-Stat, ma alcuni valori sono registrati in modo errato

<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

Motivo:

Poiché i valori PS e PR non sono compresi nell'intervallo (valori maggiori di 2^32-1), questi valori non compresi nell'intervallo vengono sostituiti con il valore massimo, ovvero 2^32-1(4294967295).

Chiavi consentite e intervallo di valori nell'intestazione P-RTP-Stat 

Limitazioni delle funzionalità

Questa funzionalità non è supportata per i flussi di chiamata SME:

• Dopo aver ricevuto le statistiche delle chiamate dal GW CUBE/IOS su SME, CUCM genererà CMR (a condizione che CMR sia abilitato) per il lato trunk, ma non sarà in grado di inoltrare le statistiche delle chiamate ad altri nodi in BYE in uscita o 200OK per BYE.
• Flusso di chiamata di esempio:
  Phone1 >> CUBE/IOS GW>> SME >> CUCM1 >> Phone2
  Per lo scenario di chiamata di cui sopra, SME genererà il CMR per il lato trunk che punta a CUBE. Queste statistiche non verranno inoltrate al nodo foglia. Per Phone2, CMR verrà registrato sul nodo foglia.