так проблема с телефонией или mgr?
mgr при выключенной телефонии - не должен работать. Если хочется что-то поделать - надо стартовать телефонию. Хотя бы в минимальном объеме - команда RUNMAO. реально платы работать не будут, но менеджментом заниматься будет можно.

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

Не помню точно (лень лезть в доки) - вы можете перейти в ограниченный режим:
1) превышение лицензий (абоненты)
2) отсутствие синхронизации со станцией, которая прописана для контроля лицензий.

Для выхода - надо устранить проблему (провести глобальную синхронизацию со станцией, убрать лишних абонентов). Мне помнилось в нормальный режим должно перейти через 5 дней.

Потому что с 4039 работают консоли на 40 клавиш, на 10 и на 14. А 20 клавиш - это от аппаратов другого типа (4020/4035).
С 4039 можно:
10
40
40+10
14 (+14(+14))

Глянул точнее - с релиза 6 работает без проблем. А вообще похоже - по занятости стала работать с 5.1.2 Lx
В вашем 5.0Ux - работать не будет.

Что происходит при звонке на человека, заказавшего переадресацию:
1) просто "занято" вызывающий получает
2) у вызывающего - КПВ (уведомление о вызове, предложение заказать "обратный вызов"?

Глянул - должен работать.
Пара вопросов - аппарат multi-line - может он не занят?
Не переадресовывается при внутренних звонках или внешних (т.е. ему откуда звонят)?

Что-то мне помнилось - что у Алкателя - не предусматривался форвард по занятости на внешний номер, надо будет глянуть feature list.
А если не секрет - зачем это надо (безусловная или по неответу - понятно, человек ушел. А по занятости? Человек сидит на рабочем месте, разговаривает - а вы на его сотовый переадресовываете?)

Обычно - прописывая новый (пустой) узел - прописывал IP адреса, задавал номера узлов (в netadmin и system), линк, делал рестарт.
После этого - настройка объектов для броадкаста, аудит - General check (только построение базы, указав центральный узел как референс).

Далее - уже все остальное. По идее - должны появиться другие узлы. (в Х25). Иногда в Х25 - по этим узлам что-нибудь настраивается (IP или IP/X25 адресация используется).

Ну и для всяких пингов - проверяем настройку маршрутизации (смотрим команду route).

А вы ждали некоторое время?
Когда вы создали узел - нужно, чтоб информация с роутинг нода разбежалась по другим узлам. На тех узлах в supoutage должен был появиться новый узел (и в Х25/узлы сети).

Вам (если это тестовая) - может сначала базу обнулить (empty database через swinst сделать), а потом снова накатить какие-нибудь ключи и базу?
Если говорить про С1.714 - есть и он, и патч 3 и 3af
Но все равно - сначала посмотрите что происходит. Это не похоже на проблему с процессором.

Еще раз повторюсь.
Когда доступ прописан в TG - будет до 30 разговоров (но при этом совершенно не факт, что будет задействована MADA, например при звонках с IP аппаратов - не будет.) по trkstat - вы увидите состояние TS - WB (without B-channel).
При звонках с выносов - ресурсы MADA по идее тоже задействоваться не будут (иначе - задействовалось бы по 2 кодека на одно соединение).

Для начала - посмотрите трассировки. просто t3 - как у вас что ходит при таких звонках.
Основной момент - не путайте сигнализацию и голос.
Сигнализация (Н323) пойдет с той платы VoIP, которая прописана в TG (например GD в центральной части). Соответственно - количество разговоров - будет не более 30 (на одну GD).
Голос (его вы увидите в трассировке - как адреса RTP портов) - может идти напрямую с удаленных GD (или прямо с IP аппаратов).

Т.е. ресурсы установления соединения (сигнализация) и ресурсы голоса (RTP порты) - они не связаны жестко.  

Поэтому - вносить в TG доступы с удаленных GD особого смысла нет. Это может иметь смысл - если у вас с выноса МНОГО звонков в сеть - тогда прописывая доступ локальной GD в транковой группе вы решаете некоторые проблемы - увеличиваете например количество одновременных звонков.
Но и тогда - по исходящей связи лучше создать ОТДЕЛЬНУЮ TG - и звонки с выноса разруливать в нее (например не указывая в ARS роуте TG, а указывая TG в домене, и в ARS руте говорить - источник TG=домен).

Поэтому, повторюсь - смотрите трассировки. Если не нравится откуда берутся кодеки - тогда что-то можно поделать.

Тогда все - надо прописывать с динамической маршрутизацией. End node - это узел где прописана в линке статическая маршрутизация. Он все чужое отправляет в сторону routing узла, к которому подключен.
В вашем случае - надо везде писать динамику. При этом - в VPN оверфлоу на каждом узле - должны присутствовать ВСЕ VPN оверфлоу.

1) Бэкбон и роутинг - вопрос только в терминологии. С точки зрения менеджмента - разницы нет. Бэкбон - это узел, к которому не подключены end ноды.
2) с точки зрения броадкаста и аудита - с других узлов по идее берется только информация о ЛОКАЛЬНЫХ ресурсах. Т.е. с центрального узла не будет браться информация об абонентах и транковых группах с других узлов. Я думаю самое правильное - просто создать на присоединенном узле нужную TG ручками.
А пробовали для вновь подключенного узла сделать сначала аудит General check? Я не помню - подгрузятся ли при этом "узлы сети"? Может после этого - появятся (для аудита/броадкаста) узля сети - тогда он будет забирать оттуда и информацию об абонентах/TG.