Совместная работа : Cisco MediaSense

MediaSense недостающее аудио или сведения о вызове

5 апреля 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Отзыв

Введение

Этот документ описывает две проблемы, с которыми вы могли бы встретиться с Cisco MediaSense и предоставляете сведения об устранении проблем о них. MediaSense является платформой записи вызовов, которая прислушивается и делает запись всей связи, направленной на него. Если та информация, которая может быть голосом или данными, не получена или получена должным образом, это не могло бы появиться в MediaSense, как требуется или ожидается. Однако это часто - конфигурация или связанный с сетью проблемы.

Внесенный паваной Дэйв, специалист службы технической поддержки Cisco.

Недостающее аудио

Первый тип вызова - то, где аудио не присутствует, но данные получены. В этих ситуациях проблема, как правило, с конфигурацией или связанна с сетью проблемы со Списками контроля доступа (ACL), Cisco унифицированный менеджер Communcations (CUCM) или Cisco Unified Border Element (CUBE).

Лучший способ проверить этот тип проблемы состоит в том, чтобы удостовериться, что журналы управления вызовами включены, вытяните журналы через устройство контроля в реальном времени (RTMT) Cisco и имейте идентификатор сеанса недостающего аудио журнала вызовов для поиска.

После того, как вы будете собирать журналы управления вызовами, будете открывать их, будете искать идентификатор сеанса и проверять, что размер под diskusage не 0. Если журналы показывают размер = "0", MediaSense, вероятно, не получал аудио, и именно поэтому это не там.

Пример

В данном примере идентификатор сеанса 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

Когда вы ищете, исследуете линии, которые упоминают diskusage для ID отдельного сеанса. В этой области вы замечаете, что существует размер в атрибутах записи. Данный пример показывает, что размер = "0", что означает MediaSense, не получал аудио от CUCM или CUBE.

Для дальнейших советов по устранению проблем на недостающем аудио, ссылочном ошибочном CUCM MediaSense Устранении проблем Записи вызовов.

Без вести пропавшие или неправильные сведения о вызове

Второй тип вызова - то, где данные являются или не существующими или изменены. В этих сценариях проблема происходит из-за конфигураций на CUBE или CUCM.

Лучший способ проверить этот тип проблемы состоит в том, чтобы удостовериться, что журналы управления вызовами включены и обращаются к тем через RTMT. Гарантируйте что youd для имения идентификатора сеанса недостающего аудио журнала вызовов для поиска.

Ищите Блок текста под CCBU_CALL_CONTROL-6-BORDER_MESSAGE, который содержит все сведения о вызове, которые получает MediaSense, который включает, но не ограничен:

  • Инициирующее местоположение вызова
  • Номера каталога (DN) вызова
  • Кодек и много дополнительных сведений

Если что-то здесь не совпадает, каково это должно быть, вы, возможно, должны были бы проанализировать поток вызовов или в CUCM или в CUBE для определения, где изменена информация.

Эти два примера показывают эти два других вопроса с без вести пропавшими или неправильными сведениями о вызове.

Пример 1 - отсеченный номер телефона

В данном примере ожидаемое значение для идентификатора сеанса 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 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 получает информацию правильно, и затем проверьте CUBE.


Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.