Re: [Freeswitch-users] Return code from ESL Message Sending
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?
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@lists.freeswitch.org <javascript:_e({}, 'cvml', 'freeswitch-users-request@lists.freeswitch.org');> wrote:
*From: *Kurtis Heimerl <kheimerl@cs.berkeley.edu <javascript:_e({}, 'cvml', '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 <javascript:_e({}, 'cvml', 'freeswitch-users@lists.freeswitch.org');>> *Reply-To: *FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org <javascript:_e({}, 'cvml', '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?
_________________________________________________________________________ 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
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@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@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?
_________________________________________________________________________ Professional FreeSWITCH Consulting Services:consulting@freeswitch.orghttp://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Serverhttp://www.cudatel.com
Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://wiki.freeswitch.orghttp://www.cluecon.com
FreeSWITCH-users mailing listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
_________________________________________________________________________ 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
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org
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@lists.freeswitch.orgwrote:
*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?
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@quentustech.com 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@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?
_________________________________________________________________________ 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
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@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@lists.freeswitch.org <javascript:;> wrote:
*From: *Kurtis Heimerl <kheimerl@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@lists.freeswitch.org <javascript:;>> *Reply-To: *FreeSWITCH Users Help <freeswitch-users@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@freeswitch.org <javascript:;> 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 <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@freeswitch.org <javascript:;> 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 <javascript:;> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (5)
-
Abaci
-
Eli Burke
-
Kurtis Heimerl
-
Michael Collins
-
William King