Добрый день. Есть бурно развивающаяся ABCF сеть (в перспективе 80 с лишним узлов). На одном из узлов сделан alarm set, который ведет себя как ему предписано, то есть отображает приход определенных алармов. Суть вопроса такая - пока в сети 20 с чем-то узлов, проблем не было. Когда узлов станет 80 и случится (постучали по дереву) какой-то глобальный карамболь по всей сети с валом инцидентов, как это может отразиться на работе процессора того узла, на котором собираются алармы? Как сильно сбор алармов нагружает проц?
Здравствуйте. Я в недоумении. Смотрю номерной план центральной станции в ABCF звезде, и вижу, что примерно два десятка номеров встречаются дважды (как локальный внутр. номер и Speed Dial, как Network Number и SD, как SD и другой SD). Как так могло выйти? Какие грабли будут при аудите?
Integrated Cellular Client, Не идет звонок на мобильный
Добрый день. Имеем ОХЕ R10.1.1-j2.603-25-a-ru-c7s2. Клиент запросил возможность одновременного вызова на стационарный телефон и на мобилу. Настраивалось все по разделу Integrated Cellular Client. Ключами DISA и Remote Ext открыты. Схема включения такая: OXE1 --> PRI --> OXE2 --> PRI --> Город. ОХЕ2 - чистый транзит. На ОХЕ1 настроил все точно по документации, виртуальных номеров создал 10 шт. При звонке на 5002 (internal cellular ext.) получаю трассу без поля called number. Причем вызов продолжает куда-то идти еще 12 секунд, несмотря на то, что по трассе все давно отвалилось. Куда ковырять, подскажите, пожалуйста.
Здравствуйте. Давненько не делал апгрейдов на дублированных системах, подзабыл. Для определенности, 20 процессор - Main, 06 - StandBy. 1. Заливаем новые ключи на 20. Рестартуем его. Дожидаемся конца загрузки. В это время 06 становится Main. 2. Заливаем ключи на 06. Рестартуем. Во время старта тормозим телефонию. 20 становится Main с новыми OPS. 3. На 06 делаем пустую базу, клонируем.
Добрый день. Имеем кристалл R11.0. При попытке чекина гостя с голосовой почтой (неважно откуда, из Оперы или hotmenu) выдается инцидент 1410: ABCA_MAO operation 10 status 65. По расшифровке выходит, что не может создать ящик по причине его неактивности. В голосовой почте, само собой, ящик не появляется.
Начал смотреть ключи и углядел, что lock 59 Hotel manager = 0. На всех прочих наших гостиницах он отличен от нуля. Может быть в этом дело?
Добрый день. Имеем OXO R920.017.001. Звонок приходит из города по потоку,попадает на виртуальный номер с безусловной переадресацией на АА (Single function AA --> transfer to subscr/group --> 201. При этом AA Default function = transfer to subscr/group --> 201, Mailbox Default Function = Not used). Косяк вот в чем: в приветствии про возможность донабирать внутренние номера ни слова, однако некоторые ушлые звонящие пытаются донабрать, и дозваниваются до внутренних номеров. Отключил метку AAGrDialing, теперь после первой же цифры сразу говорит "соединяю" и падает на 201. 201 не в аттендант группе, если что.
Это баг или фича? Как совсем запретить донабор?
Есть мысль попробовать через Personal Greeting абонента 201.
Коллеги, здравствуйте. Есть кристалл R10, через которую звонят друг другу периферийные MG (IP speed dial). На периферийных не включено откладывание тикетов. Омнивиста видит все узлы. Задача - детальная тарификация абонентов всех станций.
Собственно, вопрос - как правильно сделать: включить тарификацию на периферийных станциях и вистой забирать оттуда (есть нюанс - юзера на них кое-где пересекаются) или работать только на центральном узле через включение фильтров на входящие звонки.
Попутно вопрос - как со станции посмотреть файлы с IP звонками IPxxxx.DAT? Обычный способ, как для не IP тикетов, accview -tf не работает. Команда ipview не понимает ключа -tf.
Добрый день, коллеги. Есть центральная ОХЕ (кристалл R7.1) и включенные в нее потоками (не ABCF) маленькие MG разных видов. На всех есть SIP абоненты. Через центральную АТС они ходят в город. Плюс есть 4760, которая ходит на все узлы. Все станции поднимаются до R10.1, 4760 превращается в 8770. С подъемом станций я проблем не ожидаю, но все-таки, с чего более грамотно начать: с центра, с периферии или с омнивисты? И как вообще происходит миграция 4760 - 8770? На сайте поиском не нашел ТС по этому поводу.
Здравствуйте. Настраиваю свой первый IP DECT (OXE кристалл R10.1.1, базы 4080IP AP300E). Есть вопросы.
1. Подключил два DAP (включены в один свитч, лежат на расстоянии 2 метров). Регистрирую трубку, появляется subscription на одной из баз, звонки идут. Потом отрываю ту базу, на которую была прописана трубка. По идее, абонент должен переключиться на второй DAP, но переход происходит только через 5 минут - минимальное значение таймера из DECT Settings/Move subscription non operational DAP.
2. Почему в DECT Settings количество цифр в PARI всего 8? Разве оно не должно соответствовать PARI в станции?
3. Подкючил к системе трубку Mobile 200. Прописалась, статус абонента в менеджере стал Subscribed, Present, Registered. В SIP трассе регистрация успешная, 200 ОК. Но трубка цифр не набирает, при звонке на нее трасса пустая, на дисплее звонящего телефона Network Congestion.
Здравствуйте, колеги. Одному клиенту поставляется следующий набор: 1. OmniVista 8770 2. IP DECT 3. OmniPCX Voice Record 4. Call Center 5. Барсум. Плюс ОХЕ кристалл к несколькими 4059 IP, которые будут жить пока неизвестно где. Стоит задача уменьшить количество физических серверов под это все. Известно, что 1 и 2 уживаются вместе на одной системе, под Барсум клиент согласен дать отдельный сервер. А вот 3 и 4 могут с чем-то сожительствовать или работать на виртуалках?
Коллеги! Имеется гостиничная ОХЕ R9.1 Crystal, и Attendant Group о трех аттендантах 4059IP. Входящий из города падает на Entity Call, где первой очередью стоит Attendant Group, второй - хантгруппа. При неответе аттендантов по таймеру в entity Overflow Timer вызов перетекает на вторую очередь. Все как надо. А внутренние звонки, сделанные на тот же Entity Call, долбятся у аттендантов до посинения. Я прочел в доке, что тот таймер работает для внешних звонков. Есть ли какой-нибудь альтернативный способ получить для внутренних звонков перетекание по неответу с операторской группы?
Здравствуйте, коллеги. Так получилось, что в соседних корпусах одного комплекса живут две разные ОХЕ (одна кристалл, вторая common hw), обе с DECT, и PARI у них одинаковый. Так вот, через два дня после запуска второй станции на первой начались проблемы: отвалились две базы (ну, это, скорее всего, совпадение) и в районе баз, географически близких к зданию со второй станцией, начались беды с уровнем сигнала.
Что делать - менять PARI на второй с перерегистрацией трубок?
Здравствуйте. Имеем MG R10.1.1, по сетевой архитектуре нод 14, смотрящий двумя гибридными линками в ноды 1 и 2 той же сети. Проблема такая: во вражеском техзадании (французы делали) сказано, что аксессы в линках должны быть 19-0-0 и 19-0-1 (Signaling type = IP). У меня же упорно создаются 19-0-2 и 19-0-3. Удалял, ребутил, делал заново - та же петрушка. Фокус в том, что самый первый раз создались правильно, 19-0-0 и 1, но что-то мне там не понравилось, удалил, и вот теперь никак к канону не вернуться. PS Насколько это вообще принципиально?
Здравствуйте, коллеги. Хочу поделиться опытом. Подключал аппарат 4135 к OXE в железе MG. После создания абонент не жеьает регистрироваться. Отключаю регистрацию - начинает звонить. Включаю регистрацию - регистрируется и звонит. Ребут АТС (регистрация включена). После ребута не регистрируется. Отключаю регистрацию - пошли звонки. Включаю регистрацию - регистрируется и звонит. Пробовал на патчах 20i и 22.
Фокус в том, что к 9.1 (правда, в кристалле) регистрируется сразу без танцев.