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@lists.freeswitch.org wrote:

From: Kurtis Heimerl <kheimerl@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@lists.freeswitch.org>
Reply-To: FreeSWITCH Users Help <freeswitch-users@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?