[Asterisk-Dev] SIP failover using Asterisk and openais

[Mark Aiken]

RTP is used to carry the media between endpoints. Its UDP based. SIP is
rapidly moving to TCP (and some to TLS) so the UDP assumption will work now
but unlikly in say 18 months from now.

The problem you face is that there are other entities in the network that
expect the IP address for the sessions to remain unchanged - unless
specifically redirected.

The UA's for one will be sending their media to the old IP address of the
Asterisk server (if they were in the path , for a conference or voicemail or
DTMF based feature handling for example). The firewalls in the path will be
expecting media and new requests within the same dialog to be coming from
the old address as well. SBC's will no doubt reject any attempts to re-use
the same session from a different address ...

There are many problems to solve for a general solution.

Mark

On 9/28/05, Steven Dake <sdake at mvista.com> 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 <http://192.168.1.10> active
> 192.168.1.11 <http://192.168.1.11> standby
>
> The active has a virtual ip address 192.168.1.200 <http://192.168.1.200>which is the IP
> address of the actual SIP server. if 192.168.1.10 <http://192.168.1.10>fails or is assigned
> standby, it should delete this virtual ip address. Then 192.168.1.11<http://192.168.1.11>
> will be assigned active, and it should create a virtual ip address
> 192.168.1.200 <http://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
>
> > On 9/28/05, Steven Dake <sdake at mvista.com> wrote:
> > Fellow developers,
> >
> > I maintain the open source project openais
> > http://developer.osdl.org/dev/openais which is an open source
> > version of
> > the Service Availability Forum's AIS specification.
> >
> > This implementation provides checkpointing and application
> > failover.
> > I'd like to create an integration between the SIP channel
> > module and
> > openais AMF/checkpointing and perhaps have it integrated into
> > the
> > asterisk source base as a proof of concept of AIS.
> >
> > The integration would allow multiple servers to maintain an
> > active/standby the state of all SIP sessions. Then the active
> > server
> > for which the IP phone is communicating with would continue to
> > operate
> > and maintain its session in the event the active server
> > failed.
> >
> > Would someone be kind enough to point me to the data
> > structures or
> > functions where the state of a SIP session is recorded. Is it
> > possible
> > just to record SIPs state, or does the rest of the asterisk
> > server that
> > loads the sip module contain state about the SIP session?
> >
> > In SIP, is an IP phone configured to talk to one specific IP
> > address, or
> > is there a discovery process to determine the SIP server's ip
> > address?
> >
> > Finally in do_monitor, I notice there is a ast_sched_wait,
> > followed by
> > an ast_io_wait. ast_io_wait appears to dispatch any pending
> > i/o events
> > as derived from poll. I need to plug in here with an
> > ast_io_add to add
> > my "healthchecking" for the SIP server. My question is with
> > ast_sched_wait.. Will it timeout immediately if there is I/O
> > waiting?
> > In other event systems, timers and events are usually
> > integrated.. I'm
> > not sure how these two work in asterisk by looking at the
> > code.
> >
> > Thanks for the help
> >
> > regards
> > -steve
> >
> >
> > _______________________________________________
> > Asterisk-Dev mailing list
> > Asterisk-Dev at lists.digium.com
> > http://lists.digium.com/mailman/listinfo/asterisk-dev
> > To UNSUBSCRIBE or update options visit:
> > http://lists.digium.com/mailman/listinfo/asterisk-dev
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20050928/367b6d30/attachment.htm