С персональным приветствием все красиво заработало, кроме одного нюанса - хотелось бы сначала пять-десять секунд приветствия, а потом вызов приходит на аппарат. Но, похоже, только два варианта - до распределения вызовов и одновременно. Невелика беда.
Добрый день. Имеем 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.
Дмитрий, спасибо. Пока ждал ответа, уже включил на всей периферии откладывание аккаунтинга. Вроде все работает. Пока нужны просто отчеты по абонентам каждой станции - кто, куда и сколько звонил. Это работает. А еще клиент хочет стстистику по нагрузке IP транк группы. Чтобы по заданному периоду показывать нагрузку на кодеки. В виде графика или диаграммы. Ну или просто пиковые значения в виде какой-то таблицы. Есть идеи, какой предсозданный отчет можно применить?
Коллеги, здравствуйте. Есть кристалл R10, через которую звонят друг другу периферийные MG (IP speed dial). На периферийных не включено откладывание тикетов. Омнивиста видит все узлы. Задача - детальная тарификация абонентов всех станций.
Собственно, вопрос - как правильно сделать: включить тарификацию на периферийных станциях и вистой забирать оттуда (есть нюанс - юзера на них кое-где пересекаются) или работать только на центральном узле через включение фильтров на входящие звонки.
Попутно вопрос - как со станции посмотреть файлы с IP звонками IPxxxx.DAT? Обычный способ, как для не IP тикетов, accview -tf не работает. Команда ipview не понимает ключа -tf.
Ну, собственно, все. По факту все отличается от обещанного - один кристалл в центре, соединенный IP транк группами с кучей MG. Все друг другу через IP сокращенные номера. ABCF нет. SIP нет. Так что по сути - отдельные апгрейды.
Проблем особых не возникло, кроме нюанса с платами GD - 4 рестарта надо для того, чтобы схватились новые бинарники.
vad пишет: Особо тревожного нет - надо просто ПЕРЕД апгрейдом посмотреть таблицу совместимости (чего не будет работать в 10.1), прочитать ТС по инсталляции и посмотреть таблицу по совместимости баз данных (были нюансы - из какого патча/релиза в какой можно переползать смело).
После прочтения ТС1854 ed2 (OXE patch alignment procedure) впал в недоумение. Таблица начинается с g1.503.35. Про ранние релизы вообще молчок. А мне надо двигать с f5.401.17. Будут совместимы базы?
Стоп! Назад! В Актисе углядел у всех узлов VoIP H323 Network Links for ABCF Network = от 8 до 20 Сначала увидел Number of nodes in network = 1 у всех и успокоился...
vad пишет: Это хорошо, что не видите проблем с апгрейдом ОХЕ (хотя в 10.1 могут быть заморочки при наличии старого железа - RT2, SUVG, при использовании каких-то протоколов - R1.5).
Звучит тревожно. Старого железа, R1.5 нет. Какие могут быть грабли?
Добрый день, коллеги. Есть центральная ОХЕ (кристалл R7.1) и включенные в нее потоками (не ABCF) маленькие MG разных видов. На всех есть SIP абоненты. Через центральную АТС они ходят в город. Плюс есть 4760, которая ходит на все узлы. Все станции поднимаются до R10.1, 4760 превращается в 8770. С подъемом станций я проблем не ожидаю, но все-таки, с чего более грамотно начать: с центра, с периферии или с омнивисты? И как вообще происходит миграция 4760 - 8770? На сайте поиском не нашел ТС по этому поводу.
vad пишет: 1. А разве оно должно быстро переключиться? Это IP, работоспособность контролируется не мгновенно, трубка регистрируется на базе!! (DAP), не на станции, соответственно, пока не будет принято решение, что она (DAP) умерла - перерегистрации на новую базу наверное не произойдет.
А как же тогда переключение с базы на базу при перемещении трубки? (Handover или switchover - все время путаю...) К сожалению, ограничен размерами комнаты, толком это не попробовать.
Цитата
2. Вы про какие установки (про 8 цифр в PARI)? Вы случаем не про КОЛИЧЕСТВО возможных PARI в ОХЕ спрашиваете (в ОХЕ может быть до 8 PARI, вы можете разным шелфам присвоить разные PARI, абоненты отдельных шелфов будут работать ТОЛЬКО в своих зонах - как будто это разные станции).
Нет, это не в станции. Это в IP DECT Manager, в настройках системы можно (и нужно, без этого не работает) ввести PARI. Там только одно поле, и максимум можно ввести 8 знаков. Впрочем, поскольку трубки не регистрируются на станции, станционный PARI может и не совпадать с DAP Managerовским. Интересно, а нужен вообще PARI на станции при использовании IP DECT?
Цитата
3. А про Mobile 200 - кто-то обещал, что он будет работать? Всякие нюансы с кодеками (типа выключить multialgorithm for compression) указали?
Указал, само собой. Это в доке прямо указано отключить. Что интересно, трубка Mobile 200, а определилась как 400. Видимо, 400-е должны работать, жаль, на руках ни одной нет.
Здравствуйте. Настраиваю свой первый 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.
Спасибо всем за помощь. to Error: дело тут вовсе не в нашей жадности. Мы как раз клиенту видвинули все по-честному: пять систем - пять серверов. А клиент сказал, что мы офигели и попросил урезать. Такие дела...
Пока что дела обстоят так: на одной машине (не виртуальной) посадил 8770, CCSupervision и IP DECT. Вроде бы все работает. Ну, а рекордер на отдельную машину, так спокойнее.
