asterisk users - Sep 2012 - XMPP sendtodialplan

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.

Obviously, it's not a huge cost and it's not breaking my implementation.
But I wonder if anyone might know of something I'm doing wrong that is
causing the "extra" sendtodialplan triggers.  Alternately, if this is
"expected" or "normal" behavior, I would like to propose
that the expected behavior be changed if possible so that sendtodialplan only
fires on truly unsolicited messages.


Configuration snippet:
xmpp.conf -
[asterisk]
type=client
*snip connection information*
status=available
sendtodialplan=yes
context=xmpp-incoming

General XMPP call flow:

1)      Client sends XMPP request to Asterisk

2)      Asterisk processes message, requests authentication and waits for PIN

3)      Client sends PIN via XMPP

4)      Asterisk receives PIN, validates, completes processing

5)      Asterisk sends process response to client (if applicable), and then lets
the call fall through

6)      Asterisk fires the sendtodialplan incoming logic for the message that
was sent in step 3

Thank you,

Noah Engelberth
MetaLINK Technologies

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20120920/63f5d81a/attachment.htm>

On 20/09/2012, at 3:59 PM, Noah Engelberth <Noah at
directlinkcomputers.com> 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
_______________________________________________

http://www.venturevoip.com/news.php (Daily Asterisk News)
http://www.venturevoip.com/pabx_on_disk.php (PABX on a Disk)
http://www.venturevoip.com/exchange.php (Full ITSP Solution)
http://www.venturevoip.com/cc.php (Call Centre Solutions)





-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20120920/0d0704a6/attachment.htm>