Reference13r1:Concept Number Resolution and LDAP: Difference between revisions

From innovaphone wiki
Jump to navigation Jump to search
 
(45 intermediate revisions by 9 users not shown)
Line 8: Line 8:


= Short overview and scenarios =
= Short overview and scenarios =
There are basically two different directions for resolutions.
There are basically two different directions for resolutions:


* Number to Name (Reverse Lookup)
* Number to Name (Reverse Lookup)
:Backward resolutions are performed centrally for calls on the PBX-level calls. A [[Reference13r1:PBX/Config/General|''Reverse Lookup URL'']] can be stored per PBX.
:Backward resolutions are performed centrally for incoming and outgoing calls on PBX-level. A [[Reference13r1:PBX/Config/General|''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).<br>
: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)
* Name to Number (Forward Search)
:In the search, we still distinguish between software and hardware.
:Forward search differs between software and hardware:
:* myApps
:* myApps
::Here exists a 1-to-n relationship. A user search simultaneously in multiple sources
::1-to-n relationship. A user can search simultaneously in multiple sources
:* Desk phone
:* Desk phone
::Here the well known V12 scenario is still used and the [[Reference13r1:Phone/User/Directories|external directories]] in the user object can be used for the LDAP configuration.
::Search can be done according to the LDAP configuration in the [[Reference13r1:Phone/User/Directories|external directories]] settings of the user object.


=Number to Name (Reverse Lookup)=
=Number to Name (Reverse Lookup)=


== Concept ==
== 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 at the PBX for incoming and outgoing calls according to the locally defined reverse lookup setting. The URL might be different within PBXes of the same system (master, slaves).
 
For a general overview about the URL definition, refer to the [[Reference13r1:Concept_Reverse_Lookup|concept article on reverse lookup]].
 
In incoming direction resolution is done only for calls without any provider embedded display name information.


Resolution is done by LDAP-queries against sources like the PBX phonebook itself, V13-contacts application or any external 3rd-pty directory.
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 [[Reference13r1:PBX/Config/General|PBX/Config/General]].<br>
Setup is done via the ''Reverse Lookup URL'' which is configured under [[Reference13r1:PBX/Config/General|PBX/Config/General]].<br>
If a resolution succeeds via this mechanism, the resolved name is given to all other applications/locations. (MyApps, Phones (also DECT), CDRs, Reporting, eg.)
If a resolution succeeds via this mechanism, the resolved name is given to all other applications/locations. (MyApps, Phones (also DECT), CDRs, Reporting, Call-List, etc.)
 
With PBX-based ReverseLookup, the resolved name is forwarded to the destination via a facility. Therefore, this feature is only available for H323 connections.


== PBX Configuration ==
== PBX Configuration ==
Line 37: Line 42:
Otherwise, you can use any other LDAP Server that you want. The URL is an [https://tools.ietf.org/html/rfc2255 RFC2255] encoded string. The format is explained [[Reference13r1:PBX/Config/General|here]]
Otherwise, you can use any other LDAP Server that you want. The URL is an [https://tools.ietf.org/html/rfc2255 RFC2255] encoded string. The format is explained [[Reference13r1:PBX/Config/General|here]]


Of course only attributes which exist in the external directory will be resolved.
Since v13r1sr10 the LDAP-URL support also the attribute DN (Distinguished Name) see : [http://wiki.innovaphone.com/index.php?title=Reference13r1:Release_Notes_Firmware#66919_-_PBX_Reverse_Lookup:_Allow_X.500_bindname_format Reference13r1:Release Notes Firmware]
 
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.
Only the "deepest" definition is taken into account for number conversion/adaption. In case of empty prefixes, no higher-leveled definitions are taken into account.
 
E.g. if the called pbx-user is located within a node, the prefix definition of this node is used for number normalisation. If those node prefixes are empty, no other prefixes in e.g. PBX-general are used.
 
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 tries to format the incoming number (CGPN) by performing a match against the 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)<br>
:CGPN: 00171123456 (0 Trunk + mobile number)<br>
:PBX Prefixes (INT/NTL/SUB/AC/CC): 000/00/0/7031/49<br>
:Result: 49171123456<br>
 
2) German mobile call (missing pbx config)<br>
:CGPN: 00171123456 (0 Trunk + mobil number)<br>
:PBX Prefixes (INT/NTL/SUB/AC/CC): none<br>
:Result: 00171123456<br>
 
3) German city call (typically ISDN, SIP-CGPNs are always signaled in international format)<br>
:CGPN: 0123456 (0 Trunk + local subscriber number)<br>
:PBX Prefixes (INT/NTL/SUB/AC/CC): 000/00/0/7031/49<br>
:Result: 497031123456 <br>
 
4) Spain national call (no SUB)<br>
:CGPN: 0925123456 (0 Trunk + national number)<br>
:PBX Prefixes (INT/NTL/SUB/AC/CC): 000/0//912/34<br>
:Result: 925123456<br>
 
=== 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'. This is the default setting configured by Installer.
** 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 ===
==== Contacts App ====


  ldaps://ap.domain.tld/dc=entries?givenname,sn,company?sub?(metaSearchNumber=+%n)?bindname=domain.de\contacts
  ldaps://ap.domain.tld/dc=entries?givenname,sn,company?sub?(metaSearchNumber=+%n)?bindname=domain.de\contacts
Line 45: Line 108:
Contacts is asked by further instances (e.g. PhoneAPP) for details about the found contact via websocket query.
Contacts is asked by further instances (e.g. PhoneAPP) for details about the found contact via websocket query.


=== Estos MetaDir ===
==== Estos MetaDir ====


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


=== C4B ===
==== C4B ====


  to be tested
  ldap[s]://c4b.domain.tld:[Port]/vdir=VDir?givenname,sn,company?sub?(|(telephoneNumber=+%n)(mobile=+%n)(homePhone=+%n))?bindname=c4b.domain.tld\telbook


=== Active Directory ===
==== 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
  ldaps://domain.tld:636/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 ===
==== PBX as LDAP Server ====


This refers to the legacy [[Howto:Maintaining a Phone Directory in the PBX| PBX-directory solution]].
This refers to the legacy [[Howto:Maintaining a Phone Directory in the PBX| PBX-directory solution]].


  ldap://ldap.domain.tld/cn=PBX0?dn,e164,email?sub?(&(node=PhoneBook)(e164=000%n))?bindname=telbook
  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 ==
== 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.
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 [[Reference13r1:Phone/User/Preferences | option "Disable Phonenumber Look-up"]] at Phone/User/Preferences.
Optionally, it is possible to enable the resolution directly at the phone. This is done by unticking the [[Reference13r1:Phone/User/Preferences | option "Disable Phonenumber Look-up"]] at Phone/User/Preferences.
Line 76: Line 137:


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.
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.
== DECT ==
In V13, reverse number lookup for DECT systems is also done via the PBX-defined ReverseLookupURL.
Definition of any reverse lookup destination in DECT/Config/Master is obsolete.


=Name to Number (Forward Search)=  
=Name to Number (Forward Search)=  
Line 85: Line 152:
== UsersApp ==
== UsersApp ==
All PBX users can be searched via the UsersApp.
All PBX users can be searched via the UsersApp.
Preventing PBX-users from being found in Users/PhoneApp can be realized by disabling option "Visible" in privacy settings.


== ContactsApp ==
== ContactsApp ==
Line 94: Line 163:
Configure LDAP query with Contacts e.g. at phone:
Configure LDAP query with Contacts e.g. at phone:
* use of the correct user incl. domain (e.g. domain.tld\contacts)
* use of the correct user incl. domain (e.g. domain.tld\contacts)
* Correct password (in plain text in PBXManager/APContacts/configuration)
* Correct password (visible in plain text in PBXManager/APContacts/configuration, checkmark show password)
* Search attributes:
* Search attributes:
** Meta Name Attributes -> metaSearchText
** Meta Name Attributes -> metaSearchText
** Meta Number Attributes -> metaSearchNumber
** Meta Number Attributes -> metaSearchNumber


== PhoneApp / SoftphoneApp / myPBX ==
== PhoneApp / SoftphoneApp / myAPPs ==
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.
Within Phone/SoftphoneAPP search requests can be performed towards multiple sources in parallel if assigned to the respective user.


=== LDAP Object ===
=== LDAP Object ===
Line 112: Line 178:


LDAP object has to be assigned via App-tab to dedicated user / configuration template.
LDAP object has to be assigned via App-tab to dedicated user / configuration template.
The Phone/Softphone App only shows matches where there are matches at dn, sn, givenname, company, as these are the only attributes that are displayed in the Phone/Softphone app.
== myPBX ==
For myPBX, forward search is performed as usual via the [[Reference13r1:Phone/User/Directories | Phone/User/Directories]].
myPBX does not perform forward search in databases defined via ldap-objects.


== Outlook ==
== Outlook ==
* Works with myAPPs windows launcher and so Windows compliant only
* Works with myAPPs and myPBX [[Reference13r1:Concept_myAPPs_Search_in_local-Outlook_Contacts|'''windows launcher''']] and so Windows compliant only
* Outlook Search will find contacts in all exchange accounts and all contact folders from these accounts
* 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)
* requires a configured MAPI profile in Outlook (Exchange Account)
Line 120: Line 192:
== Hardware Phone ==
== Hardware Phone ==
Search on the hardware phone is done by use of the [[Reference13r1:Phone/User/Directories|configured directories]] at the phone.
Search on the hardware phone is done by use of the [[Reference13r1:Phone/User/Directories|configured directories]] at the phone.
In case of phone connection via ReverseProxy, refer to [[Howto:V13_LDAP_IP_Phones_Directory_Services_via_Reverse_Proxy|this description]] on how to configure search.


= Troubleshooting =
= Troubleshooting =


== Reverse Lookup doesn't work on SIP Trunk ==
== Reverse Lookup doesn't work ==
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.<br>
 
You can remove this additional information from your carrier in the routing by deactivating the Flag "[[Reference12r2:Gateway/Routes/Map|Interworking (QSIG,SIP)]]" in the incoming SIP Route.
=== SIP Trunk name delivery ===
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.<br>
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.
 
=== Contacts password ===
Reverse lookup against contacts does not work due to wrong password usage. Password used at ReverseLookupURL has to be equal to password defined at AP Contacts settings in PBXManager
 
== 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. The trace can be taken with the web console of your browser (F12), or by activating the trace flag "[[Reference13r1:Concept_myApps#Tracing_and_logging|Browser]]" available in your myApps client.


== 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 the following example an LdapApp-object exists with the Name "MetaDir" and is configured as App to the User who searches for "jon doe":
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"
  // search pattern is "jon doe"
  PhoneSearchBar::onSearchInputChange() input=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.
One can see the following lines in myAPPs-trace:


  // start connection and login  
  // start connection and login  
Line 159: Line 240:
* [[Reference13r1:PBX/Objects/LDAP]]
* [[Reference13r1:PBX/Objects/LDAP]]
* [[Reference13r1:Phone/User/Directories]]
* [[Reference13r1:Phone/User/Directories]]
* [[Reference13r1:Concept_App_Contacts]]
* [[Reference13r1:Concept_App_Service_Contacts]]
* [[Howto:V13_LDAP_IP_Phones_Directory_Services_via_Reverse_Proxy]]
* [[Reference13r1:Concept_Number_Adjustments_(Dialing_Location)]]
* [[Reference13r1:Concept_Reverse_Lookup]]
* [[Reference13r1:Concept_myAPPs_Search_in_local-Outlook_Contacts]]

Latest revision as of 08:01, 27 June 2022

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 incoming and outgoing calls on PBX-level. 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 and outgoing calls according to the locally defined reverse lookup setting. The URL might be different within PBXes of the same system (master, slaves).

For a general overview about the URL definition, refer to the concept article on reverse lookup.

In incoming direction resolution is done only for calls without any provider embedded display name information.

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, Call-List, etc.)

With PBX-based ReverseLookup, the resolved name is forwarded to the destination via a facility. Therefore, this feature is only available for H323 connections.

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

Since v13r1sr10 the LDAP-URL support also the attribute DN (Distinguished Name) see : Reference13r1:Release Notes Firmware

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. Only the "deepest" definition is taken into account for number conversion/adaption. In case of empty prefixes, no higher-leveled definitions are taken into account.

E.g. if the called pbx-user is located within a node, the prefix definition of this node is used for number normalisation. If those node prefixes are empty, no other prefixes in e.g. PBX-general are used.

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 tries to format the incoming number (CGPN) by performing a match against the 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'. This is the default setting configured by Installer.
    • 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

ldap[s]://c4b.domain.tld:[Port]/vdir=VDir?givenname,sn,company?sub?(|(telephoneNumber=+%n)(mobile=+%n)(homePhone=+%n))?bindname=c4b.domain.tld\telbook

Active Directory

ldaps://domain.tld:636/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.

DECT

In V13, reverse number lookup for DECT systems is also done via the PBX-defined ReverseLookupURL. Definition of any reverse lookup destination in DECT/Config/Master is obsolete.


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.

Preventing PBX-users from being found in Users/PhoneApp can be realized by disabling option "Visible" in privacy settings.

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 (visible in plain text in PBXManager/APContacts/configuration, checkmark show password)
  • Search attributes:
    • Meta Name Attributes -> metaSearchText
    • Meta Number Attributes -> metaSearchNumber

PhoneApp / SoftphoneApp / myAPPs

Within Phone/SoftphoneAPP search requests can be performed towards multiple sources in parallel if assigned to the respective 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.

The Phone/Softphone App only shows matches where there are matches at dn, sn, givenname, company, as these are the only attributes that are displayed in the Phone/Softphone app.

myPBX

For myPBX, forward search is performed as usual via the Phone/User/Directories. myPBX does not perform forward search in databases defined via ldap-objects.

Outlook

  • Works with myAPPs and myPBX 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.

In case of phone connection via ReverseProxy, refer to this description on how to configure search.

Troubleshooting

Reverse Lookup doesn't work

SIP Trunk name delivery

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.

Contacts password

Reverse lookup against contacts does not work due to wrong password usage. Password used at ReverseLookupURL has to be equal to password defined at AP Contacts settings in PBXManager

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. The trace can be taken with the web console of your browser (F12), or by activating the trace flag "Browser" available in your myApps client.


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"]}}}

Related Articles