Course12:Advanced - Distributed PBX

From innovaphone wiki
Jump to navigation Jump to search
There are also other versions of this article available: Course11 | Course10 | Course12 (this version)

This book explains the basic methods to create a distributed PBX setup.

Basics

There are various reasons to set up more complex PBX systems. These include amongst others:
  • increased availability in case of device failure
    PBX components are duplicated for redundancy
  • increased availability in case of network failure
    PBX components are installed decentralized in a WAN-based scenario to make sure vital call functions are still available when the network fails (sometimes known as remote survivability)
  • increased scalability for larger systems
    multiple PBX components create a uniform larger system that can handle more extensions than a single component
  • structured numbering plans
    multiple overlapping numbering plans are used to support convenient (i.e. short) dialing within a logical organization unit while retaining the ability to call cross-unit
  • PBX virtualization
    multiple logical PBXs (e.g. for different customers) are implemented on a single PBX system. With V8 this scenario can be implemented using Dynamic PBXs. However this topic is not discussed in this book.
The redundancy issue is covered in a separate book. The remaining issues are covered in this book.



System, PBX and PBX Tree

PBX and PBX System


In innovaphone speak, a PBX system is made up of one or more PBXs. A PBX in this context refers to a single innovaphone device which includes the PBX firmware component (as opposed to adapters and media-gateways which do not) and has it enabled.

PBX Tree


Multiple PBXs which are configured to form a single system are set up in a tree-like structure. Exactly one of these PBXs implements the root of the screenshot.png PBX tree and all others register with this PBX (either directly or indirectly), forming the PBX tree. The registration links between the PBXs in the PBX tree are used for passing calls between physical PBXs.

The root PBX is called the master PBX, whereas all other PBXs in the PBX tree are called slave PBX.

In most of the cases, all slave PBXs register directly to the master PBX, that is, the tree has 2 levels only. A system consists of exactly one PBX tree, so all PBXs in the system must be part of it.

If redundancy is configured for a PBX, a second PBX is configured as a duplicate stand-in for the original PBX. This is called a stand-by PBX. A stand-by PBX registers with the PBX it is a duplicate for. From a logical point of view, the stand-by PBX is not part of the PBX tree, as it is non-functional as long as the original PBX is working and vice versa.

There is an endless number of scenarios with respect to the physical placement of the PBXs in a system. Sometimes, a PBX may be screenshot.png placed in each physical location of a system. Sometimes, several PBXs may be screenshot.png placed within the same location to facilitate a higher number of registrations (i.e. serve more phones).



Intra PBX Call Flow

Each VoIP endpoint (i.e. an IP phone or a gateway) needs to register with the system in order to make or receive calls. Technically, the endpoint's registration is screenshot.png with exactly one of the PBXs within the PBX tree.

When the originating and receiving endpoints of a call are registered with different PBXs, the call needs to be passed between these two PBXs. This is done along the registration paths which form the PBX tree.

A PBX which needs to switch a call towards the recipient thus needs to know if the recipient's PBX is registered with itself, with a PBX further up to the leaves of the PBX tree, further down to the root or in a different sub-tree. The PBX will then forward the call accordingly. Also, if the recipient PBX is unknown to the switching PBX, the call will be sent upwards towards the master PBX.

As a result, calls will screenshot.png pass both PBXs the calling and the called endpoint is registered with.


Numbering Plan, Node and Node Tree

Numbering Plan


In a VoIP PBX, all entities have a distinct name that can be used to call them (this is set in the object's Name property and sometimes also referred to as H.323-Id for historical reasons). However, like in traditional PBX systems, they can also have an (optional) number to call, often referred to as extension.

In a simple case all extensions are unique, forming a screenshot.png flat numbering plan.

However, in some cases, a structured numbering plan is desired where extensions share the same number. For example, screenshot.png a customer with several branch offices may want to have short, overlapping extensions per branch office. When dialing an extension, it is interpreted in the context of the caller's branch office. Remote branch extensions are called by means of a branch dial prefix.

This creates a screenshot.png structured, multi-level numbering plan.

Node


In innovaphone speak, each scope in the numbering plan (that is, each range where extension numbers must not overlap) is called a numbering node. Each extension thus lives within exactly one numbering node.

In our screenshot.png exemplary numbering plan, Branch A would be a node.

Node Tree


Numbering nodes are structured hierarchically forming the screenshot.png numbering node tree. The root of this tree is always called root. There is exactly one numbering node tree per system. Of course, if your numbering plan is screenshot.png flat, the resulting numbering node tree is trivial: it consists of screenshot.png the root node only.

The processing of a dialed number is controlled by the numbering node tree and depends - amongst others - on the position of the caller extension's node in the numbering node tree. That is, dialing the same digit string may yield different results for different callers. For example, dialing an extension number 11 from within one branch may ring at this branches extension 11 whereas dialing 11 from within another branch may ring an extension in that branch.

Independent Trees


It is important to understand that the PBX tree and the numbering node tree are independent. As a result, there can (and often will) be more nodes than PBXs. However, there can never be less nodes than physical PBXs, as we will see later on.

Object Namespace and Naming

All objects in the PBX (users, trunk lines, etc.) share a single name space for their Names. The same is true for the objects Long Names and the Hardware Ids defined in the object Devices list. That is, you cannot have 2 objects with the same name. As a result, you cannot have 2 nodes with the same name or a PBX with the same name as a node. This is true throughout the entire PBX system, as opposed to the objects Numbers, which can have duplicates as long as they do not belong to the same node.

When creating (and thus naming) nodes and PBXs you need to be careful. Of course there are no further restrictions regarding the choice of names. However, here are some guidelines which might be useful.

Both nodes and PBXs should not have names that sound like they could be useful for normal extensions.

Nodes (if you have some other than the root node) should be named in a way that they reflect some sort of logical grouping. innovaphone Holding and innovaphone Manufacturing Ltd might be good numbering node name choices if this is how extensions are grouped.

PBXs in contrast to that, should be named to reflect rather physical properties, such as the physical location of the PBX device. Berlin and Tokio might be good choices. Or even Berlin, Kudamm 56, 2nd Floor. Some people find it convenient to prefix PBX names consistently, such as eg. PBX-Berlin, PBX-Tokio etc.


Setting up the PBX

All PBX devices which are part of the same PBX system need to have the same value for the System Name property found in PBX / Config / General.

It is usually best to use the customers email domain as value for the System Name property. So if the customer has email addresses like joe@example.com, you should set the System Name property as example.com.

Each PBX device needs to have a unique value for the PBX Name property. This value must match the Name of the corresponding PBX / Objects / PBX object in the PBX tree.

The value for the PBX Mode property is pretty obvious:

Role
PBX Mode value
Master PBX
Master
Slave PBX
Slave
Standby to a Master PBX
Standby
Standby to a Slave PBX
Slave-Standby

The Node Tree

This chapter discusses the creation of your numbering node tree by creating appropriate fish-help.png node objects in PBX / Objects.

Setting up the Node Tree

The numbering node tree (short hand node tree) is set up by creating fish-help.png Node and fish-help.png PBX type PBX objects in the PBX / Objects area.

The root of the numbering node tree is always called root and there is no way to change this. Because of this, the root node does not need to be (in fact must not be) created explicitly. It exists implicitly.

Sub-nodes of the root node (and possibly further sub-nodes below these nodes) must be created explicitly. Each nodes Parent Node property must be set to the Name of the next node further up the root of the node tree. The Parent PBX property is not normally used in the node tree definition and hence is always set to root.

In our screenshot.png numbering node tree example, the required node definitions would look like this:




If we extend the example to a screenshot.png 3 level tree, then some more definitions are required:




Keep in mind that all nodes and their Parent Node links must form a single tree with the root node being the root.

Objects (e.g. users) are placed into their appropriate node by setting their Node property to the name of this node:




General Remark: as discussed, each PBX is also a node at the same time. So a PBX can be viewed as a "specialized" node. In previous firmware versions (V8 and before), there was no PBX object at all, a PBX was just a Node object with a PBX attribute not set to root. This is why in these screenshots (which are old, admittedly), the PBXs (such as xxx) are shown as Node objects. In your firmware, they will show up as PBX objects.

Number Resolution

When a call is placed (by a phone or just any VoIP endpoint registered to the PBX), the called number is interpreted to determine the target endpoint.

Generally, the idea is quite straight forward: if a number is not found in the callers node, it is searched in the next higher node (higher meaning nearer to the root). Looking at it a little closer, the overall algorithm is as follows
  1. The caller's position in the node tree is determined (that is, the value of the Node property in the PBX object the caller is registered with) and the evaluation context is set to this node
  2. If there is a matching non-node object in the evaluation context (i.e. the calling node) (that is, an object which has a Number defined that is equal to the called number or is equal to the beginning of the called number), then this object is the target and the call is delivered to this object
  3. If there is a matching node-object in the evaluation context, then the calling node is set to this node and the number defined for this node is stripped from the head of the called number. The algorithm then resumes with step b
  4. If there is no matching object at all, and the evaluation context is not the root node, and the current evaluation context's Parent Node has not been used as evaluation context so far, then the evaluation context is set to the Parent Node of the current evaluation context. The algorithm then resumes with step b
  5. If the evaluation context is already the root node, or its Parent Node has already been used as evaluation context then there is no target
In other words, the number is searched first in your node, and then up the tree to the root. This way, you can have shared objects, e.g. a trunk line, which can be accessed from all nodes screenshot.png using the same number. The steps taken then are the same from all the sub-nodes: a, d, b.

To call a number in the node below yours (that is towards the node tree leaves), you must screenshot.png prefix the underlying nodes number. The steps taken are a, c, b.

To call a number that is in a sibling of your node, you screenshot.png prefix the sibling's node number. This works because the sibling's number is unknown in your node, so the prefixed node number will be evaluated in your parent node where it is known. The steps taken are a, d, c, b.

This of course implies that there must be no object in your node that has a number that overlaps with a sibling node's number in your parent node, and if so, you would not be able to screenshot.png call objects in this sibling node. So if you use multi-level node trees you will probably allocate a generic node prefix which is not used otherwise in any of the nodes.

The PBX Tree

This chapter discusses the creation of your PBX tree by creating appropriate fish-help.png PBX objects in fish-help.png PBX/Objects.

Setting up the PBX Tree

Much like the numbering node tree, the PBX tree is set up by creating fish-help.png PBX type objects in the PBX / Objects area. Each physical PBX must have a corresponding PBX object which has the PBX's PBX Name (defined in PBX / Config / General) as its Name.

The root of the PBX tree is referred to as the master PBX. Sub-nodes of the master PBX are referred to as slave PBX.

The master PBX as well as all the slaves must be created explicitly as PBX objects. Each PBX Parent PBX property must be set to the Name of the next PBX further up to the master of the PBX tree. Similar to a node object, the PBX object must have a number too. This number allows to address this particular PBX (we will see how this is used later on). The Parent Node property defines the position of this number within the numbering node tree (as for all other objects).

Thus the PBX tree and the numbering node tree are 2 separate trees which share the nodes that describe your physical PBXs. It is important to understand that the name of a PBX thus always is also the name of a numbering node!

3 PBX, flat Numbering Plan Example


Assume a scenario with a flat numbering plan (that is, all extensions live in the root node) and hence a screenshot.png trivial numbering node tree (root node only) with a screenshot.png number of extensions in it.

There are 3 sites though and there is a physical PBX in each of them. They are located in Berlin, New York and Tokio. The master PBX shall be located in Berlin, so we end up with a screenshot.png straightforward PBX tree. As we have a flat numbering plan and hence a single numbering node (which is root), all PBX nodes screenshot.png have the root node as its Parent Node.

If we now combine screenshot.png both trees, we end up with a screenshot.png graph with nodes, PBXs and phones in it.

As mentioned before, PBX objects must have a Number assigned. In our little scenario we have got a flat numbering plan, so the PBXs numbers are in the same scope as all the extensions. To avoid conflicts (and as users usually do not have a need to call a PBX by number), we screenshot.png choose "unlikely" numbers for these nodes, such as e.g. #11, #12 and #13.

Registration PBX

As we already know, each VoIP endpoint must register with one of the system's PBXes, otherwise it cannot place or receive calls. In a multi-PBX scenario thus, an endpoint must know where to register. This is configured in the object's PBX property. Thus such objects are part of both the numbering node and the PBX tree.

In our Berlin, New York, Tokio example, we can now finalize the screenshot.png complete picture. And this is what it looks like in the PBX / Objects list of the PBX:




Remember the root node exists by default and thus does not need to (and in fact must not) be configured.

Physical Location

As discussed, the PBX where an endpoint registers is defined in the PBX object definition the endpoint registers for. When an endpoint sends the registration request to the wrong PBX, this PBX will send a response to the endpoint which requests the endpoint to try again with another PBX.

For this, the PBX will try to determine the object's correct registration PBX. Taking the registration links within the PBX tree into account, it will redirect the endpoint either to the master (that is to the next PBX towards the root of the registration tree) or to a PBX that itself is registered to the redirecting PBX (that is up to the leaves of the PBX tree).

Let us assume that in our little example scenario, extension 40 is actually a laptop with a soft-phone. The user does a business trip to New York. When the soft-phone is started, it sends its registration request to the local PBX New York. The system will then screenshot.png behave as follows:
  1. The registration for extension 40 is sent to New York
  2. The PBX evaluates the object that corresponds to 40 and determines the value of its PBX property
  3. As this PBX (Tokio in this example) is not within a sub-tree beneath Tokio in the PBX tree, the endpoint is requested to refer to the master (Berlin)
  4. The endpoint receives the redirect answer and tries again with Berlin
  5. Berlin commences with step b. However, it then determines that the target PBX is within the Tokio sub-tree underneath Berlin in the PBX tree
  6. Berlin requests the endpoint to refer to the head of the correct sub-tree (which is Tokio directly in our example)
  7. The endpoint receives the redirect answer and tries again with Tokio
  8. Tokio commences with step b. However, it then determines that the target PBX is itself and accepts the registration
Whenever such registration redirection happens, the system will record the name of the first PBX the endpoint sent the registration request to. This name is known as the physical location of this registration. It will be shown in the registration PBX's object list as ip-addr@physical-location.:




For this to work, any endpoint must first send its registration request to the local PBX instead of having a fixed PBX IP address configured. This can be achieved using either gatekeeper discovery or obtaining the local PBX address via DHCP.

If the registration request is not redirected (because the endpoint sent the request to the correct PBX right away), the registration PBX itself is the physical location.

It is important to understand that this physical location actually is the name of a node both in the PBX tree and the numbering node tree.

Local Objects

PBX objects (not objects of type PBX!) can be screenshot.png marked as local. When a PBX evaluates a called number (see Number Resolution above), then in fact there is a new first step "a-0" in the algorithm:
  1. a-0. The callers physical location is determined and the evaluation context is set to this node. If there is a matching non-node object in the evaluation context that has its local property set, then this object is the target and the call is delivered to this object. Otherwise...
  2. a. The caller's position in the node tree is determined (that is, the value of the Node property in the PBX object the caller is registered with) and the evaluation context is set to this node
  3. b. ...
In other words, if there is a matching local object defined in the numbering node that is the physical location of the caller, then this object will hide any other object that would normally be found in the caller's scope. Note that the physical location of an object is always a PBX. Thus it does not make sense to have a local object with a Node that is not a PBX.

This is often used for locations with local trunk lines. The trunk line object is put into the numbering node of the PBX serving the location and the local flag is turned on. This way, all calls from users who are located in this location will use the local trunk when dialing the trunk prefix, regardless of their node.

Likewise, a user travelling to a remote location and carrying his phone (e.g. a soft-phone) will be able to work exactly as before as neither his numbering node nor his registration PBX will change. However, when calling the trunk, he will now access the local trunk in the location he is visiting.

In our sample scenario, let us assume we have defined an object with Number 42 in node New York which is also marked as local.




Let us also assume that the registration for Ext. 40 took place in New York, so that Ext. 40's physical location is now New York (although it is still in the root numbering node).




In the screenshot.png resulting scenario, Ext. 40 dials number 42. If 42 wouldn't be marked local, there would be no match for 42 and the call would fail. However, as Ext. 40's physical location is New York and there is an object with Number 42 in node New York, the call is delivered.

It is important to understand that the call routing does not depend on the object's PBX property, that is, on the PBX the endpoints registers with. We can move both Ext. 40 and 42 to other PBXs and the experiment will still work as before!


Addressing "remote" local Objects

Now, what if in our screenshot.png sample scenario another extension that has not got New York as physical location wants to call the local object 42 in node New York?

For example, if Ext. 30, which is in the same node as Ext. 40 is (root) but registers with PBX Berlin wants to call the same object Ext. 40 is calling when dialing 42?

As Ext 30.'s physical location is Berlin, when 42 is dialed this number is searched for in the Berlin (being the physical location) node and the caller's node, which is root. However, there is no object with number 42. So the call will fail. If Ext. 30 prefixes the New York node's number (which is #12) and calls #1242, then #12 is found as a matching object in the root node. As it is a node, the node prefix is stripped from the called number (as per step c. in Number Resolution above) and the remaining digits are searched for in the New York node.



Calling from local Objects

Some thoughts are required to understand how calls from local objects work.

Assume that in the screenshot.png previous example, the Local Object in Node New York is a trunk line and there is an incoming call through it, say to 40.

The PBX's evaluation context would be set to New York (as this is the object's Node). There is no object with Number 40. So the evaluation context would move down to root. There is an object with Number 40, so the call is delivered to this object. Although this is what we expect, please note that the physical location of this object does not matter here.

Now let us assume, the setup is a little different and 40 actually screenshot.png is in a sub-node of root. Again, an incoming call to 40 would not find a matching object in the New York node. But then, it would not find a matching object in the root node either. So the call would fail. This is true although the call from 40 to 42 would still be delivered to Local Object in Node New York.

Care must be taken to position the local object's PBX appropriately within the numbering node tree!

In our example, the fix is to screenshot.png move the node New York underneath SubNode.

Non-Registering Objects

There are object types that work without any endpoint registering to it. While for example a normal extension probably will not work if there is no phone registered for it, a Waiting Queue object works well without anything registering on it (in fact, it is not recommended at all to register on a waiting queue).

Calls to such objects are handled by the PBX set in the objects PBX property itself. They are delivered to the target PBX just like calls to normal objects are. However, at the target PBX, the call is handled within the PBX instead of being delivered to a registered endpoint.

Multi-Homed Objects

Empty PBX


Objects may have an empty value in their PBX property. In this case, when a call is to be delivered, each PBX will consider itself as the target PBX. The object still lives in the numbering node defined in its Node property and standard number resolution rules apply. However, once the object to deliver the call to has been determined, the PBX handling the call will consider itself as the target PBX.




In other words, calls to such objects will always be handled by the PBX defined in the caller's PBX property (as this is the one the calling endpoint will register with and thus the one which will evaluate the called number first).

Empty Node


Objects may have an empty value in their Node property. In this case, when evaluating a called number, each PBX will consider such an object as if its own node was configured as Node. Such an object thus exists in each node that is also member of the PBX tree.

Empty PBX and Node with Local Flag


It is recommended to set both PBX and Node empty and set the Local flag to create objects which are available to all callers in all nodes through the same number. This is especially useful for objects such as fish-help.png Directory_Search or fish-help.png DTMF_Features which should be available universally.

Just putting it to the root node doesn't do the trick:
  • it could be hidden by objects with same number in sub-nodes of root
  • the object must always be implemented in the caller's registration PBX, as it needs knowledge about all of the callers current calls

Groups

PBX groups are used with many PBX objects. It is fundamental to understand that with two notable exception, groups are restricted to a single registration PBX!

Two objects that do not register with the same PBX cannot normally be member of the same group. If you configure the same group for users with different registration PBXs, then you in fact configure 2 different groups with the same name (although this of course is not recommended!). The reason for this is, that a PBX does not necessarily (e.g. in a scenario with partial replication of user data) know the group assignments for remote users.

This sounds like a severe limitation, but it is not. Keep in mind that number resolution does not depend on the PBX the calling object is registered with. Given that, you can always change a PBX object's PBX property to the PBX property of another object if you want both of them to be in the same group.

So what are the notable exceptions?



From firmware version 9 on, there is a new subscription mechanism which allows endpoints to subscribe for the presence and dialog info state of a (possible remote) user. This is used for partner function keys on the phone and within the web-based unified communication client myPBX. With this technique, a user will convey his own group properties to the target PBX of the subscription (that is, to the remote user's PBX) so this PBX can match the groups. However, this works for said subscriptions only - all other group based functions still have the restrictions mentioned above.

The same mechanism can be used to subscribe to a group instead of a user (you would then subscribe to the name .groupname if the group is called groupname) with a partner key. In this case, the PBX will send dialog-info for all users in the group to that subscription. Even more, if this PBX is a slave PBX, it will in turn create a subscription to the master for the group. This way, all group-related dialog-info is sent to the master PBX which distributes it in turn to all slaves. See also fish-help.png Concept Group Pickup across PBXs.

Setting up PBX Replication

For number resolution and call routing purposes, all involved PBXs need to know the numbering node tree as well as the PBX tree and the calling and called objects.

Sharing this information is implemented by means of PBX replication.

With replication, a PBX entertains an LDAP connection to another PBX and retrieves the full object database as well as any updates. The querying PBX is known as LDAP slave, whereas the PBX keeping the master database is referred to as LDAP master. The software component that replicates the database from the LDAP master to the LDAP slave is called fish-help.png LDAP replicator. The software component that serves the replicator's requests on the LDAP master is called fish-help.png LDAP server.

From firmware V8 upwards, the easiest and thus recommend method is to configure the entire replication in the PBX / Config / General tab. You just set the Replication property to the desired value.

This simplified replication will always replicate from the master PBX (so the master PBX will also become the LDAP-master). Also, the replicator will then use the special account _PBX along with the PBX password as LDAP credentials. This will work if the LDAP-master (in this case the master PBX) also runs V8 or later - even though this user is not configured in the Services / LDAP / Server tab, as this account is pre-defined with read/write access!

In many cases, you will screenshot.png use the master PBX as LDAP master. The slave PBXs will then also work as LDAP slaves.

Please note that all PBXs, LDAP master and LDAP slaves, will run an LDAP server. Because of this, an LDAP replicator may screenshot.png retrieve its information from another LDAP slave (which in turn retrieves its information either directly or indirectly from the LDAP master).

Objects can be created and removed on the LDAP master only. However, changes to objects can also be done on the LDAP slaves. Full administration thus can be done only on the LDAP master.

Manual LDAP Replicator Configuration



There are only a few cases were you want to configure LDAP replication manually. One is when you upgrade a pre-V8 system and you don't want to touch the configuration. The other is when you run a really large system and want to use a system as LDAP-master which is not the master PBX to remove the replication load from the master PBX. This can be configured in the Services / LDAP / Replicator tab.

The replicator authenticates to the server using credentials defined in the Services / LDAP / Server area of the LDAP master. The replicator requires read and write privileges on the server as it needs to be able to migrate back changes that have been done to objects on the LDAP slave. You thus need to create an account for replication as the standard ldap-guest account will not do.

In this case, you must disable the PBX replicator in the PBX / Config / General tab! This is especially important if you upgrade a box from pre-V8 to V8 or V9 firmware.

Please note that when using this replication method, Kerberos accounts will not be replicated and thus Kerberos authentication won't work.

Partial Replication

In many cases, it is best to replicate the full PBX object database to the LDAP slaves. However, in some cases, this is not possible.

Network traffic may be one thought, however, LDAP replication consumes only little bandwidth so that this is rarely a real problem. However, think about a scenario where there is a huge head-quarter with thousands of users and some small branch offices with only a few users each. The PBX object database is huge (say 9000), but in each branch office, since there are only a few users, smaller PBX devices such as the IP411RIGHT are installed. Replicating the full database is not an option as it would exceed the storage limitation of the IP411RIGHT.

In this situation, partial replication is the solution. It is enabled in the PBX / Config / General configuration by setting the Replication property to Local. This will limit the replication to just those objects that need to be known by the slave PBX in order for the number resolution and call routing to work.

When you are using the manually configured LDAP replicator, you would use the PBX Name property in the Services / LDAP / Replicator tab.

Manual Replication

There are situations where automated replication is not desirable.

For example, there could be a multi-site PBX system where each site has its own administrator and administrative access to remote PBXs is not permitted. In a replicated scenario, as LDAP slave administrators are not able to create or delete objects, a site administrator would not even be able to create local extensions. Although this scenario should be handled by creating restricted administrative accounts for the LDAP master PBX, it could be solved by maintaining separate and independent PBX object databases on the master and slave PBXs.

Another scenario might be if the total number of objects in the system exceeds the number of objects that can be handled by even the largest innovaphone PBX device. Imagine a system with 50.000 extensions. This could be handled using e.g. 10 IP2000 PBXs covering 5000 users each. In such a scenario, each PBX would have a separate and independent PBX object database keeping their own objects only.

Implications on Number Resolution

When a PBX performs number resolution, it needs to have access to all the relevant objects in the object database. However, in a non-replicated scenario, not all of the information may be present.

The PBX will thus try to determine if
  • the addressed object is known by the PBX itself. In this case, the call is delivered accordingly
  • the addressed object is unknown but might be known to a PBX that is with a sub-tree of this PBX in the PBX tree. This is assumed if the evaluated number matches the Number property of a PBX in the PBX tree that registers with the current PBX. In this case, the call will be forwarded to this slave PBX
  • if the current PBX is a slave PBX, that is registered to another PBX. In this case the call is forwarded to this (master) PBX
Making this work can become tricky and tedious as all the relevant objects must be configured manually in each PBX and kept in-sync. However, a simple rule of thumb would be to define the complete numbering node tree as well as the PBX tree in each PBX in addition to all local objects.

Using the Phone's LDAP Client

The IP phones feature a pretty fish-help.png sophisticated directory feature which supports outbound dial-by-name as well as name resolution for inbound calls. There can be 3 different sources for directory entries:
  1. the local phone book (stored in the phone's persistent memory)
  2. the PBX directory retrieved from the PBX the phone is registered with
  3. an external (e.g. company wide) directory that is retrieved via LDAP
In fact, the second and third one are technically very similar: 2 instances of an LDAP client are present in each IP phone. The only difference is that the configuration of the second one is derived automatically from the phone's registration. In particular, the client is configured so that it connects to the LDAP server on the PBX the phone is registered to.

In a normal, fully replicated scenario, the phone directory will thus have access to all PBX objects. However, when the PBX is replicated partially only, the directory will only be able to show those entries that have been replicated to the registration PBX. In most scenarios, users will not consider this sufficient. There are 3 solutions to this problem:
  1. the PBX directory (2.) is configured to use the PBX maintaining the master copy of the PBX object database. This can be done by setting the Address and Gatekeeper Identifier properties of the fish-help.png Phone/User/Directories configuration. Unfortunately, this works for the phone's LDAP client, but not for myPBX (as of V10 SR11)
  2. the PBX directory (2.) is not used. Instead, the external directory (3.) is used and configured to access the PBX maintaining the master copy of the PBX object database. See chapter innovaphone PBX in fish-help.png How_to_configure_the_IP200_LDAP_client
  3. A 3rd party LDAP server is used to consolidate all company address information including the PBX user list into a single database. This one is then configured to be the target for the external LDAP directory (3.), e.g. fish-help.png MetaDirectory
In a large installation, using the master's LDAP as target for all phone directory clients may impose considerable load on the master. You may thus consider using the master standby PBX (if you have one) instead. The standby always maintains an up-to-date copy of the master's LDAP database, it can server the clients as good as the master can.

Dialling from the PBX LDAP

Looking at the PBX object list reveals that it stores actually 2 properties which determine the objects number: Number and Node. The Node is used to determine the prefix which needs to be dialed if the caller is in a different node than the called object. The Number then selects the object within the node.

In fact, determination of the prefix to be dialed to address the target objects node is non-trivial. Even more, it depends on the callers position in the numbering node tree. The LDAP directory however will return the same number to any requester, regardless who it is. In fact, it merely returns the value of the Number property, that is the local extension within the node. The phone however has no knowledge about the PBX system's numbering node tree, so it cannot do the determination either.
In addition to the Number attribute, the PBX-LDAP-server will return also a LDAP-attribute called otherTelephoneNumber. This otherTelephoneNumber is the complete number of the object, starting from the root node. This means that it contains all node prefixes, the numberstructure is node + sub-node + number of object.
innovaphone phones will use this otherTelephoneNumber for making calls to users retrieved from the PBX directory.

This of course implies that there must be no object in your node that has a number that overlaps with a sibling node's number in your parent node, and if so, you would not be able to screenshot.png call objects in this sibling node. So if you use multi-level node trees you will probably allocate a generic node prefix which is not used otherwise in any of the nodes.

Implications on "Zero Configuration Deployment"

For Zero Configuration Deployment, the PBX's Unknown Registrations feature must be turned on (in PBX / Config / General) and the user has to call "his own" extension to link the calling phone to the user object.

This works as if the feature is turned on, the PBX allows endpoints with unknown credentials (i.e. registration name) to register on the pseudo-object _UNKNOWN_. Being registered this way, the endpoint is able to place a call to the PBX object it wants to link to.

However, the _UNKNOWN_ object is considered to live in the root node. As a result, to address the object the endpoint wants to link to, a number must be dialled as if the target object would be called from an object which lives in the root node. Practically, this means that the desired extension must be prefixed with all Numbers of all nodes from the root of the numbering node tree to the node the target object lives in.

Looking at our screenshot.png structured numbering node tree example, if a phone needs to be linked to Ext. 20 in node Branch B, 8220 needs to be called.

The zero configuration deployment works if the first of the PBXs from the PBX the initial registration comes in up the PBX tree to the master PBX that has the Unknown Registrations feature enabled knows about the target object. Practically, either the slave or the master PBX must have the feature turned on.