Hi,
i have a question about redundancy. Do you know any solutions for this? I mean somethink like a cluster if one server goes down the second is active…
I can’t find any information about this feature in Asterisk…
Thanx
David
Hi,
i have a question about redundancy. Do you know any solutions for this? I mean somethink like a cluster if one server goes down the second is active…
I can’t find any information about this feature in Asterisk…
Thanx
David
Well, have multiple Asterisk boxes. Use DNS SRV/NAPTR on your phones to allow them to select the Asterisk box to use based on a failover method, or load balance.
The trick is how to maintain a consistent/uptodate set of configuration between all the Asterisk boxes. Anyone got an opinion this?
Sure, you can access a database from extensions.conf for your dial plan. But you can’t from sip.conf, voicemail.conf etc. What’s that project called to put all the files into a database? Asterisk realtime? Looks a bit too alpha for what I’d like.
Maybe some custom scripts with rsync to regularly sync files between all the boxes.
The redundancy suggestion seems pretty dumb to me.
Get phones that support DNS NAPTR/SRV. The phones will use the correct Asterisk server. Better than having to change IP addresses.
[quote=“dgarstang”]The redundancy suggestion seems pretty dumb to me.
Get phones that support DNS NAPTR/SRV. The phones will use the correct Asterisk server. Better than having to change IP addresses.[/quote]
There are multiple suggestions in the link above, which one seems ‘pretty dumb’ and why? There are many ways to approach redundancy all depending on requirements and resources available to the system being implemented.
Depending entirely on the endpoints for redundancy will not be practical for many systems. As there are a myriad of endpoints that may be used, mixed endpoints, etc. Further, there are service providers deploying Asterisk as a network component providing services to third parties.
It is best to make a broad set of possibilities available without knowing the users specific requirements, and then assess what makes sense for their particular implementation. What may be ‘dumb’ for your environment is perfect for another and vice versa.