Уважаемые дамы и господа! Для вас сохранен старый форум по адресу http://forum.intersyst.ru

Поиск  Правила  Войти
Форум » Username
Выбрать дату в календаре…Выбрать дату в календаре

Страницы: Пред. 1 2 3 4 5 След.
OmniVista8770 -server error, OmniVista8770 -server error при вводе пароля
 
#
06.12.2019 10:11:34
Абсолютно согласен
Цитата
error написал:
Цитата
Username написал:
ставьте 8770 на Windows оригинальный - или французский или американский. Если соблюдать это правило, то нет проблем ни с Windows 7,10, ни с прочими
1. Госструктры, дают свой образ ISO с своей лицензией  как хочешь так и крути, оригинальный образами и близко не пахнет тем более  или французский или американский
2. Закрытые объекты, пронос флешки телефона и т.д. запрещен и тем более "Windows оригинальный" не понятного происхождения для службы безопасности, как говорится можно пройти только "в трусах и носках"
и т.д. могу дальше перечислять что в "небылицы ALU >= R2.6.1" для России не применимо

Цитата
Username написал:
Поэтому не надо создавать сетевых легенд про "с пятого раза накатили", "жесть" и проч
 не знаю как у вас, а у нас тут суровая реальность, и то что написано в ALU да "какать" на это хотели безопасники
Абсолютно согласен, все так. Это российские реалии.
Windows ISO российский - это означает неработоспособность 8770 для заказчика. И это реалии.
Она ставится на этот Windows (раньше проблемы возникали уже на этапе установки), но не работает, парочка сервисов не заводится.
Я еще раз уточняю - не все 8770 глючны, не вся Винда кривая. А только сочетание "8770 и русская Винда"
.
Изменено: Username - 06.12.2019 10:13:44
 
Перейти    
OmniVista8770 -server error, OmniVista8770 -server error при вводе пароля
 
#
05.12.2019 22:48:14
После версии R2.6.1 ALU сказало - ставьте 8770 на Windows оригинальный - или французский или американский.
Если соблюдать это правило, то нет проблем ни с Windows 7,10, ни с прочими.  
Поэтому не надо создавать сетевых легенд про "с пятого раза накатили", "жесть" и проч. Берете требования к релизу, внимательно читаете  и ставите. Работает и на 7-ке и на 10-ке, и на серверах без проблем.
Поэтому первый вопрос к ТС - какая версия Windows? Если локализованная, российская, то ищем другой дистрибутив (и лицензии, само собой)..
 
Перейти    
CPU8, ethernet через ACT
 
#
13.09.2019 23:03:54
 Как только появился CPU8 везде упоминалось , что embedded Ethernet отсутствует в этом CPU. например, presale-презентация TBE053 "OmniPCX Enterprise R12.1 & OmniVista 8770 R3.2.08 Ed.01", стр.12:
­ No more embedded Ethernet interface  
Или TC2414 ed.04, стр.47/114:
No more USB interface
No more floppy interface
no more embedded ethernet  

По-моему, достаточно понятно написано.
 
Перейти    
CPU7-2 Standby перегружается
 
#
09.09.2019 23:26:09
Цитата
Vlad 46 написал:
Цитата
Username написал:
TC2585 ed.5,  параграф 10.3 прочтен и исполнен, как написано?
Так же там рекомендуется ознакомиться с TC0567 "Reboot of the CPU board after an inopportune shutdown of IO2N board."
По поводу TC2585 хорошая идея, он  исполнен, изменения внесены, но CPU после этого не перегружался.
Увы, там написано: "This management must be followed by a reboot of the installation".
Надо брать окно на полный рестарт.
 
Перейти    
CPU7-2 Standby перегружается
 
#
09.09.2019 15:15:54
TC2585 ed.5,  параграф 10.3 прочтен и исполнен, как написано?
Так же там рекомендуется ознакомиться с TC0567 "Reboot of the CPU board after an inopportune shutdown of IO2N board."
 
Перейти    
Проблема с факсами
 
#
30.07.2019 08:34:59
"Прозрачный" режим (без использования T.38 и других проприетарных режимов передачи факса) работает только с кодеком G.711. VAD должен быть отключен.
Задержки, потери на LAN должны быть минимальны.
В таком случае будет режим псевдо-TDM передачи факса, то есть она никоим образом не затрагивается IP средой и не вносятся искажения аналоговых сигналов, т.к. G.711 используется внутри АТС.

Но если T.38 на младших релизах не отключается, то тогда ничего не поможет. На старших есть пунктв IP-домене fax modem transparency для автоматичексого перехода на прозрачный режим для факсов.модемов.
Но попробовать стоит. Всю станцию перезапускать не надо, достаточно GD/INTIP перезапустить после смены IP-параметров.
Изменено: Username - 30.07.2019 08:41:09
 
Перейти    
Проблема с факсами
 
#
29.07.2019 17:03:27
На G.729 передавать аналоговый факс в прозрачном режиме (без Т.38), с включенным VAD'ом? Однако...
Сетка настолько плоха, что не включить G.711?
 
Перейти    
Не загружается INT-IP3
 
#
06.07.2019 11:47:09
Я бы не мучился - - скопировал бы каталог /DHS3bin/downbin/intip3/ в /etc/rc.d/init.d/, сначала через "ln -s" попробовал бы.
 
Перейти    
Не заливается база
 
#
19.06.2019 21:19:54
Цитата
Aleksandr . написал:

Доходит до середины замирает и пишет -

gunzip: stdin: invalid compressed data--format violated
cpio: premature end of file

ERROR: Restoration failed

ERROR: a problem occured during data restoration
Press return
Бубен не нужен.
Эти сообщения - с вероятностью 99,99% индикатор того, что ftp при сохранении файлов было в автоматическом или текстовом режиме.
Надо волюнтаристски использовать тип передачи - binary (image) всегда. Ftp пришел из unix'а, в этой ОС есть некая процедура, которая определяет тип файла по его заголовку, имени и содержанию.
Если старый диск вообще не читаем - то только ручками снова все набивать.
 
Перейти    
Сброс вызова при звонке сотовому абоненту
 
#
12.04.2019 12:18:18
Цитата
Михаил написал:
И я таки поставил патч на станцию (статический и динамический). Ничего не изменилось.
Но у нас есть АТС с  релизом R7.0, так от нее идет вызов и далее соединение без проблем. А все АТС с 8 релизом не коннектятся.

Значит, все-таки придется искать причину.Cм. https://www.intersyst.ru/support/forum/messages/forum13/topic2601/message21166/#message21166
 
Перейти    
High-layer Compatibility
 
#
22.03.2019 11:29:19
Читаем  Technical communication №1522 " No connect_ack sent from OmniPCX Enterprise in case of ISDN call to Mobile", проверяем версию/патч OXE, ставим галку.
Изменено: Username - 22.03.2019 11:29:57
 
Перейти    
Сброс вызова при звонке сотовому абоненту
 
#
06.03.2019 11:32:57
Имеем:
  • вызов с периферийного узла на абонента центрального узла работает
  • вызов с центрального узла на мобильного абонента работает
Проблема только в транзитном вызове.
Так ТС-у уже писали Метод перебора всех параметров когда-нибудь даст, конечно, результат., при наличии достаточного количества свободного времени и усидчивости. Но анализ конкретно проблемы, почему периферийный узел присылает DISCONNECT при транзитном вызове даст результат гораздо быстрее.
 
Перейти    
Сброс вызова при звонке сотовому абоненту
 
#
06.03.2019 10:34:37
Не увеличивайте энтропию.
Крыжик "Specific EI status for GSM"  не имеет отношения к PROGRESS:
Код
In case of GSM call, this parameter at « true » allows to accept a message «connect» which includes a
«bearer capabitity» to move in conversation.
When this parameter is at « false »,the oxe send a message « status » and the message « connect ack » is
not sent, thus, the conversation status is not established and enquiry call / transfer is not possible.  
Изменено: Username - 06.03.2019 10:34:54
 
Перейти    
рестарт SIP движка станции
 
#
06.03.2019 10:19:20
Цитата
fedoseevka написал:
Цитата
Username написал:
В ps видно, что процессов SIP'a нет
стесняюсь спросить, а это тогда что? pid 16934, 16935
root     16934   741  0 Mar03 ?        00:00:00 [#sipmotor]
root     16935 16934  0 Mar03 ?        00:00:00 [sipmotor_tcl]

Вот нормальные процессы с работающим SIP'ом для 10-й версии: Читайте TG0069
Код
(1)vm10.1.1> ps -ejH | grep sip
 1658   735   735 ?        00:00:00     #sipmotor
 1660   735   735 ?        00:00:00       sipmotor_tcl
 1661   735   735 ?        00:00:00       sipmotor
 1662   735   735 ?        00:00:00       sipmotor_dump
 1663   735   735 ?        00:00:00       sipmotor_presen
Только когда будет так можно начать разбираться с конфигурацией.
Раз bascul - значит, дублирование - там еще больше нюансов с SIP.
Изменено: Username - 06.03.2019 10:19:35
 
Перейти    
Сброс вызова при звонке сотовому абоненту
 
#
05.03.2019 10:22:29
Цитата
Михаил написал:

­__________________
| (750597:000039) Concatenated-Physical-Event :
| long: 22  desti: 0  source: 0  cryst: 0  cpl: 15  us: 0  term: 1  type a5
| tei: 0  >>>>  message received : RELEASE [4d]   Call ref :  00 52
|____________________________________________________________­­__________________
|
| IE:[08] CAUSE (l=2) 81 90 -> [90] NORMAL CALL CLEARING
|____________________________________________________________­­__________________
____________________________________________________________­­__________________
| (750597:000040) 1006: Send_IO1 (link-nbr=0, sapi=0, tei=0) :
| long: 26  desti: 0  source: 15  cryst: 0  cpl: 0  us: 8  term: 1  type a5
| tei: 0  <<<<  message sent : DISCONNECT [45]  Call ref :  08 f4
|____________________________________________________________­­__________________

Сообщение (750597:000039) ясно говорит, что отбой посылает периферийный узел. Провайдер здесь ни при чем. Надо смотреть, что не нравится периферийному узлу.
 
Перейти    
Страницы: Пред. 1 2 3 4 5 След.