简介
本文描述两发出您也许遇到与思科MediaSense并且提供关于他们的故障排除信息。MediaSense是细听并且记录所有通信处理在它的呼叫记录平台。如果该信息，可以是语音或数据，没有适当地接收也没有接收，也许没在如期望的一样MediaSense出现或预计。然而，它经常是配置或网络相关的问题。
缺少音频
呼叫的第一种类型是音频不存在的地方，而是数据接收。在这些情况下，问题典型地是一个配置或网络相关的问题与访问控制列表(ACL)、Cisco Unified Communcations管理器(CUCM)，或者Cisco Unified Border Element (多维数据集)。
验证此种问题的最佳方法是确保，呼叫控制日志启用，通过思科实时监控工具(RTMT)请求日志，并且有搜索的缺少音频呼叫日志的会话ID。
在您收集后呼叫控制记录，打开他们，搜索会话ID，并且验证在diskusage下的大小不是0。如果日志显示size="0"， MediaSense很可能没有接收音频，并且所以不在那里。
在本例中，会话ID是78e146437088a93。
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
当您搜索时，请检查提及特定的会话ID的diskusage的线路。在此区域中，您注意有在录音属性的一个大小。此示例显示该size="0"，含义MediaSense没有接收从CUCM或多维数据集的音频。
在缺少音频的为做进一步的故障排除提示，参考CUCM MediaSense呼叫记录错误故障排除。
缺失或不正确的呼叫信息
呼叫的第二种类型是数据是不存在或修改的地方。在这些情况下，问题归结于在多维数据集或CUCM的配置。
验证此种问题的最佳方法是确保，呼叫控制日志启用和访问那些通过RTMT。保证youd有搜索的缺少音频呼叫日志的会话ID。
搜索正文块在包含所有呼叫信息MediaSense获得，包括，但是没有被限制对的CCBU_CALL_CONTROL-6-BORDER_MESSAGE下：
- 呼叫的产生的位置
- 目录号(Dns)呼叫
- 编码和更多信息
如果某事此处不匹配什么应该是，您也许需要分析在CUCM或多维数据集的呼叫流为了确定信息哪里被修改。
这两示例显示与缺失或不正确的呼叫信息的这两个不同的问题。
示例1 -截去的电话号码
在本例中，会话ID的5148fb9543011预期值显示19725551234，但是MediaSense只显示197255512在搜索&作用。
0000030499: 10.201.227.36: Oct 10 2014 15:42:16.512 -0400: %CCBU_CALL_CONTROL-6-
BORDER_MESSAGE: {Thrd=Pool-ams-thread-9} %[message_string=HttpPostClient-9:
executing POST http://10.201.227.36:8640/ora/SipAdaptorService/SipAdaptor/
addOrUpdateSession HTTP/1.1
{"sessionData": {
"callControllerIP": "10.201.227.33",
"callControllerType": "Cisco-CUCM",
"endPoints": [
{
"clusterid": "StandAloneCluster",
"conference": false,
"device": "SEP123456ABCDEF",
"displayName": "Agent 2102",
"dn": "2102",
"startDate": 1412970136508,
"tracks": [{
"codec": "PCMU",
"location": "/recordedMedia",
"mediaState": "ACTIVE",
"startDate": 1412970136508,
"track": 0,
"type": "AUDIO"
}],
"type": "NEAR_END",
"xRefci": "37328298"
},
{
"clusterid": "StandAloneCluster",
"conference": false,
"device": "S0/SU1/DS1-1@PAVAN-2811",
"dn": "197255512",
"startDate": 1412970136508,
"tracks": [{
"codec": "PCMU",
"location": "/recordedMedia",
"mediaState": "ACTIVE",
"startDate": 1412970136508,
"track": 1,
"type": "AUDIO"
}],
"type": "FAR_END",
"xRefci": "37328299"
}
],
"operationType": "ADD",
"recordingServer": "10.201.227.36",
"rtspUrl": "rtsp://10.201.227.36/5148fb9543011",
"sessionName": "5148fb9543011",
"sipServer": "10.201.227.36",
"startDate": 1412970136508,
"state": "ACTIVE",
"version": 7
在这种情况下，请注意MediaSense接收有最后两个位的第19725551234剥去。因为此信息来自CUCM，那是查找的下个地方为了确定CUCM是否也接收从进一步上的一个截去的编号呼叫流或这是否在CUCM发生。
促进故障排除确定，在此方案， CUCM导致了问题，在Cisco Bug ID CSCuq20108描述：
If the From header sent to a recording server exceeds 231 characters, the header
will get truncated if escaped characters are found. if the From header contains
escaped characters "@", (i.e. %40), the dynamic buffer allocation doesn't account
for this resulting in characters getting truncated.
示例2 -没有电话号码
在本例中， DN是完全缺少的呼叫SIP_TRUNK_CVP的设备。
0014107576: 10.201.227.136: Sep 02 2014 16:50:30.484 -0500: %CCBU_CALL_CONTROL-6-
BORDER_MESSAGE: {Thrd=Pool-ams-thread-222081} %[message_string=HttpPostClient-222082:
executing POST http://10.201.227.136:8640/ora/SipAdaptorService/SipAdaptor/
addOrUpdateSession HTTP/1.1
{"sessionData": {
"callControllerIP": "10.201.227.133",
"callControllerType": "Cisco-CUCM",
"endPoints": [
{
"conference": false,
"device": "SEP12356ABCDEF",
"displayName": "Agent 3102",
"dn": "3102",
"startDate": 1409694630483,
"tracks": [{
"codec": "PCMU",
"location": "/recordedMedia",
"mediaState": "ACTIVE",
"startDate": 1409694630483,
"track": 0,
"type": "AUDIO"
}],
"type": "NEAR_END",
"xRefci": "65826764"
},
{
"conference": false,
"device": "SIP_TRUNK_CVP",
"dn": "",
"startDate": 1409694630483,
"tracks": [{
"codec": "PCMU",
"location": "/recordedMedia",
"mediaState": "ACTIVE",
"startDate": 1409694630483,
"track": 1,
"type": "AUDIO"
}],
"type": "FAR_END",
"xRefci": "65826763"
}
],
在此方案中，日志显示没有DN信息发送对MediaSense，非常类似于前一个示例。为了进一步排除故障，您应该验证CUCM正确接受信息，然后检查多维数据集。
反馈