本文档介绍当内置网桥的呼叫记录中出现错误时,如何对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上通过批量管理启用。
流1是带有另一个IP电话或网关的远程地址的主呼叫。这包含两个流:第一个流是IP电话上收到的音频,第二个流是发送到另一端的音频。
要验证MediaSense是否记录了两个呼叫段,请点击Stream 2和Stream 3,以验证页面多次刷新时Sender Packets是否增加。远程地址应显示流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会话是否正确设置。