Re: [asterisk-users] Passing parameter to Queue-called macro
Hi Marie
Thanks!
I was just worried about thread safety if I had to use a global variable, e.
g. it might be set to a value by one call (since I'm using the same global
for every incoming call to transfer the accountcode gotten from my HTTP
endpoint to the same macro, and there can be several calls simultaneously
all inserting HTTP-sourced values at more or less the same instant) and then
another call is in such a state that it then reads this call's data - and
never reads its logical "own" data. The classic concurrently accessed single
variable issue.
Anyway, I've managed to solve this by declaring a variable in the main
dialplan as inheritable and storing my back-office relevant GUID in there,
then referencing that variable without the pre-prended _ in the macro:
E. g.
[verdianswer]
exten=>s,n,NoOp(Lodging CDR accountcode: ${curIncAccCode} as an incoming
call from ${numbersource} with VerDi and answered by ${MEMBERINTERFACE}...)
exten=>s,n,MacroExit
[telkomin]
.
.
.
same=>n,Set(curlResult=${SHELL(/usr/src/verdi/bash/verdiIncGetUUID.sh)})
same=>n,Set(_curIncAccCode=${curlResult})
same=>n,Queue(stefantest,trhc,,,60,,verdianswer)
The above works just fine for doing what I want to do, e. g. pass a
parameter from an Asterisk dialplan context into a queue-triggered "agent
just answered in the queue" Asterisk macro.
Thanks for the reply!
Kind regards
Stefan
-Original Message-
From: Marie Fischer
Sent: Thursday, 10 May 2018 15:08
To: viljo...@verishare.co.za; Asterisk Users Mailing List - Non-Commercial
Discussion
Subject: Re: [asterisk-users] Passing parameter to Queue-called macro
Hi,
maybe I am overlooking something, but channel variables should be thread
safe, shouldn't they?
I am using the following (sorry, in ael):
macro dial-queue (number) {
Set(_ORIG_UNIQUEID=${UNIQUEID});
Queue(${number},rCt,,,${timeout},,set-dst-agent);
..
}
// the "context macro-..." things is an ael-specific workaround to get
transfer working (macro sets context to app_queue_gosub_virtual_context)
context macro-set-dst-agent {
s => {
Noop(${ORIG_UNIQUEID});
&add-current-call-agent(${ORIG_UNIQUEID},${MEMBERNAME});
}
}
macro add-current-call-agent (id,num) {
Set(ODBC_ADD_CURRENT_AGENT(${id},${num})=1);
return;
}
--
marie
On 08.05.2018, at 16:16, Stefan Viljoen wrote:
> Hi all
>
> I need to pass a parameter in a thread-safe manner to the Queue pickup
> macro. This is to know when (and who) picked up an incoming call to a
> queue and log that to my back-office system with a CURL to a HTTP
endpoint.
>
> However, the Queue application does not appear to allow passing of
> parameters to the called queue pickup macro.
>
> E. g. non-working code is:
>
> [queuetest]
> timeout = 60
> retry = 2
> member=>SIP/testnum
>
> [macro-verdianswer]
> exten=>s,1,NoOp(Entering Verdi answer macro)
> exten=>s,n,NoOp(Value: ${ARG1})
> exten=>s,n,MacroExit
>
> [incomingcontext]
>
> exten=>tstqueue,1,NoOp(Incoming call for VerDi)
> same=>n,Set(curlResult=${SHELL(/usr/src/verdi/bash/verdiIncGetUUID.sh)
> })
> same=>n,Set(curlResultLength=${LEN(${curlResult})})
> same=>n,NoOp(Curl result for incoming call UUID from VerDi:
> ${curlResult})
> same=>n,Set(CDR(accountcode)=${curlResult})
> same=>n,Set(curIncAccCode=${curlResult},g)
> same=>n,Macro(VCRECORD,stefantestEXT${CALLERID(num)}ACC${CDR(accountco
> de)},$
> {EXTEN})
> same=>n,Queue(queuetest,trhc,,,60,,verdianswer(${curIncAccCode}))
> same=>n,Hangup()
>
> This results, when executed, in:
>
> [May 8 15:14:50] WARNING[20921]: app_macro.c:309 _macro_exec: No such
> context 'macro-verdianswer(2018050815141huzzu4
> ' for macro 'verdianswer(2018050815141huzzu4
>
> How can one pass a paramter into the macro called by the Asterisk
> queue application on queue pickup?
>
> Alternatively, how can a global variable or ASTDB entry be made thread
> safe to do the same?
>
> Thank you
>
> 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? 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
--
_
-- 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] 7965G sporadically not able to make calls via chan_sip
Hi, the tcpdump starts with a pretty standard INVITE sequence: 10.0.0.121 -- INVITE --> 10.0.0.3 10.0.0.121 <-- 401 Unauthorized -- 10.0.0.3 // asterisk gives nonce in WWW-Authenticate: header 10.0.0.121 -- ACK --> 10.0.0.3 After that, normally you would see a new INVITE from the phone with Authorization: header, but in your case the phone does not send this - although it is clearly reachable as indicated by the SIP OPTIONS dialogue. In the Asterisk SIP debug, I see only the packets sent by Asterisk to the phone, but not the phone's responses. Did you do just 'sip set debug on' or something different? Can you provide the same logs for a successful call? Do incoming calls to the phone work when this happens? -- BR, marie On 02.05.2018, at 20:23, John Kinsner wrote: > sometime during the past few upgrades on asterisk 13, my Cisco 7965G phones > are sporadically not able to make calls. after a few seconds, they just play > a fast-busy tone. I tried upgrading the 7965G OS from their original > (working for years) 9.4.2SR1 to 9.4.2SR3 and the behavior did not change. > > they are talking via chan_sip on asterisk 13.19.0. I cannot determine the > sporadic part, sometimes the call goes through fine with no configuration > changes or restarts/reboots on either end. > > sip debug from asterisk: > https://pastebin.com/Mmz9JsAP > > tcpdump from pbx: > https://pastebin.com/jRT9QJwq > > sip.conf: > [121] > type=friend > ;qualify=yes > ;qualifyfreq=300 > host=dynamic > context=extensions > secret=MySecret > nat=no > callerid="MBR" <121> > > > can anyone give me clues to troubleshoot? > > > > > > -- > _ > -- 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 -- _ -- 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] SIP Codec negotiation
On Thu, May 10, 2018 at 11:44:14AM -0700, Steve Edwards wrote: > I receive an INVITE/SDP containing: > > m=audio 11310 RTP/AVP 3 0 101 > > which I interpret as gsm, ulaw, rfc2833. > > and I reply with an OK/SDP containing: > > m=audio 15884 RTP/AVP 0 3 101 > > which I interpret as ulaw, gsm, rfc2833. > > How can I tell which codec was actually used for the call? AFAIK this is undetermined. The callee can send either ulaw or gsm, unless the caller wants to narrow it down to 1 codec, see https://tools.ietf.org/html/rfc4317#section-2.2 Most of the time the callee will pick the first (so in this case ulaw). But there are media gateways out there that choose g711[au] above "more complex" codecs regardless order in SDP. My prefer PSTN provider will always prefer alaw if offered since that will prevent transcoding on their side if the call goes to ISDN/POTS, but AMR if the call goes to VoLTE. -- _ -- 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
[asterisk-users] SIP Codec negotiation
I receive an INVITE/SDP containing: m=audio 11310 RTP/AVP 3 0 101 which I interpret as gsm, ulaw, rfc2833. and I reply with an OK/SDP containing: m=audio 15884 RTP/AVP 0 3 101 which I interpret as ulaw, gsm, rfc2833. How can I tell which codec was actually used for the call? -- Thanks in advance, - Steve Edwards sedwa...@sedwards.com Voice: +1-760-468-3867 PST https://www.linkedin.com/in/steve-edwards-4244281 -- _ -- 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] Passing parameter to Queue-called macro
Hi,
maybe I am overlooking something, but channel variables should be thread safe,
shouldn't they?
I am using the following (sorry, in ael):
macro dial-queue (number) {
Set(_ORIG_UNIQUEID=${UNIQUEID});
Queue(${number},rCt,,,${timeout},,set-dst-agent);
..
}
// the "context macro-..." things is an ael-specific workaround to get transfer
working (macro sets context to app_queue_gosub_virtual_context)
context macro-set-dst-agent {
s => {
Noop(${ORIG_UNIQUEID});
&add-current-call-agent(${ORIG_UNIQUEID},${MEMBERNAME});
}
}
macro add-current-call-agent (id,num) {
Set(ODBC_ADD_CURRENT_AGENT(${id},${num})=1);
return;
}
--
marie
On 08.05.2018, at 16:16, Stefan Viljoen wrote:
> Hi all
>
> I need to pass a parameter in a thread-safe manner to the Queue pickup
> macro. This is to know when (and who) picked up an incoming call to a queue
> and log that to my back-office system with a CURL to a HTTP endpoint.
>
> However, the Queue application does not appear to allow passing of
> parameters to the called queue pickup macro.
>
> E. g. non-working code is:
>
> [queuetest]
> timeout = 60
> retry = 2
> member=>SIP/testnum
>
> [macro-verdianswer]
> exten=>s,1,NoOp(Entering Verdi answer macro)
> exten=>s,n,NoOp(Value: ${ARG1})
> exten=>s,n,MacroExit
>
> [incomingcontext]
>
> exten=>tstqueue,1,NoOp(Incoming call for VerDi)
> same=>n,Set(curlResult=${SHELL(/usr/src/verdi/bash/verdiIncGetUUID.sh)})
> same=>n,Set(curlResultLength=${LEN(${curlResult})})
> same=>n,NoOp(Curl result for incoming call UUID from VerDi: ${curlResult})
> same=>n,Set(CDR(accountcode)=${curlResult})
> same=>n,Set(curIncAccCode=${curlResult},g)
> same=>n,Macro(VCRECORD,stefantestEXT${CALLERID(num)}ACC${CDR(accountcode)},$
> {EXTEN})
> same=>n,Queue(queuetest,trhc,,,60,,verdianswer(${curIncAccCode}))
> same=>n,Hangup()
>
> This results, when executed, in:
>
> [May 8 15:14:50] WARNING[20921]: app_macro.c:309 _macro_exec: No such
> context 'macro-verdianswer(2018050815141huzzu4
> ' for macro 'verdianswer(2018050815141huzzu4
>
> How can one pass a paramter into the macro called by the Asterisk queue
> application on queue pickup?
>
> Alternatively, how can a global variable or ASTDB entry be made thread safe
> to do the same?
>
> Thank you
>
> 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? 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
--
_
-- 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
