Глянул - должен работать.
Пара вопросов - аппарат 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.

Это наверное потому, что вы в calling number смотрели только цифры номера (3422104000), а надо еще тип звонка смотреть. У вас идет 80. Мне помнится должно быть 21 81 (не помню, искать трейсы лень, но звонок должен быть ISDN National), а у вас какой нибудь Unknown.

Не всмотрелся в трейс, у вас оказывается QSIG.
Переделка точно работает для ISDN/private/master.

Для QSIG или ABC-F - не факт.

Аппарат - в юзерах (но может и нет его)
Можно через фильтр - по типу S0
Можно по номеру порта (который юыл у цифровика) - если помните.

У вас в свойствах аппарата скорее всего стояла галка S0 extention (возможно - еще в shelf/board на данном интерфейсе была прописана шина S0, и был создан S0 аппарат).

По идее - не должно было позволить поменять тип аппарата.
В нормальных условиях - удаление/смена такого аппарат делается следующим порядком:
1) удаляется S0 аппарат
2) удаляется SO шина (shelf/board)
3) убирается галка S0 в цифровом аппарате

После этого с ним можно что-то делать.

Network mode = yes (естественно с той стороны - нет/slave/user  не знаю как оно там называется)

Проблема - когда Directory Manager пароль заблокирован.