+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Проблема с SIP в версиях 7.4.x и 7.5

Проблема с SIP в версиях 7.4.x и 7.5, RouterOS

Maggiore81

Guest

21.09.2022 08:18:00

Здравствуйте! У меня есть HAP Ac3 с обычной конфигурацией на объекте клиента. Маршрутизатор выполняет NAT masquerade, как в стандартной настройке. Все firewall helpers отключены. Я обновился с версии 6.48.6 до 7.1.5 — сработало, обновился до 7.4 — тоже работает. А с версии 7.4.1 и дальше, на 7.5 Gigaset 690 больше не регистрируется. Я попытался включить sip helper — теперь регистрация проходит, но в аудиопотоке появляются "дырки". Переустановил обратно 6.48.6 — всё работает. Что можно проверить?

По соединениям на firewall в версиях 7.4.1 и 7.5 я вижу, что UDP-соединения начинают работать, но через несколько секунд исчезают из таблицы conntrack. При включенном SIP helper они остаются там с таймаутом в 1 час (мои таймауты conntrack по умолчанию). В версии 6.48.6 таймаут составляет 3 минуты, но он периодически сбрасывается до 3 минут, и соединения стабильно держатся без проблем.

Maggiore81 Guest	#2 0 02.03.2023 05:21:00 Я тоже пробовал версию 7.7 с включённым и выключенным SIP helper — без изменений. Похоже, что я решил проблему, увеличив таймаут UDP (та же проблема, что и с RDP) с 10 до 20 секунд.

grawerpl

Guest

11.10.2022 19:02:00

У меня такая же проблема. Примерно через 3 минуты весь VoIP перестаёт работать. Я на 100% уверен, что дело в этой версии прошивки, потому что это случается только у пользователей с версиями 7.4.x и 7.5. Мы проверяли с провайдером и оператором VoIP, и каждый раз проблема возникала при использовании версий 7.4.x и 7.5. После отката на 7.3.1 всё снова начинает работать нормально.

Maggiore81 Guest	#4 0 12.10.2022 06:36:00 Если баг есть в релизах 7.4.x и 7.5, решение — сделать даунгрейд.

biomesh

Guest

12.10.2022 10:35:00

Если бы это сломало VoIP у всех, уверен, жалоб было бы куда больше, чем у нескольких человек. Я сейчас пользуюсь версией 7.5 и регулярно обновляю ROS без каких-либо проблем с VoIP-сервисами. У меня используется Asterisk, который подключен к нескольким провайдерам. Можешь выложить свою конфигурацию или откатиться до предыдущей версии и открыть тикет в поддержку.

ingdaka

Guest

12.10.2022 22:14:00

CCR2004-16G-2S+ Ros7.5 Около 70 пользователей PPPoE, все используют VoIP, и у всех всё работает нормально последние 13 дней (с тех пор как я обновил роутер). Elia, похоже, в этот раз тебе не повезло, дружище… Или проблема в модели устройства плюс версия RoS.

Ferrograph Guest	#7 0 15.10.2022 22:09:00 Попробуйте отключить правило fasttrack в вашем фаерволе, если оно у вас есть.

Maggiore81 Guest	#8 0 16.10.2022 04:26:00 Пробовал. Ни малейшей разницы.

underdog

Guest

16.10.2022 17:11:00

ROS V7 использует ядро Linux версии 5.x с новым типом SIP-хелпера. У меня теперь всё действительно работает, тогда как в версии 6.x приходилось применять массу костылей. На клиенте я включил SIP-хелпер и добавил 2 правила в файрвол: chain=input action=accept connection-type=sip log=no log-prefix="" chain=forward action=accept connection-type=sip log=no log-prefix="" Без NAT и без STUN.

pssara Guest	#10 0 01.03.2023 20:49:00 Фу, столкнулся с той же проблемой в версии 7.7. Проблема в том, что я не могу откатиться назад. Это новый роутер 5009, который не работает на v6.

ecylcje

Guest

#11

23.03.2023 07:52:00

Могу подтвердить, что после перехода на ROS 7.8 с последней версии 6.X SIP перестал работать. Как только я увеличил таймаут UDP с 10 до 20 секунд и убил существующие соединения во вкладке IP->Firewall->Connections, SIP снова заработал. Включать SIP Helper не нужно, достаточно было только изменить UDP. Спасибо, Крис.

olivier2831

Guest

#12

23.03.2023 08:47:00

Ты контролируешь другую сторону SIP-соединения? Если да, это помогло бы понять, почему ответ по UDP приходит с задержкой больше 10 секунд. С другой стороны, я думал, что таймауты NAT для UDP значительно больше 10 секунд (гугля по запросу «UDP NAT timeout» я увидел, что в Linux по умолчанию это 3 минуты).

ecylcje Guest	#13 0 23.03.2023 10:02:00 Мой VOIP-провайдер — localphone. Мои два SIP-клиента (Grandstream GXP1630 и Siemens N510) оба не могли подключиться к localphone, пока я не изменил время ожидания UDP.

Maggiore81

Guest

#14

30.07.2023 08:18:00

Я провёл кучу тестов. Сейчас у нас версия 7.10.2. Я пробовал менять таймаут UDP на 30, но результата нет. Иногда работает, иногда нет. Вчера обновил несколько RB до последней версии 6.49.x. Обновил их, потому что хотел избавиться от проблемы с BGP, когда соединения иногда застревали в состоянии «open sent». После обновления до версии 7 в некоторых случаях VoIP перестал работать. Таймаут стал равен нулю, и соединение сбрасывалось в conntrack. Я попробовал включить sip helper (раньше никогда не включал), таймаут поднялся до 60 минут… но VoIP стал работать с перебоями. Я откатился назад, с точно той же конфигурацией файрвола — и всё снова работало без сбоев. Пока что я не могу спокойно обновить всё до версии 7, есть вопросы, которые нужно решить, хотя у 95% моих устройств проблем нет. Например: Hap AC3 с Gigaset IP 690 — на версии 6 работает, на версии 7 — нет. Другой FreePBX на версии 6 работает, на версии 7 — не работает… провайдер SIP тот же самый.

bacontrees

Guest

#15

10.09.2024 16:52:00

Есть какие-то новости по этому поводу? Столкнулся с очень странными проблемами у клиента, который использует OnSIP, и думаю, что это может быть связано. Забавно, что не все мои RB/клиенты, кажется, пострадали. Этот — RB750Gr3, ROS 7.15.3, fasttrack включён. Установка таймаута UDP на 120 секунд (по рекомендации провайдера) вроде помогла. Но я заметил множественные/дублирующиеся треки соединений (хотя, судя по всему, это проблем не вызывает). Может попробую отключить fasttrack, но только если они продолжат жаловаться.

Maggiore81 Guest	#16 0 10.09.2024 19:06:00 Моё окончательное решение: установить таймаут UDP на 30, задать статический DHCP-лизинг для устройства ATA или SIP-телефона, настроить netwatch на пинг каждые 5 секунд. Проблема исчезла. Похоже, что проблема связана с автоматическим удалением ARP-записей (потому что стандартный срок жизни — 30 секунд).

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры