Re: [Freeswitch-users] Clustering FreeSWITCH
I'll have to 100% disagree with this statement. NAPTR and SRV are how it should always be done. Toss in some GEO dns and you have many of the problems solved. SRV records should never be optional they should be required to function properly. The NATPR records order preference of records which works in many hard and soft phones. Example which this works: <92>:host -t NAPTR bkw.org bkw.org has NAPTR record 10 10 "s" "SIPS+D2T" "" _sips._tcp.bkw.org. bkw.org has NAPTR record 20 20 "s" "SIP+D2S" "" _sip._sctp.bkw.org. bkw.org has NAPTR record 30 30 "s" "SIP+D2T" "" _sip._tcp.bkw.org. bkw.org has NAPTR record 40 40 "s" "SIP+D2U" "" _sip._udp.bkw.org. <93>:host -t SRV _sips._tcp.bkw.org _sips._tcp.bkw.org has SRV record 10 0 5061 sip.bkw.org. <94>:host -t SRV _sip._sctp.bkw.org. _sip._sctp.bkw.org has SRV record 10 0 5060 sip.bkw.org. <95>:host -t SRV _sip._tcp.bkw.org. _sip._tcp.bkw.org has SRV record 10 0 5060 sip.bkw.org. <96>:host -t SRV _sip._udp.bkw.org. _sip._udp.bkw.org has SRV record 10 0 5060 sip.bkw.org. With these records in place my Eyebeam will register to my FreeSWITCH instance via TLS since it was listed as the highest preference. The same goes for my Snom phones on my desk. They see the NAPTR's, SRV's and do exactly what I told them to do via DNS. The internet wouldn't exist today without DNS and if your DNS is that fragile you need to figure out why because without it we would be in for a world of hurt.... Not sure about you but I don't wanna remember what 4 billion IP's go to. Bottom line is NO SRV NO NAPTR you're doing it wrong in my opinion because as a SIP UA you have to look them all up anyway since its NOT optional as per the spec. /b On Oct 29, 2008, at 6:54 PM, Yuval Hertzog wrote:
4. I would strongly recommend reconsidering the use of any DNS feature (such as SRV records) when deploying a telephony infrastructure. Of course, it all depends what this deployment is for. DNS is commonly used in the ITSP space due to the vast audience but enterprises (all sized) are recommended to refrain adding DNS to the list of point-of-failures in their telephony architectures.
I actually spent a big chunk of today doing various tests. Freeswitch is doing all the right things in this scenario. The problem actually turns out to be my router/firewall that I'm testing behind. When the phones register, it only opens up the port back from the IP address of the server it registers to, so when the secondary server tries to send the invite, the router blocks it. In case anyone is curious, the router/firewall is a Linux box running Arno's Firewall. I'll be doing more tests with different routers to see which ones work and which ones don't. I'll post my results on the wiki page that I'll be creating that covers the setup I've got. For your other points, I'll take them (at least a few of them) one by one. 1. I'm doing this already to an extent. My "fs1" box is using a floating IP address and is being monitored using Redhat's cluster suite. If that box goes down, the IP's migrate to a backup machine that contains identical copies of the configurations and access to the shared storage. While not a load balancer, this keeps the primary switch up (except for the wedges that I've been experiencing that I talk about in another thread). The failover switch, my "fs2" box, is running on in a Xen guest machine on another server. 2. Freeswitch can't do what you describe. I believe that it does have the architecture for it, though, and it will just be a SMOP(tm) (Simple Matter Of Programming). Once Freeswitch matures a bit more I expect we'll be seeing all sorts of enterprise solutions for it. 3. True. Unless you control everything end to end like Cisco's Call Manager, you have to deal with what's out there, so you work up solutions like the one I've described. 4. Brian followed up on this point, and he said it better than I could. 5. I do agree that conferencing needs to be a bit more robust in a clustered environment. However, there is already a lot of that can be done to make Freeswitch scale by having multiple boxes and putting different conferences on different servers. Using xml_curl, you can write a back-end application that easily routes conferences to multiple different boxes to allow some form of load balancing. 6. I'm not nearly as worried about current calls dropping in the case of a failure as I am about new calls being routed and phones being registered. It would be nice in the case of a failure to not have calls drop, but not a requirement for me. 7. Carrierroute works extremely well for me in my environment. It allows me to have great control with least cost routing as well as have automatic redundant gateways both in and out. It also supports the shared database model for building in my own redundancies. The only thing that I don't like about it is that I can't selectively handle the media path. With my CR setup it doesn't touch any media at all. That has caused me some issues with one or two of my carriers, but nothing that was insurmountable. The ones I've had problems with expect you to be running a b2bua and have media come from the same IP as the SIP messages. For that reason alone I may end up replacing OpenSER with Freeswitch at some point in the future and selectively bypass media, but only if I can get a configuration as efficient as my CR setup. If not, I'll just add a second Freeswitch gateway that talks only to those certain providers. Not ideal, but it works. I will be starting a wiki page about everything I've setup within the next couple days. - Marc Yuval Hertzog wrote:
I assume the problem you asked about it happening because the client is disregarding the INVITE from a server with an IP address it was not registered to. If you try to capture the packets going out of your FS (or packets coming in your phone client), I bet you'll see the INVITE request, but no activity thereafter.
I believe that when considering High-Availability for FreeSWITCH, these issues need to be addressed: 1. A shared/floating IP clustering solution such as a load-balancer will only work if the SOFIA hash table is shared between all servers. I donâEUR^(TM)t know if FreeSWITCH entire state is being held in the database or whether some elements are being held in memory.
2. FreeSWITCH needs to have shared-bus architecture to allow for a fully clustered solution. Currently, I donâEUR^(TM)t think that two parked channels on different cluster nodes can be bridged in the current architecture because thereâEUR^(TM)s no inter-cluster media switching protocol that I know of.
3. A Meshed server approach where different clients are registered to different nodes (like the Cisco Call Manager architecture) seems to be the only immediate option but it is problematic as it requires the client to be configured with a list of redundant servers and most clients donâEUR^(TM)t have that functionality.
4. I would strongly recommend reconsidering the use of any DNS feature (such as SRV records) when deploying a telephony infrastructure. Of course, it all depends what this deployment is for. DNS is commonly used in the ITSP space due to the vast audience but enterprises (all sized) are recommended to refrain adding DNS to the list of point-of-failures in their telephony architectures.
5. I believe the FreeSWITCH conferencing module needs to be adapted to support clustering in order to scale over more than one server. This is due to the same share-bus issue mentioned earlier.
6. In a meshed servers architecture you will need to implement a mechanism that will identify which node in the cluster âEURoeownsâEUR? B-Leg, bridge the call to that node and in that node bridge the call again to B-Leg. When you find a way to implement it (I believe FreeSWITCH to have the tools to enable you to do it now), it would solve your current issue.
7. I still have doubts about using carrierroute module opposed to the DISPATCHER module for inbound traffic, mainly because of the registration issue, but I donâEUR^(TM)t have sufficient experience to determine that.
Anyway, itâEUR^(TM)s very interesting and I definitely like to know how youâEUR^(TM)re going with it.
*On Thu Oct 30 2:04 , "Anthony Minessale" sent:
*
This all seems right and would make a great wiki page. What you have described *should* work.
when a phone registers try doing sofia_contact <user@domain.com <javascript:top.opencompose('user@domain.com','','','')>> from the cli on each box and see what you get.
you can also use this function in the dialpan ${sofia_contact(user@domain.com <javascript:top.opencompose('user@domain.com','','','')>)}
check that they are both using the same domain name as the profile name or at least have an alais for it etc.
if it's a bug i can fix it pretty fast as that is the intended behaviour perhaps you can join irc and get us in the box(s) to have a look at it as we do not have that situation labbed up anywhere.
On Tue, Oct 28, 2008 at 6:41 PM, Marc Lewis <marc@avvatel.com <javascript:top.opencompose('marc@avvatel.com','','','')>> wrote:
I am in the process of making my FreeSWITCH installation highly available and I'm running into a couple of snags that was hoping that someone may have some insight on.
First, the setup as it is now.
There are two installations of FS on two different servers, lets call them fs1 and fs2. They each pull their configurations, dialplan, directory and post CDR's all using mod_curl from a central web server. That part works great.
Calls into and out of FS go through an OpenSER proxy set up using carrierroute. That part also works great for outbound calls to the PSTN. Inbound calls also come in through this OpenSER proxy and get routed to the primary switch fs1. That also works perfectly as long as its going to fs1.
fs1 and fs2 are both setup to use an ODBC connection to store registrations. This is pointed to a MySQL database made highly available using the RedHat Cluster Suite on a shared fibre channel partition. fs1 and fs2 both share the same database. Voicemail storage on fs1 is directly mounted on a GFS2 partition, fs2 is mounting the shared storage from a different server via NFS for no single point of failure.
For the phones, I have them setup to use SRV records and have fs1 at priority 10 and fs2 at priority 20 for acme.domain.com <http://acme.domain.com>. I've tested this and phones register to the correct server and the sip_registration table shows either fs1 or fs2 as the hostname as I would expect.
Here is the problem. If user 100@acme.domain.com <javascript:top.opencompose('100@acme.domain.com','','','')> registers on fs2 and a call comes in from the OpenSER proxy to fs1, bridging the call to /sofia/internal/100%acme.domain.com <http://acme.domain.com> from fs1 doesn't ring the phone. Is there a difference between 'sofia/internal/100%acme.domain.com <http://acme.domain.com>' and 'user/100@acme.domain.com <javascript:top.opencompose('100@acme.domain.com','','','')>'?
Calls out from either fs1 or fs2 routed to the proxy work fine, its just calls coming in from the proxy. If the call doesn't go to the switch the user is registered on, the user's phone doesn't ring. It still goes to voicemail, etc., so that part works.
Is there a better way to cluster FreeSWITCH than DNS SRV records and a shared state database?
Also, as a side note to Anthony, Brian, et al, if this is the best way, I'll be happy to write up a wiki page on how I have this setup with a lot more detail than this. I was not able to find much in the way of highly available configurations or cluster configurations, so I put together this system using information cobbled from the wiki, mailing list messages and lurking on IRC.
Thanks.
- Marc
-- Marc Lewis Avvatel Corporation
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org <javascript:top.opencompose('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
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthm MSN:anthony_minessale@hotmail.com <javascript:top.opencompose('MSN:anthony_minessale@hotmail.com','','','')> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <javascript:top.opencompose('PAYPAL:anthony.minessale@gmail.com','','','')> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <javascript:top.opencompose('sip:888@conference.freeswitch.org','','','')> iax:guest@conference.freeswitch.org/888 <http://iax:guest@conference.freeswitch.org/888> googletalk:conf+888@conference.freeswitch.org <javascript:top.opencompose('googletalk:conf_PLUS_888@conference.freeswitch.org','','','')> pstn:213-799-1400
------------------------------------------------------------------------
_______________________________________________ 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
-- Marc Lewis Avvatel Corporation
I had this same prblem, so the solution was to re-route the traffic with the info in the sip_registration database via the server the nat¹d client had registered to... This solves the NAT issue... Of couse if we didn¹t have to deal with NAT things would be much easier heh From: Marc Lewis <marc@avvatel.com> Organization: Avvatel Corporation Reply-To: <freeswitch-users@lists.freeswitch.org> Date: Wed, 29 Oct 2008 19:10:32 -0700 To: <freeswitch-users@lists.freeswitch.org> Subject: Re: [Freeswitch-users] Clustering FreeSWITCH I actually spent a big chunk of today doing various tests. Freeswitch is doing all the right things in this scenario. The problem actually turns out to be my router/firewall that I'm testing behind. When the phones register, it only opens up the port back from the IP address of the server it registers to, so when the secondary server tries to send the invite, the router blocks it. In case anyone is curious, the router/firewall is a Linux box running Arno's Firewall. I'll be doing more tests with different routers to see which ones work and which ones don't. I'll post my results on the wiki page that I'll be creating that covers the setup I've got.
what if you turn on that PATH header stuff in openser that we support that lets you pick the reverse proxy path for the calls? On Wed, Oct 29, 2008 at 9:50 PM, Ken Rice <krice@suspicious.org> wrote:
I had this same prblem, so the solution was to re-route the traffic with the info in the sip_registration database via the server the nat'd client had registered to... This solves the NAT issue... Of couse if we didn't have to deal with NAT things would be much easier heh
*From: *Marc Lewis <marc@avvatel.com> *Organization: *Avvatel Corporation *Reply-To: *<freeswitch-users@lists.freeswitch.org> *Date: *Wed, 29 Oct 2008 19:10:32 -0700 *To: *<freeswitch-users@lists.freeswitch.org> *Subject: *Re: [Freeswitch-users] Clustering FreeSWITCH
I actually spent a big chunk of today doing various tests. Freeswitch is doing all the right things in this scenario. The problem actually turns out to be my router/firewall that I'm testing behind. When the phones register, it only opens up the port back from the IP address of the server it registers to, so when the secondary server tries to send the invite, the router blocks it. In case anyone is curious, the router/firewall is a Linux box running Arno's Firewall. I'll be doing more tests with different routers to see which ones work and which ones don't. I'll post my results on the wiki page that I'll be creating that covers the setup I've got.
_______________________________________________ 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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
That would assume that I was putting openser infront of the boxes... That adds another failure point and yet another set of boxes that end up needing to be redundant From: Anthony Minessale <anthony.minessale@gmail.com> Reply-To: <freeswitch-users@lists.freeswitch.org> Date: Wed, 29 Oct 2008 21:55:46 -0500 To: <freeswitch-users@lists.freeswitch.org> Subject: Re: [Freeswitch-users] Clustering FreeSWITCH what if you turn on that PATH header stuff in openser that we support that lets you pick the reverse proxy path for the calls? On Wed, Oct 29, 2008 at 9:50 PM, Ken Rice <krice@suspicious.org> wrote:
I had this same prblem, so the solution was to re-route the traffic with the info in the sip_registration database via the server the nat'd client had registered to... This solves the NAT issue... Of couse if we didn't have to deal with NAT things would be much easier heh
From: Marc Lewis <marc@avvatel.com> Organization: Avvatel Corporation Reply-To: <freeswitch-users@lists.freeswitch.org> Date: Wed, 29 Oct 2008 19:10:32 -0700 To: <freeswitch-users@lists.freeswitch.org> Subject: Re: [Freeswitch-users] Clustering FreeSWITCH
I actually spent a big chunk of today doing various tests. Freeswitch is doing all the right things in this scenario. The problem actually turns out to be my router/firewall that I'm testing behind. When the phones register, it only opens up the port back from the IP address of the server it registers to, so when the secondary server tries to send the invite, the router blocks it. In case anyone is curious, the router/firewall is a Linux box running Arno's Firewall. I'll be doing more tests with different routers to see which ones work and which ones don't. I'll post my results on the wiki page that I'll be creating that covers the setup I've got.
_______________________________________________ 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
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthm MSN:anthony_minessale@hotmail.com <mailto:MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <mailto:PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <mailto:sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 <http://iax:guest@conference.freeswitch.org/888> googletalk:conf+888@conference.freeswitch.org <mailto:googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
_______________________________________________ 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
yah i guess, but seems like a proxy as the first thing your traffic hits is not the worst thing though then you can redir the traffic as needed. On Wed, Oct 29, 2008 at 10:03 PM, Ken Rice <krice@suspicious.org> wrote:
That would assume that I was putting openser infront of the boxes... That adds another failure point and yet another set of boxes that end up needing to be redundant
------------------------------ *From: *Anthony Minessale <anthony.minessale@gmail.com> *Reply-To: *<freeswitch-users@lists.freeswitch.org> *Date: *Wed, 29 Oct 2008 21:55:46 -0500 *To: *<freeswitch-users@lists.freeswitch.org> *Subject: *Re: [Freeswitch-users] Clustering FreeSWITCH
what if you turn on that PATH header stuff in openser that we support that lets you pick the reverse proxy path for the calls?
On Wed, Oct 29, 2008 at 9:50 PM, Ken Rice <krice@suspicious.org> wrote:
I had this same prblem, so the solution was to re-route the traffic with the info in the sip_registration database via the server the nat'd client had registered to... This solves the NAT issue... Of couse if we didn't have to deal with NAT things would be much easier heh
*From: *Marc Lewis <marc@avvatel.com> *Organization: *Avvatel Corporation *Reply-To: *<freeswitch-users@lists.freeswitch.org> *Date: *Wed, 29 Oct 2008 19:10:32 -0700 *To: *<freeswitch-users@lists.freeswitch.org> *Subject: *Re: [Freeswitch-users] Clustering FreeSWITCH
I actually spent a big chunk of today doing various tests. Freeswitch is doing all the right things in this scenario. The problem actually turns out to be my router/firewall that I'm testing behind. When the phones register, it only opens up the port back from the IP address of the server it registers to, so when the secondary server tries to send the invite, the router blocks it. In case anyone is curious, the router/firewall is a Linux box running Arno's Firewall. I'll be doing more tests with different routers to see which ones work and which ones don't. I'll post my results on the wiki page that I'll be creating that covers the setup I've got.
_______________________________________________ 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
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> <mailto:MSN%3Aanthony_minessale@hotmail.com><MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> <mailto:PAYPAL%3Aanthony.minessale@gmail.com><PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net <http://irc.freenode.net> <http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> <mailto:sip%3A888@conference.freeswitch.org><sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 <http://iax:guest@conference.freeswitch.org/888><http://iax:guest@conference.freeswitch.org/888> googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> <mailto:googletalk%3Aconf%2B888@conference.freeswitch.org><googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
------------------------------
_______________________________________________ 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
_______________________________________________ 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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
Marc, I'll chime in since I'm currently in the process of building a very similar environment... I currently have two FS boxes using xml_curl for configuration, dialplan, and directory data. All sip session info and voicemail data is stored in the mysql db which is on two multi-master mysql boxes. The two mysql boxes are in no way clustered, but the DNS A record round robins between them so generally the FS servers are load balancing their traffic between the two.. xml_curl pulls its data from the mysql db as well, so this way I could theoretically add as many FS boxes as I want, since they will all go back to the db for directory, configuration, dialplan, voicemail, sip registration data, etc. The UAs register directly with the FS boxes using DNS SRV and NAPTR records. As Brian already pointed out, SRV/NAPTR is the best way to go. Regarding your point of dealing with UAs sitting behind a NAT firewall/router and registered to any one of your many FS boxes, unless you have a single proxy for all your UAs, you need to bridge the call to the FS server the UA is registered with to get through the UA's firewall. I'm dealing with this in my dialplan through xml_curl. If a call comes in for a UA, the xml_curl module looks up in the sip_registrations table the location(s) of the FS server the user is registered with and if necessary, bridges the call to the appropriate FS server(s). Those servers in turn look up the user location, realize the user is registered locally, and generates a ${sofia_contact(user%domain.com <mailto:user@domain.com>)}to bridge the call to the one or many registrations. With UAs behind NAT/firewall routers, I think this is the only way to do it unless you want a SIP proxy sitting in front of your FS boxes with a single IP dealing with the UAs. While this environment isn't completely fault tolerant, I think it's easily scaled, as you can add more FS boxes with very little configuration effort since everything goes back to the db. If you'd like some help putting together the wiki, contact me offline, I'm more than willing to help. Now if we could only purchase g.729 licenses for transcoding in FS, that would solve a huge headache for me :) ... ~Gabe Marc Lewis wrote:
I actually spent a big chunk of today doing various tests. Freeswitch is doing all the right things in this scenario. The problem actually turns out to be my router/firewall that I'm testing behind. When the phones register, it only opens up the port back from the IP address of the server it registers to, so when the secondary server tries to send the invite, the router blocks it. In case anyone is curious, the router/firewall is a Linux box running Arno's Firewall. I'll be doing more tests with different routers to see which ones work and which ones don't. I'll post my results on the wiki page that I'll be creating that covers the setup I've got.
For your other points, I'll take them (at least a few of them) one by one.
1. I'm doing this already to an extent. My "fs1" box is using a floating IP address and is being monitored using Redhat's cluster suite. If that box goes down, the IP's migrate to a backup machine that contains identical copies of the configurations and access to the shared storage. While not a load balancer, this keeps the primary switch up (except for the wedges that I've been experiencing that I talk about in another thread).
The failover switch, my "fs2" box, is running on in a Xen guest machine on another server.
2. Freeswitch can't do what you describe. I believe that it does have the architecture for it, though, and it will just be a SMOP(tm) (Simple Matter Of Programming). Once Freeswitch matures a bit more I expect we'll be seeing all sorts of enterprise solutions for it.
3. True. Unless you control everything end to end like Cisco's Call Manager, you have to deal with what's out there, so you work up solutions like the one I've described.
4. Brian followed up on this point, and he said it better than I could.
5. I do agree that conferencing needs to be a bit more robust in a clustered environment. However, there is already a lot of that can be done to make Freeswitch scale by having multiple boxes and putting different conferences on different servers. Using xml_curl, you can write a back-end application that easily routes conferences to multiple different boxes to allow some form of load balancing.
6. I'm not nearly as worried about current calls dropping in the case of a failure as I am about new calls being routed and phones being registered. It would be nice in the case of a failure to not have calls drop, but not a requirement for me.
7. Carrierroute works extremely well for me in my environment. It allows me to have great control with least cost routing as well as have automatic redundant gateways both in and out. It also supports the shared database model for building in my own redundancies. The only thing that I don't like about it is that I can't selectively handle the media path. With my CR setup it doesn't touch any media at all. That has caused me some issues with one or two of my carriers, but nothing that was insurmountable. The ones I've had problems with expect you to be running a b2bua and have media come from the same IP as the SIP messages. For that reason alone I may end up replacing OpenSER with Freeswitch at some point in the future and selectively bypass media, but only if I can get a configuration as efficient as my CR setup. If not, I'll just add a second Freeswitch gateway that talks only to those certain providers. Not ideal, but it works.
I will be starting a wiki page about everything I've setup within the next couple days.
- Marc
Yuval Hertzog wrote:
I assume the problem you asked about it happening because the client is disregarding the INVITE from a server with an IP address it was not registered to. If you try to capture the packets going out of your FS (or packets coming in your phone client), I bet you'll see the INVITE request, but no activity thereafter.
I believe that when considering High-Availability for FreeSWITCH, these issues need to be addressed: 1. A shared/floating IP clustering solution such as a load-balancer will only work if the SOFIA hash table is shared between all servers. I donât know if FreeSWITCH entire state is being held in the database or whether some elements are being held in memory.
2. FreeSWITCH needs to have shared-bus architecture to allow for a fully clustered solution. Currently, I donât think that two parked channels on different cluster nodes can be bridged in the current architecture because thereâs no inter-cluster media switching protocol that I know of.
3. A Meshed server approach where different clients are registered to different nodes (like the Cisco Call Manager architecture) seems to be the only immediate option but it is problematic as it requires the client to be configured with a list of redundant servers and most clients donât have that functionality.
4. I would strongly recommend reconsidering the use of any DNS feature (such as SRV records) when deploying a telephony infrastructure. Of course, it all depends what this deployment is for. DNS is commonly used in the ITSP space due to the vast audience but enterprises (all sized) are recommended to refrain adding DNS to the list of point-of-failures in their telephony architectures.
5. I believe the FreeSWITCH conferencing module needs to be adapted to support clustering in order to scale over more than one server. This is due to the same share-bus issue mentioned earlier.
6. In a meshed servers architecture you will need to implement a mechanism that will identify which node in the cluster âownsâ? B-Leg, bridge the call to that node and in that node bridge the call again to B-Leg. When you find a way to implement it (I believe FreeSWITCH to have the tools to enable you to do it now), it would solve your current issue.
7. I still have doubts about using carrierroute module opposed to the DISPATCHER module for inbound traffic, mainly because of the registration issue, but I donât have sufficient experience to determine that.
Anyway, itâs very interesting and I definitely like to know how youâre going with it.
*On Thu Oct 30 2:04 , "Anthony Minessale" sent:
*
This all seems right and would make a great wiki page. What you have described *should* work.
when a phone registers try doing sofia_contact <user@domain.com <javascript:top.opencompose('user@domain.com','','','')>> from the cli on each box and see what you get.
you can also use this function in the dialpan ${sofia_contact(user@domain.com <javascript:top.opencompose('user@domain.com','','','')>)}
check that they are both using the same domain name as the profile name or at least have an alais for it etc.
if it's a bug i can fix it pretty fast as that is the intended behaviour perhaps you can join irc and get us in the box(s) to have a look at it as we do not have that situation labbed up anywhere.
On Tue, Oct 28, 2008 at 6:41 PM, Marc Lewis <marc@avvatel.com <javascript:top.opencompose('marc@avvatel.com','','','')>> wrote:
I am in the process of making my FreeSWITCH installation highly available and I'm running into a couple of snags that was hoping that someone may have some insight on.
First, the setup as it is now.
There are two installations of FS on two different servers, lets call them fs1 and fs2. They each pull their configurations, dialplan, directory and post CDR's all using mod_curl from a central web server. That part works great.
Calls into and out of FS go through an OpenSER proxy set up using carrierroute. That part also works great for outbound calls to the PSTN. Inbound calls also come in through this OpenSER proxy and get routed to the primary switch fs1. That also works perfectly as long as its going to fs1.
fs1 and fs2 are both setup to use an ODBC connection to store registrations. This is pointed to a MySQL database made highly available using the RedHat Cluster Suite on a shared fibre channel partition. fs1 and fs2 both share the same database. Voicemail storage on fs1 is directly mounted on a GFS2 partition, fs2 is mounting the shared storage from a different server via NFS for no single point of failure.
For the phones, I have them setup to use SRV records and have fs1 at priority 10 and fs2 at priority 20 for acme.domain.com <http://acme.domain.com>. I've tested this and phones register to the correct server and the sip_registration table shows either fs1 or fs2 as the hostname as I would expect.
Here is the problem. If user 100@acme.domain.com <javascript:top.opencompose('100@acme.domain.com','','','')> registers on fs2 and a call comes in from the OpenSER proxy to fs1, bridging the call to /sofia/internal/100%acme.domain.com <http://acme.domain.com> from fs1 doesn't ring the phone. Is there a difference between 'sofia/internal/100%acme.domain.com <http://acme.domain.com>' and 'user/100@acme.domain.com <javascript:top.opencompose('100@acme.domain.com','','','')>'?
Calls out from either fs1 or fs2 routed to the proxy work fine, its just calls coming in from the proxy. If the call doesn't go to the switch the user is registered on, the user's phone doesn't ring. It still goes to voicemail, etc., so that part works.
Is there a better way to cluster FreeSWITCH than DNS SRV records and a shared state database?
Also, as a side note to Anthony, Brian, et al, if this is the best way, I'll be happy to write up a wiki page on how I have this setup with a lot more detail than this. I was not able to find much in the way of highly available configurations or cluster configurations, so I put together this system using information cobbled from the wiki, mailing list messages and lurking on IRC.
Thanks.
- Marc
-- Marc Lewis Avvatel Corporation
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org <javascript:top.opencompose('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
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthm MSN:anthony_minessale@hotmail.com <javascript:top.opencompose('MSN:anthony_minessale@hotmail.com','','','')> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <javascript:top.opencompose('PAYPAL:anthony.minessale@gmail.com','','','')> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <javascript:top.opencompose('sip:888@conference.freeswitch.org','','','')> iax:guest@conference.freeswitch.org/888 <http://iax:guest@conference.freeswitch.org/888> googletalk:conf+888@conference.freeswitch.org <javascript:top.opencompose('googletalk:conf_PLUS_888@conference.freeswitch.org','','','')> pstn:213-799-1400
------------------------------------------------------------------------
_______________________________________________ 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
-- Marc Lewis Avvatel Corporation
------------------------------------------------------------------------
_______________________________________________ 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, Sorry for jumping in without reading the whole thread correctly but I will most likely not have the time to do so before Saturday but would still provide some feedback. When using Openser as a customer phone proxy, it is my understanding that unless you use the PATH extension you will have problem with firewalls as the packet from Freeswitch will not match the opened IP address for the UDP port. In the scenario where the phone send a REGISTER this way : Phone -> Firewall (create an association) -> OpenSer -> Freeswitch. If Freeswitch answers directly to the packet, it will not match the association on the firewall for the return packet (different IP) and the connection may/will be blocked, so the reply to the REGISTER must come back via OpenSER. Same thing for the INVITE message, if FS tries to connect the firewall directly the packet will be blocked. As well, the firewall mapping need to be kept open with some kind of SIP pinging using OPTIONS - for example - and going through OpenSER as well from the FS server When quickly looking into it a few weeks ago - before I was side tracked, I found that the way OpenSER and FS way of using SIP PATH are not working together very well (I was planning a mail to the list with more info once I checked this more extensively). I can see the point with trying to not use OpenSER and use DNS SRV but you may not always be able to do without. Regards, Thomas
participants (7)
-
Anthony Minessale
-
Brian West
-
Gabriel Kuri
-
Ken Rice
-
Marc Lewis
-
Thomas Mangin
-
Yuval Hertzog