Course11:Advanced - Distributed PBX: Difference between revisions
m (Protected "Course11r1:Advanced - Distributed PBX" [edit=sysop:move=sysop]) |
m (Protected "Course11:Advanced - Distributed PBX" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))) |
(No difference)
|
Latest revision as of 11:57, 12 October 2023
This book explains the basic methods to create a distributed PBX setup.
Basics
- 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.
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 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 placed in each physical location of a system. Sometimes, several PBXs may be placed within the same location to facilitate a higher number of registrations (i.e. serve more phones).
Intra PBX Call Flow
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 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 flat numbering plan.
However, in some cases, a structured numbering plan is desired where extensions share the same number. For example, 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 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 exemplary numbering plan, Branch A would be a node.
Node Tree
Numbering nodes are structured hierarchically forming the 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 flat, the resulting numbering node tree is trivial: it consists of 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
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
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
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
Setting up the Node Tree
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 numbering node tree example, the required node definitions would look like this:
If we extend the example to a 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
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
- 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
- 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
- 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
- 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
- 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
To call a number in the node below yours (that is towards the node tree leaves), you must 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 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 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
Setting up the PBX Tree
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 trivial numbering node tree (root node only) with a 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 straightforward PBX tree. As we have a flat numbering plan and hence a single numbering node (which is root), all PBX nodes have the root node as its Parent Node.
If we now combine both trees, we end up with a 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 choose "unlikely" numbers for these nodes, such as e.g. #11, #12 and #13.
Registration PBX
In our Berlin, New York, Tokio example, we can now finalize the complete picture. And this is what it looks like in the
Remember the root node exists by default and thus does not need to (and in fact must not) be configured.
Physical Location
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 behave as follows:
- The registration for extension 40 is sent to New York
- The PBX evaluates the object that corresponds to 40 and determines the value of its PBX property
- 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)
- The endpoint receives the redirect answer and tries again with Berlin
- 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
- Berlin requests the endpoint to refer to the head of the correct sub-tree (which is Tokio directly in our example)
- The endpoint receives the redirect answer and tries again with Tokio
- Tokio commences with step b. However, it then determines that the target PBX is itself and accepts the registration
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
- 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...
- 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
- b. ...
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 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
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
Assume that in the 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 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 move the node New York underneath SubNode.
Non-Registering Objects
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 Directory_Search or 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
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 is the notable exception?
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.
Setting up PBX Replication
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 LDAP replicator. The software component that serves the replicator's requests on the LDAP master is called LDAP server.
From firmware V8 upwards, the easiest and thus recommend method is to configure the entire replication in the
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
In many cases, you will 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 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
The replicator authenticates to the server using credentials defined in the
In this case, you must disable the PBX replicator in the
Please note that when using this replication method, Kerberos accounts will not be replicated and thus Kerberos authentication won't work.
Partial Replication
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 IP302 are installed. Replicating the full database is not an option as it would exceed the storage limitation of the IP302.
In this situation, partial replication is the solution. It is enabled in the
When you are using the manually configured LDAP replicator, you would use the PBX Name property in the
Manual Replication
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
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
Using the Phone's LDAP Client
- the local phone book (stored in the phone's persistent memory)
- the PBX directory retrieved from the PBX the phone is registered with
- an external (e.g. company wide) directory that is retrieved via LDAP
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:
- 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
Phone/User/Directories configuration. Unfortunately, this works for the phone's LDAP client, but not for myPBX (as of V10 SR11) - 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 How_to_configure_the_IP200_LDAP_client
- 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. MetaDirectory
Dialling from the PBX LDAP
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 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"
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 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.