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

Наверх

Если звук есть, то все хорошо. А что делать, если звука нет? Или есть, но не такой какой должен.

Существует большое количество возможностей, как определить и наладить. В любом случае начинается все с диагностики. Статья призвана облегчить и уменьшить объем работ технической поддержке. Чаще всего диагностика требует времени именно на проведение рутинных мероприятий. Умозаключениям там отведено довольно малое и довольно редкое место. Речь конечно же идет о SIP.

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

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

• 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.