<div>Hi Eli,</div><div><br></div>I recently updated my installation, and now my old scripts for sending messages through event creation aren't working. Basically, FS is sending tens to hundreds of MESSAGEs a second after I send a SMS::SEND_MESSAGE event. This was working before your patch (and I'm sure a bunch of other patches), so I'm hoping you have some intuition as to what might be broken. I'll start tracking it down myself here in a little bit. <br>
<br>On Wednesday, November 21, 2012, Eli Burke wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Kurtis,<div><br></div><div>
We've been working with FreeSWITCH Consulting to address some issues with MESSAGE delivery. A couple of patches were committed on Nov 13 and Nov 14 to trunk and they may help with your problem. These patches affect the following behavior:</div>
<div>* MESSAGEs fed through the chatplan are correctly delivered or ignored by sofia</div><div>* when blocking=False, "Delivery-Failure" is replaced with "Nonblocking-Delivery: true"</div><div>* when blocking=True, "Delivery-Failure" is correctly set to true or false</div>
<div>* when blocking=True, "Delivery-Result-Code" is added to the event</div><div><br></div><div>Some background explanation: MESSAGEs are normally delivered in non-blocking mode, which means FreeSWITCH makes no attempt to determine if they were successfully received. There is a variable that can be set ("blocking: true") to force FreeSWITCH to wait for a response. You can already see this in action using the chat command in fs_cli-- it will report success or failure. </div>
<div><br></div><div>Unfortunately, "blocking" is not set by default. RIght now, the only way to get this behavior is to set it manually. For example, a chatplan rule to add the header to all inbound MESSAGEs:</div>
<div><div> <extension name="add_blocking" continue="true"></div><div> <condition></div><div> <action application="set" data="is_reg=${sofia_contact(${to_user}" inline="true"/></div>
<div> <action application="set" data="blocking=true"/> </div><div> </condition></div><div> </extension></div></div><div><br></div><div>There is a potential (and untested!) downside to forcing blocking to be always-on. The MESSAGE delivery queue is currently handled by a single thread. Even if all MESSAGE objects are delivered successfully to the local switch, some amount of latency may be introduced. In a real-world high-throughput scenario, it's possible that this could cause noticeable delays in the time it takes to delivery a MESSAGE, creating an ever-growing backlog.</div>
<div><br></div><div>The "is_reg" variable in the rule above could be used to short circuit failed attempts by shunting MESSAGEs to a database, or dropping them on the floor, but this would not necessarily fix things. The good news is that if a high-volume user can demonstrate that there is a problem, it's fixable within FreeSWITCH by moving to a multi-threaded message delivery queue.</div>
<div><br></div><div>-Eli</div><div><div><br><div><div><br></div><blockquote type="cite">On Nov 10, 2012, at 1:00 PM, <a>freeswitch-users-request@lists.freeswitch.org</a> wrote:<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div>
<span style="color:rgb(127,127,127)"><b>From: </b></span>Kurtis Heimerl <<a style="color:purple">kheimerl@cs.berkeley.edu</a>><br><span style="color:rgb(127,127,127)"><b>Subject: </b></span><b>[Freeswitch-users] Return code from ESL Message Sending</b><br>
<span style="color:rgb(127,127,127)"><b>Date: </b></span>November 9, 2012 11:42:19 PM EST<br><span style="color:rgb(127,127,127)"><b>To: </b></span>FreeSWITCH Users Help <<a style="color:purple">freeswitch-users@lists.freeswitch.org</a>><br>
<span style="color:rgb(127,127,127)"><b>Reply-To: </b></span>FreeSWITCH Users Help <<a style="color:purple">freeswitch-users@lists.freeswitch.org</a>><br><blockquote type="cite"></blockquote><font color="#007316"><br>
</font><blockquote type="cite">
</blockquote><font color="#007316"><br></font><blockquote type="cite">
</blockquote>Hello Freeswitch Users:<br><font color="#007316"><br></font>We're currently trying to get the return code from a MESSAGE we send using ESL. The closest we've found is this jira: <a href="http://jira.freeswitch.org/browse/FS-4453" style="color:purple" target="_blank">http://jira.freeswitch.org/browse/FS-4453</a> which seems to provide similar functionality for the chat command, but nothing for ESL.<br>
<font color="#007316"><br></font>Here's a pastebin of our current code: <a href="http://pastebin.freeswitch.org/20201" style="color:purple" target="_blank">http://pastebin.freeswitch.org/20201</a><br><font color="#007316"><br>
</font>The server we are hitting is returning a "415 Unsupported Content Type" (which is correct) and we're trying to discover that in freeswitch, instead of assuming the message was received correctly. Right now, we get that the recvEventTimed is returning None. This is all done on the a pull of FS from yesterday. <br>
<font color="#007316"><br></font>
<div style="font-family:Helvetica;font-size:medium;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
Any suggestions?</div></div><br></div></blockquote>
</blockquote></div><br></div></div></div></blockquote>