Panoramisk / The VoIP druid 

On peut être passionné par la téléphonie et prendre soin de soi : "Faites du sport, faites du vélo" est la devise du site d'e-commerce lancé par l'un des auteurs de Panoramisk : bikeo. Si vous faites du vélo, que ce soit en ville, sur la route ou sur les chemins plus accidentés, n'hésitez pas à aller faire un petit tour sur www.bikeo.fr pour vos prochains achats verts.
En plus leur plate-forme de téléphonie utilise Asterisk, comme quoi on peut la convergence est une réalité.

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

Both Asterisk server in the cluster¹ 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:

; ---------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] ------------------

; ---------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 [↩]