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
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.
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
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 <[EMAIL PROTECTED]
from the cli on each box and see what you get.
you can also use this function in the dialpan
check that they are both using the same domain name as the profile
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
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 <[EMAIL PROTECTED]
I am in the process of making my FreeSWITCH installation highly
available and I'm running into a couple of snags that was
someone may have some insight on.
First, the setup as it is now.
There are two installations of FS on two different servers,
them fs1 and fs2. They each pull their configurations, dialplan,
directory and post CDR's all using mod_curl from a central web
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
PSTN. Inbound calls also come in through this OpenSER proxy
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.
on fs1 is directly mounted on a GFS2 partition, fs2 is
shared storage from a different server via NFS for no single
For the phones, I have them setup to use SRV records and have
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
table shows either fs1 or fs2 as the hostname as I would expect.
Here is the problem. If user [EMAIL PROTECTED]
registers on fs2 and a
call comes in from the OpenSER proxy to fs1, bridging the call to
from fs1 doesn't ring the phone. Is
there a difference between 'sofia/internal/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
the user is registered on, the user's phone doesn't ring. It
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
I'll be happy to write up a wiki page on how I have this setup
lot more detail than this. I was not able to find much in the
highly available configurations or cluster configurations, so
together this system using information cobbled from the wiki,
list messages and lurking on IRC.
Freeswitch-users mailing list
Anthony Minessale II
IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference
Freeswitch-users mailing list
Freeswitch-users mailing list