Есть установленная станция ОХЕ релиз 9.1 Станция состоит из двух CS на серверах HP Так же станция имеет порядка 60 телефонных выносов географически разбросанных. В каждом выносе установлена GD и PCS, также несколько периферийных плат (MIX, SLI8-16, и APA4. АРА4 не используется с MIX только цифровые и аналоговые аппараты) По факту с данных выносов звонок только в центральный филиал.Конечно планировалось что станция будет подключатся в своем регионе по СО, но при работе сразу от этого отказались, ведь если рвется VPN туннель станция перезагружается, а это время на перезагрузку плюс регистрацию = очень долго. И в этот момент нет ни какой связи ни локальной ни городской.
Задача состоит в следующем, необходимо рассмотреть возможность переделать не много всю систему. А именно внедрить IP телефоны, по возможности вообще отказаться от выносов совсем. За почти 5 с лишним лет проблем от данных выносов больше чем пользы)))). Понятно что не везде есть хорошее электропитание, и стабильный интернет канал. Тем самым постоянные проблемы с GD либо на ней слетает программное обеспечение, либо она просто висит. А я как обслуживающий персонал не могу до нее достучаться, пинг проходит и все. Телнет недоступен ничего не доступно.
Хотел бы вот и спросить у знающих людей как лучше организовать систему, имеется ввиду в центральном филиале стоит станция и один вынос со всеми периферийными платами. А во всех остальных просто IP телефоны, и в редком случае вынос.
Также хотел бы узнать поддерживает ли сейчас ОХЕ IP аппараты сторонних производителей (Желательно вообще использовать SIP), не просто поддерживает а именно работают ли они стабильно без глюков и сбоев.
все как в рекламе рекламе "...не любишь кошек?! наверное просто не умеете их готовить"
тут осталось только выяснить 1. выносы распили по доменам 2. привязка GD к PCS
вместо 60 выносов ставить ip-phone с регистрацией с одного места заведомо тупиковая идея, там проблем еще больше чем вы думаете, на первых парах проблемы типа этих: - если канал связи будет не стабильный то ip-телефон будет часто перезагружаться - кривизна маршрутизации, голос не бегает в одну сторону - инкапсуляция. был случае - удаленном объекте 10 ip-телефонов, работали любые 3 и только, остальным "балалайка"
у вас три пути - настроить ваше хозяйство грамотно - на каждый вынос поставить по CS - либо смотреть в стороне opensource
был один проект - 4 крупных города, выход PSTN через Москву, туево-куча ip-phone, выживаемость - при падении узлов в 3-х городах чтобы все работало. заказчику не устроило лишь opensource, пошли по пути брендов
Если с IP все плохо - ничего доброго SIP не даст. Кроме того надо определиться с требуемым сервисом - директор/секретарь, имена нужны? Возможно вам стоит: 1) посмотреть на предмет старости релиза/свежих патчей; 2) посмотреть - чего у вас с доменами (засунуть удаленные GD в отдельный домен, ограничить количество одновременных соединений за пределы домена - раз у вас плохо с каналами). 3) купить несколько IP телефонов и поставить на какой-то площадке, сравнить (поймете плюсы,минусы).
Сразу извинюсь что не быстро отвечаю, конец года коммандировки и все такое.
Уважаемый Error
1) выносов кажется 72 вообще, каждому выносу присвоен свой домен. Инсталляция была произведена хорошо, не глупым инженером. 2) Вся привязка выполнена MAC адресами.
Смотрите как сейчас это все, чуть что работники выноса бегут ребутить станцию)))), потом пытаются доказать что она не работает. Не оспоримым фактом являются только логи с Cisco где видно что канала не было.
Поэтому из трех путей развития 1) АТС сейчас настроенна грамотно, 2) На каждый вынос свой CS, это очень здорово настроил IP каналы и все работает. Пропал канал нет выхода и все. Но Сеть построенна следующем образом в Центре стоит куча железа Cisco в филиалах роутер поднят VPN security, при звонке из филиала в филиал проходит только сигнализация через центр, далее роутеры филиалов строят временный свой канал напрямую. Если сейчас поставить свой CS в каждый филиал куча перенастроек, и плюс потеря общего биллинга и управления станции с одной точки, что очень важно. 3) Open Source не подойдет, так впринципе я за неделю бы всем Астериска поставил и в центр ввел.
Уважаемый VAD,
Я бы не сказал что бы с IP все плохо, но VPN строиться через интернет а там частенько что то не работает, Вот в Москве вроде все хорошо но примерно раз в год GD стреляет на ремонт))). R9.0-h1.301-34-ru-c0 версия ПО и пакетов
У каждой GD свой домен, в филиале максимум 20 телефонов в среднем 12, но исходя из ширины канала, ограничения инсталятор настроил, примерно 4 канала за пределы домена.
Я просто не знаю выше релиз я не пробовал, там такие же проблемы с GD, тоже нельзя зайти на GD по Telnet? Не хочу просто настоять на апгрейте, и в итоге картинка не измениться.
Если это так, то может есть смысл сменить оборудование возможно на Cisco, единная станция управление по MGCP и ни каких перезагрузок?
просто апгрейд я думаю будет подешевле, плюс хотят добавить номерной емкости, и расширить количество PCS.
Начиная с релиза (по моему 7) - на GD так просто телнетом не зайти. В свое время Алкатель предлагал следующее: 1) заходить ТОЛЬКО с процессора main (адрес main должен быть прописан в GD в mgconfig) 2) перед заходом надо "разрешить" телнет на процессоре через команду ippstat 3) вроде надо использовать команду telnet_al а не обычный телнет.
Все же проблема очень гемморойна, возможно просто дешевле приобрести лицензии для всех выносов, а на центральном филиале просто в лицензиях разрешить либо SIP либо H323, тогда если будет кратковремменое пропадание канала, просто не будет доступна связь между филиалами, но не будет никакого ребута и регистрации.
Так просто будет дешевле, и расширение после этого не проблема просто докупается комплекты и все.
На Астериске все было бы проще, так же как и Алкатель, ядро в центре, в филиалах свой Астер по сипу все подвязано.
Но тут суть в том что нужно централизованное управление и сбор данных и статистика.
Как вариант рассматривали замену на Avaya, но у нее похожая ситуация, перерегистрация связана с перезагрузкой. Если используются IP телефоны то изначально они все регистрируются на центральном процессоре, в случае падения канала перерегистрируются на пассивном процессоре, а вот у Cisco это все реализовано без перезагрузок как утверждает вендер.
Есть канал связи все работает под управлением центра по протоколу MGCP, канал упал роутер CUCM становиться мастером, без перезагрузок.
Вот тут как раз вся и проблема что делать дальше....
Пути решения проблем
1) Каждый вынос оснащать своим процессором своей лицензией и строить маршрутизацию по IP на Центр. Центр будет осуществлять только маршрутизацию звонков. Желательно тогда все выносы которые станут самостоятельными станциями подключить к омнивисте для сбора данных и статистики. Управление для меня удобнее через командную строку. (SIP, Н323 проблем с голосом не должно быть есть VPN туннель, в нем 2-а vlan один данные другой голос, голос имеет приоритет перед данными),
2) Использование OpenSource невозможно, необходима полная сертификация оборудования и возможность СОРМ. Это условие безопасности.
3) Переход на другого производителя.
Жалко конечно, Alcatel в центре в виде двух серверов и своего выноса в виде шасси М2 работает стабильно и без глуков в течение 5 лет.
Вся проблема связана с GD, нестабильность интернета вызывает падение VPN вследствие перезагрузка выноса, а при проблемах в электропитании выход из строя GD (программного обеспечения) неизбежно.
"The MGCP gateway maintains a remote connection to a centralized CUCM cluster, as shown in figure by sending MGCP keepalive messages to the CUCM server at 15 second intervals. If the active CUCM server fails to acknowledge receipt of the keepalive message within 30 seconds, the gateway attempts to switch over to the next available CUCM server. If none of the CUCM server responds, the gateway switches into fallback mode and reverts to the default H.323 or SIP session application for basic call control."
Т.е. переключение на резервный сервер занимает минимум 30 секунд после падения канала.
даже если и брать во внимание 30 секунд, даже 1 минуту, Перезагрузка и регистрация Алкателя это минимум 5-7 минут, как говорит мой знакомый курительная станция))), то есть можно пойти покурить))).
Андрей, ни кто саму станцию не перезагружает. Станцию за пять лет один раз я выключал для проведения планово профилактических работ, и раза 2-3 выключали по питанию.
Вся проблема состоит не в центральной станции, а в филиальных выносах. перезагружается сам вынос.
Когда теряет связь с центральной станцией она перезагружается для того что бы перерегистрироваться на PCS -е. это и есть 5-7 минут а того еще больше.
Про проблемы с электропитанием: а у вас что, выносы, где GD2 стоят, без батареек (в самых первых версиях корпусов они были внутренние, потом все - внешние)? Просто вынос "чувствует" напряжение на батарейках и при снижении его, плата GD2 корректно завершает свою работу (на это ей требуется несколько минут). Из опыта: имеется объект с порядка 40 выносами, за несколько месяцев проблем с GD2, GD3 не было, хотя проблемы с питанием были, но везде стоят внешние батареи.
ИМХО - если качество каналов связи под сомнением то и космический корабль не поможет
Цитата
Alexandr пишет: А сколько на одной омнивисте можно прописать ОХЕ?
сколько реально нод прописать честно говоря за задумывался грубо говоря на омнивесте лицензируте 5000 и добивать потом нодами, на этих нодах нет необходимости иметь лицензию омнивисты
Цитата
Alexandr пишет: Насчет циско и MGCP, пишут следующее:
красиво написано, так же можно написать и про аваю и про алькатель, но что потом будет иметь в реале - кластер в топку и все выносы распилить на standalone либо группировать секторами чем больше "курю" cucm тем больше убеждаюсь то проблемы одни и те же да тут
Цитата
Alexandr пишет: Как вариант рассматривали замену на Avaya
с моей точки зрения идея не айс (алькател по сравнению с авайя - прогулка по бродвею). ибо режим выживания на авайи пишется исключительно руками в консоли т.е. какой алгоритм описали так и будет работать тобишь автоматом такой конфиг не создается, а если что-то новое внесли в конфиг атс а про выживание забыли так и будите ломать голову на предмет "работает по разному до и после потери центра". режим выживания поддерживает определенное число терминалов, лишние терминалы уйдут в ourserv. да и придется изучать сам алгоритм выживания, спецов по этой теме почти нет да и с pri какая-то засада если приходят от нескольких провов, периодически бывают слипы когда синхра хромает
Цитата
Alexandr пишет: 2) Использование OpenSource невозможно, необходима полная сертификация оборудования и возможность СОРМ. Это условие безопасности
если оборудование выступает в роли терминации т.е. исключительно стык транзитного узла то СОРМ не обязательно иметь, можите заглянуть в положения. на сколько помню это называется "канальный коммутатор"
