Mejora de CMR en CUCM 12.5

Introducción

Este documento describe las mejoras de Call Management Records (CMR) en Cisco Unified Communications Manager (CUCM) 12.5.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• CUCM versión 12.5
• Habilitar registro de detalles de llamada (CDR) y CMR en CallManager

Componentes Utilizados

La información que contiene este documento se basa en Cisco Call Manager versión 12.5.

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 tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Antecedentes 

 CUCM produce dos tipos de registros, que almacenan el historial de llamadas y la información de diagnóstico:

• Registros de detalles de llamadas: los registros de datos contienen información sobre cada llamada procesada por CallManager.
• Registros de gestión de llamadas: los registros de datos contienen la calidad del servicio (QoS) o información de diagnóstico sobre la llamada, también denominada registros de diagnóstico.

Tanto los CDR como los CMR juntos se denominan datos CDR. Los datos de CDR proporcionan un registro de todas las llamadas que han realizado o recibido los usuarios del sistema CallManager. Los datos de CDR son útiles principalmente para generar los registros de facturación; sin embargo, también se puede utilizar para realizar un seguimiento de la actividad de las llamadas, diagnosticar determinados tipos de problemas y planificar la capacidad.

Los CMR contienen información sobre la cantidad de datos enviados y recibidos, la fluctuación, la latencia y los paquetes perdidos. Inicialmente, se generó CMR para llamadas internas, ahora CUCM puede generar CMR para llamadas a través del troncal SIP.

El troncal SIP recibe las estadísticas de llamadas en el encabezado P-RTP-Stat en el mensaje BYE o en los mensajes 200 OK (respuesta al mensaje BYE) de CUBE o la puerta de enlace IOS. Estas estadísticas incluyen los paquetes enviados o recibidos del protocolo de transporte en tiempo real (RTP), los bytes totales enviados o recibidos, el número total de paquetes perdidos, la fluctuación de demora, la demora de ida y vuelta y la duración de la llamada.

El formato del encabezado P-RTP-Stat:

P-RTP-Stat: PS=<Packets Sent>, OS=<Octets Sent>, PR=<Packets Recd>, OR=<Octets Recd>, PL=<Packets Lost>, JI=<Jitter>, LA=<Round Trip Delay in ms>, DU=<Call Duration in seconds>

Es el formato del informe de estadísticas de RTP de gateway del IOS de CUBE/SIP. El lado troncal SIP de CUCM para la compatibilidad con CMR se limita a ese formato de estadísticas RTP.

• Después de recibir BYE o 200OK para BYE, SIPCdpc analiza el encabezado P-RTP-Stat y rellena los campos CMR correspondientes basándose en los pares de valores Key en el encabezado P-RTP-Stat.

• SIPCdpc envía el registro de diagnóstico a EnvProcessCdr con datos CMR rellenados y EnvProcessCdr crea un archivo plano y envía los datos CMR a él.

• No se agregan nuevos campos al CMR como parte de esta función. El formato existente se mantendrá.

• Cualquier campo del CMR que no sea relevante para las métricas del lado del tronco (como DirectoryNumber, etc.) que se dejarán en nulo, de forma similar para las métricas no recibidas de CUBE (por ejemplo, varVQMetrics o métricas de vídeo) que se dejarán en nulo. 

• Si el encabezado P-RTP-Stat no se recibe del mensaje CUBE para BYE o 200 OK (respuesta a BYE), no habrá ningún registro CMR escrito para SIPTrunk.

  

Requisito previo de CUBE para admitir esta función / proporcionar estadísticas de llamadas :

• Cisco IOS Release 15.1(3)T o una versión posterior debe estar instalada y ejecutarse en Cisco Unified Border Element.
• Cisco IOS XE versión 3.3S o una versión posterior debe estar instalada y ejecutarse en el router Cisco ASR 1000 Series.

Configuraciones

Paso 1. CMR está habilitado a través de los parámetros de servicio del Call Manager bajo :

1. Vaya a System > Service Parameter.
   
   
2. Seleccione un servidor en el cuadro desplegable y, a continuación, seleccione el servicio Call Manager

Paso 2. Establezca el parámetro Call Diagnostics Enabled en:

1. Habilitado sólo cuando el indicador CDR habilitado es True (genere CMR sólo cuando el parámetro de servicio CDR Enabled Flag esté establecido en True).
   
   

2. Habilitado independientemente del indicador CDR habilitado (genera CMR sin tener en cuenta la configuración del parámetro de servicio CDR Enabled Flag).

Análisis de seguimiento 

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

Los datos CMR anteriores se introducen en el archivo en el siguiente repositorio activelog/cm/cdr_repositorio/procesado/<fecha actual>/

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

cmr_StandAloneCluster_01_201902051047_0

dir count = 0, file count = 1

Verificación

Desde cli, puede verificar si CMR se genera o no. Para cada fecha, hay una carpeta creada con el formato <yyyymmdd>

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

cmr_StandAloneCluster_01_201902051047_0

dir count = 0, file count = 1

Troubleshoot

 El encabezado P-RTP-Stat se recibe en BYE/200OK, pero los datos CMR no se generan

<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

Solución alternativa:

Verifique si Call Diagnostics Enabled SP está habilitado.

El encabezado P-RTP-Stat está presente pero CMR no está registrado

<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:

Dado que numberPacketsSent y numberPacketsReceived no son válidos, los datos CMR no se descargan en el archivo para el troncal SIP.

Los datos CMR se generan a partir del encabezado P-RTP-Stat, pero algunos valores se registran erróneamente

<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:

Dado que los valores PS y PR están fuera del intervalo (valores mayores que 2^32-1), estos valores fuera del intervalo se reemplazan por el valor máximo, es decir, 2^32-1(4294967295).

Claves permitidas y rango de valores en el encabezado P-RTP-Stat 

Limitaciones de la función

Esta función no es compatible con los flujos de llamadas de SME:

• Al recibir estadísticas de llamadas de CUBE/IOS GW en SME, CUCM generará CMR (siempre que CMR esté habilitado) para el lado troncal, pero no podrá reenviar estadísticas de llamadas a otros nodos en BYE saliente o 200OK para BYE.
• Flujo de llamada de ejemplo:
  Phone1 >> CUBE/IOS GW> SME >> CUCM1 >> Phone2
  Para el escenario de llamada anterior, SME generará el CMR para el lado troncal que apunta a CUBE . Estas estadísticas no se reenviarán al nodo de hoja. Para Phone2, CMR se grabará en el nodo de hoja.