@etoosamoe

Почему иногда нет исходящего звука при исходящем звонке?

Всем привет!
Очень долго не могу разобраться с одной проблемой.

Имеется Asterisk + FreePBX доисторических версий, но, скорее всего, дело не в этом.
Имеется sip транк с провайдером (пчелиным):
type=friend
nat=force_rport,comedia
qualify=yes
insecure=port,invite
host=beeline_ip
dtmfmode=inband
disallow=all
allow=alaw


Имеется Микротик как маршрутизатор в офисе. Астериск расположен за натом с своей подсети. Скажем, 10.1.130.9 у него адрес. На микротике настроены пробросы портов 10004-61000(порты указаны в ТЗ) на внутренний адрес Астериска.

Телефонные аппараты расположены в разных местах, и в разных подсетях (но не за пределами НАТа, везде внутренняя маршрутизация). Все внутренние подсети добавлены в localnet в настройках.

А теперь кейс:
Абонент А: внутренний телефонный аппарат
Абонент Б: рандомный мобильный телефон, городской номер, etc...

Абонент А звонит абоненту Б (т.е. это исходящий внешний звонок).
Примерно один раз из 10-15 - абонент Б не будет слышать абонента А. Сброса звонка по таймауту не происходит. В дампе звонка RTP устанавливается в обе стороны. Дамп снятый с Астериска слышит оба направления, значит АТСка отправляет исходящий звук корректно.
В Wireshark-е на графике воспроизведения есть подозрительные "Вставленная заглушка", их происхождение я не выяснил.

Что проверено:
  • отключение\влияние SIP ALG на микротике
  • смена кодеков
  • аналогичное поведение при входящих звонках
  • отключение qualify
  • rtpkeepalive=1
  • отключение\изменение настроек NAT в FreePBX
  • различные способы проброса портов на микротике
  • сбойный звонок повесить на паузу и снять с паузы

UPD, что еще не помогло:
  • дамп трафика у провайдера показывает RTP пакеты в ОБЕ стороны. Номера портов совпадают с двух сторон
  • переключение на новую версию Астериска\FreePBX
  • переключение на другого провайдера (одноименного с поставщиком транка)


Опять же, я не думаю, что дело в НАТе, так как это происходит не всегда, все указанные порты проброшены, и помимо этого связь работает нормально.
Провайдер неделю смотрел на дамп моего звонка, который они сами записали. Общались с вендором, с их слов:
Была скорректирована логика формирования version number SDP на то, что parameter in the "o=" attribute line increases by 1 only if the SDP body changes.
но это не помогло.

В какую еще сторону можно посмотреть?
  • Вопрос задан
  • 83 просмотра
Пригласить эксперта
Ответы на вопрос 2
@PeeX
посмотреть сниффером как трафик ходит и там уже копать ?
wireshark умеет восстанавливать из записанного трафика беседу и воспроизводить ее
Ответ написан
@dronmaxman
VoIP Administrator
Без дампа звонка можно только гадать, присылайте дапм проблемного звонка (можно в личку если опасаетесь атак). Идеально было бы посмотреть ДАМП на WAN порту микротика. Если проблема плавающая, я бы грешил на микротик.

qualify=yes вам зачем? если регистрация insecure=port,invite
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы