Не реагирует на 200 OK от конкретного провайдера

[ip59]

Коллеги, добрый день.

Имеется адекватно работающий Asterisk 1:13.1.0 за NAT и несколько SIP транков Билайн.
Подключили SIP транк нового провайдера, все настройки аналогичные.
При исходящих звонках АТС не реагирует на приходящие 200 OK после INVITE и отключается с Retransmission timeout reached.
В логах входящие 200 OK регистрируются.
Прошу помощи.

[Wapo]

Retransmit = вы посылаете пакет а ТАМ его не принимают. Ну или Вы не принимаете их ответы.
1. Пров и его файерволл
2. Ваш файерволл

[ip59]

Retransmit = вы посылаете пакет а ТАМ его не принимают. Ну или Вы не принимаете их ответы.
1. Пров и его файерволл
2. Ваш файерволл

К сожалению, все это было сделано, провайдер присылает симметричную картинку - множественные INVITE от нас и множественные 200 OK нам.
У нас все эти запросы и ответы тоже видны с точностью до пакета и в логах АТС все 200 OK видны, вот что не понятно.

Вчера увидели, что устанавливается RTP с провайдером, но не устанавливается RTP с телефоном. Провайдер говорит, что у нас плохие телефоны. Но при переключении проблемного экстеншна на контекст давно работающего билайна проблем нет.

Вопрос к профессионалам: можно как-то подсмотреть реакцию АТС на конкретный пакет?

[Wapo]

rtp set debug on

[BorisTheBlade]

Очевидно астериск не может сопоставить ok и invite.
Например invite улетает в один интерфейс, а ok прилетает через другой.

[ip59]

rtp set debug on

Код: выделить все

pbx01*CLI> rtp set debug on
RTP Debugging Enabled
Got  RTP packet from    176.32.181.115:19388 (type 08, seq 041239, ts 000000, len 000160)
Got  RTP packet from    176.32.181.115:19388 (type 08, seq 041283, ts 007040, len 000160)
Got  RTP packet from    176.32.181.115:19388 (type 08, seq 041383, ts 023040, len 000160)
Got  RTP packet from    176.32.181.115:19388 (type 08, seq 041583, ts 055040, len 000160)
Got  RTP packet from    176.32.181.115:19388 (type 08, seq 041983, ts 119040, len 000160)

176.32.181.115 это провайдер

Возможно, Вы правы.
Интерфейс один, но Астерисков на самом деле два, VRRP с общим ip и с собственными различающимися адресами.
Нат действительно пересылает пакет на виртуальный адрес, потом он преобразуется на адрес активного астериска.

Вот так выглядит ОК 200:

[Показать] Спойлер:

IP 176.32.181.115.5060 > 172.27.32.51.5060: UDP, length 817
E..M....v.... .s.. 3.....9.TSIP/2.0 200 OK
Via: SIP/2.0/UDP 172.27.32.50:5060;received=172.27.32.50;branch=z9hG4bK351673dd;rport=5060
From: "Test" <sip:8122441555@172.27.32.50>;tag=as02e6eac5
To: <sip:89522142958@176.32.181.115:5060>;tag=2486532216-3927036120-637547691-2153257557
Call-ID: 3f0c231b172c82067ecb90b92374bc89@172.27.32.50:5060
CSeq: 102 INVITE
Contact: <sip:89522142958@176.32.181.115:5060;transport=udp>
Content-Type: application/sdp
Allow: ACK, BYE, CANCEL, INFO, INVITE, OPTIONS, REFER, REGISTER, UPDATE
X-mera-expires: 86460
Content-Length: 269

Но со вторым провайдером такого поведения нет, а ничего кроме новой регистрации мы не добавляли.

Есть ли возможность

[ip59]

Проблема закрыта.
Сетевые инженеры втихую включили SIP ALG на оборудовании.