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

Версия 06:50, 30 января 2014

Наверх

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

Структурно телефония состоит из 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.

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

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

Понадобится (может понадобиться) лог-журнал испытуемых каналов. То есть следует научиться провоцировать явление. Или придется держать включенным логирование голоса, что сильно увеличивает нагрузку на систему, и ждать проявления. Голосовой лог журнал включается в разделе "Параметры аппаратуры. Конфигурация". Пункт "трассировка голосовых каналов". По умолчанию выключен. И настоятельно рекомендуется держать его выключенным все время, кроме тестов конкретно голосового направления. Как только определили, что ситуация состоялась - следует записать время и каналы, участвующие в битом коннекте. Канальные логи располагаются в папке 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, или исполняемых методов по номерам потоков или линий).для слежения
• - Far. Он умеет держать файлы открытыми и постоянно обновлять, не напрягая систему. Перемотал вниз, и сидишь следишь. Очень удобно в отдельных случаях. Также особо крупные файлы, не залезающие даже в Notepad++ (хотя я таких не видел), Far открывает сразу, ибо не грузит в память, а только отображает блоками.

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

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

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

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

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

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