Introduction
本文描述两发出您也许遇到与Cisco MediaSense并且提供关于他们的故障排除信息。MediaSense是细听并且记录所有通信处理在它的呼叫记录平台。如果该信息，可以是语音或数据，没有适当地获得也没有获得，也许没于如期望的一样MediaSense出现或预计了。然而，它经常是配置或网络有关的问题。
缺少音频
呼叫的第一种类型是音频不存在的地方，而是数据被接受。在这些情况下，问题典型地是一个配置或网络有关的问题的访问控制列表(ACL)、Cisco Unified Communcations管理器(CUCM)，或者Cisco Unified Border Element (多维数据集)。
验证此种问题的最佳方法是确信，呼叫控制日志是启用的，通过Cisco实时监视工具(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正确接受信息，然后检查多维数据集。
反馈