[Freeswitch-users] Return code from ESL Message Sending

[William King]

Issue found and replicated, and patch to be pushed momentarily.

The problem is that FS has two methods for sending SMS messages,
blocking and non-blocking. By default endpoints send in blocking form,
and everything else defaults to non-blocking. In a recent patch the
non-blocking form was missed when confirming that the sms was sent
successfully, thus causing the message to be queued up again as soon as
it's sent.

It appears to have only effected sms messages that were queued in a
fully processed form(skipping the chatplan).

William King
Senior Engineer
Quentus Technologies, INC
1037 NE 65th St Suite 273
Seattle, WA 98115
Main:   (877) 211-9337
Office: (206) 388-4772
Cell:   (253) 686-5518
william.king at quentustech.com

On 11/24/2012 10:00 PM, Kurtis Heimerl wrote:
> Hi Eli,
> 
> 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. 
> 
> On Wednesday, November 21, 2012, Eli Burke wrote:
> 
>     Kurtis,
> 
>     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:
>     * MESSAGEs fed through the chatplan are correctly delivered or
>     ignored by sofia
>     * when blocking=False, "Delivery-Failure" is replaced with
>     "Nonblocking-Delivery: true"
>     * when blocking=True, "Delivery-Failure" is correctly set to true or
>     false
>     * when blocking=True, "Delivery-Result-Code" is added to the event
> 
>     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. 
> 
>     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:
>         <extension name="add_blocking" continue="true">
>           <condition>
>               <action application="set"
>     data="is_reg=${sofia_contact(${to_user}" inline="true"/>
>               <action application="set" data="blocking=true"/>   
>           </condition>
>         </extension>
> 
>     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.
> 
>     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.
> 
>     -Eli
> 
> 
>>     On Nov 10, 2012, at 1:00 PM,
>>     freeswitch-users-request at lists.freeswitch.org wrote:
>>
>>         *From: *Kurtis Heimerl <kheimerl at cs.berkeley.edu>
>>         *Subject: **[Freeswitch-users] Return code from ESL Message
>>         Sending*
>>         *Date: *November 9, 2012 11:42:19 PM EST
>>         *To: *FreeSWITCH Users Help
>>         <freeswitch-users at lists.freeswitch.org>
>>         *Reply-To: *FreeSWITCH Users Help
>>         <freeswitch-users at lists.freeswitch.org>
>>
>>
>>         Hello Freeswitch Users:
>>
>>         We're currently trying to get the return code from a MESSAGE
>>         we send using ESL. The closest we've found is this
>>         jira: http://jira.freeswitch.org/browse/FS-4453 which seems to
>>         provide similar functionality for the chat command, but
>>         nothing for ESL.
>>
>>         Here's a pastebin of our current
>>         code: http://pastebin.freeswitch.org/20201
>>
>>         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. 
>>
>>         Any suggestions?
>>
> 
> 
> 
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
> 
> 
> 
> 
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
> 
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org