Что значить не правильно? Номер относится к диапазону ваших номеров, а вы должн выдать номер не аллоцирован? Честно говоря - вы первый, кому провайдер (на моей памяти) предъявил такие претензии.
Собственно у вас выбор не большой:
- править DID транслятор (если это помогает);
- заставить провайдера ДОКАЗАТЬ что вы обязаны отдавать такую причину дисконнекта (не уверен, что им это удастся);
- напрячь Алкатель (не понятно, как это у вас получится)

Если при исключении номера из DID диапазона ваша станция выдает нужную причину дисконнекта - значить придется вам править DID транслятор.

Все правильно человек делает. Телефон РЕАЛЬНО от удаленной станции, при наборе - будем видеть и слышать все что происходит.
Если надо просто звонить (снимая трассировки типа t3) - можно конечно воспользоваться dialer, но реальный аппарат - приятней.

Если вам для тестов, а не для разбирательств с DHCP, lanpbxbuild (где должны быть две записи с tftp процессора main и адресами процессоров) - вколотите в аппарат ручками - IP адрес, маску, шлюз, tftp адрес (main нужной вам станции), если надо номер VLAN. На станции - в IP параметрах аппарата укажите его МАС адрес.
И все.

Потому что PLI 31 - это означает, что трубка работает ТОЛЬКО с указанным PARI.
Если вы посмотрите внимательней при регистрации - то увидите, что трубки, которым разрешено бегать по сети (Mobility right=Yes) при регистрации регистрируются с PLI прописанным в системных DECT параметрах. А если регистрируете трубку без прав на сетевой роуминг - то с PLI 31.

Соответственно - смотрите, стоит ли в DECT параметрах трубки Mobility rights. Ну и естественно - при регистрации в команде dectinston никто не мешает добавить опцию -pli.

не помню - надо ли кроме tftp адреса - вводить еще и адреса процессоров с той станции.
А если вы в аппарат вводите адреса ручками, а на той станции ручками - в IP параметрах аппарата указываете его МАС адрес - все работает?

Вы не получаете сообщения Alert. Вы послали Setup, приняли Call Proc, а далее получили Progress (Progress Id 81 88) - лень лезть в стандарт, это скорее всего означает - что надо слушать разговорный тракт.
Такое по идее правится - или установкой более свежих патчей (были на эту тему исправления в разное время), или баловаться с галками типа System/ other system/ external signaling param -  Alert On Progress T2.
Или попросить товарищей из города - присылать Alert.

Это последовательный порт. Два маленьких разъема с контакта 17 - это Ethernet'ы, второй маленький с контакта 1 - это последовательный порт (А1, В1) дублирующего процессора.

PLI/PARI - это аналог адреса/маски - т.е. у вас PARI должны начинаться одинаково 1000400700 и PLI например 27. Это означает, что у вас в сети может быть до 16 станций с PARI
10000400700
10000400710
10000400720
10000400730
10000400740
..
10000400770
10000400704
10000400714
10000400724
..
10000400774
Перерегистрация трубок после смены PARI потребуется.

Регистрировать трубку на другой станции можно, вы должны дать команду dectinston dir_number -pari pari_number. Номер PARI надо указывать как на родной станции трубки, номер трубки должен быть известен текущей станции (присутствовать как префикс network number).

Ситуация с шелами - проста как три рубля, при создании - тип аппарата 4074/Shell, в DECT параметрах - галка Shell. Когда аппарат, при посещении чужого нода зарегистрируется в shell - туда будут на время посещения записаны - имя, категория и т.п. пришедшего аппарата. Т.е. аппарат в шеле - обладает не категорией шела, а будет иметь тот НОМЕР категории, который у него на своем узле (содержимое категории - то, которое на посещаемом узле - это хороший повод, на разных узлах сети иметь одинаковое СОДЕРЖИМОЕ категорий).

Это - в общем Линукс, и если хватает квалификации - то можно.
Встраивают обычно - средства отладки (пример - всем известный dialer) и т.п, настраивают - всякие запуски скриптов (для выполнения каких-то задач - типа периодического рестарта плат, например).

Т.е. - все в ваших руках.

Если у человека - дублированная станция - то вопрос копирования диска без остановки станции не возникает.

Подскажите - какое отношение ваша ссылка имеет в заданному вопросу?

На процессоре стоит коммутатор - один Ethernet наружу, второй внутри (on-board, embedded).
Если вы включаете ОБА процессора во внешний коммутатор - то встроенный Ethernet должен быть запрещен (перемещением перемычки). Если это не сделать - то у вас будет кольцо по передаче данных (встроенный Ethernet не может быть запрещен автоматически, с использованием протоколов типа STP).
А насчет - двух ног - я не понял, вы включились как-то не через CBRMA (где по ОДНОЙ дырке на процессор)?

Делается обычно следующим образом:
- на основном процессоре - сохраняем - mao, vg, accounting;
- перегружаем дублирующий процессор без телефонии, ставим патч;
- восстанавливаем на нем базу, сохраненную на первом шаге;
- останавливаем основной процессор, стартуем резервный (только что приготовленный);
- проверяем, что все работает;
- если все Ок - стартуем бывший main без телефонии, ставим на нем патч, запускаем в работу через клонирование (выравнивание базы данных).

По DHCP - аппарат может получать IP параметры от ближнего узла, это не проблема. Но для того чтоб работать с другой станцией, требуется ряд телодвижений:
- если на аппарате сказано использовать DHCP - у вас должна правильно быть настроена эта служба (если у вас аппарат доходит только до этапа 2 - значить с DHCP у вас проблемы);
- номер аппарата должен присутствовать в виде префикса network number с упоминанием, что он с дальнего узла;
- на станции надо правильно сконфигурировать параметры с помощью команды lanpbxbuild. Вы должны указать в качестве адресов tftp сервера и процессора второго узла (создаете запись, если ее нет, там указываете, через добавление адреса tftp серверов - как своего узла, так и второго - где должен работать аппарат).

Собственно по DHCP он от ближнего процессора получит адрес, дойдет до момента ввода номера (пройдет 5 из 5 этапов). По вводу номера - станция поймет, что он с удаленного узла - и позволит ему загрузить по tftp софт с удаленной станции.