Один из заказчиков приобрел через "Гора и копыта" (Юнит-Копир) партию телефонов Алкатель 8038.
Часть телефонов (10 шт.) оказалась бракованной. Неисправность в следующем: в разговоре по трубке слышен гул (генератор около 50Гц), в спикерфоне же все нормально.
Гул весьма очевидный, громкостью на уровне разговора. Вне разговора, например, при наборе номера, гула нет.
Порекомендовали заказчику отправить аппараты поставщику. Через месяц аппараты были возвращены с Актом от Комптека с ответом "Заявленная неисправность не обнаружена, т/а полностью исправны."
От чего делаю вывод, что либо там полные дилетанты, либо абсолютные пох...сты, работающие на отъеб...сь.
Начали разбираться сами. Попробовали более новые бинарники (за что отдельно спасибо Dmitry Ryzhakov!!!), - увы - не помогло.
Разобрали трубку, обнаружили, что микрофон и динамик заметно отличаются от тех, которые стоят в исправных трубках. Сделали переполюсовку - отчасти помогло. На самом аппарате гул исчез, а на встречном сильно уменьшился (до терпимого уровня). На остальных аппаратах сделали переполюсовку в витом шнуре - перезашили разъем (RJ).
В поставленной партии были телефоны Маде Ин Чина и Маде Ин Румыния. К китайским телефонам претензий нет. А вот все румынские оказались - хлам. В серийных номерах связи не обнаружил, айпишники же такие: 00 80 9F Ex xx xx
Здравствуйте, Порекомендуйте, пожалуйста, какой нибудь проверенный SIP-шлюз (SIP->аналог) для подключения в удаленном месте аналоговой "тарелки" для конференций. (ОХЕ R11.0)
ЗЫ. Мы, конечно, рекомендовали заказчику приобрести SIP-тарелку, но он уже накупил аналоговых Поликомов... (
Здравствуйте, Вроде уж давно живем на 8770, но до сих пор не получается отладить нормальный экспорт тикетов в архив. На 4760 это все прекрасно работало.
В общем было так: - сделали Отчет "За предыдущий месяц" - в Планировщике запланировали его на каждое первое число месяца - на сервере сделали батник, который пакует файл и отправляет его по назначению (файл большой 700-800 тыс. строк в файле txt)
Сейчас в 8770 можно сделать необходимый "Отчет". Можно его экспортировать в текстовый файл. Все это по отдельности работает. Но стоит только Отчет "Запланировать", - беда. Планировщик в строке состояния говорит:
[13:36:35] > Начато немедленное выполнение задания '_Тикеты за месяц'... [13:42:03] > Задание '_Тикеты за месяц' было выполнено в состоянии Ошибка...
... а в журнале:
[12/16/2016 4:19:19 PM] Scheduler: The job is started. [12/16/2016 4:19:21 PM] Target: Generation In Process [12/16/2016 4:19:21 PM] Target: Generation Initialization [12/16/2016 4:19:22 PM] Target: Create Data Table [12/16/2016 4:19:49 PM] Target: Fill Data Table [12/16/2016 4:23:23 PM] Target: Data Table OK [12/16/2016 4:23:28 PM] Target: Cre ate Table of Contents: RI_400_R [12/16/2016 4:23:28 PM] Target: Launching external process for printing or mailing. [12/16/2016 4:23:30 PM] Target: New connection ==> Nb of Connexions = 1 [12/16/2016 4:23:30 PM] Target: Connection number = 12715 [12/16/2016 4:23:34 PM] Target: New connection ==> Nb of Connexions = 2 [12/16/2016 4:23:35 PM] Target: Connection number = 12716 [12/16/2016 4:23:36 PM] Target: New connection ==> Nb of Connexions = 3 [12/16/2016 4:23:36 PM] Target: Connection number = 12717 [12/16/2016 4:23:36 PM] Target: New connection ==> Nb of Connexions = 4 [12/16/2016 4:23:36 PM] Target: Connection number = 12718 [12/16/2016 4:23:46 PM] Target: Exception in thread "main" java.lang.OutOfMemoryError: Java heap space [12/16/2016 4:23:46 PM] Target: at org.mariadb.jdbc.internal.mysql.packet.MySQLRowPacket.getRow(MySQLRowPacket.java:88) [12/16/2016 4:23:46 PM] Target: at org.mariadb.jdbc.internal.common.queryresults.StreamingSelectResult.next(StreamingSelectResult.java:107) [12/16/2016 4:23:46 PM] Target: at org.mariadb.jdbc.internal.common.queryresults.CachedSelectResult.createCachedSelectResult(CachedSelectResult.java:77) [12/16/2016 4:23:46 PM] Target: at org.mariadb.jdbc.internal.mysql.MySQLProtocol.createQueryResult(MySQLProtocol.java:815) [12/16/2016 4:23:46 PM] Target: at org.mariadb.jdbc.internal.mysql.MySQLProtocol.getResult(MySQLProtocol.java:951) [12/16/2016 4:23:46 PM] Target: at org.mariadb.jdbc.internal.mysql.MySQLProtocol.executeQuery(MySQLProtocol.java:982) [12/16/2016 4:23:46 PM] Target: at org.mariadb.jdbc.MySQLStatement.execute(MySQLStatement.java:280) [12/16/2016 4:23:46 PM] Target: at org.mariadb.jdbc.MySQLStatement.executeQuery(MySQLStatement.java:301) [12/16/2016 4:23:46 PM] Target: at org.mariadb.jdbc.MySQLStatement.executeQuery(MySQLStatement.java:360) [12/16/2016 4:23:46 PM] Target: at com.alcatel_lucent.nms8770.appl.client.apps.reportingtool.view.rdefinition.DataSet.execQuery(DataSet.java:80) [12/16/2016 4:23:46 PM] Target: at com.alcatel_lucent.nms8770.appl.client.apps.reportingtool.view.rdefinition.DataSetDetail.<init>(DataSetDetail.java:69) [12/16/2016 4:23:46 PM] Target: at com.alcatel_lucent.nms8770.appl.client.apps.reportingtool.view.rdefinition.RDefinition.<init>(RDefinition.java:142) [12/16/2016 4:23:46 PM] Target: at com.alcatel_lucent.nms8770.appl.client.apps.reportingtool.view.ReportMainPanel.blindReportMainPanel(ReportMainPanel.java:339) [12/16/2016 4:23:46 PM] Target: at com.alcatel_lucent.nms8770.appl.client.apps.reportingtool.view.ReportMainPanel.<init>(ReportMainPanel.java:318) [12/16/2016 4:23:46 PM] Target: at com.alcatel_lucent.nms8770.appl.client.apps.reportingtool.view.ReportMainPanel$Test.main(ReportMainPanel.java:1268) [12/16/2016 4:23:47 PM] Target: External process returned an error [12/16/2016 4:23:47 PM] Target: Generation Failed [12/16/2016 4:23:48 PM] Scheduler: Job failed.
Отчет, при этом, создается (висит в Отчетах), но экспорт его в файл не происходит. В логах Омнивисты (C:\8770\log) ни чего интересного не происходит (не обновляются). Разве что в файле NMC_Viewer.log появляются строчки:
2016-12-16 15:41:44,266 oms02nmc Accounting: New connection ==> Nb of Connexions = 1 2016-12-16 15:41:44,266 oms02nmc Accounting: Connection number = 12644 2016-12-16 15:41:44,266 oms02nmc UTIL : Locale set by the application: ru RU 2016-12-16 15:41:46,891 oms02nmc Accounting: New connection ==> Nb of Connexions = 2 2016-12-16 15:41:46,891 oms02nmc Accounting: Connection number = 12645 2016-12-16 15:41:46,891 oms02nmc Accounting: New connection ==> Nb of Connexions = 3 2016-12-16 15:41:46,891 oms02nmc Accounting: Connection number = 12646 2016-12-16 15:41:47,141 oms02nmc Accounting: New connection ==> Nb of Connexions = 4 2016-12-16 15:41:47,141 oms02nmc Accounting: Connection number = 12647
НО намедни обнаружилось, что если файл маленький, то все работает прекрасно.
Еще раз проверил размеры, которые имеют значение...
Максимальное количество строк в формате txt - 10 000 000 Максимальное количество страниц в формате html - 50 Максимальное количество страниц в формате pdf - 50 Максимальное количество страниц в формате excel - 1000 Максимальное количество строк в базе данных - 10 000 000
Столкнулся со следующей проблемой.. Вдруг (как это обычно и происходит), все абоненты одной из полок (соединенных INTOFом) при подъеме трубки стали получать занятость (входящие звонки, при этом, проходили). Абоненты на полке только аналоговые и их очень много - АСТ28 практически битком.
При этом повалились в огромном количестве инциденты: 01/08/16 10:46:58 000001M|---/--/-/---|=0:1721=Phone exc 5, PC 0x083cd6bb neqt 2781
проверка checkdb показала следующее: (1)xa000001> checkdb Data base checking in progress ... /...........ERROR 1006 : DPNSS Prefix Missing. No DPNSS prefix added. .ERROR 4351 : DATA INCONSISTENCY, Table ADRFICT, function=addr already used nulog=2929 Coupler=0 Position=89 ........................ ./ (1)xa000001>
Не знаю, связано-ли это было или нет...
Попытался перескочить на другой процессор (баскул), - не помогло. Подтянул базу данных "за вчера" - перескачил на нее баскулом - все заработало...
Можно ли как нибудь считать из ОХОшки всю инфу по абонентам со всеми их "Функциями", "Услугами" и прочими "MISC" хоть в каком-то удобочитаемом виде?
Заказчик требует сделать файл со всеми настройками абонентов. Изъять инфу у меня как-то не выходит, а просматривать каждого абонента вручную - гимор еще тот...
Спасибо!
OV8770. Мажорный аларм "No response from any RADIUS server!"
Здравствуйте, При рестарте Омнивисты (2.6.07.06), всякий раз, вываливается мажорный инцидент "No response from any RADIUS server!" (в том числе и при "еженедельной работе"). Пока я не заметил какого бы то ни-было влияния на работу Омнивисты, но мажорность инцидента мне не нравится...
Прошу подсказать, в чем может быть проблема? Или хотя бы задать направление поиска?
PS Также с ошибкой проходит работа "RTU Scheduled Reports" ----------- [4/2/2016 11:00:18 PM] Scheduler: The job is started. [4/2/2016 11:00:18 PM] Scheduler: Error! Received return value is an incorrect type. [4/2/2016 11:00:18 PM] Scheduler: Job failed. -----------
Что-то последнее время абоненты стали жаловаться на некоторые надписи на телефоне (типа "Перегрузка" или "Отправить D..."). 10 лет всех устраивало, а тут завредничали... Я точно не уверен, но сдается мне, что видел я здесь (на форуме) обсуждение того, как можно изменить эти слова/символы... Вроде как есть какой-то файл с этими самыми словами (который при старте грузит телефон), который можно подредактировать...
ЗЫ Хотя, возможно, я путаю с какой-нить другой PBX-ой...
Здравствуйте, Накопилось с десяток побитых плат eZ32. Хотим попробовать починить хоть что-нибудь из них. Хорошие паяльники есть, "некривые" руки тоже найдутся, а вот ни каких схем, как я понимаю, найти не удастся... Поэтому надежда только на чей-нибудь удачный/неудачный опыт.
Начну с пары плат с весьма очевидными симптомами: - на всех первых портах на планках (0,4,8,12...) - сильный свист; - на всех последних портах на планках (3,7,11,15...) - все ОК; - на остальных (средних) - на некоторых свист, на некоторых легкое но очевидное подвывание (как серена), на некоторых ОК. Все порты "запели" одновременно.
Может у кого-нибудь есть опыт борьбы с подобными симптомами? Прошу помочь советом...
(ОХЕ R11.0) Есть новая полка (АСТ28) с двумя платами INTIP3 (поз. 6 и 20). Одна из плат (20) работает стабильно и без вопросов. А вот со второй (6) прям беда какая-то...
Прописали подключили - она заработала, но через некоторое время (от полу-часа до 3-4 часов) станция вываливает инциденты:
16/09/15 14:56:32 000001M|014/06/-/---|=2:3720=C1 Access Pb INTIP3[INTOF/INT2B]Hexa C1Flag:10,0[Time],HostFlg:bf,7d,HstST:5,LINE:3,0 16/09/15 14:56:32 000001M|014/06/-/---|=2:2042=Loss of a INTIPB/INTIP3B type cpl 16/09/15 14:56:32 000001S|014/06/0/254|=2:0379=Inter ACT link HS: 23,(14,6),Unused,00:80:9f:d7:68:24 16/09/15 14:56:37 000001M|014/06/-/---|=2:3720=C1 Access Pb INTIP3[INTOF/INT2B]Hexa C1Flag:10,0[Time],HostFlg:0,ec,HstST:5,LINE:4,ee 16/09/15 14:57:01 000001M|019/01/-/---|=3:0747=Config error or Loss of IP connection: 3,(14,6),Unused,00:80:9f:d7:68:24
после чего, плата начинает циклично перезагружаться:
16/09/15 14:58:00 000001M|014/06/-/---|=4:0740=Beginning of an INT/IP downloading @:00.80.9f.d7.68.24 (binintip3) 16/09/15 14:58:00 000001M|014/06/-/---|=5:0741=End of downloading of an INT/IP board @:00.80.9f.d7.68.24 (binintip3)
Вернуть ее в работу получается только после полной ее остановки (кнопочкой). После чего вся история повторяется...
Подскажите, пожалуйста, в чем может быть проблема? Где-то здесь (на форуме) находил упоминание инцидента 3720, - говорилось о проблеме с железом, так ли это?
Здравствуйте, Столкнулся с проблемой, - и не хватает мозгов разобраться...
Есть ОХЕ R11.0
Конструкция следующая: город -> (DSS) -> ОХЕ -> (SIP) -> IVR -> (SIP) -> OXE Конструкция в целом работает: приходит вызов, IVR отрабатывает, соединяет с абонентом в ОХЕ, Но, при попытке абонента ОХЕ перевести вызов на другого внутреннего абонента, ОХЕ зачем-то пытается сделать это в SIPе (видно в трассировке)... Т.е. посылает INVITE сама себе, причем уже при постановке на удержание. В итоге выдает ошибку: SIP/2.0 500 Internal Server Error
Вопрос у меня такой, как заставить ОХЕ переводить вызов не затрагивая SIP соединение?
ЗЫ Прошу прощения за сумбур, - выразился как смог...
Есть ОХЕ R11.0 с 16-ю полками (плюс виртуальные - 11 и 19) Хотел сделать временную полку с номером 20 - не позволила... с номером 16 или 17 - нет проблем...
Обзавелись давеча новой ОмниВистой 8770. Сразу же столкнулись с проблемой АлармСервера - регулярно рестартует, падла такая... Ковыряния по логам привели к следующему: АлармСервер рестартует при приеме с PBX-а любого "События/Event" (менеджмент, переадресация и пр.).
NMCFaultManager_1.log --------------------- [5/22/2015 3:42:35 PM] 6356 FaultManager: A4400 EVENT from Center issued 2015-05-22 15:42:00 : #967 active OSI[EvType=1,Sev=-1,ProbCause=0] AddInfo[2 0 #-1 1 FWD] [5/22/2015 3:42:35 PM] 6356 FaultManager: Warning: Problem when inserting alarm 967 in the base [5/22/2015 3:42:35 PM] 6356 FaultManager: Warning: AlarmBackupThread::run : Alarm insertion failed [5/22/2015 3:42:35 PM] 6356 FaultManager: Close Connection ==> Nb of Connexions = 10
Соответственно, пока АлармСервер стартует заново, для новых алармов он недоступен. Ну и, разумеется, "События/Events" не собираются, - вернее сказать, собираются, но пустые - без информации внутри...
Может уже кто сталкивался с хренью такой? Подскажите, пожалуйста, как лечить?
Здравтвуйте. До сей поры желающих пользоваться этим атавизмом у меня не было, - и вот на те... Попытался настроить снаскоку - не вышло, - прошу помощи...
Здравствуйте! Есть ОХОшка в корпусе "L" на 220В и есть MG ОХЕ в корпусе "L" на -48В. По соображениям более надежного резервирования питания появилась идея поменять корпуса местами. Это возможно? Отличаются ли они между собой, кроме как питанием?
PS Попробовать, увы, не могу, - не начем. А что б затевать работу, - хотелось бы знать наверняка.
