Course13:IT Advanced - 06 Setting up the Apps

From innovaphone wiki
Jump to navigation Jump to search

This books looks at the setup of various standard Apps in more detail

More PBX vs. instance interaction

There is much more interaction with App services than what we have discussed so far.

For example, there are URLs served by App service instances which are not for Apps, but for other HTTP clients. An example would be the URL used to send CDRs to, which is provided by the Reports App service instance. Also, access to such URLs is usually protected and proper credentials are required therefore.

We'll look at that by discussing more advanced configuration settings related to the various App services in the next chapters.

Reports

The Reports App service provides Apps for end-users (the personal Call List) as well as for administrators (Reports for overall call reporting). Also, an API (the callistapi) provides services for other Apps so they can display personal call information (for example, the phone app uses this).

For this to work, the App service must receive call data information (so called Call Detail Records, CDR) from the PBX.

CDRs are sent using HTTP GET or HTTP POST requests to the App service instance.


The steps to make Reports work are
  • download the Reports App service from the App store and create a new instance (we have already done this before)
  • create the App objects in the PBX and configure the appropriate URLs and flags so it is known how to access them
  • assign the Apps to a user to make them available in myApps
  • configure CDR delivery path and credentials in Gateway/CDR0
  • setup users so that they have the appropriate licenses for their calls to appear in Reports


The client side

To be able to send CDR data to the Reports App service instance, we need to configure the URL for the GET request and also the credentials for the HTTP authentication.

To explore this a bit, let's look at our master PBX again.

CDRs are sent by the PBX to the application that processes them if the Generate CDRs check-mark is ticked in PBX/General. Btw, for historical reasons, the Gateway level is also able to send CDR data, albeit with different format. However, we don't care as this is not used anymore.

The check-mark needs to be set therefore in
But how does the PBX know where to send the CDR data to?

The target and method must be configured in Gateway/CDR0 (again of course in both the master and standby PBX).

To use our reports App service instance for call lists, configure Gateway / CDR0 as follows:
  • select HTTPS as Log Server Type
  • use apps.dvl-ckl2.net as Address as this is the DNS name of your AP
  • leave Port empty (which will use the https default port 443)
  • select External (GET) as Method
  • use /dvl-ckl2.net/reports/cdr as Path
    Note that the prefix /dvl-ckl2.net/reports is what has been screenshot.png configured as Webserver path in your Reports instance while /cdr is a fixed part you always use to send CDRs to the Reports service instance
  • use an appropriate User of your choice for CDR delivery. Note that this user name will only be used to authenticate the delivery of CDRs to the Reports App service instance. Here in the training, please use cdr (so that your teacher knows it and can help if need be)
  • use an appropriate secure Password of your choice for CDR delivery. Note that this password will again only be used to authenticate the delivery of CDRs to the Reports App service instance. Here in the training, please use ip411 (so that your teacher knows it and can help if need be)
We now have screenshot.png configured the client side of the CDR delivery on the master PBX.


An interesting case is the construction of the Path value. It probably was no surprise to you that it starts with the PBX's domain name followed by the string /reports (/dvl-ckl2.net/reports). This is what we have screenshot.png configured as Webserver path for our app service instance before, so all URLs provided by this instance will share this prefix. However, the trailing /cdr is sort of classified information as it not listed as App URL in the list of URLs in the instances edit dialog. It arguably should be listed there. Now, you at least know why you are attending this course wink

The server side

On the server side, we obviously need to tell the App service instance the credentials it shall accept for incoming CDRs.

This is a property of the App service instance and as such configured in the screenshot.png Configuration dialog of the PbxManager plugin Christoph's AP reporting:
  • set User name and Password in the Account for the CDR authorization dialog to the values you have configured on the client side before (cdr and ip411)
(Further Hints) The other credentials (Account for the myPBX call list) is used for the legacy myPBX client only and you can disregard it as long as you do not run myPBX in your installation (which you shouldn't in an all new installation).

Trying it out

To try it out, we can start the Call List App. To do so, we need to assign access to the App to John Doe's list of Apps in his user record. And to be able to do that - you guessed it - we need to create the appropriate App objects in the PBX.

Fortunately, you already know a convenient way to do this:
Well done!

Licensing

Just to be on the safe side,
  • screenshot.png start Reports to see if this works too
  • Leave all fields as is in the selection criteria, so that we see todays calls for all users and hit screenshot.png Show results
Oops! What is that? Why are the new entries we have seen in the call list before not shown here?

Call reports (as opposed for listing own calls only) is done only for users which have a reporting license assigned. Assigning the reports App to users doesn't do the trick as it controls access to the reports. To have calls included in the reports, the users initiating or receiving the calls must have a Reporting license assigned.

So
(Further Hints) When the Reporting license is assigned to a user, all subsequent calls will be listed in the Reports App. Previous calls will still not show up.

For historical reasons, there is some confusion regarding the name of the App. It should have been called Reports from the very beginning but it started out as Reporting and therefore, you find both names.

Users

The Users App service manages various data related to users in the PBX. It provides the Users App which allows end-users to find other PBX users. Also, the UsersAdmin App allows administrators to add/remove and edit PBX users. The Profile App however allows end-users to edit their own properties. Finally it provides an Api (users-apis) to other Apps which allow them to retrieve avatar pictures for users (this is used by the phone App for example).



As you already know, the PBX itself does also manage user data. For this reason, the Users App service needs to synchronize it's own user data with the User and Executive objects in the PBX. This is done in tandem by a function in the PBX known as TableUsers and a replicator in the App service.

Whereas the Apps are available only once a user runs myApps, the replication obviously needs to take place even if no user at all is using myApps. Therefore, a direct websocket connection between the PBX and the Users App service is established. This happens because the screenshot.png WebSocket check-mark is ticked in the profile App object in the PBX.

As you might remember, the myApps settings have a link to the users profile (Edit profile in MY ACCOUNT available through the burger menu). Therefore, myApps needs to know which profile App is to be used).

The steps to make Users work are
  • download the Users App service from the App store and create a new instance
  • create the App objects in the PBX and configure the appropriate URLs and flags so it is known how to access them
  • assign the Apps to a user to make them available in myApps
  • configure the Profile App as the app to be linked from myApps burger menu
  • configure user replication

The App service

To install the Users App service and create a new instance

The App objects

To try it out, we can start the Users App. To do so, we need to assign access to the App to John Doe's list of Apps in his user record. And to be able to do that - you guessed it - we need to create the appropriate App objects in the PBX.

Next step is to create the App objects in the PBX

Just like before with the Reports App, the way to do this is:

As you will notice, the App starts up empty - no users. This is because the replication is not yet properly configured. We'll do that in the next step.

Replication

To setup proper replication between our Users App instance and the PBX, let's first see if the replicator connection is setup properly.

WebSocket


If the screenshot.png WebSocket flag is set in an App object, the PBX strips the last component of the URL property (leaving https://apps.dvl-ckl2.net/dvl-ckl2.net/users from https://apps.dvl-ckl2.net/dvl-ckl2.net/users/innovaphone-profile for example) and uses this as target for a WebSocket connection.

This connection is then authenticated based on the shared secret (the Password in the App instance on the AP and in the PBX App object). Once the connection is established, messages can be exchanged between the PBX and the App service and vice versa. In case of the Users App service, this is used to exchange user object update messages. The access rights which are granted to the App service for this connection are ticked in the Grant access to APIs section.

(Further Hints) As soon as the WebSocket connection between the PBX and the App service instance is established, the state shown next to the URL property field screenshot.png changes to connected. If it stays in the connecting state, there is probably something wrong with the credentials or the URL. Also, the App service instance may not be running.

We actually have nothing to do so far, as the PbxManager has perfectly created all the required objects.

Replicator properties

However, to get the replicator up and running, some additional configuration needs to be done in the Users Admin App's burger-menu settings. When you open them right now, you'll see it screenshot.png complaining.

To fix that, you need to enter
  • the PBX Password (we had set that to ip411 in the PBX)
  • and the PBX name (which is hq)
Now everyone is screenshot.png happy smile


You may ask yourself why we need to specify the PBX name. This is because in a master/slave system (we'll look at that in a later topic), all of the PBXs will connect to the Users App service instance. However, you will want to make sure that replication takes place from/to the master PBX. So you need to tell Users the name of the master.

Self-service device provisioning

While you are at that page, we can quickly look at the bottom of the burger-menu page. You'll see a check-mark called Allow users to edit and provision phones. If this is ticked, end-users will be allowed to provision their own phones (you have seen that in your IT Connect training).

Whether you want your users to be able to do this themselves or not is at your own discretion. If the flag is turned on, users will see some screenshot.png options to add phones in their profile. If it is turned off, the assigned phones will just be screenshot.png listed with no option to add one.

For the course, make sure you video2.png ticked the option.


All other settings on this page (password policy, SMTP, default settings for new users) should be pretty self explanatory and/or they have already been discussed in the IT Connect training.

To set these values to what the Install would set,
  • set the password policy's Minimum length to 8 and
  • Minimum number of categories to 1

  • set the default settings - new user's Node to root (so far, there is no other node than root),
  • PBX name to the name of the master PBX (which is hq),
  • Default password (import) to password,
  • Home screen apps to users,
  • Template to Config User (which does not yet exist in our PBX but we'll create it later)
For the course, you can leave the SMTP settings as is, as we don't use them. In real life, you would enter the customers SMTP data just as you would do when running the Install.

The profile App

You might recall that myApps allows access to the screenshot.png user's own profile editor through its burger-menu.

However, when you look at myApps' burger-menu now, there is screenshot.png no Edit profile link. This is because we need to configure the profile App that should be linked-to in PBX / Config / myApps. So far, this field screenshot.png is empty, so no profile App is linked.

This can easily be fixed using the Users PbxManager plugin (Christoph's AP users):
  • when you click on Users configuration / Change configuration a drop-down will appear (admittedly, it doesn't look like one initially, but just trust me and click on it, you'll see a drop-down list). screenshot.png Select your IP411LEFT here (as it is the master PBX)
  • you will see a dialog there which allows you to set the Profile app. Even more, it allows you to control some additional behavior in your PBX:
    • can users register themselves?
    • can users reset their password?
    • can users delete their account?
      Just click on profile (this is the only profile editing app we have anyway). You can screenshot.png select whatever you like for the other choices, but letting users register and delete themselves is a rather rare setting (unless you run a web-based public PBX)
  • once you have saved the new settings, you will see the settings in PBX / Config / myApps screenshot.png updated and the Edit profile link appears (you might have to re-open the profile though for the change to take effect)
(Further Hints) All these settings are done in the individual PBX settings. Therefore, they must be done on each PBX in the system!

Contacts

Contacts can be used to dial out from a shared contact database (directory) and to provide caller id data for incoming calls.

You already have seen how to upload directory data and how to use it in the Contacts App during your IT Connect training. In this chapter however, we will look at how non-App clients get access to this data.

To play around with Contacts, we have to create a new App service instance.
Even though we run the risk to bore you, here is how to do this:
  • install the Contacts App service from the App store
  • add an App service instance called contacts for domain dvl-ckl2.net with password ip411 (of course only in the training, in real life you'd rather choose a secure password)
  • start the instance
  • use the Christoph's AP contacts PbxManager plugin to add the App objects for
    • Contacts (Name Contacts, SIP contacts)
    • Contacts admin (Name Contacts Admin, SIP contacts-admin)
    • Contacts API (name ContactsApi, SIP contacts-api)
  • assign contacts, contacts-admin and contacts-api to John Doe
  • start Contacts Admin
  • screenshot.png upload the https://class.innovaphone.com/moodle2/pix/f/web.gif Sample contacts file (UTF8) in to the new instance.
    When you type fen in to the search window, you should see the screenshot.png entry for Renée-François Fenêtre if everything went well


Name/number resolution overview

Let's have a bit of theory and look at how name/number resolution works in V13.

So what is name/number resolution anyway?

There are two kinds of resolution:
  • name resolution maps a name to a number (e.g. by looking up the name in a directory so the user can use it to dial out). As this is usually what a user expects to happen when he does an outgoing call, a.k.a. forward lookup
  • number resolution does the opposite thing: it resolves a number to a name (e.g. to display the caller-id for an incoming call), a.k.a. reverse lookup

Directory Interfaces
Both kinds of resolution work with a number of possible directories.

There are basically 3 types of directory-access:
  • local
    The hard-phones feature a local directory list which can be edited by the end-user (on the phone)
  • LDAP
    both the phone and the PBX can use LDAP to look in to a directory (which might be a Contacts App service instance, an external LDAP server or the PBX internal LDAP server)
  • search-API provider
    myApps (and hence all the Apps running inside myApps) can use the com.innovaphone.search API. There are several providers for this API:
    • the Users App service instances. Provides data for PBX User and Executive objects
    • the Contacts App service instances. Provides data for the entries stored in their respective database
    • the PBX LDAP objects. Provide proxy access to entries stored in a remote LDAP server. myApps can not talk LDAP directly. These objects are the way to provide access to LDAP entries for myApps.
    • your local Outlook contacts. myApps for Windows will search your local Outlook contacts for a matching name.
The PBX system will use these interface to resolve names to numbers (or SIP URIs, which is functionally equivalent) e.g. to place calls or to resolve numbers to names to display the caller identity of the remote peer of a call.

Directories

In practice, the following directory services exist:
  • the screenshot.png PBX User database
    these are the PBX objects that do not have the Hide from LDAP property set. They are made available both by the PBX's internal LDAP server (via LDAP obviously) and the Users App service instance as a com.innovaphone.search API provider to Apps running in myApps (however, limited to User and Executive objects only in the latter case)
  • the directory entries uploaded to the screenshot.png Contacts App service instances
    made available by the Contacts App service instances both via LDAP and as a com.innovaphone.search API provider
  • contact entries stored in the user's own screenshot.png Outlook installation (e.g. an Exchange contacts folder)
    made available by the myApps launcher as a com.innovaphone.search API provider
  • directory entries stored in the user's own screenshot.png hard-phone
    accessed locally and hence only available on a single phone
  • directory entries stored in an LDAP compatible screenshot.png 3rd party directory server such as Estos' MetaDir, C4B's XPhone Virtual Directory or any OpenLDAP server
    made available both by the 3rd party's server (via LDAP obviously) and (optionally) by an LDAP type PBX object
This adds up to a screenshot.png pretty complex scenario. But don't be afraid, we'll look in to how this works in the next sections.

Number resolution in action

Let's see what happens for an incoming call.

  • An external call comes in
    It is received by the PBX's signaling core. The signaling core now uses it's screenshot.png configured Reverse Lookup URL and screenshot.png performs a reverse lookup call (as to map the incoming number to a caller-id).
    (Further Hints) The Reverse Lookup URL usually points towards a Contacts App service instance. However, it does not need to. If you decide to use an external directory system instead, you can do so (see fish-help.png Concept Number Resolution and LDAP for some samples how to address other services)
  • meanwhile, screenshot.png the call is forwarded to both the hard-phone (using H.323) and to myApps (more precisely, to the phone App running in myApps, using the EpSignal WebSocket API)
  • when a search result is received from Contacts, the PBX creates a name-identification from it (this could look like Christoph Künkel innovaphone AG for example) and sends it to the hard-phone and to the phone App (again using H.323 and EpSignal, respectively) which will display it to the user
  • the phone App does an attempt to even do better and sends the name-id (Christoph Künkel innovaphone AG) to the search API available in myApps. myApps will screenshot.png forward to this request to all search API providers available:
    • Contacts
    • Users
    • any PBX LDAP object available
    • Outlook contacts

Each of them may or may not yield a result, however, the Contacts App service certainly will, as the name-id was constructed from its search result by the PBX in the first place. The difference now is, that the full directory information is available to the phone App which will use it to display a screenshot.png nice vCard

(Further Hints) Note that the hard-phone does not do any such attempt, as it relies on the PBX to do the reverse number lookup and also has no ability to display extended vCard information.
This behavior is controlled by the screenshot.png Disable Phonenumber Look-up check-mark in the user's Phone configuration. For legacy installations (pre-V13), this is turned off (so that phone number lookup is done) because the PBX did not do the reverse lookup in these systems

(Further Hints) Also note that reverse lookup is only performed for calls to user objects. For example, if you call a waiting queue with two agents, number resolution will be done for each agent separately (as there might be different results) but it will not be done for the waiting queue. SO when looking at a call report for the waiting queue, no resolved names will be seen.

For an outgoing call, the scheme is pretty similar:
  • the call is sent from the endpoint (either hard-phone or phone App) to the PBX
  • the PBX does the reverse lookup and sends back a name-id
  • myApps attempts to display a vCard and sends a search request to the search API therefore

Number normalisation

Let's have a slightly deeper look at the reverse lookup done by the PBX.

The number to resolve will usually be a dial-able number in the so-called unknown format (could be e.g. 007031730090 or 000497031730090). That is, it is not a full number in a format usually stored in a directory (such as eg. +49 (7031) 73009 0).

In order to find an entry in a directory regardless of the format that has been dialed, the PBX does an attempt to normalize the number. This is done using screenshot.png the Prefix for Intl/Ntl/Subscriber/Area-Code/Country-Code properties in PBX / Config.
  • if the number matches the Intl prefix (usually 000), the prefix is removed

    000497031730090 -> 497031730090

  • otherwise, if the number matches the Ntl prefix (usually 00), the prefix is removed and the Country-Code (49 in our example) is prepended

    007031730090 -> 7031730090 -> 497031730090

  • the resulting number (497031730090) is made available to the Reverse Lookup URL as variable %n
  • in the default lookup URL

    ldap://apps.dvl-ckl2.net/dc=entries?givenname,sn,company?sub?(metaSearchNumber=+%n)?bindname=apps.dvl-ckl2.net\contacts

    you see the part metaSearchNumber=+%n. %n is replaced by 497031730090 as shown above. The URL also has a + (plus sign) in front of the %n, so the number actually looked up in the directory is

    +497031730090

    which is actually the full international format usually maintained in a directory (although it might be displayed with some decoration as in +49 (70317) 3009-0)
(Further Hints) So keep in mind that your directories should always contain all numbers in a full international format! Otherwise, reverse number resolution might not work.

Name resolution in action

When a user types in a name in myApps (or even on the hard-phone) the system must map the name to a dialable number in order to place the call.

Here is how this works in myApps:
  • the user types in a search string in the phone App
  • the phone App will send the string to myApp's com.innovaphone.search API
  • myApps will screenshot.png forward the search request to all com.innovaphone.search providers:

    • Outlook
    • Users
    • Contacts
    • any available PBX object of type LDAP

  • incoming results will be displayed to the user
  • the user selects an entry (and the number within this entry, there might be multiple)
  • the phone App screenshot.png creates a call using the EpSignal API and sends the selected number with it
  • the PBX screenshot.png forwards the call to the users local phone and the remote peer (using either the appropriate trunk or a local PBX object)
Again, its not an screenshot.png easy picture wink
Number normalization
Unfortunately, numbers found in directories need to be modified too before they can be used to dial (just as you already have seen for the reverse lookup), as they appear in different formats (Users for example will yield pure extensions such as 123, whereas Contacts will deliver international numbers like +49703173009123 and user-maintained directories such as Outlook often contain dialable numbers such as 0703173009123).

Assuming the following prefix configuration:

Intl = 000
Ntl = 00
Subscriber = 0 (note that the Subscriber prefix is also often known as trunk access prefix)

the phone App can handle a variety of number formats:


type
 		input
 		dialed
international numbers +49 (7031) 73009-123 00049703173009123
international numbers with full dialing prefixes 00049703173009123 00049703173009123
international numbers 0049703173009123 00049703173009123
national numbers 0703173009123 00703173009123
subscriber numbers 73009123 073009123
local extensions 123
 123

Local extensions are distinguished from subscriber numbers by their length (less than 7 digits).

Name resolution in action (cntd.)

Name resolution also takes place when dialing directly from a phone.

In this case,
  • when the user types in a search string the phone would consult 3 different databases, depending on the screenshot.png registered user's Phone/Directory configuration:

    • the Local phone-book, which is stored in the phone's flash memory and can be maintained by the user itself directly on the phone
    • the PBX phone-book, which lists all the PBX objects
    • the External LDAP Server phone-book, which usually is configured to look in to the Contacts database
Except for the Local phone-book, they are screenshot.png accessed using LDAP
  • the call is then screenshot.png sent to the PBX with H.323 and forwarded both to the remote peer (using SIP) and the phone App running in myAps (using EpSignal)

(Further Hints) Note that also for outgoing calls, the PBX will do a reverse number lookup for the called party as explained in Number resolution in action above. Again, the result is sent back both to the hard-phone and the phone App (this is the reason why you ultimately see the nice vCard of the called party again in myApps).

The full picture


Whenever you configure or debug name/number resolution issues, the following full picture may be useful:


Multiple directory sources

Most installations will want to use their own phone-books. Looking at the scenarios for forward- and reverse-lookup it should be clear that
  • forward lookup on the phone allows access to :
    • one external phone-book (the External LDAP Server). Access to it is controlled by the User PBX object's Phone configuration
    • and the phone-book stored directly on the phone

  • forward lookup in the phone App (that is, in myApps) can handle many phone-books:
    • zero or more Contacts App service instances
    • as well as zero or more external LDAP servers connected through PBX LDAP objects.
      Access to those phone-books is controlled by the respective User PBX object's Apps tab
    • local Outlook contact folders for myApps running on Windows

  • reverse lookup (being done centrally in the PBX) can only use a single phone-book, connected through LDAP (controlled by the PBX's Reverse Lookup URL property). Results are made available to all PBX users

The most common setups are:
  • screenshot.png use Contacts
    • a single Contacts App service instance is used for forward- and reverse-lookup
    • no PBX LDAP objects

  • screenshot.png use 3rd party directory
    • Contacts is not used
    • Instead, a 3rd party LDAP server is used in the PBX's Reverse Lookup URL property and in a single PBX LDAP object

    Configure Forward Lookup

    Now that we're gone through all this weird theory, let's get practical and configure the whole thing. After all: if you are able to configure it correctly and it works, there is no need to understand the details wink

    To configure forward lookup in myApps (and hence the phone App), you need to

    Note that there is no App check-mark for the Outlook search provider. This is available to myApps simply due to the fact that it is installed on the PC where myApps runs.

    Also, if a user may search a directory (as allowed by enabling the search providers above) it obviously makes sense to give access to their respective UI too. So we also tick the

      • contacts and
      • users

    check-marks.

    To enable forward lookup on the hard-phone, we need to configure the directories to be used by the phone. This is done in the user's Phone config tab in the PBX.

    At first we need to activate the screenshot.png Store Phone config checkmark in John Doe’s user object because otherwise changes of the phone config won’t be transmitted to the phone. This option will be explained in more depth later on.

    To enable the local phone-book on the phone
    To configure access to the PBX's objects (such as e.g. Users), you need to configure the LDAP access to your PBX in screenshot.png the PBX section:
    • tick the Enable and Use TLS check-marks

    • leave the Server property empty. In this case, the server address found in the phone's registration configuration is used and this is most likely what you want

    • leave the Port property empty. In this case, the LDAP (389) or LDAPS (636) default port is used, depending on your Use TLS setting. Again, this is probably what you want

    • set the Username to a name in the domain\user format. The domain is your PBX's DNS (hq.dvl-ckl2.net in your case). We suggest to use ldap-guest as user. So in your case, you end up with hq.dvl-ckl2.net\ldap-guest

    • set the Password to a secure password (yeah, you guessed it, in this course, you set it to ip411)

    • leave the Gatekeeper Identifier property empty

    • Leave the Name Attribute property as-is. You could set it to Display Name instead of Long Name. However, Display Names are not unique throughout the system, so you could get ambiguous results, which you probably don't want
    Again, note that this configuration won't work for now, as we first need to also set up the user and the password in the PBX's LDAP server settings.

    To configure access to the entries found in Contacts, you need to set screenshot.png the External LDAP Server properties:
    • tick the Enable and Use TLS check-marks
    • set the Server property to the DNS name of your App platform (apps.dvl-ckl2.net in your case)

    • leave the Port property empty. In this case, the LDAP (389) or LDAPS (636) default port is used, depending on your Use TLS setting. This is probably what you want

    • set the Username to a name in the domain\user format. The domain is your PBX System name (dvl-ckl2.net in your case). user is the name of your Contacts App service (contacts). So in your case, you end up with apps.dvl-ckl2.net\contacts

    • set the Password to a secure password (again, how boring, we use ip411 in the course)

    • set Search Base to dc=entries (just don't ask wink this is a hard-wired value imposed by the Contacts app service)

    • leave Mode as is (that is, basic). Again, this is a hard-wired value imposed by the Contacts app service
    • leave Name Attributes empty since it is a legacy option and not required to configure any longer.

    • leave Number Attributes empty (remember: we do not use reverse lookup on the phone)

    • set H323 ID Attribute to sip
      (this is the name of the attribute in the Contacts database which allows to be called like a phone number)

    • set the Detail Attributes to title,company,street,postalCode,city,country,email,url
      This is something you may modify to your taste. It defines the way the phone would construct the display search result entry

    • set the Meta Name Attribute to metaSearchText

    • set the Meta Number Attribute to metaSearchNumber
    (Further Hints) These two Meta attributes are an interesting case. They are meant for servers which can perform intelligent wildcard searches on their own, just based on a simple search string given as value for the meta attribute. This often leads to better search performance but requires a server which is capable of doing it. Contacts is wink. If you use an LDAP server that can't do it, leave the Meta- attributes empty. In this case, the LDAP client will construct its own search expression based on the Name Attributes and Number Attributes.
    • leave the Hold Server Connection property as is

    The remaining fields are for the dialing location. This resembles the Prefix for Intl/Ntl/Subscriber/Area-Code/Country-Code property in PBX/Config/General, however, the format is slightly different.

    To set the screenshot.png Dialing Location for the phones
    • set Country Code to the country code of your trunk line, 49 in your case

    • set Area Code to the area code of your trunk line

      (Further Hints) If there are no area codes in your country, this field must be left empty. So for you, set it to

      621

    • set National Prefix to the prefix you need to dial to access a national number but without the trunk access prefix (this is the difference to the setting in PBX/Config/General).

      So for you, set it to

      0

    • set International Prefix to the prefix you need to dial to access a international number but without the trunk access prefix (this is the difference to the setting in PBX/Config/General).

      00

    • set External Line to the trunk-access prefix of your trunk. In your case, this is 0

    • leave Subscriber Numbers as-is (empty)

    • set Max Internal Number Length to 7 (so it is consistent with the hard-coded limit implemented in the phone App)


    ... PBX local LDAP server

    PBX local LDAP server

    We have configured the client side to the PBX's LDAP server above. However, you also need to configure this LDAP server side in Services / LDAP / Server.

    To configure the screenshot.png PBX's LDAP server properties so that phones can access PBX object information
    • add a new User called hq.dvl-ckl2.net\ldap-guest with Password ip411
      This needs to be exactly the credentials you have configured in the screenshot.png PBX settings of the PBX User record in the last section!

    • make sure you tick the Apply Hide check-mark for this new user

    • optionally delete the existing ldap-guest user. This legacy setting is there by default but is not suitable for remote access to the PBX LDAP (that is, access through a reverse proxy)

    ... Contacts LDAP server

    Contacts LDAP server
    The last missing part is the setup of the Contacts App service instance LDAP server. The only thing to be done here is to set the LDAP access password which we have used before both in the PBX's reverse lookup URL and in the phone's external directory setting.

    To see the configuration of your Contacts App service instance
    • open the PbxManager in myApps
    • click on the Christoph's AP contacts plugin
    • click on Change configuration
    You can leave all settings as-is except for the User (LDAP) and Password (LDAP) and Enable LDAP.

    Set the User (LDAP) to apps.dvl-ckl2.net\contacts

    The password is currently not set (you can check this by ticking the Display check-mark next to the input field.

    To set up the LDAP password
    • type a secure password in to the Password (LDAP) field
      In this course, as usual, use ip411
    • tick the Enable LDAP check-mark to start the LDAP server
    (Further Hints) Of course, the Install does this configuration for you. If so and you need to know the secure password created by the Install, you can always run the plugin and tick the Display check-mark to see the password.


    ... number/name resolution in the PBX

    Reverse lookup
    To configure reverse lookup in the PBX
    • set the screenshot.png Reverse Lookup URL in PBX / Config / General to

      ldaps://      DNS-name-of-your-AP/dc=entries?givenname,sn,company?sub?(metaSearchNumber=+%n)?bindname=apps.your-domain\name-of-your-Contacts-instance.

      In your case, this would be

      ldaps://apps.dvl-ckl2.net/dc=entries?givenname,sn,company?sub?(metaSearchNumber=+%n)?bindname=apps.dvl-ckl2.net\contacts

      The Password shall be set to a secure password in real life. However, as usual, here in the training we use ip411 as password. Note that this configuration won't work for now, as we first need to also set it up in Contacts

    • set the screenshot.png Prefix for Intl/Ntl/Subscriber/Area-Code/Country-Code prefixes to

      • Intl: prefix to access international numbers, including the trunk-access-code. In your case

        000

      • Ntl: prefix to access national numbers, including the trunk-access-code.

        In your case

        00

      • Subscriber: prefix to access local numbers (also known as trunk-access-code).
        In your case

        0

      • Area-Code: the area code of your trunk line

        (Further Hints) In countries which do not have area codes (that is, users must always dial full national or international numbers) this field must be left empty!

        621

      • Country-Code: the country code of your trunk line.

        In your case

        49
    (Further Hints) You could also set the Subscriber field to the trunk line's subscriber number (3428231 in our case). However, in many cases this is not necessary (as it mainly inhibits loopback calls to local extensions through the trunk line when a colleague's extension is dialed from a directory) and the Install therefore also does not do it.

    ... Trying it

    Trying it

    To verify your configuration
    • use your IP111 where John Doe is registered
    • do a long press on the 5 (j)
      you should see a screenshot.png search result entry for John Doe (14). This is a result from the PBX LDAP server
    • clear the j using the backspace key on the upper right
    • and press 7 three times (yielding an r)
      you should see a screenshot.png search result entry for Renée-Francois. This is a result from the Contacts App service instance LDAP server
    To check the search-api provider we first need to make the phone App available to John Doe (so we can try the search function within):
    • open John Doe's PBX User record
    • switch to the Apps tab
    • tick the phone App
      now, several Apps representing John Doe's devices are available in the ALL APPS area (POTS phone, Hot Desking and IP111)
    • start one of your phone apps.
    • try to search for both j and f
      Notice that the search for f works screenshot.png as expected but the search for j does not. This is because visibility through LDAP access is a yes/no configuration in the PBX object (controlled by the Hide from LDAP check-mark which is off for John Doe). Visibility through search-api access however is controlled by a much more sophisticated privacy mechanism which we need to configure before it works
    To configure privacy for John Doe
    • edit John Doe's profile by starting the Profile App available in the ALL APPS area
    • switch to the Privacy tab
    • click on + Filter for domain to add a rule for all users in your PBX system
    • put dvl-ckl2.net (your PBX System Name) in to the input field next to the @
    • tick the Visible check-mark
      This is to say that John Doe is visible to all users in this specific domain. If you like, you can tick all the other privacy options (except for Group, you must not tick this as this is not a privacy option but changes the interpretation of what you have typed in the input field from being a domain name to being a group name)
    • if you now go back to the phone App and re-run the search for j, it should work

    Retrieved from "https://wiki.innovaphone.com/index.php?title=Course13:IT_Advanced_-_06_Setting_up_the_Apps&oldid=68896"