Asterisk 13.22.0 - функция SHELL() - не пропускает несколько переменных Asterisk

Question

Я прекратил попытки использовать system() для вызова скриптов BASH с параметрами из Asterisk 13.

Оказалось, под Asterisk 13.22.0 System() работает, но только если вы НЕ пытаетесь передать какие-либо параметры вызываемому скрипту.

Это работает и надежно вызывает скрипт:

same=>n,System(/bin/bash /usr/src/bash/setData.sh)

Однако, момент, когда вы делаете это:

same=>n,System(/bin/bash /usr/src/bash/setData.sh ${CHANNEL(accountcode)})

ты получаешь

WARNING[30982][C-00000238] app_system.c: Unable to execute '/usr/src`/bash/setData.sh'`

Поэтому я попытался использовать SHELL(), чтобы сделать то, что я пытался сделать с SYSTEM().

Это также не работает, так как SHELL(), по-видимому, может анализировать только ОДИН параметр звездочки в отправленной ему строке. Все остальные отправляются как пустые.

Если я сделаю это:

same=>n,Set(nothing=${SHELL(/usr/src/verdi/bash/verdiLogIncomingCall.sh NA 201807270838t49hgzs SIP/centra-out-00006d9a IN SIP/3027-00006db1 SIP/3027-00006db1 ApiLogIncomingCall.java 1)})

Скрипт видит при выполнении диалплана:

[root@acasterisk bash]# cat passed_param.txt
http://127.0.0.1/api/logIncomingCall?account_reference=NA&call_reference=201807270838t49hgzs&originating_channel_id=SIP/centra-out-00006d9a&direction=IN&requested_endpoint=SIP/3027-00006db1&caller_id=SIP/3027-00006db1&sourced_from=ApiLogIncomingCall.java&successfully_sent_to_server=1
[root@acasterisk bash]#

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

Если я использую это:

[macro-verdianswer]
exten=>s,1,NoOp(Entering Verdi answer macro - picked up by ${CHANNEL}) 
same=>n,NoOp(Source Channel: ${sourceChannel}) 
same=>n,NoOp(Answering Channel: ${CHANNEL}) 
same=>n,NoOp(Lodging CDR accountcode: ${curIncAccCode} as an incoming call from ${numbersource} with VerDi and answered by ${CHANNEL}...)
same=>n,Set(CHANNEL(accountcode)=${curIncAccCode})
same=>n,Set(nothing=${SHELL(/usr/src/verdi/bash/verdiLogIncomingCall.sh NA ${curIncAccCode} ${sourceChannel} IN ${CHANNEL} ${numbersource} ApiLogIncomingCall.java 1)})
same=>n,MacroExit()

давая это на exection:

-- SIP/3002-000070c2 answered SIP/centra-out-000070bf
    -- Executing [s@macro-verdianswer:1] NoOp("SIP/3002-000070c2", "Entering Verdi answer macro - picked up by SIP/3002-000070c2") in new stack
    -- Executing [s@macro-verdianswer:2] NoOp("SIP/3002-000070c2", "Source Channel: SIP/centra-out-000070bf") in new stack
    -- Executing [s@macro-verdianswer:3] NoOp("SIP/3002-000070c2", "Answering Channel: SIP/3002-000070c2") in new stack
    -- Executing [s@macro-verdianswer:4] NoOp("SIP/3002-000070c2", "Lodging CDR accountcode: 2018072709061hrriyu
    --  as an incoming call from xxxxxxxxxx with VerDi and answered by SIP/3002-000070c2...") in new stack
    -- Executing [s@macro-verdianswer:7] Set("SIP/3002-000070c2", "nothing=Incoming call NOT stored. Contact software support.
    -- ") in new stack

Например, мои переменные заполнены, и если я их не использую, они имеют значения.

В этой ситуации скрипт, вызываемый через SHELL(), видит:

[root@acasterisk bash]# cat passed_param.txt http://127.0.0.1/api/logIncomingCall?account_reference=NA&call_reference=2018072709061hrriyu&originating_channel_id=&direction=&requested_endpoint=&caller_id=&sourced_from=&successfully_sent_to_server=

Например SHELL(), очевидно, только когда-либо анализирует переменную FIRST Asterisk, переданную в него как строку, и никогда не анализирует последующие ссылки на переменные.

Кто-нибудь может подтвердить или предложить решение?

Мне отчаянно нужно иметь возможность выполнять внешние BASH-скрипты и как-то передавать им несколько параметров. Ничто, которое работало в 1.8 для этого, не работает в 13...

Спасибо!

Стефан

Answer 1

Вот мой связанный вопрос, который имеет точно такую ​​же причину и был решен точно таким же образом

Хорошо, это решено.

Оказалось, что проблема заключалась в том, что одна из переменных, которые я передавал в функцию набора номеров Asterisk 13.22.0 SHELL(), содержала символ перевода строки (\n или hex 0x0a).

Это также случилось с ПЕРВОЙ переменной, которую я передавал в вызов SHELL().

Таким образом, оказалось, что SHELL анализировал только один параметр - это было - но ПРИЧИНОЙ, что он не анализировал следующие параметры и не оценивал их для данных канала Asterisk, было наличие этого трейлинга \ n в первой канальной переменной Asterisk 13.22.0 I переходил в ОБОЛОЧКУ ().

Решение проблемы было простым, я просто удалил завершающий символ \ n из первой переменной канала Asterisk, переданной в SHELL () в Asterisk 13.22.0, и SHELL () начал работать, как и ожидалось.

Таким образом, существенное различие между Asterisk 1.8 и Asterisk 10 / 11 / 12 / 13 для приложений SYSTEM() и SHELL (), по-видимому, состоит в том, что если какие-либо ссылки на параметры оцениваются в строке параметров, передаваемой в SYSTEM() и SHELL (), при разборе и оценка указанных строк параметров SYSTEM() или SHELL () останавливается в точке, где встречается символ перевода строки.

Поэтому все, что мне нужно было сделать, - в моем скрипте, генерирующем UUID, который я передавал в качестве первого параметра - который нарушал SYSTEM() и SHELL() - должен был опустить завершающий \n.

Мой скрипт отправил данные из BASH следующим образом:

echo $uuid

Все, что мне нужно было сделать, это изменить эту строку на

echo -n $uuid

в сценарии BASH генератора UUID.

Как только это было сделано, приложение и план набора номера Asterisk 13.22.0 SYSTEM() и SHELL () начали работать и работать так же, как и в Asterisk 1.8.32.3, где код изначально разрабатывался.

Поэтому, работая с Asterisk 13 и более поздними версиями, имейте в виду любые переводы строки - особенно в проанализированных и оцененных ссылках на переменные канала - подразумеваемые в строке параметров, отправляемой в SYSTEM() или SHELL() - очевидно, они прекращают анализировать и оценивать переменные в тот момент, когда они встретить \ n или символ перевода строки.

Насколько я могу судить, это НЕ относится к версиям Asterisk версии 1.8.32.3 и ниже.

Надеюсь, это кому-нибудь поможет.