Course13:IT Plus- E.164 PBX Setups

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

Start Configuration

A new book starts with a new start configuration.

Please go ahead and upload a new start configuration for this lesson to your devices. Afterwards please upload the lesson configuration to your Application Platform as well.

In this configuration, the IP411LEFT is configured as a (single) master PBX with  some nodes and users. We will convert this configuration in to an E.164 node tree in the course of this book.

We will later add a slave PBX on the IP811 and then the IP222 will register with that slave. So for now, the IP222 does not register. Don't worry, this will be resolved soon

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  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 PBX and Nodes. In particular, to be able to call from one site (i.e. node) to another site, we use so-called node-prefixes (e.g. 80, 82, 82, ...) at our own discretion.

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 PBX and Nodes 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  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 PBX and Nodes: Number resolution 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 dialing 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 dialing 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 dialed, 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 dialed country code (e.g. 41) moves it down to the respective country code node (e.g. Switzerland), a dialed area code (e.g. 44) to the respective area code node (e.g. Zurich) and finally a dialed subscriber number (e.g. 54321) to a subscriber number node. All trailing digits are then used to select the extension within the target PBX. So, dialing 0 0 0 41 44 54321 9 from a phone in HQ (in Berlin) will call to extension 9 in Office Zurich. Sounds familiar, I guess.

It should be noted that the PBX node is what is called a Subscriber Number node in the drawing (usually but not necessarily, as we will see later on).

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.

Node tree setup

To define the escape digit(s) mentioned above, in addition to the  PBX/Objects/Node object properties we already know, the  Escape property must be set. It defines which escape is used to move one level up in the tree from this node. This is (more or less ) all you need to do to change a node tree in to an E.164 node tree!

To convert the simple node tree into an E.164 node tree, proceed as follows

• set the Escape property in the Node tab of the Node objects node-branch-berlin, node-branch-verona and node-branch-zurich to 0

This converts to an E.164 node tree because it changes the implicit search strategy (search a number in the next node towards the root if not found in the current node) into an explicit search strategy (only search the next node towards the root if the escape is dialed).

Node tree setup (contd.)

We promised that defining the escape in all nodes is all we need to do to convert our old node tree into a fancy E.164 node tree.

Well, strictly speaking, this is true as we thereby changed the search strategy. However, the node tree is incomplete obviously, as our "location" nodes (such as node-hq-berlin) are directly underneath the root. Obviously, the area-code and country nodes are missing.

To complete our E.164 tree, please add the missing nodes:

• create a Node type PBX object called node-cc-germany with Number 49, Parent node root and Escape 0
  Always set  Name and Long Name identical, as in the node-branch objects (such as node-branch-berlin)
  
• create a Node type PBX object called node-ac-germany-berlin with Number 30, Parent node node-cc-germany and Escape 0
• create a Node type PBX object called node-cc-switzerland with Number 41, Parent node root and Escape 0
• create a Node type PBX object called node-ac-switzerland-zurich with Number 44, Parent node node-cc-switzerland and Escape 0
• change node-branch-berlin's Parent node property to node-ac-germany-berlin
• change node-branch-zurich's Parent node property to node-ac-switzerland-zurich

2-level Numbering Plans

Unfortunately, in reality, not all PSTN systems in all countries work exactly 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  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 a Swiss 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 (as many of them start with 0 which resembles an escape), 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 Berlin 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 dialed even from the international level.

No big deal if you take care to configure the tree correctly.

Node tree setup (contd. II)

So, it certainly did not go unnoticed by you that we had omitted Italy when we created the E.164 node tree. Meanwhile, you know why: it is a bit special.

To set up the italian node tree do the following:

• create a Node type PBX object called node-cc-italy with Number 39, Parent node root and Escape 0
  
• change node-branch-verona's Parent node property to node-cc-italy

You might have observed that we did not yet change the Number properties of the branch-node objects.

node-branch-verona's node is directly underneath the Italian country node. This corresponds to the structure of the Italian numbering plan. However, in the E.164 numbering plan, the branch-nodes should not have arbitrary node-prefixes. Instead, they need to have the branch's subscriber number as Number. This way, the node tree matches the countries real numbering plan.

This change still remains to be done for all our branch offices:

• set the Number property of node-branch-berlin to 54321
• set the Number property of node-branch-verona to 0454321
• set the Number property of node-branch-zurich to 54321

For simplicity, we have defined (almost, look at the Verona branch!) identical subscriber numbers for all branches. Of course, this is unrealistic (and also ignores the different number lengths set forth for subscriber numbers in most countries).

Inconsistent 3-level dialling

Traditionally, subscriber lines were structured by the local exchange they were physically connected to. Users would dial a local subscriber number to reach another user connected to the same local exchange. Later on, local exchanges were interconnected and users would optionally dial a specific prefix (usually 0) followed by the identification of the foreign local exchange (a.k.a. area code) to call remote subscribers. Finally, national telephone networks were connected so that users would dial yet another prefix (again, usually 0) followed by the identification of a foreign national telephone network (a.k.a. country code) to call subscribers in a different country.

For example, to call innovaphone's headquarter in Sindelfingen from Vienna, a user would dial 0 (get to the national level), 0 (to get to the international level) 49 (to get to Germany), 7031 (to get to the Sindelfingen area), 730090 to get to innovaphon'e subscriber line.

Alternatively, a user in Munich would omit the 049 part and just call 0 7031 730090 and a user from Sindelfingen would just call 730090.

Also, PBX systems usually create a new level underneath the area code: plain numbers identify an extension in the same PBX. To reach subscribers outside of your own PBX, you would need to dial a specific prefix (known as trunk access code, usually 0 too). So to call the Sindelfingen headquarter from a Munich PBX, a user would dial 0 0 7031 730090.

In other words: the international dialing plan (a.k.a. E164 plan) used to be  a tree-like structure.

Subscribers are located in the leaf level and can descend to the root by dialing escape digits. Anything but the escape digits climbs towards the subscribers.

However, since this approach was caused by the physical structure of the telephone network, it was changed by various countries as part of the digitization. In these countries, the dialing scheme was changed in a way that it was not longer possible to call within an area code level directly. Instead, users would need to descend to the national level and then back to the (same) area code level.

In other words: in our example, the Sindelfingen user rather than dialing 730090 to reach innovaphone would then need to dial 0 7031 730090.

Switzerland has such a behavior and therefore a user in Zurich who wants to call the mayor (whose number is +41 44 4123120 where 44 is the area code of Zurich)

 must call 0 0 44 4123120 (assuming he is in a PBX with a 0 escape), 0 4123120 would not work.

Even though this new behavior was not introduced in Austria and Germany, the adoption of SIP trunks has led to the same effect. SIP trunks usually do not have a notion of the area code where the subscriber resides in. Therefore, they cannot imply the users area code when no prefix to the national level is dialed and so they behave similarly.

As a result, you nowadays do not need to know if or if not a countries dial plan behaves like this or not. You can safely assume that all do.

It is important to note though, that this inconstant 3-level dial plan is not the same as the 2-level dial-plan found in some other countries such as Italy. In a 2-level dial-plan there is no third level at all.

How to handle it

To handle this inconsistent behavior, you need to do the following things in an E164 setup::

• You configure a 3-level numbering plan as usual (already done )
  
• declare to the PBX all objects which must not be called directly (as opposed to being called from the national level)
  
• on all trunk lines, you configure interface maps to fix incoming and outgoing calling party numbers with no prefix to the national format, i.e. fix 4123120 (pure subscriber number) to 0 44 4123120 (subscriber number with national prefix and Zurich are code)
  
• on all trunk lines, you configure route maps to adjust outgoing called party numbers to the national format

Members not to be called

For any objects that is not to be called directly, we need to enable the Members not to be called option on the Node the object belongs to. This option will tell the PBX to add the national prefix and the area code (i.e. the Number of the parent node). So if the Zurich mayor would be called directly (4123120 instead of 0444123120) by a Zurich subscriber, as we described in our  previous example (which would not work in the real PSTN due to the inconsistent dialing described in the previous section but does work inside our PBX E164 tree), the mayor would see the expected calling party number (which includes the national prefix and the Zurich area code).

So then, which objects "shall not be called directly"?

Objects which have an area code node set as their Parent Node property.

In our sample setup, we have called all area code nodes like node-ac-<country>-<area>, so finding all objects which have those as Parent Node is pretty straight forward:

• go to PBX / Objects on your IP411LEFT
  
• click on show
• sort all objects by parent node (that is, click on the Node column title)
• search for all entries including "node-ac-" (using your browsers search function, usually CTRL-F) in the Node column
  
• you should find node-branch-zurich, node-branch-berlin and Christoph Künkel(your object is the mayor of zurich)

Tick the Members not to be called check-mark in both nodes node-ac-germany-berlin and node-ac-switzerland-zurich

MSNs

There is a little tricky situation when the customer PBXs do have one or multiple MSNs instead of one subscriber number with extensions and DDI. Here is how to handle it in an E164 plan.

 scenario

What is an MSN anyway?

An MSN is essentially a number to which no further digits can be appended. If you like, it is a DDI number with a zero length internal numbering plan. Therefore, there is no way to address individual extensions behind the MSN.

This happens in real life (and is in fact quite popular) but it doesn't exist in our E.164 numbering scheme. Here, all subscriber numbers (that is, numbers which address a PBX) can carry further digits to address individual extensions behind the PBX (and in fact, the internal numbering plan is practically not limited in length).

Single MSN

As a result, to implement an MSN in an E.164 numbering plan is, you would define a Node having the MSN as the value for its Number property (just like you would do it for a DDI). However, in addition to that, you need to define which internal extension is to be called when the MSN is dialed. This is done using the Incomplete No property in  PBX/Objects/Node.

So let us assume that node-branch-zurich has an MSN instead of a DDI:

• the Number property of the Node node-branch-zurich must be 54321 (which it already is)
• to define who is to be called when only the plain MSN is called (no further digits), we must set the Incomplete No property to 12 (which is John Doe)
• now we can have Edward Hyde call 000414454321 (the MSN) from his IP232. John Doe's phone will ring
• note that calling 00041445432112 (that is, the MSN plus Johns extension) from Edward Hyde will also reach John Doe's phone
• also note that calling 00049305432111 from John Doe's phone will ring at Edward Hyde's phone, which is not surprising). However, it shows 00041445432112 (that is, the MSN plus John Doe's extension) as calling party number

Calling out from an MSN site will show the MSN plus the extension as calling line id. While this may sound surprising (as in the real PSTN, the MSN only would be seen) it has the beauty that you can directly call back even if the MSN is not mapped to the called back user. Of course, this only works on-net.

Multiple MSNs

In the PSTN, more than one MSN can be assigned to a trunk line (hence its name multiple subscriber number). Up to 10 MSNs may be assigned to a single trunk line.

Now how do we handle a scenario where a site (more precisely, the trunk line it is using) has multiple MSNs?

First of all, we need to define which extension shall be addressed if one of the extra MSNs is called. Before (that is, for the first MSN), we used the Incomplete No property. For all further MSNs, we can create a Number map object which maps the MSN to the first MSN with the extension the call shall be routed to appended to this MSN.

Assuming that node-branch-zurich has an additional MSN 47111 assigned to it and calls towards this MSN shall be routed to Jane Doe, we can proceed as follows:

• we create a Number Map PBX object called node-branch-zurich-msn2 with its Number property set to 47111 and its Parent node property set to node-ac-switzerland-zurich (just as for node-branch-zurich )
• we add a map with Dest. No set to 5432111 (the trunk line's first MSN (54321) with Jane Doe's extension (11) added) in the Mapping tab (Addr and Mask must be left empty)
• now we can have Edward Hyde call 000414447111 (the second MSN) from his IP232. Jane Doe's phone will ring
• also note that calling 00049305432111 from Jane Doe's phone will ring at Edward Hyde's phone, which is not surprising). However, it shows 00041445432111 (that is, the first MSN plus Jane Doe's extension) as calling party number

Within the E.164 numbering plan (that is, for all on-net calls in the PBX system), the first MSN with the callers individual extension added will be signaled as CGPN. As discussed before, this might seem surprising but it has the benefit that internal users can call the first MSN plus extension to directly call to a specific user.

We will see later on how we handle this situation towards the real PSTN.

Issues with MSNs

As discussed before, 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 for whatever reason (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 added to the CDPN) or call the "primary" MSN with the extra digits stripped off and thus the extension defined for this MSN using the Incomplete Name / No property (usually the PBXs switchboard), whereas the caller would expect to reach the original caller directly.

Also, 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 as an alternative.

Unusual Escapes

Another issue is "unusual" escape digit sequences. Have a look at  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 trunk line access code (usually 0 in Europe) may be customer specific. In the US for example, 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.howtocallabroad.com: codes.html and  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 Dynamic physical location in PBX and Nodes: Dynamic physical location 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.

E.164 and PBX internal LDAP searches

As you might recall from one of your previous trainings, the PBX object database can be queried by LDAP clients for name resolution (forward lookup). For example, DECT phones are still using this feature.

The PBX LDAP server would obviously return the object numbers (as taken from the Number property of the object itself and all its parent nodes down to the root). This is fine for a normal multi-node setup. However, in an E.164 setup this is not good.

As an example, if you have an object innovaphone with number 73009 in a node Sindelfingen with number 7031 in a node Germany with number 49, then the LDAP would return 49703173009 for this object. This is not useful to the calling client, unfortunately. It should be either 0049703173009 or +49703173009.

By ticking the Adjust LDAP results for e.164 check-mark on the PBX/Config/General page the issue is fixed by adding a '+' as prefix to the returned numbers.

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

Multi-PBX E.164

So far, we have configured the whole E.164 numbering plan using a single PBX. This in fact is perfectly fine.

Note that this is an advantage when compared to the older versions v12 and before. Previously, there was a distinct PBX device required for each PBX in the numbering plan (that is, for each node that has user extensions). This is no longer the case.

However, you can still use several physical PBX devices as part of your setup and there are the following benefits:

• a site implemented using a dedicated PBX device will still work when another PBX (including the master PBX) fails
• partial on-net routing of calls for least-cost-routing can be implemented
  

You would simply create a PBX type object instead of a Node type object for a subscriber number and register a physical PBX device there. Also, all objects underneath this PBX node would have their PBX property set to this PBX node. This is just like you would do in a normal multi-node system. You have already exercised this as part of the PBX and Nodes: Setting up the PBX for the Italian trunk line book.

Partial on-net routing

Partial on-net routing is a mechanism that routes calls whose destination is outside the network to the vicinity of the destination. There, they can then be routed via an existing trunk line. This can save charges by avoiding international calls, for example.

For an example, let us assume that Edward needs to call a user in Geneva, Switzerland. He would dial 0 (trunk access) 00 (international prefix) 41 (country code Switzerland) 22 (area code Geneva) 23456 (subscriber number).

The PBX would try to evaluate this number and determine that when it  has processed 00041 (which reaches the node-cc-switzerland node) there is no further matching object with a number starting with the next dialed digit 2. Without Partial on-net routing, the call would then be delivered to a trunk line (with number 0) in the callers node node-branch-berlin.

However, if

• there is  a PBX object in the node-cc-switzerland node (not just a plain Node object)
• and it has  a PBX registered to it
• and it has  the Route PBX-Node External Calls to property set
• and this property is the Long name of an object  that is registered with that PBX
• then the call is routed to this object instead

Phew.... I think we need to have a  closer look at that:

• when the call evaluation has reached node-cc-switzerland it determines that there is no matching object for the remaining digits (22 2345)
• the node has a PBX registered to it
• this PBX has a Route PBX-Node External Calls to property that points to the trunk object
• therefore, the call is sent to this trunk

A PBX implementing a node in the node tree can catch all target numbers that can not be delivered on-net as long as they are located in or underneath this node.

In our case, this would be all numbers below 0041, i.e. all Swiss numbers.

Note that the trunk which is registered with this PBX does not need to be configured to live in the node of this PBX (node-cc-switzerland in our case). In fact, it is much more likely that the trunk is configured for one of the subscriber nodes (e.g. in node-branch-zurich in our example).

To get a grasp on how this needs to be configured, proceed with re-configuring the object type of node-cc-switzerland:

• edit the node-cc-switzerland object and  change its Type property from Node to PBX
• set Parent PBX to hq (which is the master PBX in our scenario)
• set Password to (you guessed it) ip411

Now node-cc-switzerland is a PBX type object instead of a Node type object. This works well as the PBX type is a superset of the Node type (i.e. a Node with a PBX associated to it).

To configure the IP811 as a PBX associated to the node-cc-switzerland node we need to perform the following steps:

•  configure the IP811 as a slave PBX to the master hq on PBX / Config / General
• PBX Mode: Slave
• System name: dvl-ckl2.net
• Use as domain ticked
• PBX Name: node-cc-switzerland
• DNS: branch-b.dvl-ckl2.net
• Reverse Lookup URL: ldaps://apps.dvl-ckl2.net/dc=entries?givenname,sn,company?sub?(metaSearchNumber=+%n)?bindname=apps.dvl-ckl2.net\contacts
• Reverse Lookup URL password: pwd
• Registration: H.323/TLS
• Master: 172.31.31.2
• Password: ip411
• Replication: All
• Replication/use TLS ticked
  
• Route PBX-Node External Calls to: trunk-switzerland

• set the PBX password on PBX / Config / Security to the same value as in the master PBX (ip411)

The IP811 should now  register as a slave on the master IP411.

• change the PBX property of the trunk-switzerland object to node-cc-switzerland

This is important as the Route PBX-Node External Calls to property only works if the referenced object is registered with this same PBX!

If we now  call 0 00 41 22 23456 from Edward Hyde's IP232, we will hear the Swiss trunk line prompt.

CGPN and CDPN in partial on-net routing

Now we have seen how to define catch-all treatment for destinations that are not part of the numbering plan covered by our PBX.

Let's take a look at the actual numbers (both CDPN and CGPN) that are part of a call sent to the trunk object which is used in the Route PBX-Node External Calls to property.

To do this, we open the Maintenance / Logging page click on the logging switch Gateway Calls on the IP411LEFT, where the Swiss trunk is implemented as GW3. This shows us the properties of the calls to this trunk.

Now we can do some test calls.

The first attempt is a call from abroad.

• start the logging by clicking on the syslog link on the Maintenance/Logging page
• call 0 0041 22 23456 from Edward Hyde's IP232 again (you will hear the Swiss trunk line prompt)

You see is the following logging output:

20220608-123031 CALL 2 B:Call 00049305432111:edward.hyde@dvl-ckl2.net->02223456 / GW3:00049305432111:trunk-switzerland->HTTP:02223456:

So the CGPN as seen after it has passed the Trunk object is 00049305432111 and the CDPN is 02223456. As you might notice, these are the  numbers of the caller and the destination as seen from the node where the trunk line used is in.

Let's take a look at the CGPN first:

• we start at the node node-branch-zurich
• from there we ascend with a 0 to the node node-ac-switzerland-zurich
• from there with a 0 up to the node node-cc-switzerland
• from there with a 0 up to the node root
• from there with 49 down to node node-cc-germany
• from there with 30 down to node node-ac-germany-berlin
• from there with 54321 down to node node-branch-berlin
• from there with 11 from to the user Edward Hyde

And now the CDPN.

There is a special thing to note here, because as you probably remember, the Trunk object removes its own number (the 0) from the beginning of the CDPN. However, since we only see the numbers in the syslog after they have passed the Trunk object, we have to mentally add a first 0. This is not necessary for the CGPN, because it is not changed by the Trunk object.

So the CGPN initially sent is 0 02223456.

• we start again at the node node-branch-zurich
• from there we ascend with a 0 to the node node-ac-switzerland-zurich
• from there with a 0 to the node node-cc-switzerland
• from there with the 2223456 to the destination

Just for the fun of it, we can modify the Swiss trunk line a bit to see what happens:

• open the trunk-switzerland Trunk Line object
  
• change the Node property from node-branch-zurich to root
  
  due to this, both CDPN and CGPN will now be sent as international numbers in root node context
  
  
• start the logging by clicking on the syslog link on the Maintenance/Logging page
• call 0 0041 22 23456 from Edward Hyde's IP232 again (you will hear the Swiss trunk line prompt)

You will now see in the syslog a line like

20220608-142325 CALL 7 B:Call 49305432111:edward.hyde@dvl-ckl2.net->412223456 / GW3:49305432111:trunk-switzerland->HTTP:412223456:

instead of as before

20220608-123031 CALL 2 B:Call 00049305432111:edward.hyde@dvl-ckl2.net->02223456 / GW3:00049305432111:trunk-switzerland->HTTP:02223456:

As you can see, both CGPN and CDPN are now as seen from the root node, starting with their respective country code.

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  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 node-branch-berlin 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 do not have to but practically 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 dialed 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.

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 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 all nodes representing a PBX with extensions).

To ensure a dialtone after the 0 in all nodes, tick the Dialtone check-mark for

• node-branch-berlin
• node-branch-verona
• node-branch-zurich
  

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 use your trunk line at your expense), but is forwarded to the switchboard. This is done by setting the Loopback property in the  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 via 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  PBX/Objects/Node settings does what the Incomplete property in the Trunk Line object does and the No Response Name property in the Node object does what the No Answer property in the Trunk Line object does.

 trunk-versus-node

To configure Edward Hyde as switchboard user for the Berlin branch, proceed as follows:

• in the trunk-germany Trunk Line object set the Loopback, Incomplete and No Answer property to the Name property of Edward Hyde, which is edward.hyde
• also in the trunk-germany Trunk Line object tick the Internal check-mark
  
• in the node-branch-berlin Node object set the Incomplete Name and No Response Name properties to the same value edward.hyde

Obviously, in real-life, you would want to do similar settings for the other branch offices.

Loopback and Partial on-net routing

In the previous chapter (Loopback) we talked about the handling of so-called loopback calls (calls coming in to a location and dialing the trunk from there, which is also known as non-local breakout). We have seen how to prevent that using the Loopback property of the Trunk line object so such calls would be routed to a switch-board instead. We also talked about the possibility to have this function for callers from within our E.164 numbering plan (using the Internal flag).

When partial on-net routing is configured (as we did using the slave PBX on the node-cc-switzerland node), it effectively implements an implicit (that is, not done explicitly by the caller) loopback call. You can therefore not activate the Internal flag in the Trunk line object used, as its sole purpose is to inhibit such calls.

If you want to implement implicit non-local breakout but inhibit explicit non-local breakout, then you need to create an extra Trunk line or Gateway object without Loopback handling and use it as value for the Route PBX-Node External Calls to property (see (Partial on-net routing).

Dialing locations

You may recall what has been said in section More Node properties of PBX and Nodes: More Node properties regarding the Prefixes Intl/Ntl/Subscriber and Country Code/Area Code/Subscriber properties in the Node type objects: these must be configured individually for the nodes, depending on the properties of the respective trunk line. This is also the case in connection with an E.164 configuration.

However, in our scenario, we have a lot of nodes:

• country code nodes
• area code nodes
• subscriber nodes

Where do we have to set the dialing location properties then?

As a rule of thumb, the properties need to be defined in all nodes that have objects where the node is used as value of the Node property (that is: where users or trunk lines are defined in).

So we have to set these properties as follows:

Prefixes Intl, Ntl, Subscriber

Country Code, Area Code, Subscriber

• node-branch-berlin
  000, 00, 0
  49, 30, 54321
• node-branch-verona
  000, 0, 0 (there are no area codes in Italy, so the prefix is the same as the Subscriber prefix)
  39, empty (there are no area codes in Italy, so we leave it empty), 0454321
• node-branch-zurich
  000, 00, 0
  41, empty (all calls must be national in Switzerland, so we leave it empty), 54321

The PBX Tree

In an E.164 scheme, just like with other multi-node schemes, it is both possible to run locations on separate PBX devices or to run all of them on the master PBX.

It is possible as well to run only some locations on a separate PBX. This may be useful if you have some locations which require enhanced robustness in case of a WAN failure. In this case, while the location would be disconnected from the rest of the E.164 system, it would still manage all local extensions (as those would be registered with the local PBX device). Also, if a local non-SIP trunk line (or a SIP trunk line that uses a separate WAN access) is used in this location, external calls would still be possible.