Courseware:IT Plus - Multiple Trunks
Jump to navigation
Jump to search
How to set up a PBX with multiple Trunks and address each trunk seperatly.
Start
In the third exercise of this topic, we will discuss a scenario in which user objects from different locations should be merged into a single PBX. This means that each user will be located on the master PBX in the root node, but external calls will still be routed to different local trunks.
To enter your myApps client please enter hq-dvl-ckl2.training.innovaphone.com and use ckl and ip411 to log in.
Scenario description
As explained in the previous chapter, there is only one PBX in this scenario. Previously, users John, Jane, Richard, and you were located on different PBXs. Now, they are all users of the master PBX and are located in the root node, meaning they can call each other without dialing a prefix or area code. They should still be able to use the local trunk they used before the locations were merged to a single PBX.
The initial configuration includes four SIP interfaces to simulate the scenario. These interfaces are registered in different German cities on our PSTN simulation, which is hosted on the IP811. Your IP232 is also registered with the PSTN simulation.
Create locations
As first task we will create the PBX tree consisting of 
PBX objects for our fictitious locations that do not exist.
PBX objects for our fictitious locations that do not exist.
that do not exist.
- Long Name:
stuttgart , Name:stuttgart , Number:**711 , Parent Node:root , Parent PBX:hq - Long Name:
leipzig , Name:leipzig , Number:**341 , Parent Node:root , Parent PBX:hq - Long Name:
hannover , Name:hannover Number:**511 , Parent Node:root , Parent PBX:hq - Long Name:
hamburg , Name:hamburg Number:**40 , Parent Node:root , Parent PBX:hq
Create trunk objects for those locations
As a next step let's create a trunk object in each location and register the appropriate SIP interface internally to the trunk object.
Create the following four Trunk objects on our master PBX (IP411LEFT) using the advanced UI this time. Now you can register your SIP Interfaces internally with H.323/TLS . You just have to enter the primary gatekeeper hq-dvl-ckl2.training.innovaphone.com
Create the following four Trunk objects on our master PBX (IP411LEFT) using the advanced UI this time.
using the advanced UI this time.- Name and Long Name:
trunk-stuttgart
Number:0 ,
Node:stuttgart
PBX:hq
Hardware Id:0090334000b3-SIP1 trunk-leipzig ,0 ,leipzig ,hq ,0090334000b3-SIP2 trunk-hannover ,0 ,hannover ,hq ,0090334000b3-SIP3 trunk-hamburg ,0 ,hamburg ,hq ,0090334000b3-SIP4
Now you can register your SIP Interfaces internally with After a successful registration of the trunk, you can already make inbound and outbound calls. Unfortunately, if John (IP111) dials 00511271 (national number) or 00049511271 (international number), he will not be able to reach IP232 (Triton).
This is because John currently resides in the root node. To go down one node to Stuttgart, where the trunk is located, he would need to dial the Stuttgart prefix. If he dials **71100511271, however, the call will work. This obviously can't be the final solution because it would be too complicated for users to dial.
On a side note, inbound calls from Triton to John work, as call 07111234514 from Triton enters node Stuttgart. Since no appropriate number is found, the call travels one node up to the root node where John Doe's user object is found.
Use physical location
To solve the issue, we will use the concept of physical locations. In a multi-PBX scenario, if a PBX other than the registration PBX (e.g., Stuttgart) receives the phone's registration request, that PBX will forward the request to the registration PBX and inform it that the request was received by that PBX first. This information is called the physical location. At this point, the assumption is that the phone is at a different location than where it was supposed to register.
To configure the solution we will create 3 categories in our Devices app. Please enable the check mark Provisioning category for device configuration deployment for all of them. 
We don't need a category for softphone users like you. We will discuss softphones later in the book.
The next step is to create Phone individual device configurations for all three locations. Depending on the phone's location, please set the following options: Please note that the Gatekeeper ID is essential for this configuration. The syntax is <physical-location>@<gatekeeper-ID>. The @ symbol acts as a separator. This is how we apply physical locations to phones. Although we register all phones to the same PBX (hq-dvl-ckl2.training.innovaphone.com), this method allows us to declare that they reside in different locations.
To deploy the new configuration, change the respective provisioning categories for your phones: Note that as a device can have a single provisioning category only, you need to remove the existing one first.
We can assign a physical location to a phone without the need of a PBX that redirects the registration request. Consequently, the PBX will be informed of the phone's physical location when it sends the registration request directly.
You might wonder what the benefit is of the PBX knowing the physical location. In our scenario, the PBX takes this information into account when routing calls to trunk objects. If the physical location matches an object's PBX attribute and the first digit of the CDPN is 0, the trunk line that matches is used to route the call to the correct SIP interface.
To configure the solution we will create 3 categories in our Devices app. Please enable the check mark 
in our Devices app. Please enable the check mark Stuttgart IP Phone Leipzig IP Phone Hannover IP Phone
We don't need a category for softphone users like you. We will discuss softphones later in the book. The next step is to create individual device configurations for all three locations. Depending on the phone's location, please set the following options:
for all three locations. Depending on the phone's location, please set the following options:- Description:
dvl-ckl2.net Stuttgart /dvl-ckl2.net Leipzig /dvl-ckl2.net Hannover - Categories:
Stuttgart IP Phone /Leipzig IP Phone /Hannover IP Phone - Primary gateekper:
hq-dvl-ckl2.training.innovaphone.com - Gatekeeper ID:
stuttgart@dvl-ckl2.net /leipzig@dvl-ckl2.net /hannover@dvl-ckl2.net
Please note that the Gatekeeper ID is essential for this configuration. The syntax is <physical-location>@<gatekeeper-ID>. The @ symbol acts as a separator. This is how we apply physical locations to phones. Although we register all phones to the same PBX (hq-dvl-ckl2.training.innovaphone.com), this method allows us to declare that they reside in different locations. To deploy the new configuration, change the respective provisioning categories for your phones:- IP111:
Stuttgart IP Phone - IP112:
Leipzig IP Phone - IP222:
Hannover IP Phone - IP232: stays in the PSTN, so there is no change
Note that as a device can have a single provisioning category only, you need to remove the existing one first. Now, take a look at the registration information for your users. For example, John Doe.
the registration information for your users. For example, John Doe.
for your users. For example, John Doe.This registration contains:172.31.31.4@stuttgart*tls
- The phone's IP address (172.31.31.4)
- The physical location (@stuttgart)
- the phone has authenticated itself via TLS (*tls)
Before we can test the configuration, there is still one step missing to complete our configuration.
Marking trunks as local
We talked about the problem before. When the system determines a target number for an object (e.g., when a user dials a number), it searches for an object with that number in the same node as the calling user. This means, when John tries to call the PSTN phone Triton, he would dial either 00511271 or 00049511271. At the moment no matching trunk object(which has the number 0) is found because the root node doesn't contain any.
Set the Local flag on all of our 4 trunk objects.
Open the Gateway/Calls tab on your IP411LEFT. Then, call 00511271 or00049511271 one after another from John (IP111), Jane (IP112), and Richard (IP222). You will see that each call passes through the local SIP trunk of the city.
To fix this, we can create an overlaying numbering space for local objects. Therefore, tick the "Local" checkbox in an object, such as a trunk object. As a result, a calling user with a physical location will search for matching objects inside the PBX location node that matches their physical location first.
"Local" checkbox in an object, such as a trunk object. As a result, a calling user with a physical location will search for matching objects inside the PBX location node that matches their physical location first.![](https://class.innovaphone.com/moodle2/file.php/1836/Course_Data%5Cmultiple-trunks%5Clocal-trunk-object.png "Screenshot: "Local" checkbox in an object, such as a trunk object. - Course_Data\multiple-trunks\local-trunk-object.png")
As a result, a calling user with a physical location will search for matching objects inside the PBX location node that matches their physical location first. Set the Local flag on all of our 4 trunk objects. Open the Gateway/Calls tab on your IP411LEFT. Then, call 
on your IP411LEFT. Then, call Physical location on softphones
You can also set the physical location for softphones. This can be done on the myApps launcher or directly in the browser.
In the myApps launcher, you need to set as server parameter.You can use either of these variations.
In the browser, you need to set add the physical location to the URL. There are two ways to do this:
Please start your myApps client with the physical location of Hamburg. Next, start your softphone and select an audio device.Finally, check your user object in the PBX. You will see that the physical location is part of your softphone's registration information. The physical location is applied just as it would be for a hard phone.
your softphone's registration information. The physical location is applied just as it would be for a hard phone.
The physical location is applied just as it would be for a hard phone.Please check Gateway/Calls once again. Calls to 00511271 or 00049511271 are routed through SIP4.
are routed through SIP4.
No physical location
If you go to PBX/Config/myApps, you will find an option called No physical location, which is used for all softphones on this PBX. When this option is enabled, the PBX ignores any manually configured physical location parameter.
This setting becomes particularly interesting in a multi-PBX scenario. Imagine you have a master and a slave PBX. If you enter a PBX address (via the launcher or browser) that does not match the PBX location of your user object, you will automatically be redirected to the PBX that matches your location attribute.
-
If you are redirected and this option is enabled, the physical location will be set to the PBX that matches your location attribute.
-
If you are redirected and this option is disabled, the physical location will remain as the PBX you initially accessed, before the redirection occurred.
Central trunk forwarding based on subnets
There is also an entirely different solution that works without physical locations. You can decide which solution better fits your customers' requirements.
Furthermore, we must create the following mappings in the Mappings tab. The destination of each map is the node number, followed by the external line number, which is always 0 for our trunk objects.
This configuration (using full IP addresses) is a bit special due to our test setup. In real life you would certainly configure a network range.
In order to test the configuration, you need to remove the physical location of your devices, as callers will find local objects matching with their physical location before finding objects in their own node when searching for a number (0 in this case). To do so, you can either use an appropriate device configuration category in Devices or you can remove the Local flags from your trunk lines.
This solution uses a number map object to forward calls to the correct trunk object based on the caller's IP subnet.
with the following parameters:- Name and Long Name:
central-trunk - Number:
0 - Node:
root - PBX:
hq
Furthermore, we must create the following mappings in the Mappings tab. The destination of each map is the node number, followed by the external line number, which is always 0 for our trunk objects.
The destination of each map is the node number, followed by the external line number, which is always 0 for our trunk objects.| <your PC IP address> |
This configuration (using full IP addresses) is a bit special due to our test setup. In real life you would certainly configure a network range. In order to test the configuration, you need to remove the physical location of your devices, as callers will find local objects matching with their physical location before finding objects in their own node when searching for a number (0 in this case). To do so, you can either use an appropriate device configuration category in Devices or you can remove the Local flags from your trunk lines. Now call 00511271 or 00049511271 from John, Jane, Richard or your softphone. The call will always use the correct SIP interface, which you can view in the Gateway/Calls section.