Будьте добры, если несложно, проясните пожалуйста следующие моменты:
Цитата
про синхру от прова подрядчик от части прав т.е. когда начинает хрома синхра надо делать делать рестарт синхронизации на dect, а самый надежный вариант это перезапуск dect-системы
Дурацкий вопрос - а как это сделать? В том смысле, есть какие-то команды для - рестарта синхронизации DECT - перезапуска всей DECT?
Цитата
согласно доке одну плату dect8 можно выделить под раздачу синхронизации для всей системы dect, побочный эффект - количество tdm-каналов урезается до 16 (если память не подводит), дект базы от этой dect8 лучше ставить в отдаленные участки где меньше потребности в dect-ах
Правильно ли я понимаю, что если, к примеру, в полке стоит две DECT8 платы, от одной из которых раздается синхронизация, то абоненты, которые пользуются в настоящий момент данной DECT-платой могут установить не более 16 вызовов, тогда как на абонентах другой платы, а уж тем более, другой полки, это никак не сказывается?
Цитата
тут само собой назревает вопрос - у вас синхронизация для dect прописана от процессора или dect8?
Пожалуйста, сориентируйте, где это посмотреть?
Цитата
а чтобы навсегда избавить от хромой синхры терминируйте стык к прову через sip т.е. физически изолировать isdn-pri атс от прова, терминировать через h323 заведомо тупиковая идея тобишь опять вернетесь к тому с чего все началось
Error, не совсем понял... У нас ведь классический ISDN PRI, никакого IP на стыке. А SIP и H323 же IP решения и подразумевают кардинальных изменений как договорных обязательств с провайдером, так и технических решений для этого. Или я что-то не так понял?
Цитата
отключить на 2-15 isdn если подключены и глянуть на события
В настоящий момент isdn 2-15 совсем не используется. Может ли плата с неиспользуемым потоком (никуда не подключенным) вызывать данную ситуацию?
Цитата
думаю что если кристалл 3 отправить в ребут то события уйдут
Понял. Попробую перегрузить. Еще один дурацкий вопрос: не приходилось сталкиваться с перезагрузкой отдельного кристалл. Платы - да, станцию в целом - да, а вот отдельный, зависимый кристалл - что-то не припомню такого. Команда reboot, я так понимаю, здесь не поможет. Достаточно ли перезагрузить просто платы INTIPB на этом узле?
Большое спасибо!
Инциденты 3660 в большом количестве, Постоянно с периодичностью чаще одного раза в минуту регистрируются события
Уважаемый, Vad! Прошу прощения, не совсем понял Вашу формулировку.
Т.е. подрядчик прав? Инциденты это следствие некорректной синхронизации?
Но если есть проблемы почему станция помимо этих инцидентов не подает никаких знаков? Infocs тоже показывает, что все в норме. Качество телефонной связи по данному потоку нормальное.
Провайдер - Ростелеком.
Спасибо.
Инциденты 3660 в большом количестве, Постоянно с периодичностью чаще одного раза в минуту регистрируются события
Прошу Вашей помощи. После установки выноса в удаленном офисе на основном узле постоянно фиксируются события
0:3660 = status of 8KFS (0 is OK, 1 is KO): 0, value: 3029 0:3660 = status of 8KFS (0 is OK, 1 is KO): 1, value: 3028
Эта пара событий с 0 и 1 повторяется примерно раз в минуту или чаще. К основному узлу уже был подключен один вынос по IP через связку INTIPA - INTIPB. Пару месяцев назад подключили еще один вынос по оптике, но в этот раз через связку INTOFA-INTOFB. На всех площадках имеется DECT (может быть связано с ним), но на основной площадке используем RBS c платами DECT8 , а на удаленных IBS и соответственно eUA32.
Стоит также отметить, что второй вынос подключен сразу двумя линками INTOF, т.е. в основном узле установлены две платы INTOFA, которые разными оптическими трассами подключены соответственно в две платы INTOFB выноса.
В описании инцидента рекомендуется перезагрузка платы INTOF. Перезагружал поочередно обе. При перезагрузке первой инциденты продолжаются фиксироваться со ссылкой на вторую плату. При перезагрузке второй - все наоборот.
Подрядчик, который ставил вынос, уверяет, что в данном случае линки просто резервируют друг друга, т.е. по факту используется только один линк, а второй просто простаивает, ожидая, когда умрет первый. Также подрядчик отметил, что какой-либо петли в этой топологии (по аналогии с Ethernet) возникнуть не может.
На вопрос относительно инцидентов, подрядчик объяснил проблему плохим качеством потока E1 с ГТС. Дело в том, что основная полка подключена к ГТС по E1 через наше же оборудование SDH. Согласно слов подрядчика, некачественный поток E1 не позволяет кристаллу нужным образом синхронизироваться. Также, с его слов, отключение синхронизации узла с E1 устраняет проявление указанных инцидентов.
Хочу услышать Ваше мнение относительно причин возникновения инцидентов, способов борьбы с ними, а также корректности предположений подрядчика.
Большое спасибо!
S0 bus exists, При смене типа аппарата или удалении
А как мне узнать какой S0 аппарат был создан? Т.е. что (точнее где) я должен удалять по п.1 Вашего ответа? Это там же в разделе Users? Но какой у него номер получается?
S0 bus exists, При смене типа аппарата или удалении
Одному из пользователей вместо цифрового аппарата решили установить IP Touch. Сделали все не путем удаления-создания, а с помощью изменения типа с цифрового на IP (IP аппарат изъяли у другого пользователя, которому наоборот поставили цифровик, так же путем изменения типа). Подключили телефон и обнаружили, что аппарат постоянно уходит в перезагрузку после последнего 5-го этапа. При этом на станции телефон "пророс" в том плане, что у него появились MAC и IP адреса в TSC/IP свойствах.
На станции при этом регистрируется инцидент 3:0377=ip phone init incident Not an ip set
Решили пересоздать абонента, удалив его для начала. Однако удалить абонента не удается - появляется ошибка Object -1: Attribute 0: S0 bus exists. Изменить тип аппарата назад на цифровик также не получается - та же самая ошибка.
Прошу помочь в разрешении тупиковой ситуации: 1. Почему аппарат может постоянно уходить в перезагрузку с регистрацией указанного инцидента? 2. Как все-таки удалить абонента в условиях возникновения указанной ошибки?
Большое спасибо!
Не регистрируются пропущенные вызовы, На цифровом телефоне не отображаются пропущенные звонки
Ясно. А подскажите пожалуйста, администратор может как-то уточнить что именно заказано. Ну с переадресацией понятно - Users/Descendant/Dynamic State User. А со всем остальным как? Там же?
Спасибо!
Не регистрируются пропущенные вызовы, На цифровом телефоне не отображаются пропущенные звонки
Действительно дело было в параметрах ISDN subscriber. Большое спасибо!
От этого абонента (а также еще нескольких человек) жалоба еще на то, что когда они снимают трубку, намереваясь сделать вызов, вместо непрерывного гудка слышать очень короткие (милисекунд по 300). Но звонить они при этом могут.
Что это за гудки такие? Phone Feature COS аналогичен другим абонентам.
Спасибо
Не регистрируются пропущенные вызовы, На цифровом телефоне не отображаются пропущенные звонки
Спрашиваю со слов пользователя. Проверить в данный момент возможности нет, т.к. пользователь находится на узле в другом городе. Но пользователь не полный дундук - раньше у него все работало и после какого-то момента перестало, так что просматривать пропущенные он точно умеет. Насчет внешних и внутренних уточню, но вроде как жалоба и на те и на другие. Можно поподробней насчет загрузки софта?
1.Вот в моем листинге есть строчка
Код
** 1 IPTOUCH TDM phones are not updated with the right binary !!
Т.е. какой-то аппарат не обновлен? Почему это может произойти и как все же форсировать обновление?
2. Жалобы поступают от абонента 3204. В листинге как раз есть данный абонент, значащийся как out of order
Код
| IPTOUCH TDM out of order
+----------+-------+-------------+-----------------+--------+--------------+-------------------+------------+
| QMCDU | Neqt | Cry/Cpl/Trm | Name | Type | Dw Policy | Custo | Local |
+----------+-------+-------------+-----------------+--------+--------------+-------------------+------------+
| 3204 | 00588 | 0/ 9/ 1 | Ivanova T.V. | IPTOUC | DELAYED | | chi2.01.01 |
Т.е. аппарат неработоспособен и необходимо его менять? Ведь других нареканий к аппарату, кроме пропущенных, нет. Неужели из-за этого станция определила его как нерабочий?
Спасибо!
Не регистрируются пропущенные вызовы, На цифровом телефоне не отображаются пропущенные звонки
Помогите пожалуйста.Некоторые пользователи жалуются на то, что на их телефонах не регистрируются пропущенные звонки. Вот, в частности, сегодня поступила заявка по данной проблеме. У абонента цифровой аппарат. Обратил внимание, что по downstat t -> 4 отображается два аппарата, в том числе принадлежащий данному юзеру
Код
Your choice ? 4
*** IPTOUCH-A(4019) TDM : soft : 3.81.00
*** IPTOUCH-B(4029) IPTOUCH-C(4039) TDM : soft : 3.81.00 - data : 3.81.00
*** Download time optimization: FOR EACH SET
** 32 IPTOUCH TDM phones are declared on this node !!
** 1 IPTOUCH TDM phones are not updated with the right binary !!
** 0 IPTOUCH TDM phones can be reseted for update !!
| IPTOUCH TDM out of order
+----------+-------+-------------+-----------------+--------+--------------+-------------------+------------+
| QMCDU | Neqt | Cry/Cpl/Trm | Name | Type | Dw Policy | Custo | Local |
+----------+-------+-------------+-----------------+--------+--------------+-------------------+------------+
| 3204 | 00588 | 0/ 9/ 1 | Ivanova T.V. | IPTOUC | DELAYED | | chi2.01.01 |
| 3117 | 00598 | 0/ 9/11 | Petrov | IPTOUC | DELAYED | N/R | N/R |
+----------+-------+-------------+-----------------+--------+--------------+-------------------+------------+
Total IPTOUCH TDM Phones out of order 2
IPTOUCH TDM phone downloaded informations :
-------------------------------------
1 Display up to date IPTOUCH TDM phones
2 Display IPTOUCH TDM phones not yet updated
3 Display download in progress
4 Display out of order IPTOUCH TDM phones
5 Display all IPTOUCH TDM phones
0 Quit
Может ли это быть причиной проблемы? Что за статус у аппарата DELAYED (отложенный, кто или что его отложило)? Как можно устранить данную проблему? Пробовал перезагрузить плату eUA32, к которой подключен аппарат - не помогло.
Просветите пожалуйста на тему сертификации инженеров ACFE/ACSE. Какие предварительные требования к сертифицируемому? Необходимо ли предварительное обучение? Сколько нужно сдать экзаменов, какие, сколько стоят? Где можно сдавать экзамены (PearsonVUE, Prometric)? Что из себя представляет экзамен: тест или лабораторная? Сколько времени и какое кол-во вопросов? Каков проходной балл?
Большое спасибо!
О влиянии hunt группы на доступ к внешним сетям, При указании HG не удается позвонить на межгород
Есть абонент с определенным Public network COS, согласно которому в соответствии с правилами дискриминатора и зон ARS, данному пользователю разрешены звонки на межгород.
Как только прописываю абоненту hunt-группу при наборе первых цифр междугороднего вызовы идет отбой с сообщением "Функция отклонена"
Может ли как-то влиять (и если может, то как) задание hunt-группы на правила дискриминатора?
Спасибо!
Инциденты DECT, Инциденты после изменения PARI PLI
Для того чтобы работал Distant Mobility пришлось на одной из станций поменять PARI/PLI значения, для приведения в соответствие с другими станциями. После изменения естественно поотваливались все трубки. Зарегистрировал их заново. Возможно небольшое число трубок осталось неперерегистрированными (работники в отпусках). Плату DECT и станцию не перезапускал, т.к. вроде и так все нормально работало. Сегодня обратил внимание на множество инцидентов с источником DECT:
Код
08/05/14 06:21:12 000004M|000/02/-/---|=4:3841=DECT8 WINDI software anomaly {2 b 0 3f 18 1e 0 0 0}
08/05/14 06:22:16 000004M|000/02/0/004|=5:1381=DECT (CTM) Radio Fixed Part put in service: cspver 24 bsver 83
08/05/14 06:22:47 000004M|000/02/0/004|=3:1378=DECT (CTM) loss of base station: cspver 24 cause 1 param 255 bsver 255
08/05/14 06:22:52 000004M|000/02/-/---|=4:3841=DECT8 WINDI software anomaly {2 b 0 53 3d 1e 0 0 0}
08/05/14 06:23:52 000004M|000/02/-/---|=4:3841=DECT8 WINDI software anomaly {2 b 0 91 56 1e 0 0 0}
08/05/14 06:26:09 000004M|000/02/0/004|=5:1381=DECT (CTM) Radio Fixed Part put in service: cspver 24 bsver 83
Подскажите пожалуйста, с чем связаны данные события, насколько они критичны и как от них избавиться.
Тема настроек COS для меня пока что достаточно мутна. Помогите пожалуйста разобраться в следующей ситуации.
Есть сеть из станций OXE, расставленных по региону и соединенных ABC гибридными линками. Согласно текущим настройкам если абоненту некоторой станции назначен Public Network COS = 2, то он может звонить только абонентам внутри сети, Public COS = 3 разрешены звонки на ГТС, Public COS = 4 разрешены междугородние вызовы. Один из узлов, который внедряли последним выбивается из общей схемы и портит картину: если некоему абоненту этого узла присвоить Public COS = 4, то он может успешно дозваниваться до абонентов этого же узла, но НЕ МОЖЕТ звонить абонентам других узлов (на аппарате высвечивается Busy). Стоит сменить COS на 2, вызов не внутренних абонентов других узлов проходит, но естественно не доступен город.
В какой части Public Network COS может влиять на вызовы между внутренними абонентами, пусть и расположенными на разных узлах, соединенных по IP.
Спасибо!
Инциденты после установки патча, Инциденты 2686, 1603, 1607
Проверил соответствие OPS-файлов реальному положению вещей с платами.
В файле hardware.mao имеются данные о платах 3. ez32 8. INTOF2C-MO 27. INTOF2C-MO
По факту данных плат нет.
И наоборот. Согласно файлу 13-й слот должен быть пустым, но по факту установлена плата NDDI. Т.е. несоответствия имеются.
Наверное, важно еще отметить следующую историю. Незадолго до своего ухода предыдущий администратор совместно с подрядной организацией занимались апгрейдом. Дело в том, что у нас скоро открывается еще один филиал, в этой связи был приобретен вынос, связывающийся с данной станцией через INTOF. Сам вынос пока еще не подключен (лежит на складе), но, возможно, попытки его подключения были. По крайней мере, точно знаю, что производилась установка новых лицензий на основной узел для обеспечения возможности подключения выноса. Также были установлены платы IO2N и обновлен софт с 10 до 11 версии.
Является ли текущее положение дел с платами причиной возникающих инцидентов? Даже если принять, что инцидент 2686 может быть связан с данным несоответствием (он имел место до установки патча 33), то инциденты 1603,1607 ранее не появлялись и были спровоцированы последним патчем. В чем их причина - неясно?
