Course13:IT Advanced 2 - 05 Master/Slave Operation

From innovaphone wiki
Jump to navigation Jump to search

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 fish-help.png Advanced - Distributed PBX and fish-help.png 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 screenshot.png multiple offices, the headquarters and some branch offices.

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 screenshot.png 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.

(Further Hints) 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.

(Further Hints) 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 screenshot.png 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





(Further Hints) In this course however, we'll make it simple and screenshot.png run one AP only (in the headquarters) smile

Preparation

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

(Further Hints) 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.invalid member reference '.domain' in 'domain'/invalid member reference '.domain' in 'domain'/devices/sysclients as Devices App URL
  • in the Devices App (in the Devices tab), add the IP811 to your domain (invalid member reference '.domain' in 'domain')

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 smile - 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 video2.png 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 invalid member reference '.domain' in 'domain' 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.invalid member reference '.domain' in 'domain'

(Further Hints) 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.invalid member reference '.domain' in 'domain'. 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!

(Further Hints) 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.invalid member reference '.domain' in 'domain'. 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 /invalid member reference '.domain' in 'domain'/reporting/cdr. User and Password must match what is configured in the Reporting App's PBX Manager plugin.

(Further Hints) Fortunately, you can steal all these values from Gateway/CDR0 on your master PBX smile 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.invalid member reference '.domain' in 'domain'/dc=entries?givenname,sn,company?sub?(metaSearchNumber=+%n)?bindname=apps.invalid member reference '.domain' in 'domain'\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 screenshot.png set as Password(LDAP) in the PBX manager plugin.

(Further Hints) 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 (0invalid member reference '.netccescape' in 'netccescape'invalid member reference '.netacescape' in 'netacescape', 0invalid member reference '.netacescape' in 'netacescape', 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 (invalid member reference '.netccext' in 'netccext',invalid member reference '.netrealacext' in 'netrealacext', ) for now

(Further Hints) 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


(Further Hints) 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

(Further Hints) 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 screenshot.png 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 screenshot.png IP Address in IP4/ETH0/IP on the IP411LEFT. In our case, this is invalid member reference '.network' in 'network'.2

(Further Hints) 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 smile

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.


(Further Hints) 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 screenshot.png 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.



(Further Hints) 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)
  • screenshot.png 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

     

(Further Hints) 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

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 screenshot.png a lot of objects there, then replication works fine.

However, if you only see the (pseudo) screenshot.png entry for _MASTER_, then your replication doesn't work. You can check the replication status
(Further Hints) One common reason for an issue here is that your master screenshot.png requires LDAPS in Services/LDAP/Server but you screenshot.png 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 screenshot.png see in PBX/Registrations, there are no phones registered with our new PBX.

(Further Hints) 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 screenshot.png new option, 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 screenshot.png shows a registration for both. Amazing, isn't it?


The physical location

Let's look at the screenshot.png registration information shown for Richard Roe:
invalid member reference '.network' in 'network'.5@hq*tls

The phone's IP address is obvious, the screenshot.png 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 screenshot.png Primary Gatekeeper 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.invalid member reference '.domain' in 'domain' 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.invalid member reference '.domain' in 'domain' as part of it's screenshot.png 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 invalid member reference '.domain' in 'domain' screenshot.png device configuration) because both phones are screenshot.png 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 screenshot.png Phone type device configuration which is identical to the existing invalid member reference '.domain' in 'domain' configuration except
    • the Description is invalid member reference '.domain' in 'domain' branch-b
    • the Categories list has branch-b IP Phone instead of hq IP Phone
    • the Primary gatekeeper must be branch-b.invalid member reference '.domain' in 'domain' instead of hq.invalid member reference '.domain' in 'domain'
    • the Gatekeeper ID is invalid member reference '.domain' in 'domain' (the same)
Now, Devices screenshot.png deploys different configurations to the IP phones in each location.

For aesthetic reasons, we also
  • screenshot.png rename the Phone type invalid member reference '.domain' in 'domain' configuration screenshot.png to invalid member reference '.domain' in 'domain' hq (to indicate that it is meant for hq only)

  • screenshot.png rename the IP811 in the Devices list to PBX - branch-b.invalid member reference '.domain' in 'domain'
If we now look at the screenshot.png 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.


Categories

We need separate categories (with check-mark Provisioning category for device configuration deployment set) if we want to apply different configuration settings. We have seen that for users to be registered with a slave PBX, different registration settings are needed. We have created both the category (branch-b IP Phone) and the respective device configuration (dvl-ckl2.net branch-b) for this.

(Further Hints) Generally, it is a good idea to create separate categories for each location right away.

Even if you do not use separate settings now, it is much easier later if you create them in the first place. Also, keep in mind that this also allows you to handle backups and firmware updates based on location later on.

So let us create the screenshot.png remaining location categories
  • branch-b Analog Phone
  • branch-b Fax Device
  • branch-b Gateway
Do not forget to tick the Provisioning category for device configuration deployment check-mark !

There is no need for a branch-b App Plattform category as we only have one AP and it sits in hq.

Of course, categories won't do any good if they are not assigned to devices. We have 2 phones (John's IP111 and Richard's IP222) and a PBX (the IP811)) in Branch B. We already changed the category of the phones. So

screenshot.png assign the category
  • branch-b Gateway to PBX - branch-b.invalid member reference '.domain' in 'domain' (your IP811)

     
     

What about branch-a?

If you recall our screenshot.png 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 screenshot.png categories for Branch A:
  • 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 screenshot.png 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 invalid member reference '.domain' in 'domain' 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 invalid member reference '.domain' in 'domain' 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 invalid member reference '.domain' in 'domain' Analog Phone branch-b
    • Categories branch-b Analog Phone
    • Primary gatekeeper branch-b.invalid member reference '.domain' in 'domain'
    • Gatekeeper ID invalid member reference '.domain' in 'domain'

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

  • Analog phone / fax invalid member reference '.domain' in 'domain' Fax Device

    The same is true for this configuration.
    So the only thing to do here is to rename it to invalid member reference '.domain' in 'domain' 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.

    (Further Hints) 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 invalid member reference '.domain' in 'domain' 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 invalid member reference '.network' in 'network'.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.

    (Further Hints) 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 invalid member reference '.domain' in 'domain' NTP hq and

    • create a new configuration NTP settings invalid member reference '.domain' in 'domain' 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 invalid member reference '.network' in 'network'.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 smile

    • Both branch-a IP Phone and branch-a Gateway must be added to the Categories list in NTP settings invalid member reference '.domain' in 'domain' NTP hq

  • Phone invalid member reference '.domain' in 'domain' 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 invalid member reference '.domain' in 'domain' 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:



(Further Hints) 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.

(Further Hints) 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.

(Further Hints) This function requires standby licenses in real life, for details regarding licensing, see link_intern.png 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 screenshot.png 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 invalid member reference '.domain' in 'domain' branch-b device configuration and
  • screenshot.png set the Secondary gatekeeper field to hq.invalid member reference '.domain' in 'domain' (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 screenshot.png 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 screenshot.png physical location for John and Richard 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 invalid member reference '.domain' in 'domain' branch-b device configuration
  • set the Gatekeeper ID to branch-b@invalid member reference '.domain' in 'domain'
    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 screenshot.png shown in red (ok, cause it's the standby registration), but the physical location is as it should be: branch-b.

Eh voilà smile



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 screenshot.png 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 screenshot.png trunk's SBC is run on a separate device (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).

(Further Hints) 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 smile

(Further Hints) 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 invalid member reference '.domain' in 'domain' hq device configuration on Devices so that branch-b.invalid member reference '.domain' in 'domain' is set as Secondary Gatekeeper

(Further Hints) 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 screenshot.png 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 screenshot.png 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

(Further Hints) 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.

(Further Hints) 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 screenshot.png Loopback from the PbxManager plugin) in the advanced UI. For that, we switch to the Trunk tab and set screenshot.png 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 screenshot.png complaint Duplicate Number.

(Further Hints) 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.

(Further Hints) 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 screenshot.png 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, screenshot.png the first Device (with same name) is always created (at least if you have set the Name property of the new object).

(Further Hints) 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!

(Further Hints) 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.invalid member reference '.domain' in 'domain'). 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
    (Further Hints) 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 (invalid member reference '.ip811mac_newmac' in 'sudevs.ip811mac_newmac' - branch-b.invalid member reference '.domain' in 'domain') 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
    +invalid member reference '.netccext' in 'netccext'


    invalid member reference '.netcnameext' in 'netcnameext'
    Connection type
    MSN




    Individual registration Yes




    Number mappings & credentials





    +invalid member reference '.netccext' in '<span class="label">netccext</span>'invalid member reference '.netrealacext' in '<span class="label">netrealacext</span>'invalid member reference '.netreale164ext' in '<span class="label">netreale164ext</span>'23 -> 0 MSNinvalid member reference '.netrealsiptrunkaccount' in 'netrealsiptrunkaccount'invalid member reference '.nete164ext' in 'nete164ext'23 pw123
    invalid member reference '.netcnameext' in 'netcnameext', invalid member reference '.nettownext' in 'nettownext'


    +invalid member reference '.netccext' in '<span class="label">netccext</span>'invalid member reference '.netrealacext' in '<span class="label">netrealacext</span>'invalid member reference '.netreale164ext' in '<span class="label">netreale164ext</span>'35 -> 13 MSNinvalid member reference '.netrealsiptrunkaccount' in 'netrealsiptrunkaccount'invalid member reference '.nete164ext' in 'nete164ext'35 pw123

    +invalid member reference '.netccext' in '<span class="label">netccext</span>'invalid member reference '.netrealacext' in '<span class="label">netrealacext</span>'invalid member reference '.netreale164ext' in '<span class="label">netreale164ext</span>'40 -> 14 MSNinvalid member reference '.netrealsiptrunkaccount' in 'netrealsiptrunkaccount'invalid member reference '.nete164ext' in 'nete164ext'40 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
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 screenshot.png 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 screenshot.png 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.invalid member reference '.domain' in 'domain' screenshot.png has been configured as Gatekeeper Address (primary) - which is exactly what we want.

(Further Hints) 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 (0invalid member reference '.netccescape' in 'netccescape'invalid member reference '.netacescape' in 'netacescape', 0invalid member reference '.netacescape' in 'netacescape', 0, invalid member reference '.netccext' in 'netccext',invalid member reference '.netrealacext' in 'netrealacext',) 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 screenshot.png defined in the Node tab of the PBX-type objects (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 - 0invalid member reference '.netccescape' in 'netccescape'invalid member reference '.netacescape' in 'netacescape'
  • National Prefix - 0invalid member reference '.netacescape' in 'netacescape'
  • Subscriber Prefix - 0
  • Area Code - invalid member reference '.netrealacextexplanationbracketsempty' in '</font><font face="courier new,courier,monospace"><font face="courier new,courier,monospace">netrealacextexplanationbracketsempty</font>'
  • Country Code - invalid member reference '.netccext' in 'netccext'
  • Subscriber - leave empty
(Further Hints) 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 screenshot.png 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.

(Further Hints) Our recommendation therefore is to screenshot.png 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 screenshot.png override the Dialing Location. You then need to assign Config User and its descendants to users screenshot.png depending on the trunk they are using.

In our pure V13 scenario, we can simply screenshot.png remove all settings in the Dialing Location area 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 invalid member reference '.domain' in 'domain' domain
  • click on Device configuration
  • edit Phone invalid member reference '.domain' in 'domain' hq
  • change the Gatekeeper ID from invalid member reference '.domain' in 'domain' to hq@invalid member reference '.domain' in 'domain'
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).

(Further Hints) 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

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 screenshot.png Gateway Calls and PBX Calls logging on the IP811
  • click on the screenshot.png syslog link on the same page (the page will now show all log messages in real-time)
  • call 0invalid member reference '.netacescape' in 'netacescape'invalid member reference '.netrealacext' in 'netrealacext'invalid member reference '.netreale164ext' in 'netreale164ext'11 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 invalid member reference '.netreale164ext' in '<span class="label">netreale164ext</span>'40 (which is the MSN we mapped to extension 14 on trunk-branch-b). We can verify this screenshot.png on the called phone (Edward's IP232)
When we call this MSN (invalid member reference '.netreale164ext' in '<span class="label">netreale164ext</span>'40) 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 screenshot.png appear at John's IP111
     

CDRs

To verify that both PBXs create CDRs for their calls,

Events, alarms and logs

Let is start with the logs.
To verify that log messages are sent from both PBXs
(Further Hints) Of course, this only works because we previously have screenshot.png turned on some logging flags in Maintenance/Logging on both boxes.
     
To check the alarms (and events) we can force a video2.png 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 screenshot.png registration on the PBX object branch-b is lost (note: failure detection can last up to 2 minutes).

When the fail-over is completed
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 screenshot.png 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
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 invalid member reference '.ip811mac_newmac' in 'sudevs.ip811mac_newmac'-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)
(Further Hints) Note that once the Expert Mode is turned on for an SBC, it can not be turned off again!
  • screenshot.png verify that Gatekeeper Address ... (primary) is set to branch-b.invalid member reference '.domain' in 'domain' (as this shall be the regular PBX)
  • set Gatekeeper Address ... (secondary) to hq.invalid member reference '.domain' in 'domain' (as this shall be the fail-over PBX)
  • set Gatekeeper ID to branch-b@invalid member reference '.domain' in 'domain' (as branch-b shall be the physical location in any case)
Now screenshot.png 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, screenshot.png trunk-branch-b is used - as we would expect.

(Further Hints) 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.