RTP flows and device doing a local redirection
Hi mates, We are encountering a problem with some of our customers in the following situation: * we are running Freeswitch with a public IP address, detecting far-end nat traversal when needed (customers behind NAT) * our customers interconnects their IPBXes to our FS platform (we do only SIP trunking with FS) * if the customer has its IPBX behind a NAT and sets a local redirect, there's no sound (and I completely understand why, I'm just trying to find a solution, if any...) So there are two distinct calls: PSTN_X <===> FS <===> customer1 IPBX customer1 IPBX <===> FS <===> PSTN_Y (redirection) When PSTN_Y answers the call, FS sends 200 OK w/ SDP to customer1 IPBX. The IPBX then sends an empty RTP packet, I reckon to allow the remote platform (FS in this case) to be able to detect the IP/port couple where to send RTP packets. The problem I have is that on the 'caller' side, this single empty RTP packet is sent by the IPBX before sending the 200 OK (like, a few ms before) and then FS seems to not be ready for it and reply ICMP unreachable. To make this whole stuff almost-work, I've set 'rtp_auto_adjust_threshold' to 1, otherwise FS will wait for far more than 1 RTP packet to detect NAT. My idea is that the IPBX should send the 200 OK first and right after this empty RTP packet. The problem is I'm encountering the issue with two different constructors (on one of them we ended using STUN, but the other one has a terrible STUN implementation, hence I'm really looking for a solution). I know it's tricky (SIP, NAT, redirection and so on) but what do you think about this use case? Would you know a way to solve this trouble? If you have any clue please share! Thanks in advance Florent
then FS seems to not be ready for it and reply ICMP unreachable.
This sounds odd. ICMP unreachable will be sent by the OS/firewall not FS. It means nothing is listening on that UDP port (or it's blocked). What's odd is the SDP FS sends in its INVITE packet will contain the IP and port it's using. It finds that port by creating a socket using a random port then checking what it's using. So before the INVITE is even sent the port is open, so you shouldn't see ICMP unreachable from the OS. Are they sending to the exact same IP and port you send in the SDP? Are you running any stateful firewalls that might not have opened the port for the RTP stream? On 25 September 2014 14:59, Florent Krieg <flokrrr@gmail.com> wrote:
Hi mates,
We are encountering a problem with some of our customers in the following situation: * we are running Freeswitch with a public IP address, detecting far-end nat traversal when needed (customers behind NAT) * our customers interconnects their IPBXes to our FS platform (we do only SIP trunking with FS) * if the customer has its IPBX behind a NAT and sets a local redirect, there's no sound (and I completely understand why, I'm just trying to find a solution, if any...)
So there are two distinct calls: PSTN_X <===> FS <===> customer1 IPBX customer1 IPBX <===> FS <===> PSTN_Y (redirection)
When PSTN_Y answers the call, FS sends 200 OK w/ SDP to customer1 IPBX. The IPBX then sends an empty RTP packet, I reckon to allow the remote platform (FS in this case) to be able to detect the IP/port couple where to send RTP packets. The problem I have is that on the 'caller' side, this single empty RTP packet is sent by the IPBX before sending the 200 OK (like, a few ms before) and then FS seems to not be ready for it and reply ICMP unreachable.
To make this whole stuff almost-work, I've set 'rtp_auto_adjust_threshold' to 1, otherwise FS will wait for far more than 1 RTP packet to detect NAT.
My idea is that the IPBX should send the 200 OK first and right after this empty RTP packet. The problem is I'm encountering the issue with two different constructors (on one of them we ended using STUN, but the other one has a terrible STUN implementation, hence I'm really looking for a solution).
I know it's tricky (SIP, NAT, redirection and so on) but what do you think about this use case? Would you know a way to solve this trouble? If you have any clue please share!
Thanks in advance Florent
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.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
Hi Steven, Thanks for the reply! Here's the firewall policy (iptables, the FS service is hosted on a centos6 server): -A INPUT -p udp -m udp --dport 20000:40000 -j ACCEPT The port annonced by FS and actually used was in this range (34546). Hence, I doubt the port s blocked. There is still the possibility of the port not being listening. This is comforting that you say it should be listening on it right before the INVITE, but it is a bit weird I'm experiencing such a behaviour... Steven, there are a lot of public IPs in my capture (among them some of customers and I don't want to obfuscate it so I won't post it here), but if you'd like I can send it to you by email so that you can have a look as well? Thanks Florent 2014-09-25 17:06 GMT+02:00 Steven Ayre <steveayre@gmail.com>:
then FS seems to not be ready for it and reply ICMP unreachable.
This sounds odd. ICMP unreachable will be sent by the OS/firewall not FS. It means nothing is listening on that UDP port (or it's blocked). What's odd is the SDP FS sends in its INVITE packet will contain the IP and port it's using. It finds that port by creating a socket using a random port then checking what it's using. So before the INVITE is even sent the port is open, so you shouldn't see ICMP unreachable from the OS.
Are they sending to the exact same IP and port you send in the SDP? Are you running any stateful firewalls that might not have opened the port for the RTP stream?
On 25 September 2014 14:59, Florent Krieg <flokrrr@gmail.com> wrote:
Hi mates,
We are encountering a problem with some of our customers in the following situation: * we are running Freeswitch with a public IP address, detecting far-end nat traversal when needed (customers behind NAT) * our customers interconnects their IPBXes to our FS platform (we do only SIP trunking with FS) * if the customer has its IPBX behind a NAT and sets a local redirect, there's no sound (and I completely understand why, I'm just trying to find a solution, if any...)
So there are two distinct calls: PSTN_X <===> FS <===> customer1 IPBX customer1 IPBX <===> FS <===> PSTN_Y (redirection)
When PSTN_Y answers the call, FS sends 200 OK w/ SDP to customer1 IPBX. The IPBX then sends an empty RTP packet, I reckon to allow the remote platform (FS in this case) to be able to detect the IP/port couple where to send RTP packets. The problem I have is that on the 'caller' side, this single empty RTP packet is sent by the IPBX before sending the 200 OK (like, a few ms before) and then FS seems to not be ready for it and reply ICMP unreachable.
To make this whole stuff almost-work, I've set 'rtp_auto_adjust_threshold' to 1, otherwise FS will wait for far more than 1 RTP packet to detect NAT.
My idea is that the IPBX should send the 200 OK first and right after this empty RTP packet. The problem is I'm encountering the issue with two different constructors (on one of them we ended using STUN, but the other one has a terrible STUN implementation, hence I'm really looking for a solution).
I know it's tricky (SIP, NAT, redirection and so on) but what do you think about this use case? Would you know a way to solve this trouble? If you have any clue please share!
Thanks in advance Florent
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.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
Keep in mind that FreeSWITCH does not use the 20K to 40K range for RTP by default. It used 16384:32768 so your iptables rules there will probably cause a problem when FS tries to do media in the lower part of the range On 9/25/14 10:54 AM, "Florent Krieg" <flokrrr@gmail.com> wrote:
Hi Steven,
Thanks for the reply!
Here's the firewall policy (iptables, the FS service is hosted on a centos6 server): -A INPUT -p udp -m udp --dport 20000:40000 -j ACCEPT The port annonced by FS and actually used was in this range (34546). Hence, I doubt the port s blocked.
There is still the possibility of the port not being listening. This is comforting that you say it should be listening on it right before the INVITE, but it is a bit weird I'm experiencing such a behaviour...
Steven, there are a lot of public IPs in my capture (among them some of customers and I don't want to obfuscate it so I won't post it here), but if you'd like I can send it to you by email so that you can have a look as well?
Thanks Florent
2014-09-25 17:06 GMT+02:00 Steven Ayre <steveayre@gmail.com>:
then FS seems to not be ready for it and reply ICMP unreachable.
This sounds odd. ICMP unreachable will be sent by the OS/firewall not FS. It means nothing is listening on that UDP port (or it's blocked). What's odd is the SDP FS sends in its INVITE packet will contain the IP and port it's using. It finds that port by creating a socket using a random port then checking what it's using. So before the INVITE is even sent the port is open, so you shouldn't see ICMP unreachable from the OS.
Are they sending to the exact same IP and port you send in the SDP? Are you running any stateful firewalls that might not have opened the port for the RTP stream?
On 25 September 2014 14:59, Florent Krieg <flokrrr@gmail.com> wrote:
Hi mates,
We are encountering a problem with some of our customers in the following situation: * we are running Freeswitch with a public IP address, detecting far-end nat traversal when needed (customers behind NAT) * our customers interconnects their IPBXes to our FS platform (we do only SIP trunking with FS) * if the customer has its IPBX behind a NAT and sets a local redirect, there's no sound (and I completely understand why, I'm just trying to find a solution, if any...)
So there are two distinct calls: PSTN_X <===> FS <===> customer1 IPBX customer1 IPBX <===> FS <===> PSTN_Y (redirection)
When PSTN_Y answers the call, FS sends 200 OK w/ SDP to customer1 IPBX. The IPBX then sends an empty RTP packet, I reckon to allow the remote platform (FS in this case) to be able to detect the IP/port couple where to send RTP packets. The problem I have is that on the 'caller' side, this single empty RTP packet is sent by the IPBX before sending the 200 OK (like, a few ms before) and then FS seems to not be ready for it and reply ICMP unreachable.
To make this whole stuff almost-work, I've set 'rtp_auto_adjust_threshold' to 1, otherwise FS will wait for far more than 1 RTP packet to detect NAT.
My idea is that the IPBX should send the 200 OK first and right after this empty RTP packet. The problem is I'm encountering the issue with two different constructors (on one of them we ended using STUN, but the other one has a terrible STUN implementation, hence I'm really looking for a solution).
I know it's tricky (SIP, NAT, redirection and so on) but what do you think about this use case? Would you know a way to solve this trouble? If you have any clue please share!
Thanks in advance Florent
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.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
-- Ken http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org irc.freenode.net #freeswitch Twitter: @FreeSWITCH
Hi Ken, Thanks for pointing this out. I guess the value you have mentioned are overwritten by the following settings in switch.conf.xml (which I have set)? <!-- RTP port range --> <param name="rtp-start-port" value="20000"/> <param name="rtp-end-port" value="40000"/> Florent 2014-09-25 19:38 GMT+02:00 Ken Rice <krice@freeswitch.org>:
Keep in mind that FreeSWITCH does not use the 20K to 40K range for RTP by default. It used 16384:32768 so your iptables rules there will probably cause a problem when FS tries to do media in the lower part of the range
On 9/25/14 10:54 AM, "Florent Krieg" <flokrrr@gmail.com> wrote:
Hi Steven,
Thanks for the reply!
Here's the firewall policy (iptables, the FS service is hosted on a centos6 server): -A INPUT -p udp -m udp --dport 20000:40000 -j ACCEPT The port annonced by FS and actually used was in this range (34546). Hence, I doubt the port s blocked.
There is still the possibility of the port not being listening. This is comforting that you say it should be listening on it right before the INVITE, but it is a bit weird I'm experiencing such a behaviour...
Steven, there are a lot of public IPs in my capture (among them some of customers and I don't want to obfuscate it so I won't post it here), but if you'd like I can send it to you by email so that you can have a look as well?
Thanks Florent
2014-09-25 17:06 GMT+02:00 Steven Ayre <steveayre@gmail.com>:
then FS seems to not be ready for it and reply ICMP unreachable.
This sounds odd. ICMP unreachable will be sent by the OS/firewall not FS. It means nothing is listening on that UDP port (or it's blocked). What's odd is the SDP FS sends in its INVITE packet will contain the IP and port it's using. It finds that port by creating a socket using a random port then checking what it's using. So before the INVITE is even sent the port is open, so you shouldn't see ICMP unreachable from the OS.
Are they sending to the exact same IP and port you send in the SDP? Are you running any stateful firewalls that might not have opened the port for the RTP stream?
On 25 September 2014 14:59, Florent Krieg <flokrrr@gmail.com> wrote:
Hi mates,
We are encountering a problem with some of our customers in the following situation: * we are running Freeswitch with a public IP address, detecting far-end nat traversal when needed (customers behind NAT) * our customers interconnects their IPBXes to our FS platform (we do only SIP trunking with FS) * if the customer has its IPBX behind a NAT and sets a local redirect, there's no sound (and I completely understand why, I'm just trying to find a solution, if any...)
So there are two distinct calls: PSTN_X <===> FS <===> customer1 IPBX customer1 IPBX <===> FS <===> PSTN_Y (redirection)
When PSTN_Y answers the call, FS sends 200 OK w/ SDP to customer1 IPBX. The IPBX then sends an empty RTP packet, I reckon to allow the remote platform (FS in this case) to be able to detect the IP/port couple where to send RTP packets. The problem I have is that on the 'caller' side, this single empty RTP packet is sent by the IPBX before sending the 200 OK (like, a few ms before) and then FS seems to not be ready for it and reply ICMP unreachable.
To make this whole stuff almost-work, I've set 'rtp_auto_adjust_threshold' to 1, otherwise FS will wait for far more than 1 RTP packet to detect NAT.
My idea is that the IPBX should send the 200 OK first and right after this empty RTP packet. The problem is I'm encountering the issue with two different constructors (on one of them we ended using STUN, but the other one has a terrible STUN implementation, hence I'm really looking for a solution).
I know it's tricky (SIP, NAT, redirection and so on) but what do you think about this use case? Would you know a way to solve this trouble? If you have any clue please share!
Thanks in advance Florent
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.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
------------------------------ _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.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
-- Ken
*http://www.FreeSWITCH.org <http://www.FreeSWITCH.org> http://www.ClueCon.com <http://www.ClueCon.com> http://www.OSTAG.org <http://www.OSTAG.org> *irc.freenode.net #freeswitch Twitter: @FreeSWITCH
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.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
Hi all, No one has a clue about this use case? Can anybody confirm what Steven wrote earlier (i.e. 'So before the INVITE is even sent the port is open')? I just don't know how to behave here. I know it's a weird scenario and I understand why it doesn't work but it happens so many times with customers behind a NAT and I feel so close to a solution that I just can't stop trying to find a solution. Thanks in advance! Florent 2014-09-26 10:26 GMT+02:00 Florent Krieg <flokrrr@gmail.com>:
Hi Ken,
Thanks for pointing this out. I guess the value you have mentioned are overwritten by the following settings in switch.conf.xml (which I have set)? <!-- RTP port range --> <param name="rtp-start-port" value="20000"/> <param name="rtp-end-port" value="40000"/>
Florent
2014-09-25 19:38 GMT+02:00 Ken Rice <krice@freeswitch.org>:
Keep in mind that FreeSWITCH does not use the 20K to 40K range for RTP by default. It used 16384:32768 so your iptables rules there will probably cause a problem when FS tries to do media in the lower part of the range
On 9/25/14 10:54 AM, "Florent Krieg" <flokrrr@gmail.com> wrote:
Hi Steven,
Thanks for the reply!
Here's the firewall policy (iptables, the FS service is hosted on a centos6 server): -A INPUT -p udp -m udp --dport 20000:40000 -j ACCEPT The port annonced by FS and actually used was in this range (34546). Hence, I doubt the port s blocked.
There is still the possibility of the port not being listening. This is comforting that you say it should be listening on it right before the INVITE, but it is a bit weird I'm experiencing such a behaviour...
Steven, there are a lot of public IPs in my capture (among them some of customers and I don't want to obfuscate it so I won't post it here), but if you'd like I can send it to you by email so that you can have a look as well?
Thanks Florent
2014-09-25 17:06 GMT+02:00 Steven Ayre <steveayre@gmail.com>:
then FS seems to not be ready for it and reply ICMP unreachable.
This sounds odd. ICMP unreachable will be sent by the OS/firewall not FS. It means nothing is listening on that UDP port (or it's blocked). What's odd is the SDP FS sends in its INVITE packet will contain the IP and port it's using. It finds that port by creating a socket using a random port then checking what it's using. So before the INVITE is even sent the port is open, so you shouldn't see ICMP unreachable from the OS.
Are they sending to the exact same IP and port you send in the SDP? Are you running any stateful firewalls that might not have opened the port for the RTP stream?
On 25 September 2014 14:59, Florent Krieg <flokrrr@gmail.com> wrote:
Hi mates,
We are encountering a problem with some of our customers in the following situation: * we are running Freeswitch with a public IP address, detecting far-end nat traversal when needed (customers behind NAT) * our customers interconnects their IPBXes to our FS platform (we do only SIP trunking with FS) * if the customer has its IPBX behind a NAT and sets a local redirect, there's no sound (and I completely understand why, I'm just trying to find a solution, if any...)
So there are two distinct calls: PSTN_X <===> FS <===> customer1 IPBX customer1 IPBX <===> FS <===> PSTN_Y (redirection)
When PSTN_Y answers the call, FS sends 200 OK w/ SDP to customer1 IPBX. The IPBX then sends an empty RTP packet, I reckon to allow the remote platform (FS in this case) to be able to detect the IP/port couple where to send RTP packets. The problem I have is that on the 'caller' side, this single empty RTP packet is sent by the IPBX before sending the 200 OK (like, a few ms before) and then FS seems to not be ready for it and reply ICMP unreachable.
To make this whole stuff almost-work, I've set 'rtp_auto_adjust_threshold' to 1, otherwise FS will wait for far more than 1 RTP packet to detect NAT.
My idea is that the IPBX should send the 200 OK first and right after this empty RTP packet. The problem is I'm encountering the issue with two different constructors (on one of them we ended using STUN, but the other one has a terrible STUN implementation, hence I'm really looking for a solution).
I know it's tricky (SIP, NAT, redirection and so on) but what do you think about this use case? Would you know a way to solve this trouble? If you have any clue please share!
Thanks in advance Florent
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.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
------------------------------ _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.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
-- Ken
*http://www.FreeSWITCH.org <http://www.FreeSWITCH.org> http://www.ClueCon.com <http://www.ClueCon.com> http://www.OSTAG.org <http://www.OSTAG.org> *irc.freenode.net #freeswitch Twitter: @FreeSWITCH
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.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
participants (3)
-
Florent Krieg
-
Ken Rice
-
Steven Ayre