目录

简介

先决条件

要求

使用的组件

背景信息

配置

跟踪分析

验证

故障排除

在BYE/200OK中接收P-RTP-Stat报头，但未生成CMR数据

P-RTP-Stat报头存在，但未记录CMR

CMR数据是从P-RTP-Stat报头生成的，但某些值记录错误

P-RTP-Stat报头中允许的密钥和值范围

功能限制

简介

本文档介绍Cisco Unified Communications Manager(CUCM)12.5上的呼叫管理记录(CMR)增强功能。

先决条件

要求

Cisco 建议您了解以下主题：

- CUCM版本12.5

- 在CallManager上启用呼叫详细信息记录(CDR)和CMR

使用的组件

本文档中的信息基于 Cisco Call Manager 12.5 版。

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您的网络处于活动状态，请确保您了解所有命令的潜在影响。

背景信息

CUCM生成两种记录，存储呼叫历史记录和诊断信息：

- 呼叫详细记录 — 数据记录包含有关CallManager处理的每个呼叫的信息。

- 呼叫管理记录 — 数据记录包含有关呼叫的服务质量(QoS)或诊断信息，也称为诊断记录。

CDR和CMR一起称为CDR数据。CDR数据提供CallManager系统用户已发出或接收的所有呼叫的记录。CDR数据主要用于生成计费记录；但是，它还可用于跟踪呼叫活动、诊断某些类型的问题和容量计划。

CMR包含有关发送和接收的数据量、抖动、延迟和丢包的信息。最初，CMR是为内部呼叫生成的，现在CUCM可以通过SIP中继生成呼叫的CMR。

SIP中继从CUBE或IOS网关接收BYE消息或200条OK消息（响应BYE消息）中P-RTP-Stat报头中的呼叫统计信息。这些统计信息包括发送或接收的实时传输协议(RTP)数据包、发送或接收的总字节数、丢失的数据包总数、延迟抖动、往返延迟和呼叫持续时间。

P-RTP-Stat报头的格式：

P-RTP-Stat:PS=<发送的数据包数>、OS=<发送的八位组数>、PR=<发送的数据包数>、OR=<八位组数>、PL=<丢失的数据包数>、JI=<抖动>、LA=<ms中的往返延迟数>、DU=呼叫持续时间（秒）>

它是CUBE/SIP IOS网关RTP统计报告的格式。CMR支持的CUCM SIP中继端限于RTP统计的该格式。

- 在收到BYE或200OK的BYE后，SIPCdpc解析P-RTP-Stat报头，并根据P-RTP-Stat报头中的密钥值对填充相应的CMR字段。

- SIPCdpc将诊断记录发送到包含已填充CMR数据的EnvProcessCdr，EnvProcessCdr创建平面文件并将CMR数据转储到该文件中。

- 此功能的一部分不会向CMR添加新字段。要维护的现有格式。

- CMR中与中继端度量（如DirectoryNumber等）不相关的任何字段都保留为空，类似地，对于未从CUBE接收的度量（如varVQMetrics或视频度量）保留为空。

- 如果未从CUBE收到P-RTP-Stat报头以用于BYE消息或200 OK（响应BYE），则不会为SIPTrunk写入CMR记录。

CUBE支持此功能/提供呼叫统计的前提条件：

- 必须安装思科IOS版本15.1(3)T或更高版本，并且应在思科统一边界元素上运行。

- 必须安装Cisco IOS XE版本3.3S或更高版本，并且应在Cisco ASR 1000系列路由器上运行。

配置

步骤1. CMR通过以下Call Manager服务参数启用：

1. 导航至 系统(System)>服务参数(Service Parameter)。

2. 从下拉框中选择服务器，然后选择Call Manager服务

步骤2.将Call Diagnostics Enabled参数设置为以下任一参数：

1. 仅在CDR启用标志为True时启用（仅当CDR启用标志服务参数设置为True时生成CMR）。

2. 无论CDR启用标志如何启用（生成CMR而不考虑CDR启用标志服务参数中的设置）。

跟踪分析

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

上述CMR数据被推送到存储库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

验证

从cli，您可以验证是否生成了CMR。对于每个日期，都会创建一个格式为<yyymmdd>的文件夹

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

cmr_StandAloneCluster_01_201902051047_0

dir count = 0, file count = 1

故障排除

在BYE/200OK中接收P-RTP-Stat报头，但未生成CMR数据

<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

解决方法：

检查是否启用了呼叫诊断SP。

P-RTP-Stat报头存在，但未记录CMR

<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

理由：

由于numberPacketsSent和numberPacketsReceived都无效，因此CMR数据不会转储到SIP中继的文件中。

CMR数据是从P-RTP-Stat报头生成的，但某些值记录错误

<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

理由：

由于PS和PR值超出范围（大于2^32-1的值），因此这些超出范围的值将替换为最大值，即2^32-1(4294967295)。

P-RTP-Stat报头中允许的密钥和值范围

功能限制

SME呼叫流不支持此功能：

- 在SME上从CUBE/IOS GW接收呼叫统计信息后，CUCM将为中继端生成CMR（如果启用了CMR），但它无法将呼叫统计信息转发到传出BYE或200OK中的其他节点进行BYE。

- 呼叫流程示例：

Phone1 >> CUBE/IOS GW>> SME >> CUCM1 >> Phone2

对于上述呼叫场景，SME将为指向CUBE的中继端生成CMR。这些统计信息不会转发到枝叶节点。对于Phone2,CMR将记录在枝叶节点上。