Howto:Description of the Numbering Scheme used in V6
|
FIXME: partly pre-SR1 info, needs to be updated to SR1 |
Applies To
This information applies to
- all innovaphone PBX Platforms, V6
SR1 and later
More Information
Introduction
The locations concept found in V5 PBX’ has been greatly reworked in v6 and replaced by a generalized numbering scheme. This eliminates some of the following problems with the old scheme:
- In v5, a single PBX configuration could include more than one object with the same number. Although all configurations for all PBXs in a network could be defined and storedin a single (usually the master) PBX and replicated from there, this limitation implied that for numbering plans with non-unique numbers each PBX had to store its own configuration with no replication. So each PBX configuration had to be administered separately and it was hard to get a complete overview and to backup the complete configuration.
- In a non-flat numbering plan, there was a physical PBX required for each nodein the numbering tree
- Group function are limited to users which are registered to the same PBX. This is to avoid the extra overhead of synchronizing state information between several PBXs. In V5 this implied that a group could not comprise users from within different nodesin the numbering tree.
V6’s numbering scheme attempt to overcome these problems.
The general idea is to separate the location where a user registers from the location of the user inside the numbering plan and again from the physical location of the user.
For each registered user, the PBX thus maintains
- Its position in the numbering tree (the numbering node). This is defined as “Node” in the corresponding user object. It determines the way called numbers are interpreted for call routing
- Its registration PBX. This is defined as “PBX” in the corresponding user object. It defines the set of users which can be part of the same group (i.e. all users registered to the same PBX can be part of the same group)
- Its physical location. This is determined on run time and may be used to modify the call routing (see below)
The numbering node
Each object in the PBX must be assigned to a numbering node in the numbering tree. All objects within one numbering node can call each other without the use of a prefix.
A numbering node is defined by creating an object of type Node in the PBX configuration. For details on how to configure a node object, see the Node objects help page.
There is one implicitly defined numbering node root without a prefix. This is the root of the numbering tree. There is no prefix that can be used to call the objects in the root node.
The registration PBX
Each PBX entity running on a gateway is a registration PBX, with a name configured locally on this gateway (“Administration/PBX/General/PBX Name”). There must be an object of type Node in the PBX configuration that has this name configured as Name. In other words, the name of a PBX is always the name of a numbering node too. However, there is no need that for each defined numbering node there is a registration PBX (for details, see above).
Each object is assigned to a registration PBX. This is done using the Parent PBX drop down in the objects configuration. If the registration is performed, then it is always forwarded to the registration PBX defined for the object, even if the registration was initially directed to a different PBX.
The physical-location
The physical-location is not configured but determined for each registration on runtime depending on the PBX the registration was initially sent to. This physical-location is not necessarily identical to the registration PBX since if the registration is sent first to a PBX which is not the registration PBX for this object, it will be the physical-location anyway, but the registration is redirected to the registration PBX.
This only works when the registration is initially sent to the “local” PBX, no matter what numbering node or registration PBX is defined for the object the registration is attempted for. Usually, this implies that you do not configure a fixed ip address (for the gatekeeper) in the endpoint (e.g. phone). Instead, you would use gatekeeper discovery or provide the local PBXs IP address via DHCP to the endpoint.
When a registration is forwarded to another PBX for the first time, then the name of the PBX forwarding the registration is appended to the gatekeeper ID. This way, the correct physical location is passed to the registration pbx finally accepting the registration.
DECT and the physical-location
For DECT devices, one of the IP1200 (a.k.a. IP-Master) holds the endpoint registrations to the PBX (as the DECT devices itself are not IP-capable). The PBX the registration is sent to for all of the DECT devices is configured into the IP1200. This would imply that all DECT devices handled by one DECT IP-Master would share the same physical-location. This is clearly undesirable when a single DECT systems spans over more than one physical-location.
It is thus that for DECT device registrations the physical-location is always set to the regstration PBX, that is, the PBX that is configured as Parent PBX in the DECT users PBX configuration. This way, each DECT user normally its correct physical-location. However, if a DECT user carries her handset over to another location that is part of the same DECT location, then she can use it right away like "at home", however, the physical location is still assumed to be the "home PBX", not the real physical location.
Gatekeeper Id
The gatekeeper ID is defined in each PBX (“Administration/General/System Name”). It shall be identical for all PBXs in the whole PBX system.
Local Objects
Each object can be tagged as local. This means that when performing call routing, this object shall take precedence over objects with the same number in the numbering node of the calling endpoint if its physical location PBX is in the same node as the object tagged as local.
A common example would be a trunk line. All trunk lines in all numbering nodes (which usually map to branches in the companies organization) usually share the same access code, that is, they have the same Number configured. Now if a user moves to a branch office (e.g. carrying a softphone) and then dials the trunks access code, then she would normally access the trunk in her “home branch office”, depending on the numbering node she is configured in. However, this is often unexpected behavior. Instead, it is expected that a user always uses the “local” trunk. To configure this behavior, the object representing the trunk line is tagged as local.
Another example is a common numbering plan throughout all locations. That is, a numbering plan where all extensions are uniq throughout the organization. You would implementing this using a single numbering node (probably root) where all users are in. However, the trunk lines would reside in their own nodes (one per real location) and be marked local. You would have a PBX in each location which implements the node corresponding to the location. The only object in such a node would probably be the local trunk line. As the users in that location would then have this PBX as physical-location (keep in mind that all these users would probably be registered with the local pbx, although they are configured to a different node), they would use this nodes local trunk line.
Routing
The routing of calls works by applying the following rules in this precedence on each PBX the call is handled:
- The dialled number is searched in the numbering node the physical-location pbx belongs to. If there is such an object and it is tagged as local, the call goes there
- Else the dialled number is searched in the numbering node the calling endpoint belongs to. If there is such an object, the call goes there
- Else the dialled number is searched in the next higher numbering node. If there is such an object, the call goes there
- If there is no such object found, the call is passed to the PBX the PBX currently handling the call is registered with (which is defined by the Parent PBX attribute of the pbx object with the name of the PBX). The above procedure is applied recursively.
- If the call has been routed to an existing node, but there is no appropriate extension in this node defined, then if there is a Route PBX-Node External Calls to destination defined in the nodes PBX's configuration (that is, in the PBX configured for this node, if any), then the call is routed to this destination. This can be used e.g. to address a legacy PBX tied into the trunk line in this location or for non-local breakout.
- If the call has been routed to an existing node, but there is no appropriate extension in this node defined, then if there is no Route PBX-Node External Calls to destination defined in this nodes PBX's configuration or there is no PBX for this node, then if there is a Route PBX-Node External Calls to destination defined in the calling users node PBX's configuration (if any), then the call is routed to this destination. This can be used e.g. if all destinations shall be reached via IP (that is, internally within the PBX) if possible to break out to the local trunk line when the number does not exist
- If the call has been routed to an existing node, bu there is no appropriate extension in this node defined, and there is neither a PBX defined for the called nor for the calling node, then if there is a Route Root-Node External Calls to destination defined in the systems master PBX's configuration, then the call is routed to this destination.
- Else the call fails
Redundancy
The master of a registration PBX (the PBX where this PBX is registered) always acts as standby for the registration PBX. One registration PBX which is registered at a given master can be configured as standby to this master.
If the physical location of a user is different from the registration PBX this physical location will also act as standby if the connection to the master fails.
On the endpoint the local PBX (the one next to the user) has to be configured as primary gatekeeper.
As alternate gatekeeper the respective master (where the local PBX is registered) has to be configured, or a PBX which is registered at the physical location and is configured as standby.
Numbering Nodes and Escapes
Normally, when a number is called that is not present in the calling (or current) node, then it will be searched for in the next higher node implicitly. However, searching the next higher node can be forced by specifying a Escape sequence in the node configuration. 0 is a very common value for such an escape sequence.
If in a node the escape sequence is dialled, then the search for the destination is forced to the next higher node tree level. An escape sequence differs from other objects in that it may (in in practice often will) conflict with existing objects. For example, when you use a 0 as an escape, you will probably also configure a trunk object with Number 0. This will have the effect that first the node tree is searched for a specific number and if this fails, the call is routed to the local trunk.
Specifying an escape sequence disables the implicit search of numbers in the next higher node.
In practice, you could implement the worlds E.164 numbering plan (or part of it ;-) into a PBX system. You would create nodes underneath root for each country code, underneath each country you would create nodes for each area code etc. The lowest level in the node tree would then be for a trunk you in fact own. You would then configure the appropriate local escape digit as Escape. Within the physical locations you have PBXs (and thus trunk lines) in, you could implement non-local breakouts by defining a Route PBX-Node External Calls to for the node (see #5 in Routing above).
Normally, users would expect to hear a dial tone after dialling the escape sequence in the lowest tree level. This can be achieved by ticking the Dialtone checkmark in the Node configuration.
Related Articles
This article is (at least partly) redundant to the information found in some other articles. Although this introduces the risk of inconsistencies it is hoped that it nevertheless adds some value (usually, reading things twice may make it clearer)