Reference13r1:Concept Number Resolution and LDAP

From innovaphone wiki
Jump to navigation Jump to search
There are also other versions of this article available: Reference13r1 (this version) | Reference13r2 | Reference13r3

General

This document shows the V13 concept of number resolution, LDAP search and reverse lookup.

Applies to

This information applies to

  • V13 and up

Short overview and scenarios

There are basically two different directions for resolutions.

  • Number to Name (Reverse Lookup)
Backward resolutions are performed centrally for calls on the PBX-level calls. A Reverse Lookup URL can be stored per PBX.
By default, this is a 1-to-1 relationship. (A single PBX can query an single LDAP source).
For this scenario, there is a special parameter "%u" available that you can change the relationship to the user. So a specific LDAP source is requested depending of the user which receive the call.
  • Name to Number (Forward Search)
In the search, we still distinguish between software and hardware.
  • MyApps
Here exists a 1-to-n relationship. A user search simultaneously in multiple sources
  • Desk phone
Here the well known V12 scenario is still used and the external directories in the user object can be used for the LDAP configuration.

Number to Name (Reverse Lookup)

Concept

Resolution is done at the PBX for incoming calls without any embedded name information according to the locally define reverse lookup setting. This might be different for master and slaves.

Resolution is done by LDAP-queries against sources like the PBX phonebook itself, V13-contacts application or any external 3rd-pty directory.

Setup is done via the Reverse Lookup URL which is configured under PBX/Config/General.
If a resolution succeeds via this mechanism, the resolved name is given to all other applications/locations. (MyApps, Phones (also DECT), CDRs, Reporting, eg.)

PBX Configuration

If you want to use the central PBX Reverse Lookup you can use one of the following examples for your Reverse Lookup URL.
Otherwise, you can use any other LDAP Server that you want. The URL is an RFC2255 encoded string. The format is explained here

Of course only attributes which exist in the external directory will be resolved.

Contacts App

ldaps://ap.domain.tld/dc=entries?givenname,sn,company?sub?(metaSearchNumber=+%n)?bindname=domain.de\contacts

Contacts is asked by further instances (e.g. PhoneAPP) for details about the found contact via websocket query.

Estos MetaDir

ldap://metadir.domain.tld:712/dc=meta?givenname,sn,company?sub?(|(telephoneNumber=+%n)(mobile=+%n)(homePhone=+%n))?bindname=username

C4B

to be tested

PBX as LDAP Server

This refers to the legacy PBX-directory solution.

ldap://ldap.domain.tld/cn=PBX0?dn,e164,email?sub?(&(node=PhoneBook)(e164=000%n))?bindname=telbook

The three zeros before the %n depend on the dialable format, i.e. how your number is stored in the Phone Directory

Legacy Device Configuration

By default, in V13 the reverse number lookup is done at the PBX and displayed at the phone. Phone originated directories such as internal phone book, pbx access and external ldap are disabled.

Optionally, it is possible to enable the resolution directly at the phone. This is done by unticking the option "Disable Phonenumber Look-up" at Phone/User/Preferences.

The phone will then use the directory settings of the appropriate user, which are defined in the user object or config template.

If the resolution on the local phone provides a result, this is shown instead of the resolution of the PBX.

Be aware that this might lead to a different result than displayed on the PhoneAPP/SoftphoneAPP/CallList etc. as these applications always resolve against PBX-located settings.

Name to Number (Forward Search)

Search can be done by use of various sources. Those may be

  • PBX itself (UsersApp)
  • included ContactsApp
  • any other external directories

UsersApp

All PBX users can be searched via the UsersApp.

ContactsApp

Further, contacts can be managed and searched within the ContactsApp.

It is possible to define several contact instances hosting different contact data and assign those to dedicated users/config template.

Usage

Configure LDAP query with Contacts e.g. at phone:

  • use of the correct user incl. domain (e.g. domain.tld\contacts)
  • Correct password (in plain text in PBXManager/APContacts/configuration)
  • Search attributes:
    • Meta Name Attributes -> metaSearchText
    • Meta Number Attributes -> metaSearchNumber

PhoneApp / SoftphoneApp / myPBX

Search requests can be done via dedicated directory applications such as UsersAPP or ContactsAPP or within the Phone/SoftphoneAPP and also myPBX.

Search requests are performed towards multiple sources in parallel if assigned to the respective user.

User objects and configuration templates offer possibility to define search against the PBX and one external source. In case of more external sources are required (e.g. Contacts and C4B), an LDAP-object has to be defined and assigned to the user.

LDAP Object

To extend the amount of external search sources you can use the LDAP Object in the PBX.

To be defined depending on the external source attributes according to this description.

LDAP object has to be assigned via App-tab to dedicated user / configuration template.

Outlook

  • Works with myAPPs windows launcher and so Windows compliant only
  • Outlook Search will find contacts in all exchange accounts and all contact folders from these accounts
  • requires a configured MAPI profile in Outlook (Exchange Account)

Hardware Phone

Search on the hardware phone is done by use of the configured directories at the phone.

Troubleshooting

Reverse Lookup doesn't work on SIP Trunk

Reverse Lookups are only executed for incoming calls without any embedded name information. Some SIP Provider will send the Phone Number as additional Name Information. In this case the Reverse Lookup will not be performed.
You can remove this additional information from your carrier in the routing by deactivating the Flag "Interworking (QSIG,SIP)" in the incoming SIP Route.

MyApps - Forward Search with LDAP Object

For Search Request to a configured LDAP APP you will find the following lines in your myapps traces and can check the response. In this example there exist an LDAP Object with the Name "MetaDir" and is configured as App to the User.

// search pattern is "jon doe"
PhoneSearchBar::onSearchInputChange() input=jon doe

You can search for the Name of your LDAP Object (in this example "MetaDir") and have to see the following lines.

// start connection and login 
open MetaDir url=http://localhost:10008/appproxy/ext/pbx.domain.de/PBX0/APPS/MetaDir/ldap_api.htm? 
name=MetaDir&title=MetaDir&scheme=dark&lang=de&originalUrl=http%3A%2F%2Fpbx.domain.de%2FPBX0%2FAPPS%2FMetaDir%2Fldap_api
started: MetaDir (hidden)
AppWebsocket(MetaDir) ws://localhost:10008/appproxy/ext/pbx.domain.de/PBX0/APPS/MetaDir/132075/websocket
AppWebsocket(MetaDir) ws://localhost:10008/appproxy/ext/pbx.domain.de/PBX0/APPS/MetaDir/132075/websocket
send: {"mt":"AppLogin","app":"ldap_api","domain":"domain.de","sip":"slutz","guid":"e9653d7a7a615901b5b300155dbb1337","dn":"slutz","info":{"appobj":"MetaDir","appurl":"../../APPS/MetaDir/ldap_api","cn":"slutz","unlicensed":true,"groups":["test"]},"digest":"***","pbxObj":"MetaDir"}

// Login successful and Search API is registered
recv: {"mt":"AppLoginResult","ok":true}
recv from MetaDir: {"mt":"RegisterApi","api":"com.innovaphone.search"}

// send search request to LDAP APP
send to MetaDir: {"mt":"ApiRequest","api":"com.innovaphone.search","consumer":"dev:009033465440","provider":"*","src":"2","msg":{"mt":"Search","type":"contact","search":"jon doe"}}

// receive result from LDAP App
recv from MetaDir: {"mt":"ApiResult","api":"com.innovaphone.search","consumer":"dev:009033465449","src":"2","msg":{"mt":"SearchInfo","type":"contact","dn":"Jon Doe","contact":{"cn":"John Doe","givenname":"John","sn":"Doe","company":"Company","street":"street 123","postalcode":"12345","city":"city","telephonenumber":["+49123456789"],"homephone":[],"mobile":["+49123456789"],"sip":[],"email":["john.doe@domain.de"]}}}

Related Articles

Known issues