Reference13r1:Concept Number Resolution and LDAP: Difference between revisions
mNo edit summary |
|||
Line 179: | Line 179: | ||
This additional carrier information can be removed within the routing by deactivating the flag "[[Reference12r2:Gateway/Routes/Map|Interworking (QSIG,SIP)]]" in the incoming SIP route. | This additional carrier information can be removed within the routing by deactivating the flag "[[Reference12r2:Gateway/Routes/Map|Interworking (QSIG,SIP)]]" in the incoming SIP route. | ||
== | == MyAPPs - Forward Search with LDAP Object == | ||
In case of non-working search request to a configured LdapApp-object, one can search in the myapps traces and crosscheck for related responses. | |||
In the following example an | In the following example an LdapApp-object exists with the Name "MetaDir" and is configured as App to the User who searches for "jon doe": | ||
// search pattern is "jon doe" | // search pattern is "jon doe" | ||
PhoneSearchBar::onSearchInputChange() input=jon doe | PhoneSearchBar::onSearchInputChange() input=jon doe | ||
One can see the following lines in myAPPs-trace: | |||
// start connection and login | // start connection and login |
Revision as of 10:07, 11 November 2019
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).
- Name to Number (Forward Search)
- Forward search differs between software and hardware:
- myApps
- 1-to-n relationship. A user can search simultaneously in multiple sources
- Desk phone
- Search can be done according to the LDAP configuration in the external directories settings of the user object.
Number to Name (Reverse Lookup)
Concept
Resolution is done at the PBX for incoming calls without any embedded display 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
Following prerequisites apply:
Prefix section
Depending on the PBX setup (flat or nodes) prefixes are defined either in the general PBX config and/or in the node/pbx-objects. The deepest definition is taken into account for number conversion/adaption only.
In general, prefix definition may contain prefixes for
- International (INT)
- National (NTL)
- Subscriber (SUB)
- Area Code (AC)
- Country Code (CC)
Usage and definition depend on the country specific number plan.
The PBX always tries to format the incoming number (CGPN) by performing a headmatch with the above mentioned prefixes in left to right order. In case of any prefix field is empty, the next one will be investigated.
Following rules apply upon prefix match:
- INT prefix matches: remove INT prefix
- NTL prefix matches: remove NTL prefix, prepend CC
- SUB prefix matches: remove SUB prefix, prepend CC + AC
Examples
1) German mobile call (best practice pbx config)
- CGPN: 00171123456 (0 Trunk + mobile number)
- PBX Prefixes (INT/NTL/SUB/AC/CC): 000/00/0/7031/49
- Result: 49171123456
2) German mobile call (missing pbx config)
- CGPN: 00171123456 (0 Trunk + mobil number)
- PBX Prefixes (INT/NTL/SUB/AC/CC): none
- Result: 00171123456
3) German city call (typically ISDN, SIP-CGPNs are always signaled in international format)
- CGPN: 0123456 (0 Trunk + local subscriber number)
- PBX Prefixes (INT/NTL/SUB/AC/CC): 000/00/0/7031/49
- Result: 497031123456
4) Spain national call (no SUB)
- CGPN: 0925123456 (0 Trunk + national number)
- PBX Prefixes (INT/NTL/SUB/AC/CC): 000/0//912/34
- Result: 925123456
URL definition
In general, reverse lookup uses the above created result after number conversion with prefixes. Depending on the use phone book source, the reverse lookup URL might look different. The number handed over to those source needs to be adapted by use of following variables:
- %n - cgpn
- if phone book entries are stored in international format with "+xyz", leading "+" may be prepended by using this notation: '+%n'
- if phone book entries are stored in international format with "00xyz", leading "00" may be prepended by using this notation: '00%n'
- %u - h323 name of the current object. Used to change the relationship of the searchbase to the user. A specific LDAP source can be requested depending of the user which receive the call.
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
Active Directory
ldap://domain.tld:389/OU=tld,OU=company,DC=city,DC=LOCAL?givenname,sn,company?sub?(|(telephoneNumber=+%n)(mobile=+%n)(homePhone=+%n))?bindname=domain\username
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
Legacy Device Configuration
By default, 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 display name information. Some SIP provider will send the phone number as additional Display Name Information. In this case the Reverse Lookup will not be performed.
This additional carrier information can be removed within the routing by deactivating the flag "Interworking (QSIG,SIP)" in the incoming SIP route.
MyAPPs - Forward Search with LDAP Object
In case of non-working search request to a configured LdapApp-object, one can search in the myapps traces and crosscheck for related responses.
In the following example an LdapApp-object exists with the Name "MetaDir" and is configured as App to the User who searches for "jon doe":
// search pattern is "jon doe" PhoneSearchBar::onSearchInputChange() input=jon doe
One can see the following lines in myAPPs-trace:
// 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"]}}}