Проблемы со звуком

Наверх

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

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

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

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

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

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

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

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

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

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

2.1. Проверьте, проброшены ли нужные порты на вашем NAT-устройстве. Воспользуйтесь статьей: Настройка работы сервера за NAT

2.2. Проверьте настройки брандмауэра (firewall). Перейдите Брандмауэр Windows -> Разрешить запуск программы или компонента через брандмауэр Windows -> Разрешить другую программу -> Обзор и выберите

• \oktell\server\oktell.ServerService.exe
• \oktell\server\oktell.HALRemoteApp.exe

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

2.3. Перезагрузите сервер Oktell.

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

3.1. Если оператор находится в другой локальной сети за NAT (удаленный офис) - порты пробрасывать не нужно. Проверьте настройки роутера (например, установлено DMZ).

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

4.1. Перейдите в Администрирование->Параметры аппаратуры.

• Настройки потока -> Адрес назначения для RTP трафика. Настройка нужна, если абонент не слышит оператора (то есть звук идет от Oktell). Попробуйте поменять эту настройку и посмотреть на результат.

• Настройки потока -> Разрешить изменять параметры связи во время коммутации - рекомендуется установить Нет. Бывает, шлюзы/провайдеры не любят REINVITE инструкции, отправляемые с сервера. Хотя некоторые сами иной раз пользуются этим. Если выставлен запрет, Oktell включает транскодинг у себя, иначе может попросить внешний шлюз (считая его конечным аппаратным устройством) сменить кодек.

4.2. Кодеки. На время устранения проблем со звуком, рекомендуется установить единый кодек g.711a (или g.711u) во всех шлюзах и телефонах (в карте сети).

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

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

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

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

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

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

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

• Если проблема со звуком от внешнего абонента, попробуйте подключить другого SIP-провайдера и совершите пробный звонок. Например, SipNet. Если звук появился, проблема в провайдере или в настройке соединения. Если нет, проблема в соединении или в настройке Oktell.

• Если проблема со звуком от оператора, попробуйте подключить другой IP-телефон и совершить пробный звонок. Например, софтфон X-Lite. Если звук появился, проблема в телефоне. Если нет, проблема в соединении.

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

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

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

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

udp

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

Вы увидите список всех пакетов которые пришли или отправились с сервера 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-трафика.

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

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

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

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

Проблемы со звуком — всегда сетевые проблемы. Любое искажение звука — это либо выпадение пакетов, либо задержка пакета в сети.

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

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

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

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

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

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

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

Во время работы 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 - размер принятых пакетов. Отношение packets received/bytes received должно быть близко к 20.
• out of order - количество пакетов, пришедших вне очереди.
• invalid - количество неверных пакетов.
• lost - количество потерянных пакетов. Если их много, то наблюдаются проблемы в сети.
• delays - количество задержек во время коммутации. Проявляется как "заикание" (пропадание) голоса. Если их много, то наблюдаются проблемы в сети.
• max delay - максимальная задержка. Чем больше, тем сильнее слышится "заикание".
• average delays - средняя ширина RTP-пакета. У качественной связи должно быть 20 мс.

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

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

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

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

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

Выше был рассмотрен захват пакетов данных, которые были получены/отправлены. Telephony-> Rtp-> Show all streams. Проверьте что у вас будут две строки, а один из портов будет совпадать с тем, что мы нашли в канальном логе на шаге 1. В столбце Lost будут определены потери RTP пакетов. Потери до 5% считаются допустимыми. С помощью этой информации вы можете определить в какую сторону у вас идут потери - на входящий или исходящий трафик.

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

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

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

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