Переход по занятости или переадресация?

На ваш вопрос можно ответить только - никак. А в чем проблема?
Обычно страшных проблем с QSIG при правильном менеджменте (сигнализация в TG ABC-F, указана некоторая remote network, в network routing table сказано QSIG-GF, звонки через routing number префиксы, с указанием данной сети) нет.

Есть некоторые нюансы по настройкам переадресации и т.п.

у вас на станциях - есть подключение к городу?
Берете и делаете по образцу и подобию. А E1 - это ISDN, QSIG, R1.5 или еще чего?

Мой вопрос был - какие транковые группы вы в состоянии прописать (что с той стороны - Авайа, Алкатель,S12 или другая станция) - какая разница. (а что запрограммировать в Авайя - я не знаю).
В алкатель по ISDN все просто

прописываете плату
в ниже вложенном пункте (digital access) - ставите или нет Network mode (на одной стороне да, на другой нет).

Создаете транковую группу - тип T2, сигнализация - ISDN all countries, number compatible with - на ваше усмотрения (чего вы хотите набирать по ней).
В локальных параметрах транковой группы (если у вас сторона нетворк) - ставит b-channel choice
Ниже прописываете access (указываете например 0-5-0 - если используете 0-й доступ, с платы стоящей в 0-м кристалле на 5 месте).
Создаете префикс занятия транковой группы.
Втыкаете провода.
Если ничего красного не горит (иначе разбирайтесь с проводами, модемами и пр.)
- даете trkstat 0 5 0 (0 5 для PRA2) - дожидаетесь level2: CONNECT2 (иначе разбираетесь с режимом нетворк)

Далее пробуете звонить, глядя в трассировки t3

а опыт по стыковке ЧЕМ есть?

Стыковка по ISDN с Avaya - по Е1 легко. Ничем не отличается от стыковки с любой другой станцией. Вопрос как всегда один - Network mode/ synchro_priority/ B-channel choice.

Все остальное видится в t3 и правится как хочется.

Не понял - у вас есть шлюз g430 который вы хотите состыковать с ОХЕ? А сервер s8XXX Avaya у вас есть?

Иными словами - у вас ЕСТЬ Avaya как станция, или вы хотите чужой шлюз приколотить к неродной для него станции?

Данная тема касается ТОЛЬКО сигнализации в 0-м крситалле в станции с дублированными процессорами.
Суть проблемы - инциденты типа

3139=IO2 Sig path problem , type D, link 7, Way 0
2042=Loss of a IO2 type cpl
2168=Stand-By CPU is out of service
3113=Routing error of a signalization message

а так-же всякий проблем с межпроцессорным обменом (не успевают общаться по С1 линку). twin кстати показывает вид сигналинга.

Поэтому - если рядом с процессорами стоит IO2N - можно сигналинг из С1 линка утащить в IO2 (ставим IO2 и говорим 8 каналов).

Для CPU7 можно выбрать режим Ethernet (втыкаем оба в локалку, пермычкой on-board Ethernet запрещаем). Недостаток - если проц выдернуть из локалки (или проблемы с ней) - stand-by будет кувыркаться.

Естественно - после смены параметра - рестарт (два баскуля не подходят).

Проблема в передаче DTMF - чего рисует аппарат? Как переходите в DTMF? Чего слышно с той стороны?

Менять надо - или Ethernet, или IO2 с 8-мью каналами. Рестарт потребуется.

Не пробовали просто в параметрах SIP транковой группы (в локальных) прописать номер IAA в поле Digits to add?

нихт не понял - вы с SIP абонента (не просто входящий SIP звонок) хотите позвонить на IAA?
Если так - то нет. Если просто входящий IP TG звонок - должен работать (если в локальных параметрах TG разрешен автоматический оператор).

Как это удалось (потерять), это ведб синий зуб, не DECT, далеко не уйдешь от аппарата.

А в доке надо не забывать - есть Search - жмем его, вколачиваем в строке поиска Bluetooth - зачастую поиск дает вменяемые результаты