Коллеги-связюки, приветствую!
Прошу помощи.
Model: Yeastar P570
HW ver: v2.00 0005-0000
SW ver: v37.18.0.19
Подключено к провайдеру Beeline: SIP-транк без регистрации.
АТС за NAT/filer, конечно, но все проброшено, что нужно.
Вызовы ходят в обе стороны, голос слышен в обе стороны.
Но...
Вызов завершается, если инициатор положил трубку.
Вызов НЕ завершается, если положили трубку на отвечающей стороне.
Висит долго - ни на какой таймер не похоже.
Причем, без разницы, является ли инициатором вызова внешний абонент (на стороне провайдера) или внутренний абонент АТС - вызов НЕ завершается именно в случае, когда кладут трубку на отвечающей стороне. То есть ситуация странно симметрична.
Ну не может же она не реагировать на BYE?!
Может кто подкинет идею - куда копать?
Не завершается вызов
-
vda
- Ангел
- Сообщения: 1249
- Зарегистрирован: 14 май 2019, 11:04
- Благодарил (а): 271 раз
- Поблагодарили: 246 раз
Re: Не завершается вызов
Это очень очень странно.
Не зависит от того, кто инициатор? То есть, кто именно не кладет трубку? АТС косячит?
Кто именно?
Re: Не завершается вызов
Согласен с Вами, доктор!
Вызов А (внеш) ---> АТС ---> Б (внутр):
... кладёт трубку А - вызов завершается
... кладёт трубку Б - вызов НЕ завершается
Вызов А (внеш) <--- АТС <--- Б (внутр):
... кладёт трубку А - вызов НЕ завершается
... кладёт трубку Б - вызов завершается
Не может P570 не реагировать на BYE, иначе бы Солнце вращалось вокруг Земли. Это же базовый принцип SIP: получил BYE, ответил OK.
-
vda
- Ангел
- Сообщения: 1249
- Зарегистрирован: 14 май 2019, 11:04
- Благодарил (а): 271 раз
- Поблагодарили: 246 раз
Re: Не завершается вызов
Вопрос решился. Хочу поделиться КАК. Вдруг кто столкнётся с такой же бедой.
Ибо вопрос решился вообще случайно, и если бы не этот случай, мы могли бы совместно с отделом ИТ биться головой об стену месяцами без результата.
Файрвол в данном случае был 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 часа - полёт нормальный, все службы телефонии работают как часы.
Пойду напьюсь. Можно, коллеги?
Ибо вопрос решился вообще случайно, и если бы не этот случай, мы могли бы совместно с отделом ИТ биться головой об стену месяцами без результата.
Файрвол в данном случае был 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 часа - полёт нормальный, все службы телефонии работают как часы.
Пойду напьюсь. Можно, коллеги?
