Версия для печати темы
АРТКОМ Форум _ Техническая поддержка iPECS-LIK & iPECS-UCP _ Периодически пропадает связь при NETWORKING
Автор: bfl 19.10.2020, 16:46
Добрый день,
Помогите, пожалуйста, разобраться в проблеме. Между двумя LIK-300 настроена связь через Интернет по NETWORKING с помощью модулей VOIM. Связь работает нормально, в обе стороны абоненты звонят друг-другу по коротким номерам (2***<->3***). В течении дня, примерно, в 11 и 16 часов то с одной, то с другой из сторон позвонить абонентам соседней станции не удаётся, при наборе из 2*** на 3*** или наоборот - просто тишина. В течении 5-10 минут всё проходит и связь восстанавливается. И так каждый день.
Автор: AXEL 19.10.2020, 17:15
Как правило в 99% случаев проблема в сети (маршрутизаторы, провайдер итд). Лечится заменой составляющих.
Автор: bfl 19.10.2020, 17:34
Цитата(AXEL @ 19.10.2020, 18:15)
Как правило в 99% случаев проблема в сети (маршрутизаторы, провайдер итд). Лечится заменой составляющих.
Понятно, спасибо, т.е. искать проблему в настройках станций и модулей бесполезно. Будем искать в сетевых устройствах.
Автор: AXEL 19.10.2020, 17:55
Цитата(bfl @ 19.10.2020, 17:34)
Понятно, спасибо, т.е. искать проблему в настройках станций и модулей бесполезно. Будем искать в сетевых устройствах.
Immediate_Second_Call_Problem_Behind_NAT_Router.docx ( 183,14 килобайт )
: 14Не совсем может то, но вдруг поможет. Это как бороться с постоянными проблемами по H323 протоколу.
Для LIK это можно сделать только через командную строку.
Автор: bfl 30.10.2020, 12:11
Как оказалось, основной причиной является то, что MFIM и, в частности, VOIM общаются друг с другом через VPN канал. Насколько небезопасной является настройка общения VOIM друг с другом напрямую по Интернет через Firewall и NAT?
Автор: AXEL 30.10.2020, 12:39
Цитата(bfl @ 30.10.2020, 12:11)
Как оказалось, основной причиной является то, что MFIM и, в частности, VOIM общаются друг с другом через VPN канал. Насколько небезопасной является настройка общения VOIM друг с другом напрямую по Интернет через Firewall и NAT?
Просто защищайте соединение. В 320 программе обязательно включите NET IP AUTH. Так же можно прописать правила для фаервола на ваших маршрутизаторах: принимать запросы на порт 1720 только от определенного ip. Можно так же прописать ACL в 255 программе.
Автор: bfl 30.10.2020, 13:03
Цитата(AXEL @ 30.10.2020, 13:39)
Просто защищайте соединение. В 320 программе обязательно включите NET IP AUTH. Так же можно прописать правила для фаервола на ваших маршрутизаторах: принимать запросы на порт 1720 только от определенного ip. Можно так же прописать ACL в 255 программе.
Спасибо. Т.е. вся защита заключается в авторизации приёмо-передачи? А как насчёт голосового траффика, он передаётся при этом в нешифрованном виде или что-то типа IPKTS?
Автор: AXEL 30.10.2020, 14:51
Цитата(bfl @ 30.10.2020, 13:03)
Спасибо. Т.е. вся защита заключается в авторизации приёмо-передачи? А как насчёт голосового траффика, он передаётся при этом в нешифрованном виде или что-то типа IPKTS?
В нешифрованном. По умолчанию на всех модулях включено SRTP, но как это работает через NAT....
Автор: bfl 30.10.2020, 15:45
Цитата(AXEL @ 30.10.2020, 15:51)
В нешифрованном. По умолчанию на всех модулях включено SRTP, но как это работает через NAT....
Значит по старой-доброй традиции не будем мешать механизму работать.
Благодарю за подсказку!)
Русская версия Invision Power Board (http://nulled.ws)
© Invision Power Services (http://nulled.ws)