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

Текущая версия на 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

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)

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

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

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

• Настройки потока -> Размер звукового пакета для кодека G.711 должен быть 20 мс.

ВНИМАНИЕ: Все телефоны сотрудников также должны иметь параметр ptime (размер звукового пакета) равный 20 мс.

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

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

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.

Раздел 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) эхо во время разговора

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

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

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 вы сможете определить в какую сторону у вас идут потери - на входящий или исходящий трафик.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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