[Freeswitch-users] Return code from ESL Message Sending

[Michael Collins]

Please do! If you have any questions about using the wiki please let me
know. Also, I will be doing a wiki tutorial during tomorrow's weekly
conference call.

-MC

On Tue, Nov 20, 2012 at 1:26 PM, Abaci <abaci64 at gmail.com> wrote:

>  Would you mind documenting these option on the wiki (
> http://wiki.freeswitch.org/wiki/Mod_sms) so that people know about it.
> Thanks
>
> On 11/20/2012 1:43 PM, 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.orghttp://www.freeswitchsolutions.com
>
> FreeSWITCH-powered IP PBX: The CudaTel Communication Server
>
> Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://wiki.freeswitch.orghttp://www.cluecon.com
>
> FreeSWITCH-users mailing listFreeSWITCH-users at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.freeswitch.org
>
>
>
> _________________________________________________________________________
> 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
>
>


-- 
Michael S Collins
Twitter: @mercutioviz
http://www.FreeSWITCH.org
http://www.ClueCon.com
http://www.OSTAG.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20121120/dd17dab5/attachment-0001.html