Course11:Basic - PBX - initial Configuration
Jump to navigation
Jump to search
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.
In this course, we will work without licenses, using the so-called test mode. This mode can be turned on and off for any device that needs licenses inGeneral / License . When in test mode, the device is fully licensed with no limits. However, the test mode will automatically be turned of and the device rebooted after 8 hours.
In real life however, you will use real licenses of course. They are uploaded to the device in theGeneral / License tab of the user interface.
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 thePBX / Config / General tab to Master.
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.
There may be several reasons to use multiple PBXs in a customer installation:
In this course, we will discuss single master / master standby scenarios only.
In order to use a phone, it needs to register with the PBX, more precisely, it needs to register with a Device defined for a PBX 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 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 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 Ids for different registrations (that is, registering endpoints). This way, you can distinguish the different registrations in the Device column of the PBX'sPBX / 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).
Sometimes, endpoints will use an extension number instead of a name to register. So as an alternative, the registration may convey the Number of an existing PBX object. In this case, the PBX behaves like if the registration came in presenting the Name of the PBX object as registration name. In other words, to allow a registration with the PBX object's Name or Number, there must be a Device entry in the object that has its Name as Hardware Id.
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.
There are also other versions of this article available:
Course11 (this version) | Course10 | Course12
This book explains the initial configuration of a PBX.
Installing the PBX
The PBX software is integral part of the gateways 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.
While working through this book, we will configure a PBX scenario step-by-step. To begin with, load the start configurations on to the devices now by clicking onPBX_-_initial_Configuration_Lesson .
As already known from Topic 2, uploading and refresh of the involved devices may take up to 5 minutes - so please stay patient.
While working through this book, we will configure a PBX scenario step-by-step. To begin with, load the start configurations on to the devices now by clicking on
As already known from Topic 2, uploading and refresh of the involved devices may take up to 5 minutes - so please stay patient.
The PBX will be configured on the IP305 then. Later on, a standby PBX will be installed. Use your IP302 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.
In this course, we will work without licenses, using the so-called test mode. This mode can be turned on and off for any device that needs licenses in
In real life however, you will use real licenses of course. They are uploaded to the device in the
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
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 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 can 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). However, discovery works with UDP based protocols such as H.323/RAS or SIP over UDP only. If TCP based protocols are used such as H.323/TCP, H.323/TLS, TSIP or SIPS, discovery is not possible.
If discovery is not used or 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.
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.
If discovery is not used or 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.
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.
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.
Next to the System Name field, there is the Use as domain check-mark. If this is ticked, then the System Name assumes an important relevance for VoIP calls which leave the system (e.g. federation). Even if we will not expose our training PBX to the internet, you should always prepare your installation for doing so. So please have the mark checked! For now, simply make it a habit to use the customers email domain name as System Name. In this course, we use class.innovaphone.com.
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.
Next to the System Name field, there is the Use as domain check-mark. If this is ticked, then the System Name assumes an important relevance for VoIP calls which leave the system (e.g. federation). Even if we will not expose our training PBX to the internet, you should always prepare your installation for doing so. So please have the mark checked! For now, simply make it a habit to use the customers email domain name as System Name. In this course, we use class.innovaphone.com.
Don't forget to confirm your entry with OK at the bottom of the window. Upon confirmation, you will see a red Reset required link appearing below the window. This happens when changing any settings which influence the system behaviour. So please reset the device - and refresh the page when the gateway is back in service.
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 an encryption secret (password), known as the PBX password.
The PBX password is used to authenticate a standby to the PBX it stands in for too.
It is set inPBX / Config / Security . In this course, use pwd.
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 an encryption secret (password), known as the PBX password.
The PBX password is used to authenticate a standby to the PBX it stands in for too.
It is set in
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.
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!
For this course, we use - as a reminiscence to our headquarters - the name pbx-Sindelfingen.
Don't forget to confirm your entry and execute a possibly required reset!
In certain situations, the PBX needs to map numbers sent as International, National and Subscriber type of number. To this, it needs top know the various prefixes as well as the subscriber numbers of the trunk line used. As we will in this course use a (simulated ) trunk line in Sindelfingen, Germany, the values shall be 000 for Intl, 00 for Ntl and 0 for Subscriber.
These are the dial prefixes users will need to call a destination of the type in question (e.g. to call an international number +49 (7031) 73009, the user would need to dial 0 (trunk access code) + 0 (leave your own area code) + 0 (leave your own country) -> 00049703173009).
While in many installations these values will be shared by all locations (and thus PBXs), they may differ across locations (e.g. if we have locations in several countries).
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!
For this course, we use - as a reminiscence to our headquarters - the name pbx-Sindelfingen.
Don't forget to confirm your entry and execute a possibly required reset!
Prefix for Intl/Ntl/Subscriber
In certain situations, the PBX needs to map numbers sent as International, National and Subscriber type of number. To this, it needs top know the various prefixes as well as the subscriber numbers of the trunk line used. As we will in this course use a (simulated ) trunk line in Sindelfingen, Germany, the values shall be 000 for Intl, 00 for Ntl and 0 for Subscriber.
These are the dial prefixes users will need to call a destination of the type in question (e.g. to call an international number +49 (7031) 73009, the user would need to dial 0 (trunk access code) + 0 (leave your own area code) + 0 (leave your own country) -> 00049703173009).
While in many installations these values will be shared by all locations (and thus PBXs), they may differ across locations (e.g. if we have locations in several countries).
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 thePBX / Objects object list. This is true even if there is only a single master. Configuring an 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 this course, as we are dealing with a single master only, the "PBX tree" is quite simple - it consists of this one master only . So the bottom line is: we need to configure a PBX type object on the master PBX for the master PBX. And it's Long Name (and Name) must be the same as the PBX Name inPBX / Config / General : pbx-Sindelfingen.
Each PBX in the PBX tree must have a corresponding PBX type object entry in the
The Name
In this course, as we are dealing with a single master only, the "PBX tree" is quite simple - it consists of this one master only . So the bottom line is: we need to configure a PBX type object on the master PBX for the master PBX. And it's Long Name (and Name) must be the same as the PBX Name in
In the PBX object config the (short) Name needs to match the PBX Name in the Configuration / PBX / General tab.
For the master's PXB object, the Parent PBX must be the 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. #002 etc.
The Parent PBX
For the master's PXB object, the Parent PBX must be the 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!
The Number
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. #002 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 thePBX / Config / Filter tab to make sure endpoints register only from within networks you are expecting them to do so!
In this course, we will limit access to our own training network, so Addr in IP-Filter (registration without authentication) will be something like 172.31.xx.0 and the Mask 255.255.255.0.
In some installations, users will only have restricted access to phone numbers. For example, a site administrator could decide to inhibit calls to premium rate numbers. This can be done by defining one or more Call-Filter inPBX / Config / Filter and assigning those filters to individual users. By default, two filters are defined, normal and unknown. The normal filter is used as a standard if not defined otherwise for a particular user, the unknown filter is used for extensions which are not yet fully booked in to the system (we'll come back to this topic later).
For now, you can leave the normal filter as is and define the unknown filter so that calls to the trunk line are impossible (that is, as our trunk line access code is 0, set to 0->nok).
IP Filter
However, in any case, you should set the IP-Filter property for authenticated and unauthenticated registrations in the
In this course, we will limit access to our own training network, so Addr in IP-Filter (registration without authentication) will be something like 172.31.xx.0 and the Mask 255.255.255.0.
Filter
In some installations, users will only have restricted access to phone numbers. For example, a site administrator could decide to inhibit calls to premium rate numbers. This can be done by defining one or more Call-Filter in
For now, you can leave the normal filter as is and define the unknown filter so that calls to the trunk line are impossible (that is, as our trunk line access code is 0, set to 0->nok).
Adding Users
In order to use a phone with a PBX, you need to create a user object in the PBX / Objects tab.
We will see how to configure such user objects in the course of the next chapters.
We will see how to configure such user objects in the course of the next chapters.
User Object Properties
The user object is one of 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
Unless you intend to allow this user to register from arbitrary phones (hot desking), you should actually remove the automatic entry in the Devices list. It will be set later.
Also, you should check the E-mail check mark.
Finally, no object should be left with no Password for security reasons. So make a habit and assign one to every User object you create.
So we end up with a slightly modified recommended configuration.
Now go ahead and create a user with the following properties:
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 an extension using the destinations Name property just like you can using the destinations Number property. 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:
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.
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
Unless you intend to allow this user to register from arbitrary phones (hot desking), you should actually remove the automatic entry in the Devices list. It will be set later.
Also, you should check the E-mail check mark.
Finally, no object should be left with no Password for security reasons. So make a habit and assign one to every User object you create.
So we end up with a slightly modified recommended configuration.
Now go ahead and create a user with the following properties:
Field | Value |
Long Name | John Doe |
Name | john.doe |
Number | 11 |
Password | pwd |
Node | root |
PBX | pbx-Sindelfingen |
How to set all these Names
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 an extension using the destinations Name property just like you can using the destinations Number property. 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
Numbers
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).
Devices
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.
What's left
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 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 (e.g. User) object. If this does happen, it is said that there are multiple registrations for the object.
In addition to objects phones (or others) can register with, the PBX manages so-called Devices. Zero or more Devices can be configured for a PBX object. If there is no Device defined for the PBX object, no endpoint can register. So, more precisely, endpoints do not register with PBX objects, they register with Devices defined for PBX objects.
A Device has a number of properties. For now, we only look at one: the Hardware Id. This is the name that an endpoint must provide (possibly along with a password) to register with the Device and hence the PBX object.
The PBX 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 (e.g. User) object. If this does happen, it is said that there are multiple registrations for the object.
In addition to objects phones (or others) can register with, the PBX manages so-called Devices. Zero or more Devices can be configured for a PBX object. If there is no Device defined for the PBX object, no endpoint can register. So, more precisely, endpoints do not register with PBX objects, they register with Devices defined for PBX objects.
A Device has a number of properties. For now, we only look at one: the Hardware Id. This is the name that an endpoint must provide (possibly along with a password) to register with the Device and hence the PBX object.
Linking a Telephone to a User Object
Registering with a name
In order to use a phone, it needs to register with the PBX, more precisely, it needs to register with a Device defined for a PBX 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 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 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 Ids for different registrations (that is, registering endpoints). This way, you can distinguish the different registrations in the Device column of the PBX's
Registering with a number
Sometimes, endpoints will use an extension number instead of a name to register. So as an alternative, the registration may convey the Number of an existing PBX object. In this case, the PBX behaves like if the registration came in presenting the Name of the PBX object as registration name. In other words, to allow a registration with the PBX object's Name or Number, there must be a Device entry in the object that has its Name as Hardware Id.
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, should have a password assigned for security reasons.
The user/object password is not used only for device registrations. 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 registered using the user password this will result in a non-functional phone, as long as the password is not changed in the device too.
You should thus make it a habit not to register phones using the user password. There are 2 methods to do so.
Each innovaphone hardware IP-phone has a built-in certificate. This can be used to verify its identity to other devices. This allows us to configure a Device in a PBX user object that allows a registration from a single device exclusively.
To do so, you would create a Device entry whose Hardware Id is equal to the serial number of the phone and whose TLS only check-mark is ticked.
To fix this issue, the other option is 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 inPBX / Config / Security ) instead of the user/object password. You would then configure the phone to use the PBX password to register. This option is especially useful for 3rd party devices which do not have a certificate.
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. As an administrator, you should carefully decide if or if not to create such an entry. As you do not have control over the registration password (the user defines it), it presents a security risk!
To practice, configure all three variations as entries in the Devices list of the PBX User object John Doe. Use john.doe for the entry allowing ad-hoc registrations and john-doe-3rd-party for the entry allowing 3rd party phone registrations. Allow your IP111 to register based on the certificate.
The user/object password is not used only for device registrations. 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 registered using the user password this will result in a non-functional phone, as long as the password is not changed in the device too.
You should thus make it a habit not to register phones using the user password. There are 2 methods to do so.
Use the device certificate
Each innovaphone hardware IP-phone has a built-in certificate. This can be used to verify its identity to other devices. This allows us to configure a Device in a PBX user object that allows a registration from a single device exclusively.
To do so, you would create a Device entry whose Hardware Id is equal to the serial number of the phone and whose TLS only check-mark is ticked.
Use the PBX password
To fix this issue, the other option is 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
Allowing personal ad hoc Registrations
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. As an administrator, you should carefully decide if or if not to create such an entry. As you do not have control over the registration password (the user defines it), it presents a security risk!
To practice, configure all three variations as entries in the Devices list of the PBX User object John Doe. Use john.doe for the entry allowing ad-hoc registrations and john-doe-3rd-party for the entry allowing 3rd party phone registrations. Allow your IP111 to register based on the certificate.
Registrations without Password
In many installations though, this may 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 (which is the default, 1).
This property instructs the PBX to allow n (by default 1) registrations per PBX object to register without any password at all. This comes handy as the administrator does not have to deal with registration passwords for most of the telephones.
However, this obviously presents a security risk.
We therefore do not recommend to allow registrations without password. So please set this property to 0!
This property instructs the PBX to allow n (by default 1) registrations per PBX object to register without any password at all. This comes handy as the administrator does not have to deal with registration passwords for most of the telephones.
However, this obviously presents a security risk.
We therefore do not recommend to allow registrations without password. So please set this property to 0!
Setting Phones to send their Certificate
As discussed before, phones (at least innovaphone hard-phones) can send their identity in a secure fashion during registration. However, this requires use of a TLS based protocol and this in turn disables gatekeeper discovery.
So we need two settings on the phones to make registrations based on certificates possible:
So we need two settings on the phones to make registrations based on certificates possible:
- the phones need to know the address of their PBX (that is, the gatekeeper)
- the phones need to be configured to use a TLS based protocol
For backward compatibility, phones use UDP based H.323 and gatekeeper discovery by default.
Settings on the Phone
We could do these two settings on the phone (let's say the IP111) directly in
To do so, we set the vendor options Primary Gatekeeper and VoIP Protocol in
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 use its serial number (which is the MAC address, e.g 009033280075).
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.
If the PBX property No of Regs w/o Pwd. is set to a value greater then 0, the phone would then be able to register with this user object without any extra configuration on the phone.
If this property is set to 0 (which is the recommended configuration) however, the phone must identify itself to the PBX. This can be done using either a password (requires to touch the phone configuration which we want to avoid entirely) or H.323/TLS to provide the certificate to the PBX.
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 object. The only thing the end-user needs to do is to attach the phone to the LAN.
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.
If the PBX property No of Regs w/o Pwd. is set to a value greater then 0, the phone would then be able to register with this user object without any extra configuration on the phone.
If this property is set to 0 (which is the recommended configuration) however, the phone must identify itself to the PBX. This can be done using either a password (requires to touch the phone configuration which we want to avoid entirely) or H.323/TLS to provide the certificate to the PBX.
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 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 (Unknown Registrations) needs to be enabled explicitly in thePBX / Config / General settings.
If this option is enabled and a device tries to register with the PBX and there is no matching PBX object, then the device will be registered anyway and show up in thePBX / Registrations list.
The administrator now has the option to copy the registration name from the list and paste it into an Hardware Id entry in the Device list of the appropriate (user) object.
The other option is to click on the Long Name field of the registration and create a new User object in the PBX that has the proper Hardware-Id already set.
To help here, the PBX features the ability to accept unknown registrations. For security reasons, this mode (Unknown Registrations) needs to be enabled explicitly in the
If this option is enabled and a device tries to register with the PBX and there is no matching PBX object, then the device will be registered anyway and show up in the
The administrator now has the option to copy the registration name from the list and paste it into an Hardware Id entry in the Device list of the appropriate (user) object.
The other option is to click on the Long Name field of the registration and create a new User object in the PBX that has the proper Hardware-Id already set.
Be sure to turn off the unknown registrations when you are done. Otherwise, anyone will be able to register with your PBX!
It is possible to limit this function to incoming registrations from known devices. This adds a certain level of security. To do so, you need to tick the With PBX Pwd only check-mark.
Despite its name, the check-mark allows unknown registrations both from devices presenting a valid certificate as well as those presenting the PBX password.
Restricting Unknown Registrations to known Devices
It is possible to limit this function to incoming registrations from known devices. This adds a certain level of security. To do so, you need to tick the With PBX Pwd only check-mark.
Despite its name, the check-mark allows unknown registrations both from devices presenting a valid certificate as well as those presenting the PBX password.
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.
To practice, please
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.
To practice, please
- configure the PBX to allow unknown registrations from known devices
- add a new user with Number 13, Long Name Richard Roe, Name richard.roe and Password pwd
- call extension 13 on your IP222
Your IP222 should now register as Richard Roe.