[Asterisk-Dev] SIP failover using Asterisk and openais

[John Todd]

At 4:58 PM -0700 on 9/28/05, Steven Dake wrote:
>On Wed, 2005-09-28 at 18:43 -0500, Mark Aiken wrote:
>>  Steven,
>>
>>  I'm not familiar with AIS but if your plan is to support in-call
>>  handoff to a different IP you have issues at the session layer to deal
>>  with. That problem I am familiar with and its not easy to keep a SIP
>>  call up and move the IPs of a SIP server than is in the call-control
>>  and/or media path of the session. Especially if the original server
>>  just dies mid-call. DNS tricks will be of little use mid-call. In
>>  fact, without moving the sessions prior to the switch,  I'm not sure
>>  its even possible  without 'dialing' back the parties to reestablish
>>  the sessions. That may be your only viable option, and its not such a
>>  bad one really. Note aslo that wrt SIP, Asterisk is a B2BUA and has 2
>>  call-control (SIP) and often 2 media (RTP) sessions for each call
>>  between UAs (SIP phones).
>>
>>  Certainly it will be an interesting project.
>>
>>  Mark
>>
>
>Mark,
>
>
>Thanks for the feedback. 
>
>I would like to ensure that sessions remain operational and a redial
>isn't necessary.
>
>AIS will checkpoint the entire SIP session state into a data storage
>area shared by multiple nodes.  Since SIP uses UDP, it should be
>possible to switch the IP address (ip address failover) when the active
>becomes standby.  Then new operations will be directed to the same IP
>address, which is now on the newly assigned active node.  Then the
>standby server will have an exact replica of the SIP session state when
>it recovers and becomes active.  AIS takes care of all of the details of
>the checkpoint management and assignment of active/standby states.  The
>only trick is to record any changed SIP state data using a checkpoint
>write call, and read state data on active assignment using a checkpoint
>read call.  I found sip_pvt which should contain all the private data.
>Are there other data structures that I should worry about recording?
>
>If that isn't clear, let me give an example with two nodes:
>192.168.1.10 active
>192.168.1.11 standby
>
>The active has a virtual ip address 192.168.1.200 which is the IP
>address of the actual SIP server.  if 192.168.1.10 fails or is assigned
>standby, it should delete this virtual ip address.  Then 192.168.1.11
>will be assigned active, and it should create a virtual ip address
>192.168.1.200.
>
>Regarding the call control (SIP) connections..  Are there 2 at each end,
>or just one instance at each end?
>
>It appears that asterisk contains state data that is passed to some of
>the operations.  The comments indicate it has to do with pbx state
>management.  I assume this is for cli and gui access.  Does this
>asterisk state contain any other useful information, or could I avoid
>having to also replicate it, and instead just checkpoint the full SIP
>session state.
>
>One final question, I am not familiar with the purpose of RTP.  Does it
>also have some state that is required for two ip phones to communicate?
>
>regards
>-steve
[snip]

In another note: while I did not read a detailed report on the 
methods or functionality, I heard the IBM guys in the Digium booth at 
VON last week talking about hot failover with their equipment 
combined with Asterisk.  "Some patches were required" was the comment 
from the IBM rep, but he claimed that the entire system could be 
replicated and kept state across multiple blades.

This was on a multi-blade server sitting in the booth, which they 
were showing off as an Asterisk-specific platform.  The big trick was 
not that Asterisk ran on IBM equipment, but that they had redundancy 
within the platform in a way that was not just a "stupid IP trick", 
and kept call state across failure events.  I couldn't get near the 
sales rep due to the congested booth area, or I would have asked 
about media state.

I think perhaps someone from Digium could comment on this, or someone 
from IBM, but I have no idea who is responsible for the work/product 
from either company.

JT