Переадресация в потоке

[yulyanov]

Asterisk 11.14.0. Работает в связке с АТС LG CS1000. Соединены потоком E1.
Сам asterisk работает исключительно как замена штатного IVR по схеме:
Звонок от провайдера по E1 приходит в АТС, перенаправляется в asterisk, опять же по E1, отрабатывает IVR и звонок возвращается в АТС по новому каналу потока. Оба канала заняты всё время разговора.
Есть большое желание, чтобы asterisk работал в другом режиме:
Звонок от провайдера приходил по E1 в АТС, оттуда по потоку в asterisk. Asterisk отрабатывал IVR и давал команду АТС по открытому каналу сделать переадресацию на нужный номер, после чего отрубался и не занимал каналов.
Я не уверен что это возможно, на данный момент пытался прописать такой вариант (для реакции на "2" в одном из меню, для соединения с номером 258 на АСТ):

Код: Выделить всё

exten => 2,1,DAHDISendcallreroutingFacility(258)
exten => 2,n,Hangup()

в chan_dahdi.conf:

Код: Выделить всё

callerid=asreceived
usecallerid=yes
hidecallerid=no
callwaiting=yes
overlapdial=no
pridialplan=unknown
usecallingpres=yes
callwaitingcallerid=yes
rxgain=0.0
txgain=0.0
threewaycalling=yes
facilityenable=yes
transfer=yes
echocancel=yes
echocancelwhenbridged=yes
faxdetect=both
faxbuffers=>8,full
channel => 1-15, 17-31

В ответ получаю следующее:

Код: Выделить всё

[2015-01-19 14:23:04] WARNING[3587][C-0000001a]: chan_dahdi.c:6126 dahdi_send_callrerouting_facility_exec: Callrerouting Facility without original called number argument
[2015-01-19 14:23:04] NOTICE[3587][C-0000001a]: chan_dahdi.c:6131 dahdi_send_callrerouting_facility_exec: Callrerouting Facility without diversion reason argument, defaulting to unknown
PRI Span: 1 Could not schedule facility message for CallRerouting/CallDeflection message.
aster*CLI>

Подскажите, в ту ли сторону я копаю, и возможно ли сделать то что хочется?
Надеюсь на помощь.

[awsswa]

схема работы сейчас у вас правильная - астер стоит транзитом
кроме вашего большого желания сломать рабочую схему еще какие то аргументы есть ?

[Zavr2008]

Навыдумывали..

Если логика входящих звонков - через IVR: нахрена козе баян?!!

E1 город -> Asterisk (IVR) -> E1 УПАТС.

При этом лишние петли в/из УПАТС не будут нарушать карму потоков )

[yulyanov]

схема работы сейчас у вас правильная - астер стоит транзитом
кроме вашего большого желания сломать рабочую схему еще какие то аргументы есть ?

Не транзитом. У меня на АТС приходят 2 потока от разных провайдеров и 60 линий меди. Часть номеров из потоков нуждаются в IVR. Взамен вышедшей из строя платы на АТС стоит asterisk, подключенный к АТС по E1. Маршрут звонка через IVR: E1 -> АТС -> Е1 -> Asterisk -> E1 -> ATC -> абонент. Думал, что возможно использовать asterisk только на время работы IVR и потом освобождать "лишний" канал дав через него на АТС команду на переадресацию.

[awsswa]

забейте на все эти платы - купите б\у циску 2801 с двух головой платой Е1 на nag.ru за 15000 руб и забудьте про все эти проблемы

[Zavr2008]

awsswa, лечишься от навязчивой зависимости считать доллар по 30р? )

ТС: Насколько много номеров в потоках, приходящих в IVR? в процентах. Просто если больше 50%, схема с транзитом через Астер с платой или через шлюз - актуальна. Да, медь по-прежнему через АТС - но всёж потоки наверное более активно используются..
А так, если в существующей схеме, сами петли снимаются в режиме QSIG, если на обоих концах активированы CT/CF.

[yulyanov]

В IVR идут практически все входящие звонки из потока. Поэтому есть вероятность того, что при текущей конфигурации 30 каналов на все петли не хватит в пике. Несмотря на малое количество звонков. Отсюда и был мой изначальный вопрос. Выбор сейчас или делать транзит, или всё таки освобождать петли и не держать их всю сессию. Увеличить емкость под петли возможности уже нет, все шкафы забиты и приходится рассчитывать только на существующие 3 платы E1 в АТС.
Просто освобождать петли после отработки IVR, лично мне кажется более предпочтительным вариантом. Даже без оглядки на стоимость других решений. Хотя это тоже немаловажно, станция уже не молодая и придумывать дорогие решения для временных решений не хочется.

[awsswa]

http://shop.nag.ru/catalog/02601.VoIP-i ... 801VoIP2E1
ну не 15000, а 21000

[yulyanov]

Нда. Режим QGIG оказался более опасной штукой чем я думал. Сам режим включился без проблем, но первый эксперимент по переадресации подвесил всю АТС Придётся ночью экспериментировать.