Course12:Advanced - E164 PBX Setups

From innovaphone wiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
There are also other versions of this article available: Course11 | Course10 | Course12 (this version)

This books is about setting up a PBX system which partly emulates the worldwide PSTN E.164 numbering plan.

What is "E.164"?

E.164 actually is the ITU standard The international public telecommunication numbering plan. It defines the structure of telephone numbers that can be used globally to call subscribers. It also describes dialling procedures.

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 screenshot.png 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 Distributed PBX. In particular, to be able to call from site (i.e. node) to another site, we use so-called node-prefixes at our own discretion.

While this is great, some customers - especially when migrating to VoIP - ask for a screenshot.png 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

The E.164 numbering plan is a variation of the PBX's standard node tree. In general, E.164 defines a screenshot.png hierarchical numbering plan. Translation of the PSTN's E.164 numbering plan into a structured PBX node tree is pretty straight forward.

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 Distributed PBX for a description). In a standard tree, a called number, if not found in the current node, is searched in the current nodes parent node. If it is still not found, this is continued to the root node.

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 fish-help.png PBX/Objects/Node object properties we already know, the screenshot.png Escape property must be set to define which escape is used to move one level up in the tree from this node. This is (more or less wink) all you need to do to change a node tree in to an E.164 node tree!

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 screenshot.png real-life node tree.

2-level Numbering Plans

Unfortunately, in reality, not all PSTN systems in all countries work like this.

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

Some dial plans are sort of inconsistent. From a structure point of view, they are a standard 3-level country/area/subscriber dial plan. However, they do not allow subscribers to dial subscriber numbers. All calls must be dialled using the national number (that is escape-to-area + escape-to-national + area code + subscriber), even when both caller and called reside in the same area code.

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 fish-help.png 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

One unfortunate case is when the customer PBXs do have multiple MSNs instead of one subscriber number with extensions and DDI.

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 fish-help.png PBX/Objects/Trunk Line and Incomplete Name in fish-help.png PBX/Objects/Node).

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

Another issue is "unusual" escapes. Have a look at screenshot.png Nigeria's dial plan. To dial from Office Abuja to HQ Sindelfingen, users will need to dial 0 (for an outside line), 0 for national calls 09 for international calls and then 49703173009. 000949703173009 looks strange to your eyes perhaps, but then again, so many countries, so many customs!

Also, the PBX node's escape may be customer specific. In the US, both 0 and 9 are common.

United States

One of the assumptions in this model is that all escapes are concatenated to climb up the node tree to the root. In other words, if the national prefix is 0, then the international prefix must be something like 00.

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 www.png www.howtocallabroad.com: codes.html and www.png www.timeanddate.com: worldclock/dialing.html. They may thus be grossly wrong. So just take them as examples, not solid knowledge!

Physical Location

The "physical location" is a special routing mechanism that allows you to route calls depending on where your endpoint physically resides (see chapter Physical Location in Distributed PBX for more details).

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

There is one major reason to use an E.164 numbering plan: least cost routing (LCR).

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

Call routing in an E164 node tree works pretty much like call routing does in a standard node tree. A PBX will search the called party's registration PBX and if it decides that it for whatever reason cannot be sure it knows it, it will send it across the PBX tree, either towards the master PBX or towards a slave (or sub-slave) PBX.

However, a few things are different and we will discuss these in the next chapters.

Trunk Lines

Let us for a moment recall the screenshot.png the schematic E164 node tree we have seen before. Looks pretty straight forward, but how does a physical trunk line fit in to the picture?

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

In a non-E.164 PBX setup, when a user dials the trunk line prefix (usually 0), then he expects to hear a dial-tone. This will be either provided by the PSTN provider itself, or - if some kind of non-trivial routing is done in the gateway's routing table - by the TONE interface.

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 screenshot.png must be set if a dial-tone is required (which generally is the case for node representing a PBX with extensions).

Loopback

When a user calls in to a PBX through a trunk from external and then dials the trunk prefix, you usually want to make sure this call is not routed back to the trunk (which would give external callers the ability to user your trunk line at your expense!), but is forwarded to the switchboard. This is done by setting the Loopback property in the fish-help.png PBX/Objects/Trunk Line settings.

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 screenshot.png 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 fish-help.png PBX/Objects/Node settings does what the Incomplete property in the Trunk does and the No Response Name property in the Node does what the No Answer property in the Trunk does.

screenshot.png trunk-versus-node

Return Calls from the "Escape Link"

Let us look a bit how the screenshot.png on-net vs. off-net escape routing works.

Suppose there are actually 3 PBXs: a Master and slaves Vienna and Innsbruck. A user in the Vienna PBX screenshot.png 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]
Now suppose the same user screenshot.png calls 0 0 512 12345.
  • 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 screenshot.png 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, screenshot.png 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

Basic Least Cost Routing (LCR) is built-in to the E.164 scheme. That is, if a called party is within the PBX network, then the call will be delivered on-net.

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 screenshot.png 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 screenshot.png set the Route PBX-Node External Calls to property in fish-help.png PBX/Config/General.

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 screenshot.png configured in the Route Root-Node External Calls to property in fish-help.png PBX/Config/General for the master PBX.

Each slave (i.e. location) then can decide if or if not to use this central trunk. This is done by screenshot.png setting the No other Node External check-mark in the Node tab of fish-help.png PBX/Objects/Node for the respective slave node.


Redundancy

One of the nice things with an E.164 setup is that WAN redundancy is more or less "built-in". This is because calls that leave the PBX (and thus are subject to WAN redundancy) will always have a full E.164 called party number. So if the WAN is not available, calls can be sent to the local trunk instead simply.

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 fish-help.png PBX/Config/General. This must be screenshot.png set to the long name of an object where calls which cannot be sent to the master are sent to. A PBX Gateway object is most appropriate.

You will register a screenshot.png 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 Redundancy book). However, it only works if there are no calling endpoint registered with the master PBX. If so, a call from such an endpoint (as it is not registered with a slave PBX that has the re-routing configuration) will fail.

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

In most cases, this simple step (outlined in the previous chapter) does what has to be done for re-routing WAN calls to the PSTN trunk line when the WAN link fails or is overloaded.

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 screenshot.png 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 screenshot.png on A
and screenshot.png 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

When it comes to ISDN redundancy, then there are several scenarios, where calls may need to be routed through the PSTN. One of them is when the number of calls exceeds the number specified in the Max Calls to Master property of a PBX or the Busy On property of a PBX object.

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 Redundancy.

E.164 and Partial-Rerouting

Partial rerouting (fish-help.png How to Configure EDSS1 Partial Rerouting) is a PSTN provider service that allows to forward (CFU andf CFB) incoming calls to the PBX to external numbers right in the PSTN. That is, when a user for example sets a call forward to his own mobile, it will not consume two trunk line channels in the PBX (one for the incoming, one for the outgoing call). Instead, the call will be diverted right in the PSTN provider's switch.

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 fish-help.png 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.

screenshot.png call-routing-scenario-pr



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 fish-help.png 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 fish-help.png 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

When looping in a legacy PBX, you will use the Route PBX-Node External Calls to property in fish-help.png PBX/Config/General. While this still works with E.164 setups, you need to be aware that calls to destinations which can not be located on the slave PBX will always be sent to the master for delivery. Only if they are not known there, they are returned to the slave PBX and then sent to the object specified in Route PBX-Node External Calls to.

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.

screenshot.png pbx-ext

The PBX Tree

There is nothing special with the PBX tree for an E.164 scheme. The easiest way to go is to have all slave PBXs register with the master PBX.

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 Redundancy need to be employed. This will make for a difficult setup which is not easy to understand and thus error-prone in maintenance.

If for economical reasons a location must be run on the master hardware, we recommend to use a DynPBX slave for the location.

Configuration

To set up the system, you may want to screenshot.png draw a graph with the relevant sites (PBXs), their subscriber numbers, the area and country-code. Also, take note of the various escapes.

From this, it should be easy to screenshot.png create the node tree. Don't forget to configure the relevant essentials in the Node and Trunk PBX objects.