目錄

簡介

必要條件

需求

採用元件

背景資訊

組態

追蹤分析

驗證

疑難排解

P-RTP-Stat標頭在BYE/200OK中接收，但未生成CMR資料

P-RTP-Stat標頭存在，但未記錄CMR

CMR資料由P-RTP-Stat報頭生成，但某些值記錄錯誤

P-RTP-Stat報頭中允許的鍵和值範圍

功能限制

簡介

本檔案介紹Cisco Unified Communications Manager(CUCM)12.5上的通話管理記錄(CMR)增強功能。

必要條件

需求

思科建議您瞭解以下主題：

- 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中繼在BYE消息或200 OK消息（對BYE消息的響應）的P-RTP-Stat報頭中接收來自CUBE或IOS網關的呼叫統計資訊。這些統計資訊包括傳送或接收的即時傳輸協定(RTP)資料包、傳送或接收的總位元組數、丟失的資料包總數、延遲抖動、往返延遲和呼叫持續時間。

P-RTP-Stat報頭的格式：

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

它是CUBE/SIP IOS網關RTP統計報告的格式。CMR支援的CUCM SIP中繼端僅限於RTP統計資訊的格式。

- 在收到BYE或200OK for BYE後，SIPCdpc解析P-RTP-Stat報頭，並根據P-RTP-Stat報頭中的鍵值對填充相應的CMR欄位。

- SIPCdpc將診斷記錄傳送到包含填充的CMR資料的EnvProcessCdr，EnvProcessCdr建立平面檔案並將CMR資料轉儲到其中。

- 作為此功能的一部分，沒有向CMR新增新的欄位。要維護的現有格式。

- CMR中與中繼端度量（如DirectoryNumber等）不相關的任何欄位保留為null，與未從CUBE接收的度量（如varVQMetrics或影片度量）的欄位類似，保留為null。

- 如果未從CUBE收到BYE消息或200 OK（對BYE的響應）的P-RTP-Stat標頭，則不會為SIPTrunk寫入CMR記錄。

CUBE支援此功能/提供呼叫統計資訊的先決條件：

- 必須安裝Cisco IOS版本15.1(3)T或更高版本並且應在您的思科統一邊界元素上運行。

- 必須安裝Cisco IOS XE 3.3S版或更高版本，並且應在Cisco ASR 1000系列路由器上運行。

組態

步驟1.通過下面的Call Manager服務引數啟用CMR:

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資料被推入下面的檔案repository 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。對於每個日期，都有一個以<yyyymmdd>格式建立的資料夾

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

cmr_StandAloneCluster_01_201902051047_0

dir count = 0, file count = 1

疑難排解

P-RTP-Stat標頭在BYE/200OK中接收，但未生成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

因應措施：

檢查Call Diagnostics Enabled 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呼叫流不支援此功能：

- CUCM從SME上的CUBE/IOS GW接收呼叫統計資訊後，將為中繼端生成CMR（如果啟用CMR），但無法將呼叫統計資訊轉發到傳出BYE或200OK中的BYE。

- 呼叫流程示例：

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

對於上述呼叫情況，SME將為指向CUBE的中繼端生成CMR。這些統計資訊不會轉發到枝葉節點。對於Phone2，將在枝葉節點上記錄CMR。