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.
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:
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.
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.
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.