Проблемы со звуком
В данной статье рассматриваются проблемы, связанные с отсутствием звука или плохим качеством звука при соединении с абонентом.
Структурно телефония состоит из 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.
