Для какого аппарата?
401х - 4008, 4018,4019
other - 402x, 403x, 4068.

Я так понимаю - здесь языки не трогаем (ставим их аналогично system), а балуемся comatibilities  - "да" или "нет".
Т.e. для обычных (типа 4039):
берем other/ кирилица  и говорим 0/русский/совместим (в system по дефолту 0 - русский), 1/английский/не совместим.
По идее при звонках абонентов с языком 0 и 1  - будут браться имена из name, а не UTF-8 name.

У вас есть UTF-8, display name, language - и соответственно в параметрах 8&9 серии - есть language type compatibilities.

Не сталкивался с таким, но мне показалось, что лучше 48 или 50-й патч поставить.

Да в догонку - возвращаете указанные галки, просматриваете и удаляете вызова, снова убираете галки (если хочется).

Может у вас БЫЛИ не отвеченные вызовы. Далее не удалив их - в свойствах абонента убрали в разделе ISDN user - Internal или external?

а без ARS, просто занятием все работает?
Т.е. у вас проблемы с организацией ARS или с работой вообще?
Ничего красного не горит на плате?
по trkstat шелф плата - connect2 - присутствует?

в транковой группе - перетекание особого смысла не имеет. А вот второй роут чтоб заработал, тут веселее.
Имеет в external services/ trunk COS посмотреть default transmission - разрешен у вас набор при отсутствии ответа станции или нет. Если уберете галку - то при проблемах с линией - должна пометиться как неисправная и с вторым маршрутом станет легче.
А при проблемах с девайсом или с коннектом к GSM - надо в руте ставить quality= poor routing.
Но работает забавно (стоит почитать в доке).

Чувствую сарказм в ответе - но что вы ожидали? Именно так и есть - прописываете плату и вставляете.
А прописывание транковых групп, совместимости с дискриминаторами, работа с CLIP, маршрутизация вызовов - это за вас никто не сделает - тем более вы ни грамма информации в вопросе не дали (собственно таков и ответ получили).

И все?
Странно, а зачем их оттуда перед этим убирали?

А они присутствуют? Типа Calling number для ISDN?
Если есть - тогда Ext. callback translation - хотя бы DEF-0

имеется в виду - что на станциях с дублированными процессорами и платами IO2N - в 0-м кристалле рекомендуется поставить сигналинг IO2 с 8-мю (а не 4-мя каналами).
Для CPU7 - рекомендуется сигналинг ethernet.

Можно. Пишете софт - который смотрит биллинг, при срабатывании порога - лезет на станцию и запускает чего-то меняющее категории абонентам.

Если вы посмотрите параметры DECT - вы увидите IPUIO. Например аппарат номер 3000.
Дайте на станции команду dectipuio 3000 - и вы поймете чего там написано.
Поэтому механизм роуминга прост.
При правильном менеджменте PARI/PLI - пришедшая трубка видит станцию. Сообщает свой номер IPUIO.
По нему гостевая станция знает - это аппарат 3000, соответственно знает с какого узла труба пришла.
Обращается на домашний узел - есть ли, разрешено ли бегать по сети и т.п.
Если все ок - регистрирует у себя трубу в ячейке (shell), а на домашнем ноде автоматически заказывается маршрутизация вызовов туда, куда труба зарегистрировалась.
Соответственно
-  менеджмент PARI/PLI
- посещаемый узел - должен знать откуда 3000
- домашний узел - должен знать, где ячейка куда зарегистрировался аппарат.

такое напоминает - приличную станцию, с дублированными процами, где в 0-м кристале оставлена сигнализация Nx64 (Вместо IO2 или Ethernet)
Достаточно плохо. Хотя все приходится домысливать (дублированность и пр.)

Специально инциденты урезали (номер инцидента в частности) - чтоб тяжелее было помочь?
Первый - какой-то комп не забирает данные тарификации.
Второй - проблемы с OPS файлами.
incinfo GEA номер_инцидента - должен был помочь.