Добрый день всем!
Подскажите, есть сервер * с двумя внешними интерфейсами и одним внутренним,
если поднять два транка (каждый через свой внешний интерфейс) до одного провайдера с одинаковыми учетными данными, то оба транка зарегистрируются или первый из них?
Смысл сего - получить доступность звонков извне к нам при проблемах у одного из интернет-провайдеров.

фигней страдаете
если отвалится один провайдер, сменится IP адрес и все клиенты отвалятся.
Филиалы объединяете?

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

Я взял маршрутизатро с двумя wan портами (Fortigate-50B) пробросил порты по обеим каналам. Создал домен, привязял его к обоии IP и клиенты коннектятся не по IP а по домену. При этом не важно какой у меня канал лежит, всё равно все коннектятся. Правда время коннекта после падения основного канала примерно 1-1,5 минуты.

А ещё лучше по моему поднять несколько IP-Sec VPN и что-бы клиенты коннектились по внутренниму IP через тонель. Так даже надёжней. Сделать несколько тонелей и выставить приоритеты. Я так тоже делал, очень удобно соединить так несколько офисов если в каждом по два интернет-канала.

При желании можно ещё чего нибудь придумать. )

а мы делаем так, что при падении канала межфилиальная связь вообще не рвется.

Телефоны локальных сотрудников коннектятся к локальному CCM, сейчас телефония приходить по PRI через циску, подцепленную к CCM по MGCP.
Хочется подключиться к sip-провайдеру (в будущем возможно отказаться от потока) с помощью *
Для резервируемости вход/исход связи планируется использовать канал интернет-провайдера.
Так вот - реализуема ли резервируемость SIP-телефонии ?
В идеале - при падении канала sip-провайдера, регистрация * на серверер sip-прова идет по интернет каналу.
Поиск ничего не дал.

Другие филиалы подключать не надо :)

аналогичную задачу разбирали на прошлой неделе.
варианты:
1) выкинуть астериск и сделать все на циске (в самом деле, зачем он вам понадобился? циска все умеет!)
2) не парить мозги и возложить задачу переключения инет каналов на маршрутизатор, а * убрать за NAT (так, поидее, по-людски делается)

1) CUBE (ip2ip gate) имеете в виду?
2) ОК. Возможны ли ситуации, когда маршрутизатор будет думать, что канал жив, а * потеряет регистрацию на сервере? Вот таких неприятностей хочется избежать, когда две думающие головы не сойдутся во мнении.

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

По-первому, вот сейчас и поднялся вопрос, на чем sip-proxy реализовывать, на cisco (бабло нужно) или на софтверном решении.
По-второму пункту я имею в виду, что линк последней мили будет жив допустим, а проблема у прова дальше. То есть инет не упал, а сервер по этому линку недоступен.
Ну и выбор в итоге сведется к самому простому в настройке и дешевому по цене решению.