Course10:Basic - PBX - initial Configuration

This book explains the initial configuration of a PBX.

Installing the PBX

The PBX software is integral part of the  gateways and  IP-DECT firmware. So there is no need to "install" it, as it is already there. However, in order to use it, it must be licensed and configured properly.

NB: while working through this book, we will configure a PBX scenario step-by-step. To begin with, load the  start config on to the devices. The PBX will be configured on the IP305 then. Later on, a standby PBX will be installed. Use your IP800 for this.

Licensing

Without a proper license installed, the PBX will not work. It will show up and allow configuration but phones will not be able to register. Details on licensing works is discussed in a separate book.

The  trial license will include any necessary license, so you can proceed with designing your PBX setup and play around with before you actually buy real licenses.

Licenses are  uploaded to the device in the General / License tab of the user interface.

PBX Modes

Single Master PBX

In a simple case, a PBX is running on a  single gateway device. VoIP devices involved register to this PBX. This single PBX is know as the master.

To setup a PBX as master, you need to set the PBX Mode property in the PBX / Config / General tab to Master.

Standby

To ensure maximum availability, a PBX can have a duplicate, known as standby. This is a gateway device that can take over the role of the master should it fail for whatever reason. In normal operation, a standby PBX does not accept any registrations and does nothing except monitoring the PBX it is a standby for. This is done by  registering to the active PBX.

When the active PBX fails, the standby will consider the PBX lost. In this case, the standby takes over. It will start to accept registrations and thus  become the active PBX. It will go back to standby mode as soon as the master is available again.

A standby doesn't need to be a physical duplicate of the master PBX. The only requirement is that the standby can handle as much registrations and object definitions as the failing master had, so it is able to take over. In other words, an IP800 may well stand in for an IP302.

Master / Slave

There may be several reasons to use multiple PBXs in a customer installation:

• load balancing
• enhanced availability for remote locations
• scaling

In this case, individual PBXs are setup in a  tree-like structure with one being the master. All others are known as slave. Although the PBXs form a tree, the extensions registered to those PBXs do not. In other words, any extension can be registered to any of the PBXs.

In this course, we will discuss single master / master standby scenarios only.

Registration Strategies

When a VoIP client tries to register with its PBX, it may or may not have configured the IP address of the PBX. If not, the client will try gatekeeper discovery. This allows the client to find any PBX in the local network with zero configuration. Discovery is also available in SIP, however it is rarely implemented in SIP clients (innovaphone SIP does it).

If discovery cannot identify the PBX, the PBXs IP address has to be made known to the client, e.g. by fixed configuration or by DHCP. To address fail over scenarios, the address of the standby PBX (known as alternate gatekeeper) may be configured.

When a registration has completed successfully, the client will continue to probe the PBX continuously by sending registration refreshes continuously (sometimes referred to as lightweight registration). When the active PBX fails, it will not answer to the registration refreshes. This allows the client to detect a PBX failure.

In that case, the registration is removed and the client starts trying to re-establish it. When there is no PBX IP address known, the client restarts discovery. If the PBX's IP address is known but no alternate, this address is continuously retried. If both primary and alternate are known, both are tried alternating.

If the primary PBX IP address is not configured and there is an alternate PBX IP address, then first gatekeeper discovery is tried and if it fails the alternate is tried.

PBX Failover

A standby PBX detects the availability of the PBX it stands in for by maintaining a registration to it. When the active PBX fails, the standby takes over. That is, it will start to accept registrations and thus become the active PBX. However, it will still try to re-register with its PBX.

Likewise, the other PBX clients will detect their failing registrations and will try to re-establish their registrations. This will succeed with the standby PBX now.

When the standby successfully re-establishes its registration with the PBX it stands in for, it will terminate all registrations it has and go to passive mode. The clients will re-start their normal registration procedures and will now be accepted by the original PBX again.

Shared PBX Properties

Some of the PBX configuration properties must be shared by all PBX instances (master, standbys and slaves). They are configured (amongst others) in the PBX / Config / General tab and need to be consistent through all PBXs in a system.

System Name

Identifies the PBX instances that belong to the same PBX installation. This allows to operate multiple PBXs in the same network. In H.323, this is used as the gatekeeper id. Even in a single master installation with no standby, this is required in order not to interfere with possible 3rd party VoIP entities. You should always use a meaningful name here.

In pre-V9 versions of the firmware, the System Name was a purely technical property with little influence on the operation of the system. From V9, there is the Use as domain check-mark. If this is ticked, then the System Name assumes an important relevance for IP (namely SIP) calls which leave the system (for example to a SIP provider or the like). However, this is not an issue for this course, so please leave the mark unchecked! For now, simply make it a habit to  use the customers email domain name as System Name.

PBX Password

PBX instances share a number of encrypted data, most notably user passwords. Such data is communicated in encrypted form between PBXs, so they all need to share the same PBX password.

The PBX password is used to authenticate a standby to the PBX it stands in for too.

Instance specific Properties

Each PBX instance has a number of  properties that may be configured individually in the PBX / Config / General tab. Most of them influence the handling of calls that flow through this particular PBX instance.

PBX Name

To begin with, most of the default configuration will be fine as is. There is only one property for now that should be set explicitly, the PBX Name.
It should be a short name that identifies the physical location of this PBX. So, master is not a good idea, headquarter probably is!

Required PBX Objects

A common error is failure to configure the required PBX node objects properly.

Each PBX in the PBX tree must have a corresponding  PBX type object entry in the PBX / Objects object list. This is true even if there is only a single master. Configuring a object for a PBX may be confusing sometimes, so make a habit to configure the object for each PBX you set up right away.

In the  PBX object config the (short) Name needs to match the PBX Name in the  Configuration / PBX / General tab.

For the master, the Parent PBX must be the short name of the master itself, while the Parent Node must be root.

As we do not cover multi-node or multi-PBX setups in this course, you will never use anything but root as Parent Node. Also, for nodes that represent a PBX (as the ones we discuss here), you must never configure root as the parent PBX!

Any PBX object must have a number. Unfortunately, use of this number is not that obvious for nodes representing a PBX. So for now, make a habit and use numbers that are unlikely to be needed elsewhere ever, e.g. **01 etc.

Security

There are various issues to consider regarding the security of a PBX, especially if it is accessible from the public internet. These will be covered in one of the advanced training modules.

However, in any case, you should set the  IP-Filter property for authenticated and unauthenticated registrations in the PBX / Config / Filter tab to make sure endpoints register only from within networks you are expecting them to do so!

Adding Users

In order to use a phone with a PBX, you need to create a  user object in the PBX / Objects tab.

User Object Properties

The user object is the most generic of the PBX object types, so most of its properties are actually  common properties shared by most objects. As all other objects are, it is created using the  New link next to the object type drop down in the PBX / Objects tab.

The  minimal configuration for a user consist of

• the Long Name
• the Name
• the Node
• the PBX
• at least one entry in the Devices list
  

Setting those correctly is sufficient to register a phone to this user object. However, in reality you would probably want to assign a Number (a.k.a. extension) to the user, so you can call the user by dialling a number, although this is not strictly required.

So what exactly is a Name and a Long Name? The Name is a property you can use to call a user. Technically, you can call using the destinations Name property just like you can using the destinations Number property. This is why a phone will by default show the user's Name and Number property values in its idle display (as these are the properties you can use to call the phone). In contrast, the Long Name is what is displayed at the remote end when a user does a call. The Long Name must be unique system wide. So if you want a name to be displayed with a call that is not unique, you can use the Display Name property, which overrides the Long Name then and does not need to be unique!

You may ask yourself the question how you should set all these properties for objects you create. Here is a simple rule of thumb:

• set the Name to the user's shortest email address leaving away the domain part (so if the user has an email of joe@example.com, then set Name to joe)
• set the Long Name to the user's full name (e.g. Joe Satriani). Make sure the name is unique, if not so, add a department number etc. (e.g. Joe Satriani, Sales)
• if you don't like the Long Name to be used as the display name, set a display name of your choice. Otherwise leave it empty
  

User objects (to be more precise: all objects) must not have similar extensions. So if you try to add an object and assign a Number which is already allocated to another object, the PBX will deny it. However, it will search for the next best free number and suggest it for use. So if you try to save the new object again, it will be created with the extension number found and suggested.

As phone numbers generally can be dialled digit-by-digit (overlapped sending), this also implies that one extension must not be a prefix of another. In other words: if you have an object with extension 9, then you cannot have another with e.g. 95, as 9 is a prefix of 95. The two extensions are considered similar (despite not equal).

Another important property of a user object is the  Device property. It consist of a list of pairs, the Hardware Id and the Name. If you create a new user object, the first device entry is created automatically. The Hardware Id of the object is set equal to the aforementioned mandatory attribute Name.

Within this course, as no multi-pbx or multi-node scenarios will be covered, the Node will always be root and the PBX will always be the Name of the node entry representing your single master PBX.

What a User Object is

It is important to understand that a user is not a phone. A user basically represents an extension (which is though to be linked to a user, hence the object's name).

The PBX actually does not manage devices, it manages objects that an endpoint can register with. Such an endpoint might be a phone of course. However, more than one endpoint can register with the same PBX (User) object. If this does happen, it is said that there are multiple registrations for the (User) object.

If there is no PBX (user) object, no endpoint can register. The PBX thus does not have any knowledge of existing endpoints (phones), it only knows about registrations with that object.

Linking a Telephone to a User Object

In order to use a phone, it needs to register with the PBX, more precisely, it needs to register with a PBX (User) object. When the PBX receives a registration it will try to match the provided identification with one of the Hardware-Id values of an existing (User) object. If there is a match, the registration is accepted (after potential verification of an associated password).

In fact, when an endpoint registers with a PBX (User) Object, it needs to present one of the Hardware Ids present in the Devices list as registering name. Although multiple registrations are possible using the same Hardware Id, it is best practice to  define different Hardware Idsfor different registrations (that is, registering endpoints). This way, you can  distinguish the different registrations in the Device column of the PBX's PBX / Registrations tab. Please note that Hardware Ids must be unique in your entire PBX (as they are used to identify an object during registration). The Name however does not need to be (that is, the Name in the Device list. The one in the general part needs to be unique).

As an alternative, the registration may convey the Number of an existing (User) object. In this case, the PBX behaves like if the registration came in presenting the first Hardware Id of the PBX (User) object's Device list as registration name. The same is true if the registration conveys the Name from the object's general part in its registration.

While both methods work fine, there is a problem with both of it: in order to register a phone, it needs to receive a specific configuration (either name or number). This practically requires an administrator or advanced user to get the phone in hands and do the necessary configuration.

User Passwords

In a real life environment, user objects (more precisely: all objects) which shall allow an endpoint to register with, may have a password assigned for security reasons.

In previous versions, the user/object password was used only for device registrations. Since V9, user passwords are also used by normal end users to login to their web UI (that is, myPBX). This of course implies that users will change their password once in a while. If their standard hard phone is registerered using the user password this will result in a non-functional phone, as long as the password is not changed in the device too.

To fix this issue, it is recommended to tick on the Admin Pwd check-mark next to the respective Devices entry. If this is done, registrations do require the PBX password (as defined in  PBX/Config/Security) instead of the user/object password. You would then configure the standard hard phone to use the PBX password to register.

To allow users to register other phones using their own password (e.g. to do an ad-hoc login on another telephone), you would add another Devices entry with Admin Pwd not checked.

In many installations though, this will be a non-issue if the No of Regs w/o Pwd property in the  PBX/Config/General tab is set to a value larger than 0.

Auto-Deployment

In larger installations, it is clearly undesirable to have an administrator touch each phone in order to do the required configuration. Rather, the phones should be usable with zero configuration on the phone or using a procedure which just any end-user can do.

Using the Hardware-ID

innovaphone telephones feature a so-called "hardware registration" configuration. When not configured otherwise, a phone will craft a registration name from its serial number (which is the MAC address). For this, the device types short name (which is hard-wired based on its device type) is prepended to the last 3 bytes of the MAC address.

Let us assume there is an IP200A with MAC address is 00-90-33-10-4B-AF, then a registration name of IP200A-10-4B-AF is used and a registration is requested.

As we have seen before, you could create an user object and  add an entry to the Devices list with this registration name appearing as one of the Hardware-Id. values in the Devices list. The phone would then be able to register with this user object without any extra configuration on the phone.

This allows an administrator to send out a phone to the end-user and pre-configure its Hardware-Id into the target user's PBX (user) object. The only thing the end-user needs to do is to attach the phone to the LAN.

Dealing with unknown Registrations

When configuring the hardware-id into the PBX object properties, the administrator still needs to know the serial number of each users phone. This can be tricky if impossible at all in a larger installation e.g. if the administrator does not install the phones personally.

To help here, the PBX features the ability to accept unknown registrations. For security reasons, this mode needs to be enabled explicitly in the  PBX/Config/General settings. If this option is enabled and a device tries to register with the PBX and there is no matching PBX (user) object, then the device will be registered anyway and  show up in the  PBX/Registrations list.

The administrator now has the option to copy the registration name from the list and and paste it into an Hardware Id entry in the Device list of the appropriate (user) object.

Be sure to turn off the unknown registrations when you are done. Otherwise, anyone will be able to register with your PBX!

Zero Configuration Deployment

When deploying many phones at a time, it can be tedious to relate entries in the registration screen to phones that are being deployed and thus to their appropriate PBX objects.

So when a phone registers as an unknown registration and the user then dials an existing extension (or more precisely, places a call to an existing object) and the object currently has no registrations and there is no entry in its Devices list (or the only entry in the list is identical to the object's Name) , then the PBX will write the identification that came along with the unknown registration into a new entry in the Devices list. It will then terminate the unknown registration.

The endpoint that had the unknown registration will try to re-establish its registration and this time, the PBX will find a match between the identification provided and a user entry and will accept the registration on behalf of this object.

This allows users which receive a new phone (either during deployment or as a replacement) to simply attach the phone to the network and call their own extension and they are done. If users don't know their extensions (i.e. during a new deployment when the numbering plan is new or has changed), they can call by just typing their own name or selecting their own entry from the systems user directory.

Zero Configuration Deployment does not work if the target object has a CFNR set. You will thus need to remove any CFNR as well as the old hardware-id in the Devices list before you can replace a user's phone with Zero Configuration Deployment.