Проблемы со звуком — различия между версиями
(→Возможные причины) |
(→Плохое качество звука) |
||
| Строка 137: | Строка 137: | ||
<span style="color:red;"> ВНИМАНИЕ: Для проверки не рекомендуется отключать защиту системы в целях безопасности. | <span style="color:red;"> ВНИМАНИЕ: Для проверки не рекомендуется отключать защиту системы в целях безопасности. | ||
| + | |||
=== Диагностика с помощью канального лога === | === Диагностика с помощью канального лога === | ||
| − | + | Во время работы Oktell записывает статистику по каждому разговору в специализированный текстовый файл (лог-файл). Это помогает разобраться с поиском причин неисправности, локализовать и устранить проблему. Для выяснения причин понадобятся канальные логи. | |
| − | + | ||
| − | + | Канальные логи располагаются в папке '''Server\Log\Hardware\Sip\[текущая дата]\[номер канала].log'''. Например, '''Server\Log\Hardware\Sip\2014-01-30\13003.log''' | |
| − | + | ||
| + | 10:52:54:083 1368 13003 -- -----------> MediaControl->StreamSignal REC_STARTED from stream rtp-audio-stream | ||
| + | 10:52:54:083 1368 13003 -- -----------> Raising async event: 'REC_START' param:'empty' | ||
| + | 10:52:54:083 1368 13003 -- recording started | ||
| + | 10:52:54:083 4928 13003 -- -----------> Raise Event 'REC_START' (5) param:'empty' | ||
| + | 10:52:54:084 4928 13003 -- -----------> Event 'REC_START' raised | ||
| + | 10:52:54:096 4728 13003 -- Get fax capabilities : fax enabled true | ||
| + | 10:52:54:122 592 bas-strm -- stream rtp-audio-stream : increase new ts:4535216 diff 1200, time:150 ms, result 4536416 | ||
| + | 10:52:54:180 2828 RTPS -- stream rtp-audio-stream : received New ssrc_rx 837DC6B0 | ||
| + | 10:53:04:623 4960 bas-strm -- WARNING : stream rtp-audio-stream : unbind_peer main link while stream is started | ||
| + | 10:53:04:739 4728 13003 -- stop recording to file... | ||
| + | 10:53:04:739 4728 13003 -- -----------> MediaControl->StreamSignal REC_STOPPED from stream rtp-audio-stream | ||
| + | 10:53:04:739 4728 13003 -- -----------> Raising async event: 'REC_STOP' param:'empty' | ||
| + | 10:53:04:740 4728 rec -- Final flush... | ||
| + | 10:53:04:740 4728 rec -- Close file... | ||
| + | 10:53:04:740 4728 rtp-rec -- Closeing file... | ||
| + | 10:53:04:742 4728 rtp-rec -- File closed. | ||
| + | 10:53:04:742 4728 rec -- File closed | ||
| + | 10:53:04:742 4728 13003 -- recording stopped | ||
| + | 10:53:04:742 4728 13003 -- unbind peer 16e001 | ||
| + | 10:53:04:743 4728 13003 -- unbind trunk from 16e001... | ||
| + | 10:53:04:743 4728 13003 -- stop audio stream rtp-audio-stream | ||
| + | 10:53:04:743 4728 13003-0 -- Stop audio stream... | ||
| + | 10:53:04:743 4728 RTPS -- -----------> stream rtp-audio-stream : stopping : ssrc_rx:00000000 ssrc_tx:8376E2F0 | ||
| + | 10:53:04:743 4728 RTPS -- -----------> stream rtp-audio-stream : stopped | ||
| + | 10:53:04:743 4728 bas-strm -- stream rtp-audio-stream : stream statistics: | ||
| + | --OUT------------------ | ||
| + | packets sent : 525 | ||
| + | bytes sent : 90300 | ||
| + | delays : 1 | ||
| + | max delay : 129 | ||
| + | average delays : 20 | ||
| + | --IN------------------- | ||
| + | packets received : 521 | ||
| + | bytes received : 89612 | ||
| + | out of order : 0 | ||
| + | invalid : 0 | ||
| + | lost : 0 | ||
| + | delays : 2 | ||
| + | max delay : 188 | ||
| + | average delays : 20 | ||
| + | |||
| + | 10:53:04:743 4728 13003-0 -- Audio stream stopped | ||
| + | 10:53:04:743 4728 13003-0 -- Connect audio terminator | ||
| + | 10:53:04:743 4728 RTPS -- -----------> stream rtp-audio-stream : RTP started ssrc_rx:00000000 ssrc_tx:8376E2F0 | ||
| + | 10:53:04:743 4728 13003 -- trunk unbinded | ||
| + | 10:53:04:743 4728 13003 -- remove main sip call session 09393708... | ||
| + | |||
| + | |||
| + | |||
| + | Канальные логи ведутся по внутренним и внешним линиям. Если вы | ||
| + | |||
| + | |||
| + | |||
| + | В конце каждой коммутации, будь даже это коммутация с терминатором или с mp3-плеером, приводится статистика rtp-сессии: сколько пакетов/байтов отправлено, сколько получено, средний интервал, максимальный интервал между пакетами и т.д. Взглянув раз в этот журнал, станет понятно, где начинаются коммутации, где они заканчиваются, как разделять их друг от друга и как отличать проигрывание файлов от двунаправленного обмена.Понятно, что в зависимости от наблюдаемой информации следует принимать совершенно разные решения. | ||
| + | |||
Вообще в разборе лог-журналов очень удобно использовать две программы для анализа: | Вообще в разборе лог-журналов очень удобно использовать две программы для анализа: | ||
Версия 07:26, 30 января 2014
Содержание
В данной статье рассматриваются проблемы, связанные с отсутствием звука или плохим качеством звука при соединении с абонентом.
Структурно телефония состоит из 2х компонентов:
1) Сигнализация - механизм, который отвечает за то, чтобы два абонента могли связаться между собой (найти друг друга, отправить вызов в трубку, начать коммутацию). В Oktell используется протокол SIP.
2) Передача медиа-трафика - механизм передачи звуковой информации (голоса). Механизм являет собой пакетную передачу данных: голос конвертируется в пакеты данных (RTP-пакеты), которые начинают передаваться от абонента А к абоненту Б через интернет.
В процессе передачи, пакеты данных могут теряться из-за плохого интернет соединения, испытывать задержки, не достичь конечного пункта из-за неправильной конфигурации.
Отсутствие звука
Возможные причины
Для определения причины требуется предварительная диагностика проблемы. О методах диагностики читайте ниже.
1. Удаленный медиа-сервер (сервер провайдера телефонии) не отправляет медиа-трафик. Проверить можно с помощью WireShark.
2. Медиа-трафик не поступает на сервер Oktell.
- 2.1. Проверьте, проброшены ли нужные порты на вашем NAT-устройстве. Воспользуйтесь статьей: Настройка работы сервера за NAT
- 2.2. Проверьте настройки брандмауэра (firewall). Перейдите Брандмауэр Windows -> Разрешить запуск программы или компонента через брандмауэр Windows -> Разрешить другую программу -> Обзор и выберите
- \oktell\server\oktell.ServerService.exe
- \oktell\server\oktell.HALRemoteApp.exe
- ВНИМАНИЕ: Для проверки не рекомендуется отключать защиту системы в целях безопасности.
- 2.3. Перезагрузите сервер Oktell.
3. Медиа-трафик поступил на сервер Oktell, но не попал на телефон оператора. Из-за этого оператор не слышит внешнего абонента и думает, что звук отсутствует.
- 3.1. Если оператор находится в другой локальной сети за NAT (удаленный офис) - порты пробрасывать не нужно. Проверьте настройки роутера (например, установлено DMZ).
4. Прочее. Неправильная конфигурация сервера Oktell.
- 4.1. Перейдите в Администрирование->Параметры аппаратуры.
- Настройки потока -> Адрес назначения для RTP трафика. Настройка нужна, если абонент не слышит оператора (то есть звук идет от Oktell). Попробуйте поменять эту настройку и посмотреть на результат.
- Настройки потока -> Разрешить изменять параметры связи во время коммутации - рекомендуется установить Нет. Бывает, шлюзы/провайдеры не любят REINVITE инструкции, отправляемые с сервера. Хотя некоторые сами иной раз пользуются этим. Если выставлен запрет, Oktell включает транскодинг у себя, иначе может попросить внешний шлюз (считая его конечным аппаратным устройством) сменить кодек.
- 4.2. Кодеки. На время устранения проблем со звуком, рекомендуется установить единый кодек g.711a (или g.711u) во всех шлюзах и телефонах (в карте сети).
Диагностика в Oktell
Откройте Офис - Статистика АТС. Прослушайте запись разговора.
- Если на записи вы не слышите внешнего абонента, а голос оператора присутствует - проблема в соединении между провайдером телефонии и сервером Oktell. Необходимо проверить входящий трафик на сервере Oktell.
- Если на записи вы слышите только внешнего абонента, а голоса оператора нет - это обозначает что проблема в соединении между телефоном оператора и сервером Oktell. Необходимо проверить исходящий интернет-трафик у оператора.
- Если на записи вы слышите обоих участников разговора, но оператор плохо слышит собеденика, значит проблема также в соединении между телефоном оператора и сервером Oktell. Необходимо проверить входящий интернет-трафик у оператора.
Диагностика путем сравнения
В зависимости от проблемы выбираются различные варианты.
- Если проблема со звуком от внешнего абонента, попробуйте подключить другого SIP-провайдера и совершите пробный звонок. Например, SipNet. Если звук появился, проблема в провайдере или в настройке соединения. Если нет, проблема в соединении или в настройке Oktell.
- Если проблема со звуком от оператора, попробуйте подключить другой IP-телефон и совершить пробный звонок. Например, софтфон X-Lite. Если звук появился, проблема в телефоне. Если нет, проблема в соединении.
Диагностика сниффером Wireshark
Wireshark - программный инструмент для анализа сетевого трафика. С его помощью можно проанализировать RTP-пакеты, просмотреть работу SIP протокола, а также многое другое.
Запустим wireshark, чтобы он сохранил все исходящие и входящие пакеты во время разговора. В главном окне необходимо выбрать раздел Interface List и выделить необходимый интерфейс. Далее нажмите на Options.
Раздел Capture Filter - называется фильтром захвата. Wireshark будет захватывать только те пакеты, которые указаны в этом фильтре. Если нажать непосредственно на саму кнопку Capture Filter вам будут показаны различные предустановленные варианты захвата. Нам понадобиться UDP-протокол, введите его в поле ввода.
udp
В этом окне также вы можете нажать Capture Files и выбрать в какой файл будут сохраняться результаты. Если поставить галочку Use multiple files, то можно выбрать кольцевую схему сохранения, дробление файлов (например, по 200 мегабайт) и условие окончания захвата (например, после 1 гигабайта информации). После выбранных настроек нажмите кнопку Start.
Вы увидите список всех пакетов которые пришли или отправились с сервера Oktell. Совершите тестовый звонок, затем остановите захват.
Далее воспользуемся еще одним типом фильтра - фильтром отображения. Распологается он в верхней части программы, рядом находится подпись "Filter". Введите один их запросов:
- rtp - показывает все rtp пакеты
- ip.addr==192.168.0.81 - показывает все пакеты с участием IP-адреса 192.168.0.81
- ip.src==192.168.0.81 - показывает все пакеты, у которых IP-адрес отправителя равен 192.168.0.81
- ip.dst==192.168.0.81 - показывает все пакеты, у которых IP-адрес получателя равен 192.168.0.81
Если ввести IP-адрес сервера, то вы можете увидеть пришли пакеты на сервер Oktell или нет. Если операторы используют гарнитуру, то Wireshark можно поставить на рабочее место пользователя и оценить поступление и отправку RTP-трафика.
Есть другой способ: выберите в меню Telephony -> VoIP Calls.
Выберите интересующую вас коммутацию и нажмите Flow. Если вы видите две стрелки RTP-трафика, значит трафик поступал в обе стороны. Если вы увидите только одну стрелку - вы поймете в какую сторону RTP-трафика не было.
Плохое качество звука
Возможные причины
Проблемы со звуком — всегда сетевые проблемы. Любое искажение звука — это либо выпадение пакетов, либо задержка пакета в сети.
Возможные причины ухудшения звука:
1) В интернет-канале (интернет-провайдер) возникли проблемы, большая нагрузка. Обратитесь к интернет-провайдеру.
2) В локальной сети возникли проблемы с NAT-устройством (роутер, маршрутизатор). Перезагрузите устройство.
3) Большая нагрузка сервера Oktell. На сервере производится резервное копирование данных, обрабатывается большой поток информации (актуально, если на рабочем сервере установлен не только Oktell, а, например, сервер 1С). Запустите диспетчер задач, проверьте нагрузку на процессор, озу.
4) Firewall (брандмауэр, антивирус) обнаружил большое количество пакетов и приостановил поток данных. Проверьте настройки Firewall.
ВНИМАНИЕ: Для проверки не рекомендуется отключать защиту системы в целях безопасности.
Диагностика с помощью канального лога
Во время работы Oktell записывает статистику по каждому разговору в специализированный текстовый файл (лог-файл). Это помогает разобраться с поиском причин неисправности, локализовать и устранить проблему. Для выяснения причин понадобятся канальные логи.
Канальные логи располагаются в папке Server\Log\Hardware\Sip\[текущая дата]\[номер канала].log. Например, Server\Log\Hardware\Sip\2014-01-30\13003.log
10:52:54:083 1368 13003 -- -----------> MediaControl->StreamSignal REC_STARTED from stream rtp-audio-stream 10:52:54:083 1368 13003 -- -----------> Raising async event: 'REC_START' param:'empty' 10:52:54:083 1368 13003 -- recording started 10:52:54:083 4928 13003 -- -----------> Raise Event 'REC_START' (5) param:'empty' 10:52:54:084 4928 13003 -- -----------> Event 'REC_START' raised 10:52:54:096 4728 13003 -- Get fax capabilities : fax enabled true 10:52:54:122 592 bas-strm -- stream rtp-audio-stream : increase new ts:4535216 diff 1200, time:150 ms, result 4536416 10:52:54:180 2828 RTPS -- stream rtp-audio-stream : received New ssrc_rx 837DC6B0 10:53:04:623 4960 bas-strm -- WARNING : stream rtp-audio-stream : unbind_peer main link while stream is started 10:53:04:739 4728 13003 -- stop recording to file... 10:53:04:739 4728 13003 -- -----------> MediaControl->StreamSignal REC_STOPPED from stream rtp-audio-stream 10:53:04:739 4728 13003 -- -----------> Raising async event: 'REC_STOP' param:'empty' 10:53:04:740 4728 rec -- Final flush... 10:53:04:740 4728 rec -- Close file... 10:53:04:740 4728 rtp-rec -- Closeing file... 10:53:04:742 4728 rtp-rec -- File closed. 10:53:04:742 4728 rec -- File closed 10:53:04:742 4728 13003 -- recording stopped 10:53:04:742 4728 13003 -- unbind peer 16e001 10:53:04:743 4728 13003 -- unbind trunk from 16e001... 10:53:04:743 4728 13003 -- stop audio stream rtp-audio-stream 10:53:04:743 4728 13003-0 -- Stop audio stream... 10:53:04:743 4728 RTPS -- -----------> stream rtp-audio-stream : stopping : ssrc_rx:00000000 ssrc_tx:8376E2F0 10:53:04:743 4728 RTPS -- -----------> stream rtp-audio-stream : stopped 10:53:04:743 4728 bas-strm -- stream rtp-audio-stream : stream statistics: --OUT------------------ packets sent : 525 bytes sent : 90300 delays : 1 max delay : 129 average delays : 20 --IN------------------- packets received : 521 bytes received : 89612 out of order : 0 invalid : 0 lost : 0 delays : 2 max delay : 188 average delays : 20 10:53:04:743 4728 13003-0 -- Audio stream stopped 10:53:04:743 4728 13003-0 -- Connect audio terminator 10:53:04:743 4728 RTPS -- -----------> stream rtp-audio-stream : RTP started ssrc_rx:00000000 ssrc_tx:8376E2F0 10:53:04:743 4728 13003 -- trunk unbinded 10:53:04:743 4728 13003 -- remove main sip call session 09393708...
Канальные логи ведутся по внутренним и внешним линиям. Если вы
В конце каждой коммутации, будь даже это коммутация с терминатором или с mp3-плеером, приводится статистика rtp-сессии: сколько пакетов/байтов отправлено, сколько получено, средний интервал, максимальный интервал между пакетами и т.д. Взглянув раз в этот журнал, станет понятно, где начинаются коммутации, где они заканчиваются, как разделять их друг от друга и как отличать проигрывание файлов от двунаправленного обмена.Понятно, что в зависимости от наблюдаемой информации следует принимать совершенно разные решения.
Вообще в разборе лог-журналов очень удобно использовать две программы для анализа:
- - Notepad++. Он не только быстро грузит огромные файлы и шустро работает, но еще помогает вести подсчет, выделять цветом все обнаруженные присутствия указанного текстового блока (что как раз незаменимо при отслеживании пакетов по call-id, или исполняемых методов по номерам потоков или линий).для слежения
- - Far. Он умеет держать файлы открытыми и постоянно обновлять, не напрягая систему. Перемотал вниз, и сидишь следишь. Очень удобно в отдельных случаях. Также особо крупные файлы, не залезающие даже в Notepad++ (хотя я таких не видел), Far открывает сразу, ибо не грузит в память, а только отображает блоками.
Диагностика сниффером Wireshark
Выше был рассмотрен захват пакетов данных, которые были получены/отправлены. Telephony-> Rtp-> Show all streams. Проверьте что у вас будут две строки, а один из портов будет совпадать с тем, что мы нашли в канальном логе на шаге 1. В столбце Lost будут определены потери RTP пакетов. Потери до 5% считаются допустимыми. С помощью этой информации вы можете определить в какую сторону у вас идут потери - на входящий или исходящий трафик.
Диагностика с помощью программы NetTester
Есть замечательная программа - NetTester . Запускается на одной машине, запускается на другой. Настраиваются друг на друга, обе стартуют. Можно придти через неделю и посмотреть, сколько пакетов в какую сторону потерялось, где были задержки, сколько серий потерь наблюдалось, сколько были размеры этих серий в пакетах и секундах.Идеальная связь предполагает идеальные каналы. Бывает иначе.
Бинарный поиск всегда эффективнее полного перебора. Далее требуется несколько умозаключений. С опытом приходит понимание, какие из приведенных пунктов узловые, какие вспомогательные. Как правило руководствуясь коэффициентом полезность/трудозатраты. Разумеется, пытаться получать всю информацию сразу - бессмысленно. От характера проявления появляются подозрения и гипотезы. По ним выстраивается короткая серия тестов. По результатам формируются из оставшегося списка новые тесты/задачи. И напрямик к проблеме. Но чтобы суметь понять что важное, а что второстепенное (зависит от характера и проявления) - требуется опыт. Который есть у технической поддержки и у части специалистов, в том числе сертифицированных в Телефонных Системах.
В случае, если вы самостоятельно не можете разобраться с данной проблемой, обращайтесь в техническую поддержку Oktell.
