Re: [asterisk-users] SHELL() function Asterisk 13 - can only accept one paramter in string?

2018-07-30 Thread Stefan Viljoen
Hi Ludovic

 

Thank you very much for replying!

 

Ok, I’ll give up on the dialplan apps then in total and try out AGI.

 

Thanks again,

 



 

From: Ludovic Gasc  
Sent: Friday, 27 July 2018 13:37
To: viljo...@verishare.co.za; Asterisk Users Mailing List - Non-Commercial 
Discussion 
Subject: Re: [asterisk-users] SHELL() function Asterisk 13 - can only accept 
one paramter in string?

 

Hi Stefan,

 

You might use AGI instead of SHELL, it's better because you can interact with 
the call via AGI and you don't have a risk of remote execution you might have 
if you add arguments that come from outside, for example via a SIP header.

 

Regards.


--

Ludovic Gasc (GMLudo)

 

 

Le ven. 27 juil. 2018 à 09:37, Stefan Viljoen mailto:viljo...@verishare.co.za> > a écrit :

Hi all

This is a followup on my post "Asterisk 13 - system() dialplan app cannot call 
bash scripts" from yesterday

I've given up trying to use system() to call BASH scripts with parameters from 
Asterisk 13. 

Turned out under Asterisk 13.22.0 System() DOES work, but only if you do NOT 
attempt to pass any parameters to the called script.

This works, and reliably calls the script:

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

However, the moment you do this:

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

you get

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

I therefore tried to use SHELL() to do what I was trying to do with SYSTEM().

This also does not work, as SHELL() apparently can only ever parse ONE asterisk 
parameter in the string sent to it. All the rest are sent as blank.

If I do this:

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

The script sees, on dialplan execution:

[root@acasterisk bash]# cat passed_param.txt
http://127.0.0.1/api/logIncomingCall?account_reference=NA 

 
_reference=201807270838t49hgzs_channel_id=SIP/centra-out-6d9a=IN_endpoint=SIP/3027-6db1_id=SIP/3027-6db1_from=ApiLogIncomingCall.java_sent_to_server=1
[root@acasterisk bash]#

E. g. all params present - because no variable references need to be parsed.

If I use this:

[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()

giving this on exection:

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

e. g. my variables ARE populated, and if I NoOp them, they have values.

In this situation, the script called via SHELL() sees:

[root@acasterisk bash]# cat passed_param.txt
http://127.0.0.1/api/logIncomingCall?account_reference=NA 

 
_reference=2018072709061hrriyu_channel_id==_endpoint=_id=_from=_sent_to_server=

E. g. SHELL() apparently only ever parses the FIRST Asterisk variable passed 
into it as a string, and never parses subsequent variable references.

Can anybody confirm or suggest a solution?

I desperately need to be able to execute external BASH scripts and pass 
multiple parameters to them, somehow. Nothing that worked in 1.8 for this works 
in 13...

Thanks!

Stefan


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? 

Re: [asterisk-users] dialplan reload not showing debug info even with debug on (ast 15.5)

2018-07-30 Thread Richard Mudgett
On Sun, Jul 29, 2018 at 10:04 AM, Jonathan H  wrote:

> OK, many thanks for that. Not sure I see the point of the change, but
> at least I can get the info back by changing
>
> console => notice,warning,error
> to
> console => notice,warning,error,debug
>
> That said, dialplan reload seems to show significantly fewer items
> than before. I've got loads of extensions, and it does indeed seem to
> reload them all, but only shows about 1/4 of them in the console when
> doing dialplan reload. Hmmm...
>
> Incidentally, just while I'm here, is there a particular reason that
> debug can only every be pushed higher when connecting to the console?
> it's always been the case since I started using Asterisk 3 years ago
> so I guess there's a reason, and I never questioned it before. I'm
> just curious!
> For example:
>
>
> asterisk -rvddd
> Core debug was 2 and is now 3.
>
> asterisk -rv
> Core debug was 3 and is now 4.
>
> asterisk -rvdd
> Core debug is still 4.
>
> asterisk -rvd
> Core debug is still 4.
>
> But it always respects "core set debug" in whichever direction of
> verbosity is required.
>

When you connect to a remote asterisk with the -r option, there are a couple
commands automatically sent every time.  These automatic commands tell
the remote asterisk what verbose and debug level you passed on the
command line.

core set verbose at least X silent
core set debug atleast X

That is why the debug level does not go down.  Another thing is that the
debug level
is global to the system.  Thus if you set the level in one connection it
affects all
connections including future ones.  The verbose level is per connection.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] asterisk-users Digest, Vol 167, Issue 17

2018-07-30 Thread Stefan Viljoen
Hi Daniel

Thanks for the reply!

Yes, turns out it was all my fault, I had a line feed character (0x0a a.k.a 
printf("\n")) in one of the Asterisk channel variables passed via system() / 
shell() to my target script.

It seems 13.22.0 (I'm using the same version as you) reacts to a line feed in 
the parameter string by not processing or parsing the string any further one 
the line feed is encountered.

I removed the line feed (by using "echo -n" instead of just "echo" in a related 
BASH script that was providing input to Asterisk also via SHELL) and the 
problem disappeared and system() (and shell() itself ) started working 
correctly.

So, the moral is just keep the data clean that is fed through SYSTEM() and 
SHELL() from having any line-feeds in them.

On Asterisk 1.8 (my previous version) line-feeds in an Asterisk channel 
variable dereferenced in a SYSTEM() or SHELL() call did NOT stop parsing of the 
rest of the string - so apparently a relevant difference between the two 
versions there.

Kind regards,
---
Message: 2
Date: Fri, 27 Jul 2018 10:24:56 +0200
From: Administrator TOOTAI 
To: asterisk-users@lists.digium.com
Subject: Re: [asterisk-users] SHELL() function Asterisk 13 - can only
accept one paramter in string?
Message-ID: <008fecea-e2c0-9230-7cb4-cd1b6990c...@tootai.net>
Content-Type: text/plain; charset=utf-8; format=flowed

Le 27/07/2018 à 09:36, Stefan Viljoen a écrit :
> Hi all
> 
> This is a followup on my post "Asterisk 13 - system() dialplan app 
> cannot call bash scripts" from yesterday
> 
> I've given up trying to use system() to call BASH scripts with parameters 
> from Asterisk 13.
> 
> Turned out under Asterisk 13.22.0 System() DOES work, but only if you do NOT 
> attempt to pass any parameters to the called script.

[...]

*CLI> core show version
Asterisk 13.22.0 built by root @ pabx on a x86_64 running Linux on
2018-07-14 13:36:49 UTC

This works for us

same = n,system(/bin/echo "To: ${CALLED_CHANNEL}   From: ${ORI_CALL}" | 
/usr/bin/mail -s "TOOTAiAudio - Congestion Gateway ${CONGESTION_GW} used" 
${AUDIO_ADMIN})

--
Daniel


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users