Форум мини АТС компании Солярис

Коллеги-связюки, приветствую!
Прошу помощи.

Model: Yeastar P570
HW ver: v2.00 0005-0000
SW ver: v37.18.0.19

Подключено к провайдеру Beeline: SIP-транк без регистрации.
АТС за NAT/filer, конечно, но все проброшено, что нужно.
Вызовы ходят в обе стороны, голос слышен в обе стороны.
Но...

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

Причем, без разницы, является ли инициатором вызова внешний абонент (на стороне провайдера) или внутренний абонент АТС - вызов НЕ завершается именно в случае, когда кладут трубку на отвечающей стороне. То есть ситуация странно симметрична.

Ну не может же она не реагировать на BYE?!

Может кто подкинет идею - куда копать?

Это очень очень странно.

daniel0_ писал(а): ↑28 апр 2025, 11:09 Вызов НЕ завершается, если положили трубку на отвечающей стороне.

Не зависит от того, кто инициатор? То есть, кто именно не кладет трубку? АТС косячит?

daniel0_ писал(а): ↑28 апр 2025, 11:09 Ну не может же она не реагировать на BYE?!

Кто именно?

vda писал(а): ↑29 апр 2025, 05:43 Это очень очень странно.

daniel0_ писал(а): ↑28 апр 2025, 11:09 Вызов НЕ завершается, если положили трубку на отвечающей стороне.

Согласен с Вами, доктор!

vda писал(а): ↑29 апр 2025, 05:43 Не зависит от того, кто инициатор? То есть, кто именно не кладет трубку? АТС косячит?

daniel0_ писал(а): ↑28 апр 2025, 11:09 Ну не может же она не реагировать на BYE?!

Кто именно?

Вызов А (внеш) ---> АТС ---> Б (внутр):
... кладёт трубку А - вызов завершается
... кладёт трубку Б - вызов НЕ завершается
Вызов А (внеш) <--- АТС <--- Б (внутр):
... кладёт трубку А - вызов НЕ завершается
... кладёт трубку Б - вызов завершается

Не может P570 не реагировать на BYE, иначе бы Солнце вращалось вокруг Земли. Это же базовый принцип SIP: получил BYE, ответил OK.

daniel0_ писал(а): ↑28 апр 2025, 11:09 Ну не может же она не реагировать на BYE?!

А есть трассировка?

Вопрос решился. Хочу поделиться КАК. Вдруг кто столкнётся с такой же бедой.
Ибо вопрос решился вообще случайно, и если бы не этот случай, мы могли бы совместно с отделом ИТ биться головой об стену месяцами без результата.

Файрвол в данном случае был Kerio. Через него бегает вся внешняя коммуникация. Внутри сети он ничем не рулит, а VLAN'ы режутся на свичах. Дело оказалось в нём, но кто бы знал - где.

Изначально было сделано два правила проброса снаружи внутрь: с адреса SIP-сервера провайдера на локальный адрес АТС с трансляцией порта UDP на 5060 (внешний порт далеко в верхнем диапазоне) и с адреса MEDIA-сервера провайдера на адрес АТС без трансляции порта. Проброс медиа можем не рассматривать. Крыса застряла исключительно в пробросе SIP'а.

Если проброс делается на destination = interface, имеем сабж.
Если проброс делается на destionation = host IP (который, мать его , и есть единственный на этом интерфейсе), проблема исчезает.

Что имеем в трассировке?

В первом случае вообще нет BYE, зато из ниоткуда волшебные четыре INVITE подряд с тем же call id. Причем, в трассировке на интерфейсе со стороны WAN оно есть, а на стороне LAN (одновременно!) этих пакетов нет. Соответственно, не получив BYE, не отбиваемся. Пробовали ждать до 15 минут! BYE'я нет. Отбоя нет.

Во втором случае чётко и быстро BYE и ответ OK (BYE).

Собственно, как обнаружили: снесли все правила, на словах обяснили другому человеку, что требуется, и дали руль от Kerio - он сделал правила заново как сам их видел, использовав HOST IP вместо INTERFACE. Внезапно заработало. Толпа матёрых ИТ-бронтозавров и один не менее опытный связюк (Я) знатно офигели и поначалу не поверили. Вернули обратно destination = interface - снова перестало работать. Проделали манипуляцию несколько раз и чётко убедились, что дело именно в этом.

Сравнивали пакеты в обоих ситуациях, но понять, откуда берутся четыре внезапных INVITE, когда пора вызов завершать, так и не смогли. Предшествующие пакеты идеально одинаковые с точностью до call id, так как каждый новый звонок имеет новый id. Но в одном случае АТС начинает слать INVITE'ы, а в другом имеем совершенно ожидаемые BYE.

Т.е. дело не в том, как ведёт себя АТС или Kerio, а как АТС реагирует на поведение Kerio. Так что ли выходит? Но весь мой опыт подсказывает, что ТАК БЫТЬ НЕ МОЖЕТ. Потому что что на уровне IP и на уровне UDP никакой разницы нет между этими двумя ситуациями, а все другие SIP-пакеты в этих же сессиях ходят нормально.

С тех пор уже 4 часа - полёт нормальный, все службы телефонии работают как часы.

Пойду напьюсь. Можно, коллеги?