<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><base href="x-msg://2520/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On 20/09/2012, at 3:59 PM, Noah Engelberth <<a href="mailto:Noah@directlinkcomputers.com">Noah@directlinkcomputers.com</a>> wrote:</div><blockquote type="cite"><div lang="EN-US" link="blue" vlink="purple" style="font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div class="WordSection1" style="page: WordSection1; "><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">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.<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">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. <span style="font-size: 11pt; "> </span></div></div></div></blockquote><br></div><div>What does your dialplan look like?</div><div><br></div><div>Are you using _.</div><div><br></div><div apple-content-edited="true"><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px; "><div>--</div><div>Cheers,</div><div><br></div><div>Matt Riddell</div><div>_______________________________________________</div><div><br></div><div><a href="http://www.venturevoip.com/news.php">http://www.venturevoip.com/news.php</a> (Daily Asterisk News)</div><div><a href="http://www.venturevoip.com/pabx_on_disk.php">http://www.venturevoip.com/pabx_on_disk.php</a> (PABX on a Disk)</div><div><a href="http://www.venturevoip.com/exchange.php">http://www.venturevoip.com/exchange.php</a> (Full ITSP Solution)</div><div><a href="http://www.venturevoip.com/cc.php">http://www.venturevoip.com/cc.php</a> (Call Centre Solutions)</div><div><br></div><div><br></div></span><br class="Apple-interchange-newline">
</div>
<br><div><br></div></body></html>