innovaphone wiki - User contributions [en]

Howto:Doorbell - MediaRunway - Partner App

2025-03-13T14:20:39Z

Achim.klix: /* Installation */

[[Image:Mediarunway_company_logo_200.png|200px|right|mediarunway_company_logo_200.png/]]

==Product Name==


MediaRunway [https://mediarunway.com/myapps/ Doorbell]

==Certification Status==

{{Template:Compat_Status_referral_product_new|type=App}}

This App has been listed Juni 2023.

==Category==

[[Category:Partner Apps|{{PAGENAME}}]]
[[Category:3rdParty CTI and integrations|{{PAGENAME}}]]
{{Category:3rdParty CTI and integrations}}

==Vendor==



[[Image:Mediarunway_company_logo_150_2.png|150px|mediarunway_company_logo_150_2.png/]]




MediaRunway is an ITC enterprise that provides its customers with contemporary IT services in all areas - Your business, our solution.


[https://www.mediarunway.com/ MediaRunway - About us]

==Description==



[[Image:Mediarunway-doorbell.png|mediarunway-doorbell.png/]]




Doorbell allows you to connect your door intercom to the innovaphone myApps system. This makes it possible to receive the ringing of a visitor like a phone call and additionally view the image of the camera in your softphone while taking to the visitor or opening your door by a "soft button" click.


[https://mediarunway.com/myapps/ MediaRunway - About this application]




==Functions==



The doorbell app is a video and function key add-on to the innovphone myApps softphone/ phone app.

If the myApps doorbell app is installed correctly, then there is a "doorbell" and a "doorbell admin" app. The doorbell admin app hasn´t to be licensed. With this app you can configure the door bell intercoms, the licensing and which user get the doorbell function. Each user who should get the doorbell function has to get access to the "doorbell" app (not "doorbell admin"). But a user will not see an app icon of the "doorbell" app, because it is a hidden app, which will integrate on thy fly in the innovphone myApps phone app if a configured doorbell is calling.

Videos: [https://www.youtube.com/watch?v=zSSxXEe-QCs DE] | [https://www.youtube.com/watch?v=Z70INs8ApK8 EN]

We succsessfull tested door bell intercoms from the following vendors with the myApps doorbell app (doorbell and pbx were connected directly via network layer 2 and a installed myApps client on Windows, iOS, Android): 2N, Axis, Mobotix, Telecom Behnke

If no direct access to the camera over lan exists, then the client will get alternativly, if possible, an image of the camera through the myApps app platform (pre-condition the app platform could access the camera video/ image source). Thats should be the default behavior for a smartphone on the road without active company vpn. For the possible different video/ image paths look in this wiki article under prerequisites.


==Licensing==



Licensing: innovaphone licensing. One Doorbell App App (User) license per user with any number of doorbell devices. No floating licensing, only the users who got a configured license have access.
The user must also have a myApps phone app.

==Prerequisites==


'''Required other licenses'''

The user who should use the doorbell app needs a licensed myApps softphone/ phone app and access to myApps.

'''Voice / function-key'''

The app is a video and function key add-on to the innovaphone myApps phone app. So the voice communication with the door bell intercom has to work first. In the innovaphone wiki you find infos to connect some door intercom models to connect them with the innovaphone pbx, for example a [http://wiki.innovaphone.com/index.php?title=Howto:V13_MyApps_Cloud_-_connecting_2N-Intercom 2N in a cloud scenario].
The configured function key to open via DTMF the door works independently of the camera video/ image access. So only the voice path has to work independently of the doorbell app.

'''Video/ image access'''

The myApps user/client which should get access to the camera video/ image has to have anonymous access to the MJPEG/ JPEG source via http/ htpps of the camera.
Example to configure anonymous access for a "2N IP Verso" door bell intercom (in 08/2022). You have to navigate to Service>HTTP API. There you have to enable "Camera API" and set "Authentication" to "none", if only a self signed certificate for ssl exist, then we recommend "unsecure (TCP)" for "connection type" and then we also recommend to use myApps with an installed client (Windows, Android, iOS was tested).
For more security you could restrict the anonymous video/ image access with network secruity mechanism (firewalling rules, etc.). What we recommend not to do is to do a port forwarding from WAN to the camera video/ image port. So that we didn´t describe that video path possibility.
The access to the video image depends on how the user is connected to myApps. We could decide between two big different scenarios

1. the pbx / app plattform and maybe one or more reverse proxys which are installed on premise in the customer company wlan

2. the pbx / app plattform and reverse proxy installed on the cloud provider side

Each of the following two diagrams show one of the to big different scenarios. And each picture shows an abstract example for that scenario and which paths exist to access the camera video/ image from a myApps client.

[[Image:Doorbell-videopath-onPremPBX.png|doorbell-videopath-onprempbx.png/]]

----

[[Image:Doorbell-videopath-cloudPBX.png|doorbell-videopath-cloudpbx.png/]]

'''App installing knowledge'''

Knowledge about installing an App, adding the App Object for the users and how to configure your doorbell model for the access. The steps of the installation process are the same as described in this article [https://wiki.innovaphone.com/index.php?title=Howto:Callback_-_mediarunway_-_3rd_Party_Product#Install_app_from_App_Store "Callback - Install App from App Store"] only with different names. We need to install the app, add an app instance, and the app objects, the names of these can be found in the [https://wiki.innovaphone.com/index.php?title=Howto:IFrame_-_MediaRunway_-_3rd_Party_Product#Configuration "Configuration"] area of this article.

What you need is this Wiki article and a valid license. For a valid license please install the app and in the admin area of the app you will find the authentication key. Please send us this authentication key, together with the number of users and the desired license period to [mailto:myApps-sales@mediarunway.com myApps-sales@mediarunway.com].

==Versions==


* MediaRunway Doorbell 1.0 (132xxx sr13)

===Compatible innovaphone firmware versions===

* MediaRunway Doorbell 1.0 (132xxx sr13)
** innovaphone V13r2, V13r3, V14r1

===Application versions used for interop testing===


* MediaRunway Doorbell 1.0 (132xxx sr13)

** innovaphone IPVA V13r2sr13

==Configuration==








...

==Installation==








The steps of the installation process are the same as described in this article [https://wiki.innovaphone.com/index.php?title=Howto:Callback_-_mediarunway_-_3rd_Party_Product#Install_app_from_App_Store "Callback - Install App from App Store"] only with different names. We need to install the app, add an app instance, and the app objects.

Important: after deplyoing the app to the user, the user has to reload myApps to get the video-popup

==Contact==




{|
| MediaRunway GmbH & Co. KG
|-
| Venloer Str. 8
|-
| D-41569 Rommerskirchen
|-
| Tel: +49 2183 80628-0
|-
| Mail: [mailto:myApps-sales@mediarunway.com myApps-sales@mediarunway.com]
|-
| Support: [mailto:myApps-support@mediarunway.com myApps-support@mediarunway.com]
|-
| Website: [https://www.mediarunway.com/ MediaRunway.com]
|}

For any questions please refer to [https://mediarunway.com/contact/ our contact page].

Reference13r1:Concept Number Resolution and LDAP

2019-11-12T13:52:12Z

Achim.klix: /* C4B */

= 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 [[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).

* 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 [[Reference13r1:Phone/User/Directories|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 [[Reference13r1:PBX/Config/General|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 [[Reference13r1:PBX/Config/General|''Reverse Lookup URL'']]. 
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]]

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'
** 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://vdir.domain.tld:712/vdir=VDir?givenName,sn,company?sub?(|(telephoneNumber=+%n)(mobile=+%n)(homePhone=+%n))

==== 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 [[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

== 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 [[Reference13r1:Phone/User/Preferences | 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 [[Course13:IT_Connect_-_09.0_Contacts|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 [[Reference13r1:PBX/Objects/LDAP|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 [[Reference13r1:Phone/User/Directories|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 "[[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 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 =
* [[Reference13r1:PBX/Config/General]]
* [[Reference13r1:PBX/Objects/LDAP]]
* [[Reference13r1:Phone/User/Directories]]
* [[Reference13r1:Concept_App_Contacts]]

Reference13r1:Concept Number Resolution and LDAP

2019-11-12T13:51:56Z

Achim.klix: /* C4B */

= 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 [[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).

* 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 [[Reference13r1:Phone/User/Directories|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 [[Reference13r1:PBX/Config/General|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 [[Reference13r1:PBX/Config/General|''Reverse Lookup URL'']]. 
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]]

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'
** 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 ====

tested with anonymous request:
ldap://vdir.domain.tld:712/vdir=VDir?givenName,sn,company?sub?(|(telephoneNumber=+%n)(mobile=+%n)(homePhone=+%n))

==== 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 [[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

== 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 [[Reference13r1:Phone/User/Preferences | 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 [[Course13:IT_Connect_-_09.0_Contacts|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 [[Reference13r1:PBX/Objects/LDAP|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 [[Reference13r1:Phone/User/Directories|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 "[[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 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 =
* [[Reference13r1:PBX/Config/General]]
* [[Reference13r1:PBX/Objects/LDAP]]
* [[Reference13r1:Phone/User/Directories]]
* [[Reference13r1:Concept_App_Contacts]]

Reference13r1:Concept Number Resolution and LDAP

2019-11-12T13:50:19Z

Achim.klix: /* C4B */

= 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 [[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).

* 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 [[Reference13r1:Phone/User/Directories|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 [[Reference13r1:PBX/Config/General|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 [[Reference13r1:PBX/Config/General|''Reverse Lookup URL'']]. 
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]]

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'
** 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 ====

tested with anonymous request:
ldap://ip-vdir-server:712/vdir=VDir?givenName,sn,company?sub?(|(telephoneNumber=+%n)(mobile=+%n)(homePhone=+%n))

==== 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 [[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

== 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 [[Reference13r1:Phone/User/Preferences | 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 [[Course13:IT_Connect_-_09.0_Contacts|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 [[Reference13r1:PBX/Objects/LDAP|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 [[Reference13r1:Phone/User/Directories|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 "[[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 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 =
* [[Reference13r1:PBX/Config/General]]
* [[Reference13r1:PBX/Objects/LDAP]]
* [[Reference13r1:Phone/User/Directories]]
* [[Reference13r1:Concept_App_Contacts]]

Reference13r1:Concept Number Resolution and LDAP

2019-11-12T13:50:06Z

Achim.klix: /* C4B */

= 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 [[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).

* 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 [[Reference13r1:Phone/User/Directories|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 [[Reference13r1:PBX/Config/General|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 [[Reference13r1:PBX/Config/General|''Reverse Lookup URL'']]. 
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]]

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'
** 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 ====

tested with anonymous request:
ldap://ip-vir-server:712/vdir=VDir?givenName,sn,company?sub?(|(telephoneNumber=+%n)(mobile=+%n)(homePhone=+%n))

==== 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 [[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

== 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 [[Reference13r1:Phone/User/Preferences | 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 [[Course13:IT_Connect_-_09.0_Contacts|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 [[Reference13r1:PBX/Objects/LDAP|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 [[Reference13r1:Phone/User/Directories|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 "[[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 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 =
* [[Reference13r1:PBX/Config/General]]
* [[Reference13r1:PBX/Objects/LDAP]]
* [[Reference13r1:Phone/User/Directories]]
* [[Reference13r1:Concept_App_Contacts]]

Reference12r1:PBX/Config/General

2017-12-08T10:56:42Z

Achim.klix: /* Common */

The fundamental operating modes of the PBX are configured on this page.

== Configuration ==

=== Common ===

;PBX Mode: The PBX operating mode
:* '''Off''' - The PBX is disabled. After enabling the PBX a browser refresh is needed to activate additional PBX webpages.
:* '''Master''' - The PBX on this device acts as Master. Within a multisite installation exactly one PBX must be configured as Master.
:* '''Slave''' - The PBX on this device acts as Slave. Within a multisite installation several PBXes can be configured as Slave.
:* '''Standby''' - The PBX on this device acts as Standby for the Master. As long as the master is available, this PBX is not active, but just monitors the Master. If the Master is not available this PBX is active.
:* '''Standby-Slave''' - The PBX on this device acts as Standby for a Slave. As long as the slave is available, this PBX is not active, but just monitors the slave. If the slave is not available this PBX is active.

;System Name: The system Name. On all PBX within a multisite installation the same System Name must be configured. For H.323 endpoints this name is the gatekeeper identifier, for SIP endpoints it is the server name.

;Use as Domain: Uses the ''System Name'' as domain name, together with the name field in the user object the PBX constructs the email address (used for sending emails out ox myPBX). This mechanism is also used for Federation, to federate with other domains.

;PBX Name: The name of the PBX on this device. With this name a PBX is associated to a node. The field 'Name' (not Long Name) of a PBX Node object relates to this name.

;DNS: DNS Name of the PBX. If configured this will be used for myPBX redirects if a client tries to register at a PBX on which the user is not configured.

;Unknown Registrations: If this checkmark is set, the PBX accepts 'unknown' registrations. This means registrations with no matching object configured. If from an endpoint registered in this way a number of an object is dialed, which has no registration active and no 'HW-ID' configured the name used for the registration is configured as 'HW-ID' of this object. This is an easy way to deploy large numbers of phones.

:'''With PBX Pwd only:''' If checked only registrations with a PBX authentication or a verfiied certificate in case of H.323/TLS are accepted. In this case either "PBX Pwd" or "TLS only" is set in a device generated.

;Reverse Proxy Addresses: Up to 8 addresses (no DNS names allowed) can be entered in this field, seperated by comma. Registrations from one of these addresses are assumed to be routed thru a Reverse Proxy.
: '''Assume TLS''': If the ''Assume TLS'' checkmark is set, it is assumed, that the reverse Proxy did a successful check of the TLS certificate against the registration name.

;Music On Hold URL: A URL for the Music On Hold. This file is read by the PBX using HTTP and sent to a held endpoint via RTP. The format of this URL is

:'''<nowiki>http://<addr>/<file>.$coder?coder=opus-wb,g722,g711a,g711u,g729,g723&repeat=true</nowiki>'''. <addr> is the IP address of the http server, no dns name is allowed here. <file> is the filename. $coder will be replaced by the actual coder used.

:Parameters: ''coder=opus-wb,g722,g711a,g711u,g729,g723'' is the list of available coders. Only these coders must be specified for which a corresponding file exists. ''repeat=true'' should be specified in order to loop the file endlessly. ''random=true'' can be used to start the music on hold on a random point (this will work only if the URL is not local though).

:By default the built-in Music-On-Hold is played (Pseudo URL: "MOH?coder=g729,g711a,g723&repeat=true"). You can also play a dial tone (Pseudo URL "TONE") or a ring-back tone (Pseudo URL "TONE?tone=ringback").

:If you configure a wrong (or invalid) URL then you will have silence as MOH. To prevent this situation when the MoH for some specific context/user(see below) is missing and silence is played instead of any MoH, an additional parameter ''fallback=true'' is available. If the file provided in the URL is missing (HTTP Error 404 Not Found is delivered by the HTTP Server) and the parameter ''fallback'' is provided, the default MoH will be played instead of silence. To use a custom file as fallback MoH, instead of default MoH, any file name can be provided with the ''fallback'' parameter: e.g. ''fallback=other_filename''. The file other_filename.g7xx must be placed in the same folder as a file provided with URL. A special filename ''fallback=ringback'' can be used to generate a ringback tone (equivalent to ''TONE?tone=ringback'') instead to play an alternative file.

:Within the URL %<id> can be used to put in some context information of the call. The information refers to the party which has put the receiving party on hold. For information about the receiving party itself, the id has to be preceded by '.' (e.g. '''.l''').

:'''l''' Long Name
:'''h''' Name (H.323 id)
:'''n''' Number
:'''N''' Node
:'''P''' PBX
:'''d''' Diverting Name
:'''#d''' Diverting Number

;External Music On Hold: To offload the device from playing the Music on hold, the Music On Hold can be played by a separate device. This device can register with a name configured here. To retrieve the Music On Hold a call is sent to this device. For each held endpoint a call is sent.

;Response Timeout: Global timeout (in seconds) after which any action for no response is taken (e.g. Call Forward on No Response). A timeout configured at any object overrides this value.

;Dial Complete Timeout: Global timeout (in seconds) after which any action for incomplete dialed number is taken (e.g. incomplete destination at trunk object).

;No. of Regs w/o Pwd: Number of registration without password authentication which are allowed per user. If 0 is configured no registration without password is possible.
Pls. note that registrations from 127.0.0.1 w/o password will be accepted anyway

;Recall Timeout: A value configured here enables recall after transfer. If a call is transferred and not answered within this time, the call is sent back to the transferring endpoint.

;Max Call Duration (h): Number of hours until a call with media is disconnected automatically. Affects all calls with initialized media channels signalled via PBX.

;Max WebRTC calls: Sets the max. amount of concurrent WebRTC calls. ''Usage: x (max y)'' The counters ''x'' and ''y'' show the current amount of WebRTC calls respectively the max. amount of concurrent calls, measured since the last reboot of the PBX.

;Group Default Visibility: Allows to restrict default visibility to active group members. If changed active subscriptions are not affected. Is used to prevent standard users from getting access to sensitive information like activities/presences of group members in myPBX. If not generally allowed by the administrator via this setting, normal users are not able to change it via myPBX.

;Pickup Prefix V7: In V7, the pickup prefix is obsolete. Please use the pbx object [[:Reference7:Administration/PBX/Objects/DTMF Features|DTMF Featurecodes]].

;Presence with Alert: Enable presentation of presence on phone upon alert. Setting applies for all PBX users. Alternatively, display of presence subject only delivered by Exchange can be prohibited - see [[Reference10:Concept_Exchange_Calendar_Connector#Exchange|Exchange Calendar Connector : Omit Subject]]

;Enable External Transfer: Unless this checkbox is set any attempt to transfer an external call back to an external destination will result in disconnection of the call.

;No CLIR on Internal calls: If checked numbers are displayed even if received with presentation restricted. When sending a call presentation restricted can still be set and should be honored by a public network.

;Media Relay:
:;Off: No Media Relay is done in the PBX
:;On: All media traffic is routed through the PBX. With the '''No Media Relay if Addresses are identical or private''' checkmark, this is not done if the two call endpoints registration addresses are either private or equal (i.e. external endpoints behind the same NAT router). To identify an address as private the "Private Networks" configuration from ''IP4/General/Settings'' is used.
:;Auto: Media traffic is routed through the PBX if calls are between private and public registration addresses but not for calls between private and private or public and public registration addresses. To identify an address as private the "Private Networks" configuration from ''IP4/General/Settings'' is used. In v11 this was the behaviour if 'RTP Proxy'' was ''on''.
: Please note that when media relay is in effect for a call, '''video is not working'''. With ICE (available from v12r1), media relay in the PBX should be obsolete except for special applications. Check ''On'' or ''Auto'' only if you need to have this, since it creates CPU load on the PBX.

;Generate CDRs: If this checkbox is set, the PBX generates CDRs for all calls. See [[Reference9:Concept_Call_Detail_Record_CDR_PBX]] for a description of the CDRs.

;Route Root-Node External Calls to: Destination object (Long Name) of Root-Node external calls. This configuration option is available on the Master or Standby PBX only. Any call call which cannot be terminated inside the PBX is sent to this destination as long as neither the source nor the destination of the call can be associated with a node with a PBX configured. This object must be assigned to this PBX.
:'''For calls from local PBX only''': If set on a master, calls from a slave are not sent to this destination but sent back to the slave where the call came from. On the slave the call is then sent to a destination configured with 'Route Root-Node External Calls to'.

;Route PBX-Node External Calls to: Destination object (Long Name) of PBX-Node external calls. Any call which cannot be terminated inside the PBX is sent to this destination as long as the source nor the destination of the call can be associated with the node of this PBX. If a call is sent from or to an object defined inside the node of this PBX or in a node hierarchically below the node of this PBX the call is associated to the node of this PBX. This object must be assigned to this PBX, that is, it has to register to this PBX.

;Route Internal Calls to: Destination object (Long Name) to which any call is sent for which a PBX internal destination was found, except for those calls that originated from that object. This can be used to apply special routing on PBX internal calls.

;Escape Dialtone from: The PBX object (Long Name) to which a call is made to get a dialtone if a dialtone is configured for the escape of a node. As above, this object must be assigned to this PBX.

;Prefix for Intl/Ntl/Subscriber: Prefixes to be used to map International, National and Subscriber numbers. For example to send from the faxserver in the case that the received mail contains the number in international format, e.g. +49123456578@faxserver.local
:* '''International Prefix''' (<code>000</code> in Germany).
:* '''National Prefix''' (<code>00</code> in Germany).
:* '''Subscriber Numbers''' (in Germany, <code>0</code> is a commonly used trunk line access code).

;Tones: The tones scheme to be used for PBX generated dialtones. This applies to dialtones generated for node prefixes, ringback on transfer and some more.

=== Slave PBX ===

If the PBX is operated in Slave mode, then the Slave PBX section is displayed

;Registration: The VOIP protocol used for the registration to the master. Possible choices are H.323, H.323/TCP or H.323/TLS.

;Master: The IP address of the PBX master

;License Only: If set, the PBX obtains license from master, but acts as master in all other respects.

;Alternate Master: The IP address of an alternative PBX master (standby, if available)

;Password: The password to be used for registration at the Master as configured in the corresponding PBX Object

;Master GK-ID: The System Name/Gatekeeper ID of the PBX Master were will register (Optional, usually used for DynPBX).

;Replication: This parameter allows you to select the replication style for the slave PBX: either ''All'' or ''Local'' (only users that need to be known in this PBX).

;dyn PBX ID: This parameter allows to set replication from a specific DynPBX configured on the Master Device.

;Use local static User DB: A dynPBX has also this checkmark. The database of the main PBX is used, but be careful due to the increased memory usage. The dynPBX will create its own PBX datastructure which allocates memory.

;Route Master calls if no Master to: If the master is not available, master calls are sent to this destination

;Max Calls to Master/No Reroute: This parameter can be used to limit the calls to the master. If a call is sent to the master and there are already calls to/from the master equal to or exceeding this value, the call is rejected if '''No Reroute''' is set or is handled as if the master was not available otherwise.

;License Limits: Here we can set limit of licensing for this Slave PBX for Port, Mobility, Operator and Softwarephone.

For complete replication from master to slave, check also password in [[Reference9:Administration/PBX/Security]]

=== Standby PBX ===

If the PBX is operated in Standby mode, then the Standby PBX section is displayed

;Master: The IP address of the PBX master

;Replicate from Master: Turns on full replication from the master PBX

;use TLS: Use LDAPS (TLS) instead of LDAP (TCP).

For complete replication from master to standby, check also password in [[Reference9:Administration/PBX/Security]]

== License Status ==

=== Licenses ===

A list of all installed PBX license with their current usage is displayed here.

;Count: The total number of installed licenses of this type.

;Usage: The total usage of this license type

;Local: The usage of this license on this PBX

;Slaves: The usage of this license on PBX's registered to this PBX.

see [[Reference10:Licenses]] for a description of the licenses.

=== Registrations ===

The current number of registrations and the limit as defined by the base license is displayed here. Because this limit is defined by the base license it includes any registrations because of standby as well, which require no registration license.

Reference12r1:PBX/Config/General

2017-12-08T10:55:41Z

Achim.klix: /* Common */

The fundamental operating modes of the PBX are configured on this page.

== Configuration ==

=== Common ===

;PBX Mode: The PBX operating mode
:* '''Off''' - The PBX is disabled. After enabling the PBX a browser refresh is needed to activate additional PBX webpages.
:* '''Master''' - The PBX on this device acts as Master. Within a multisite installation exactly one PBX must be configured as Master.
:* '''Slave''' - The PBX on this device acts as Slave. Within a multisite installation several PBXes can be configured as Slave.
:* '''Standby''' - The PBX on this device acts as Standby for the Master. As long as the master is available, this PBX is not active, but just monitors the Master. If the Master is not available this PBX is active.
:* '''Standby-Slave''' - The PBX on this device acts as Standby for a Slave. As long as the slave is available, this PBX is not active, but just monitors the slave. If the slave is not available this PBX is active.

;System Name: The system Name. On all PBX within a multisite installation the same System Name must be configured. For H.323 endpoints this name is the gatekeeper identifier, for SIP endpoints it is the server name.

;Use as Domain: Uses the ''System Name'' as domain name, together with the name field in the user object the PBX constructs the email address (used for sending emails out ox myPBX). This mechanism is also used for Federation, to federate with other domains.

;PBX Name: The name of the PBX on this device. With this name a PBX is associated to a node. The field 'Name' (not Long Name) of a PBX Node object relates to this name.

;DNS: DNS Name of the PBX. If configured this will be used for myPBX redirects if a client tries to register at a PBX on which the user is not configured.

;Unknown Registrations: If this checkmark is set, the PBX accepts 'unknown' registrations. This means registrations with no matching object configured. If from an endpoint registered in this way a number of an object is dialed, which has no registration active and no 'HW-ID' configured the name used for the registration is configured as 'HW-ID' of this object. This is an easy way to deploy large numbers of phones.

:'''With PBX Pwd only:''' If checked only registrations with a PBX authentication or a verfiied certificate in case of H.323/TLS are accepted. In this case either "PBX Pwd" or "TLS only" is set in a device generated.

;Reverse Proxy Addresses: Up to 8 addresses (no DNS names allowed) can be entered in this field, seperated by comma. Registrations from one of these addresses are assumed to be routed thru a Reverse Proxy.
: '''Assume TLS''': If the ''Assume TLS'' checkmark is set, it is assumed, that the reverse Proxy did a successful check of the TLS certificate against the registration name.

;Music On Hold URL: A URL for the Music On Hold. This file is read by the PBX using HTTP and sent to a held endpoint via RTP. The format of this URL is

:'''<nowiki>http://<addr>/<file>.$coder?coder=opus-wb,g722,g711a,g711u,g729,g723&repeat=true</nowiki>'''. <addr> is the IP address of the http server, no dns name is allowed here. <file> is the filename. $coder will be replaced by the actual coder used.

:Parameters: ''coder=opus-wb,g722,g711a,g711u,g729,g723'' is the list of available coders. Only these coders must be specified for which a corresponding file exists. ''repeat=true'' should be specified in order to loop the file endlessly. ''random=true'' can be used to start the music on hold on a random point (this will work only if the URL is not local though).

:By default the built-in Music-On-Hold is played (Pseudo URL: "MOH?coder=g729,g711a,g723&repeat=true"). You can also play a dial tone (Pseudo URL "TONE") or a ring-back tone (Pseudo URL "TONE?tone=ringback").

:If you configure a wrong (or invalid) URL then you will have silence as MOH. To prevent this situation when the MoH for some specific context/user(see below) is missing and silence is played instead of any MoH, an additional parameter ''fallback=true'' is available. If the file provided in the URL is missing (HTTP Error 404 Not Found is delivered by the HTTP Server) and the parameter ''fallback'' is provided, the default MoH will be played instead of silence. To use a custom file as fallback MoH, instead of default MoH, any file name can be provided with the ''fallback'' parameter: e.g. ''fallback=other_filename''. The file other_filename.g7xx must be placed in the same folder as a file provided with URL. A special filename ''fallback=ringback'' can be used to generate a ringback tone (equivalent to ''TONE?tone=ringback'') instead to play an alternative file.

:Within the URL %<id> can be used to put in some context information of the call. The information refers to the party which has put the receiving party on hold. For information about the receiving party itself, the id has to be preceded by '.' (e.g. '''.l''').

:'''l''' Long Name
:'''h''' Name (H.323 id)
:'''n''' Number
:'''N''' Node
:'''P''' PBX
:'''d''' Diverting Name
:'''#d''' Diverting Number

;External Music On Hold: To offload the device from playing the Music on hold, the Music On Hold can be played by a separate device. This device can register with a name configured here. To retrieve the Music On Hold a call is sent to this device. For each held endpoint a call is sent.

;Response Timeout: Global timeout (in seconds) after which any action for no response is taken (e.g. Call Forward on No Response). A timeout configured at any object overrides this value.

;Dial Complete Timeout: Global timeout (in seconds) after which any action for incomplete dialed number is taken (e.g. incomplete destination at trunk object).

;No. of Regs w/o Pwd: Number of registration without password authentication which are allowed per user. If 0 is configured no registration without password is possible.
Pls. note that registrations from 127.0.0.1 w/o password will be accepted anyway

;Recall Timeout: A value configured here enables recall after transfer. If a call is transferred and not answered within this time, the call is sent back to the transferring endpoint.

;Max Call Duration (h): Number of hours until a call with media is disconnected automatically. Affects all calls with initialized media channels signalled via PBX.

;Max WebRTC calls: Sets the max. amount of concurrent WebRTC calls. ''Usage: x (max y)'' The counters ''x'' and ''y'' show the current amount of WebRTC calls respectively the max. amount of concurrent calls, measured since the last reboot of the PBX.

;Group Default Visibility: Allows to restrict default visibility to active group members. If changed active subscriptions are not affected. Is used to prevent standard users from getting access to sensitive information like activities/presences of group members in myPBX. If not generally allowed by the administrator via this setting, normal users are not able to change it via myPBX.

;Pickup Prefix V7: In V7, the pickup prefix is obsolete. Please use the pbx object [[:Reference7:Administration/PBX/Objects/DTMF Features|DTMF Featurecodes]].

;Presence with Alert: Enable presentation of presence on phone upon alert. Setting applies for all PBX users. Alternatively, display of presence subject only delivered by Exchange can be prohibited - see [[Reference10:Concept_Exchange_Calendar_Connector#Exchange|Exchange Calendar Connector : Omit Subject]]

;Enable External Transfer: Unless this checkbox is set any attempt to transfer an external call back to an external destination will result in disconnection of the call.

;No CLIR on Internal calls: If checked numbers are displayed even if received with presentation restricted. When sending a call presentation restricted can still be set and should be honored by a public network.

;Media Relay:
:;Off: No Media Relay is done in the PBX
:;On: All media traffic is routed through the PBX. With the '''No Media Relay if Addresses are identical or private''' checkmark, this is not done if the two call endpoints registration addresses are either private or equal (i.e. external endpoints behind the same NAT router). To identify an address as private the "Private Networks" configuration from ''IP4/General/Settings'' is used.
:;Auto: Media traffic is routed through the PBX if calls are between private and public registration addresses but not for calls between private and private or public and public registration addresses. To identify an address as private the "Private Networks" configuration from ''IP4/General/Settings'' is used. In v11 this was the behaviour if 'RTP Proxy'' was ''on''.
: Please note that when media relay is in effect for a call, '''video is not working'''. With ICE (available from v12r1), media relay in the PBX should be obsolete except for special applications. Check ''On'' or ''Auto'' only if you need to have this, since it creates CPU load on the PBX.

;Generate CDRs: If this checkbox is set, the PBX generates CDRs for all calls. See [[Reference9:Concept_Call_Detail_Record_CDR_PBX]] for a description of the CDRs.

;Route Root-Node External Calls to: Destination object (Long Name) of Root-Node external calls. This configuration option is available on the Master or Standby PBX only. Any call call which cannot be terminated inside the PBX is sent to this destination as long as neither the source nor the destination of the call can be associated with a node with a PBX configured. This object must be assigned to this PBX.
:'''For calls from local PBX only''': If set on a master, calls from a slave are not sent to this destination but sent back to the slave where the call came from. On the slave the call is then sent to a destination configured with 'Route Root-Node External Calls to'.

;Route PBX-Node External Calls to: Destination object (Long Name) of PBX-Node external calls. Any call which cannot be terminated inside the PBX is sent to this destination as long as the source nor the destination of the call can be associated with the node of this PBX. If a call is sent from or to an object defined inside the node of this PBX or in a node hierarchically below the node of this PBX the call is associated to the node of this PBX. This object must be assigned to this PBX, that is, it has to register to this PBX.

;Route Internal Calls to: Destination object (Long Name) to which any call is sent for which a PBX internal destination was found, except for those calls that originated from that object. This can be used to apply special routing on PBX internal calls.

;Escape Dialtone from: The PBX object (Long Name) to which a call is made to get a dialtone if a dialtone is configured for the escape of a node. As above, this object must be assigned to this PBX.

;Prefix for Intl/Ntl/Subscriber: Prefixes to be used to map International, National and Subscriber numbers. For example to send from the faxserver if the received mail contains the number in international format, e.g. +49123456578@faxserver.local
:* '''International Prefix''' (<code>000</code> in Germany).
:* '''National Prefix''' (<code>00</code> in Germany).
:* '''Subscriber Numbers''' (in Germany, <code>0</code> is a commonly used trunk line access code).

;Tones: The tones scheme to be used for PBX generated dialtones. This applies to dialtones generated for node prefixes, ringback on transfer and some more.

=== Slave PBX ===

If the PBX is operated in Slave mode, then the Slave PBX section is displayed

;Registration: The VOIP protocol used for the registration to the master. Possible choices are H.323, H.323/TCP or H.323/TLS.

;Master: The IP address of the PBX master

;License Only: If set, the PBX obtains license from master, but acts as master in all other respects.

;Alternate Master: The IP address of an alternative PBX master (standby, if available)

;Password: The password to be used for registration at the Master as configured in the corresponding PBX Object

;Master GK-ID: The System Name/Gatekeeper ID of the PBX Master were will register (Optional, usually used for DynPBX).

;Replication: This parameter allows you to select the replication style for the slave PBX: either ''All'' or ''Local'' (only users that need to be known in this PBX).

;dyn PBX ID: This parameter allows to set replication from a specific DynPBX configured on the Master Device.

;Use local static User DB: A dynPBX has also this checkmark. The database of the main PBX is used, but be careful due to the increased memory usage. The dynPBX will create its own PBX datastructure which allocates memory.

;Route Master calls if no Master to: If the master is not available, master calls are sent to this destination

;Max Calls to Master/No Reroute: This parameter can be used to limit the calls to the master. If a call is sent to the master and there are already calls to/from the master equal to or exceeding this value, the call is rejected if '''No Reroute''' is set or is handled as if the master was not available otherwise.

;License Limits: Here we can set limit of licensing for this Slave PBX for Port, Mobility, Operator and Softwarephone.

For complete replication from master to slave, check also password in [[Reference9:Administration/PBX/Security]]

=== Standby PBX ===

If the PBX is operated in Standby mode, then the Standby PBX section is displayed

;Master: The IP address of the PBX master

;Replicate from Master: Turns on full replication from the master PBX

;use TLS: Use LDAPS (TLS) instead of LDAP (TCP).

For complete replication from master to standby, check also password in [[Reference9:Administration/PBX/Security]]

== License Status ==

=== Licenses ===

A list of all installed PBX license with their current usage is displayed here.

;Count: The total number of installed licenses of this type.

;Usage: The total usage of this license type

;Local: The usage of this license on this PBX

;Slaves: The usage of this license on PBX's registered to this PBX.

see [[Reference10:Licenses]] for a description of the licenses.

=== Registrations ===

The current number of registrations and the limit as defined by the base license is displayed here. Because this limit is defined by the base license it includes any registrations because of standby as well, which require no registration license.