Добрый день. Подскажите, возможно ли настроить SIP trunk, как резервный маршрут для вызовов через ABC-IP link? Хотелось бы в случае отказа ABC-IP link переключаться на SIP trunk. Думал, что это можно сделать просто с помощью ARS. Оказалось, что не так уж просто. Опишу ситуацию: 1. Обычно настраиваю Inter-node link, VPN overflow и Routing No. префикс для маршрутзации вызовов на другой узел, а также ARS лист. Только сегодня понял, что ARS лист не используется, то есть вызовы не в ARS уходят, а напрямую на другой узел через Inter-node link и VPN overflow. 2. Если строго следовать документации, то настраивать Routing No. не нужно. Но без него вообще не работает. Во время набора номера загорается "Неверный номер" и потом "Повесьте трубку". То есть система не понимает, что делать с таким набранным номером. Что, в общем-то, логично.
Вопрос заключается в том, как заставить VPN Overflow работать через ARS и как потом в этот ARS вписать SIP транк. Заранее прошу прощения, если это примитивный вопрос (на форуме найти ничего похожего не смог). А также спасибо всем ответившим:)
Ноде - для перетекания при звонке на другой узел, нетворк - при перетекании при звонках в другую сеть. Пока у вас два узла в одной сети - теоретически и нетворк можно прописать, а если три станет?
Здравствуйте, Хотел бы задать возникший вопрос, близкий по сути к данной теме, надеюсь, топикстартер не против.
Есть две ноды одной ABC - сети, соединённые ABC-F full ip hybrid link'ом. Для обработки обрыва линка (отсутствие ABC-F сигнализации) на ноде А прописан node access prefix с маршрутизацией во внешний ISDN транк (будем считать PSTN) - то есть, как я понимаю, настроена функция private to public overflow. При обрыве для вызовов к абонентам ноды Б от абонентов, непосредственно подключенных к ноде А эта функция отрабатывает корректно (при условии правки phone feature cos), но для вызова, пришедшего из вне (с того же самого внешнего ISDN транка) к абонентам ноды Б получаю отбой с причиной destination out of order. Нормально ли это и если нет, то какие настройки в данном случае могут влиять на транзитные вызовы из публичной сети к абонентам удалённой ноды при неработающем abc-link'е ? Как я понимаю phone feature cos для trank'а не существует ?
вопрос интересный. для начала стоит посмотреть разрешен ли вообще транзит транк-транк в connection COS (с 5 на 5-ю категорию). если я правильно понимаю, то у вас на узле Б есть абоненты, которые получают вызова от транков, физически включенных в узел А?
У Дарта Вейдера в столе всякого навалено: карты разные галактик и портрет Гагарина.
посмотрите еще параметр system > incoming DID overflow priv. to public. по идее надо поставить 2 - перетекание в случае состояния линка out of service.
У Дарта Вейдера в столе всякого навалено: карты разные галактик и портрет Гагарина.
Здравствуйте, Решил написать в этой же теме, так как вопрос близкий.
Подскажите, пожалуйста, есть ли в OXE R9 средства для реализации следующей схемы: Имеем: 2 УАТС, соединены H323 транком (настроены speedial), никаких ABC нет, обе УАТС имеют соединение с ТфоП через ISDN.
На первой УАТС объявлен ip домен 0, куда помещены все ip-интерфейсы этой УАТС и домен 1 с определённым диапазоном IP-адресов включающий ip-интерфейсы 2ой УАТС. В домене 0 - max voice connections = -1, в домене 1 - max voice connections = 1. Как и следовало ожидать первый вызов в направлении "уатс 2" проходит без проблем, по второму получаем "resourse unavailable".
Есть ли механизм который можно использовать для рерутинга 2ого вызова в ТфОП ? Как я понимаю private to public overflow без ABC не работает ?
Реализуется и через ARS, смотря чего и как хочется набирать. По идее и тупо через SD может сработать. Ячейка 3, call number IP_TG+3 (хотим набрав 3000 послать 3000) Ячейка D3, call number ISDN_Tg+2103 (набрав 3000 через город посылаем 2103000 - пример, когда городской номер отличается от внутреннего).
Теперь в ячейке 3 находите поле Overfl.Dir.Abbrev.No Pref. и пишите там D3.
Т.е. не имея возможности набрать 3000 в IP - попадем в другую ячейку.
То-же через ARS ячейка 3, call number ARS префикс+3 ячейка 4 (для примера), call number IP_TG+3
и собственно ARS с двумя рутами: 1 - TG=-1, удалить 1-у цифру, добавить 4-ку (используем внутренний роут на SD 4) 2 - ISDN TG и чего надо делаете с цифрами
PS - Чего вас так вставляет писать в старые темы - чтоб тяжелее было пользоваться поиском и дальше листать. НИЧЕГО общего у вас нет - ни sip, ни abc-f - по названию никто не догодается о том что обсуждаем.
vad пишет: Вы все-таки чего хотите? Сигнализация между узлами имеется?
Тогда это VPN overflow, через ARS с указанием SIP TG, dialing command table с указанием команды I (insert) и SIP GW (внешнего).
А эту схему кто-либо тестировал, с VPN Overflow через SIP TG ? При попытке реализовать, вызовы через SIP TG не идут, в lookvpn SIP TG видна как OOS, supervised by routing на ней не включить.
Remote net на SIP TG выставлена как в VPN Overflow, все сделано через ARS, SIP EXt. Gw - In Service. Судя по трассе, она даже не пытается выйти через SIP, нет инвайта.
Если supervised by routing на ней не включить - значить как TG для VPN overflow ee использовать нельзя. В ней нет реальных доступов - соответственно не создать Х25 кластер для ресурса. Но собственнно не вижу в этом плане никаких проблем (если у вас 2 ОХЕ с VoIP, которые могут достучаться друг до друга - ведь сигналинг у вас ходит) - пропишите кроме SIP еще и H323 TG. Мне казалось, что нет особых проблем в одновременном существовании - SIP сигналинг на проце, H323 на VoIP плате, кодеки используются для тех звонков которым они нужны.
Конечно никаких проблем, лицензий вот только нет, а так все в порядке, отчего бы и не прописать H.323 TG. Кроме того, причем тут компрессоры на плате не вполне ясно, т.к. релиз 9 и вызов, например, между двумя IP Touch.
Про компрессоры я упомянул просто в том плане, что при включенном Direct RTP они все лежат в одном пуле и будут использованы там где надо. Надо ли их будет - я ведь не знаю - кто у вас звонит, какие требования по кодекам с разных сторон. Лицензии - можно и докупить если у вас окрыты лицензии на сеть - вы чем планировали объединять станции? В конфигураторе (Актис) упоминание про ABC-F есть только в разделе H323 (в разделе SIP никто поддержку ABC-F не обещал).
С лицензиями история отдельная, как планировал объединять тот, кто рассчитывал в актисе, - неизвестно. Однако, была надежда что через сип все же можно, но озвученный вами ранее сценарий, к сожалению, не работает. Хотя, Private to Public Overflow через SIP работает, с ограниченной функциональностью, по сравнению с VPN Overflow. Вообще, очень жаль, что SIP до сих пор так и не прикручен к ABC сети, кроме ABCF TG.
если у вас окрыты лицензии на сеть - вы чем планировали объединять станции? В конфигураторе (Актис) упоминание про ABC-F есть только в разделе H323 (в разделе SIP никто поддержку ABC-F не обещал).