Смотря сколько абонентов. На малое количество можно и на виртуалке развернуть.
Можно ещё вот это:
www.qmsystem.ee - будет дешевле NICE

ALU OmniPCXRecord

Откатить так и не получилось - мало времени заказчик дал на тесты. Но проблему решили так:

1. Файлы Актис переделали чётко под конфигурацию плат
2. Удалил все файлы Actis в usr3/mao
3. Остановил телефонию
4. Загрузил переделанные файлы Актис
5. Запустил телефонию

Транзит поднялся. Спасибо за поддержку.

Непонятно только где ещё остатки OPS файлов остаются. Я чищу software.mao в 2-ух местах:
usr3/mao
DHS3data/mao

Всё равно видит последний номер 9 OPS и не даёт поставить предыдущий 7.

Да. Проблема с транками. После добавления 32 цифровых абонентов пропал транзит ГородЕ1->PrivateISVPN по Е1
Ключи снёс как показано выше - транзит появился, но появились новые глюки. Причём ключи вычистились не полностью - при установке повторно ключей вижу что есть например PhoneBook users.

CfgUpdate правил т.к. не давало создавать SIP транк группу - это тех ком разрешал делать.
Т.е. после правки CfgUpdate я должен изменённые параметры сообщать Актис-продавцу?

Доброго времен суток всем,
Есть подозрение что новые ключи не правильно сконфигурированы - после их установки возникли проблемы. Пытаюсь вернуться на предыдущие вот так:
Удаляю в usr3/mao
*.hw
*.zip
*.swk
hardware.mao
sofware.mao
sofware.new
offer.num

Рестартую.
Ставлю предыдущие ключи. Даёт ошибку:
File version = 8
>
> Previous file version = 9
> *************************************
> * 5 remaining day(s) to fix this issue
> *************************************

Пробовал со стартом и без старта телефонии - одинаково.
Где-то ещё сидит последний ключ. Где?

Доброго времени суток всем,
Имеется OXE версии 11.0. На OXE имеется 60 SIP абонентов на планшетах по WiFi. Заказчик хочет зашифровать голосовой трафик этих абонентов. Актис шифровать даёт только абонентов c телефонами ALU. Можете посоветовать решение?

Попробуйте поставить тип протокола CLIP на плате в dual tone signal и перезагрузите плату.

Но ведь 3 платы INTIP2 находятся в 0 шелфе и привязаны к домену 0. Соответственно и абоненты 0 шелфа должны ходить через свой домен 0 и соответственно свои доменные платы INTIP2 или я ошибаюсь?

У меня 3 платы INTIP2. 2 из них находятся в разных TG для организации H.323 стыка с OXO. Одна из плат нигде в транкгруппах не прописана. Все платы находятся в домене 0 (смотрю в Ethernet parameters конкретной платы).
Под SIP TG я понимаю SIP trunk group.
Mutual aid with remote ACT: 0 : No Mutual aid: no mutual aid possible with remote ACT

Правильно, SIP TG не привязывается к железу но привязывается к своему домену. Соответственно и должна пользоваться как мне кажется и как описано в доках ресурсами своего домена, т.е. в моём случае ресурсами 3-ёх плат INTIP2. У меня так не происходит.

SIP TG находится в процессорном кристалле 0, там же где и 3 платы INTIP2.
Про IP абонента речь не шла. К кристаллу 0 через SIP TG приключена железка (колл-центр стороннего производителя например)

Не совпадает. По этим правилам кодеки я должен брать в первую очередь из своего IPMG (или кристалла)-что в принципе логично. У меня не так.

Доброго времени суток всем,
Имеется OXE с 3-мя платами INTIP2 и более 20-ти удалённых выносов MG. Вчера заметил что на на одном из MG выдало ошибку что не хватает кодеков. Запустил compvisu и увидел на этом MG что несколько каналов стоит в состоянии CG (RTP Direct : CG = Comp used:Flux RTP on GW). Я так понял что центральная станция воспользовалась кодеками платы GD этого MG для звонка на железку, подключенную по SIP. В этот момент на 3-ёх платах INTIP2 центральной станции было много свободных каналов.
Какой же принцип занятия каналов SIP TG? Как заставить брать каналы только из плат INTIP2?
MG и центральная станции в разных IP-доменах.

В пределах Астериска не только номер но даже и фамилия на русском.