Multi-site, high availability SOP configuration
Topology
Let's assume:
- a main site with a redundant gateway and an active/standby SOP server and
- a remote site, connected via the corporate VPN network, with a standalone SOP server
- The solution described here is made of 5 SOPs:
- GW1 and GW2 are SOP with voice interface cards and implements VoIP gateways
- SOP1, SOP2 are applicative SOPs in active/standby mode. These SOPs must have been provisioned as a Master/Clone configuration by ESCAUX.
- SOP3 is a standalone applicative SOP
| Server |
Active IP |
Standby IP |
Type |
| GW1 |
192.168.144.21 |
NA |
standalone |
| GW2 |
192.168.144.22 |
NA |
standalone |
| SOP1 |
192.168.144.11 |
192.168.144.10 |
active |
| SOP2 |
192.168.144.11 |
192.168.144.12 |
standby |
| SOP3 |
192.168.140.11 |
NA |
standalone |
- The "Active IP" address and "Server Type" should be configured via "Advanced" > "System Management" > "Server Configuration"
- The "Standby IP" should be configured via "Advanced" > "System Management" > "Module Configuration" > "High Availability". Make sure the module is installed. If not, install it first.
As a result of the above configuration, SOP1 will be in active mode using IP address 192.168.144.11. SOP2 is in standby mode and therefor it is using IP address 192.168.144.12. In the event of a problem with the active server, the active-standby fail-over procedure (
Detailed procedure) will convert SOP1 into a standby server running on IP address 192.168.144.10 and SOP2 will become the active server running on IP address 192.168.144.11. All peripheral devices and applications communicating with the active server will not notice the difference since the production IP address remains on 192.168.144.11.
Interfaces
IAX Interface
The central point of our IP telephony network are the gateway servers (GW1 and GW2). We must now establish IAX trunks between all SOP servers and the gateway servers. Therefor the following IAX interfaces must be defined:
| Server |
IAX Interface |
From |
To |
| GW1 |
IIA10001 |
all |
|
| GW1 |
IOA10001 |
|
SOP1 |
| GW1 |
IOA10002 |
|
SOP3 |
| GW2 |
IIA10001 |
all |
|
| GW2 |
IOA10001 |
|
SOP1 |
| GW2 |
IOA10003 |
|
SOP3 |
| SOP1 |
IIA10001 |
all |
|
| SOP1 |
IOA10001 |
|
GW1 |
| SOP1 |
IOA10002 |
|
GW2 |
| SOP3 |
IIA10001 |
all |
|
| SOP3 |
IOA10001 |
|
GW1 |
| SOP3 |
IOA10002 |
|
GW2 |
For more information concerning the creation and definition of incoming and outgoing IAX interfaces, see ResourceIIA0 and ResourceIOA0.
PRI interfaces
In this topology, the PRI interfaces are located inside the gateways GW1 and GW2. Each gateway has a single PRI interface. Follow the configuration guidelines as explained in ResourceZOA1 and configure the following interfaces:
| Server |
IAX Interface |
| GW1 |
ZOA10001 |
| GW2 |
ZOA10001 |
If something is not working as expected, please consult IsdnDebugging.
Routing
In a topology with 2 PRI interfaces connected to an active/active gateway it is advisable to designate one gateway primarly for incoming calls and the other primarly for outgoing calls. In the event one of the gateways or PRI connections fails, the other takes care of both incoming and outgoing calls.
Incoming call routing
Before you begin:
-
This must be done before starting Step 1. If your DDI is 021112233, on GW1, define 1021112233 in the internal directory via 'Directory' > 'Internal Directory'. If you have a large amount of numbers to define, you can use Bulk Admin or LDAP.
The gateway routing occurs in 3 steps:
- Step 1: Accept the call to 02 111 22 33 in the incoming context, prefix by 10 to create a virtual internal extension and send to the internal context. This is done via 'Call Routing' > 'External Number Mapping'.
- Step 2: The call enters the internal context as 1021112233. We can now play a callflow to send the call either to a SOP server via an IAX trunk or to a locally connected fax machine. In order to make sure that the calls are sent to SOP1 via to the outgoing context, we define a callflow called Forward.netPBX1. This callflow simply consists of a Redirect towards 20${LastUserExt}. This means that we prefix by 20. We could also send the calls to SOP3 by using another callflow called Forward.netPBX3 and using 30${LastUserExt}
- Step 3: The call enters the outgoing context as 201021112233. In our routing table 'Call Routing' > 'Define Routes', we add a route called '_20.' which matches the number 201021112233 and we send it to SOP1 via the IOA10001 using the action Goto.INTERFACE. Before sending out the call we define that Goto.INTERFACE must strip the first 4 front digits. Hence when entering in SOP1, the number is seen again in its basic form, which is 21112233.
For reasons of redundancy the above configuration must also be applied on GW2. By asking your ISDN provider to send your incoming calls first to GW1 and try GW2 only when GW1 is down or saturated, one can guarantee full redundancy on incoming calls.
Outgoing call routing
The concept of outgoing call routing is much simpler.
- Step 1: on SOP1 define a default route '_X.' in route group 'DefaultOut' pointing towards IOA10002 and IOA10001 via the Goto.INTERFACE action. Please note that outgoing calls are first sent to GW2 and then to GW1. GW2 is the primary gateway for outgoing calls.
- Step 2: on GW1 and GW2 define a default route '_X.' in route group 'DefaultOut' pointing towards ZOA10001.
