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

Куда смотреть? Показываете t3 трассу и спрашиваете, что не хватает.

У вас - здоровая сеть.
Инцидентов - хватает (мне всегда казалось, что при наличии инцидентов - количество начинает переходить в качество).

Разберитесь с сетью (работает или нет) - suproutage вам в руки.
Далее - разберитесь с броадкастом. Включен или нет на узлах. Что разрешено рассылать/принимать, что нет. Т.е. или выключить везде (или по зонам) или включить везде, настроив что вас интересует.
После чего рестартуйте броадкаст - cleanbroad по всей сети (если он включен)

Повторю вопрос - т.е. были рабочие инциденты и все - никаких слов - что shutdown вызван и т.п.?
команда last  что показывает (она в 5-м есть?) - есть коннекты, кто вызвал рестарт

Был VH. Не помню чем с ним сердце успокоилось:
- при работе от 220 - практически сразу уходил в ребут (причем инцидентов не было)
- при работе от АКБ - работал!!!
- поменялись корпусами с учебным - т.е. переставив платы из одного в другой - оба VH продолжили работу.

А инцидентов - точно никаких нет? Т.е. были обычные - и бац? Никаких - что система пошла на перезагрузку и т.п.?

Присоединюсь к etc - бывает интересно переключить БП в режим 54В - если снять верхнюю крышку и крышку закрывающую БП увидите перемычку 44/54. Переключить на 54В, подстроечным резистором рядом - выставить 54В.
Посмотрите неисправное оборудование (listout). Если есть закороченные комплекты Z (MISCALL) и не рабочие UA - рекомендуется проверить.

Насколько регулярно уходит в ребут - утром/вечером/когда попало - может у вас проблемы с питанием/землей?

1) VG - это voice guides. Если вы не знаете про них - лучше попросить хелп у людей, кто ставил/обслуживал у вас станцию.
2) должен быть префикс (или его надо создать) например #44 - Set feature, Forward on no replay. Соответственно для заказа надо набрать #442000 (если требуется переадресация на 2000). Про категорию вопрос не понял. Организовать длинную цепочку переадресаций вам так просто не удастся. Можно что-то придумать, но сначала разберитесь как просто переадресация работает.

1) Какое железо - CS\GD или GPA2? Как VG на станцию положить/поправить - знаете?
2) с переадресацией - набираете префикс переадресации по не ответу (должен быть в префикс плане) и куда. Если требуются разные времена - надо использовать разные Phone feature COS - где есть параметр Overflow Noreply Timer. В старых релизах - все переадресации срабатывали по одному таймеру.

Собственно вопросы:
1) проблема с набором ЛЮБОГО номера (город, межгород и т.п.)?
2) тип набора - тон или импульсный?
3) нарисовано ли в транковой категории детектирование сигнала "ответ станции" (External services/Trunk COS - item "default transmission")?

Можно - просто положить файл swk в папку /usr3/mao под именем software.mao (если не путаю). Но так делать не правильно.
Требуйте с поставщика полный комплект OPS файлов.

Адреса CPU и VOIP плат прописаны в доступе , пинги есть во все стороны
Т.е. вы прямо заходили телнетом на GD на периферийной станции и пинговали GD другой периферийной станции (пинг с процессора на GD не считается - адреса разные, шлюзы могут быть прописаны разные и т.п.)?
Кроме того - ping  и VoIP трафик - это разные пакеты, могут быть проблемы.
Собственно что делаем - звоним с периферийной на периферийную - смотрим t3 трассировку. Пытаемся понять как идет голос. Разбираемся с маршрутами с указанными адресами/портами.
Кроме того:
- у вас звонки с периферийной на периферийную прямо идут или через центральную станцию (набранный номер направляется в центр, а та разруливает звонки).
- UTF8 имена в сети - у вас везде разрешены?

Правильно я понял:
- с центральной станции можно позвонить на любую из периферийных без проблем
- с периферийной на периферийную позвонить можно, но голоса нет?

Тогда это скорее всего проблема сети передачи данных. Во время звонка станции договариваются об IP адресах (хорошо видно в t3 - если звонки по H323).

И пакеты с VoIP платы одной периферийной станции не добегают до VoIP платы второй периферийной станции. У вас в сети передачи данных:
- или один периферийный маршрутизатор/коммутатор - не знает где находятся нужные адреса
- или в access lists - не прописано, что разрешено пропускать пакеты с таких адресов.

Я правильно понимаю - есть VIP клиенты, которым воспроизводится сообщение, их звонок проваливается к оператору (у того есть информация на дисплее, но  он не смотрит), и вы хотите еще и операторам что-то говорить (оператору одну, клиенту другое)?
Может оператору объяснить, что он не прав и должен смотреть на имя пилота? Была в одном колцентре (Англия) проблема - у операторов выпадали шнуры телефонов из розетки (и они переставали принимать звонки). После того как одного оштрафовали на 200 фунтов стерлингов - выпадать шнуры перестали.

Пара мыслей - уберите с платы DECT8 галку о DTM (у вас пара CPU7 - этого достаточно для синхронизации DECT, в приведенном выводе синхронизация DECT была от CPU7 0 20)

Если поток добегает от провайдера по SDH - там тоже должна быть синхронизация (в SDH). Косвенным признаком проблем - могут быть проблемы с факсами (если они есть).

А так, если инциденты с INTOF возникают каждую пару минут - убираете с Е1 синхронизацию (ставите 255) и смотрите. Если проблемы с INTOF пропали - тогда вам предстоит разбираться, что у вас в SDH с синхронизацией.

Плат INTOF нет в выводе по infocs - потому что они не причем в этом вопросе. ITNIP упомянут в разделе синхроницации DECT. Для работы баз DECT на IP выносе  - будет использоваться генератор (условно) с платы INTIP.

Про смену плат - я имел в виду - физически поменять платы INTOF A и INTOF местами (т.е. 0-8 поменять местами с 2-20). И посмотреть.
Если длина оптики 2,5 км по одномодовому волокну - проблем быть не должно.
Но все равно  - проверьте - хорошо ли подсоединены патч-корды и т.п. Встречал Заказчика, который считал, что FC разъемы надо недокручивать (чтоб не повредить поверхность), работа с воздушным зазором - вещь забавная.