本文檔介紹當內建網橋的呼叫記錄中出現錯誤時,如何對MediaSense進行故障排除。
此圖說明了使用內建網橋時的基本MediaSense呼叫流:
以下步驟描述了呼叫流程:
如果您收到指示MediaSense上沒有錄製的錯誤,則必須檢視日誌並搜尋此會話ID:
0000049583: 10.201.227.136: May 28 2014 11:27:09.022 -0400: %CCBU_COMMON-6-VSMS
HTTP Info: {Thrd=Pool-capture-thread-2800} %[HTTP Response Body=<Session>
<diskusage>
<recording name="78e146437088a93-TRACK0" size="0" repository="/
recordedMedia" />
<recording name="78e146437088a93-TRACK1" size="0"repository="/
recordedMedia" />
</diskusage>
</Session>][HTTP Response Content Type=application/xml][HTTP Response Status
Code=200][logId=close-25668]: VSMS Received HTTP Response
此輸出中的size="0"表示伺服器上沒有記錄該呼叫的音訊。這通常意味著RTP流無法從電話訪問MediaSense伺服器。發生這種情況時,下一步是驗證電話是否傳送了RTP流量。
驗證IP電話是否傳送RTP流量的一種快速方法是檢視IP電話網頁。此功能在電話配置頁面或批次管理中在CUCM上手動啟用。
Stream 1是另一台IP電話或網關的遠端地址的主呼叫。這包括兩個流:第一個流是IP電話上接收的音訊,第二個流是傳送到另一端的音訊。
為了驗證MediaSense是否記錄兩個呼叫段,請點選流2和流3,以驗證頁面多次刷新時傳送方資料包是否增加。遠端地址應顯示流2和流3的MediaSense伺服器。存在兩個流到MediaSense伺服器的原因是,其中一個流是流1上接收的音訊(接收方資料包),另一個流是流1上向另一端傳送的音訊(傳送方資料包)。
此捕獲顯示流1:
此捕獲顯示流2:
此捕獲顯示流3:
驗證流2和流3的資料時,需要注意的關鍵問題是:
這表示RTP封包是透過IP電話傳送的。
如果您仍不確定IP電話是否傳送RTP資料包,則下一步是執行資料包捕獲並重放資料流。
在執行資料包捕獲之前,請確保在CUCM的IP電話配置上啟用以下設定:
然後,應用配置並重置IP電話。完成此操作後,開啟Wireshark並捕獲一個持續30秒的資料包。確保記錄相關IP電話的遠端地址以及流2和流3的埠。例如:
完成封包擷取後,開啟封包擷取並對每個串流完成以下步驟:
執行資料包捕獲並驗證MediaSense配置正確並且IP電話向MediaSense伺服器傳送有效的RTP流,並且您繼續遇到問題後,應檢查伺服器和IP電話之間的路徑。
確保路徑沒有任何存取控制清單(ACL),且不會封鎖或過濾RTP流量。
如果使用CUCM設定的呼叫出現問題,則檢視詳細的CUCM日誌,然後開啟MediaSense日誌以查詢呼叫ID。從會話ID中可找到此項,並且在呼叫控制日誌中看起來與此項相似:
CallId: 74acba00-38c1ea2d-3a2937-f183000a@10.0.131.241
CallId: 74acba00-38c1ea2d-3a2938-f183000a@10.0.131.241
由於IP電話使用MediaSense設定兩個流(一個流用於原始電話呼叫的每一段),因此使用其中一個呼叫ID搜尋CUCM日誌,以驗證MediaSense會話是否正確設定。
修訂 | 發佈日期 | 意見 |
---|---|---|
1.0 |
26-Jun-2014 |
初始版本 |