On 20/09/2012, at 3:59 PM, Noah Engelberth
<[email protected]<mailto:[email protected]>> wrote:
I've been working on an interactive XMPP interface so users at my office can
interact with the timeclock and queues by XMPP (in addition to IVR menu, which
has been running just fine for quite a while before the XMPP interface). I'm
using sendtodialplan=yes to handling the incoming unsolicited messages, and
typically will have at least one point of interaction where Asterisk requests
authentication from the user and then waits with XMPP_RECEIVE for the response.
Asterisk then processes the reply and finishes out the "call" as expected, no
problems there. However, I'm seeing some behavior that I don't really expect
after the call finishes.
After my call finishes, sendtodialplan triggers again one time for each message
that was sent back (and caught by XMPP_RECEIVE) during the just completed call.
I've avoided unwanted extra processing by using XMPP_RECEIVE on a short
timeout to process incoming unsolicited messages, so the net effect of this
extra trigger is one or more "XMPP calls" that trip the 1 second timeout on
this XMPP_RECEIVE and then fall through and clean up. However, when I
initially started setting this up, my expectation was that sendtodialplan would
only trigger on messages that weren't solicited.
What does your dialplan look like?
Are you using _.
--
Cheers,
Matt Riddell
No pattern matching in this portion of the dialplan. A rough
approximation/sanitized psuedocode of what the code winds up as is...
[xmpp-incoming]
exten => s,1,Verbose(5,incoming)
same => n,Set(REPLY_TO=${MESSAGE(from)})
same => n,Set(REPLY_TO=${CUT(REPLY_TO,:,2)}) ; to cut off xmpp:
same => n,Set(REPLY_TO=${CUT(REPLY_TO,/,1)}) ; to cut off /resource
same => n,Set(MSG=${JABBER_RECEIVE(asterisk-xmpp,${REPLY_TO},1)
same => n,GotoIf($[${ISNULL(${MSG})}]?hangup,1:message,1)
exten => message,1,Verbose(5,process message)
same => n,Set(CMD=${CUT(MSG, ,1)})
same => n,Set(PIN=Retrieve PIN via ODBC function)
same => n,JabberSend(asterisk-xmpp,${REPLY_TO},Please authenticate)
same => n,Set(ENTERED_PIN=${JABBER_RECEIVE(asterisk-xmpp,${REPLY_TO},15)
same => n,GotoIf($[${ISNULL(${ENTERED_PIN})}]?timeout,1)
... check if the pin matches, kick them to invalid-user,1 if it doesn't, or
process their command if it does...
exten => hangup,1,Verbose(5,let the message fallthrough because using Hangup()
dorks up message receiving)
exten => timeout,1,Verbose(5,no input on authentication)
same => n,JabberSend(asterisk-xmpp,${REPLY_TO},Sorry, you timed out. If you
still want to execute your command, please try again.)
What I'm seeing 100% of the time is that as soon as the "call" from the initial
message falls through the end and gets hung up by autofallthrough, then a "new
call" executes for the incoming message from the prompted JABBER_RECEIVE in the
message extension (when I'm asking for authentication code. I have one
specific command that winds up prompting for input a second time, and both
prompted messages spawn off new calls, in order received, one after the other,
after the original call is cleaned up. By having the one second timeout on the
JABBER_RECEIVE in the s extension that pulls incoming unsolicited messages off
the stack, I keep the XMPP calls from stacking up and impacting performance,
but it just seems like odd behavior. Especially that the incoming message will
wait any amount of time and fire off exactly when the previous call ends.
Thank you,
Noah Engelberth
MetaLINK Technologies
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
