Course Content - Advanced
Welcome to the online training series from 3CX. This module will take you through the configuration of Bridges in 3CX.
In this module, we will create a bridge between two 3CX PBXs. We will be configuring both the Master and Slave Bridges, using the Tunnel protocol.
We will see how the Bridge is used to make calls between extensions. We will see how a meshed setup is configured, to connect more than 2 PBXs together, and we will see how the presence information is shared between the PBXs across the Bridge.
Bridges traditionally connect two pieces of land. In 3CX, a Bridge will connect two remote PBXs.
A traditional bridge will have its two ends defined as geographical points, such as North/South, East/West. A 3CX Bridge will have its ends defined as Master and Slave.
A 3CX Bridge can also pass the traffic between the 2 PBXs via the tunnel protocol. This is referred to as a Tunneled Bridge.
The Master Bridge will control the connection between the 2 PBXs. It will listen for incoming connections from the Slave Bridge. If the connection is tunneled, it will listen on the PBX Tunnel Port, which by default, is 5090.
Creating a bridge in 3CX is very simple. From the “Bridges” page in the menu on the left hand side, click the “Add” button, and select “Add Master” from the drop down box.
The configuration page will ask for the Bridge name. This will be used to identify the Bridge in the Outbound Rules, as well as show the remote bridge name in the 3CX Windows and Web Client switchboards, to show the presence between the bridged PBXs.
The Virtual Extension Number will be used during the authentication process of the connection, when the Slave PBX will be connecting to the Master PBX, so it is important that the Virtual extension number is identical on both the PBXs on both ends of the bridge.
The Outbound Rule prefix is added to the bridge settings in order to facilitate the placement of calls from one PBX to another. This can be left blank, depending on your setup, for example if you have extension numbers in different ranges, on each PBX.
You can limit the number of calls going through the bridge, by defining the maximum number of calls. The number of calls placed through the bridge will count towards the licenses of both PBXs.
The authentication of the bridge consists of the password, and this is the password that the Slave will use to connect onto the Master. The bridge password can be changed, but if you do change it, please keep the password complex.
If the 3CX Tunnel protocol is going to be used to pass the traffic from one PBX to the other, check the “Remote PBX uses SBC/Tunnel Connection” option. The Remote PBX IP Address and Tunnel Port of the Slave PBX will need to be defined in the fields below.
The Slave Bridge PBX will be the PBX which initiates the registration attempts to the Master Bridge PBX. When the connection is tunneled, it will use the tunnel port to pass this traffic to the Master Bridge PBX. By default this port is 5090.
Similar to the creation of the Master Bridge PBX, the creation of a Slave Bridge PBX is very simple. When you click on “Add” however, choose “Add Slave”.
The configuration of the slave bridge parameters will be mainly identical to the Master PBX.
The Bridge Name however will be slightly different to reflect the name of the PBX which you will be connecting to.
The Virtual extension number will be identical to the Master PBX.
The outbound rule prefix is optional and can be added depending on the configuration of the extension numbers, just like in the Master Bridge PBX. This can also be left blank depending on your setup and if you have no overlapping extension number ranges.
The number of calls allowed to traverse the bridge will also be defined on the Slave PBX as well. Please note that if you have different numbers of calls allowed on the 2 bridges, the lower number will take effect. Calls traversing the bridge will also count towards your license usage on both PBXs.
In the Authentication section, you will need to put the same password as is also defined in the Master PBX. This password will be used to authenticate the slave to the master.
If you are using the tunnel protocol to connect the two PBXs together, enter the IP Address of the master PBX and its tunnel port, in the “Remote PBX” section.
You can easily check the connectivity status of the bridge from both the PBXs, by going to the “Bridges” page. A green dot next to the name of the remote PBX indicates an established connection. Red means the bridge is disconnected.
When the bridge connection has been established, the presence information between the 2 PBXs can be exchanged.
There is the option to “Publish” or send the presence information from the local PBX. Extension Group information will be sent across to the bridged PBX. This is available in ALL versions of 3CX.
The option to “Receive” the presence information from the remote bridge PBX is a Pro or Enterprise edition feature. Here, you choose which specific extensions will have the right to see the presence information for this connection, not entire extension groups.
The presence information for remote PBXs can only be viewed from 3CX clients as well as the 3CX Web client. Presence information is not transmitted through the BLF keys of IP Phones. IP Phones can only see the call status of local extensions.
The configuration of the presence is performed from the “Presence” tab of the bridge configuration.
In the “Publish Information” section, you will Add the Extension Groups you wish to publish the presence information for.
To receive the presence information from the remote PBX, you will need to have a PRO or Enterprise edition license.
In the “Receive Information” section, you will define the FQDN and HTTPS port of the remote PBX, to receive the presence. Please have in mind that the presence information will not traverse the bridge connection but will be flowing through the normal HTTPS route.
To receive the presence, you will then add the local extensions which you want to receive presence information. You can limit the number of extensions which can receive the presence. The viewing of presence information does not count towards the license count of the PBX.
Each remote system which is bridged to the local PBX will be shown in the presence screens of the 3CX client and Web Client, as a different header in the 3CX Client, or tab in the 3CX Web Client, and it is possible to see the presence of multiple bridged PBXs.
Let's go and see an example of a bridge configuration.
Let us assume that prior to the configuration of the bridge, the administrator had it in mind that there was a plan to connect two sites together and had a numbering plan put into effect.
The master bridge PBX is configured with 4 digit extensions in the 1000 range. The slave bridge PBX is configured with 4 digit extensions in the 2000 range.
The outbound rule required in the Master bridge to connect to the slave bridge would be just a prefix of 2, representing the 2000 range of extensions. In order to differentiate between the 4 digit extensions of the bridge, and any other external number starting with 2, we add the number length of 4 to the outbound rule.
Similarly, in the slave PBX, we would have the prefix of 1 in the Outbound Rule, with a digit length of 4, to represent the 1000 range of extensions.
With this type of setup, no outbound rule prefix is required in the Bridge Settings.
On the other hand, if both your PBXs have the same extension range, that is in the 1000 range for example, the outbound rules on both the PBXs will be similar to the scenario on screen now.
A prefix would be required in this case, for example 9. This could be any number.
A digit length of 5 would be required in this case, as the prefix will be detected as a digit. We will need to strip this prefix, however, as the remote PBX will not be in a position to recognise the prefix as part of a valid extension number.
In the outbound rule prefix in the bridge settings, a 9 would be required, assuming you have used 9 as the prefix.
Let’s have a look at a configuration of a fully meshed setup with 3 PBXs.
We will need to configure each of the connections between the 3 PBXs.
As we can see in this example, PBX A will be the Master Bridge in the connection between PBX A and PBX B.
PBX A will be the Master Bridge for the connection to PBX C as well.
PBX B will be the Master Bridge for the connection to PBX C.
We can see that PBX B is a Master Bridge for one connection, and a Slave Bridge in the other connection. This is entirely feasible and will not cause any problems. A PBX does not need to be a Master or Slave solely, but can be either or.
The numbering plans will be as follows:
PBX A will have extensions in the 1000 range.
PBX B will have extensions in the 2000 range.
PBX C will have extensions in the 3000 range.
The calls will be sent from one PBX to the other via the Outbound Rules.
We will configure an outbound rule for each PBX to contact its connected bridge PBX.
We will have a total of 6 outbound rules in this case.
PBX A will have an outbound rule to connect to PBX B, by defining a prefix of 2 and a length of 4 digits. No digits will be stripped in this case.
PBX A will also have an outbound rule to connect to PBX C, by defining a prefix of 3 and a length of 4 digits. No digits will be stripped in this case, neither.
PBX B will have an outbound rule to connect to PBX A, by defining a prefix of 1 and a length of 4 digits. No digits will be stripped in this case.
PBX B will also have an outbound rule to connect to PBX C, by defining a prefix of 3 and a length of 4 digits. No digits will be stripped in this case, neither.
PBX C will have an outbound rule to connect to PBX A, by defining a prefix of 1 and a length of 4 digits. No digits will be stripped in this case.
PBX C will also have an outbound rule to connect to PBX B, by defining a prefix of 2 and a length of 4 digits. No digits will be stripped in this case, neither.
You can also define a backup route to send the calls to PBX B through PBX A. All you need to do is define PBX A as Route 2.
With the 3CX Web Client, you are able to see the presence of remote extensions, if you have been given the access to do so.
By using the 3CX Web Client, you will be able to perform a variety of functions to interact with the extension as well.
Thank you, and goodbye!