Введение

При разработке MikoPBX, мы стараемся реализовать ту или иную функцию максимально просто, чтобы даже новичок мог быстро начать работу.

Но некоторые вещи неподготовленному пользователю могут существенно усложнить жизнь.

Одна из проблем - плохое качество связи, односторонняя слышимость. Попробую описать в этой статье подход к анализу проблем со звуком.

Кодеки

Пожалуй это первое, что следует проверить. К MikoPBX возможно подключить самые различные SIP / IAX устройства (endpoints):

  • Аппаратный SIP телефон
  • Аналоговый телефон (через SIP шлюз)
  • Учетную запись провайдера, в качестве "endpoint" тут может выступать как реальная "железка", так и приложение (тот же asterisk)

Устройства, при попытке установить "договориться" о диалоге обмениваются информацией о поддерживаемых кодеках (формате медиа данных), это может быть gsm / ulaw / alaw и тд.

Если устройства не найдут общий кодек, то вызов скорее всего прервется. В логе отобразиться ошибка, что совместимый кодек не найден.

В MikoPBX кодеки настраиваются в разделе "Общие настройки" - "Аудио/Видео Кодеки" (см. wiki). Наиболее распространенный кодек в РФ alaw. При работе с webRTC следует разрешить кодек opus.

NAT

Не корректно настроенное сетевое окружение, наиболее распространенная проблема.

Типичный пример

На предприятии имеется несколько локальных подсетей:

  • 172.16.32.0/24 - Офис
  • 172.16.33.0/24 - VPN
  • 172.16.34.0/24 - Прочее

Есть внешний IP адрес 109.61.231.230. Сотрудники должны подключаться к АТС из подсетей:

  • Офис
  • VPN
  • Просто из интернет (LTE), для мобильных сотрудников

Для подключения внешних сотрудников необходимо:

  • Публичный, статический IP адрес - приобретается у поставщика услуг связи интернет
  • В настройках сетевого интерфейса следует прописать внешний адрес АТС (см. wiki)
  • Сопоставить на маршрутизаторе внешние порты SIP и RTP (см. wiki) с соответствующими портам на АТС (один к одному). К примеру если на АТС порт SIP=5060 и RTP=с 10000 по 10000, то и на маршрутизаторе следует открывать лучше эти порты.
  • Включить на АТС firewall (см. wiki)
  • Настроить на АТС сетевой экран (см. wiki)

В сетевом экране следует описать все локальные подсети. Обязательно установите для таких подсетей флаг "Это локальная подсеть или VPN...". Если флаг не будет установлен, то АТС будет работать с данной подсеть как с внешней, в SIP сообщениях будет сообщаться внешний адрес АТС, а не внутренний, что повлечет за собой проблемы со звуком.

В новой версии АТС 2021.4.1+ появится возможность прописать stun сервер, он необходим для корректного определения внешнего адреса, и на моей практике, пригодился для корректной работы webRTC клиента: stun сервер

Симптомы не корректной настройки:

  • Односторонняя слышимость
  • Нет звука в обе стороны
  • Не возможно совершать звонки
  • Не завершается вызов

SIP ALG

"SIP ALG" - Это средство преодоление NAT, функция с подобным названием есть в большинстве современных роутерах.

Фактически, когда роутер получает SIP пакет с INVITE он сам подменит ip адрес в пакете, что может привести к проблемам со связью.

Если нет понимания как корректно настроить, отключите SIP ALG на вашем маршрутизаторе

Прочие проблемы

Есть ряд проблем которые сложно сходу обнаружить. На практике встречал следующее:

  • Рассыпался жесткий диск для хранения данных - как следствие, АТС не корректная работа станции, в частности проблемы с качеством связи
  • Не надежный канал связи интернет - перегнули сетевой провод (как ни странно встречается часто), перегрузили канал скачиванием файлов с torrent и прочее подобное
  • Прочие проблемы с железом

Вот пример анализа сетевого трафика по проблемному звонку: пример анализа сетевого трафика по проблемному звонку

На изображении видны "красно-желтые точки". фактически, это "отброшенные пакеты", которые не будут воспроизведены клиенту. В данном случае при увеличении значения Jitter Buffer до 800, звук выравнивался, заикания пропадали.

При этом, клиент "получил" все пакеты, но из за значительных задержек просто не стал их воспроизводить. Конкретно эта проблема заключалась в использовании системы виртуализации Proxmox, решилась переходом клиента на железный сервер.

Итоги

  • При возникновении проблем с качеством связи проверьте настройки NAT
  • Убедитесь, что все устройства поддерживают выбранные кодеки
  • Снимите дамп трафика, и отправьте его провайдеру на анализ

Если ничего не помогает - обращайтесь к нам, присылайте дампы.