IPECS UCP multi language file и переадресация Опции

[DaGash]

Коллеги, добрый день.
Кто-нибудь может сталкивался. Перепрошил UCP600 на выложенную на сайте прошивку (App(R2.1.23), Kernel(R1.1.14)). Теперь имею кучу ошибок в интерфейсе вида: Error : Can't find this string. Please check your multi language file
Я так понимаю, нужен как раз упомянуты файл с локализацией. Если у кого-нибудь есть такой для английского, буду рад.

И да, какая-то беда с трансфером вызова снаружи наружу. "Net--->абонент UCP-->net" например или "Net--->абонент UCP-->ТфОП по sip". В то же время переадресация между абонентами АТС и между абонентами АТС с выходом наружу (абонент UCP--->абонент UCP-->ТфОП/Net) вполне работает. Вроде и CID в порядке и SIP UID нужный выкидывает. Может есть какие-нибудь особенности у UCP в отличии от LIK и MG в части Offnet переадресации?

[AXEL]

Wiresharkом. В станции iPECS-UCP есть встроенный анализатор пакетов.

[DaGash]

Wiresharkом. В станции iPECS-UCP есть встроенный анализатор пакетов.

Извиняюсь за паранойу. Я отправил вам в ЛС.
Harris и Dron, готов также выслать если потребуется.
PS. Кстати, транзит тоже не хочет работать.

[harris]

Извиняюсь за паранойу. Я отправил вам в ЛС.
Harris и Dron, готов также выслать если потребуется.
PS. Кстати, транзит тоже не хочет работать.

ИМХО, возможно проблема в значении поля Remote-Party-Id или P-Asserted ??

А SIP провайдер требует от вас наличие полей [ REMOTE_PARTY_ID ] и [ P_ASSERTED_IDENTITY ] ??

Если нет, то попробуйте выключить эти поля в ПГМ133:
в подразделе ID Presentation Option
P-Asserted-Identity = NOT USE
Remote-Party-ID = NOT USE

Если эти поля все же требуются, то попробуйте добиться, чтобы их значения при транзите были аналогичны случаю прямого вызова от абонента UCP.
Какие значения прописаны для поле P-Asserted и Remote-Party-Id в подразделах
CO to Offnet Direct Call Route и
Offnet Call Forward by Station ??

ИМХО, может просто обратится к провайдеру за разъяснениями, в чем причина того, что он прерывает обработку вашего транзитного вызова??

[DaGash]

ИМХО, возможно проблема в значении поля Remote-Party-Id или P-Asserted ??

А SIP провайдер требует от вас наличие полей [ REMOTE_PARTY_ID ] и [ P_ASSERTED_IDENTITY ] ??

Если нет, то попробуйте выключить эти поля в ПГМ133:
в подразделе ID Presentation Option
P-Asserted-Identity = NOT USE
Remote-Party-ID = NOT USE

Если эти поля все же требуются, то попробуйте добиться, чтобы их значения при транзите были аналогичны случаю прямого вызова от абонента UCP.
Какие значения прописаны для поле P-Asserted и Remote-Party-Id в подразделах
CO to Offnet Direct Call Route и
Offnet Call Forward by Station ??

ИМХО, может просто обратится к провайдеру за разъяснениями, в чем причина того, что он прерывает обработку вашего транзитного вызова??

Провайдеру заявку отправил, ждал ответа.
Вы мне наполовину катастрофу уменьшили, спасибо! Это помогло:
P-Asserted-Identity = NOT USE
Remote-Party-ID = NOT USE
Вызовы на ТфОП заработали. Я так понимаю надо найти аналог для NET линий. MG тоже отбивает переадресованные вызовы.
PS: И транзит MS Skype for business тоже. А как вы поняли? В трассировке был ответ или по опыту?

[harris]

Провайдеру заявку отправил, ждал ответа.
Вы мне наполовину катастрофу уменьшили, спасибо! Это помогло:
P-Asserted-Identity = NOT USE
Remote-Party-ID = NOT USE
Вызовы на ТфОП заработали. Я так понимаю надо найти аналог для NET линий. MG тоже отбивает переадресованные вызовы.
PS: И транзит MS Skype for business тоже. А как вы поняли? В трассировке был ответ или по опыту?

По интуиции... В трассировке успешного вызова опция Remote-Party-Id party=calling ( номер вызывающего),
а при неудачном, транзитном вызове опция party = redirect (переадресованный номер)...
Далее можно предположить, что ваш провайдер анализирует эту опцию, если она используется.
Но ведь можно ее и не использовать. Поэтому я и спросил, требовал ли проаайдер наличие этих полей.