Course13:IT Advanced - 03 PBX - initial Configuration

This book explains the initial configuration of a PBX.

PBX and Application Platform

In the IT Connect training we have seen how to install, configure and maintain the system using the tools and interfaces provided by the Install and all the Apps available in myApps (which are implemented either as part of the PBX firmware or on the Application Platform).

In this book however, we will look at the details of the PBX and gateway components more deeply. Therefore, we will setup the system using the advanced user interface of the components (as available in the Devices App or directly through the web server built-in to each device).

Some of this stuff will sound familiar to you because you have worked through the The individual Device User Interface book during your IT Connect training. So this will be a recap partly but we will also go in to some more detail.

Access to the advanced UI

As said before, we will proceed with installing an entire system without using the Install facility. When we access the device however (for example using http://172.31.31.2/), the Install will be shown. So we need a way to bypass it. You of course still remember from the IT Connect training how to do that: you add the path admin.xml?xsl=admin.xsl to the URL. The default administration user is called admin and the password is ip411.

In real life, the first thing you would do is to generate a strong and secure password (you may want to try one of the many online secure password generators,  www.lastpass.com: password-generator for example), print it out, hide it in your strongest safe and set it in General / Admin. However, in the course, you don't do this! Instead, you leave the default password untouched.

Note that passwords in the innovaphone system must not be longer than 15 characters.

Installing the PBX

To begin with, we will setup a fresh PBX system using the advanced user interface (that is, we will not use the Install as we have done in the IT Connect training). This gives us the chance to have a decent look at all the details which need to be configured and understand what the Install is doing for us. Also, we will discuss various features which are not available by merely using the Install and the PBX Manager user interface available in myApps.

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 - if you have not yet done so - load the start configurations on to the devices now by clicking on A_look_at_the_system_architecture.

As already known from Topic 2, uploading and refresh of the involved devices may take up to 5 minutes - so please stay patient. Your devices page should look something like this then:

 devices page when devices are online

The PBX will be configured on the IP411LEFT during the course.

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.

In this course however, 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 General / License. When in test mode, the device is fully licensed with no limits. However, the test mode will automatically be turned off and the device rebooted after 8 hours. Also, to start test mode, a  reset is required.

In real life however, you will use real licenses of course. There are several options to install licenses:

• You can download a license file from  my.innovaphone.com and  upload it to the device in the General / License tab of the user interface
• If you have configured the box in your  my.innovaphone.com, you can  have your box download your licenses directly. his of course requires your box to have access to the public internet and you need to enter your my.innovaphone.com credentials into the device.
• If you have configured the box in your  my.innovaphone.com, you can rent licenses. In this case, licenses are made available on your system subject to payment of a rental fee. See  Concept Software Rental and  Software Rental Guidelines (currently V13) for details
  

Working with my.innovaphone is beyond the scope of this book. There is a decent tutorial available at  www.innovaphone.com: myTutorial as well as a  wiki article. For details on the available licenses, see the  the latest innovaphone Licensing Guidelines (currently V13r2).

PBX Modes

A PBX can run in one of the following modes:

Master

In a simple case, a PBX is running on a  single gateway device. VoIP devices involved register to this PBX. This single PBX is known 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 and click OK.

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 IP811 may well stand in for an IP411.

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 and register with the master (well, in fact, you can also create multi-level PBX trees but this is a rare case). 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.

Standby/Slave

A PBX in Standby/Slave mode is a standby to a Slave mode PBX.

As a matter of fact any PBX system always has a master PBX. If there are no slaves, the setup is known as single master scenario. If there are slaves, the setup is known as master/slave scenario. In both scenarios, standby PBXs can be added to all or some of the PBXs.

In H.323-speak, Master and Slave mode PBX's are sometimes referred to as Primary Gatekeeper whereas Standby PBXs (as well as Standby/Slave PBXs) are known as Secondary Gatekeeper.

In this book, we will discuss single master scenarios only. Master/slave scenarios are discussed in-depth in a later course.

Shared PBX Properties

Some of the PBX configuration properties must be shared by all PBX instances (master, standbys and slaves). They are configured (among 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. In almost all situations, you will  use the customers domain name here (e.g. dvl-ckl2.net). Therefore, you will also set the Use as domain check-mark.

Strictly speaking, you do not need to set the Use as domain check-mark. You could as well configure all users (more precisely: all callable objects) with their full domain name (like john.doe@dvl-ckl2.net). This would allow you to have users from multiple domains in a single PBX. However, in real life, you don't do that.

In H.323, the System Name is used as the gatekeeper id. This information might be useful to you when you configure VoIP endpoints. Also, this gatekeeper id is used to route VoIP connections through innovaphone's Reverse Proxy (which will be discussed later in this course).

In any case, you must set it so that it could be a DNS name. As a simple rule of thumb, only use A-Z, a-z, 0-9 as wells as . (dot) and - (hyphen). The Username must not start with a . (dot) however. Note that identifiers such as System Name are case-sensitive in many places. Therefore, while you can use upper and lower case letters, you must make sure that you use the same spelling everywhere (or use lower case letters only in the first place, which is what we recommend)

So go ahead and configure dvl-ckl2.net as System Name in PBX / Config / General and also tick the Use as domain check-mark now.

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 behavior.

Of course you could reset the device and refresh the page when the gateway is back in service. But here is a little trick to deal with the Reset required message a bit quicker: you can also  turn the PBX off and on again. In this case, the new settings get effective and no reset is required Unfortunately, this only works for the settings found in PBX / Config / General.

So do the little trick now to activate your changes without a reset.

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 encrypt PBX user passwords and also to authenticate a standby to the PBX it stands in for. So it needs to be set to the same value on all the PBXs in a system obviously. The Install would generate a random and strong password and you should do the same in real life. However, in this course it is more convenient to use a simple password so your trainer can help you easily in case of wrong configuration

 Set the PBX password to ip411 in PBX / Config / Security.

Unknown Registrations

Turning on  the Unknown Registrations check-mark enables a special PBX mode known as Zero Administration Deployment (ZAD). This was a common method to register phones to the PBX in previous versions of the PBX. We do not recommend to use this anymore.

No of Regs w/o Pwd.

The  No of Regs w/o Pwd. setting allows registrations to the PBX even without valid credentials. This is a legacy feature and seen as a security risk nowadays, so make a habit to always

set the No of Regs w/o Pwd. to 0

Enable External Transfer

When users have an external call and create a second external call (a.k.a. consultation call), they might want to transfer both like with internal calls. In some installations however, this is seen as a risk as the transferred call is still charged to the local trunk line but cannot be controlled (more specifically: terminated) anymore. This feature must be turned on explicitly therefore.

To do so, the Enable External Transfer check-mark has to be set. As this is usually a system policy (as opposed to a location- or site-policy), the check-mark should be set the same way in all PBXs.

In this course, our policy is to allow external call transfers. So tick the Enable External Transfer check-mark.

This check-mark is also ticked by the Install as most users will consider it a bug if this doesn't work. So be sure you turn it off when your customer's system policy differs.

Prefix for Intl/Ntl/Subscriber

In certain situations, the PBX needs to map numbers sent as International, National and Subscriber type of number. To do this, it needs to know the  various prefixes of the trunk line used.

As we will in this course use a (simulated ) trunk line in Mannheim, Germany, the values shall be 000 for Intl, 00 for Ntl and 0 for Subscriber.

Even in a multi-PBX system, all PBXs must share the same settings for this. You may think but what if I need different settings in different locations? We will see how this can be handled later on, when we discuss multi-node systems.

Country-Code/ Area-Code/Subscriber

The system sometimes needs to perform some number normalization. For this, it needs to know some number properties of the trunk line, namely  area- and country code.

With our simulated SIP trunk we're using in this course, the area code has to be set to '621' and the country code to '49'.

You can also put the subscriber number into the Subscriber field, or even the maximum length of extensions (Max. length internal number). However, in many cases this will not be necessary, so we leave them alone. Also, the Install won't set them.

As before with the various prefixes, even in a multi-PBX system, all PBXs must share the same settings for this.

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.

Many of the default settings are fine as is. However, some need to be changed.

PBX Name

One property that needs to be set explicitly is the PBX Name. It must be unique throughout the system, so no slave must share the name of the master (and of course neither the name of another slave). Except however, that a standby to a (master- or slave-) must share the name of the PBX it shall stand-in for of course.

Although you may call a PBX just whatever you want, we recommend the PBX Name should be a short name that identifies the physical location of this PBX. So, master is not a good idea, headquarter probably is!

Also, you should avoid names with country specific letters, spaces etc. Just think of it as something like a DNS name and make sure it consists of characters that are valid in a DNS name too. So it should contain only the ASCII letters 'a' through 'z', 'A' through 'Z', the digits '0' through '9' and the hyphen-minus character ('-'). Again, using lowercase letters only simplifies your life!

For this course, we use the name hq.

PBX Name/DNS

Enter the  DNS name (FQDN) you created in the DNS server for your PBX in to the DNS field. Strictly speaking, this is not really required as long as you do not intend to allow external access to your PBX. However, more or less each of your customers will eventually ask for this feature. So we strongly recommend to configure it from the very beginning (and it is quite a pain to change the installation later on from IP-only to DNS name driven).

As we use hq as PBX Name and dvl-ckl2.net as System Name, the DNS name has to be hq.dvl-ckl2.net.

But my customer has no domain name

If your customer currently has no domain name, we recommend to discuss with the customer if he is sure not to want one in the near future. It might be the right time now to get one. If the customer still is not interested, consider to assign a subdomain of your own domain (e.g. customer1.yourdomain.tld, the PBX's domain name then would be hq.customer1.yourdomain.tld).

IP address for App Platform

DNS names are frequently used throughout the system configuration, especially for URLs pointing towards your Application Platform (AP). Often, the DNS system is not yet properly set up while you are installing the system. To work around this, you may enable what is known as the DNS-less Install mode. In this mode,  references to the DNS name of your AP are replaced by the IP address of your AP on the fly. To enable this mode, configure the DNS name of your AP in IP address for App Platform/DNS and the IP address in IP address for App Platform/IP and turn on the Operation without DNS check-mark.

Once the DNS is set up properly, be  sure to turn off the Operation without DNS check-mark again and remove the DNS and IP address from IP address for App Platform. The DNS-less Install mode is not meant to be used in normal operation!

In the course, our DNS has been setup auto-magically (in your IP411RIGHT) so we do not need to turn on the DNS-less mode.

All other properties on this page can be left as is for now.

Device Name

At this point you may notice that your browser shows  YourName-IP411LEFT: (empty) as title for the browser tab.

This name is taken from the Device Name value for each device. This can be set in General / Admin.

Required PBX Object

A common mistake is not configuring the required PBX node objects properly.

In a multi-PBX system, all PBXs are arranged in a so-called  PBX tree where leaves (a.k.a. slave PBXs) are registered to the master PBX (even more: the  PBX tree may consist of several levels so that a slave PBX is registered to another slave PBX which is registered to the master).

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 an object for a PBX may be confusing sometimes, so make it a habit to configure the object for each PBX you set up right away.

Note that standby PBXs are not reflected in the PBX tree. This is because they are not separate entities but merely replacements for and exact copies of their respective siblings.

Since we are dealing with a single master only in this topic, 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.

So let us  create a new PBX object for our master PBX as outlined in the following sections.

Name

The Name (and Long Name) name of the PBX object must be the same as the PBX Name in PBX / Config / General.

In our scenario, it has to be hq therefore.

We recommend to set Name and Long name equal, as there is no use in choosing different names and it is just confusing.

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

Parent node

For now, we won't deal with multi-node PBX system but we will stick to single-PBX, single node systems. The only node we use therefore is the root node and you will never use anything but root as Parent node for a PBX.

So set  root as Parent Node for your new PBX object.

Parent PBX

For the master's PBX object, the Parent PBX must be the Name of the object itself (in other words, in the PBX tree the master PBX is the one with the Parent PBX attribute pointing to itself).

So set  hq as Parent PBX for your new PBX object.

Number

Any PBX object must have a number. Unfortunately, the use of this number is not that obvious for nodes representing a PBX. So for now, make it a habit and use a number that is unlikely to be needed in your dial plan ever, like numbers which start with a star (*) or hash (#).

We will use **1, so set  **1 as Number for your new PBX object.

Password

Above we stated "slave PBXs are registered to the master PBX". For this to work, slave PBXs must use the master's Name and Password for the registration. This is not only true for slaves, but also for standby PBXs (which also need to register to their sibling in normal operation).

Make sure you use a strong password here (like the one the Install generates for you).

In this course however, we use a simple password to make sure your trainer can help you with the configuration at any time. So set the Password (as well as Retype password) to ip411 here.

---

You can leave all other fields in this tab as is.

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 a later topic in more detail.

Note that these settings need to be made and kept up-to-date on each PBX in the system (in case of a multi-PBX system). In other words: they are not replicated. So they are quite similar to the shared properties we talked about above. However, they do not have to be exactly the same. In some cases, it may be useful to set them differently.

Registrations: IP Filter

In any case, you should set the  IP-Filter property for registration without authentication and registration with authentication in the PBX / 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 registrations to our own training network (both for authenticated and un-authenticated registrations which should not be possible anyway due to the setting of No of Regs w/o Pwd.)

So set Addr in  both IP-Filters to 172.31.31.0 and Mask to 255.255.255.0.

Calls: 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 is done using Filters and we will discuss this in-depth later.

Access to the advanced UI: Allowed stations

Access to the advanced UI is critical and should be kept secure obviously. For this, we can restrict access to the device's HTTP server using the Allowed stations properties in Services / HTTP / Server tab.

You could set Address to 172.31.31.0 and Mask to 255.255.255.0, as we did for the registrations before. However, for practical reasons it is useful to allow your trainer to access your devices too. For this reason,

Set Address to 172.24.0.0 (or 172.31.31.0) and Mask to 255.248.0.0

In real life you would set it to the network and mask used in your customers network, which will be given to you by the network administrator.

Note that this is not blocking access to the advanced UI through the Devices App. Since you would use access via Devices in normal operation, you could restrict this mask to those stations that you would only use for direct access to the advanced user interface in an emergency. However, clients like myApps and also the TAPI CTI driver use HTTP to access the PBX. The mask you enter here must therefore include all computers on which myApps or a TAPI driver is installed.

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.

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.

Technically, the minimal configuration for a user consists of

• the Long Name

Anything else is optional. However, in almost all cases, you will also set

• the Name
• the Node
• the PBX

This is also the minimal configuration the UsersAdmin App requires in order to create/modify a user object (in other words: the UsersAdmin App  would complain about missing fields when you try to save such a 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 dialing a number, although this is not strictly required.

Now go ahead and  create a user with the following properties:

Field	Value
Long Name	John Doe
Name	john.doe
Number	14
Password	ip411
Node	root
PBX	hq

Using phones

Using this configuration, the user still cannot do phone calls (neither with a hard- nor with a soft-phone). More precisely, no phones can register on behalf of the user.

For this to work, you need to add at least one device to the user's  Devices list. An entry in the Devices list is essentially a name that can be used to register a device (such as a hard- or soft-phone). This name (given in the Hardware Id property of the device entry) then could be used to configure the registration on a phone. In normal operation with an innovaphone phone, you would use the phone's serial number (such as 009033280075 or IP111-28-00-75). We will look in to this later.

For historical reasons and in contrast to the operation of the UsersAdmin App, the advanced user interface  will automatically create an entry whose Hardware Id equals the user's Name property (john.doe in our case).

Unless you intend to allow this user to register from arbitrary phones (hot desking), you should actually remove this automatic entry in the Devices list.

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 e.g. at the remote end when a user does a call. Both Name and 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).
  
  In any case, you must set it so that it could be a valid user-part of a SIP-URI. As a simple rule of thumb, only use A-Z, a-z, 0-9 as well as . (dot) and - (hyphen). The Name must not start with a . (dot) however. Although it is not strictly required, we recommend to use no upper-case letters
  
  
• set the Long Name to the user's full name (e.g. Joe Satriani). Make sure the name is unique throughout the system. If the pure name is not, add a department name or similar (e.g. Joe Satriani, Sales). There are no character restrictions for the Long Name but for practical reasons, we recommend to use 17 or less characters
  
  
• 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. The display name does not need to be unique
  

In many parts of the system, a user is identified by its Name property. For example, if you change a user's Name, most App data (chat messages for example) will get lost. We therefore recommend to avoid changing the Name property. However, changing Long Name or Display Name is ok.

Number

The Number property actually defines the user's phone extension.

User objects (to be more precise: all objects) must not have similar extension numbers. 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 (you already have seen such a mechanism in the UserAdmin App). 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 dialed 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, you cannot have another with e.g. 95, as 9 is a prefix of 95. The two extensions are considered similar (despite not equal).

Email

In certain situations, the PBX needs to know the users email address. You can enter this to the  E-Mail field. However, if you follow our recommendation to use the local part of the user's email address for the user's Name property, you can simply tick the check-mark next to the user's name just in front of the E-Mail field. This will tell the PBX to always use whatever is in the user's Name field as email address (the domain part is taken from the PBX's System Name field as we have ticked the Use as Domain check-mark before).

Tick the john.doe  check-mark next to the E-Mail field

The check-mark is only available if a Name is set. So you need to click on Apply after setting the Name to make it available

Password

Of course, an object's password should be as strong as possible. This applies to any type of object, not just Users. Again, you can use a secure online password generator to create a secure password.

Please note that you as an administrator may choose any password here, regardless of a password policy you may have set for your system (we will discuss password policies later).

If No of Regs w/o Pwd. is set to 0 you do not have to configure a password. In fact, it is better to leave it empty because the No of Regs w/o Pwd. option foreces a password. This way no registration is possible if no password is configured.

Node/PBX

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.

As you can see, these are actually the default settings. So no need to change either of them.

Filter / Diversion Filter

When you switch from the General tab to the User tab, you can (and should) set the Filter and Diversion Filter properties to one of the filters you defined before.

However, as we haven't defined filters yet (we will do this in the next book), we can leave those fields empty.

What's left

All other properties in both the General and the other tabs can be left empty for now.

---

So we end up with a slightly modified  recommended configuration.

Controlling registrations

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

The PBX manages many types of objects that an endpoint can register with. Such an endpoint might be a phone of course but it could also be a gateway interface, a door intercom etc. However, more than one endpoint can register with the same PBX object. If this does happen, it is said that there are multiple registrations on that object.

As we have seen, Devices need to be configured if a registration shall be possible on an 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. By default, multiple concurrent registrations of endpoints can use the same Devices entry.

Call handling

When a call comes in for a user, it is sent to all the registered devices for the user. When any of the registered devices calls out, the users Name and Number is sent (in other words, the remote end does not see any differences between calls from devices registered to the same user).

Device properties

A  Device has a number of properties:

• 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. It should be clear that it needs to be unique through all Device entries in all PBX objects in the whole system
  
• Name. This is a user friendly nickname for the Device. It is shown in end-user interfaces and does not need to be unique (for example, you could have a Device for each user that has the respective phone serial number as Hardware Id (unique) but always My Deskphone as nickname
• App. We will look into this later
• PBX Pwd. Require the PBX password from PBX / Config / Security instead of the user password for authentication. This is a legacy mode and we recommend not to use it any more. It makes sure that device registrations are not affected when user passwords are changed. Use certificate based registration instead (see also TLS only below)
  
• No IP Filter. Disregard the registration IP-Filter we have set in PBX / Config / Filter. Only rarely used
• TLS only. Enforce secure registration based on TLS certificates. Should be used whenever possible (might fail for some 3rd party devices though)
• No Mobility. While a device with this check-mark ticked is registered, the mobility feature (forking incoming calls to the user's mobile phone) is disabled. You may want to set that for the Device used by the softphone on your mobile phone
  
• Config VOIP. Enables additional VoIP configuration options. Rarely used
• Reverse Proxy. If ticked, registrations from abroad (e.g. home office) are allowed
• Single Reg. If ticked, only one registration is allowed for this Device. Makes sense in most situations
  
• Media Relay. Some third party devices do work correctly only if the media data is passed through the PBX. While this option fixes some interop issues, it should be avoided if possible, as it adds substantial load to the PBX
• No SRTP. Again, some third party devices do not work correctly if encrypted media (SRTP) is used. If this check-mark is ticked in addition to the Media Relay check-mark, no encrypted media is used with the device. Although this option fixes some interop problems, it should be avoided if possible, as it reduces the security of the connections

Please note that the softphone available in myApps (both on your PC or on your mobile phone) behaves a bit different from a hardware phone. The softphone is not a device that registers using SIP or H.323. Instead, it is more like just any App in myApps which uses HTTP(S) to connect to the PBX. Starting Apps is always secured by the users account and password so that the TLS only flag is not applicable. Also, the Reverse Proxy flag is irrelevant to softphones (in other words: they always work via reverse proxy).

Looking up the object for a registration

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) and to set the Single Reg check-mark. 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 property however does not need to be unique (that is, the Name property in the Devices list, the one in the general part needs to be unique).

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 property of an existing PBX object. In this case, the PBX behaves like if the registration came in presenting the value of the Name property of the PBX object as registration name. In other words, to allow a registration with the PBX object's Name property or Number property, there must be a Devices entry in the object that  has its Hardware Id set equal to the user object's Name property.

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.

Device Authentication

In a real life environment, user objects (more precisely: all objects) which shall allow an endpoint to register with (i.e. have at least one Device), 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, myApps). 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.

Use the device certificate instead of a password

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 an entry in the Devices list whose Hardware Id is  equal to the serial number of the phone and whose TLS only check-mark is ticked.

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 entry in the Devices list with TLS only 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 both variations as entries in the Devices list of the PBX User object John Doe. Use john.doe as Hardware Id for the entry allowing ad-hoc registrations and 0090334f22f9 for the entry allowing certificate based registrations. The latter will allow your IP111 to register based on the certificate. Furthermore  add a Name for each of your devices and enter phone in the App column. We need to associate the device with the phone app so we can use it later on to control the device with myApps.

Setting Phones to send their Certificate

As discussed before, many phones (for example 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:

• 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

Fortunately, as you have already seen in the IT Connect course, the device provisioning in the Devices App can do this for us.

However, here we want to do these  two settings on the phone (let's say the IP111) directly so you see what's going on under the hood when provisioning a phone with Devices. Also, you may have to do this manually for some phones (e.g. 3rd party phones).

 To manually register your IP111 with user John Doe configure the phone's registration data in Phone / User-1 / General

• change the Protocol from H.323 to H.323/TLS to enable certificate based registration

• set the Primary Gatekeeper property to the address of your PBX. As we already know from the IT Connect training, moodle has configured a customer DNS on your IP411RIGHT. So you can use hq.dvl-ckl2.net

Note that you need to configure neither Name nor Number to register. innovaphone devices will always use their serial number as Name then. In your case, this is 0090334f22f9, which is what you have configured as Hardware Id in one of the Devices entries for John Doe before.

Using DHCP

There is also a legacy method of provisioning with DHCP. However, we do not recommend to use this method anymore, as it interferes with the provisioning implemented in the Devices App.

Certificate Registration for Interfaces

We have seen how the phone can be registered to the PBX with no password based on its certificate. This can be done for interfaces (e.g. the TEL1 FXS interface of your IP411LEFT) too!

The device interface will behave similarly to a phone and send its serial number as registration name to the PBX when configured with no Name and no Number for the Internal Registration. However, to be able to distinguish the individual interfaces of the device, it will append the interface name to it.

Let's assume we want to register an analog phone attached to your IP411LEFT's TEL1 interface for John Doe.

• the interface, when configured to register to the PBX with H.323/TLS with neither Name nor Number would use a registration name which is built up by its serial number (0090334000b3), a hyphen (-) and the name of the interface (TEL1)
• the interface needs to be configured to register to the PBX (hq.dvl-ckl2.net in your case)
• there must be an entry in the Devices list of John Doe's user object that has  this name set as Hardware Id

 To register the analog phone for John Doe

• create an additional Devices entry in John Doe's User object with 0090334000b3-TEL1 as Hardware Id
• configure a value for the Name property of this device and enter phone as value for the App property
  
• tick the TLS only check-mark for the new entry
  
  
• set the Protocol to H.323/TLS in the TEL1 interface configuration on Gateway / Interfaces / TEL1
• set the Gatekeeper Address (primary) to hq.dvl-ckl2.net
• you might also want to set a value for the Name property of the interface

In this special case, the interface (TEL1) is physically on the same box as the PBX runs. Therefore, we could also use 127.0.0.1 (localhost) or 172.31.31.2 as gatekeeper address.

If all is done well, you will see  two registrations for John Doe listed in PBX / Registrations showing 0090334f22f9 (the IP111) and 0090334000b3-TEL1 (TEL1) as Device (it make take a while for the TEL1 registration to appear).