нужно входящий

надо смотреть t3 которая data
не исключено что pri от прова идет через костыль

есть подозрение что это издержки миграции бд
попробуйте на "чистом листе" (стенд) тоже самое повторить

1. у вас была миграция БД на другой софт?
2. на SD который используется из ARS barrier какое имеет значение?

OpenTouch 2 - засада для русских, т.е. русских имен НЕТ при звонке OT-to-OXE

Как известно при звонке с терминала который базируется на OpenTouch при звонке на терминалы ОХЕ не корректно показывается имя на русском

По данной ссылке находится кодировка UTF-8 http://www.utf8-chartable.de/unicode-utf8-table.pl

Я нашел закономерность  в кривезны имени (проверено на всем русском алфовите)
Кривизна выражается в следующем:
Не может определить в каком формата ISO-8859-5 и имя и делает транскодирование UTF-8 -> ASCII

Реальный пример:
буква «Г» имеет байтовое «d0 93» соотношение выделенное красным  (поле UTF-8 hex.) в ниже следующей таблице
в результате транскодирования берется поле имя из «Unicode code point»  а конкретно «U+0413» и оттуда берутся последние две цифры (данном случае 13) вставляются в поле имени как значение hex(13)

На мой взгляд если в java будет использоваться lib/rt.jar вместо lib/charsets.jar , в первой как раз есть support ISO-8859-5 то проблем не должно быть, тобишь необходимо переписывать все плагины java

если неким чудом всеже сделают полноценную поддержку UTF-8 то есть другая засада это терминалы 4020 4035 и т.д. из этой серии, тут OpenTouch должен знать какой тип термина и слать в этом случае ASCII

На OpenTouch используется sip-движок от Genesys, в нем есть  поддержка ISO-8859-5, проблема заключается в софте Alcatel

В теории есть выход из этой ситуации - это использовать допилинный софтовый SBC который будет использоваться как proxy для обоих сторон. т.е. при прохождении звонка через SBC, SBC должен выдернуть из БД (БД использовать от 8770 и OT) тип термина и в соответствии с типом выдать имя либо UTF-8 либо ACSII, а выдавать имя нужно по SIP 183, в этом случае должно корректно передаваться

Персональное приветствие конечно красиво но на практике получается по принципу "общага" т.е. операторов практически не возможно обучить логинится под своим номером а логинятся зачастую просто logon где где уже прописан номер автоматом.
также персональное приветствие не подходит если есть tapi и надо лицензировать с учетом агентов и операторов что ну очень дорого

для полного счастья осталось в system включить alaw to ulaw

по трассе на ОХЕ ничего не изменилось? я веду мысль к тому что есть две разновидности t.38 и одна с другой не работает

как вариант на cucm запустить дамп и посмотреть что там происходить с факсом

в CUCM на SIP профиле для терминала пока не активируешь "Outgoing T.38 INVITE include audio mline" все запросы T.38 будет игнорироваться со всеми вытекающими обстоятельствами
этот профиль необходимо прописать в настройках CUCM на терминале
в CUCM не прокатывают дешёвые фокусы как в астериске

в CUCM T.38 на SIP-транке это отдельная песня, там надо крутить SIP профиль для транка ибо профиль для транка и профиль для терминала это разные вещи

в теории (по докам) CUCM может поднять FAX в тупой оцифровке G711, а на H323 - использовать T38 если использовать MTP, но тут есть одно НО - CUCM должен быть выше версии 7

cucm: device->device setting-> sip profile
создаете новый sip профиль по аналогии с со штатным "Standard SIP Profile" и ставите галку тут -> Outgoing T.38 INVITE include audio mline

в балалайке под кодовым названием "факс" прописать новый профиль

у вас факс на cucm через что подключен
- ata sip
- MGCP

entity на isdn и h323 один и тот же?

один из путей ars-to-h323
в ars list в поле TG ставим -1, далее add digit - AAAA
AAAA это sd с типом ip

а если еще по пути к Екатеринбургу стоит астериск то выкидывайте его в топку

вся причина головной боли в отказа форварда покажет трасса

Что у вас стоит в TG параметр "b channel chouse", наверное yes

скорей всего оператору не нравиться тип номера, уточнять надо