you can set-up multiple innovaphone devices to create a distributed, redundant PBX. Here is an introduction to these setups (which are known as master/slave configurations)

Introduction

So far, we have built innovaphone PBX systems based on a single PBX device. However there are scenarios where it makes sense to use multiple devices. Here are some of the reasons:

increased availability in case of device failure
PBX components are duplicated for redundancy (standby)
increased availability in case of network failure
PBX components are installed decentralized in a WAN-based scenario to make sure vital call functions are still available when the network fails (sometimes known as remote survivability)
increased scalability for larger systems
multiple PBX components create a uniform larger system that can handle more extensions than a single component (scalability)

To learn about all the options available, have a look at the

Advanced - Distributed PBX and

Advanced - E164 PBX Setups books in our wiki.

In this course however, we will setup a simple system where we have multiple locations where some of them have their own trunk lines.

The scenario

As said before, we'd like to support some phones and PCs in

multiple offices, the headquarters and some branch offices Screenshot: multiple offices, the headquarters and some branch offices - Course_Data/Master-Slave/scenario-branches.png

Screenshot: multiple offices, the headquarters and some branch offices - Course_Data/Master-Slave/scenario-branches.png

.

Numbering plan

Extension numbers are randomly spread over all locations and once in a while, users move from one location to another. This suggests a so-called flat numbering plan where there is no dependency between extension and location.

The PBX also supports structured numbering plans where some extensions (usually those in a certain location) share a common prefix (e.g. extensions in Branch office A have extensions 2x while extensions in Branch office B have extensions 3x). To have such subsets in the numbering plan, you would

create so called Nodes in the PBX, define a prefix (2 and 3 in our example) and assign extensions to them.

However, as we go for a flat numbering plan in our scenario, we only have a single node (which is by definition called the root node and does not need to be created explicitly).

Availability

Branch office A has been recently added and is near to the headquarters with IP fibre connection in-between. A network breakdown between the two locations is considered unlikely.

Branch office B however is remote and availability of telephony services must not depend on network availability. To make sure that this location stays fully functional even when the PBX in the headquarters is not available for whatever reason, we plan for a separate PBX device there.

Such a "sub-PBX" is known as Slave PBX. It will replicate all relevant data (such as users and extensions) from the main PBX (which is known as Master PBX) . All endpoints (phones and myApps clients) in the location are registered with this slave PBX.

A location that shall still be functional even if there is no connection to the main PBX needs to have a slave PBX installed.

Trunk lines

Branch office A - being closely connected to the headquarters - has no separate SIP trunk and hence no own E164 number. Extensions in this location are - if at all - mapped to the same public phone number range as extensions in the headquarters.

Branch office B however has its own SIP trunk and E.164 number though. Extensions in this location are mapped to this trunk's public phone number range. Although the system uses a flat numbering plan, the trunk access code (usually 0) shall always use the "local" trunk. This way, the calling line id for outgoing calls from this location always belongs to the respective trunk.

Whenever the "use local trunk" feature is needed in a location in a flat numbering plan, a slave PBX must be installed in each such location.

The SIP trunk - like all the users in this location - is registered with the slave PBX. This makes sure that it is available even when the master PBX is not.

All in all, we end up with

this simple setup:

a master PBX is installed in the headquarters
the endpoints in Branch office A are simply registered with the master PBX
the endpoints in Branch office B are registered with a slave PBX to provide availability and the local trunk logic
the two SIP trunks are registered with the master and slave respectively

And what about the App platform?

One of the reasons we installed a slave PBX in Branch office B was to enhance availability for telephony core functions. We still have one Application platform only as the users in the branch office can easily use the Apps provided by the App platform in the headquarters.

Obviously, enhanced availability in case of e.g. network failure could be desired for the additional services provided by the App platform too.

Although we will not address this in the course, here are some basic thoughts on how to do it:

you would install a separate Application platform in each location that requires enhanced availability
for each App you have the following options

run and use only one single App instance (probably in the headquarters' App platform). This for example is the option usually chosen for the Devices App
run separate instances of the App with distinct data and assign them to users according to their location. This is the right choice for the Messages App for example. It may or may not be a good choice for the Contacts App
run multiple instances of the App which partly share data. This might be a good choice for the Reporting App for example where you would send the PBX's call data to both your local instance (to have highly available call lists) and one central instance (to have system wide reports)
run multiple instances of the App which share all their data. The Users App would be an example

scenario-branches-with-net-trunks-and-aps

In this course however, we'll make it simple and

run one AP only (in the headquarters)

Preparation

Like the other topics before, this topic has a start config as well.

In this book, we will not need the DECT bases (neither IP1202A nor IP1202B). But we will need the IP222 again. So if you unplugged the IP222 from your switch, plug it in again (you may unplug the DECT bases to have a free port).

In any case, please load the start config

When your My Devices Page is OK (that is, all devices online),

you should add the IP811 which we will use in this topic to your Devices App so that you can reach it's advanced UI:

go to General / Devices-Registration
enter wss://apps.dvl-ckl2.net/dvl-ckl2.net/devices/sysclients as Devices App URL
in the Devices App (in the Devices tab), add the IP811 to your domain (dvl-ckl2.net)

Setting up a slave PBX

In this chapter, we will

install a slave PBX for branch-b
configure the users so they are located in hq, branch-a and branch-b
configure an additional trunk for branch-b

Adding branch-b's PBX to the system

Although the IP811 is part of the system, it is not yet configured as a PBX. This can't be done (yet) using the Install or the PBX manager plug-ins, so we need to use the Advanced UI. But don't be afraid, it's not that difficult

- and you can of course use Devices to access the IP811's advanced UI.

The first thing to do to turn the IP811 in to a slave PBX is to

set the PBX Mode to Slave

in PBX / Config / General.

Setting the "common" data

The page you see when you set the PBX Mode to Slave looks familiar (you've seen it before when setting up the master PBX). But there are some differences as we will see in a minute.

Some of the fields in this page must be set identical to the respective setting in the master PBX. Many more fields are usually set similar but do not need to be. And some of course are unique to a slave PBX and must be set accordingly.

So let's walk through all the settings and configure appropriate values:

System name and Use as Domain

must be set identical to the master PBX for all types of PBXs (Slave, Standby, Slave-Standby) in one system, so in our case,

it has to be dvl-ckl2.net and the check-mark must be ticked

PBX Name and DNS

must be unique in the system of course.

Set PBX Name to branch-b and DNS to (you guessed it) branch-b.dvl-ckl2.net

As usual, we recommend to use a PBX Name that syntactically also qualifies as a SIP-URI (or DNS name in this case). Therefore, while you could call the PBX "Branch A" as well, we do not recommend to do so. Best is to use a-z, 0-9, dot (., not as first character) and dash (-) only

moodle has already taken care of your DNS configuration and therefore created an entry for branch-b.dvl-ckl2.net. However, in real-life, you need to take care of this yourself. Otherwise, your slave PBX won't work

Unknown Registrations and With PBX Pwd only

this feature is obsolete anyway, so just don't tick any of them

Reverse Proxy Addresses and Assume TLS

these settings usually are set like on the master (although there are situations where it may differ). But we haven't discussed their meaning yet anyhow, so leave them empty as on the master PBX

IP address for App Platform, DNS and Operation without DNS

Assuming that our DNS system is already configured properly, we don't need these settings (you might recall that they are used so that you can configure your system with DNS names as recommended, although the DNS is not functional yet). So leave all of them empty and the check-mark unchecked.

Btw: you might want to check these settings on the IP411LEFT too, because they are not needed there likewise!

Music On Hold URL and External Music On Hold

The music on hold is usually set identical on all PBXs of a system. However, some customers for example play advertisements as part of their MoH and therefore want it to differ as per PBX. This is possible. During the course, we are using the built-in MoH most of the time, so simply leave both fields empty

Response Timeout, Dial Complete Timeout, No of Regs w/o Pwd., Security block time(s), Recall Timeout, Max Call Duration, Group Default Visibility, Presence with Alert, Enable External Transfer, No CLIR on internal calls

These setting are policy settings shared throughout the entire PBX system so that they are set identically on all PBXs. While you technically can set them differently it would be confusing probably for users.

You can leave almost all of them with the default settings.

However, you definitely should change the No of Regs w/o Pwd. from 1 to 0 (this default value is a legacy setting and not recommended any more). Furthermore please activate Enable External Transfer checkmark.

Media Relay and No Media Relay if Addresses are identical or private

These settings are pretty exotic. You should keep in mind that they are used only if you really know what you are doing! Turning on media-relay (in either of the available modes On and Automatic) comes with a cost (CPU and network bandwidth) and creates limitations (no video). So simply leave the settings as-is (mode Off and check-mark unchecked)

Generate CDRs

You want to generate call detail records for sure,

so make it a habit to always enable this!

Unfortunately, ticking this check-mark is not enough to send the CDRs to the Reports App. You also need to tell the box where to send the CDRs to!

This is done in Gateway/CDR0. You need to set the Log Server Type to HTTPS. The Address is the DNS name of your AP apps.dvl-ckl2.net. The Port can be left empty (so it uses the default 443). The Method is External (GET) (or External (POST) which is even slightly more preferrable) and the Path is /dvl-ckl2.net/reporting/cdr. User and Password must match what is configured in the Reporting App's PBX Manager plugin.

Fortunately, you can steal all these values from Gateway/CDR0 on your master PBX But beware, do not forget to save the settings in PBX/Config so far before you switch to the Gateway / CDR0 tab.

Reverse Lookup URL

This URL points towards the directory you use to perform number-to-name lookup. It is quite common to have that set differently on different PBXs of the same system, for example if you use location-specific Contacts App instances.

In our case, we use a single Contacts instance only,

so we use the same URL as for the master PBX: ldaps://apps.dvl-ckl2.net/dc=entries?givenname,sn,company?sub?(metaSearchNumber=+%n)?bindname=apps.dvl-ckl2.net\contacts. This is an URL for an LDAP access from the PBX to our Contacts instance (as the scheme ldaps:// easily tells you). So the password required to authenticate towards Contacts is the one you have set as Password(LDAP) in the PBX manager plugin.

If you do not recall it, you can reveal it with the Display check-mark.

Route Root-Node External Calls to, Route PBX-Node External Calls to, Route Internal Calls to, Escape Dialtone from, Adjust LDAP results for e.164 and Tones

These are really special settings, so better don't touch. They should be empty on your master PBX too

Prefix for Intl/Ntl/Subscriber

As we don't know our trunk data yet, we set these like on the master (000, 00, 0 ) for now

Country Code/Area Code/Subscriber

As we discussed for our scenario, we aim at using a separate trunk line for the users in Branch A. Therefore, most likely, some of these values (for sure Subscriber, probably Area-Code and perhaps Country-Code) will differ from the settings in the master PBX.

As we don't know our trunk data yet, we set these like on the master (49,621, ) for now

You may wonder why Subscriber is empty. This is because the Install doesn't set this value anyway (as opposed to Country Code and Area Code which it does set) and it doesn't strictly need to be set. You would only set this option if you have a PBX using a local DDI trunk and a myApps user is calling a full e164 number of an internal contact. Such a call should not be forwarded to your PSTN provider.

Log Calls

It's always a good idea to check this to enable ad-hoc debugging of call-routing related issues

Don't forget to save all the settings with the OK button. This might require a reset.

All the settings we have discussed so far also appear the same way for each type of PBX (master, slave, standby). If you think it's difficult to recall what to set how, then here is the

simple rule-of-thumb: In most cases, you set all these fields exactly as you did on the master PBX, except for

PBX Name and DNS. Must always be set unique in the whole system
Reverse Lookup URL if you use a different Contacts instance for the slave
Area-Code/Country-Code if you use a different trunk in the location served by the slave PBX
Do not forget to set Gateway/CDR0 (and possibly Gateway/CDR1)

Setting the "Slave PBX" data

The

settings in the Slave PBX section are special to slaves and can therefore not be "stolen" from the master PBX.

So let's walk through all of them and see, how they must be set:

Registration

This is the protocol used by the slave PBX to connect to the master PBX. This connection is used to receive calls from and send calls to the master PBX. We recommend to always use H.323/TLS, as this is encrypted and hence secure

Master

This is the IP address of the master PBX. You can find it as IP Address in IP4/ETH0/IP on the IP411LEFT. In our case, this is 172.31.31.2

Note that it is not possible to use a DNS name here!

Alternate Master

This is the IP address of a PBX that can be connected should the master fail (also known as Standby PBX). We don't have a redundant master PBX in our setup, so we leave this field empty

Password

This is the password the slave PBX shall use to authenticate to the master PBX. Later on, we will actually create sort of an "account" for the slave PBX in the master PBX. For now, we just put the password here that we will be defining then. As always in the course, we use ip411 here. In real life however, .... Ok, you already know this

Master GK-ID

This field is optional and only required when the System name of the master PBX differs from the System name of the slave. This is a rare case, so we can leave it empty

Replication and use TLS

This is an interesting field. In almost all cases, you want all PBX objects (those configured in PBX/Config/Objects) such as e.g. users to be known in all PBXs (simply to be able to call all of them to begin with). This is why a slave PBX would want to synchronize its own object database with the database in the master PBX. This is known as "replication". Having said that, we set the replication mode to All and tick the use TLS check-mark

Route Master calls if no Master to

This enables a mechanism to route calls which should be sent to the master (e.g. calls to other branches) when the master is not available. This is an advanced setting and you should leave it empty

Max Calls to Master and No Reroute

This is a mechanism to limit the number of calls sent to the master (e.g. calls to other branches). This may be useful when the bandwidth is limited. Nowadays, this is rarely used and you should leave both fields empty

License Limits

Most licenses are stored on the master PBX and distributed to slave PBXs on-demand. These fields allow you to set a maximum license usage for a slave PBX so that a single location can not accidentally consume all available licenses. In normal, single-customer PBX systems, this is rarely used so we can leave all of the fields empty

License Only

We skipped this option above (next to the Master field) as it relates more to the License Limits field. As said above, licenses are stored in the master PBX and distributed to the slave PBXs. It is however even possible, to set up a master PBX where other master PBXs connect to, solely for the purpose of acquiring licenses. The topmost master PBX is known as license master and the master PBXs connecting to the license master are configured as slave PBX but in License Only mode. This is quite neat for a service provider who serves a number of customers (with independent PBXs) which obtain their licenses from the license master.

Don't forget to save all the data (which again may require a reset)

Setting the "PBX Password"

A few minutes before, we spoke about the "Replication". This is when the slave PBX synchronizes all the objects known in the master PBX into its own object database. When we look what we have as objects in PBX/Object however, we see an

error message.

Sensitive data in the object database (most notably passwords) are encrypted using a secret known as the PBX password. This password needs to be set in PBX/Config/Security on each PBX - and it must be set identically in all PBXs that replicate from the master PBX.

Set the PBX password to what has been set as PBX password in the master PBX (this should be ip411 as always in this course)

More basic settings

There are some more "basic" PBX settings in the Authentication and myApps tabs under PBX/Config (the myPBX tab contains legacy settings not relevant in v13).

Copy all settings in the Authentication and myApps tabs from your master PBX to the new slave PBX.

The settings under PBX/Config/Filter are replicated from the master automatically, so you don't need to edit them. You should however have a look at the following settings:

Filter/IP-Filter (registration with authentication)

If you limit registrations to a PBX by network, then you probably need to check the network address and mask here so that it reflects the network configuration in the branch served by the slave (if you wonder why IP-Filter (registration without authentication) is not mentioned - you should not use or allow registrations without authentication anyway)

Making the slave known to the master

Our new PBX now is more or less fully configured as a slave PBX.

Unfortunately, it is not yet known to the master PBX and therefore any attempt to connect fails. To change this, we need to create a so-called PBX type object on the master PBX.

To introduce the new slave PBX to the system

switch to PBX/Objects in the master PBX (IP411LEFT)
select PBX from the drop-down menu and
create a new PBX object by clicking on new

Let's see what's in the two tabs (General and Node) in the popup window opened and set all the fields properly:

Long name and Name are the identification of the slave PBX. Name needs to be set to the PBX Name we have set in PBX/Config/General on the IP811. In our case, this is branch-b.
While you could set the Long Name to an arbitrary name, we recommend to set it the same as there is no benefit in setting it differently and it might even be confusing
Every PBX for technical reasons needs a Number. You will rarely or never use it, so the only thing you need to make sure is that this number does not pollute your numbering space. So we recommend to assign something "strange", such as **2 as Number (remember, in telephone, 0 - 9, # and * are considered "digits"). The Install has already assigned **1 to the headquarter's hq PBX object, so it makes sense to keep that style for further PBXs
You could mark the new object as Critical. However, this is a legacy method to limit administrative access which is rarely used nowadays. So just leave it alone
As discussed before, we are creating a flat numbering plan where all objects live in the (only) root node. This is why we need to set the Parent Node to root
The Parent PBX however is the PBX where a slave PBX registers with. In almost all cases, all slave PBXs will register with the master PBX. Therefore, the Parent PBX must be set to the name of the master PBX (which is hq)
Setting Hide from LDAP makes sense, as you can not meaningfully call a PBX number so the PBX should not appear in LDAP search results
The Password is the password that the slave PBX uses to authenticate to the master PBX. You may recall from chapter Setting the "Slave PBX" data above that we have set this to ip411 (simply cause we always use this password throughout the course - in real life however, you know, do you?)
Busy on ... Call(s) is the counterpart to Max Calls to Master which we also discussed in chapter Setting the "Slave PBX" data above.Again, this is rarely used nowadays and we therefore leave it empty as we did with Max Calls to Master
Reporting is a setting that allows calls to a slave destination to be listed in the Reports App. This only rarely makes sense, so you usually leave this unchecked
Reverse Proxy is a setting you need when the slave PBX connects to the master PBX from the internet. We will discuss in a later topic, so simply leave it unchecked so far

Summary: to create a PBX type object for a slave

set both Long Name and Name to the PBX name of the slave PBX
set Parent Node to root
set Parent PBX to the name of the master PBX
set Password to the password you configured for the slave PBX in PBX/General/Slave PBX/Password

Slave registration

Now that the slave PBX is known to the master PBX, it should be able to register successfully.

We can verify this

on the master PBX in the PBX/Objects list which shows the slave's DNS name and IP address
on the slave PBX in the PBX/Config/General page which shows the master's DNS name and IP address

Replication

Now that you have set all basic PBX settings, it should replicate all objects from the master PBX. You can see that easily under PBX/Objects/show. If you see

a lot of objects there, then replication works fine.

However, if you only see the (pseudo)

entry for _MASTER_, then your replication doesn't work. You can check the replication status

on the slave in Services/LDAP/Rep-Status
on the master in Services/LDAP/Srv-Status

One common reason for an issue here is that your master

requires LDAPS in Services/LDAP/Server but you

did not check the use TLS check-mark under PBX/Config/General.

Setting up the phones to register with the slave PBX

So now we have a nice little slave PBX. Fair enough.

We certainly want some of our users (those located in the new location) to register with the new slave PBX. But as we can

see in PBX/Registrations, there are no phones registered with our new PBX.

Of course, for registrations to take place, valid Port licenses are required on the PBX. Before, we said that licenses are obtained from the master PBX. While this is true, it does not apply to the "virtual wild-card licenses" provided by the PBX test mode.

So make sure that you turn on the test mode in General/License on the IP811!

But even then, there are no phone registrations on the slave PBX. Well, not that surprising - we need to define who's where. In other words, we need to tell our system which user shall be served by which PBX. This is done by the PBX selection in the General tab of an user object. Here we now see a

new option Screenshot: new option - Course_Data/Master-Slave/pbx-object-pbx.png

, the branch-b slave PBX.

Change the settings for John Doe and Richard Roe so that they register with the slave PBX branch-b.

As soon as you have done this, John's IP111 and Richard's IP222 should register with the slave PBX instead of the master PBX. You can verify this by looking at PBX/Objects/show on the IP811. The last column now

shows a registration for both. Amazing, isn't it?

The physical location

Let's look at the

registration information shown for Richard Roe:

172.31.31.5@hq*tls

The phone's IP address is obvious, the

tooltip reveals the meaning of both the asterisk (*) and the at (@):

the phone has authenticated itself via TLS (*tls)
it has the physical location hq (@hq)

The physical location is the name of the PBX where the phone's registrations has been sent to first. If this is the PBX configured as registration PBX in the User object, then the physical location is identical to the registration PBX. However, if it is sent to the wrong PBX first (as is the case for both John Doe and Richard Roe now as their phone's

Primary Gatekeeper Screenshot: Primary Gatekeeper - Course_Data/Master-Slave/ip232-primarygatekeeper.png

still points to the master PBX), then

the registration is rejected by the PBX along with a hint where the registration should be re-tried. In our case, the master PBX will send the DNS name of the slave PBX branch-b.dvl-ckl2.net as hint
the endpoint uses the hint to register with the right PBX, along with the information that and where the registration was tried first (hq in our case)
the registration PBX would accept the registration but note that the phone has a foreign physical location

Remember that the Devices App still configures all the phones to register with hq.dvl-ckl2.net as part of it's

Phone configuration settings. This is why both phones have a physical location which is not their registration PBX.

A physical location allows to route calls depending on where they originate from (the physical location of the caller).

Recall that we wanted to set-up a dedicated trunk line in both locations (and we will do so in a few minutes). The trunk access code shall be 0 of course in both locations. The physical location is what the PBX takes into account to resolve this ambiguity and decide which trunk to route the call to.

Fixing the physical location

Ok, now we know why the physical location is wrong for John Doe and Richard Roe: their phones are sending the registration to the wrong PBX initially. From there, they are redirected to the slave PBX which is fine but the wrong physical location remains.

This configuration (where to send the registration to) is done by the Devices App (as part of the Phone dvl-ckl2.net

device configuration) because both phones are

still in the hq IP Phone category, which is used for device configuration.

So to fix it, we must

create a new category branch-b IP Phone, usable as Provisioning category for device configuration deployment
change the IP111's and IP222's category from hq IP Phone to branch-b IP Phone
create a new Phone type device configuration which is identical to the existing dvl-ckl2.net configuration except

the Description is dvl-ckl2.net branch-b
the Categories list has branch-b IP Phone instead of hq IP Phone
the Primary gatekeeper must be branch-b.dvl-ckl2.net instead of hq.dvl-ckl2.net
the Gatekeeper ID is dvl-ckl2.net (the same)

Now, Devices

deploys different configurations to the IP phones in each location.

For aesthetic reasons, we also

rename the Phone type dvl-ckl2.net configuration to dvl-ckl2.net hq (to indicate that it is meant for hq only)
rename the IP811 in the Devices list to PBX - branch-b.dvl-ckl2.net

If we now look at the

PBX/Objects/show listing of John Doe and Richard Roe, we see that there is no @hq any more, which means that the physical location is the registration PBX itself.

More on device configurations

As we have seen, it makes sense to have separate Devices categories and configurations for separate branches. So let's see what more we have to configure in Devices.

What about branch-a?

If you recall our

intended scenario, we also plan for a Branch A location. So far, we ignored it as we said that there won't be an extra slave PBX in this location.

So, does it make sense to create separate categories for branch-A too?

The general answer is: usually yes. As said before, this also allows you to handle backups and firmware updates based on location. Of course, if you're sure you won't need them, you don't have to.

But as it's easy enough, let's quickly create the

categories for Branch A Screenshot: categories for Branch A - Course_Data/Master-Slave/devices-branchacategories.png

:

branch-a IP Phone
branch-a Analog Phone
branch-a Fax Device
branch-a Gateway

Again, do not forget to tick the Provisioning category for device configuration deployment check-mark!

Of course, categories won't do any good if they are not assigned to devices. We only have phones in branch A, so we need to decide which one will be there. Let's use Jane's IP112 for this. Having said that,

assign

the category:

branch-a IP Phone for Christoph-IP112 (which should be Jane's IP112)

That's it as we don't have more devices in Branch A.

Device configurations

We have created a bunch of new categories and assigned them to the appropriate devices. Also, we have created a new device configuration called branch-b IP Phone. to make sure the phones register with the slave PBX.

Is there anything else that we need to change in the device configurations?

Well, so far we have not seen any need for any further different configuration. So there is currently no need to create a respective configuration. However, we have changed the provisioning category for some devices (namely the phones in Branch A and Branch B) as well as for the slave PBX in Branch B.

As Devices applies its configurations to devices based on their category, we need to make sure the existing device configurations also are applied to the devices we had changed the categories of (or, more precisely, to their respective device categories).

To check, we walk through all existing configurations and check to which categories they are applied:

Alarm Server Global

The settings here (where to send alarms and events) do not need to be changed, as we still have only one event server (the Events App service instance).
Also, we do not need to change the categories the configuration is applied to as the Apply to all devices check-mark is ticked
Analog phone / fax dvl-ckl2.net Analog Phone

This configuration must be applied to analog interfaces in the headquarters. There is no need to change it, except that the name is a bit misleading now.
So let's rename it to dvl-ckl2.net Analog Phone hq.

But what about analog phones in Branch A? Well, we don't have them but if we would, then we would use the same configuration as in the headquarters (as we do not have a separate PBX for this location).
So what we do here is to add the branch-a Analog Phone category to it.

And what about analog phones in Branch B? Well, we don't have them either but if we would, then we would use a different configuration (as we do have a separate PBX for this location). So once we have analog phones in Branch B, we need to create a separate configuration with

Description dvl-ckl2.net Analog Phone branch-b
Categories branch-b Analog Phone
Primary gatekeeper branch-b.dvl-ckl2.net
Gatekeeper ID dvl-ckl2.net

Until then, we're lazy and don't care though

Analog phone / fax dvl-ckl2.net Fax Device

The same is true for this configuration.
So the only thing to do here is to rename it to dvl-ckl2.net Fax Device hq and to add the branch-a Fax Device category
Media Global

Like for the alarm server setting, we don't need to change anything here. Again the Apply to all devices check-mark is ticked, so it will be applied to all devices anyway.

However, note that as opposed to the alarm server configuration, where we could have a different alarm server, it is very unlikely for the media configuration to be different in a location. To understand this, let us quickly look at the settings

The STUN server anyway needs to be a globally accessible resource in the internet (probably provided by your ISP), so there is rarely a situation where you would want to use a different one in a location
The TURN server must to be shared by all endpoints in your installation (except you are using public TURN servers but this is a rare case and will happen mostly if you use a cloud PBX hosted by a provider). We will discuss this in-depth in a later topic
TOS priority - RTP data, TOS priority - signaling, First UDP-RTP port and First UDP-NAT port need to be set consistently with your routing and firewall infrastructure. Again it is very unlikely that it has to be set differently in locations (as your network administrator probably likes to keep it simple and uniform therefore)

NTP settings dvl-ckl2.net NTP

The NTP settings indeed are a good candidate for being changed when you introduce new locations. This is simply because you usually use a local NTP server to keep away load from the public NTP servers. In our setup, we use our own internet router (the IP411RIGHT 172.31.31.1). So if the new location has its own internet router, then we need to create a new setting and assign the appropriate categories to it.

Another good reason for a location-specific NTP configuration is the Timezone string as the new location may live in a different time zone.

In our little training network however, we do not have separate networks with separate internet access. So in our case, when we create the new configuration, we must use the same NTP server nevertheless

So we

rename the existing configuration to NTP settings dvl-ckl2.net NTP hq and
create a new configuration NTP settings dvl-ckl2.net NTP branch-b and
We apply this new configuration to categories branch-b Gateway and branch-b IP Phone. Again, if we would have an AP in Branch B, we would also assign branch-b App Platform
set the proper Time server (which is 172.31.31.1 in our case and identical to the one used in hq)

And what about devices in Branch A? Very good indeed you mention it

Both branch-a IP Phone and branch-a Gateway must be added to the Categories list in NTP settings dvl-ckl2.net NTP hq

Phone dvl-ckl2.net branch-b

This was the configuration we already created when we fixed the physical location for the phones. So there is nothing we need to do here
Phone dvl-ckl2.net hq

By now, you should have an idea what to do with this configuration?!

Yes, you're right, we need to

add category branch-a IP Phone so it is applied for phones in Branch A as well

Once we have done all this, we end up with a new set of configurations:

See that Devices has applied its configurations to the right devices automatically. This always happens as soon as a configuration was touched (in fact, changing the name is enough to trigger it, so you can safely try it out with a changed name if you like).

Master/slave redundancy

Now that we have a slave PBX in Branch B, users in this location are still operational when the network link to the headquarters breaks down. Not too bad!

However, in the introduction of this book, we also said that "increased availability in case of device failure" is one of our goals to use multiple PBX devices. Does that mean that users in Branch B are still operational when our IP811 fails?

Why not try it out?

Unplug the IP811 from your switch (simulating a failure)
try a call from Jane Doe to 14 (John Doe)
You will hear nothing and after a while (around 15s) the call times out with a channel not available or channel not free message

Obviously we are still missing some important configuration settings to make the increased availability work!

Setting up the phones to use a standby PBX

Here's the trick.

A master PBX can take over registrations for a slave PBX if the slave PBX is not registered to the master PBX. The slave PBX, when it is operational and network connection is OK, will maintain a registration to the master PBX. When the slave PBX fails (or the network breaks down), the master PBX will accept registrations even though the PBX setting in the respective User object is for the slave.

This function requires standby licenses in real life, for details regarding licensing, see

innovaphone Licensing Guidelines V13r1 - EN, chapter 3.2 Standby License

It takes a while for a PBX to discover a lost registration.

To see if the situation recovers

have a medium coffee (about 4 minutes, you already had a coffee) and wait until branch-b's registration to hq is gone
repeat the call
Unfortunately, the result is almost similar: no call. But there is no timeout, you get the error message immediately. So the difference is: the system now knows that you can't call branch-b (and the IP111 shows no registration state)

If the master PBX shall accept the registrations for the two phones in Branch B (John Doe and Richard Roe), then obviously these phones need to send their registration there (when sending it to the "right" PBX fails). This is what the Secondary Gatekeeper property in the phone's Phone/User-1/General tab is for. This the place where we need to put the DNS name of our master PBX into.

Of course, we don't fix that in each phone individually but let Devices do it for us.

For this, we

edit the Phone dvl-ckl2.net branch-b device configuration and
set the Secondary gatekeeper field to hq.dvl-ckl2.net (the DNS name of our master PBX)
wait a bit (a second medium coffee may or may not be a good idea)

Very soon, both the IP111 and IP222 will

show that they are registered again and a call from Jane to John (14) rings at the IP111.

Fixing the physical location again

Looks good, doesn't it?

Well.... let's see what the

physical location for John and Richard Screenshot: physical location for John and Richard - Course_Data/Master-Slave/pbx-master-standby-physloc-wrong.png

Screenshot: physical location for John and Richard - Course_Data/Master-Slave/pbx-master-standby-physloc-wrong.png

is (btw: note the red color indicating the standby registration).

There is no location, so they are treated like the users in the headquarters.

This is because there was no redirection, the phone did send the registration directly to the master PBX (although using the Secondary Gatekeeper field). This is easily fixed by adding the location information to the phone registration.

To do so

edit the Phone dvl-ckl2.net branch-b device configuration
set the Gatekeeper ID to branch-b@dvl-ckl2.net
As you can see, the physical location is prefixed to the PBX's System Name with an @ as separator
wait some time until John and Richard's phones are registered again

Now they are still

shown in red Screenshot: shown in red - Course_Data/Master-Slave/pbx-master-standby-physloc-good.png

(ok, cause it's the standby registration), but the physical location is as it should be: branch-b.

Eh voilà

We can now plug our IP811 in to the switch again. What happens then is

the box boots up
the slave PBX starts
it registers with the master PBX
the master PBX unregisters all phones with a standby registration for branch-b (we see the not-registered-screen on the phone for a moment)
the phones will restart their registration which succeeds at the Secondary Gatekeeper (the slave PBX)

Do we always need to fix the physical location for the standby case?

We've seen how to make sure the physical location is still set to the slave PBX even though this PBX is down.

However, this doesn't need to be done always. In fact, there are many cases where you even don't want this.

Consider our

little setup. The SIP trunk SBC will run (we haven't configured it yet) on the slave PBX in Branch B. In this case, when the slave PBX fails, the SBC will fail too, obviously. For this reason, it doesn't make sense to try to use the branch's trunk and therefore it's perfectly OK when all Branch B users change their physical location to the master PBX in the failover case.

However, there are also scenarios where the

trunk's SBC is run on a separate device Screenshot: trunk's SBC is run on a separate device - Course_Data/Master-Slave/scenario-branches-with-net-trunks-sbc-separate.png

Screenshot: trunk's SBC is run on a separate device - Course_Data/Master-Slave/scenario-branches-with-net-trunks-sbc-separate.png

(probably located in a DMZ - this is actually the scenario we recommend to use). In this case, when the slave PBX fails, the SBC is still available and therefore it makes sense to still use it for outgoing calls. For this to happen, the physical location needs to remain at the slave PBX (branch-b).

Of course, the SBC in the DMZ would also need to be configured to use the master PBX as Secondary Gatekeeper!

You know how to configure both solutions, so the choice is up to you

Given the setup in this course, it makes sense to use the master's physical location in case of a failure. In the last step, we configured the failover so that the slave-PBX's physical location is used. However, to save time, you don't need to remove the configuration we did in the last step.

Redundancy for the master PBX

The same works for the master PBX too.

To provide redundancy for the master PBX, we can use the slave PBX. To do so, the only thing we need to do is to

change the Phone dvl-ckl2.net hq device configuration on Devices so that branch-b.dvl-ckl2.net is set as Secondary Gatekeeper

This type of cross-over redundancy only works for a master and a single slave. When there are multiple slave PBXs, then you need to setup a standby PBX for the master PBX (that is, a PBX in

mode Standby). Such a PBX is a complete duplicate of a master PBX and is setup much like a slave PBX, except that it does not need an extra PBX-type object in the PBX.

In a

multi-slave scenario,

a standby PBX for the master PBX needs to be created
all slave PBXs have the master PBX as Primary Gatekeeper
all slave PBXs have the standby PBX as Secondary Gatekeeper
all endpoints (e.g. phones) which register to the master PBX have the standby PBX as Secondary Gatekeeper
all endpoints (e.g. phones) which register to one of the slave PBXs have the master PBX as Secondary Gatekeeper

The Trunk

Now that we have a slave PBX and some users on it, let's see how to configure Branch B's trunk line.

Let's review what needs to be done to configure an outside line:

A PBX Trunk Line object must be created
one or more SBC SIP interfaces must be configured
interface maps and routing between SIP interfaces and PBX must be defined

For trunks on the master PBX, all these steps are performed by the Trunks PbxManager plugin.

Our trunk differs in some ways though:

it needs to register with the slave PBX, not the master PBX
So we need to set some special properties which the plugin does not
it's access number (0) shadows the master trunk's access number (also 0)
So we need to arrange that a dialled 0 on the slave PBX is routed differently from a 0 dialled on the master PBX

We'll go through this in the next sub-chapters.

Creating the Trunk object

There are a few issues we need to deal with when setting up a Trunk type PBX object for the slave's trunk line. The first step is the creation of the object in the first place.

We have seen that a slave PBX replicates all the PBX objects from the master PBX. New objects created on the master are duplicated on the slave PBX and also changes are replicated back and forth between master and slave PBX. So far, so good. But

Objects can not be created nor deleted on a slave PBX

This is a restriction inherent to the replication mechanism used.

You can easily experience this yourself

open the slave PBX's PBX/Objects advanced UI
select Trunk Line from the drop-down
click on new
in the popup form, set Long Name and Name to trunk-branch-b
click on OK

Even when you refresh the object list, the new object isn't there. Likewise, when you try to Delete an object, it will not be gone.

PBX objects must be created and deleted on the master PBX

To create the object successfully, we need to

open the master PBX's PBX/Objects advanced UI
select Trunk Line from the drop-down
click on new
set Long Name and Name to trunk-branch-b
For the time being, please do not set a Number (leave it empty)
set the PBX property to branch-b (as we want this trunk to register on the slave PBX)
While we are at that, we can also set the switchboard handling (known as Loopback from the PbxManager plugin) in the advanced UI. For that, we switch to the Trunk tab and set Loopback / Number to 12. Note that we set a user on the master PBX (Jane Doe) as switchboard handling for the trunk in the slave PBX
click on OK

Making an object "local"

In the previous step, we have left the Number property of the new trunk empty. Of course, this is not good - we need a trunk access number obviously. And it should be 0 like it is for the existing trunk.

But when we try to set the Number property of the new trunk to 0, we see the

complaint Duplicate Number.

Objects cannot have duplicate numbers generally!

The reason is pretty obvious: if this would be allowed, the system could not resolve the dialled number to one specific target.

How to fix the numbering conflict

If we think about it, we certainly do not want the trunk access code for the two trunks to be ambiguous. We just want it to be resolved differently depending on who is calling to it. More precisely, we want users with physical location branch-b to resolve 0 to trunk-branch-b. Users in hq shall resolve it to the existing trunk.

This can be achieved by moving the object in to a new namespace (well, in fact, a new numbering space). In the innovaphone PBX system, such a numbering space is known as a node. Objects in distinct nodes can have identical Number attributes.

We can try this right away

open the trunk-branch-b object
set Number to 0
open the Node dropdown and select branch-b
save the object

This time the object is saved with no complaint.

Let us look a bit at the Node dropdown: it has choices branch-b, hq and root. This is because each existing PBX implicitly creates a node (branch-b and hq in our case). Also, there is also a node called root where usually all objects (i.e. users) live in.

Overlaying numbering spaces

So are we there, now that our configuration was saved?

Not really. To understand this, let us look at how nodes influence number resolution.

When the system resolves a target number for an object (e.g. because a user has dialled a number) then it will search for an object with that number in the same node as the calling user.

So far, we have configured the new trunk so that users also living in the branch-b node would call this trunk when dialling 0. However, there are no users in these nodes. In fact, the only object in the branch-b node is the new trunk.

Moving the slave PBX users (John Doe and Richard Roe) in to the branch-b node would help. However, master PBX users and slave PBX users wouldn't be able to call each other using their extension any more (as they now live in separate numbering spaces). So this is not a solution.

To fix that, there is the concept of overlaying a numbering space (that is, node) for users whose physical location is set to this numbering space (node). In other words, such objects in node branch-b overlay the objects in the root node for users whose physical location is branch-b. This exactly what we were after!

In fact, this overlay is not done for all objects in a node. Instead it is turned on "per object" by

ticking the Local check-mark in that object.

To finish the configuration of the new trunk for Branch B, we therefore need to

open the trunk-branch-b object
tick the Local check-mark

Some final cleanup

While we are at the trunk configuration dialog, we can cleanup a setting that has been done implicitly by the advanced UI. When creating a new object with the advanced UI,

the first Device (with same name) is always created (at least if you have set the Name property of the new object).

This is done for historic reasons (and still done for upward compatibility). You should always take care to remove the default Device entry!

So clear out this Device entry by removing the Hardware Id and save the object.

Creating the SIP interface

We have progressed a bit, but there are still a few things to do:

configure the SIP interface(s)
set the interface maps correctly, and
do the routing between SIP interface(s) and PBX

Fortunately, now that we have set up the PBX Trunk-type object correctly, the Trunks PbxManager plugin can do the rest. Lucky us!

Before you continue, make sure you are logged in to myApps with an account that is configured to register with the slave PBX (that is, the PBX property is set to branch-b.dvl-ckl2.net). john.doe should be configured like that

We will see later on why this is important.

In the PbxManager Trunks plugin

edit the existing trunk trunk-branch-b
This entry exists because we manually added the Trunk Line type PBX object trunk-branch-b before
click Add to add an SBC
select the IP811 (009033410004 - branch-b.dvl-ckl2.net) as we want the SIP interface on the gateway where the slave PBX runs (so that it still works if the master PBX fails)

configure the SBC according to the following properties

Interface/SBC	SBC
	Default SIP Trunk
Country code	+49				Germany
Connection type	MSN
Individual registration	Yes
Number mappings & credentials
	+4962134282323	-> 0	MSN49.621.34282323	pw123	Germany, Mannheim
	+4962134282335	-> 13	MSN49.621.34282335	pw123
	+4962134282340	-> 14	MSN49.621.34282340	pw123
Setup
Disable	turn off
Protocol	TCP
Domain	siptrunk.class.local
Proxy	leave empty
Media-Relay	turn on

Checking provider state

When the new SIP trunk is configured, we see

the SIP interface configured for trunk-branch-b (009033410004-SIP1) is registered with the IP811
it is also registered with the SIP trunk provider

You may ask yourself why SIP2 and SIP3 are not registered to the PBX?

SIP2 and SIP3 only exist because we specified Individual registration Yes when we created the SBC. This indicates that each MSN requires a separate registration to the SIP provider. So the plugin creates 3 SIP interface and all of them register to the SIP provider. Towards the PBX however, only one registration per trunk is required. Calls between the PBX and the SIP2 and SIP3 interfaces

use SIP1's registration.

And what about the admin user's registration PBX?

Above we said make sure you are logged in to myApps with an account that is configured to register with the slave PBX and promised to explain this later in more depth. So here we go!

We have seen that SIP1

registers with the slave PBX and also is not redirected there from the master PBX (otherwise we would see a different physical location). This is because branch-b.dvl-ckl2.net

has been configured as Gatekeeper Address (primary) - which is exactly what we want.

The PbxManager Trunks plugin will always set the admin users's registration PBX as primary gatekeeper to register with.

Fixing the PBX prefixes

When we created the base configuration for the new PBX we have set the Prefix for Intl/Ntl/Subscriber/Area-Code/Country-Code just like we did on the master PBX (000, 00, 0, 49,621,) as we did not know the new trunk properties yet.

Now that we have configured it, it is time to set the correct prefixes for the slave PBX. In fact, these prefix properties are set per node. In fact, the settings in PBX/Config/General are those valid for the root node. This is why we always enter the master PBX's trunk prefixes here (that is, on the master as well as on all slaves). So we do not need to change anything, cause we already did it right in the first place.

The prefixes valid for other nodes are

defined in the Node tab of the PBX-type objects Screenshot: defined in the Node tab of the PBX-type objects - Course_Data/Master-Slave/pbx-slave-prefixes.png

Screenshot: defined in the Node tab of the PBX-type objects - Course_Data/Master-Slave/pbx-slave-prefixes.png

(and Node-type objects which we do not cover in this course however).

Define the prefixes for the slave PBX in the branch-b PBX object:

International Prefix - 000
National Prefix - 00
Subscriber Prefix - 0
Area Code -
Country Code - 49
Subscriber - leave empty

Don't be misleaded: in our training setup, both trunks are located in the same area, so all properties are set equal in the root and branch-b node. You nevertheless must specify them in the PBX object.

Fixing the dialing location in the "Config User" template

For backward compatibility, the Install creates a

Dialing Location as part of the Config User template object.

These setting were used in V12 and before to facilitate directory lookup and number normalization in various contexts. In V13, they are still used in some situations but they do conflict with the prefix settings found in PBX/Config/General and in the Node/PBX objects.

Our recommendation therefore is to

remove these settings from the Config User template object in a fresh V13 installation.

Note however that myPBX still makes use (and requires) those settings! So if you still run myPBX or if you upgraded a V12 installation to V13, instead of removing the Dialing Location from the template, you should create new templates which inherit from Config User and

override the Dialing Location. You then need to assign Config User and its descendants to users

depending on the trunk they are using.

In our pure V13 scenario, we can simply

remove all settings in the Dialing Location area Screenshot: remove all settings in the Dialing Location area - Course_Data/Master-Slave/pbx-master-configuser-dl-emptied.png

Screenshot: remove all settings in the Dialing Location area - Course_Data/Master-Slave/pbx-master-configuser-dl-emptied.png

of the Config User template object.

Fixing hq's trunk to be "local" too

Now that we have set up the branch's trunk, we should also configure the original hq trunk (trunk) the same way.

To set up the original trunk (that is, the trunk for hq) to be local too:

open the trunk object in a PBX
change the node attribute from root to hq
tick the Local check-mark

Now this is the object where all calls to 0 are routed to for users whose physical location is the master pbx.

The last step is to make sure all phones registered to the master PBX always have hq as physical location:

Like we did before for the phones in branch-b, the steps are

open the Devices app
click on the dvl-ckl2.net domain
click on Device configuration
edit Phone dvl-ckl2.net hq
change the Gatekeeper ID from dvl-ckl2.net to hq@dvl-ckl2.net

This also has the effect that the trunk can be reached explicitly by calling **10 (the same as trunk-branch-b which can be reached by calling **20).

A local object can be reached explicitly by dialing the Number of its Parent PBX object followed by its extension.

Master/slave redundancy for the trunks

What happens to the trunk in the aforementioned fail-over scenario?

Let's assume branch-b's SIP interface is implemented on the same box as the slave PBX is. When the slave PBX fails, the SIP trunk is gone too (as it runs on the same - failing - box) most likely.

In this case, all registrations for the branch-b users will be accepted by the master PBX. But still, no trunk is available.

We can fix that easily by setting a CFNR towards the fail-over trunk. In our little scenario, we would like trunk-branch-b to take over for trunk and vice versa.

To implement mutual trunk fail-over

set a CFNR to trunk (**10) on trunk-branch-b
set a CFNR to trunk-branch-b (**20) on trunk

Mutual trunk failover
Screenshot: Mutual trunk failover - Course_Data/Master-Slave/pbx-master-trunk-failover-cfnrs.png

Some Testing

Now that we have set up the system, we can do some trials.

The expectation is that,

outgoing external calls are routed to the respective local trunk
incoming external calls are mapped to extensions according to the dialled MSN (for Branch B's trunk, the headquarters trunk has DDI)
CDRs are sent from both PBXs to the Reporting App
Events, Alarms and Logs are sent from both platforms (IP811 and IP411LEFT) to the respective Apps
phones in Branch B register to the headquarter's PBX when the slave PBX fails
outgoing calls for Branch B users are sent through the headquarter's trunk when the slave PBX fails

External calls

To see how an external call placed by a user in Branch B is routed

turn on Gateway Calls and PBX Calls logging on the IP811
click on the syslog link on the same page (the page will now show all log messages in real-time)
call 0062134282311 from John Doe's IP111 (you can also do this using the hq IP Phone IP111 App in myApps)

Our expectation would be that

the call is routed to trunk-branch-b
We can verify that on the logging page:

20201003-151510 PBX0 1 John Doe(14:john.doe) setup-> (0062134282311)
20201003-151510 PBX0 3 trunk-branch-b() peer-> John Doe(14:john.doe)
20201003-151510 PBX0 3 trunk-branch-b(0062134282311) <-setup John Doe(14:john.doe)
20201003-151510 CALL 0 Alloc
20201003-151510 CALL 0 A:Call -> / RS1::->*::
20201003-151510 CALL 0 B:Call 14:john.doe@dvl-ckl2.net->062134282311 / RS1:14:->TONE:062134282311:
20201003-151510 PBX0 3 trunk-branch-b(0062134282311) call-proc-> John Doe(14:john.doe)
20201003-151510 PBX0 1 John Doe(14:john.doe) <-call-proc (0062134282311)
20201003-151510 CALL 0 B:Rel 14:john.doe@dvl-ckl2.net->062134282311 / RS1:14:->TONE:062134282311: Cause: Resources unavailable, unspecified
20201003-151510 CALL 0 B:Call 004962134282340:john.doe@dvl-ckl2.net->062134282311 / RS1:14:->SIP3:062134282311:
20201003-151511 CALL 0 B:Alert 004962134282340:john.doe@dvl-ckl2.net->062134282311 / RS1:14:->SIP3:062134282311:
20201003-151511 PBX0 3 trunk-branch-b(0062134282311) alert-> John Doe(14:john.doe)
20201003-151511 PBX0 1 John Doe(14:john.doe) peer-> (0062134282311)
20201003-151511 PBX0 1 John Doe(14:john.doe) <-alert (0062134282311)
the CGPN 14 (John's extension) is mapped to 34282340 (which is the MSN we mapped to extension 14 on trunk-branch-b). We can verify this on the called phone (Edward's IP232)

When we call this MSN (34282340) the expectation is that

it is mapped to 14 vice versa: we can test this by calling back from Edward's IP232. The call must appear at John's IP111

CDRs

To verify that both PBXs create CDRs for their calls,

we first need to assign Reporting licenses to users on both PBXs. This is easily done by assigning the license to the Config User template object so that it is inherited by all the user
then repeat the call from John to Edward. We should see entries for both of them in the Reporting app now (you need to click on Show results in the lower left edge for this)

Events, alarms and logs

Let is start with the logs.

To verify that log messages are sent from both PBXs

start the Logging app
repeat the call from John to Edward
you should see log entries from both the IP411LEFT and the IP811

Of course, this only works because we previously have

turned on some logging flags in Maintenance/Logging on both boxes.

To check the alarms (and events) we can force a

trunk registration failure

edit the Trunk Line object trunk
modify the Hardware Id so that the trunk's registration will fail
verify that an alarm from the IP411LEFT is shown
do the same for the Trunk Line object trunk-branch-b

Failover

To test the fail-over from the slave to the master

unplug the network cable from the IP811, simulating a slave failure

In this case, both the slave PBX and the slave's SIP trunk fail (as both run on the same box our IP811).

Failure is detected on the master PBX when the

registration on the PBX object branch-b is lost (note: failure detection can last up to 2 minutes).

When the fail-over is completed

the slave PBX is not shown as registered in the master PBX any more
all the IP phones are registered with the master, Richard Roe and John Doe are shown in red (indicating a fail-over registration)

To check if the fail-over works according to the expectations:

call from John (physical location branch-b) to Jane (physical location hq) and vice versa
-> Users configured for the failed slave PBX can still call and can be reached
call from John to 0112
-> Users configured for the failed slave PBX which normally use the trunk on branch-b (trunk-branch-b) have still access to a trunk line (which is the headquarters trunk), you can verify this looking at the IP411LEFT's syslog with PBX Calls ticked)

PBX-only failover

An interesting variation of the previous scenario is when only the slave PBX fails but not branch-b's SIP trunk. This can happen if the branch's SBC is implemented on a separate box (e.g. because it is placed in a DMZ there).

To simulate this situation

plug in the Ethernet cable to your IP811 again
set the PBX Mode in PBX/Config/General to OFF (do not forget to click on OK)

Now, the slave PBX fails but the SIP trunk does not. Again, all the phones now register with the master PBX. But what about trunk-branch-b? Shouldn't we expect it to also register with the master PBX as fail-over?

Indeed, however, it won't. This is because we haven't done the Secondary Gatekeeper configuration yet as we have done for the phones (do you recall where we have configured this?).

Unfortunately, its not that straight forward how to accomplish this. As there is no Device configuration for SIP trunks in the Devices app (as for the phones), we somehow would need to do it in the Trunks PbxManager plugin. However, this option is not available there.

So we need to do it using the advanced UI in Gateway/SIP/SIP1 on the IP811. But we can't as here the SIP interfaces configured using the PbxManager plugin is in read-only mode.

To modify the SIP interface

edit trunk-branch-b in the Trunks PbxManager plugin
click on the SBC with Hardware ID 009033410004-SIP1
scroll down and tick the Expert Mode check-mark
open the SIP1 configuration using the advanced UI in Gateway/SIP/SIP1 on the IP811 (it is now writeable)

Note that once the Expert Mode is turned on for an SBC, it can not be turned off again!

verify that Gatekeeper Address ... (primary) is set to branch-b.dvl-ckl2.net (as this shall be the regular PBX)
set Gatekeeper Address ... (secondary) to hq.dvl-ckl2.net (as this shall be the fail-over PBX)
set Gatekeeper ID to branch-b@dvl-ckl2.net (as branch-b shall be the physical location in any case)

Now

both trunks will register with the master PBX (like the phones do). (Further Hints)

You may need to disable/enable the SIP interface to force a quick re-registration

When you now repeat the call from John to 0112, it will succeed. But this time,

trunk-branch-b is used - as we would expect.

The setting of Gatekeeper Address ... (primary) done by the Trunks PbxManager plugin depends on which PBX the myApps session runs. In other words: the admin user's PBX is used as primary gatekeeper. This is why it is important which user is used to start the PbxManager.

Please set the PBX Mode on your IP811 back to Slave because we need a working slave PBX for the next book.

Course13:IT Advanced 2 - 05 Master/Slave Operation