Achieve High Availability in VoIP: An Implementation Example--Part II

The clear modularity of the Asterisk software was helpful as the SIP channel specific layer was distinctly separate from other elements. There were a number of key challenges in porting the Asterisk application including:

1. Understanding the external event handling loops or blocking function calls in order to recognize application process role changes
2. Identifying the relevant call context "stateful" information for checkpointing

These elements are important to any highly available application--let's see why.

Detection--Application Process Roles
With elements and processes able to occupy either the Active or Standby role, it is crucial to be able to detect any changes in these roles. Depending on the direction of change either a save or a restore of the context data check-pointed previously is required for seamless failover. To affect this, an application, when registering with SAFE4CS, must be prepared to handle messages and signals delivered by the middleware so that it can take adequate actions. It is therefore important to identify the blocking event waits in the application where it should now be enhanced to recognize the aforementioned role changes.

The Asterisk PBX design contains a channel monitoring thread within the SIP module. It sits in a tight loop which monitors for external events on all its idle channels. This function is enhanced as shown in the code segment below to additionally monitor for events (such as role changes) detected via AMF and then take appropriate actions.

Checkpointing The complete inner state of the application is described by the Checkpoint data. It is crucially important that any "stateful" high availability application is capable of failover without any disruption of service. For the Asterisk PBX application to become highly available, it is necessary that call-state information is check-pointed such that in the case of a failure in the active blade, the hot-standby is able to takeover and maintain service continuity. A sample SIP session flow diagram is shown in figure 6 that identifies the call-state information checkpoints in the active blade.

In the Asterisk SIP module, the call-state information is saved in the handle_response() function as part of the INVITE and BYE processing. The checkpoint data consists of the channel control blocks (struct ast_channel, struct ast_channel_pvt) and the SIP private control block (struct sip_pvt) associated with both legs of the call (approximately 32KB). Note that no attempt was made to optimize the size of the checkpoint data as this would have required a deeper understanding of the usage of various fields within the Asterisk core control structures.

Registration, Deregistration and Signal handler changes
The application enhancements for utilizing high-availability services can be split into the following areas:

• Registration/Deregistration
• Signal handler
• Main logic for checkpointing and process role detection (described previously)

As a general rule, an application needs to initialize the functionality it requires from SAFE4CS via Registration with the management component of the particular service. Asterisk's main() function (figure 7) are the extensions that implement the registration procedures.

Page 2: next page
Page 1 | 2