Course11:Advanced - E164 PBX Setups
This books is about setting up a PBX system which partly emulates the worldwide PSTN E.164 numbering plan.
What is "E.164"?
For our purposes, the most interesting thing is that the term E.164 loosely refers to complete numbers, instead of extensions only. In most scenarios, we set up the PBX with a (flat or structured) numbering plan, which is specific for the PBX system. That is, we define extensions in nodes and the structure of the numbering plan is defined by the system (that is, the customer). More about this can be found in the book on
While this is great, some customers - especially when migrating to VoIP - ask for a numbering plan that closely resembles the numbering plan they had before installing a networked PBX. In other words, they are used to call people in remote locations by just dialling their regular PSTN numbers. In innovaphone speak, this is called an E164 numbering plan.
This book is about how to set up such a scheme.
This book requires a solid understanding of the PBX's node tree and PBX tree scheme. It is thus strongly recommended that you first complete the Distributed PBX topic before you start this one.
The Node Tree
However, the calling procedure in the PSTN is quite different from the calling procedure in a standard PBX node tree (see chapter Number Resolution in the
In an E.164 scheme however, the dialling procedure is different. If a called number is not in the current node, then it will not be found. Moving the search scope to the next higher node is not done implicitly, but explicitly by dialling a specific digit string, known as escape. Often but not necessarily, 0 is used as escape digit string.
For example, from within a PBX node, if a 0 is dialled, the scope moves up one node from the subscriber node to the area code node. Another 0 will move it up to the country code node. Yet another 0 will move it up to the root node. From there, a dialled country code (e.g. 43) moves it down to the respective country code node (e.g. Austria), a dialled area code (e.g. 1) to the respective area code node (e.g. Vienna) and finally a dialled subscriber number (e.g. 4711) to a subscriber number node. All trailing digits are then used to select the extension within the target PBX. So, dialling 000431471199 from a phone in HQ Sindelfingen will call to extension 99 in Office Vienna. Sounds familiar, I guess .
It should be noted that the PBX node is what is called a Subscriber Number node in the drawing.
As we can see, in addition to the
There is no need to configure the whole world's numbering plan though. You only need to configure all nodes from the root down to the actual locations (that is, to the location PBX's subscriber numbers). Here is a an example for a real-life node tree.
2-level Numbering Plans
First of all, escape prefixes can vary. After all, this is why you have to configure them.
A bit more surprising is that some countries do not have an area code level. Let us look at Italy as an example. If a user with an extension in a PBX in Verona wants to call the mayor of Rome, he would call 0 (to get an outside line) followed by 060606 (the mayors subscriber number). This is 0060606 which looks like as if 0 gets an outside line (correct), then another 0 moves to the national level (wrong), 60 is the area code of Rome (wrong) and 606 is the mayor's subscriber number (also wrong). This would look familiar to an Austrian or German user.
We would expect that if another citizen of Rome calls his mayor (from within a PBX), he needs to dial 0 (outside line) 606 (mayors subscriber number). But not so! In fact, he needs to dial 0 (outside line) 060606 (mayor's subscriber number) - which is exactly what the Verona user needs to dial. Although Italian numbers tend to look like a 3-level numbering plan, it is not, and all subscriber numbers reside directly in the Italy country node.
One surprising side effect of this is, that if you call the mayor of Rome from Sindelfingen HQ, the correct number to dial is 0 00 39 06 0606. For users accustomed to a 3-level numbering plan, this looks as if the 0 after the 39 needs to be removed as it seems to be the escape code to get to the national level (so the expected number would be 0 00 39 6 0606). But not so. As there are no area codes really, this 0 is part of the subscriber number and thus needs to be dialled even from the international level.
No big deal if you take care to configure the tree correctly.
Inconsistant 3-level Dialling
You could be tempted to think this is just like in Italy (see previous chapter), where there is no area code level and all subscriber numbers sit directly underneath the country node.
However, this is not the case. As we have seen before, when someone calls Rome's mayor from Sindelfingen, then he needs to dial 0 00 39 06 0606. This is because the 0 in 3906 is actually not an escape, but part of the subscriber number and the dial plan is 2-level only in Italy. In the "inconsistant" case however, the dial plan in fact is 3-level. However, the PSTN forces all users to always use national (or international) numbers, even if they reside in the same area code.
In such a situation unfortunately, when a user calls a destination in the same area code but using a national number (instead of just calling the subscriber number), the PBX will determine that the called number is in fact too complicated and will remove the supposedly superfluous extra digits.
We have been notified that Switzerland has such a behaviour. So let us assume a user in Zurich wants to call his mayor (who has the number +41 44 412 31 20). 41 is the country code for Switzerland, 44 is (one of) the area code(s) for Zurich, 412 31 20 is the mayors subscriber number. As discussed before, the user must call 0 044 412 31 20 (assuming he is in a PBX with a 0 escape). Looking at the node tree, the PBX will determine that the destination is in the Zurich node just like the caller is. It will thus optimize the called number to 0 412 31 20. However, this is not allowed, as it is not a national number. So the call will fail.
You could be tempted to think, Ok, then let's do it like in Italy, simply put all subscriber nodes just underneath the Swiss' country node and include the initial 0 within the subscriber number. This would indeed fix the national calls. However, calls from foreign countries would then be forced to include this 0 between the country code and the subscriber number (so that a foreign caller needs to call e.g. 0 0041 044 412 31 20 instead of 0 0041 44 412 31 20).
How to fix it
You configure a 3-level numbering plan as usual. Then, on all trunk lines, you configure interface maps to fix the calling line ids to the national format. Furthermore, you will need some routing maps to adjust the called number to the national format.
Lets look at the example above again:
So let us assume a user in Zurich wants to call his mayor (who has the number +41 44 412 31 20). 41 is the country code for Switzerland, 44 is (one of) the area code(s) for Zurich, 412 31 20 is the mayors subscriber number. As discussed before, the user must call 0 044 412 31 20 (assuming he is in a PBX with a 0 escape).
The drawback of this solution is that local area PSTN calls will be displayed in local area format on the phone.
If the user is called by the mayor of Zurich (CGPN 0 044 412 31 20), the PBX will determine that the caller is in the same area code as the called party is and will this shorten the calling party number to 04123120. While this is in a sense "correct", it will be confusing to the user receiving the call, as he is used to receive the callers id in the national format, e.g. 00444123120.
Starting with v10 SR3, a new option Not to be called fixes this issue. It can be activated at a Node or PBX object. In our example, it would be activated at the subscriber node (which is the called party's PBX object). If the caller and callee have the same parent node (that is, the same area code node) and the called node is marked as Not to be called, the number and escape of the parent node is added to the CGPN of the caller.
If we look again at our example from the last paragraph, our user called by the mayor of Zurich would now see as CGPN the national number 00444123120 instead of 04123120.
MSNs
Single MSN
If the PBX has a single MSN only, it is still easy: you define this MSN as the PBX object and then need to take care of the situation that a call to this MSN results to a call with an empty called party number within this PBX (see Incomplete in
For on-net calls to this PBX, you can now even use DDI to the extensions. For off-net calls you need to provide a proper incomplete map.
For off-net calls out of this PBX (through the local trunk e.g.), you may need to cut off internal extension from the CGPN sent.
Multiple MSNs
As a PBX object cannot have more than one Number property, you can not define more than one MSN for a single PBX.
To work around, you can create MAP objects for the additional MSNs of the same PBX which map the MSNs to the "primary" MSN (the one used for the PBX object), potentially with some extension added. This takes care of on-net calls to the various MSNs.
For off-net calls to this PBX, the various MSNs must be handled by interface or routing maps applied to the incoming CDPN.
In both cases (on-net and off-net calls), the CGPN for outgoing calls will always be the "primary" MSN. For off-net calls you can create routing maps which map the CGPN to one of the MSNs.
Issues
For on-net calls from such PBXs, the CGPN used will always be the "primary" MSN with the callers extension appended. This will work well as when the called party calls back, this call will be on-net too and thus work fine.
However, when the call-back is done off-net (e.g. due to WAN overflow), it will not work perfectly, as the PSTN will either not deliver the call at all (as there are extra digits in the CDPN) or call the "primary" MSN with the extra digits stripped off and thus the PBXs switchboard (whereas the caller would expect to reach the original caller directly).
Unfortunately, the originally called party may have the caller in an (LDAP) directory and the number known will probably be one of the secondary MSNs (instead of the primary MSN with an extension added). So the caller will not be recognized. To fix this, the called party needs to add this number to the directory.
Unusual Escapes
Also, the PBX node's escape may be customer specific. In the US, both 0 and 9 are common.
United States
Unfortunately, in the US, it looks like if national calls are prefixed with 1, but international calls are prefixed with 011 (and by the way the common outside line code in a PBX is 9).
New York -> Sindelfingen: 011 49 7031 730090
Boston -> New York: 1 212 262861
New York -> New York: 262861
Sindelfingen -> New York: 00 1 212 262861
Fortunately, you are not selling to the States anyway, are you?
NB: all information regarding worldwide numbering plans in this book is taken from the internet, namely from
Physical Location
This feature most often is used for trunk lines. As such, it conflicts with the escape mechanism and as a result, use of the physical location generally does not work with E.164 setups.
Benefits
With an E.164 numbering plan, the PBX can easily determine if a called PSTN is on-net or off-net. In other words, if a called destination is actually part of the PBX network, then the call can be routed via IP without any specific configuration. This eliminates the need for users to call on-net destinations with the "right" called party number (e.g. location prefixes).
Even more, if a called destination is not part of the PBX network, then the call can still be routed via IP as far as possible and then sent to the PSTN remotely. Given a scenario with offices in Germany and Shanghai, it may be interesting to route calls to other Shanghai destinations or even to arbitrary Chinese destinations via IP to China and to the PSTN from there.
Please note that for each node you want to use as a remote-breakout (e.g. Shanghai in our example), you need to run a PBX at that node. Even though you probably won't have any extensions in this PBX.
Call Routing
However, a few things are different and we will discuss these in the next chapters.
Trunk Lines
Seen from the Office Vienna node, the trunk is obviously an object with number 0 (as users expect to access an outside line with a 0 code). At the same time though, 0 is the node's escape too (trunk prefix and escape will always be equal)? So when the user dials 0, what shall happen? Isn't this a conflict?
The answer is, yes, it is a conflict and no, it is not a problem. Generally, the escape of a node and the number of the trunk in this node will be identical. The PBX resolves this ambiguity and sends a call with a called party number that starts with 0 first through the escape link and searched the dialled number in the whole node tree. If it can't be found, the call will be returned to the originating PBX and then send to the trunk!
In other words, a call is always first tried on-net, and if this fails, it is sent off-net.
In a sense, the "escape link" duplicates the function of the trunk - we will go into more detail about this soon.
Dial Tone
Given the logic fact that a call to the trunk is routed on-net first and only if this fails through the real trunk, the dial-tone provided by the trunk is certainly too late. This is why a node has the Dialtone property which must be set if a dial-tone is required (which generally is the case for node representing a PBX with extensions).
Loopback
In an E.164 scenario, you can decide how the system shall behave when an attempt to dial-out through the trunk from within the network may happen. When a user from within your E.164 node tree dials the trunk prefix of a remote trunk, then he will get access to the remote trunk line. This may make sense to allow manual non-local breakout. However, in many cases users expect that they are connected to the switchboard in this scenario, just as it was before, when locations called each other va the PSTN. For this, you need to tick the Internal check-mark in the respective Trunk object settings in addition to setting the Loopback property.
Likewise, the Incomplete Name property in the
Return Calls from the "Escape Link"
Suppose there are actually 3 PBXs: a Master and slaves Vienna and Innsbruck. A user in the Vienna PBX calls 0 0 512 8818 20 [1]. Here is what happens:
- The Vienna PBX determines that the local escape (0) has been dialled. It sends the call to the master (remember that the PBX may - and probably will - be partly replicated only, it thus does not know the target node) [2]
- The master PBX determines that another escape (0) is dialled, followed by a known node (512)
- As there is no PBX associated with the 512-node, it waits for more digits
- The master PBX determines that a known node (8818) is dialled and that there is a PBX associated with this node
- The call is thus sent to the Innsbruck PBX [3]
- The Innsbruck PBX determines that a valid extension (20) has been dialled and delivers the call [4]
- The Vienna PBX determines that the local escape (0) has been dialled. It sends the call to the master (remember that the PBX may - and probably will - be partly replicated only, it thus does not know the target node)
- The master PBX determines that another escape (0) is dialled, followed by a known node (512)
- As there is no PBX associated with the 512-node, it waits for more digits
- The master PBX determines that an unknown number is dialled
So far so good, the interesting point is here:
- The master PBX will send the call back to the PBX which is associated with the node the caller is in
- The Vienna PBX sees the call returning and sends it to the local trunk
- The PSTN connects the call
This is important to understand. In order to "send the call back to the PBX which is associated with the node the caller is in" there must be a PBX which is associated with the callers node.
You could be tempted to create another node (say Vienna2, +49 1 1234) with no PBX associated and register it's phones to the Vienna PBX. This does not work, because when a user tries an off-net call, at the point where the master needs to return the call to the originator, it does not find such PBX.
Similar issue with ''looped-in'' scenarios
The same issue arises if there are calls through an external system that is looped-in to a slave PBX. Assume a scenario, where a legacy PBX is connected behind a slave in an E.164 setup. An external user calls (1., 2.) an extension within the legacy PBX (3., 4.) which has a CFU to an external number (e.g. the users mobile +43 123 4567, 5, .6). This call is off-net obviously. So it gets sent to the master (7.). However, the calling party number will be the one of the external caller (+43 512 12345 in our example). So at step 8, the master PBX will not know where to send the call back and terminate it.
If this happens, the fix is to route all calls from the legacy PBX to the slave through a Trunk type object. You can then set the Invalid property, so that a call in this case is re-routed to the real trunk line.
Also external Loopback calls(call from the PSTN dials 0 + PSTN number) will not work. The CGPN of such a call would not have a matching PBX number, so it will get released by the master PBX.The Loopback detection is done before Escapes are evaluated. This allows to configure a Loopback target for external callers, for example allowing them to dial 0 in order to reach the switchboard.
LCR
In our previous example, the customer does many calls from Vienna to Innsbruck, but not always to extensions of 8818 (the on-net Innsbruck PBX). Let us assume, that non-local calls from Vienna to Innsbruck are expensive. In this case it would be nice to implement non-local-breakout for such calls. That is, calls should go from Vienna to Innsbruck on-net and to the PSTN from there, eliminating long-distance charges.
This can easily be done by implementing an additional PBX in Innsbruck which is associated to the Innsbruck node. This PBX has no extensions at all. The only thing that it does is to receive otherwise undeliverable calls to the Innsbruck node and route them to the local trunk. To enable this on the PBX, you need to set the Route PBX-Node External Calls to property in
You may ask yourself "do I need an extra trunk line just for non-local-breakout then?". The answer is no, you can well use one of the trunk lines you have in the area code anyway (in our example the 8818 trunk line).
Central Breakout
There are scenarios where it is useful to provide a central break-out for the locations. This may for example be a big pipe PSTN trunk which is shared by many locations for outgoing calls.
This is possible by providing a central trunk at the master PBX (just as we have discussed node specific break-outs in individual node PBXs). This trunk then is configured in the Route Root-Node External Calls to property in
Each slave (i.e. location) then can decide if or if not to use this central trunk. This is done by setting the No other Node External check-mark in the Node tab of
Redundancy
Unfortunately, this does not happen out-of-the-box. Instead, it must be configured as usual using the Route Master calls if no Master to property in
You will register a GW from the local Gateway level with this object and route calls from this GW to your local PSTN trunk.
Please note that this also works if the calling slave has WAN access but the called slave does not. In this case, the call is terminated by the master (which is unable to route the call to the target slave PBX) with a re-routing cause (no channel available). This will again trigger the Route Master calls if no Master to setting and the call will be re-routed to the local PSTN.
Redundancy when the Master PBX has Endpoint Registrations
This scheme works well without any special configuration on the master PBX (such as setting call forwards on the slave PBX objects as described in the
You could think to solve this problem by configuring respective call forwards on the slave PBX objects. However, this makes for a difficult and less clean configuration which usually leads to various mistakes and issues. We thus strongly recommend to not have any endpoint registrations on the master in an E.164 setup (in other words, at the master, there should be slave PBX registrations solely). If for economical reasons a location must be run on the master hardware, we recommend to use a DynPBX slave for the location.
Redundancy for Calls without Called Party Number
Calls with a called name instead of a called number cannot be re-routed this way. As the call does not carry called number information, re-routing through the PSTN is not possible. Calls without called party number are initiated e.g. by the myPBX client when calling a buddy.
Foreign Registrations
However, consider a scenario, where a user, say U, is part of one location as far as the node tree is concerned (that is, a user that belongs to a certain E.164 number), say node A. This user is for some reasons - e.g. pickup groups - registered with a different PBX (not the one that is assigned to the users node), say PBX B. When another user registered with A, say X, calls U, then this call needs to be passed to pbx B of course (as U is registered with B). You can try this, works without anything special you need to do.
Now if the WAN is gone, this call needs to be sent via the trunk line. For this to work, B's E.164 number must be known (to address B's trunk line through the PSTN). Unfortunately, it is not known in this case. Assume U has extension 13 in node A, then X would just call 13.
When the WAN is available, A sends the call to the master and the master sends it to B. When the WAN is not available, PBX A will send the called extension (as always) to the trunk, 13 in our example. To implement redundant routing for this case, someone needs to provide B's trunk number. Let us assume A is +49 7031 73009 and B is +49 7031 844112. When X calls U, PBX A will present a call to 13 to the trunk (more precise, to the object configured as Route Master calls if no Master to). In the routing table, we can provide B's trunk number. But this is still not enough, as when the call arrives at B, B must know that the call is for extension 13 in A, not extension 13 in B. It is thus necessary to also provide A's E.164 number. The result could be a call to 844112 0 73009 13. 844112 will send the call to B's trunk line through the PSTN and 0 73009 13 is U's number as seen from B's node. If you have problems to follow this call flow and the associated PBX objects, have a look at the explanatory picture.
While this works in principle, it unfortunately does not work in real life. The pitfall is that when the call comes in to B, the trunk line object will detect that this is a call that loops back to the trunk (as the trunk doesn't know, that the target actually is registered with B), so it will trigger the Loopback setting and the call will most likely end up in B's switchboard.
To work around this issue, you can define a MAP object in B that maps to A's E.164 number, say #1. On A, instead of sending the call to 844112 0 73009 13, you would send it to 844112 #1 13. This works around the Loopback issue. It also has the benefit that the number sent through the PSTN is much shorter. However, on B, you should additionally implement a calling line verification to make sure, that no arbitrary caller can call to #1.
Phew, tricky? But it sounds worse than it is. Here are the respective routings on A
and on B.
Please note that calling #1 through the PSTN will not work with many providers, so you may need to choose an otherwise unused prefix instead.
Call Counters
While this sounds pretty straight forward, it is not in E.164 scenarios. As we have discussed, many calls are first routed to the master and then return back from the master (see chapter Return Calls from the "Escape Link") in this book. Are these calls counted twice?
Generally, when a call is routed from a slave to the master or vice versa, it increments the current call count on the respective end. However, when the same call returns back, the call counter is in fact not incremented again, but it is decremented again. So when such a call is initiated, the call counter will be incremented and if in this very moment it exceeds the limit, the call is rejected even if it would return back later on and thus decrement the count.
In real life, this will result in some calls that will be re-routed to the PSTN due to false WAN overflow detection. However, this usually doesn't matter, as if the destination of the affected call would have been on-net, then the call would have to be rejected anyway. And if it was to be off-net, then it would have been sent to the PSTN anyway! One of the situations where a a call would be falsely sent to PSTN is when you have many concurrent call attempts.
For more details about call counters, see the How Call Counters work chapter in the book on
E.164 and Partial-Rerouting
This works if the incoming call is sent back directly to the same trunk object and the trunk supports the feature. In an E.164 setup however, the call is never sent back to the trunk directly. Instead, it is sent to the master and returns from there if the call can not be delivered on-net.
To solve this problem, you configure a second TrunkLine with a different number as the escape(e.g. #0). This second trunk has the option Reroute Supported enabled and is used for all incoming calls. If a user knows that his call forward target is in the PSTN, he can skip the escape mechanism and forward to this trunk(e.g. #000435126789). As a result, the call forward is executed with Partial Rerouting.
In addition to this trunk the normal trunk (e.g. with the number 0) still exists. It is used for outgoing calls, if the caller doesn't know or care if the recipient is on-net or off-net.
The example above shows a Partial Rerouting call flow.
1. The incoming call enters the PBX through the #0 trunk
2. User2 configured a call forward to a PSTN number and wants to use Partial Rerouting. The CFU target is #000435126789
3. The forwarded call doesn't have a CDPN starting with 0, therefore the escape is not used. The call is sent directly to the #0 trunk and Partial Rerouting is executed
This solution solves the Partial Rerouting request but has a problem. Since all incoming calls come through the Partial Reroute - trunk, the CGPN of incoming calls contains the number of this trunk(e.g. #0). To solve this problem, starting with v10SR9, a Send Number can be configured not only at a User object but also at a TrunkLine object.
Our Partial Reroute - trunk would therefore have the Send Number of the main trunk(e.g. 0) and by this users would have the usual CGPN for incoming PSTN calls(i.e. starting with 0).
Since you have now two TrunkLine object for calls to the PSTN, make sure to configure at both objects the Trunk Line specific attributes, especially the Loopback - option.
Finally, you want to enable the Reporting - license for both trunk-objects if you use Reporting for external calls.
Loopback
The Loopback detection is done by comparing the number and Send Number value of a TrunkLine object with the CDPN of a call coming from this object. It is done before Escapes are evaluated, preventing that the call is sent to other nodes or PBXs.
If the CDPN starts with one of this numbers(in the picture above 0 or #0) and a Loopback target is configured, the call is routed to this object.
As a result, you should configure the Loopback settings on the Trunk used for incoming calls (in our example #0).
Make sure to test that the Loopback - target is triggered, to prevent call fraud for calls coming through the #0 - trunk and dialling out to the 0-trunk.
E.164 and "looped-in" Scenarios
If the master PBX is unavailable however (either due to registration issues or exceeded Max Calls to Master setting), such call will be delivered to the object set in Route Master calls if no Master to instead of being delivered to the object set in Route PBX-Node External Calls to.
As a result, both objects must be capable of handling calls of both types. And if so, you can as well use the same object for both.
Unfortunately, you can not send all such calls to the trunk line directly (by specifying the trunk line's name in the Route PBX-Node External Calls to and Route PBX-Node External Calls properties. This is because PBX node external calls can not be distinguished from calls to the local area code in the relay level. Assume the trunk prefix and hence escape is 0, then a call to 01234 will be seen as 1234 in the relay (as the trunk object will remove the leading 0 from the CDPN). A call to the PBX node external number 1234 is seen is 1234 too in the relay, so it can not be distinguished from the trunk line call and hence not handled properly.
The best solution is to use the same object for both the Route PBX-Node External Calls to and Route PBX-Node External Calls properties. It should be a Gateway type object with no Number property set. You can put it into the PBX node or into the location's area code node. In both cases, the two cases (external calls and PBX node external calls) can safely be distinguished.
The PBX Tree
Generally, the master PBX can work as a normal location PBX as usual. However, we recommend to have a separate master PBX in addition to the slaves. The master should not be used as a PBX for a location. This way, you get a cleaner setup where all slaves are configured and behave alike. If you - for cost reasons - use the master PBX as a location PBX too, the configuration and behaviour of this PBX is slightly different. You should avoid it in favour of better manageability.
One of the situation where a master PBX acting as a location with registrations at the same time us ugly, is when it comes to WAN re-routing. The mechanism used in E.164 setups (Route Master calls if no Master to) is simple and clean. If there are endpoint registrations on the master too, this does not work well any more, as when the master's WAN fails, the slave's Route Master calls if no Master to mechanism is not available. Other mechanisms, as discussed in
If for economical reasons a location must be run on the master hardware, we recommend to use a DynPBX slave for the location.
Configuration
From this, it should be easy to create the node tree. Don't forget to configure the relevant essentials in the Node and Trunk PBX objects.