Звонит клиент. Как ему проиграть НЕСКОЛЬКО файлов при ответе

[fecyt]

Я ж говорю не разбирались.
В моем случае имя канала нужно было сохранять затем, чтобы потом сбриджевать, т.к. никак не узнать в канале Б о существовании канала А, если не передать переменной, а Вы его начали и в макрос вписывать.

С опцией G, если не будете дополнительно постобработку CDR делать или продолжать диалплан опцией g, то не беда.
Этот вариант скорее всего Вам и подойдет, опять же нужна будет переменная с именем канала А, чтобы абонента и оператора можно было соединить.

Я уже попробовал. Работает так, как надо.

[Felt]

Я ж говорю не разбирались.
В моем случае имя канала нужно было сохранять затем, чтобы потом сбриджевать, т.к. никак не узнать в канале Б о существовании канала А, если не передать переменной.

А чем это не вариант?

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

[incoming]
exten => _X.,1,Set(__chan=${CHANNEL})

В макросе в переменной chan первоначальный канал, который и потребуется для бриджевания. Можно было бы и переменной передать, но эффект-то один-в-один.

В chan я пробовал писать всевозможные варианты в разных форматах - эффект от нулевого, до зацикливания на самого себя. Но нужного эффекта нет.

[fecyt]

Ну идея есть, тесты нужны, можно было бы например попробовать определить канал, в макросе проиграть сообщение. Плюс добавить опцию А в dial и тоже проиграть сообщение. Но это по-моему не логично. Попробуйте с G.

[fecyt]

А чем не вариант Ваш? Дело в том, что __ используется для наследования переменной в случае, например, использования приложения Dial, а в случае с callfile это уже не сработает. Вы не передадите эту переменную и ее значение в созданный канал от callfile, если только она не будет глобальной.

[Felt]

Нее, при помощи __ я передал переменную в макрос при поднятии трубки оператором. И записал ее значение в call-файл.
Вы мне предлагаете передать ее в макрос не при помощи __, а при помощи параметра. Но в call-файл попадёт тоже самое значение переменной, зафиксируется в нем и породит еще один независимый звонок.

Не вижу разницы, которая принципиально поменяет содержимое call-файла при глобальной переменной и при помощи передачи значения и ARG1.

[Felt]

Ну идея есть, тесты нужны, можно было бы например попробовать определить канал, в макросе проиграть сообщение. Плюс добавить опцию А в dial и тоже проиграть сообщение. Но это по-моему не логично. Попробуйте с G.

В макросе-то я без проблем проиграю много сообщений оператору. Это самое простое.
Я не могу сообразить как зная канал висящего на линии клиента - проиграть ему, в этом загвоздка.

С G пробую сижу, пока не получается, но еще не все варианты исчерпал. Проиграть уже получается обоим сторонам любое количество файлов, остаётся малое - корректно сбриджевать (рабою над этим).
..
Всё, сбриджевалось. Нужно понять, что получилось!

P.S. Параметр M с G перестаёт работать, ну да ладно.

[fecyt]

А в данном случае как раз нужно __Set для канала производить до вызова Dial, тогда все получится.
А параметр М Вам и не нужен, у вас будет в новом контексте две ветки для звонящего и вызывающего, где Вы сможете проиграть обоим все что нужно, а потом сбриджевать.

[Felt]

Да, да, всё так как вы говорите!
Спасибо вам за наводку с G! Да и за другие попытки тоже спасибо и вам, и ded, и Repz.

[Felt]

Возник-таки побочный эффект: основной канал, который создался в момент входящего звонка оказался не у дел. Его статус NO ANSWER.
-- Executing [s@test22:10] Bridge("SIP/50-000001b2", "SIP/79333333333-000001b1,") in new stack
...
[Oct 27 20:40:11] WARNING[17459][C-000000a5]: pbx.c:6731 __ast_pbx_run: Don't know what to do with 'Bridge/SIP/9333333333-000001b1<ZOMBIE>'
[Oct 27 20:40:16] WARNING[17469][C-000000a6]: pbx.c:6731 __ast_pbx_run: Don't know what to do with 'SIP/9333333333-000001b1'

Когда клиент кладёт трубку, то разговор у оператора еще идёт около 10 секунд пока не заканчивается по некоему таймауту.

[Felt]

Я ж говорю не разбирались.
В моем случае имя канала нужно было сохранять затем, чтобы потом сбриджевать, т.к. никак не узнать в канале Б о существовании канала А, если не передать переменной, а Вы его начали и в макрос вписывать.

С опцией G, если не будете дополнительно постобработку CDR делать или продолжать диалплан опцией g, то не беда.
Этот вариант скорее всего Вам и подойдет, опять же нужна будет переменная с именем канала А, чтобы абонента и оператора можно было соединить.

Я уже попробовал. Работает так, как надо.

Решил в спокойной обстановке на выходных довести ваш пример до конца, когда никто не мешает и не торопит.
Вот в таком виде формально работает:

[incoming]
exten => provider,1,Set(__chan=${CHANNEL})
same => n,dial(SIP/50,,M(test2-dial-takeup))

[macro-test2-dial-takeup]
exten => s,1,noop(macros answer, ${chan})
same => n,System(echo "Channel: Local/100@test2a\nMaxRetries: 1\nRetryTime: 5\nWaitTime: 20\nContext: test2b\nExtension: 100\nPriority: 1\nSet: chan=${chan}\nArchive: yes\n" > /tmp/file.call)
same => n,System(mv /tmp/file.call /var/spool/asterisk/outgoing/)
same => n,Background(hello)
same => n,Background(hello)
same => n,Background(hello)
same => n,Background(hello)
same => n,Background(hello)
same => n,Bridge(${chan})

[test2a]
exten => _X.,1,NoOp(test2a ---- ${chan})
same => n,Answer()
same => n,Bridge(${chan})
same => n,Hangup()

[test2b]
exten => _X.,1,NoOp(test2b ---- ${chan})
same => n,Answer()
same => n,playback(tt-monkeys)
same => n,Hangup()

Только в 11 Астериске ругается на <ZOMBIE> каналы, которые образуются, а также даже после успешного разговора в CDR у всех разговоров billsec = 0. В общем некорректно работает.
А 13-й Астериск вообще напрочь вылетает после окончания звонка с сообщением "Ошибка сегментирования (сделан дамп памяти)"! Помогает только service asterisk restart.

Вариант с параметром G не подходит под LUA (проверил) - там нет понятия приоритетов (событие приходит в контекст и там ты с ним работаешь на языке программирования, никаких нумерованных строк, формально у всех команд приоритет 1).

Снова в тупике. Неужели в Астериске невозможно красиво воплотить простую идею - проиграть во входящий канал несколько файлов при поднятии трубки оператором?