Проблемы со звуком — различия между версиями

Материал из Oktell
Перейти к: навигация, поиск
 
(не показано 106 промежуточных версии этого же участника)
Строка 1: Строка 1:
 
[[Возникающие проблемы и способы их решения | Наверх]]
 
[[Возникающие проблемы и способы их решения | Наверх]]
  
−
'''Если звук есть, то все хорошо. А что делать, если звука нет? Или есть, но не такой какой должен.'''
+
__TOC__
  
−
Существует большое количество возможностей, как определить и наладить. В любом случае начинается все с диагностики. Статья призвана облегчить и уменьшить объем работ технической поддержке. Чаще всего диагностика требует времени именно на проведение рутинных мероприятий. Умозаключениям там отведено довольно малое и довольно редкое место. Речь конечно же идет о SIP.
 
  
−
== Симптомы и расширения. ==
+
В данной статье рассматриваются проблемы, связанные с отсутствием звука или плохим качеством звука при соединении с абонентом.  
  
 +
Структурно телефония состоит из 2х компонентов:
  
−
Начинается все с ответов на простые вопросы, связанные с проведением тестов. В итоге получается некоторая сводная таблица, на основании которой можно делать вывод и переходить ко второму слою. Необходимо ответить на следующие вопросы:
+
1) '''Сигнализация''' - механизм, который отвечает за то, чтобы два абонента могли связаться между собой (найти друг друга, отправить вызов в трубку, начать коммутацию). В '''Oktell''' используется протокол '''SIP'''.
  
−
*1. Связана ли проблема со звонками к/от провайдера, только ли в таких звонках наблюдается проблема. Если речь идет не о полном отсутствии, то какой характер порчи звука
+
2) '''Передача медиа-трафика''' - механизм передачи звуковой информации (голоса). Механизм являет собой пакетную передачу данных: голос конвертируется в пакеты данных (RTP-пакеты), которые начинают передаваться от абонента А к абоненту Б через интернет.  
−
**а) выпадение пакетов (щелчки)
+
−
**б) выпадение серий пакетов (потеря слов)
+
−
**в) плавание звука (перемешивание пакетов)
+
−
**г) постоянно некачественный голосд) абсолютно левый звук (свист, "водичка")
+
−
**е) периодические искажения
+
−
**ж) полное остутствие звука в одном из направлений или в обоих направлениях
+
−
*2. В каких направлениях наблюдается эффект
+
−
**а) в обоих (и я слышу плохо, и абонент слышит плохо)
+
−
**б) только в одном (я слышу плохо, абонент слышит хорошо)
+
−
**в) только в одном (я слышу хорошо, абонент слышит плохо)
+
−
*3. При каких звонках нет звука
+
−
**а) при входящих
+
−
**б) при исходящих
+
−
*4. В каких медиа-направлениях наблюдается проблема
+
−
**а) sip-cti
+
−
**б) sip-usb
+
−
**в) внешний sip - внешний sip
+
−
**г) внутренний sip- внутренний sip
+
−
**д) внешний sip - внутренний sip
+
−
*5. Стабильно ли проявляется проблема в обнаруженном направлении/комбинации.
+
−
*6. Если в наличии много проблем, то следует попытаться найти комбинацию, в которой звук нормальный. Это поможет вывести из-под подозрения сразу целые блоки. А также сравнить окружение у хорошего и плохого звонков.
+
−
*7. Каким образом происходит соединение
+
−
**а) через сценарий путем внешнего переключения с выбранным режимом "коммутация сразу"
+
−
**б) через сценарий путем внешнего переключения с выбранным режимом "прослушивание медиа-потока"
+
−
**в) вне зависимости от способа коммутации, и даже звонки на внутренние.
+
  
 +
В процессе передачи, пакеты данных могут теряться из-за плохого интернет соединения, испытывать задержки, не достичь конечного пункта из-за неправильной конфигурации.
  
−
== Что делать? ==
 
  
 +
== Отсутствие звука ==
  
−
Ответить на вопрос, в чем главная задача:
+
===Возможные причины===
−
*а) найти самое быстрое решение,
+
−
*б) найти самое дешевое решение,
+
−
*в) во что бы то ни стало заставить работать именно в текущей комбинации.
+
  
 +
Для определения причины требуется предварительная диагностика проблемы. О методах диагностики читайте ниже.
  
 +
'''1.''' Удаленный медиа-сервер (сервер провайдера телефонии) не отправляет медиа-трафик. Проверить можно с помощью программы-сниффера '''WireShark'''.
  
−
== Немного о настройках ==
+
:'''1.1.''' Возможно коммутация не установлена на уровне '''SIP'''-сигнализации. Проверьте по логу '''trn''' ('''\Server\Log\Hardware\SIP\''') наличие '''SIP'''-пакета "'''200 OK'''" по этой коммутации.
  
 +
'''2.''' Медиа-трафик не поступает на сервер '''Oktell'''.
  
−
Могут пригодиться. '''Администрирование'''->'''Параметры аппаратуры'''. Часть настроек в разделе SIP-сервер, часть у шлюзов, большинство у потоков (аккаунтов).
+
:'''2.1.''' Удостоверьтесь, что порт 5060 на вашем сетевом интерфейсе прослушивается процессом '''oktell.HALRemoteApp.exe'''. Для этого в командной строке наберите команду
 +
netstat -anopb udp
  
−
*- Отсылать пакеты на адрес отправителя (взамен указанным в SDP данным). Чаще всего используется при работе с провайдером через NAT. Не все провайдеры поддерживают такую настройку, но некоторые изначально работают именно так, некоторые по просьбе включают, некоторые не могут или не хотят. До поры реализации обхода NAT в самом Oktell, разбираться приходится внешним образом в зависимости от ситуации. В том числе можно использовать и прямые шлюзы. Выносить сервер на белый адрес не очень хорошо, но тоже действует. Не забыть только при этом спам-фильтр активировать.
 
−
*- Запретить изменение параметров соединения на лету. Бывает, шлюзы/провайдеры не любят REINVITE инструкции, отправляемые с сервера. Хотя некоторые сами иной раз пользуются этим. Если выставлен запрет, октелл включает транскодинг у себя, иначе может попросить внешний шлюз (считая его конечным аппаратным устройством) сменить кодек.
 
−
*- Кодеки. Вопросы сжатия актуальны на полностью рабочей системе. А для начала ограничить все одним базовым кодеком, g.711а (или g.711u). И шлюзы в октелле, и телефоны используемые. Исключить из подозрения вплоть до решения проблемы.
 
−
*- Другой провайдер. Попробуйте SipNet.
 
  
 +
[[Файл:Проблемы со звуком - 050.png|center]]
  
−
== Лог журналы. ==
+
 
 +
:'''2.2.''' Проверьте, проброшены ли нужные порты на вашем NAT-устройстве. Воспользуйтесь статьей: [[Настройка работы сервера за NAT]]
 +
 
 +
:'''2.3.''' Проверьте настройки брандмауэра (firewall). Перейдите '''Брандмауэр Windows''' -> '''Разрешить запуск программы или компонента через брандмауэр Windows''' -> '''Разрешить другую программу''' -> '''Обзор''' и выберите
 +
:* \oktell\server\'''oktell.ServerService.exe'''
 +
:* \oktell\server\'''oktell.HALRemoteApp.exe'''
 +
 
 +
:<span style="color:red;"> ВНИМАНИЕ: Для проверки '''не рекомендуется''' отключать защиту системы в целях безопасности.
 +
 
 +
:'''2.4.''' Перезагрузите сервер '''Oktell'''.
 +
 
 +
 
 +
'''3.''' Медиа-трафик поступил на сервер Oktell, но не попал на телефон оператора. Из-за этого оператор не слышит внешнего абонента и думает, что звук отсутствует.
 +
 
 +
:'''3.1.''' Если оператор использует клиентское приложение, убедитесь что в настройках локальных устройств выбраны действующие динамики и микрофон.
 +
 
 +
:'''3.1.''' Если оператор находится в другой локальной сети за NAT (удаленный офис) - порты в удаленном офисе пробрасывать '''не нужно'''. Проверьте настройки роутера (например, установлено DMZ).
 +
 
 +
:'''3.2.''' В настройках IP-телефона (или софтфона) размер звукового пакета должен быть установлен 20 мс (packet time)
 +
 
 +
 
 +
[[Файл:Проблемы со звуком - 052.png|center]]
 +
 
 +
 
 +
 
 +
'''4.''' '''Прочее'''. Неправильная конфигурация сервера '''Oktell'''.
 +
 
 +
:'''4.1.''' Перейдите в '''Администрирование'''->'''Параметры аппаратуры'''.
 +
 
 +
:* '''Настройки потока''' -> '''Адрес назначения для RTP трафика.''' Настройка нужна, если абонент не слышит оператора (то есть звук идет от Oktell). Попробуйте поменять эту настройку и посмотреть на результат.
 +
 
 +
:* '''Настройки потока''' -> '''Размер звукового пакета для кодека G.711''' должен быть 20 мс.
 +
 
 +
:<span style="color:red;"> ВНИМАНИЕ: Все телефоны сотрудников также должны иметь параметр ptime (размер звукового пакета) равный 20 мс.
 +
 
 +
:* '''Настройки потока''' -> '''Разрешить изменять параметры связи во время коммутации''' - рекомендуется установить '''Нет'''. Бывает, шлюзы/провайдеры не любят REINVITE инструкции, отправляемые с сервера. Хотя некоторые сами иной раз пользуются этим. Если выставлен запрет, '''Oktell''' включает транскодинг у себя, иначе может попросить внешний шлюз (считая его конечным аппаратным устройством) сменить кодек.
 +
 
 +
:'''4.2.''' '''Кодеки'''. На время устранения проблем со звуком, рекомендуется установить единый кодек '''g.711a''' (или '''g.711u''') во всех шлюзах и телефонах (в карте сети).
 +
 
 +
 
 +
<center>[[Файл:Отсутствие звука -001.png|500px]] [[Файл:Отсутствие звука -002.png|500px]]</center>
 +
 
 +
 
 +
:'''4.3.''' Бывают случаи, когда отсутствует исходящий трафик от Oktell, при этом звонящий клиент не слышит оператора и IVR меню. Проблема часто заключается в обновлениях Windows, попробуйте удалить последние установленные обновления или вовсе отключить их. Для диагностики попробуйте выполнить команду ping или tracert в командной строке.
 +
 
 +
 
 +
=== Диагностика в Oktell ===
 +
 
 +
Откройте '''Офис''' -''' Статистика АТС'''. Прослушайте запись разговора.
 +
 +
* Если на записи вы не слышите внешнего абонента, а голос оператора присутствует - проблема в соединении между провайдером телефонии и сервером '''Oktell'''. Необходимо проверить '''входящий трафик на сервере Oktell'''.
 +
 
 +
* Если на записи вы слышите только внешнего абонента, а голоса оператора нет - это обозначает что проблема в соединении между телефоном оператора и сервером '''Oktell'''. Необходимо проверить '''исходящий интернет-трафик у оператора'''.
 +
 
 +
* Если на записи вы слышите обоих участников разговора, но оператор плохо слышит собеденика, значит проблема также в соединении между телефоном оператора и сервером '''Oktell'''. Необходимо проверить '''входящий интернет-трафик у оператора'''.
 +
 
 +
 
 +
=== Диагностика путем сравнения ===
 +
 
 +
В зависимости от проблемы выбираются различные варианты.
 +
 
 +
* Если проблема со звуком от внешнего абонента (провайдера связи), попробуйте подключить другого SIP-провайдера и совершите пробный звонок. Например, '''SipNet'''. Если звук появился, проблема в провайдере связи или в настройке соединения. Если нет, проблема в соединении или в настройке '''Oktell'''.
 +
 
 +
* Как вариант, для диагностики соединения с провайдером связи вы можете использовать любой софтфон, например X-lite и подключить его с теми же учетными данными, как и на сервере Oktell. Рекомендуется предварительно отключить эти линии в Администрирование/Карта сети. Позвоните на этот софтфон и проверьте слышимость голоса. Если звук есть, проблема в настройке Oktell, если нет - проблема в провайдере связи или в настройке соединения.
 +
 
 +
* Если проблема со звуком от оператора (пользователя Oktell), попробуйте подключить другой IP-телефон и совершить пробный звонок. Например, софтфон X-Lite. Если звук появился, проблема в телефоне. Если нет, проблема в соединении.
 +
 
 +
 
 +
=== Диагностика сниффером Wireshark===
 +
 
 +
[http://www.wireshark.org Wireshark] - программный инструмент для анализа сетевого трафика. С его помощью можно проанализировать RTP-пакеты, просмотреть работу SIP протокола, а также многое другое.
 +
 
 +
Запустим '''wireshark''', чтобы он сохранил все исходящие и входящие пакеты во время разговора. В главном окне необходимо выбрать раздел '''Interface List''' и выделить необходимый интерфейс. Далее нажмите на '''Options'''.
 +
 
 +
<center>[[Файл:Отсутствие звука -003.png |800px ]]</center>
 +
 
 +
 
 +
Раздел '''Capture Filter''' - называется '''фильтром захвата'''. '''Wireshark''' будет захватывать только те пакеты, которые указаны в этом фильтре. Если нажать непосредственно на саму кнопку '''Capture Filter''' вам будут показаны различные предустановленные варианты захвата. Нам понадобиться UDP-протокол, введите его в поле ввода.
 +
 
 +
udp
 +
 
 +
В этом окне также вы можете нажать '''Capture Files''' и выбрать в какой файл будут сохраняться результаты. Если поставить галочку '''Use multiple files''', то можно выбрать кольцевую схему сохранения, дробление файлов (например, по 200 мегабайт) и условие окончания захвата (например, после 1 гигабайта информации). После выбранных настроек нажмите кнопку '''Start'''.
 +
 
 +
[[Файл:Вайр03.PNG|center|500px]]
 +
 
 +
Вы увидите список всех пакетов которые пришли или отправились с сервера '''Oktell'''. Совершите тестовый звонок, затем остановите '''захват'''.
 +
 
 +
Далее воспользуемся еще одним типом фильтра - фильтром отображения. Распологается он в верхней части программы, рядом находится подпись "'''Filter'''". Введите один их запросов:
 +
 
 +
* '''rtp''' - показывает '''все rtp пакеты'''
 +
* '''ip.addr==192.168.0.81''' - показывает все пакеты '''с участием IP-адреса 192.168.0.81'''
 +
* '''ip.src==192.168.0.81''' - показывает все пакеты, у которых '''IP-адрес отправителя равен 192.168.0.81'''
 +
* '''ip.dst==192.168.0.81''' - показывает все пакеты, у которых '''IP-адрес получателя равен 192.168.0.81'''
 +
 
 +
Если ввести IP-адрес сервера, то вы можете увидеть пришли пакеты на сервер '''Oktell''' или нет. Если операторы используют гарнитуру, то Wireshark можно поставить на рабочее место пользователя и оценить поступление и отправку RTP-трафика.
 +
 
 +
<center>[[Файл:Отсутствие звука -004.png |800px ]]</center>
 +
 
 +
 
 +
'''Есть другой способ:''' выберите в меню '''Telephony''' -> '''VoIP Calls'''.
 +
 
 +
 
 +
<center>[[Файл:Отсутствие звука -005.png |1000px ]]</center>
 +
 
 +
 
 +
Выберите интересующую вас коммутацию и нажмите '''Flow'''. Если вы видите две стрелки RTP-трафика, значит трафик поступал в обе стороны. Если вы увидите только одну стрелку - вы поймете в какую сторону RTP-трафика не было.
 +
 
 +
 
 +
<center>[[Файл:Отсутствие звука -006.png |500px ]]</center>
 +
 
 +
 
 +
== Плохое качество звука ==
 +
 
 +
=== Возможные причины ===
 +
 
 +
Все проблемы с плохим качеством звука можно разделить на две категории:
 +
:1) пропадание во время разговора, потеря отдельных слов,фраз
 +
:2) эхо во время разговора
 +
 
 +
В подавляющем большинстве случаев проблемы со звуком — всегда '''сетевые проблемы'''. Любое искажение звука — это либо выпадение пакетов, либо задержка пакета в сети.
 +
 
 +
'''Возможные причины ухудшения звука:'''
 +
 
 +
'''1)''' В интернет-канале (интернет-провайдер) возникли проблемы, большая нагрузка. Это может быть плавающий пинг или просто нестабильность работы интернет-провайдера.
 +
 
 +
:'''1.1)''' Обратитесь к интернет-провайдеру. Возможно стоит запросить выделенный канал связи или попробовать поменять провайдера на другого
 +
 
 +
:'''1.2)''' Попробуйте поставить кодек меньшего качества, например, G.729. Пакеты данного кодека меньше по размеру, чем у G.711, возможно, они будут маршрутизироваться по-другому и качество улучшится.
 +
 
 +
'''2)''' В локальной сети возникли '''проблемы с NAT-устройством''' (роутер, маршрутизатор). Перезагрузите устройство.
 +
 
 +
'''3)''' Большая нагрузка сервера '''Oktell'''. На сервере производится резервное копирование данных, обрабатывается большой поток информации (актуально, если на рабочем сервере установлен не только '''Oktell''', а, например, сервер '''1С'''). Запустите диспетчер задач, '''проверьте нагрузку на процессор, озу'''.
 +
 
 +
'''4)''' '''Firewall (брандмауэр, антивирус)''' обнаружил большое количество пакетов и приостановил поток данных. Проверьте настройки Firewall.
 +
 
 +
<span style="color:red;"> ВНИМАНИЕ: Для проверки '''не рекомендуется''' отключать защиту системы в целях безопасности.
 +
 
 +
 
 +
'''5)''' Если вы используете виртуальную машину, используйте для нее сетевой интерфейс '''Virtio''', а не эмуляцию Intel или другую. Настройка производится в интерфейсе KVM.
 +
 
 +
 
 +
=== Диагностика с помощью статистики Oktell ===
 +
 
 +
Откройте '''Офис''' - '''Статистика АТС'''. Прослушайте запись разговора.
 +
 
 +
*Если на записи вы плохо слышите внешнего абонента, а голос оператора присутствует - проблема в соединении между провайдером телефонии и сервером '''Oktell'''. Необходимо проверить входящий трафик на сервере '''Oktell'''.
 +
 
 +
*Если на записи вы слышите только внешнего абонента, а голос оператора с искажениями - это обозначает что проблема в соединении между телефоном оператора и сервером '''Oktell'''. Необходимо проверить исходящий интернет-трафик у оператора.
 +
 
 +
*Если на записи вы слышите обоих участников разговора, но оператор плохо слышит собедника, значит проблема также в соединении между телефоном оператора и сервером '''Oktell'''. Необходимо проверить входящий интернет-трафик у оператора.
 +
 
 +
 
 +
=== Диагностика с помощью канального лога ===
 +
 
 +
Во время работы Oktell записывает статистику по каждому разговору в специализированный текстовый файл (лог-файл). Это помогает разобраться с поиском причин неисправности, локализовать и устранить проблему. Для выяснения причин понадобятся канальные логи.
 +
 
 +
Канальные логи располагаются в папке '''Server\Log\Hardware\Sip\[текущая дата]\[номер канала].log'''. Например, '''Server\Log\Hardware\Sip\2014-01-30\13003.log'''
 +
 
 +
В конце каждой коммутации, будь даже это коммутация с терминатором или с mp3-плеером, приводится статистика rtp-сессии: сколько пакетов/байтов отправлено, сколько получено, средний интервал, максимальный интервал между пакетами и т.д. Взглянув раз в этот журнал, станет понятно, где начинаются коммутации, где они заканчиваются, как разделять их друг от друга и как отличать проигрывание файлов от двунаправленного обмена.Понятно, что в зависимости от наблюдаемой информации следует принимать совершенно разные решения.
 +
 
 +
Статистика по коммутации приведена после фразы
 +
 
 +
10:53:04:739    4728  13003    -- ----------->  Raising async event: 'REC_STOP' param:'empty'
 +
 
 +
Ниже представлен пример канального лога со статистикой:
 +
 
 +
10:52:54:083    1368  13003    -- ----------->  MediaControl->StreamSignal REC_STARTED from stream rtp-audio-stream
 +
10:52:54:083    1368  13003    -- ----------->  Raising async event: 'REC_START' param:'empty'
 +
10:52:54:083    1368  13003    -- recording started
 +
10:52:54:083    4928  13003    -- ----------->  Raise Event 'REC_START' (5) param:'empty'
 +
10:52:54:084    4928  13003    -- ----------->  Event 'REC_START' raised
 +
10:52:54:096    4728  13003    -- Get fax capabilities : fax enabled true
 +
10:52:54:122    592  bas-strm -- stream rtp-audio-stream : increase new ts:4535216 diff 1200, time:150 ms, result 4536416
 +
10:52:54:180    2828  RTPS    -- stream rtp-audio-stream : received New ssrc_rx 837DC6B0
 +
10:53:04:623    4960  bas-strm --  WARNING :  stream rtp-audio-stream : unbind_peer main link while stream is started
 +
10:53:04:739    4728  13003    -- stop recording to file...
 +
10:53:04:739    4728  13003    -- ----------->  MediaControl->StreamSignal REC_STOPPED from stream rtp-audio-stream
 +
10:53:04:739    4728  13003    -- ----------->  Raising async event: 'REC_STOP' param:'empty'
 +
10:53:04:740    4728  rec      -- Final flush...
 +
10:53:04:740    4728  rec      -- Close file...
 +
10:53:04:740    4728  rtp-rec  -- Closeing file...
 +
10:53:04:742    4728  rtp-rec  -- File closed.
 +
10:53:04:742    4728  rec      -- File closed
 +
10:53:04:742    4728  13003    -- recording stopped
 +
10:53:04:742    4728  13003    -- unbind peer 16e001
 +
10:53:04:743    4728  13003    -- unbind trunk from 16e001...
 +
10:53:04:743    4728  13003    -- stop audio stream rtp-audio-stream
 +
10:53:04:743    4728  13003-0  -- Stop audio stream...
 +
10:53:04:743    4728  RTPS    -- ----------->  stream rtp-audio-stream : stopping : ssrc_rx:00000000 ssrc_tx:8376E2F0
 +
10:53:04:743    4728  RTPS    -- ----------->  stream rtp-audio-stream : stopped
 +
'''10:53:04:743    4728  bas-strm -- stream rtp-audio-stream : stream statistics:'''
 +
--OUT------------------
 +
packets sent    : 525
 +
bytes sent      : 90300
 +
delays          : 1
 +
max delay        : 129
 +
average delays  : 20
 +
--IN-------------------
 +
packets received : 521
 +
bytes received  : 89612
 +
out of order    : 0
 +
invalid          : 0
 +
lost            : 0
 +
delays          : 2
 +
max delay        : 188
 +
average delays  : 20
 +
 +
10:53:04:743    4728  13003-0  -- Audio stream stopped
 +
10:53:04:743    4728  13003-0  -- Connect audio terminator
 +
10:53:04:743    4728  RTPS    -- ----------->  stream rtp-audio-stream : RTP started ssrc_rx:00000000 ssrc_tx:8376E2F0
 +
10:53:04:743    4728  13003    -- trunk unbinded
 +
10:53:04:743    4728  13003    -- remove main sip call session 09393708...
 +
 
 +
'''Описание статистики:'''
 +
 
 +
* '''IN'''- входящий трафик от устройства (шлюза, телефона) на сервер '''Oktell'''.
 +
* '''OUT''' - исходящий трафик от сервера '''Oktell''' к устройству (шлюз, телефон)
 +
 +
*'''packets received''' - количество принятых пакетов.
 +
*'''bytes received''' - размер принятых пакетов.
 +
*'''out of order''' - количество пакетов, пришедших вне очереди. Если их много, то наблюдаются проблемы в сети.
 +
*'''invalid''' - количество неверных пакетов.
 +
*'''lost''' - количество потерянных пакетов. Если их много, то наблюдаются проблемы в сети.
 +
*'''delays''' - количество задержек во время коммутации. Проявляется как "заикание" (пропадание) голоса. Если их много, то наблюдаются проблемы в сети.
 +
*'''max delay''' - максимальная задержка. Чем больше, тем сильнее слышится "заикание".
 +
*'''average delays''' - средний период поступления RTP пакетов. Должен совпадать с размером звукового пакета используемого кодека: для G.711 это 20 мс.
 +
 
 +
 
 +
Канальные логи ведутся по '''внутренним''' и '''внешним''' линиям.
 +
* Если проблемы наблюдаются на '''внешней''' линии, значит проблема между провайдером и сервером '''Oktell'''.
 +
* Если проблемы наблюдаются на '''внутренней''' линии, значит проблема между сервером '''Oktell''' и оконечным устройством (телефоном, компьютером с гарнитурой).
  
  
−
Понадобится (может понадобиться) лог-журнал испытуемых каналов. То есть следует научиться провоцировать явление. Или придется держать включенным логирование голоса, что сильно увеличивает нагрузку на систему, и ждать проявления.
 
−
Голосовой лог журнал включается в разделе "Параметры аппаратуры. Конфигурация". Пункт "трассировка голосовых каналов". По умолчанию выключен. И настоятельно рекомендуется держать его выключенным все время, кроме тестов конкретно голосового направления. Как только определили, что ситуация состоялась - следует записать время и каналы, участвующие в битом коннекте. Канальные логи располагаются в папке Log\Hardware\Sip\[текущая дата]\[номер канала].log. В канальном логе в случае логирования голоса приводится полный список всех rtp данных. Пакет пришел, пакет ушел, сменился код источника, не нравится кодек, пакет отфильтрован, пакетов слишком много, пакетов слишком мало и т.д. В конце каждой коммутации, будь даже это коммутация с терминатором или с mp3-плеером, приводится статистика rtp-сессии: сколько пакетов/байтов отправлено, сколько получено, средний интервал, максимальный интервал между пакетами и т.д. Взглянув раз в этот журнал, станет понятно, где начинаются коммутации, где они заканчиваются, как разделять их друг от друга и как отличать проигрывание файлов от двунаправленного обмена.Понятно, что в зависимости от наблюдаемой информации следует принимать совершенно разные решения.
 
−
Понадобится (может понадобиться) лог журнал TRN (статистика всех SIP пакетов, прошедших через стандартный порт - 5060. ну или другой, если иное установлено в серверном конфиге или параметрах аппаратуры). Журнал включается в разделе "Параметры аппаратуры. Конфигурация". Пункт "трассировка пакетов SIP". Лог журнал вполне краток и информативен, чтобы держать его всегда включенным.Из него стоит выделить договоренности октелла со сторонним устройством (будь то провайдер или внутренний телефон) о параметрах организации вызова (SDP в пакетах серии INVITE - invite, 180 ringing, 183 progress, 200 ok, ack). Там (в sdp) упоминаются и кодеки, и направление активности звука, и порты, и много другого.Следует найти по времени и адресу интересующее соединение, запомнить call-id (заголовок, присутствующий в любом sip-пакете) и выделить по этому call-id все пакеты этой сессии. Там обнаружатся и INVITE с предлагаемой, и OK с уточняющей, и ACK с итоговой SDP информацией.
 
−
Другие лог журналы в отдельных случаях могут пригодиться, но при работе со звуком этому я выделю.. пожалуй менее 0,1%. Поэтому опускаю.
 
 
Вообще в разборе лог-журналов очень удобно использовать две программы для анализа:
 
Вообще в разборе лог-журналов очень удобно использовать две программы для анализа:
  
−
*- Notepad++. Он не только быстро грузит огромные файлы и шустро работает, но еще помогает вести подсчет, выделять цветом все обнаруженные присутствия указанного текстового блока (что как раз незаменимо при отслеживании пакетов по call-id, или исполняемых методов по номерам потоков или линий).для слежения  
+
*'''Notepad++'''. Он не только быстро грузит огромные файлы и шустро работает, но еще помогает вести подсчет, выделять цветом все обнаруженные присутствия указанного текстового блока (что как раз незаменимо при отслеживании пакетов по call-id, или исполняемых методов по номерам потоков или линий).Предназначен для слежения  
−
*- Far. Он умеет держать файлы открытыми и постоянно обновлять, не напрягая систему. Перемотал вниз, и сидишь следишь. Очень удобно в отдельных случаях. Также особо крупные файлы, не залезающие даже в Notepad++ (хотя я таких не видел), Far открывает сразу, ибо не грузит в память, а только отображает блоками.
+
*'''Far.''' Он умеет держать файлы открытыми и постоянно обновлять, не напрягая систему. Перемотал вниз, и сидишь следишь. Очень удобно в отдельных случаях. Также особо крупные файлы, не залезающие даже в Notepad++ (хотя я таких не видел), Far открывает сразу, ибо не грузит в память, а только отображает блоками.
 +
 
 +
 
 +
=== Диагностика с помощью Wireshark ===
 +
 
 +
Выше был рассмотрен захват пакетов данных, которые были получены/отправлены. '''Telephony-> Rtp-> Show all streams'''.
 +
 
 +
В столбце '''Lost''' будут определены потери '''RTP''' пакетов. Потери до 5% считаются допустимыми. С помощью столбцов '''Src IP addr''' и '''Dst IP addr''' вы сможете определить в какую сторону у вас идут потери - на входящий или исходящий трафик.
 +
 
 +
[[Файл:Вайр7.PNG|center|1000px]]
 +
 
 +
 
 +
 
 +
=== Диагностика с помощью программы NetTester===
 +
 
 +
Есть замечательная программа - '''NetTester''' . Запускается на одной машине, запускается на другой. Настраиваются друг на друга, обе стартуют. Можно придти через неделю и посмотреть, сколько пакетов в какую сторону потерялось, где были задержки, сколько серий потерь наблюдалось, сколько были размеры этих серий в пакетах и секундах.Идеальная связь предполагает идеальные каналы.
 +
 
 +
Программу нужно поставить на двух компьютерах, между которыми необходимо проверить интернет канал. На рисунке показана односторонняя проверка канала от '''192.168.0.81 (клиент)''' на '''192.168.0.82(сервер)'''. Можно настроить двусторонннюю проверку (оба компьютера настраиваются одновременно как клиент и сервер). Запуск программы рекомендуется производить вначале на сервере потом на клиенте, иначе будут потерянные пакеты из-за асинхронного запуска приложения.
 +
 
 +
'''Скачать NetTester:''' [http://wiki.oktell.ru/images/1/1d/NetTesterSharp.zip NetTester.zip]
 +
 
 +
 
 +
[[Файл:Отсутствие звука -007.png | 800px | center ]]
 +
 
 +
 
 +
 
 +
=== Диагностика с помощью программы WinMTR===
 +
 
 +
WinMTR - отличная программа для быстрой трассировки маршрута от локального компьютера до точки назначения. Трассировка маршрута выполняется отправкой пакетов с указанным периодом отправки. В процессе работы на экране выводятся имена всех узлов, процент потерь пакетов, минимальные и максимальные времена задержки.
 +
 
 +
Перед использованием настройте интервал отправки пакетов. Для этого нажмите '''Options''' и поставьте в поле ''Interval(sec)'' значение "0.1". Здесь же вы можете указать размер отправляемых пакетов в байтах, по умолчанию каждый пакет занимает 64 байта. Нажмите OK.
 +
 
 +
В поле ''Host'' введите адрес назначения пакетов, например, IP-адрес провайдера и нажмите '''Start'''.
 +
 
 +
'''Официальный сайт программы:''' http://winmtr.net/
 +
 
 +
'''Скачать WinMTR:''' [http://wiki.oktell.ru/images/6/6e/WinMTR-v092.zip WinMTR-v092.zip]
 +
 
 +
 
 +
[[Файл:Проблемы со звуком - 051.png|center|800px]]
 +
 
 +
 
 +
== Эхо в голосовых каналах ==
 +
 
  
 +
Отдельный вид проблем - появление эха в телефонной трубке удаленного абонента. Существует два основных источника появления эха:
  
−
== Метод сравнения. ==
+
'''1)''' Акустическое эхо -  возникает в телефонной трубке удаленного абонента, например, если он не держит ее у своей головы, пользуется громкой связью или, если сама телефонная трубка плохо спроектирована. При этом микрофон этого абонента может улавливать звуки идущие от наушника или спикера, и отражать их обратно в линию.  
  
 +
'''Рекомендации по устранению:''' уменьшить громкость в исходящем голосовом канале, если это позволяет оборудование.
  
−
Возьмите "хорошую" коммутацию и "плохую коммутацию" и просто сравните. Вы многое для себя откроете. Если окажется мало, то возьмите по две хороших и плохих. Далее методом индукции со включенной головой. Здесь было бы уместно поделиться опытом и вагоном тех ситуаций, которые возникали и еще не раз возникнут. Но так по каждому пункту, поэтому снова пропускаю.
 
  
−
'''Сниффер WireShark'''- отличная программа для анализа трафика. Одна проблема - все логи складирует в ОЗУ. Неисправность можно поймать, заставив его трассировать RTP трафик. На средне - нагруженном сервере снифферу хватит, чтобы загрузить оперативную память и перестать работать. Но задача в другом. Он умеет фильтровать sip пакеты, udp транспорт, rtp транспорт, что угодно и в каких угодно направлениях. У него целый класс фильтров, которые можно комбинировать. Из полученной им статистики можно попросить его выделить RTP потоки. Подпункт одного из пунктов меню "Streams->RTP". Это как раз те самые потоки UDP пакетов, несущих в себе голос, по 20-40 миллисекунд в каждом. Он в состоянии показать, сколько было за промежуток времени полноценных (начавшихся и закончившихся) rtp-потоков, насколько в них было все гладко, какая статистика пакетных данных - интервалов, последовательности номеров и т.д. Даже не досконально продуманный тест в wireshark способен уже показать многое. По крайней мере, сравнив его данные с голосовыми логами октелла, можно сделать вывод, потерялся/испортился звук за пределами сети, или в самом октелле. Очень интересный и удобный момент - rtp потоки можно даже прослушать! Подпункт меню "Voip calls".  
+
'''2)''' Гибридное эхо — возникает в точках перехода с цифровых транков на аналоговые двухпроводные, либо в точках перехода с четырехпроводных аналоговых транков на двухпроводные. В Oktell звук передается в цифровом виде, никаких модификаций звукового трафика не происходит, поэтому возникнуть эхо в данной точке не может.  
  
−
Рекомендуем прочесть статью [[http://wiki.oktell.ru/Плохая_слышимость_во_время_звонка._Потери_RTP_пакетов]]
+
'''Рекомендации по устранению:'''
  
 +
Для борьбы с эхо используется эхокомпенсатор. Обычно на шлюзах он включен. Однако есть особенность - эхокомпенсатор корректно работает только, если величина задержки незначительная и составляет 30-200 мс. При значительных задержках применение эхокомпенсатора неэффективно и может вызывать дополнительную задержку.
  
−
== Подозрения на связь ==
+
Исходя из этого, в процессе настройки шлюзов рекомендуется также провести тесты при отключенном эхокомпенсаторе.
  
  
−
Есть такая замечательная программка - NetTester . Запускается на одной машине, запускается на другой. Настраиваются друг на друга, обе стартуют. Можно придти через неделю и посмотреть, сколько пакетов в какую сторону потерялось, где были задержки, сколько серий потерь наблюдалось, сколько были размеры этих серий в пакетах и секундах.Идеальная связь предполагает идеальные каналы. Бывает иначе.
+
'''Метод диагностики:'''
  
−
Бинарный поиск всегда эффективнее полного перебора. Далее требуется несколько умозаключений. С опытом приходит понимание, какие из приведенных пунктов узловые, какие вспомогательные. Как правило руководствуясь коэффициентом полезность/трудозатраты. Разумеется, пытаться получать всю информацию сразу - бессмысленно. От характера проявления появляются подозрения и гипотезы. По ним выстраивается короткая серия тестов. По результатам формируются из оставшегося списка новые тесты/задачи. И напрямик к кочерыжке.Но чтобы суметь понять что важное, а что второстепенное (зависит от характера и проявления) - требуется опыт. Хотя бы небольшой. Который есть у технической поддержки и у части специалистов, в том числе сертифицированных в Телефонных Системах.
+
Если в разговоре присутствует эхо, то следует перезвонить абоненту по альтернативному каналу связи (SIP провайдер). Если эхо будет отсутствовать, то проблема на стыке оборудования на стороне конкретного провайдера связи. Если эхо присутствует, то проблема на стороне вызываемого абонента(громкая связь, некачественная аналоговая линия).
  
  
−
== С чего начать? ==
+
== Заключение ==
  
 +
Бинарный поиск всегда эффективнее полного перебора. Далее требуется несколько умозаключений. С опытом приходит понимание, какие из приведенных пунктов узловые, какие вспомогательные. Как правило руководствуясь коэффициентом полезность/трудозатраты. Разумеется, пытаться получать всю информацию сразу - бессмысленно. От характера проявления появляются подозрения и гипотезы. По ним выстраивается короткая серия тестов. По результатам формируются из оставшегося списка новые тесты/задачи. И напрямик к проблеме. Но чтобы суметь понять что важное, а что второстепенное (зависит от характера и проявления) - требуется опыт. Который есть у технической поддержки и у части специалистов, в том числе сертифицированных в '''Телефонных Системах'''.
  
−
Если вы никогда не были в логах, впервые услышали про сниффер, то конечно, надо начать с самого начала, и хотя бы раз пройти по всем пунктам. Дотошно и аккуратно. В том числе и по вопросо-тестам.При условии включенной головы и более или менее развитой логики одного раза может оказаться более чем достаточно, чтобы со второго перейти уже к методу прямого анализа.
+
'''В случае, если вы самостоятельно не можете разобраться с данной проблемой, обращайтесь в техническую поддержку Oktell.'''

Текущая версия на 06:31, 19 января 2015

Наверх


В данной статье рассматриваются проблемы, связанные с отсутствием звука или плохим качеством звука при соединении с абонентом.

Структурно телефония состоит из 2х компонентов:

1) Сигнализация - механизм, который отвечает за то, чтобы два абонента могли связаться между собой (найти друг друга, отправить вызов в трубку, начать коммутацию). В Oktell используется протокол SIP.

2) Передача медиа-трафика - механизм передачи звуковой информации (голоса). Механизм являет собой пакетную передачу данных: голос конвертируется в пакеты данных (RTP-пакеты), которые начинают передаваться от абонента А к абоненту Б через интернет.

В процессе передачи, пакеты данных могут теряться из-за плохого интернет соединения, испытывать задержки, не достичь конечного пункта из-за неправильной конфигурации.


Отсутствие звука

Возможные причины

Для определения причины требуется предварительная диагностика проблемы. О методах диагностики читайте ниже.

1. Удаленный медиа-сервер (сервер провайдера телефонии) не отправляет медиа-трафик. Проверить можно с помощью программы-сниффера WireShark.

1.1. Возможно коммутация не установлена на уровне SIP-сигнализации. Проверьте по логу trn (\Server\Log\Hardware\SIP\) наличие SIP-пакета "200 OK" по этой коммутации.

2. Медиа-трафик не поступает на сервер Oktell.

2.1. Удостоверьтесь, что порт 5060 на вашем сетевом интерфейсе прослушивается процессом oktell.HALRemoteApp.exe. Для этого в командной строке наберите команду 
netstat -anopb udp


Проблемы со звуком - 050.png


2.2. Проверьте, проброшены ли нужные порты на вашем NAT-устройстве. Воспользуйтесь статьей: Настройка работы сервера за NAT
2.3. Проверьте настройки брандмауэра (firewall). Перейдите Брандмауэр Windows -> Разрешить запуск программы или компонента через брандмауэр Windows -> Разрешить другую программу -> Обзор и выберите
  • \oktell\server\oktell.ServerService.exe
  • \oktell\server\oktell.HALRemoteApp.exe
ВНИМАНИЕ: Для проверки не рекомендуется отключать защиту системы в целях безопасности.
2.4. Перезагрузите сервер Oktell.


3. Медиа-трафик поступил на сервер Oktell, но не попал на телефон оператора. Из-за этого оператор не слышит внешнего абонента и думает, что звук отсутствует.

3.1. Если оператор использует клиентское приложение, убедитесь что в настройках локальных устройств выбраны действующие динамики и микрофон.
3.1. Если оператор находится в другой локальной сети за NAT (удаленный офис) - порты в удаленном офисе пробрасывать не нужно. Проверьте настройки роутера (например, установлено DMZ).
3.2. В настройках IP-телефона (или софтфона) размер звукового пакета должен быть установлен 20 мс (packet time)


Проблемы со звуком - 052.png


4. Прочее. Неправильная конфигурация сервера Oktell.

4.1. Перейдите в Администрирование->Параметры аппаратуры.
  • Настройки потока -> Адрес назначения для RTP трафика. Настройка нужна, если абонент не слышит оператора (то есть звук идет от Oktell). Попробуйте поменять эту настройку и посмотреть на результат.
  • Настройки потока -> Размер звукового пакета для кодека G.711 должен быть 20 мс.
ВНИМАНИЕ: Все телефоны сотрудников также должны иметь параметр ptime (размер звукового пакета) равный 20 мс.
  • Настройки потока -> Разрешить изменять параметры связи во время коммутации - рекомендуется установить Нет. Бывает, шлюзы/провайдеры не любят REINVITE инструкции, отправляемые с сервера. Хотя некоторые сами иной раз пользуются этим. Если выставлен запрет, Oktell включает транскодинг у себя, иначе может попросить внешний шлюз (считая его конечным аппаратным устройством) сменить кодек.
4.2. Кодеки. На время устранения проблем со звуком, рекомендуется установить единый кодек g.711a (или g.711u) во всех шлюзах и телефонах (в карте сети).


Отсутствие звука -001.png Отсутствие звука -002.png


4.3. Бывают случаи, когда отсутствует исходящий трафик от Oktell, при этом звонящий клиент не слышит оператора и IVR меню. Проблема часто заключается в обновлениях Windows, попробуйте удалить последние установленные обновления или вовсе отключить их. Для диагностики попробуйте выполнить команду ping или tracert в командной строке.


Диагностика в Oktell

Откройте Офис - Статистика АТС. Прослушайте запись разговора.

  • Если на записи вы не слышите внешнего абонента, а голос оператора присутствует - проблема в соединении между провайдером телефонии и сервером Oktell. Необходимо проверить входящий трафик на сервере Oktell.
  • Если на записи вы слышите только внешнего абонента, а голоса оператора нет - это обозначает что проблема в соединении между телефоном оператора и сервером Oktell. Необходимо проверить исходящий интернет-трафик у оператора.
  • Если на записи вы слышите обоих участников разговора, но оператор плохо слышит собеденика, значит проблема также в соединении между телефоном оператора и сервером Oktell. Необходимо проверить входящий интернет-трафик у оператора.


Диагностика путем сравнения

В зависимости от проблемы выбираются различные варианты.

  • Если проблема со звуком от внешнего абонента (провайдера связи), попробуйте подключить другого SIP-провайдера и совершите пробный звонок. Например, SipNet. Если звук появился, проблема в провайдере связи или в настройке соединения. Если нет, проблема в соединении или в настройке Oktell.
  • Как вариант, для диагностики соединения с провайдером связи вы можете использовать любой софтфон, например X-lite и подключить его с теми же учетными данными, как и на сервере Oktell. Рекомендуется предварительно отключить эти линии в Администрирование/Карта сети. Позвоните на этот софтфон и проверьте слышимость голоса. Если звук есть, проблема в настройке Oktell, если нет - проблема в провайдере связи или в настройке соединения.
  • Если проблема со звуком от оператора (пользователя Oktell), попробуйте подключить другой IP-телефон и совершить пробный звонок. Например, софтфон X-Lite. Если звук появился, проблема в телефоне. Если нет, проблема в соединении.


Диагностика сниффером Wireshark

Wireshark - программный инструмент для анализа сетевого трафика. С его помощью можно проанализировать RTP-пакеты, просмотреть работу SIP протокола, а также многое другое.

Запустим wireshark, чтобы он сохранил все исходящие и входящие пакеты во время разговора. В главном окне необходимо выбрать раздел Interface List и выделить необходимый интерфейс. Далее нажмите на Options.

Отсутствие звука -003.png


Раздел Capture Filter - называется фильтром захвата. Wireshark будет захватывать только те пакеты, которые указаны в этом фильтре. Если нажать непосредственно на саму кнопку Capture Filter вам будут показаны различные предустановленные варианты захвата. Нам понадобиться UDP-протокол, введите его в поле ввода. 

udp

В этом окне также вы можете нажать Capture Files и выбрать в какой файл будут сохраняться результаты. Если поставить галочку Use multiple files, то можно выбрать кольцевую схему сохранения, дробление файлов (например, по 200 мегабайт) и условие окончания захвата (например, после 1 гигабайта информации). После выбранных настроек нажмите кнопку Start.

Вайр03.PNG

Вы увидите список всех пакетов которые пришли или отправились с сервера Oktell. Совершите тестовый звонок, затем остановите захват.

Далее воспользуемся еще одним типом фильтра - фильтром отображения. Распологается он в верхней части программы, рядом находится подпись "Filter". Введите один их запросов:

  • rtp - показывает все rtp пакеты
  • ip.addr==192.168.0.81 - показывает все пакеты с участием IP-адреса 192.168.0.81
  • ip.src==192.168.0.81 - показывает все пакеты, у которых IP-адрес отправителя равен 192.168.0.81
  • ip.dst==192.168.0.81 - показывает все пакеты, у которых IP-адрес получателя равен 192.168.0.81

Если ввести IP-адрес сервера, то вы можете увидеть пришли пакеты на сервер Oktell или нет. Если операторы используют гарнитуру, то Wireshark можно поставить на рабочее место пользователя и оценить поступление и отправку RTP-трафика.

Отсутствие звука -004.png


Есть другой способ: выберите в меню Telephony -> VoIP Calls.


Отсутствие звука -005.png


Выберите интересующую вас коммутацию и нажмите Flow. Если вы видите две стрелки RTP-трафика, значит трафик поступал в обе стороны. Если вы увидите только одну стрелку - вы поймете в какую сторону RTP-трафика не было.


Отсутствие звука -006.png


Плохое качество звука

Возможные причины

Все проблемы с плохим качеством звука можно разделить на две категории:

1) пропадание во время разговора, потеря отдельных слов,фраз
2) эхо во время разговора

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

Возможные причины ухудшения звука:

1) В интернет-канале (интернет-провайдер) возникли проблемы, большая нагрузка. Это может быть плавающий пинг или просто нестабильность работы интернет-провайдера.

1.1) Обратитесь к интернет-провайдеру. Возможно стоит запросить выделенный канал связи или попробовать поменять провайдера на другого
1.2) Попробуйте поставить кодек меньшего качества, например, G.729. Пакеты данного кодека меньше по размеру, чем у G.711, возможно, они будут маршрутизироваться по-другому и качество улучшится.

2) В локальной сети возникли проблемы с NAT-устройством (роутер, маршрутизатор). Перезагрузите устройство.

3) Большая нагрузка сервера Oktell. На сервере производится резервное копирование данных, обрабатывается большой поток информации (актуально, если на рабочем сервере установлен не только Oktell, а, например, сервер 1С). Запустите диспетчер задач, проверьте нагрузку на процессор, озу.

4) Firewall (брандмауэр, антивирус) обнаружил большое количество пакетов и приостановил поток данных. Проверьте настройки Firewall.

ВНИМАНИЕ: Для проверки не рекомендуется отключать защиту системы в целях безопасности.


5) Если вы используете виртуальную машину, используйте для нее сетевой интерфейс Virtio, а не эмуляцию Intel или другую. Настройка производится в интерфейсе KVM.


Диагностика с помощью статистики Oktell

Откройте Офис - Статистика АТС. Прослушайте запись разговора.

  • Если на записи вы плохо слышите внешнего абонента, а голос оператора присутствует - проблема в соединении между провайдером телефонии и сервером Oktell. Необходимо проверить входящий трафик на сервере Oktell.
  • Если на записи вы слышите только внешнего абонента, а голос оператора с искажениями - это обозначает что проблема в соединении между телефоном оператора и сервером Oktell. Необходимо проверить исходящий интернет-трафик у оператора.
  • Если на записи вы слышите обоих участников разговора, но оператор плохо слышит собедника, значит проблема также в соединении между телефоном оператора и сервером Oktell. Необходимо проверить входящий интернет-трафик у оператора.


Диагностика с помощью канального лога

Во время работы Oktell записывает статистику по каждому разговору в специализированный текстовый файл (лог-файл). Это помогает разобраться с поиском причин неисправности, локализовать и устранить проблему. Для выяснения причин понадобятся канальные логи.

Канальные логи располагаются в папке Server\Log\Hardware\Sip\[текущая дата]\[номер канала].log. Например, Server\Log\Hardware\Sip\2014-01-30\13003.log

В конце каждой коммутации, будь даже это коммутация с терминатором или с mp3-плеером, приводится статистика rtp-сессии: сколько пакетов/байтов отправлено, сколько получено, средний интервал, максимальный интервал между пакетами и т.д. Взглянув раз в этот журнал, станет понятно, где начинаются коммутации, где они заканчиваются, как разделять их друг от друга и как отличать проигрывание файлов от двунаправленного обмена.Понятно, что в зависимости от наблюдаемой информации следует принимать совершенно разные решения.

Статистика по коммутации приведена после фразы 

10:53:04:739    4728  13003    -- ----------->  Raising async event: 'REC_STOP' param:'empty'

Ниже представлен пример канального лога со статистикой: 

10:52:54:083    1368  13003    -- ----------->  MediaControl->StreamSignal REC_STARTED from stream rtp-audio-stream
10:52:54:083    1368  13003    -- ----------->  Raising async event: 'REC_START' param:'empty'
10:52:54:083    1368  13003    -- recording started
10:52:54:083    4928  13003    -- ----------->  Raise Event 'REC_START' (5) param:'empty'
10:52:54:084    4928  13003    -- ----------->  Event 'REC_START' raised
10:52:54:096    4728  13003    -- Get fax capabilities : fax enabled true
10:52:54:122     592  bas-strm -- stream rtp-audio-stream : increase new ts:4535216 diff 1200, time:150 ms, result 4536416
10:52:54:180    2828  RTPS     -- stream rtp-audio-stream : received New ssrc_rx 837DC6B0
10:53:04:623    4960  bas-strm --  WARNING :  stream rtp-audio-stream : unbind_peer main link while stream is started
10:53:04:739    4728  13003    -- stop recording to file...
10:53:04:739    4728  13003    -- ----------->  MediaControl->StreamSignal REC_STOPPED from stream rtp-audio-stream
10:53:04:739    4728  13003    -- ----------->  Raising async event: 'REC_STOP' param:'empty'
10:53:04:740    4728  rec      -- Final flush...
10:53:04:740    4728  rec      -- Close file...
10:53:04:740    4728  rtp-rec  -- Closeing file...
10:53:04:742    4728  rtp-rec  -- File closed.
10:53:04:742    4728  rec      -- File closed
10:53:04:742    4728  13003    -- recording stopped
10:53:04:742    4728  13003    -- unbind peer 16e001
10:53:04:743    4728  13003    -- unbind trunk from 16e001...
10:53:04:743    4728  13003    -- stop audio stream rtp-audio-stream
10:53:04:743    4728  13003-0  -- Stop audio stream...
10:53:04:743    4728  RTPS     -- ----------->  stream rtp-audio-stream : stopping : ssrc_rx:00000000 ssrc_tx:8376E2F0 
10:53:04:743    4728  RTPS     -- ----------->  stream rtp-audio-stream : stopped
10:53:04:743    4728  bas-strm -- stream rtp-audio-stream : stream statistics:
			--OUT------------------
			packets sent     : 525
			bytes sent       : 90300
			delays           : 1
			max delay        : 129
			average delays   : 20
			--IN-------------------
			packets received : 521
			bytes received   : 89612
			out of order     : 0
			invalid          : 0
			lost             : 0
			delays           : 2
			max delay        : 188
			average delays   : 20

10:53:04:743    4728  13003-0  -- Audio stream stopped
10:53:04:743    4728  13003-0  -- Connect audio terminator
10:53:04:743    4728  RTPS     -- ----------->  stream rtp-audio-stream : RTP started ssrc_rx:00000000 ssrc_tx:8376E2F0
10:53:04:743    4728  13003    -- trunk unbinded
10:53:04:743    4728  13003    -- remove main sip call session 09393708...

Описание статистики:

  • IN- входящий трафик от устройства (шлюза, телефона) на сервер Oktell.
  • OUT - исходящий трафик от сервера Oktell к устройству (шлюз, телефон)
  • packets received - количество принятых пакетов.
  • bytes received - размер принятых пакетов.
  • out of order - количество пакетов, пришедших вне очереди. Если их много, то наблюдаются проблемы в сети.
  • invalid - количество неверных пакетов.
  • lost - количество потерянных пакетов. Если их много, то наблюдаются проблемы в сети.
  • delays - количество задержек во время коммутации. Проявляется как "заикание" (пропадание) голоса. Если их много, то наблюдаются проблемы в сети.
  • max delay - максимальная задержка. Чем больше, тем сильнее слышится "заикание".
  • average delays - средний период поступления RTP пакетов. Должен совпадать с размером звукового пакета используемого кодека: для G.711 это 20 мс.


Канальные логи ведутся по внутренним и внешним линиям.

  • Если проблемы наблюдаются на внешней линии, значит проблема между провайдером и сервером Oktell.
  • Если проблемы наблюдаются на внутренней линии, значит проблема между сервером Oktell и оконечным устройством (телефоном, компьютером с гарнитурой).


Вообще в разборе лог-журналов очень удобно использовать две программы для анализа:

  • Notepad++. Он не только быстро грузит огромные файлы и шустро работает, но еще помогает вести подсчет, выделять цветом все обнаруженные присутствия указанного текстового блока (что как раз незаменимо при отслеживании пакетов по call-id, или исполняемых методов по номерам потоков или линий).Предназначен для слежения
  • Far. Он умеет держать файлы открытыми и постоянно обновлять, не напрягая систему. Перемотал вниз, и сидишь следишь. Очень удобно в отдельных случаях. Также особо крупные файлы, не залезающие даже в Notepad++ (хотя я таких не видел), Far открывает сразу, ибо не грузит в память, а только отображает блоками.


Диагностика с помощью Wireshark

Выше был рассмотрен захват пакетов данных, которые были получены/отправлены. Telephony-> Rtp-> Show all streams.

В столбце Lost будут определены потери RTP пакетов. Потери до 5% считаются допустимыми. С помощью столбцов Src IP addr и Dst IP addr вы сможете определить в какую сторону у вас идут потери - на входящий или исходящий трафик.

Вайр7.PNG


Диагностика с помощью программы NetTester

Есть замечательная программа - NetTester . Запускается на одной машине, запускается на другой. Настраиваются друг на друга, обе стартуют. Можно придти через неделю и посмотреть, сколько пакетов в какую сторону потерялось, где были задержки, сколько серий потерь наблюдалось, сколько были размеры этих серий в пакетах и секундах.Идеальная связь предполагает идеальные каналы.

Программу нужно поставить на двух компьютерах, между которыми необходимо проверить интернет канал. На рисунке показана односторонняя проверка канала от 192.168.0.81 (клиент) на 192.168.0.82(сервер). Можно настроить двусторонннюю проверку (оба компьютера настраиваются одновременно как клиент и сервер). Запуск программы рекомендуется производить вначале на сервере потом на клиенте, иначе будут потерянные пакеты из-за асинхронного запуска приложения.

Скачать NetTester: NetTester.zip


Отсутствие звука -007.png


Диагностика с помощью программы WinMTR

WinMTR - отличная программа для быстрой трассировки маршрута от локального компьютера до точки назначения. Трассировка маршрута выполняется отправкой пакетов с указанным периодом отправки. В процессе работы на экране выводятся имена всех узлов, процент потерь пакетов, минимальные и максимальные времена задержки.

Перед использованием настройте интервал отправки пакетов. Для этого нажмите Options и поставьте в поле Interval(sec) значение "0.1". Здесь же вы можете указать размер отправляемых пакетов в байтах, по умолчанию каждый пакет занимает 64 байта. Нажмите OK.

В поле Host введите адрес назначения пакетов, например, IP-адрес провайдера и нажмите Start.

Официальный сайт программы: http://winmtr.net/

Скачать WinMTR: WinMTR-v092.zip


Проблемы со звуком - 051.png


Эхо в голосовых каналах

Отдельный вид проблем - появление эха в телефонной трубке удаленного абонента. Существует два основных источника появления эха:

1) Акустическое эхо - возникает в телефонной трубке удаленного абонента, например, если он не держит ее у своей головы, пользуется громкой связью или, если сама телефонная трубка плохо спроектирована. При этом микрофон этого абонента может улавливать звуки идущие от наушника или спикера, и отражать их обратно в линию.

Рекомендации по устранению: уменьшить громкость в исходящем голосовом канале, если это позволяет оборудование.


2) Гибридное эхо — возникает в точках перехода с цифровых транков на аналоговые двухпроводные, либо в точках перехода с четырехпроводных аналоговых транков на двухпроводные. В Oktell звук передается в цифровом виде, никаких модификаций звукового трафика не происходит, поэтому возникнуть эхо в данной точке не может.

Рекомендации по устранению:

Для борьбы с эхо используется эхокомпенсатор. Обычно на шлюзах он включен. Однако есть особенность - эхокомпенсатор корректно работает только, если величина задержки незначительная и составляет 30-200 мс. При значительных задержках применение эхокомпенсатора неэффективно и может вызывать дополнительную задержку.

Исходя из этого, в процессе настройки шлюзов рекомендуется также провести тесты при отключенном эхокомпенсаторе.


Метод диагностики:

Если в разговоре присутствует эхо, то следует перезвонить абоненту по альтернативному каналу связи (SIP провайдер). Если эхо будет отсутствовать, то проблема на стыке оборудования на стороне конкретного провайдера связи. Если эхо присутствует, то проблема на стороне вызываемого абонента(громкая связь, некачественная аналоговая линия).


Заключение

Бинарный поиск всегда эффективнее полного перебора. Далее требуется несколько умозаключений. С опытом приходит понимание, какие из приведенных пунктов узловые, какие вспомогательные. Как правило руководствуясь коэффициентом полезность/трудозатраты. Разумеется, пытаться получать всю информацию сразу - бессмысленно. От характера проявления появляются подозрения и гипотезы. По ним выстраивается короткая серия тестов. По результатам формируются из оставшегося списка новые тесты/задачи. И напрямик к проблеме. Но чтобы суметь понять что важное, а что второстепенное (зависит от характера и проявления) - требуется опыт. Который есть у технической поддержки и у части специалистов, в том числе сертифицированных в Телефонных Системах.

В случае, если вы самостоятельно не можете разобраться с данной проблемой, обращайтесь в техническую поддержку Oktell.

Источник — «https://wiki.oktell.ru/index.php?title=Проблемы_со_звуком&oldid=11458»