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. Вроде бы все работает. Ну, а рекордер на отдельную машину, так спокойнее.
Здравствуйте, колеги. Одному клиенту поставляется следующий набор: 1. OmniVista 8770 2. IP DECT 3. OmniPCX Voice Record 4. Call Center 5. Барсум. Плюс ОХЕ кристалл к несколькими 4059 IP, которые будут жить пока неизвестно где. Стоит задача уменьшить количество физических серверов под это все. Известно, что 1 и 2 уживаются вместе на одной системе, под Барсум клиент согласен дать отдельный сервер. А вот 3 и 4 могут с чем-то сожительствовать или работать на виртуалках?
Calls entity distribution related to the internal calls which do not overflow according the cdt
Info
Only the external incoming calls are able to overflow from the attendant towards the first, second then third jump if case of no successive response. The internal calls do not follow the successive jumps according the CDT. Thus, there are no overflow towards the jumps defined in the CDT.
vad пишет: Вы всетаки так и не рассказали, как у вас настроено распределение звонков и (просто для себя интересно) что это за аттенданты такие, у которых есть вызов, но они на него не отвечают. У вас пришел вызов, вы его по CDT ентити направили на группу операторов. А что у вас написано в CDT операторской группы, может там надо второй строкой чего-то приколотить?
Я пытаюсь смоделировать ситуацию у клиента. Есть три аттенданта, на которых приходит и город, и внутренние звонки , в том числе и от гостей. Днем, когда включены все три консоли, все вызовы успевают обрабатываться. Вечером остается только один оператор, который не успевает всем ответить и выстраивает очередь из звонков. Ну так клиент хочет, чтобы звонок, подождав в очереди, уходил дальше на хант группу обычных телефонов. И городские звонки так и делают. В трансляторе номер приходит на entity call, в этом entity 1-й дневной роутинг на группу операторов, 2-й -- на ту хант группу. При этом включен Overflow timer, и городской звонок уходит на вторую очередь. Внутренний делается на тот же префикс entity call, и не переходит на вторую очередь. И по QSIG-петле тоже, блин, не переходит! Эта же очередь расписана и в CDT операторской группы.
Родился альтернативный вариант: ставим клиенту NPRAE, замыкаем потоки и префикс 0 запускаем в поток с приходом теперь уже "городского" вызова на группу операторов. Пока тип ТГ обычный PRI, все хорошо перетекает, но нет имен. Сделал ТГ ABС-F со ссылкой на Network Routing Table c QSIG-GF, и получается следующая ерунда: при вызове с поточной петли на оператора вижу, что идет звонок с Entity_0, хотя в трансляторе направлен на Entity call с энтити 2. Где entity подменяется?
Все сам нашел, это энтити юзера.
В общем, по QSIG вызов тоже не перетекает. Есть какие-нибудь идеи?
Коллеги! Имеется гостиничная ОХЕ R9.1 Crystal, и Attendant Group о трех аттендантах 4059IP. Входящий из города падает на Entity Call, где первой очередью стоит Attendant Group, второй - хантгруппа. При неответе аттендантов по таймеру в entity Overflow Timer вызов перетекает на вторую очередь. Все как надо. А внутренние звонки, сделанные на тот же Entity Call, долбятся у аттендантов до посинения. Я прочел в доке, что тот таймер работает для внешних звонков. Есть ли какой-нибудь альтернативный способ получить для внутренних звонков перетекание по неответу с операторской группы?
Ну, да. Спасибо за подтверждение, так и сделали. Кстати, у нас станций сотни, ни для одной Алкатель не присылал ПАРИ. Или его отдельно запрашивать надо?
