виртуализация стоит 7 центов, горячий резерв - да, дорого, но это вопрос отказоустойчивости, она никогда дешевой не была.
по опыту 4760 - номальная синхронизация АД позвонляет иметь справочник организации - с отделами, комнатами, должностями из которого еще и позвонить абоненту можно по протоколу STAP (кликнуть на номер в экране справочника, связанный с этой учеткой клиента справочника настольный телефон начнет звонить по кликнутому номеру), почту отправить и т.п.

усли есть Актис - можно клепнуть в help на этой странице - там коротенечко расписано что-зачем.
1) у 4760 мягко говоря никак не решался вопрос с горячим резервом сервера, в 8770 это есть.
2) можно ставить на виртуальную машину без выделения физического сервера
3) это нужно для того, чтобы внешние приложения тарификации получали данные от ОХЕ
4) пишут про двухсторонню синхронизацию. в 4760 этот делалось экспортом-импортом LDIF файлов.
1 и 2 нужно, 3 - нет, 4 - надо подумать. Если уже есть АД и там бардак с телефонными данными, наверно придется повозиться с синхронизацией. Не знаю как у Вас, но обычно там обращают внимание на логины-пароли-доступы, а к личной информации относятся с пофигизмом. 8770 имеет возможность иметь своих клиентов директории - с нормальным описанием атрибутов

в актис есть галка - миграция 4760 в 8770.  для вашего числа клиентов 4760 и количества абонентов разница в цене - процентов 15% при покупке с миграцией или без нее (в ценах WPL)

ваша проблема - в сообщении Connect в котором есть Bearer compatibility
для того, чтобы алкатель по получении такого сообщения переходил в разговорное состояние, нужно поставить в true
параметр по пути: system > other system > system parameters - specific EI status for GSM.
в 49 патче релиза 10 это уже есть, у вас более новый - попробуйте.

по первому вопросу - это нормально.
и соответственно по второму - тоже. если у вас нет пингов между GD и CS - работать ничего не будет. если упростить до предела - то CS управляет GD, а GD управляет всеми платами в медиа-шлюзе где она стоит.
они у вас в одной подсети GD и CS, поэтому можно включить их в коммутатор на CS там для этого есть 4- порта коммутации.
если все туда и включено и пачкорды вне подозрений, - тогда настройки. скорее всего надо поправить на GD.

а в чем проблема с дозвонами? если абонент вне зоны не слышно голосовой информатор? или что-то другое?

два входящих приходили на один номер? или может это было два номера на кнопках мультилайн?

а сам инцидент что же не покажете? не у всех есть под руками А4400 с таким древним релизом. Инцидент такой:
ABCA. Dow: file %c%c%c%c ope P1, format error P2 errno P3 (%c%c%c%c)

P1 : File (first four characters of the filename)
P2 : operation (operation code)
- 0 : file opening
- 1 : file reading
- 2 : extension file format checking
P3 : error (byte indicating the extension format erreur type)
- 10 : no format error
- 11 : incorrect extension number
- 12 : incorrect entries description format in extension file
- 13 : too many entries described in the extension file
- 14 : too much characters in the entry name, (limited to 4)
- 15 : description file name not in DOS format
- 16 : incorrect description file version
- 17 : repeated entries
- 18 : mandatory entry absent in the extension file
P5 : supplementary information
- entry name (si incident : entree mandatory not present, or entry repeated)
- Nb max entries in the PABX
- Nb max character in entry name
SBC Guide mode structures initilization incident
Incident received when the application saw a format error in the extension file
The Guide/Service/Trunk mode will not be available on the SBC
no operator action required

эта плата работает начиная с i1.605.37a в 9.1 (фичи на уровне стандартной eZ32). ставьте, проверено.

JKS, если продолжите эксперименты с WIN 7 - имейте ввиду следующее:

на Windows 7, запускайте клиента первый раз в режиме 'Run as Administartor".

нужно для того, чтобы обновился файл 'jssecacerts'  в папке ProgramFiles\java\lib\security\

только после обновления клиент сможет соединится с сервером.

Если не помогает - удалить 'jssecacerts'  в ProgramFiles\java\lib\security\ и попробовать снова запустить с правами администратора.

Если красный диплом долго отваривать в кипятке, а потом полученный отвар втирать в голову - ситуация улучшится.
А если серьезно, то классик жанра "просто о сложном" - Борис Соломонович Гольдштейн - "Сигнализация в сетях связи. Том 1" издание 2001 года

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

в целом в аппаратах 9-й серии чуть хуже работает дуплекс в громком режиме, чем в тех же аппаратах 4020-4035 (субъективно).... но вряд ли с этим можно что-то поделать на уровне бинарных файлов АТС.


самое простое - у вызываемого абонента включить mute - отключить микрофон. если при этом вызывающая сторона слышна нормально - мешает что-то в помещении, на столе и т.п.

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

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

в старых версиях аналоговых плат = z24, зачастую вызывная цепь сгорала при систематических перегрузках.

по идее команда rstcpl должна возвращать вашу аналоговую плату из этого состояния к жизни. не пробовали давать эту команду?