Накатил сегодня патч на УАТС с 11-м релизом, обновив ранее используемый патч 33 до версии 37. Перед установкой патча скопировал текущие версии на неактивные разделы на обоих процессорах. В общем, в результате после всех манипуляций все работает. Единственный момент, который смущает, это то что на станции стали появляться инциденты, которых раньше не было, с частотой примерно раз в 5 минут:
Код
10/09/16 13:02:27 000001S|00/23/-/---|=3:2040=Std By CPU. Bad term type = T_RESU instead o
f JONCT Msg 32 n_term 2
На данном форуме и на Alcatel Unleashed видел рекомендации о необходимости выполнить клонирование на резервный процессор с основного. Сделал клонирование: остановил на резерве телефонию, перезагрузил его с остановленной телефонией, далее через swinst -> Cloning and Duplicate выполнил клонирование на резерве с основного всего за исключением linux данных. Включил автостарт и перезагрузил резерв. Инциденты продолжают появляться.
Проверял целостность БД командой checkdb на обоих процессорах - ничего кроме сообщения об отсутствии DPNSS префикса нет. Наличие ошибки по DPNSS, думаю, не является критичным. По крайней мере, вряд ли это причина данного инцидента.
Нужно добавить что все операции - установка патча, клонирование и т.д. выполнял, подключаясь удаленно по IP (просто видел где-то рекомендации выполнять эти операции по консоли), но неужели это может влиять?
Подскажите пожалуйста, в чем может быть причина инцидентов и как ее устранить?
Большое спасибо!
G711 по входящей связи, Добиться использования G711 при звонке на УАТС
Все-таки хотелось бы для полноты картины добиться того, чтобы с устройств конференц-связи тоже можно было бы звонить на УАТС. К сожалению, в настоящий момент это невозможно, т.к. станция использует кодек по умолчанию G723, плюс за счет включения мультикомпрессионности отрабатывает еще кодек G729. Но так как Cisco C40 использует G711 входящая связь с нее недоступна. Для исходящей связи была создана отдельная транк-группа с типом кодека G711.
Какие есть варианты в этом случае? Использовать префикс захвата это новой ТГ при звонке с Cisco C40 только?
Спасибо!
О проблеме выбора платы INTIP и кодеках, В сообщений SETUP указан адрес соседней платы, изменить типа кодека
Имеется следующая проблема - не удается связать по H323 УАТС и аппаратный кодек Cisco C40, к которому по аналогу подключена система аудиоконференцсвязи. На УАТС настройки все выполнил согласно документации - создал ячейку сокращенного набора типа IP, где прописал IP циски, создал транк-группу, привязал ее к незадействованному доступу одной из плат INTIP. При звонке со станции вызов проходит на циску, однако когда на ней (циске) снимаешь трубку, то с точки зрения циски вызов кажется установленным, а на станции продолжает идти КПВ. Иногда, примерно 1 из 10 случаев, соединение устанавливается с двух сторон, но на телефоне УАТС слышны жуткие трески. По трассировкам полученным с помощью t3 видно, что когда не устанавливается двухсторонней связи, на УАТС не приходит CONNECT, однако согласно дампам, собранным Wireshark-ом видно, что CONNECT циска все же отправляет, просто он не распознается станцией по каким-то причинам.
Так как станция по умолчанию работает на кодеке G723, а Cisco C40 поддерживает кодеки G711 и G722, нами выполнены следующие настройки на станции: 1. Включен режим задействования нескольких кодеков Multicompression (раздел документации IP PCX Networks -> Direct RTP in network -> Coding Configuration -> Multi-Algorithms). В результате станция в SETUP сообщений отправляет 2 поддерживаемых кодека – G723 и G729. 2. В созданной для взаимодействия транк-группе на УАТС 150 типа IP указан тип кодека G711.
В результате станция в SETUP отправляет 3 кодека G723, G729, G711.
Подозреваю, что проблема кроется в типе компандирования. Станция работает с A-law. Однако логах циски везде фигурирует u-law. Настроек по изменению u- на A- на циске не нашел (это не роутер, имеется только очень бедный веб-интерфейс).
Обратился в тех.поддержку. Посоветовали включить u- конкретно для доступа, к которому привязана транк-группа. Соответственно в настройке
Код
shelf>board>digital access > Mu Law for BEARER CAP
поставил YES и перезагрузил плату. Никаких положительных сдвигов.
В ходе снятия трассировки, обратил внимание, что в SETUP сообщении, которое посылает станция, указан IP адрес другой INTIP платы, также имеющейся в этой станции и используемой для межстанционного гибридного линка, т.е. созданная ТГ для взаимодействия с циско привязана к доступу 0-13-1, а в SETUP указан IP платы 0-17 (гибридный линк для отказоустойчивости использует два доступа 0-13-0 и 0-17-0).
Соответственно, вопросы: 1. Почему в SETUP отправляется адрес не своей с точки зрения ТГ адрес? Можно ли как-то прибить (закрепить) адрес за ТГ? 2. Действительно ли указанная настройка доступа позволяет задать тип компандирования для доступа, отличный от общего на УАТС? 3. Если поменять глобально тип компандирования на всех узлах с A на u (в курсе, что в Европе он не используется), скажется ли это на качестве связи с ТфОП, к которому подключены по потокам E1?
Уважительно прошу Вашей помощи, так как уже сломал мозг с этой проблемой интеграции.
Большое спасибо!
Интеграция OXE с подсистемой конференц-связи Radvision, Настроить взаимодействие УАТС и ВКС
Помогите пожалуйста в следующем вопросе. К сожалению, не силен в настройках УАТС, поэтому уповаю на вашу помощь. Задача следующая. Имеется УАТС oxe с 11м релизом и лицензиями на h323 транк. Имеется система аудио видеоконференции Radvision работающая на базе h323. Система вкс в настоящий момент изолирована, все клиенты локальны. Поставлена задача связать УАТС и вкс таким образом чтобы при звонке из УАТС на заданные номера вызов проходил в вкс на заданных абонентов.
В составе вкс имеется gatekeeper. В настройках можно прописать шлюз и другой гейткипер. Хочу поинтересоваться об общем порядке настройки данной схемы. Сам вижу так: 1. На УАТС создать speed dial префиксы типа ip с адресом гейткипер вкс. 2. На гейткипере прописать новый шлюз для заданного диапазона адресов.
Есть сомнения по поводу настройки УАТС в качестве шлюза.не нужно ли на ней поднимать тоже гейткипер?
Поправьте пожалуйста меня если я ошибаюсь с общим порядком или вы видите более правильный вариант.
На цифровых и ip аппаратах есть такая настройка в разделе меню-настройки-телефон-разъём. Вопрос-можно ли каким-то образом производить переключение с гарнитуры на наушники удаленно, средствами станции? Можно ли это переключение выполнять на горячую, т.е когда связь уже установлена? Вчера в ходе конференц-связи у руководства полетел микрофон на приставке omnisound, подключенной к цифровику. Вариантов типа подойти, разорвать связь и перенастроить телефон не было. Конференция так и прошла в режиме слушания. Не хотелось бы чтобы это повторилось.
Спасибо!
Источники питания для OXE, Какие модели порекомендуете
На имеющихся станциях OXE типа Crystal используем источники питания Efore Epos Compact и Efore Epos Pomo. Не знаю, использует ли кто-нибудь из Вас подобные решения, но со своей стороны хочу отметить минус - данные устройства не мониторятся по SNMP/Syslog. Считаю, что с учетом наличия единственного источника питания вопрос его мониторинга является достаточно серьезным. Хочу поинтересоваться, какие решения используете Вы? Мониторите ли состояние Ваших систем питания УАТС?
Спасибо!
Получение тикетов о локальных вызовах, Способы получения и ПО
Имеем две станции OXE. На каждой имеются в том числе лицензии на тарификацию локальных (внутристанционных) вызовов (Ticket Local). Для сбора тикетов используем софт Barsum Enterprise достаточно старой версии (7.5). Сбор Барсумом тикетов происходит так: станция постоянно "выплевывает" на один из COM-портов свежую информацию о вызовах, преобразователь MOXA принимает эти данные. А далее, к нему уже по IP подключен сервер Барсум. Среди получаемых тикетов не обнаруживаются те, которые содержат информацию о локальных вызовах. Позвонил нашим инсталляторам, они сообщили, что локальные тикеты можно получить только по IP, вытягивая эти данные непосредственно с самой станции (т.е. сама станция отправлять на какой-либо порт их не будет). Соответственно предложили нам обновить наш Барсум за кругленькую сумму.
Подскажите пожалуйста, действительно ли так обстоят дела с локальными тикетами. Есть ли какие-либо альтернативные решения такому ПО как Барсум (у нас есть также Omnivista с модулем тарификации, но по историческим причинам, его практически для этих целей не используем)? Может быть есть какие-то opensource продукты для работы с тарификационными данными?
Спасибо!
Запрос к БД на получение Entity и Public COS абонентов
Есть необходимость автоматизированного получения списка абонентов станции, включая параметры Entity и Public Cos. На форуме нашел команду запрос к БД на получение имен абонентов
Команда отрабатывает корректно. Вот только бы хотелось дополнить вывод обозначенными ранее параметрами для каждого абонента. Подскажите пожалуйста, как это можно сделать или хотя бы сориентируйте, в каких таблицах хранятся эти данные. Вряд ли это таблица PHONEB (телефонная книга)?
Большое спасибо!
Barring внутри сети, Ограничить возможность дозвона до некоторых внутренних абонентов
В связи с организацией helpdesk в конторе встал вопрос о технической организации единой точки входа таким образом, чтобы внутренние абоненты были лишены возможности дозвона до специалистов 2-й линии тех.поддержки напрямую. На текущий момент все абоненты распределены по двум Entity, определяющими через какую из двух публичных ТГ выходить в город.
Сориентируйте пожалуйста, как можно добиться поставленной цели. Каков порядок вкратце? Подозреваю, что нужно разбить абонентов на Entity и как-то поиграться с Cos, но конкретики, к сожалению не знаю. Тем более, неясно, как быть с уже использующимся разбиением по Entity для использования разных каналов выхода в город.
Прошу помочь советом. Подключили к OXE систему транкинговой радиосвязи по BRI. При звонке с рации транкинговой системы на абонента OXE идет отбой. Трассировка показывает, что УАТС принимает SETUP, но в ответ шлет отбой со статусом No Circuits available.
Транк-группа настроена, доступы добавлены. При trkstat показывает оба канала как F (FREE).
Что еще может влиять на возникновение указанного статуса?
Большое спасибо!
Ремонт eZ32. Case 2, После перезагрузки станции перестала работать плата
Обращаюсь с похожим вопросом относительно ремонта eZ32. Вчера меняли АКБ на станции. Предварительно выключили оба процессора, выключили блок питания, после чего станция перешла на питание на старые батареи. Заменили батареи на новые. Включили станцию и обнаружили, что одна плата eZ32 не грузится - нет индикации на плате, в config 0 пишет REG NOT INIT. Меняли плату местами с другой, работающей платой - проблема именно в данной конкретной плате. Конденсаторы на плате не вспухшие.
Помогите пожалуйста советом: 1. Что является наиболее уязвимым местом в платах данного типа? Что можно попробовать заменить для восстановления работоспособности?
2. Есть подозрение, что плата могла выйти из строя именно в результате замены АКБ. В ходе отключения старых батарей, в момент отключения клемм проскочила искра, что наверняка привело к кратковременному выбросу тока. Вообще, насколько корректно отключение АКБ наживую (CPU отключены, но на всех платах имеется питание)?
Сегодня в журнале инцидентов одной из станций обнаружил сообщения о превышении температуры CPU и HDD на обеих платах. Выяснилось, что повышение температуры было связано с отказом блока кондиционера. Сразу возник вопрос, есть ли возможность проактивного мониторинга данной информации. Проверил опрос станции по SNMP всей ветки .1.3.6.1 - к сожалению, ничего похожего на показания температуры не нашел. Следующая надежда - утилиты на самой станции, типа lm-sensors. Тоже ничего.
Подскажите пожалуйста: 1. Может быть есть ли какие-либо утилиты в составе ОС станции, позволяющие производить опрос сенсоров температуры? 2. Если изначально таковых утилит нет, нет ли опыта установки из rpm-пакетов указанного ПО? Насколько мне известно, ОС станции построена на базе Mandrake Linux. Утилита rpm в составе ОС имеется. Наверняка можно подобрать бинарный пакет того же lm-sensors, с помощью которого можно собирать много полезной информации.
Большое спасибо!
Взаимодействие CPU через внешний Ethernet, Странная перезагрузка
С целью повышения отказоустойчивости OXE были выполнены работы по настройке/включению IP Redundancy. Первоначально, имеющиеся в составе станции платы CPU7-2 (2шт) и INTIP2 (2шт) были включены в один неуправляемый коммутатор, который являлся единой точкой отказа. В ходе работ было проведено раздельное подключение указанных плат в разные коммутаторы ядра Cisco Catalyst 6509 (CPU7-2 и INTIP в один коммутатор, оставшиеся CPU7-2 и INTIP в другой коммутатор) При этом были выполнены рекомендации документации Alcatel в части отключения embedded Ethernet на платах CPU7-2 с целью корректной отработки Spanning-tree.
Код
(1)gu_06> ethctl
Thresholds configuration :
broadcast frames : disabled.
total frames : disabled.
bandwidth : disabled.
scan interval : 500 (ms).
Embedded Ethernet configuration :
jumper : disabled.
xilinx : enabled.
-> state : disabled.
External Ethernet configuration :
link config : auto.
link state : 100Mb full.
В состав IP транк-группы, используемой для построения ABC туннелей включены ресурсы обеих плат INTIP Включен механизм IP Redundancy
Код
(1)gu_06> cmdcpl 0 13 MNGT
Sat Aug 8 16:46:36 AST 2015
Del to exit tool
You have selected a board with type : INTIPA
execution from 'MNGT'
(00,13)
INTIP Management :
(00,13) - Board is INTIP-A
(00,13)
- Crystal number : 0 (Management)
(00,13) : 255 (given by S400/401 switches)
(00,13) - Coupleur number : 13 (Management)
(00,13) - Recovery Mode : Normal
(00,13)
- @ MAC : 00 : 80 : 9F : 5C : F7 : A9
(00,13) - @ IP : 10.197.133.5
(00,13)
- Voip port : 32512 [7f00]
(00,13)
- Default DSCP : 0x0B
(00,13)
- Ethernet interface is configured to Auto Negociation (Half and Full duplex)
(00,13) - Link state is 100MBps / Full duplex
(00,13)
- IP Redondancy activated
(00,13) - @IP CPU1 : 10:197:133:2
(00,13) - @IP CPU2 : 10:197:133:1
(00,13) - PING emitted every 20 seconds
(00,13) - Traffic check every 3x20 seconds
(00,13)
- Framing G729 = 20ms
(00,13) - Framing G723.1 = 30ms
(00,13) - Framing G711 = 20ms
(00,13) 000000EB-0030CFA9: End of command execution
Normal exit.
Выполнена проверка переключения сервисов телефонии на резервные компоненты при потере связи с коммутаторами ЛВС: 1. При выключении линка между ЛВС и используемой в заданный момент времени платы INTIP происходит разрыв установленных соединений между данной УАТС и другими УАТС Отделения. За достаточно короткое время работа переводится на другую плату INTIP, после чего станция готова к отработке межстанционных вызовов. При этом потеря линка основной платы приводит к ее перезагрузке. До тех пор пока линк не поднят, плата находится в состоянии INIT 1 RUN. Резюме: переключение на резерв осуществляется штатно, в приемлемые временные рамки;
2. При выключении линка между ЛВС и используемой в заданный момент времени процессорной платой CPU7-2 происходит разрыв установленных соединений между данной УАТС и другими УАТС Отделения. При этом, резервный процессор, не видя основную плату, уходит в перезагрузку. Так как перезагрузка CPU выполняется достаточно длительное время (порядка 10-15 минут), в течение всего этого времени недоступны никакие телефонные сервисы. Данное поведение кажется весьма странным.
Подскажите пожалуйста, является ли штатным поведение резервного CPU, при котором он перезагружается при отсутствии связи с основным узлом? Почему этого не происходит при работоспособном embedded Ethernet линке?
Подскажите пожалуйста насчет использования внешнего источника для Music on Hold. Есть задача проигрывания нестандартной мелодии Alcatel на удержании. На вопрос техподдержке относительно конвертации своего wav-файла в moh-файл, понятный УАТС, получил ответ, что делать это можно только с помощью специальной программы, за которую нужно выложить круглую сумму (несколько сотен евро). Было предложено использовать external music. Соответственно имеются следующие вопросы: 1. Действительно ли единственный выход - использование external music, так как без специального софта файл проприетарного формата получить не получится? 2. В документации указано, что external music нужно подавать на 9-й пин платы CPU. Не совсем понятно, куда физически нужно подключить external music, с учетом того, что CPU расшит на CBRMA. Нужно разбирать CBRMA и подключать пару проводов с передаваемым звуком куда-то внутрь CBRMA-бокса? 3. Правильно ли я понимаю, что имея ПК со звуковой платой, на станцию нужно заводить не линейный выход платы, а выход для подключения акустики?
Подскажите пожалуйста, можно ли как-то использовать плату INTIP не имея коннектора 100BaseT для нее? Плата имеется, а вот указанного коннектора, к сожалению, нет. Не знаю, как устроен указанный коннектор, но думается, что если он представляет собой пассивное устройство, то может быть можно в разъем станции вместо указанного коннектора подключить разъем для платы eZ32 (коих в у нас избыток) и далее расшить кабель от этого разъема на сетевую розетку. Знать бы только распиновку разъема для INTIP.
