ну значит вам одна дорога - центр пропатчить

хм... надо самому покопаться в PCS

ОПС-ом трудно будет поделиться, даже software.mao сойдет, у меня нет ни одной ОХЕ с PCS

дока по инсталл PCS есть?

хм... интересная комбинация
осталось выяснить GD загрузила софт с из центра или с PCS т.е. прямой намек на то что в центре софт для GD старый, а PCS новый

тобишь если софт для GD разный то в процессе перезагрузки еще идет апгрейд софта в ту или иную сторону

вроде последний патч для 9.0 h1.301.50a
все же стоит пропатчить а потом уж репу чесать

ближайший переход это до версии 11

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

используйте slan чтобы GD в ребут не ходила

на версии 9.1 с патча I1.605.21 есть поддержка GD-3

SLAN такая доч.платка которая устанавливается на CS/PCS, представляет из себя 4-х портовый свич

если внимательно посмотреть на CS то увидите в нижнем ряду Unit1, Unit2, Unit3 и UpLink

теперь как-бы все ясно

если на коммутаторе порт дернется хоть на секунду GD по своему характеру уходит в перезагрузку. во избежании такого инцидента французы на даром придумали такую штуку как SLAN которая устанавливается на CS/PCS. на SLAN проблем с 802.1Q нет
многие этой штукой slan пренебрегают как бесполезной штукой а зря
если какие-то проблемы в сети появятся то все будет аукаться на ip-телефонах, вынос с использованием slan по назначению не должен пойти в перезагрузки

у клиента стоит два CS-2  и GD-3, на slan-ы в CS-2 раскидали все коммутации с дублированием  и в этого спустя месяц обнаружилось что один СS-2 ушел на пенсию но при этом перезагрузки GD-3 не было

P.S. какой-бы не был гениальный установщик но всегда прокалывается на мелочи

два развития ситуации проходом через sip-пакета через nat
1. на L3 все это ограничивается парой строк host-to-host для того чтобы sip-пакет перезаписать
2. использовать средства АТС чтобы sip-пакет формировать от внешнего. ПЛЮС на коммутаторе/роутере сделать статический проброс портов что не является универсальным решением т.к. при таком выборе решения зачастую sip хакают и выливается все это в реальное бабло на международные звонки.

знаю один такой завод который пошел по пути 2 и все вылилось в 900 т.р. в международных звонках. и таких пострадавших везде полно с разной суммой

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

ИМХО -  возможность преодоления двойного/тройного и т.д. NATa в SIP транках  это все игрушки, очередной маркетинговый ход и только, надо же чем оправдать выход 10-го релиза

лан порты с GD и PCS идут на коммутатор или на slan

мутаторы L3 это делали еще при "царе горохе". это фича полезна при бывотом wi-fi роутере

когда алькатель дорастет до строки 8ХХХХХХХ в external callback translator тогда и будет вам счастье ввиде крыжика

ИМХО - если качество каналов связи под сомнением то и космический корабль не поможет
сколько реально нод прописать честно говоря за задумывался
грубо говоря на омнивесте лицензируте 5000 и добивать потом нодами, на этих нодах нет необходимости иметь лицензию омнивисты

красиво написано, так же можно написать и про аваю и про алькатель, но что потом будет иметь в реале - кластер в топку и все выносы распилить на standalone либо группировать секторами
чем больше "курю" cucm тем больше убеждаюсь то проблемы одни и те же да тут

с моей точки зрения идея не айс (алькател по сравнению с авайя - прогулка по бродвею). ибо режим выживания на авайи пишется исключительно руками в консоли т.е. какой алгоритм описали так и будет работать тобишь автоматом такой конфиг не создается, а если что-то новое внесли в конфиг атс а про выживание забыли так и будите ломать голову на предмет "работает по разному до и после потери центра". режим выживания поддерживает определенное число терминалов, лишние терминалы уйдут в ourserv. да и придется изучать сам алгоритм выживания, спецов по этой теме почти нет
да и с pri какая-то засада если приходят от нескольких провов, периодически бывают слипы когда синхра хромает

если оборудование выступает в роли терминации т.е. исключительно стык транзитного узла то СОРМ не обязательно иметь, можите заглянуть в положения. на сколько помню это называется "канальный коммутатор"

Нда уж... на выносах не люди а дикари из леса. "За чуть что - ребут" наказать рублем показательно что бы все видели.

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

Конечно можно переехать на циско но суть проблемы не изменится, рас атс ребутают то cucm ребутнуть рука не дрогнет у дикарей

Астериск с ущербным sip-стеком с алькателью фиговато работает
есть другие реализации opensourse

все как в рекламе рекламе "...не любишь кошек?! наверное просто не умеете их готовить"

тут осталось только выяснить
1. выносы распили по доменам
2. привязка GD к PCS

вместо 60 выносов ставить ip-phone с регистрацией с одного места заведомо тупиковая идея, там проблем еще больше чем вы думаете, на первых парах проблемы типа этих:
- если канал связи будет не стабильный то ip-телефон будет часто перезагружаться
- кривизна маршрутизации, голос не бегает в одну сторону
- инкапсуляция. был случае - удаленном объекте 10 ip-телефонов, работали любые 3 и только, остальным "балалайка"

у вас три пути
- настроить ваше хозяйство грамотно
- на каждый вынос поставить по CS
- либо смотреть в стороне opensource


был один проект - 4 крупных города, выход PSTN через Москву, туево-куча ip-phone, выживаемость - при падении узлов в 3-х городах чтобы все работало.
заказчику не устроило лишь opensource, пошли по пути брендов

скорей всего "таблица в БД не поддерживает unicode" либо "запрос в БД идет без поддержки utf8"
надо поковыряться в самой БД