asterisk users - Sep 2008 - Redundant PSTN PRI Gateways using Asterisk

I currently have two T1 PRI lines feeding our company's legacy PBX.  All
our numbers are DIDs and can pass over both PRI.  Currently, if one PRI
line (or T1 interface card in the PBX) is down, communication continues
to function as normal (with the exception of the reduction of channels
available for in- and outgoing calls).

I am looking to implement Asterisk in front of the legacy PBX as the new
gateway to the PSTN for the company in an effort to begin a slow
transition to VoIP.  While I am familiar with Asterisk when it comes to
implementing it as a single box solution for PRI, SIP, voicemail, IVR,
etc, I get a little confused when you start to separate the functions to
different boxes for redundancy and scalability.

I believe that the first phase of what I am asking probably just
involves setting up two asterisk boxes with dual port T1 cards (one port
as incoming from PSTN and second as feed to legacy PBX), and including a
simple dial plan with regex extension capturing all my DIDs passing
incoming calls out the PRI and allowing from the PBX to go out the PRI.
This way if a PRI line goes down, one of the Digium T1 cards fail, or
one of the asterisk servers fail, everything continues to work through
the other one.  This essentially give me the exact same functionality
and reliability I have currently plus the ability to start a migration
to VoIP internally.  I don't believe any fancy load balancing /
redundancy techniques are need for this part as that is handled on the
providers end which routes the DIDs over both PRIs.  Is there something
I am missing about this part?  I know alternatively I could use
something like redfone bridge but then I feel that device becomes a
single point of failure which I do not want to introduce into the
environment.

The next step I would like to take is to move the voicemail from the
legacy PBX to another pair of asterisk servers acting as redundant
voicemail servers.  This is where I get a bit lost.  Here is the outline
of what I believe I need to do.

1. build asterisk server to act as voicemail server
2. setup mailboxes in voicemail.conf for each extension/user that is to
have voicemail
3. connect both gateways to the voicemail server via IAX
4. edit the dial plans on both gateway asterisk servers to include an
extension that points to voicemail() and voicemailmain() extension on
the voicemail server
5. edit legacy pbx to direct voicemail (message button on phones) to
extension on asterisk server for voicemailmain app
6. edit legacy pbx to direct unanswered call to extension on asterisk
server for voicemail app
7. build second asterisk server to act as redundant voicemail server and
integrate it somehow

Questions on this include:
-	Best way to have active/active redundant voicemail nodes (iSCSI
SAN is available) to accomplish load balancing and failure redundancy
(LVS, Linux-HA, ultramonkey, etc)
-	If balanced via LVS, then there is only one IAX connection to
the virtual IP address of the cluster and the director handles balancing
which server processes the VM call, correct?  In other solutions, how
would this work?
-	Is it appropriate for the gateway server to directly link to the
voicemail servers when distributing the services like this or should
something like DUNDi or SER be used?
-	How do I route from the legacy PBX back to one of the gateways
in order to pass to the VM servers across the two T1 connections (again,
so that in the event one is down, voicemail routing still works) - this
may be more of a question for the PBX guys.
-	Will be interested in Unified Communications, so storage of
voicemail in our email server (exchange) using IMAP may be the route
taken as opposed to using SAN in which case csync2 or similar may be
used to just keep conf files the same on cluster nodes instead of shared
storage.

The eventual next step would be to implement another cluster of asterisk
servers to act as media servers for call recording, moh, ivr menus,
conferences, and agi.  Setup a SER/openSER cluster for registering new
IP phones and somehow routing all the traffic between the IP phones,
media servers, gateways, voicemail servers, and legacy pbx.  Then,
eventual phasing out the pbx.  I will pose more specific question on
this when the time comes but I mention it in case anyone sees issue with
what I do in the early phases that would negatively impact where I
ultimately want to go.


	 PBX PRI A connection
		|
PRI A ---- Asterisk Gateway A -----IAX----\ 
				    	   ---- Asterisk VM Servers x2
(LVS Cluster with iSCSI SAN shared storage ?)
PRI B ---- Asterisk Gateway B -----IAX----/ 
		|
 PBX PRI B connection


Any thoughts, comments, suggestion would be appreciated as I don't feel
there is sufficient information out there on redundant enterprise type
setups.  Again the initial focus is on the gateways and voicemail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20080901/a1290a9a/attachment.htm

Michael Melia Jr. wrote:
> I am looking to implement Asterisk in front of the legacy PBX as the new 
> gateway to the PSTN for the company in an effort to begin a slow 
> transition to VoIP.  While I am familiar with Asterisk when it comes to 
> implementing it as a single box solution for PRI, SIP, voicemail, IVR, 
> etc, I get a little confused when you start to separate the functions to 
> different boxes for redundancy and scalability.
The main operative methodologies are:

1. Run services to a given Asterisk box in a dedicated way using SIP 
trunks among them.

2. On the TDM and/or VoIP provider side, make sure that redundant 
gateways can be cycled through using hunt groups.  If some sort of 
end-to-end reachability ping facility is available for verification on 
the VoIP side, a la the SIP OPTIONS ping that comes with the 'qualify' 
option in sip.conf, have the provider use it so unreachable servers are 
disabled if they are chronically unreachable in order to decrease call 
setup time.
> I don?t believe any fancy load balancing / 
> redundancy techniques are need for this part as that is handled on the 
> providers end which routes the DIDs over both PRIs.  
Yep, any switch that can generate PRIs from the provider side can handle 
that.
> The next step I would like to take is to move the voicemail from the 
> legacy PBX to another pair of asterisk servers acting as redundant 
> voicemail servers.  This is where I get a bit lost.  Here is the outline 
> of what I believe I need to do.
> 
> 1. build asterisk server to act as voicemail server
> 
> 2. setup mailboxes in voicemail.conf for each extension/user that is to 
> have voicemail
> 
> 3. connect both gateways to the voicemail server via IAX
> 
> 4. edit the dial plans on both gateway asterisk servers to include an 
> extension that points to voicemail() and voicemailmain() extension on 
> the voicemail server
> 
> 5. edit legacy pbx to direct voicemail (message button on phones) to 
> extension on asterisk server for voicemailmain app
> 
> 6. edit legacy pbx to direct unanswered call to extension on asterisk 
> server for voicemail app
> 
> 7. build second asterisk server to act as redundant voicemail server and 
> integrate it somehow
That is correct, although personally I would recommend the use of SIP 
trunks rather than IAX2.  But, that is a matter of perspective.
> 
> Questions on this include:
> 
> -       Best way to have active/active redundant voicemail nodes (iSCSI 
> SAN is available) to accomplish load balancing and failure redundancy 
> (LVS, Linux-HA, ultramonkey, etc)
You could store the actual messages in an IMAP backend or ODBC.  Both 
options are available.

Linux-HA and ultramonkey can both be made to work in this setup.  As 
long as you can tell the heartbeat daemon to run some script that checks 
for Asterisk's availability, you're set.  Tools like 'sipsak'
offer an
easy way to ping the SIP agent:

    sipsak -T -s sip:s at asterisk.ip
> -       Is it appropriate for the gateway server to directly link to the 
> voicemail servers when distributing the services like this or should 
> something like DUNDi or SER be used?
There's nothing inherently inappropriate about it, but an OpenSER proxy 
can be helpful because it can give you a point of control and possible 
call dialog manipulation if it is

However, a unitary proxy is another point of failure.

For something as simple as voicemail features, there's no inherent need 
for it unless you foresee one for the aforementioned purposes.
> The eventual next step would be to implement another cluster of asterisk 
> servers to act as media servers for call recording, moh, ivr menus, 
> conferences, and agi.  Setup a SER/openSER cluster for registering new 
> IP phones and somehow routing all the traffic between the IP phones, 
> media servers, gateways, voicemail servers, and legacy pbx.  Then, 
> eventual phasing out the pbx.  I will pose more specific question on 
> this when the time comes but I mention it in case anyone sees issue with 
> what I do in the early phases that would negatively impact where I 
> ultimately want to go.
Using a proxy (OpenSER) to direct distributed architectures would be 
quite sensible, and they are a critical component of enterprise VoIP 
platforms.

-- Alex


Alex Balashov
Evariste Systems
Web    : http://www.evaristesys.com/
Tel    : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599

On Mon, 1 Sep 2008 22:01:19 -0400, "Michael Melia Jr."
said:
> 
> I am looking to implement Asterisk in front of the legacy PBX as the new
> gateway to the PSTN for the company in an effort to begin a slow
> transition to VoIP.  While I am familiar with Asterisk when it comes to
> implementing it as a single box solution for PRI, SIP, voicemail, IVR,
> etc, I get a little confused when you start to separate the functions to
> different boxes for redundancy and scalability.
> 
We're doing something similar, except that we have only 1 PRI.  I too am
partially in new waters with this project, but we've chosen to buy a
RedFone box instead of a complex assortment of PRI cards between MAIN
and FAILOVER and LEGACY PBX's.  We like the choice because it's simple,
highly reliable and gives us lots of flexibility and failover options
(available).  For example:

1 - It means we don't have to any PRI cards for the asterisk servers
themselves--the redfone box wraps the TDM in ethernet frames.  The
Asterisk boxes need no hardware other than their own ethernet cards. 
The Redfone box translates the TDM to TDM over Ethernet (TDMoE).  Now we
can do any *logical* routing we want between Ast1, Ast2 and Legacy
without having to establish *physical* routes and interfaces.
2 - The RedFone box has the PRI interface(s) from the Telco, AND to the
legacy PBX.  The legacy PBX remains essentially unchanged, except that
RF routes the traffic to Ast1 (Ast2 if Ast1 is down), and Asterisk can
decide which call tasks it wants to handle, and which it will route BACK
to the legacy PBX.  If we want migrate a number, service, mailbox, IVR
etc AWAY from the Legacy PBX, we do so easily with a tiny tweak of the
dialplan.  If we move something from away from the legacy system, and it
turns out to have a problem, bug, etc. (not that my dialplans EVER have
problems, but I'm just speaking hypothetically :-) ), I can just send it
back with the same tiny dialplan tweak.  
3 - In an unlikely double-failover scenario, I can leave all of my
legacy IVR trees etc intact on the legacy PBX.  If both Asterisk servers
are down, the customer is routed to the old system.  The customer may
wonder why they're hearing the OLD voiceover artist, instead of the NEW
voiceover artist but at least the call gets handled :-)

This is just another tool to consider.  I would be able to report in
more detail but at this time but it's a work in progress.  If anyone has
a RedFone solution in place and would care to report on (from the
trenches) I'd be interested in hearing your experience. 

-Karl