По поводу нормально или нет - нормально. Процессор от ящика берет только питание, GD (через которую происходит управление всеми платами) общается с процессором ТОЛЬКО по Ethernet. Соответственно, если проблемы с коммутатором - это все равно, что не работающий процессор.

Соответственно часто это безобразие включают в локалку по другому:
- порт LAN процессора включают в разъем Unit 1 процесора;
- порт LAN GD включают в разъем Unit 2 процессора;
- порт Up-Link процессора включают в коммутатор локалки.

Т.е. на процессоре обычно стоит дочка - 3-х портовый коммутатор, им и пользуются. Есть он или нет - сразу увидите по морганию/не морганию светодиодов Unit 1, 2 и Up-Link.

В чем сейчас проблема - сказать тяжело, надо втыкаться com портов в GD (в правый верхний RG45, наверное config обозначен) и смотреть чего пишет. Втыкаться можно стандартным цисковским синим шнуром для ком порта (только надо RG45 перехлопать, повернув на 180 градусов). Скорость 9600-8-N-1, контроля передачи нет.

на коммутаторе какие то ошибки присутствуют? VLAN пользуетесь? GD на статическом адресе или получает его по DHCP?

Синхронно ответили  

в транковых группах обычно 5-я стоит, соответственно в COS/ Connection COS 5 - не должно быть 0 в 5-й позиции.

Через какой АА набираете, стоит ли в SD  галка на barring, разрешен ли транзит по connection COS.

делалось и проще - можно заказать и получить винт с вашим ПО.

А станция дублированная? Тогда один проц остановить - и на нем все приготовить.
Особенно если CPU7 - все быстро пройдет.

Мне в этом плане еще интересно - как редирект дружит с System/ other system/ ext. signaling param - NPD for ext. forwarding? Не надо ли там вместо -1 что-то доброе поставить

Так вы трассировку t3 смортите. В SETUP кроме calling и called номеров, появится еще и redirecting number.
Хорошо видно (для примера) если со своего сотового сделать переадресацию на номер в ОХЕ и позвонить откуда-то на сотовый.

Данный пункт вроде отвечал за отображение номера на дисплее вызываемого абонента ОХЕ (например кто-то  А звонит на сотовый В, а с сотового заказана переадресация на абонента ОХЕ С - что увидит абонент С при входящем звонке - А или В). В ext.signaling вроде еще одно поле есть - Redirecting number and source nb - видеть ОБА номера А и В.

В презенташке по 9.1 было упоминание, что ОХЕ при внешнем форварде может выдавать redirecting number (в IE Redirecting number или Diverting Leg info2), но я это лично не искал/не находил.

С прямым транзитом АОН (когда он идет в calling number, без forwarded/redirecting поля) - надо быть осторожнее. Не видно кто эту переадресацию заказал. Когда АОН транзитом уходит не в вашу приватную сеть, а в город - город или будет отбивать эти звонки, или регистрировать/тарифицировать на ваш пилотный номер в потоке.

Не пробовали прописать заново SIP TG с внешним SIP шлюзом? Были прецеденты, когда это помогло. Но детали - может Ryzhakov точнее симптомами поделится.

В старых релизах 9патчах) станция иногда не любила когда в Alert приходила всякая дополнительная информация (progress, информация по кодекам для IP и т.п.). Собственно если станция наша посылает Status - это не хорошо. Надо смотреть чего не нравится. Но у вас это ведь ОЧЕНЬ редко? Раз трассировку снять не удается.
А не пробовали сами выявить ситуацию, а когда собственно проблема - просто звонок на абонента, звонок на занятого абонента, звонок на выключенного абонента?

В System есть пункт "With LLC HLC" который отвечает за посылку данного информационного элемента.
Кроме того - стандартный набор телодвижений:
- system/ other system/ ext. signaling param - не посылать Status.
- system - React.Receiving State Mess. - ставим "игнорировать" на нужные события - типа "Ignore ISDN Fault In Mandatory EI".

наверное так (если 96118 не показывает в абонентах):
cdmao
cuser
delete fr om tabtrad wh ere number=’96118’; (не нравятся форуму слова "fr om" и "wh ere" - пробелы туда вставляет
сommit;
.(точку надеюсь не забыли)

Но повторюсь - удаление из базы через cuser - на свой страх и риск. Бывает что после правки чего-то checkdb начинает показывать другие ошибки. Удалили цифрового абонента из poste - вылезут ошибки в ralbit и noe_param.
Но с другой стороны - если есть проблема, если базу перед этим сохранили и есть возможность рестартовать станцию - проблем быть особых не должно.

данная команда перезапустит процесс. Просто отдельно останавливать и отдельно включать не пробовал.

по идее (удалив предварительно абонента 71018 сделать бы надо было следующее:
cdmao
cuser
delete fr om ???? wh ere nulog=17;
(тут должно показать что найдена одна запись)
(почему то "fr om" , а также слово "wh ere" разбавились пробелами, это слова "из" и "где")
commit;
. (точка!!!)

Проблема в том, что я не помню какая таблица (я написал ????) отвечает за план нумерации, может что-то типа plannum (или еще как, не помню, станции под руками нет).
можно (после команды cdmao) искать нужную таблицу с помощью команд:
ll - покажет все, чего лежит в базе
fichges - позволяет кое-чего делать с базой, по умолчанию должен выползти хелп. Если ничего не путаю:
fichges -dump имя_таблицы   (позволяет посмотреть содержимое разных таблиц, типа fichges -dump poste - покажет абонентов).
Так что осталось найти имя таблицы где лежит 96118 и использовать ее в команде cuser вместо ????

Естественно перед этим базу сохраняем, а после - делаем рестарт. Главное при cuser смотреть - найдены или нет соответствующие записи. Но это все на свой страх и риск