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
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com
Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org