есть связка Alcatel OXE R12.1 (m2.300.29a) и OpenTouch 2.4

настроены "пяток" клиентов OpenTouch Conversation на Android (смарфоны)

когда клиент OpenTouch подключен через wi-fi проблем нет.
есть проблема когда клиент OpenTouch через 3G/4G (через публичный ip)

при любом действии "исходящий/входящий" звонок в сторону  клиента OpenTouch, происходит исходящий звонок с OTMS через OXE на сотовый номер телефона, не дожидаясь ответа на звонок на сотовом телефоне OXE инициирует разъединение, сотовый телефон едва ли успевает звякнуть 1 из 5 раз, в остальных случаях 4 из 5 раза появляется пропущенный звонок "по английски" (в тихоря)

опытным путем выяснилось что такая проблема на всех сотовых провайдерах за исключением Мегафон, с Мегафоном работает нормально

снимал трассировку как t3 так и sip, инициатор разъединения где-то на OXE в isdn-pri

вопрос - как можно за трассировать isdn-pri более глубже чем t3 ?

поставил MY IC Phone Customizer 2.1

малость перепил Theme для 8082, сделал экспорт (получилось два файла Theme и Labels)
на OmniVista 8770 добавил Application, профиль с Application привязал к аппарату 8082
в конфиге config.{mac}.xml есть строка на url профиля c application

1. телефон 8082 в упор не хочет скачивать профиль с Application
2. как еще выяснилось что необходим key.xml, key.xml который есть в составе прошивки для 8082 не подходит
3. пробывал установить через dwl по аналогии как прошиву...тоже не хочет, пишет "error 9"  и приехали т.е. не ставится

собственно вопрос - MY IC Phone Customizer кто-нибудь пользовался и удалось ли Theme в телефон затолкать?

почитал форумы на этому тему и у меня сложилось впечатление что "MY IC Phone Customizer" нужна чтобы сделать заготовку, потом через сайт http://developer-enterprise.alcatel-lucent.com/  сделать экспорт своей заготовки
этот сайт девелопера у меня не открывается, может переехал на другое место может не понятно что

Поставил OpenTouch 2.4
терминал 8082 на прямую с ОТ конфиг отказывается взять из-за того что на ОТ есть только TLS1.2, а 8082 хочет TLS1 (openssl 0.9.8 который на борту терминала 8082 не поддерживает TLS1.2)

8082 натравил на ОТ через reverse-proxy и он там "благополучно" успел что-то считать и частично скачать rpm (около 30 штук из 142) и начал апгрейдиться, в итоге после нескольких перезагрузок получился "кирпич" т.е. циклическая перезагрузка с интервалом 30 сек, на экране появляется "U" (upgrade) секунд на 5 и черный экран, порт LAN на коммутаторе поднимается но ip-адреса не спрашивает

вопрос - возможно ли как-то терминал 8082 восстановить?

Для меня стало неожиданным сюрпризом что через ACT-14/28 нет ethernet между cpu8

в доках есть описание про 2 перемычки, про остальные ничего не написано

это действительно так что нет ethernet через ACT или что-то упустил я?

OXE 12.1 m2.300.22a

у клиента стоит Alcatel с сетью ABC-F через E1
на телефоном аппарате 8018 который на OXE 12.1 (нода 40) есть проблема с организацией 3х сторонней конференцией через ABC-F если на другой ноде абонент является SIP

суть проблемы:
c аппарата 8018 набираем локального абонента, затем набираем абонента через ABC-F (c другого конца SIP-телефон который зарегистрирован на ОХЕ, нода 14), нажимаем "conf" всё работает

если сделать по другому
c аппарата 8018 набираем абонента через ABC-F (c другого конца SIP-телефон который зарегистрирован на ОХЕ нода 14), затем набираем локального абонента, нажимаем  нажимаем "conf" и тут интересное - абонент (SIP-телефон) с ноды 14 слышит музыку на удержание, но на аппарате  8018 показывает конференцию т.е. конференция собрана

на аналоговых телефонах ноды 40 (ОХЕ 12.1) такой проблемы нет, собирается в любой комбинации

не могу понять как за дебажит это

OmniVista 3.2 - в планировщике процесс завис (стоит в процессе выполнения)
не дает его ни изменить и ни удалить, перезагрузка OmniVista не помогает

вариант 8770\data\scheduler с job не очень устраивает т.к. на OmniVista около 30 атс прописано

есть какой-то способ зависший процесс остановить/удалить

АТС OXE 7.1

возможно ли отключить на префиксе "Room status managment" ввод пин-кода?

в данный момент при наборе префикса нужно ввести пин-код (любой от 0000 до 9999) и затем статус.
Обслуживающий персонал это очень сильно утомляет вводить пин-код.
Я обьяснил что этот пин-код мифический (в текущей ситуации) введите что-нибудь, но на их "разумный" вопрос "а вдруг мы введем пин-код чужой или напарницы, в случае чего-либо с кем разбираться начальство будет?" я впал в ступор

стоит у клиента Alcatel OXE R11.1-l1.301-23-j-ru-c7

от провайдера приходит 5 isdn-pri, на OXE все эти потоки объедены в одну TG

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

звоню провайдеру и объясняю что setup приходит абсолютно "голый", проверяет и говорит что по трассировки звонка setup уходит полный (есть нью-анс - это показывает на логическом уровне). что там реально происходит на транке (у прова) знает только "анализатор isdn" (который в данный момент был в другом месте) и "сам бог"

продолжалось это безобразие где-то 40 минут и само все рассосалось, провайдер притащил анализатор isdn но так и не успел "заглянуть в душу транка" чтобы посмотреть что там происходит

кусок трассы одного звонка отправил провайдеру, но он захотел в бинарном ввиде. ну я естественно не сообразил трассировку в бинарном виде снять.

есть несколько вопросов:
1. кому нибудь такое "сие чудо" встречалось?
2. насколько можно верить "t3" и "t3 -data" т.е. возможно ли расхождения (тобишь в "t3 -data" данные одни, а выхлоп в "t3" другой)

вот и сама трассировка "сие чуда"

| (482066:000002) Concatenated-Physical-Event :
| long: 40  desti: 0  source: 0  cryst: 0  cpl: 3  us: 0  term: 0  type a5
| tei: 0  >>>>  message received : SETUP [05]    Call ref :  7f 82
|____________________________________________________________­__________________
|
| IE:[04] BEARER_CAPABILITY (l=3) 80 90 a3
| IE:[18] CHANNEL (l=3)  a9 83 94 -> T2 : B channel 20 exclusive
| IE:[1e] PROGRESS_ID (l=2) 82 81
| IE:[29] DATE (l=5)  ->  date :  01 / 02 / 18   12:03
| [a1] Sending complete
|____________________________________________________________­__________________

____________________________________________________________­__________________
| (482066:000003) 940: Send_IO1 (link-nbr=3, sapi=0, tei=0) :
| long: 26  desti: 0  source: 15  cryst: 0  cpl: 3  us: 8  term: 0  type a5
| tei: 0  <<<<  message sent : STATUS [7d]    Call ref :  ff 82
|____________________________________________________________­__________________
|
| IE:[08] CAUSE (l=3) 81 e3 29 -> [e3]
|    INFORMATION ELEMENT NON-EXISTENT OR NOT IMPLEMENTED
| IE:[14] CALL_STATE (l=1) 06
|____________________________________________________________­__________________

____________________________________________________________­__________________
| (482066:000004) 940: Send_IO1 (link-nbr=3, sapi=0, tei=0) :
| long: 26  desti: 0  source: 15  cryst: 0  cpl: 3  us: 8  term: 0  type a5
| tei: 0  <<<<  message sent : DISCONNECT [45]  Call ref :  ff 82
|____________________________________________________________­__________________
|
| IE:[08] CAUSE (l=2) 81 9c -> [9c] INVALID NUMBER FORMAT
| IE:[1e] PROGRESS_ID (l=2) 81 81
|____________________________________________________________­__________________

____________________________________________________________­__________________
| (482066:000005) Concatenated-Physical-Event :
| long: 18  desti: 0  source: 0  cryst: 0  cpl: 3  us: 0  term: 0  type a5
| tei: 0  >>>>  message received : RELEASE [4d]   Call ref :  7f 82
|____________________________________________________________­__________________

____________________________________________________________­__________________
| (482066:000006) 940: Send_IO1 (link-nbr=3, sapi=0, tei=0) :
| long: 22  desti: 0  source: 15  cryst: 0  cpl: 3  us: 8  term: 0  type a5
| tei: 0  <<<<  message sent : REL COMP [5a]  Call ref :  ff 82
|____________________________________________________________­__________________
|
| IE:[08] CAUSE (l=2) 81 90 -> [90] NORMAL CALL CLEARING
|____________________________________________________________­__________________

сделали апгрейд ОХЕ до версии 12.0 m1.403.18b (cpu7-2)

теперь появилось самое интересное - не могу через ftp в папку /usr4/BACKUP/IMMED базу положить

есть какие-нибудь мысли?

Добрый день

имеется ОХО r920.090.001
пользователь умудрился заблокировать телефон 8082

как можно его разблокировать?

Добрый день

есть ОХО релиза 8.2. понадобилось настроить trunk gatekeep с регистрацией от выше стоящей АТС

в конфиги поковырялся и думаю что надо сделать так
- ars -> gateway parameters добавить c индексом 1 - login/password/domain_name
- ars -> ars_prefix добавить маршрут с типом "gatekeep", в "ip adress" указать ip куда звонить, "gateway parameters index" указать созданный индекс
- в external_lines -> list_of_accesses на линии VoIP снять галку "Public" и приходящий набор разруливать через Numbering_Plan -> Private_Numbering_Plan

вроде ничего не упустил
если что-то не так поправить

имеется OXE R11.0.1 (K1.520.43)
создал SIP-транк c типом ISDN, установил тип "privat trunk group"
при входящем звонке с этой транк группы на цифровом терминале идет вызов как внешний

вопрос - параметр "privat trunk group" для транка SIP с типом ISDN применим?

развернули для тестов opensource vks с полным функционалом телефонии
из вне доступна только видеоконференция

ссылка вводим имя и email (мифические тоже сойдут)
и звоним на номера с 4940 по 4949
работает "screen share", на видео установил ограничение 1280х720
все работает только в chrome, с firefox пока "не айс"

в дальнейшем планируется для внешних пользователей доступ к ВКС через ссылку id где к пользователю автоматически прикручивается имя и email и сразу вход в нужную конференцию

к OXE подключен NEC через PRI

периодически появляются такой setup и OXE бортует звонок
____________________________________________________________­__________________
| (599925:000032) Physical-Event :
| long: 53  desti: 0  source: 0  cryst: 0  cpl: 13  us: 0  term: 0  type a5
| tei: 0  >>>>  message received : SETUP [05] Call ref : 00 0b
|____________________________________________________________­__________________
|
| IE:[04] BEARER_CAPABILITY ( l=3) 80 90 a0
| IE:[18] CHANNEL (l=3) a9 83 81 -> T2 : B channel 1 exclusive
| IE:[6c] CALLING_NUMBER ( l=12 ) -> 21 81 Num : 8432222222
| IE:[70] CALLED_NUMBER ( l=8 ) -> 81 Num : 5555555
| [a1] Sending complete
|____________________________________________________________­__________________

____________________________________________________________­__________________
| (599925:000033) 1194: Send_IO1 (link-nbr=13, sapi=0, tei=0) :
| long: 22  desti: 0  source: 15  cryst: 0  cpl: 13  us: 8  term: 0  type a5
| tei: 0  <<<<  message sent : REL COMP [5a] Call ref : 80 0b
|____________________________________________________________­__________________
|
| IE:[08] CAUSE ( l=2) 81 d8 -> [d8] INCOMPATIBLE DESTINATION
|____________________________________________________________­__________________


т.е. когда приходит IE:[04] BEARER_CAPABILITY ( l=3) 80 90 a0 (красным выделено) то звонка не будет
если приходит IE:[04] BEARER_CAPABILITY ( l=3) 80 90 a3 то все нормально

вопрос - a0 в "BEARER_CAPABILITY (l=3) 80 90 a0" что значит?

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, в этом случае должно корректно передаваться