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

Я отказался от попыток использовать 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()

давая это при исполнении:

-- 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(), по-видимому, только когда-либо анализирует ПЕРВУЮ переменную Asterisk, переданную в нее как строку, и никогда не анализирует последующие ссылки на переменные.

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

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

Спасибо!

Стефан


bash shell asterisk dialplan
person Stefan    schedule 27.07.2018    source источник

Ответы (1)


arrow_upward
0
arrow_downward

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

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

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

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

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

Решение проблемы было простым, я просто удалил завершающую \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 и ниже.

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

person Stefan    schedule 27.07.2018