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 разъемы надо недокручивать (чтоб не повредить поверхность), работа с воздушным зазором - вещь забавная.

Не понят вопрос.
По категории - routing mode at-off hook
Абоненту - категория и routing table
А что написано в routing table - внутренний номер или 810ХХХХХХХХХ - разницы нет.

И в догонку - подключение INTOF какое? Оптика, медь? Как далеко?

Никогда не задавали приоритеты синхронизации для INTOF. Это ведь приоритеты синхронизации системы.
Т.е. если поставить (например, теоретически, если получилось бы)) 0 на внешнем Е1 и 10 INTOFB:
- пока есть Е1  - ВСЯ система подстраивается под этот поток
- пропал Е1 - вся станция (и 0-й АСТ то-же) должна начать синхронизироваться от INTOFB (от своего же!!!)

Поэтому - ничего не ставим в INTOF в плане синхронизации.
При проблемах с INTOF:
- оставьте одну пару - посмотрите нет ли там проблем.
- аналогично на одной второй паре.
- внутри пары - можно поменять местами А и В платы (бывают нюансы)

Ну и естественно - интересно посмотреть infocs

Пара вопросов - вы пишете ВОССТАНОВИТЬ адрес - это означает, что работало и перестало? Или плату поменяли?
Просто в зависимости от того ЧТО произошло - немного разный подход к решению проблемы.
На процессоре при попытках GD-3 обратиться к нему - что-то пишет в инцидентах?

В общем без разницы к кому обратиться. Вы правда так и не написали - что у вас приключилось (всем ведь интересно).

SIP трафик будет идти по сети передачи данных (LAN, WAN).
Вы должны попасть с IP адреса вашего процессора на IP адрес SIP шлюза
и голос должен попадать с адреса VoIP платы у вас на адрес VoIP платы провайдера (он не всегда совпадает с IP адресом шлюза).
Если обе сети обладают private адресами (типа 10.х.х.х, 192.168.х.х), а ходят через публичную сеть - могут быть проблемы с NAT.