[Freeswitch-users] Return code from ESL Message Sending

Mon Nov 26 06:13:28 MSK 2012

Looks good to me, thanks for your time and effort William!

On Sunday, November 25, 2012, William King wrote:

> 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 <javascript:;>
>
> 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 <javascript:;> wrote:
> >>
> >>         *From: *Kurtis Heimerl <kheimerl at cs.berkeley.edu <javascript:;>
> >
> >>         *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 <javascript:;>>
> >>         *Reply-To: *FreeSWITCH Users Help
> >>         <freeswitch-users at lists.freeswitch.org <javascript:;>>
> >>
> >>
> >>         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 <javascript:;>
> > 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 <javascript:;>
> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> > http://www.freeswitch.org
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org <javascript:;>
> 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 <javascript:;>
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20121125/f777e2ab/attachment-0001.html 