Здравствуйте, колеги.
Одному клиенту поставляется следующий набор:
1. OmniVista 8770
2. IP DECT
3. OmniPCX Voice Record
4. Call Center
5. Барсум.
Плюс ОХЕ кристалл к несколькими 4059 IP, которые будут жить пока неизвестно где.
Стоит задача уменьшить количество физических серверов под это все. Известно, что 1 и 2 уживаются вместе на одной системе, под Барсум клиент согласен дать отдельный сервер. А вот 3 и 4 могут с чем-то сожительствовать или работать на виртуалках?

Ну, самое первое - поменять коробочку.

To ERROR  насчет VM мысль интересная, если есть лицензия Complete Value Pack.

To VAD  ходили через префикс. Через роутномер не пробовал. Вернусь через неделю с учебы, продолжу.

Спасибо всем за помощь.

Для информации по первоначальной теме.

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.

Resolution

Normal behaviour.

Я пытаюсь смоделировать ситуацию у клиента. Есть три аттенданта, на которых приходит и город, и внутренние звонки , в том числе и от гостей. Днем, когда включены все три консоли, все вызовы успевают обрабатываться. Вечером остается только один оператор, который не успевает всем ответить и выстраивает очередь из звонков. Ну так клиент хочет, чтобы звонок, подождав в очереди, уходил дальше на хант группу обычных телефонов. И городские звонки так и делают. В трансляторе номер приходит на entity call, в этом entity 1-й дневной роутинг на группу операторов, 2-й -- на ту хант группу. При этом включен Overflow timer, и городской звонок уходит на вторую очередь. Внутренний делается на тот же префикс entity call, и не переходит на вторую очередь. И по QSIG-петле тоже, блин, не переходит!
Эта же очередь расписана и в CDT операторской группы.




To ERROR: нет, В-канал не освобождается.

Родился альтернативный вариант: ставим клиенту NPRAE, замыкаем потоки и префикс 0 запускаем в поток с приходом теперь уже "городского" вызова на группу операторов. Пока тип ТГ обычный PRI, все хорошо перетекает, но нет имен. Сделал ТГ ABС-F со ссылкой на Network Routing Table c QSIG-GF, и получается следующая ерунда: при вызове с поточной петли на оператора вижу, что идет звонок с Entity_0, хотя в трансляторе направлен на Entity call с энтити 2. Где entity подменяется?

Все сам нашел, это энтити юзера.

В общем, по QSIG вызов тоже не перетекает. Есть какие-нибудь идеи?

Нет, не получается. Таймер 4 = 150, таймер 9 = 120. В категории разрешено все, что можно. Не перетекает.

Коллеги!
Имеется гостиничная ОХЕ R9.1 Crystal, и Attendant Group о трех аттендантах 4059IP. Входящий из города падает на Entity Call, где первой очередью стоит Attendant Group, второй - хантгруппа. При неответе аттендантов по таймеру в entity Overflow Timer вызов перетекает на вторую очередь. Все как надо. А внутренние звонки, сделанные на тот же Entity Call, долбятся у аттендантов до посинения. Я прочел в доке, что тот таймер работает для внешних звонков.
Есть ли какой-нибудь альтернативный способ получить для внутренних звонков перетекание по неответу с операторской группы?

Ну, да. Спасибо за подтверждение, так и сделали. Кстати, у нас станций сотни, ни для одной Алкатель не присылал ПАРИ. Или его отдельно запрашивать надо?

Здравствуйте, коллеги.
Так получилось, что в соседних корпусах одного комплекса живут две разные ОХЕ (одна кристалл, вторая common hw), обе с DECT, и PARI у них одинаковый. Так вот, через два дня после запуска второй станции на первой начались проблемы: отвалились две базы (ну, это, скорее всего, совпадение) и в районе баз, географически близких к зданию со второй станцией, начались беды с уровнем сигнала.

Что делать - менять PARI на второй с перерегистрацией трубок?

Попробую полностью удалить линки и рестарт.
После удаления аксессов в Х25 все чисто.

А как же - и SIP, и IP телефоны присутствуют.
Что-то у меня пробел в теории. 19-0 - виртуальная плата UA16, 19-1 и 19-2 -- INTIP3. Почему аксесс создается на 19-0?

Именно линки целиком удалять? Я удалял только аксессы из линков, потом fichges --> reboot.

Здравствуйте.
Имеем 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 Насколько это вообще принципиально?

Кстати, а как правильнее создавать абонента: SIP device или SIP extension? У меня работает и так и так.