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

Материал из Oktell
Перейти к: навигация, поиск

Наверх


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

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

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

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

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


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


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

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


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

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


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

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


  • - Другой провайдер. Попробуйте SipNet.

Симптомы и расширения.

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

  • 1. Связана ли проблема со звонками к/от провайдера, только ли в таких звонках наблюдается проблема. Если речь идет не о полном отсутствии, то какой характер порчи звука
    • а) выпадение пакетов (щелчки)
    • б) выпадение серий пакетов (потеря слов)
    • в) плавание звука (перемешивание пакетов)
    • г) постоянно некачественный голос) абсолютно левый звук (свист, "водичка")
    • е) периодические искажения
    • ж) полное остутствие звука в одном из направлений или в обоих направлениях
  • 2. В каких направлениях наблюдается эффект
    • а) в обоих (и я слышу плохо, и абонент слышит плохо)
    • б) только в одном (я слышу плохо, абонент слышит хорошо)
    • в) только в одном (я слышу хорошо, абонент слышит плохо)
  • 3. При каких звонках нет звука
    • а) при входящих
    • б) при исходящих
  • 4. В каких медиа-направлениях наблюдается проблема
    • а) sip-cti
    • б) sip-usb
    • в) внешний sip - внешний sip
    • г) внутренний sip- внутренний sip
    • д) внешний sip - внутренний sip
  • 5. Стабильно ли проявляется проблема в обнаруженном направлении/комбинации.
  • 6. Если в наличии много проблем, то следует попытаться найти комбинацию, в которой звук нормальный. Это поможет вывести из-под подозрения сразу целые блоки. А также сравнить окружение у хорошего и плохого звонков.
  • 7. Каким образом происходит соединение
    • а) через сценарий путем внешнего переключения с выбранным режимом "коммутация сразу"
    • б) через сценарий путем внешнего переключения с выбранным режимом "прослушивание медиа-потока"
    • в) вне зависимости от способа коммутации, и даже звонки на внутренние.

Немного о настройках

Могут пригодиться. Администрирование->Параметры аппаратуры. Часть настроек в разделе SIP-сервер, часть у шлюзов, большинство у потоков (аккаунтов).

  • - Отсылать пакеты на адрес отправителя (взамен указанным в SDP данным). Чаще всего используется при работе с провайдером через NAT. Не все провайдеры поддерживают такую настройку, но некоторые изначально работают именно так, некоторые по просьбе включают, некоторые не могут или не хотят. До поры реализации обхода NAT в самом Oktell, разбираться приходится внешним образом в зависимости от ситуации. В том числе можно использовать и прямые шлюзы. Выносить сервер на белый адрес не очень хорошо, но тоже действует. Не забыть только при этом спам-фильтр активировать.
  • - Запретить изменение параметров соединения на лету. Бывает, шлюзы/провайдеры не любят REINVITE инструкции, отправляемые с сервера. Хотя некоторые сами иной раз пользуются этим. Если выставлен запрет, октелл включает транскодинг у себя, иначе может попросить внешний шлюз (считая его конечным аппаратным устройством) сменить кодек.
  • - Кодеки. Вопросы сжатия актуальны на полностью рабочей системе. А для начала ограничить все одним базовым кодеком, g.711а (или g.711u). И шлюзы в октелле, и телефоны используемые. Исключить из подозрения вплоть до решения проблемы.
  • - Другой провайдер. Попробуйте SipNet.


Лог журналы.

Понадобится (может понадобиться) лог-журнал испытуемых каналов. То есть следует научиться провоцировать явление. Или придется держать включенным логирование голоса, что сильно увеличивает нагрузку на систему, и ждать проявления. Голосовой лог журнал включается в разделе "Параметры аппаратуры. Конфигурация". Пункт "трассировка голосовых каналов". По умолчанию выключен. И настоятельно рекомендуется держать его выключенным все время, кроме тестов конкретно голосового направления. Как только определили, что ситуация состоялась - следует записать время и каналы, участвующие в битом коннекте. Канальные логи располагаются в папке 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- отличная программа для анализа трафика. Одна проблема - все логи складирует в ОЗУ. Неисправность можно поймать, заставив его трассировать RTP трафик. На средне - нагруженном сервере снифферу хватит, чтобы загрузить оперативную память и перестать работать. Но задача в другом. Он умеет фильтровать sip пакеты, udp транспорт, rtp транспорт, что угодно и в каких угодно направлениях. У него целый класс фильтров, которые можно комбинировать. Из полученной им статистики можно попросить его выделить RTP потоки. Подпункт одного из пунктов меню "Streams->RTP". Это как раз те самые потоки UDP пакетов, несущих в себе голос, по 20-40 миллисекунд в каждом. Он в состоянии показать, сколько было за промежуток времени полноценных (начавшихся и закончившихся) rtp-потоков, насколько в них было все гладко, какая статистика пакетных данных - интервалов, последовательности номеров и т.д. Даже не досконально продуманный тест в wireshark способен уже показать многое. По крайней мере, сравнив его данные с голосовыми логами октелла, можно сделать вывод, потерялся/испортился звук за пределами сети, или в самом октелле. Очень интересный и удобный момент - rtp потоки можно даже прослушать! Подпункт меню "Voip calls".

Рекомендуем прочесть статью Плохая слышимость во время звонка. Потери RTP пакетов


Подозрения на связь

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

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

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