делим мух от котлет - не работает в автомате или не понимает вызов? Если не понимает вызов - делаем следующее (на факсе естественно, не помню только 0 или 1 надо ставить, но вариантов у вас не много, справитесь):
a) Go to the menu by pressing the "Setup" button
b) Press and hold the "Up" arrow button
c) While the "Up" button is pressed, press the "Cancel" button.
d) Release both the buttons
e) Go to the menu again by pressing the "setup" button
f) See the item "developer's menu" available and Select this option.
2) Select Mercury ring by...
a) Go to the "R/W parameter" menu item
b) Look for "Ring Use Mercury" it's about 105 items away... (P.S. you may press "1" "0" "5" in sequence for quick access)
c) The default will be "0".
d) Changed this to "1" to activate Mercury Ring detection.
e) Reboot the system

Если у вас ДЕЙСТВИТЕЛЬНО в транковых группах стоят NPD 33 и 34  где DID по входу (called DID id  1 и 2).
Получаете по входу 73830105300 и 73830145300.
То единственное (в общем случае) почему в одном случае звонок проходит, а в другом нет - у вас в локальных параметрах транковой группы приколочено РАЗНОЕ в полях:
number of digits unused (ISDN)
digits to add.
т.е. где-то или добавляете или удаляете чего-то и DID транслятор не работает.

Так здается мне - не надо вам его как SIP аппарат станции регистрировать. Ваш VoIP шлюз вы должны прописывать как внешний SIP gateway и звонить на него через SIP транковую группу, посылая чего надо (в доке раздел SIP trunking).

А сейчас - у вас SIP абонент, его номер вы и набираете. Дискриминатор тут не причем.

По идее не должно, собственно линк - это общение процессоров.
Но проверить ведь легко - выдерните эту плату.

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

Что вы называете файлами конфигов? Базу (без тикетов, речевых подсказок и в специфическом формате) и данные Линукса - каждый день складывает в /usr4/BACKUP. Там есть папки (обычно) - за 7-мь последних дней, за 3-и последних воскресенья и за 2-а месяца.

Я не спрашиваю - куда она СМОТРЕЛА. Я спрашиваю - куда она ПРОПИСАНА сейчас. Она ведь есть в менеджменте

Галка - черт знает, она не используется (но повлиять на что-то может).
Перед баскулями - попробуйте зайти на stand-by и там попробовать через mgr прописать INTOFы (менеджмент на stand-by основному не мешает, его базу не трогает).

А на тему RT2 - это очень интересно!!! У вас RT2A 0-9 - куда смотрит?

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

Если вы не проверяете таким образом - первый звонок, не входящий, а исходящий - через город на второй номер в группе. Т.е. вышли с DECT в город, вернулись обратно в станцию и ответили на 4029. Тогда отбившись на 4029 через busy tone detection (для аналоговых линий) или обычный отбой для цифровых - отобъется и первый разговор. Т.к. это не два разговора, а две половинки одного.

Ну и собственно с чего следовало начать - это сразу началось, или после чего-то? Тип линий указать не мешает. (аналоговые или нет, стоят отбойники или нет). Может у вас стоят (и дурят) отбойники, или провода от них перепутаны.

чудеса какие-то - рестарт может сделать?
Должно (при вашей связке 0-25 ---- 1-20) позволить прописать INTOFA 0-26 ---- INTOFB 1-6.
При этом если вы прописываете на выносе (1-19) INTOFB - не должно позволить это создать!!!
Первая пара заканчивается INTOFB в процессорных местах (6, 20). При добавлении каналов (3-я пара) - прописывается INTOFA ----- INTOFA (с обеих сторон)!!!
Попробуйте через mgr удалить плату 1-6 (может осталось что-то, после каких-то экспериментов).
Или попробуйте идти обратным порядком - пропишите INTOFB 1-6 (со ссылкой на 0-26) - что скажет? Дублированный объект или еще чего?

В целом - приватными адресами не всегда интересно пользоваться.
По идее - когда есть исходящий звонок - будет отдан приватный адрес.
А если будет ВХОДЯЩИЙ звонок - то в сообщении CONNECT не будет отдан приватный адрес.

Так не бывает, если это происходит регулярно - чем-то они повязаны - номером тандем или еще чем-то. Я ведь учавствую в обсуждении - не зная вашего менеджмента, приходящих номеров и так далее. В нашем случае были причины (какое-то совпадение) - я просто не помню - это было два года назад. Черт его знает - что-то в SD для автоматической подстановки, алиасисы какие-нибудь в телефонной книге или еще чего.
Мы просто искали через поиск в плане нумерации - по 1-й цифре, по 2-м - и нашли.

Кардинально проблемы решаются следующим образом - при ПРОЕКТИРОВАНИИ сети делается правильный гомогенный план нумерации. И все станции ходят с ПРАВИЛЬНЫМИ АОН.
По аналогии с операторами, к которым вы подключаетесь - их не интересуют ваши проблемы - вы должны формировать требуемые номера. Это же правило распространяется и на ниже стоящие подключения.

Совпадает. Не начало - так конец. Я просто не помню, у нас два года назад была аналогичная ситуация. При транзитах (с ABC-F узла на ISDN TG). Долго бились, но поскольку подставлялось одно и то-же в конце концов разобрались. Но не помню, что с чем совпало. То-ли у абонента номер в тандеме стоял, с похожим (то-ли начало, то-ли конец) номером. То-ли еще чего.
Если улетает номер прописанный как Private calling number (не указанный в ентити и т.п.) - попробуйте поменять его (не запретить в NPD, а поменять у абонентов). Если их не слишком много - то это не проблема.
380хххх - ХХХХ - не совпадает с кем-то 1110-1950?

Иногда приходится - если сеть не ABC-F, а на центральном узле вызов может разрулиться через несколько направлений, и при этом туда надо слать разные идентификаторы.