Резервная интернет-линия

[anonymous]

В нашем офисе подключили резервную линию интернет от второго провайдера и поставили роутер с двумя WAN, который переходит на резерв при отказе основной линии. Оба провайдера дают статические белые IP адреса.

Проблема состоит в автоматическом переходе 3CX v10 на другую линию. Раньше я в настройках отключал STUN и прописывал свой реальный IP, который используется при регистрации у VOIP-провайдера. Все работало отлично. Сейчас же при таких настройках при переходе на резервный интернет используется другой IP и входящие вызовы перестают проходить поскольку провайдеру сообщен при регистрации другой IP. Сейчас пробую играться со STUN, вызовы проходят, но часто не проходит голос с АТС к оператору. Порты 5060 проброшены на сервер с обоих провайдеров.

Может кто подскажет рещение?
Заранее спасибо!

 

[anonymous]

Порты 5060 проброшены на сервер с обоих провайдеров.
Порты, используемые для внешнего RTP трафика, тоже надо "пробросить" на обоих интерфейсах маршрутизатора.
Попробуйте поймать проблемный звонок Wireshark'ом, по нему можно будет попробовать выяснить (хотя бы косвенно) причину отсутствия звука.

Если честно, то такая схема дублирования плохо подходит для телефонии, хотя и выглядит простым решением для повышения отказоустойчивости соединения с интернет. Дело в том, что АТС априори не знает своего адреса и, к тому же, он может поменяться в любой момент. В таком окружении, добиться правильности договоров, в общем случае, не предоставляется возможным. Проконсультируйтесь с VoIP провайдером. Скорее всего он может предложить альтернативные методы решения или дополнительный сервис, который поможет АТС бороться с этой "неизвестностью".

 

[vpaulo]

Господа, я конечно рад что Вы снова пытаетесь изобрести велосипед, но спешу вас огорчить - он изобретен миллион лет назад.
Итак давайте по порядку:
1. Есть атс 3сх - вопрос сразу есть внутренний айпишник на ней или же внешний? Атска виртуальной среде или на физическом сервере???
2. Есть роутер, или два?
3. Каким образом и кто выбирает режим направления трафика на тот или иной интерфейс маршрутизатора?
4. еше вопрос, если интерфейсов несколько на той винде, на которой установлен 3сх, какой gw является дефолтным?

ну а теперь предположим:

1. 3сх имеет один интерфейс и живет в виртуальной среде, имеет скажем 192.168.1.2, шлюзом для инф-са будет 192.168.1.254. Предположим идеальный с точки зрения стабильности работы маршрутизатора что это стоит скажем любая циска 2801 и старше или же на худой конец какой нибудь zyxell или dlink ( что вообще лажа) с двумя wan портами.
2. Есть один роутер, как я описал выше, у которого есть два wan порта и в эти wan порты у вас сходятся оба провайдера.
3. в таком случае сам маршрутизатор на основе icmp ping выбирает куда слать пакеты.
4. вопрос отпадает по причине одного интерфейса в рассматриваемом варианте.

после всего вышеприведенного имеем один маршрутизатор с двумя wan и 3сх на интерфейсе 192.168.1.2
в таком случае стан стоит разрешить не помню точно где ( наверняка есть) время обновления стан поставить скажем раз в 5 минут , или меньше если сервис критичен и очень много звонков. С точки зрения работы 3сх, ему паралельно какой внешний айпи у него есть, так как маршрутизатор управляет этим трафиком и запросами стан, которые летят в свою очередь или в один или в другой интерфейс. Но это идельный вариант который я обычно практикую в таких случаях, можно конечно извратится и сделать провайдеринг независимый ip адрес, но это уже будет дорого ))))

Опишите подробно вашу схему и исходя из вашей топологии будем искать решение

 

[vpaulo]

перечитав еще раз с самого начала понял что написал фигню )))
Итак есть роутер с двумя ван портами, от лично какой это роутер?? марка и модель и нужно отключить там контроль сип протокола если он есть, потому как реализация этой функции почему то кривая почти у всех роутеров.

У 3сх один интерфейс с натом? и все???
роутер на резервный какнал переключается по пингам? или как?
не понятна история почему у вас не идет голос, хорошо было бы все таки действительно вайршарк посмотреть.

 

[vpaulo]

а когда у нас в форуме исчезла возможность редактировать посты?????
еще вопрос который у меня возник - вы сказали что запрещали стан запросы и прописывали айпи руками, зачем?? что не работало при разрешенных стан запросах? не ходил голос или не проходила регистрация?

 

[vpaulo]

to SY,
Степан, у меня была подобная ситуация в Москве, два канала, циска как маршрутизатор. Ничего мне провайдеры так и не предложили, мотивировали тем что через стороннего провайдера они не могут гарантировать прохождение трафика нормальное ( так мне ответил транстелком и биллайн), можно попробовать настроить с воип провайдером site-to-site vpn, который будет переустанавливаться при разрывах связи и смене провайдера, но это уже скорее исключение о котором надо договариваться с провайдером VOIP. Мне так и не удалось, пришлось перевезти серверную площадку в арендованный дата центр, где интернет соединение гарантирует провайдер.

 

[vpaulo]

Еще надо в настройках провайдера изменить время регистрации с 10 минут на 5 скажем

 

[vpaulo]

у вас есть изменения?

 

[igor.snezhko]

Насколько мне известно, хорошие провайдеры могут прописать у себя два и более IP и объединить их в группу вызова. То- есть, если абонент "отпал" по первому IP, провайдер посылает запрос по второму.

Другое решение - использовать не авторизацию по IP (транк), а авторизацию по логину и паролю (провайдер). Тогда IP адрес может быть даже динамический. У меня так несколько лет работало, пока я не нашел провайдера с дешевым статическим IP.

 

[vpaulo]

ПРивет Игорь. Мне кажется у него как раз авторизация не по айпи адресу ( транк ) а по логин паролю, проблема в том что при смене айпи, не происходит перерегистрация на сервере провайдера и поэтому провайдер продолжает слать ртп и сип запросы по старому айпи. Но как видишь человек молчит - видимо проблема решена.

 

[igor.snezhko]

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

 

[anonymous]

Если оборудование провайдера готово к тому, что клиент может иметь трудности с указанием правильного IPort в SIP запросах и SDP, то с исходящими звонками проблем быть не должно
С входящими могут возникать проблемы, поскольку местоположение клиента может измениться в любой момент (смена адреса), и до следующего запроса от клиента (например обновление текущей регистрации), по которому можно получить новый IP, клиент будет оставаться недоступным.

 

[vpaulo]

именно про это я и говорил, что нужно например уменьшить таймер перерегистрации на стороне провайдера скажем до 5 минут ))) и тогда входящая связь будет быстрее "налаживаться" ))