About | Lab | Neigborhood | Most popular | Help us

Panoramisk / The VoIP druid 

Asterisk redundancy, a very simple approach

As soon as we install in an organisation an Asterisk IP telephony service, it can impact directly on the service and we should study how it can be resilient. This article proposes a very simple but redundant telephony service with two Asterisk servers installed in a load-balancing mode.

Context

Unlike industrial equipment, generally used in traditional telephony services, our new IP telephony installation are using computers with movable parts. The main one that could fail are fans for power supplies and processors, as well as hard drives. How can we insure that telephony service will not be impacted (too much) in case this server fails? Can we add some resiliency to our Asterisk system?

The first option is to build a real Unix cluster with real time synchronisation, chorum and heartbeat. We can also build a standby Asterisk server with a procedure allowing it to start over the failing one. What we propose here is a really simple solution based on two Asterisk live servers and a way to pass calls from one to the other. We don’t manage external communication systems like SIP providers or digital interface line but these could easily be plugged on the proposed solution directly in the dial plan.

How it works

Cluster Asterisk

Both Asterisk server in the cluster1 is able to handle a local call and if this fails to push the call towards its peer node. With this principle, we let any SIP (or IAX) phone on the local installation register with one Asterisk, chosen through DNS SRV record for example. We could also use the DNS load-balancing but this could bring some discrepancy between registering and placing call. We also need an anti-loop system in order to calls to be exchanged only once between cluster nodes, we propose to do it simply through a variable.

Configuration details

Here below are both Asterisk server configuration, the extensions.conf part:

Node 1
; ---------Start: [cluster-local] ----------------
[cluster-local]
exten => _[12]X,1,Verbose(${FROM_CLUSTER})
exten => _[12]X,2,Dial(SIP/${EXTEN},20,rt)
exten => _[12]X,3,GotoIf($["${FROM_CLUSTER}" == "1"]?_[12]X,6)
exten => _[12]X,4,Set(CALLERID(num)=9999${CALLERID(num)})
exten => _[12]X,5,Dial(SIP/cluster-node2/${EXTEN},20,rt)
;
exten => _[12]X,6,Congestion()
; ---------End: [cluster-local] ------------------

; ---------Start: [cluster-from-remote] ----------------
[cluster-from-remote]
exten => _.,1,Set(_FROM_CLUSTER=1)
exten => _.,2,Set(CALLERID(num)=${CALLERID(num):4})
exten => _.,3,Goto(cluster-local,${EXTEN},1)
; ---------End: [cluster-from-remote] ------------------

Node 2
; ---------Start: [cluster-local] ----------------
[cluster-local]
exten => _[12]X,1,Verbose(${FROM_CLUSTER})
exten => _[12]X,2,Dial(SIP/${EXTEN},20,rt)
exten => _[12]X,3,GotoIf($["${FROM_CLUSTER}" == "1"]?_[12]X,6)
exten => _[12]X,4,Set(CALLERID(num)=9999${CALLERID(num)})
exten => _[12]X,5,Dial(SIP/cluster-node1/${EXTEN},20,rt)
;
exten => _[12]X,6,Congestion()
; ---------End: [cluster-local] ------------------

; ---------Start: [cluster-from-remote] ----------------
[cluster-from-remote]
exten => _.,1,Set(_FROM_CLUSTER=1)
exten => _.,2,Set(CALLERID(num)=${CALLERID(num):4})
exten => _.,3,Goto(cluster-local,${EXTEN},1)
; ---------End: [cluster-from-remote] ------------------

Main points in the proposed solution are:

  • each local call from IP phones arrives in the cluster-local context. Here we only manage the local calls in the dial plan, but we could easily add standard external routing, voicemail or any kind of call.
  • each call arriving from another cluster node is pushed to the cluster-from-remote context.
  • FROM_CLUSTER variable is set to avoid loops between cluster members. It is set when receiving a call from a remote member et checked before routing the call to another member. If we install more than two members, this principle should be enhanced with a variable passed in the call or a specific prefix.
  • when a call is passed from one member to another, the caller identifier is changed in order not to collide with SIP local extensions. Here we are using 9999 as prefix and suppress it at arrival.

Conclusion

Here is a really simple way of providing redundancy to our Asterisk solution. It is called “cluster” but is really not a real cluster. We will approach the cluster solution in some other articles, so stay tuned.


  1. this could be expanded if necessary []
Posted by: Alexandre Chauvin-Hameau, on 06/24/2007
Trackback | Popularity: 30%
tagged , , , , and
AddThis Social Bookmark Button
UselessNothing newInformativeLearned a lotAmazingly helpful (1 votes, average: 5 out of 5)
Loading ... Loading ...

See also

And why not

One answer to “Asterisk redundancy, a very simple approach”

  1. Ejemplo sencillo de redundancia en Asterisk at Mi Brain-Training Personal said:

    […] aquí un ejemplo bastante sencillo de como implementar redundancia de servidores Asterisk. El ejemplo no […]

Leave a comment

© 2010 Panoramisk | Creative Commons License wordpress logo