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

Версия 12:53, 15 июля 2013

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

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

Часть первая. Сбор информации.

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

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

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

Кто виноват?

Виноват либо октелл, либо провайдер, либо шлюз/телефон, либо внедренец. Вполне очевидно.

Что делать?

Ответить на вопрос, в чем главная задача (то бишь выбрать)

• а) найти самое быстрое решение,
• б) найти самое дешевое решение,
• в) во что бы то ни стало заставить работать именно в текущей комбинации.

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

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

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

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

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

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

С чего начать?

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

Что дальше?

В дальнейшем постараюсь описать варианты и подробности, а также выводы, которые следует производить из каждого пункта. На текущий момент, мне кажется, приведенная поверхностная информация избыточна для проведения первых мытарств, без которых идти дальше бессмысленно. А с ними некоторым уже и подробности не будут особо нужны.Если упорно не получается вникнуть и решить проблему - повод воспользоваться чужим опытом. Если упорно не получается от раза к разу, стоит бросать это дело как безнадежно неэффективное. Конечно, есть вещи, над которыми надо ломать голову и уже собаку съевшим специалистам. Что тут скажешь, побольше нам интересных задач. И чаще надо общаться. Приезжайте на семинары, рассказывайте о своих находках, задавайте вопросы, слушайте сказки из нашей жизни.Вот такая вот арифметика голосовая.