Проблемы со звуком — различия между версиями
(→Отсутствие звука) |
|||
| Строка 12: | Строка 12: | ||
== Отсутствие звука == | == Отсутствие звука == | ||
| − | Возможные причины | + | ===Возможные причины=== |
| + | Для определения причины требуется предварительная диагностика проблемы. О методах диагностики читайте ниже. | ||
'''1.''' Удаленный медиа-сервер (сервер провайдера телефонии) не отправляет медиа-трафик. Проверить можно с помощью '''WireShark'''. | '''1.''' Удаленный медиа-сервер (сервер провайдера телефонии) не отправляет медиа-трафик. Проверить можно с помощью '''WireShark'''. | ||
| Строка 43: | Строка 44: | ||
*- Другой провайдер. Попробуйте SipNet. | *- Другой провайдер. Попробуйте SipNet. | ||
| − | == | + | === Диагностика в Oktell === |
| − | |||
| − | + | === Диагностика сниффером Wireshark=== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | '''Сниффер WireShark'''- отличная программа для анализа трафика. Одна проблема - все логи складирует в ОЗУ. Неисправность можно поймать, заставив его трассировать RTP трафик. На средне - нагруженном сервере снифферу хватит, чтобы загрузить оперативную память и перестать работать. Но задача в другом. Он умеет фильтровать sip пакеты, udp транспорт, rtp транспорт, что угодно и в каких угодно направлениях. У него целый класс фильтров, которые можно комбинировать. Из полученной им статистики можно попросить его выделить RTP потоки. Подпункт одного из пунктов меню "Streams->RTP". Это как раз те самые потоки UDP пакетов, несущих в себе голос, по 20-40 миллисекунд в каждом. Он в состоянии показать, сколько было за промежуток времени полноценных (начавшихся и закончившихся) rtp-потоков, насколько в них было все гладко, какая статистика пакетных данных - интервалов, последовательности номеров и т.д. Даже не досконально продуманный тест в wireshark способен уже показать многое. По крайней мере, сравнив его данные с голосовыми логами октелла, можно сделать вывод, потерялся/испортился звук за пределами сети, или в самом октелле. Очень интересный и удобный момент - rtp потоки можно даже прослушать! Подпункт меню "Voip calls". | |
| + | Рекомендуем прочесть статью [[Плохая_слышимость_во_время_звонка._Потери_RTP_пакетов | Плохая слышимость во время звонка. Потери RTP пакетов]] | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| + | === Диагностика с помощью канального лога === | ||
Понадобится (может понадобиться) лог-журнал испытуемых каналов. То есть следует научиться провоцировать явление. Или придется держать включенным логирование голоса, что сильно увеличивает нагрузку на систему, и ждать проявления. | Понадобится (может понадобиться) лог-журнал испытуемых каналов. То есть следует научиться провоцировать явление. Или придется держать включенным логирование голоса, что сильно увеличивает нагрузку на систему, и ждать проявления. | ||
| Строка 98: | Строка 66: | ||
*- Far. Он умеет держать файлы открытыми и постоянно обновлять, не напрягая систему. Перемотал вниз, и сидишь следишь. Очень удобно в отдельных случаях. Также особо крупные файлы, не залезающие даже в Notepad++ (хотя я таких не видел), Far открывает сразу, ибо не грузит в память, а только отображает блоками. | *- Far. Он умеет держать файлы открытыми и постоянно обновлять, не напрягая систему. Перемотал вниз, и сидишь следишь. Очень удобно в отдельных случаях. Также особо крупные файлы, не залезающие даже в Notepad++ (хотя я таких не видел), Far открывает сразу, ибо не грузит в память, а только отображает блоками. | ||
| − | + | === Диагностика с помощью программы NetTester=== | |
| − | == | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
Есть замечательная программа - NetTester . Запускается на одной машине, запускается на другой. Настраиваются друг на друга, обе стартуют. Можно придти через неделю и посмотреть, сколько пакетов в какую сторону потерялось, где были задержки, сколько серий потерь наблюдалось, сколько были размеры этих серий в пакетах и секундах.Идеальная связь предполагает идеальные каналы. Бывает иначе. | Есть замечательная программа - NetTester . Запускается на одной машине, запускается на другой. Настраиваются друг на друга, обе стартуют. Можно придти через неделю и посмотреть, сколько пакетов в какую сторону потерялось, где были задержки, сколько серий потерь наблюдалось, сколько были размеры этих серий в пакетах и секундах.Идеальная связь предполагает идеальные каналы. Бывает иначе. | ||
Версия 10:39, 29 января 2014
В данной статье рассматриваются проблемы, связанные с отсутствием звука или плохим качеством звука при соединении с абонентом.
Структурно телефония состоит из 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.
Диагностика в Oktell
Диагностика сниффером Wireshark
Сниффер WireShark- отличная программа для анализа трафика. Одна проблема - все логи складирует в ОЗУ. Неисправность можно поймать, заставив его трассировать RTP трафик. На средне - нагруженном сервере снифферу хватит, чтобы загрузить оперативную память и перестать работать. Но задача в другом. Он умеет фильтровать sip пакеты, udp транспорт, rtp транспорт, что угодно и в каких угодно направлениях. У него целый класс фильтров, которые можно комбинировать. Из полученной им статистики можно попросить его выделить RTP потоки. Подпункт одного из пунктов меню "Streams->RTP". Это как раз те самые потоки UDP пакетов, несущих в себе голос, по 20-40 миллисекунд в каждом. Он в состоянии показать, сколько было за промежуток времени полноценных (начавшихся и закончившихся) rtp-потоков, насколько в них было все гладко, какая статистика пакетных данных - интервалов, последовательности номеров и т.д. Даже не досконально продуманный тест в wireshark способен уже показать многое. По крайней мере, сравнив его данные с голосовыми логами октелла, можно сделать вывод, потерялся/испортился звук за пределами сети, или в самом октелле. Очень интересный и удобный момент - rtp потоки можно даже прослушать! Подпункт меню "Voip calls".
Рекомендуем прочесть статью Плохая слышимость во время звонка. Потери RTP пакетов
Диагностика с помощью канального лога
Понадобится (может понадобиться) лог-журнал испытуемых каналов. То есть следует научиться провоцировать явление. Или придется держать включенным логирование голоса, что сильно увеличивает нагрузку на систему, и ждать проявления. Голосовой лог журнал включается в разделе "Параметры аппаратуры. Конфигурация". Пункт "трассировка голосовых каналов". По умолчанию выключен. И настоятельно рекомендуется держать его выключенным все время, кроме тестов конкретно голосового направления. Как только определили, что ситуация состоялась - следует записать время и каналы, участвующие в битом коннекте. Канальные логи располагаются в папке 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 открывает сразу, ибо не грузит в память, а только отображает блоками.
Диагностика с помощью программы NetTester
Есть замечательная программа - NetTester . Запускается на одной машине, запускается на другой. Настраиваются друг на друга, обе стартуют. Можно придти через неделю и посмотреть, сколько пакетов в какую сторону потерялось, где были задержки, сколько серий потерь наблюдалось, сколько были размеры этих серий в пакетах и секундах.Идеальная связь предполагает идеальные каналы. Бывает иначе.
Бинарный поиск всегда эффективнее полного перебора. Далее требуется несколько умозаключений. С опытом приходит понимание, какие из приведенных пунктов узловые, какие вспомогательные. Как правило руководствуясь коэффициентом полезность/трудозатраты. Разумеется, пытаться получать всю информацию сразу - бессмысленно. От характера проявления появляются подозрения и гипотезы. По ним выстраивается короткая серия тестов. По результатам формируются из оставшегося списка новые тесты/задачи. И напрямик к проблеме. Но чтобы суметь понять что важное, а что второстепенное (зависит от характера и проявления) - требуется опыт. Который есть у технической поддержки и у части специалистов, в том числе сертифицированных в Телефонных Системах.
В случае, если вы самостоятельно не можете разобраться с данной проблемой, обращайтесь в техническую поддержку Oktell.
