Cisco Jabber

General information

XPhone Connect Directory

The XPhone Connect Directory provides central access to all company contacts, even if they are distributed over different locations, databases, public directories or in different applications, e.g. CRM & ERP. User get quick and direct access to original data with the XPhone Connect Directory. Data replication is not necessary.

  • Searching and finding

    Of contact data of every supported database directly in the Cisco Jabber client.

  • Advanced search logic

    The option to enter advanced search terms directly in existing Jabber clients - exactly as in search engines with the option to combine or exclude (-) search terms, e.g.:

    • “company town”

    • “Mycompany –Deutschland sales”

    • “Taxi Hamburg”

    • “Cartis Bern”

    Tip

    Search queries for public directories can be performed by adding a dot at the beginning, e.g.: ” .Taxi Hamburg”.

  • Free text search - the alternative to wildcards

    Search queries do not have to contain all characters of a search term, the start of the word is sufficient (wildcards with one word are not supported). The search query An am results in Anna Amberg, the query na berg would not.

  • Access to distributed contact data

    The XPhone Connect Directory provides access to very different types of contact data, e.g. from groupware solutions, CRM systems, ERP systems or supported cloud services. Access to this wide range of contacts improves the suitability for daily use and the value of UCC clients in a work environment.

  • Integration

    XPhone Connect is integrated as pure server solution. A software or rollout to the users’ workstation computers is not necessary.

Cisco Jabber

Advanced search function with free text search in the Cisco Jabber client

Contact data form the basis for every form of company communication. It is important to be able to access contact data quickly and easily to be able to communicate with customers, partners and suppliers. This information is generally distributed in different applications or databases. In addition to real-time access to all of these contact data, the software form C4B also offers a free text search, which can be used to freely search all data sources.

  • Finding even more contacts

    With the XPhone Connect Directory, you get access to all public Microsoft Outlook as well as all company-wide applications (SAP, CRM, ERP, HR, etc.), databases (ADBC, SQL, MySQL…) or cloud services such as Das Telefonbuch Deutschland, ETV Inside (Swiss telephone book) and Google Apps for Business.

  • Improved search function

    XPhone Connect Directory expands your Jabber client with a free text search and offers many new possibilities to find contact data. All data sources in your company can be searched as required. Connection criteria allow a targeted search.

  • Advanced caller identification

    With the XPhone Connect Directory, you Jabber client uses the data from all of your business applications to identify users in incoming calls. You can see who’s calling in your client’s caller pop-up. This gives you the possibility to greet every users personally.

  • No more unknown telephone numbers

    If you do not have the time to accept a call, you Jabber client also uses the XPhone Connect Directory to identify callers in the call journal, for example using the data from your ERP, CRM or HR system. This gives you a perfect overview of all incoming calls and the option to decide which contact you want to call back.

  • Telephone numbers are always in the correct format

    XPhone Connect Directory access your original data in real-time, detects the different telephone number styles automatically and provides the data in the Jabber client so that you can make a call straight away without having to worry in which format the data are saved in the different databases.

  • Jabber and more

    The search function does not only work with Cisco Jabber clients but is also available for many different LDAP applications and devices (landline telephones, web and smartphone browsers).

Cisco IP phones

With XPhone Connect Directory, you can also use your Cisco phone to search all databases in your company (ERP, CRM, HR system and much more) or public directories such as Das Telefonbuch Deutschland or ETV Inside (Swiss phone book) and use them for communication - independent of your PC. In this way, you can enable employees without a PC workplace, e.g. in hospitals, warehouses or simply in meeting rooms, to access all contact data of their company.

  • Free text search for your Cisco telephone

    The free text search in your Cisco end device provides maximum convenience when searching for telephone numbers. You can easily find the requisite contacts without having to search in separate fields. The free text search relates automatically to the company, first name and last name fields.

  • Searching all or selected address books with the Cisco telephone

    You can decide if you want to search in all connected data sources at the same time or only in one address book. When looking for a customer contact, you can search directly in your CRM system, for example. If you simply need a pizza delivery service or taxi service, select the telephone book.

  • Database prioritisation for a perfect search result

    Company-internal contact data usually have a higher relevance for communication than public directories such as a telephone book. XPhone Connect Directory enables prioritisation of the affiliated data sources with the result that you always receive the best possible search result.

Planning and extension stages

Licensing

  • 1x XPhone Connect Server

  • XPhone Connect Contacts: per user

Supported client versions

  • Cisco Jabber Client: Version 12, 11.9, 11.8, 11.0 and 10.6.0 for Windows

  • Cisco Jabber Client: Version 11.8 and 10.6.0 for Mac

  • Cisco Jabber Client: Version 10.5.2 for iOS (iPhone & iPad)

Supported IP-Phones versions

IP-Phones with “Cisco IP Phone Services” interface supported.

  • Series 79xx

  • Series 89xx

  • Series 99xx

Hint

Further information: System requirements XPhone Connect Server

Configuration

Cisco Jabber

LDAP connection variations

Cisco distinguishes between three variants for the contact data connection, which can or must be configured independently of each other.

  1. BDI: Is the connection which, except for the Windows Jabber client, all other Jabber clients can use to access LDAP servers.

  2. EDI: Is the LDAP connection, which is only used by the Windows Jabber client.

  3. UDS: Is a non-LDAP based contact data integration. This is not supported by us.

Contact properties

The Jabber client responds to some properties of the found contacts in particular. In the following the EDI property is mentioned first and in brackets the BDI property.

UserAccountName (BDIUserAccountName)

In this property, the Jabber client expects the CUCM login name (without the presence domain).

Caution

  • This must not contain spaces or the characters *()/\%ß²³'.

  • Together with the presence domain, it must not exceed the length of about 450 characters.

  • The client uses this field as an index to the contact.

  • Consequently, the content must be unique (case-insensitive) and searchable across all contacts.

By default, the Jabber client expects the content of this field in the LDAP attribute sAMAccountName. Therefore the Jabber client interface offers exactly this field in the configuration. Since the Jabber client looks for this field, it must be associated in the directory with a directory attribute that is indexed. Since the Jabber client uses this field as an index field, the Jabber client interface automatically generates a unique value if a data source does not provide its own value. The sAMAccountName attribute of the Jabber client interface is mapped to the directory field Other 5.

The contact card of the Jabber client displays this field as a chat address. Thereby the presence domain is appended to the content.

The Jabber client does not use this field if the UseSIPURIToResolveContacts configuration setting (BDIUseSIPURIToResolveContacts) is set to true. In this case SipUri will be used. However, the default is false.

SipUri (BDISipUri)

The Jabber client uses this field only if the UseSIPURIToResolveContacts configuration setting (BDIUseSIPURIToResolveContacts) is set to true. If this option is set to false (default), UserAccountName will be used.

Hint

The field is used by the Jabber client as an index to the contact. It must therefore be unique across all contacts (case-insensitive). It must not contain spaces or the characters *()/\%ß²³' and must not be longer than about 450 characters. Furthermore, it must have a valid IM address format, i.e. something@domain.

If this field is to be used, the Jabber client must be configured to look for the LDAP attribute “chat”. This attribute is provided by the Jabber client interface. The client interface ensures that if a data source in it does not provide a value, it is assigned a unique value. Since the Jabber client looks for this field, it must be associated with an indexed attribute in the directory. The “chat” attribute of the Jabber client interface is mapped to the directory field “XMPP address”.

The contact card of the Jabber client shows this field as the chat address.

To use this field, these values must be set in jabber-client.xml:

<SipUri>chat</SipUri>
<UseSipUriToResolveContacts>true</UseSipUriToResolveContacts>
<BDISipUri>chat</BDISipUri>
<BDIUseSipUriToResolveContacts>true</BDIUseSipUriToResolveContacts>

Only with this setting it is possible that in the detail view of contacts from the directory chat addresses from foreign domains can be displayed. For such contacts to be added to the contact list of the Jabber client, Federation must be enabled on the Cisco servers.

DirectoryUri (BDIDirectoryUri)

The content of this field is used by the Jabber client for dialing by URI. The Jabber client normally expects the content in the LDAP mail attibute.

To make it easier to separate the contents of email addresses, the Jabber client interface provides the ipPhone attribute. The ipPhone attribute of the Jabber client interface is mapped to the SIP address directory field. To use this, these values must be set in the jabber-client.xml:

<DirectoryUri>ipPhone</DirectoryUri>
<BDIDirectoryUri>ipPhone</DirectoryUri>

In the contact card, the content of this field appears as an additional office phone number.

Only values that are in a valid (e-mail) format are displayed. In particular, no spaces may be included.

EmailAddress (BDIEmailAddress)

The Jabber client expects the content of this field in the LDAP attribute mail. Only values that are in a valid (email) format are displayed. In particular, no spaces may be included.

In the implementation of the client there is a contact cache which contains all contacts already found during the runtime of the client. Before search hits are displayed on the interface, they are compared with the contacts in the cache. If the cache thinks that a contact just found is already in the cache, the contact from the cache is displayed instead of the search hit. Of course, we do not know the exact algorithm used to compare contacts. However, tests have shown that a contact is considered “identical” as soon as the email addresses match. Empty e-mail addresses are not taken into account.

Hint

Consequently, it is imperative that the e-mail addresses of all contacts must be different. If this is not the case, search queries that return hits with non-empty and non-unique email addresses may show untraceable contacts as hits.

Since it can happen, especially with external address sources, that non-unique e-mail addresses are provided for contacts (e.g. info@c4b.de), you can configure the Jabber client interface via atlas.xml so that certain e-mail addresses are not delivered:

<jabber>
    <ExcludedEmailPrefix>info@</ExcludedEmailPrefix>
    <ExcludedEmailPrefix>contact@</ExcludedEmailPrefix>
</jabber>

By this setting the Jabber client interface suppresses all email addresses starting with info@ and contact@.

PhotoSource (BDIPhotoSource)

The Jabber client expects information about the contact image in this property. The client supports that the image is delivered directly in the LDAP attribute but also that the LDAP attribute contains a web link to the image.

The Jabber client interface only provides images directly in the LDAP attribute. It provides the image in the thumbnailPhoto and jpegPhoto attributes. In the former, the Jabber client expects it by default.

Whether the Jabber client expects the image directly is controlled by the PhotoUriSubstitutionEnabled configuration setting (BDIPhotoUriSubstitutionEnabled). By default it is set to false, which causes the client to expect the image directly in the property.

Therefore, even if it is not necessary, the jabber-config.xml should contain this:

<PhotoUriSubstitutionEnabled>false</PhotoUriSubstitutionEnabled>
<BDIPhotoUriSubstitutionEnabled>false</BDIPhotoUriSubstitutionEnabled>

The Jabber client stores the images in the directory C:\Users\<account>\AppData\Local\Cisco\Unified Communications\Jabber\CSF\Contacts. The filename is composed of the Uri of the contact and a short extension. file, all characters in the filename that are not contained in the set {a-z;0-9} are replaced by three characters long encoding. If the length of the entire path to an image file exceeds 256, no images are displayed.

Settings

To configure the LDAP connection of the Jabber client, some important configuration settings have to be made. In the following the EDI setting is always mentioned first and in brackets the BDI setting:

  • DirectoryServerType

    This setting must not be set to the value “UDS”. It is not necessary to explicitly specify EDI or BDI. So it is best if the setting is not present.

  • PrimaryServerName (BDIPrimaryServerName)

    This setting specifies the IP address or host name of the Jabber client interface:

    <PrimaryServerName>192.168.33.162</PrimaryServerName>
    
  • ServerPort1 (BIDServerPort1)

    The port on which the Jabber client interface can be reached is specified here:

    <ServerPort1>3891</ServerPort1>
    
  • BDILDAPServerType

    This must be configured to “AD”:

    <BDILDAPServerType>AD</BDILDAPServerType>
    

    There is no corresponding setting for EDI.

  • UseWindowsCredentials

    Must be configured to 0:

    <UseWindowsCredentials>0</UseWindowsCredentials>
    

    There is no corresponding setting for BDI

  • BDIUseJabberCredentials

    Must be configured to false:

    <BDIUseJabberCredentials>false</BDIUseJabberCredentials>
    

    There is no corresponding setting for EDI.

  • UseSSL (BDIEnableTLS)

    Controls whether the client connects to the Jabber client interface via TLS/SSL. This must match the configuration of the Jabber client interface. The certificate specified on the Jabber client interface must be trusted on the client:

    <UseSSL>0</UseSSL>
    <BDIEnableTLS>false</BDIEnableTLS>
    
  • UseSecureConnection

    Must be configured to 0:

    <UseSecureConnection>0</UseSecureConnection>
    

    For BDI, the setting does not exist.

  • ConnectionUsername, ConnectionPassword (BDIConnectionUsername, BDIConnectionPassword)

    These configuration values can be used to store login data. If nothing is specified, the client attempts to establish an anonymous connection to the client interface.

  • SearchBase1 (BDISearchBase1)

    Must be set to vdir=VDir:

    <SearchBase1>vdir=VDir</SearchBase1>
    <BDISearchBase1>vdir=VDir</BDISearchBase1>
    
  • BaseFilter (BDIBaseFilter)

    Must be set to “(&amp;(objectCategory=Person)”:

    <BaseFilter>(&amp;(objectCategory=Person)</BaseFilter>
    <BDIBaseFilter>(&amp;(objectCategory=Person)</BDIBaseFilter>
    
  • PredictiveSearchFilter

    Must be set to anr:

    <PredictiveSearchFilter>anr</PredictiveSearchFilter>
    

    For BDI, the setting does not exist.

  • UseWildcards

    Must be set to 0:

    <UseWildcards>0</UseWildcards>
    

    For BDI, the setting does not exist.

  • DisableSecondaryNumberLookups

    Must be set to 1. The Jabber client interface always searches in all phone numbers of a contact:

    <DisableSecondaryNumberLookups>1</DisableSecondaryNumberLookups>
    

    For BDI, the setting does not exist.

  • PhoneNumberMasks

    If dialing parameters are specified in the directory for both the data sources and the Jabber client interface, the configuration of PhoneNumberMasks is not necessary. This setting does not exist for BDI.

  • BDIUseANR

    Must be set to true:

    <BDIUseANR>true</BDIUseANR>
    

    This setting does not exist for EDI

  • UseSipUriToResolveContacts (BDIUseSipUriToResolveContacts)

    If this value is set to false, the chat address results from the content of UserAccountName (BDIUserAccountName) and the attached presence domain. If this value is set to true, the chat address results from the content of SipUri (BDISipUri).

  • PhotoUriSubstitutionEnabled (BDIPhotoUriSubstitutionEnabled)

    Must be set to false:

    <PhotoUriSubstitutionEnabled>false</PhotoUriSubstitutionEnabled>
    <BDIPhotoUriSubstitutionEnabled>false</BDIPhotoUriSubstitutionEnabled>
    

Client-Interface Mappings

The table shows the main Jabber client interface attributes and which directory fields they are associated with.

Jabber Client-Interface

Directory

sAMAccountName

Other 5

jid

Other 5

chat

XMPP address

ipPhone

SIP address

jpegPhoto

Picture

thumbnailPhoto

Picture

Directory connection

The most important decision to make is whether to set UseSipUriToResolveContacts (BDIUseSipUriToResolveContacts) to true. This determines how Jabber clients retrieve a contact, e.g. to display it in the contact view or to update it in the contact list after restart. If you change this afterwards, contacts previously added to the contact list will only appear with their chat address. The setting can only be set to true using jabber-config.xml.

If UseSipUriToResolveContacts is false, the Jabber client does not request chat addresses from the directory but only Cisco login names. The chat address of all contacts is then formed from the login name and the own presence domain. For external contacts the directory therefore invents login names and if in the data source possibly even an external chat address would be available. Federation with a contact is not possible this way. If you want to work with UseSipUriToResolveContacts false you don’t need an entry in jabber-config.xml. Also there should be no entry for SipUri (BDISipUri).

If UseSipUriToResolveContacts is true, the Jabber client works with the chat addresses of the contacts. Each contact must then have a unique and syntactically correct chat address. If this is not available in a data source, the directory invents one. For contacts from other presence domains (external contacts) to be stored in the contact list, Federation must be enabled on the Cisco servers. If this is not the case, there will be a cryptic error message when trying to save the contact. If you want to set UseSipUriToResolveContacts to true you have to set SipUri (BDISipUri) to chat in the jabber-config.xml.

If you want to avoid that the email address of a contact also always appears as an additional office phone number, you have to set the DirectoryUri (BDIDirectoryUri) setting in the jabber-config.xml to ipPhone.

Connection of the Active Directory

A few changes to the data source mapping are required to connect Active Directory to the directory to support searching in Jabber clients.

The following mapping recommendations assume that nothing has been changed in the mapping of the Jabber client interface.

  1. The AD attribute sAMAccountName must be mapped to the directory field Other 5. The Jabber clients expect the Cisco login name here.

  2. An AD attribute should be mapped to the directory field SIP address, the content of which corresponds to the URL via which the user can be reached by URL dialing, the content of which is displayed as an additional office phone number in the Jabber client. Often this corresponds to the user’s email. In this case, the AD attribute mail should then be mapped to SIP address. Otherwise, you may have to compose the correct URL from the AD attribute sAMAccountName and a chaining of the content in the mapping with a static text.

  3. An AD attribute should be mapped to the directory field XMPP Address, whose content corresponds to the chat address of the Cisco user. If the IM address scheme in the Cisco server is set to Domain URL, this is exactly the field that was also selected in the Cisco IM address scheme dialog. If the IM address scheme in the Cisco configuration was set to account@domain, there may not be an attribute in AD that contains the chat address of the users. In this case you have to associate XMPP address with the AD attribute sAMAccountName and add the presence domain via chaining in the mapping as static text.

  4. In the Active Directory, contact images are stored in either the jpegPhoto attribute or the thumbnailPhoto attribute. The directory expects the image in the jpegPhote field. Consequently, the mapping of the data source must be adjusted accordingly.

In most cases, the following changes in the Active Directory data source mapping should achieve the goal:

Active Directory attributes

Directory field

sAMAccountName

Other 5

mail

XMPP address

mail

SIP address

thumbnailPhoto

Picture

Connection of other data sources

To work correctly, the Jabber clients expect a value in the directory fields Other 5 and XMPP Address that is unique across all contacts and is also subject to some restrictions. The values must not contain spaces or the characters *()/\%ß²³' and must be shorter than about 450 characters. XMPP address must also conform to the domain syntax (name@domain).

If the Jabber client interface does not receive a value from the data sources in these fields, it generates a suitable one itself. Due to the length limitation of image file names, images can only be displayed if the value of the directory field entryID and the unique identifier of the data source are shorter than about 80 characters together. The above mentioned limit of about 450 characters is reached for automatically generated values if entryID and the Unique Identifier of the data source are about 300 characters long. If the value generated by the Jabber Client Interface would become longer than 450 characters, too_long@nrp.com is supplied. A contact marked this way will not show an image and cannot be added to the contact list.

If these restrictions do not interfere, it is not necessary to create a mapping to the directory fields Other 5, XMPP address and SIP address. The fields can remain unlinked. Otherwise you have to try to get values that match the above criteria by clever mapping of the data source fields.

If Federation is enabled on the Cisco server and the data source contains chat addresses, the Directory field XMPP Address should be mapped to the chat address.

If the data source contains a field whose content is selectable by the Jabber clients via URL, this field should be linked to the directory field SIP address.

Cisco Unified CM Administration

Directory binding to Jabber clients can be done either via service profiles or via jabber-config.xml.

Pro UC-Services und Service-Profile

To connect the directory via service profiles, two UC services must first be created.

UC Service for BDI:

cisco1

UC Service for EDI:

cisco2

The settings should be adopted exactly as they are. Only the correct IP address/name and port of the Jabber client interfaces must be entered.

In the Service Profile, which is mapped to the users, the Directory Profile section must be configured:

cisco3

Here, too, the settings should be adopted exactly as they are.

Now assign the service profile to the user:

cisco4

Depending on the desired operating mode (federation or not), settings must still be made in jabber-config.xml:

cisco5

In the Directory node, there need never be more than these six settings at most, and these only if the corresponding behavior is explicitly desired.

Exclusively via jabber-config.xml

If no settings are desired in the Directory Profile section of a user’s service profile, the complete configuration can also be contained in jabber-config.xml.

Important

It is important to know that settings coming from Service Profiles take precedence over settings in jabber-config.xml.

In the example the comprehensive configuration via jabber-config.xml:

cisco6

It is enough to use the name/IP address and port of the Jabber client interface.

Troubleshooting

Images are not displayed

First check if the mapping of the data source points to the data source field which really contains the image. If the image is in the attribute thumbnailPhoto in the Active Directory, the mapping in the data source must be changed from jpegPhoto to thumbnailPhoto.

The Jabber client stores the images in the directory between:

C:\Users\<account>\AppData\Local\Cisco\Unified Communications\Jabber\CSF\Contacts

The file name is composed of the Uri of the contact and a short extension. file, all characters in the file name that are not contained in the set {a-z;0-9} are replaced by a three-character encoding. If the length of the whole path to an image file exceeds 255, no images are displayed. For control you can open the file DirectoryRSCache in the directory:

C:\Users\<account>\AppData\Local\Cisco\Unified Communications\Jabber\CSF\Contacts

cisco10

The 1 at Photo Blob indicates whether an image was supplied by the directrory for the contact or not. The second marker shows exactly the value, which must not be too long and must contain only valid characters.

If the contact is not Photo Blob but Photo Uri, the client expects the image to be downloaded in a URL. In this jabber-config.xml the option PhotoUriSubstitutionEnabled (BDIPhotoUriSubstitutionEnabled) is set to true.

From the second marking results the file name of the photo files. After encoding it results in this file name:

ActiveDirectory%3Anrp1%2D121ckl6mvu0w9c%3A2k%40nrp%2Ecom_small32.png
Contact cannot be added to the contact list

Contacts can be added to the contact list only if they have a correctly formatted chat address.

Contacts with a chat address from external domains can be included in the contact list only if Federation has been enabled on the Cisco servers.

After restarting, the client for the contacts in the contact list shows only the chat address

This happens when the client could no longer find the contacts in the directory. This is the case when

  • The Jabber client interface is disabled.

  • The contact’s chat address contains invalid characters, is too long, or does not match the domain syntax.

  • The UseSipUriToResolveContacts setting in jabber-config.xml has been changed.

  • In the mapping of the data source the assignment for Other 5 or XMPP address was changed.

There is an error when trying to delete a contact from the contact list

If the chat address of a contact exceeds a length of about 450 characters, it is possible to add the contact to the contact list, but it is not possible to delete it or move it to another group.

Inexplicable hits appear during a search

The Jabber client interface always performs a full text search over all properties of the contacts in the directory. Therefore, it is also possible that a search term was found in a property that is not displayed in the Jabber client.

The Jabber clients keep an internal cache of the hits that have already been found. This cache is internally sorted by e-mail addresses, among other things. If the contacts from the directory do not have unique e-mail addresses, completely unexplained hits may occur.

The Jabber client ignores new configuration settings

The Jabber client often fetches new configuration settings only when you log in again or when you restart the client. So after configuration changes you should always restart the client.

In addition, the Jabber client saves some settings locally. For example, images or contacts that have already been found. To ensure that contacts are actually fetched from the directory when configuration changes are made, it is recommended to delete this local cache. In the logged off state the client offers this option:

cisco11

After modifying the jabber-config.xml it can happen that it gets an invalid content. To check if the Jabber client really gets the values in the jabber-config.xml you can check them in the file cachedTFTPConfigStore.xml in the directory:

C:\Users\<account>\AppData\Roaming\Cisco\Unified Communications\Jabber\CSF\Config\Cache

In the cachedUcm90ConfigStore.xml in the directory above, the client stores the setting it got from the Service Profile.

Cisco IP Phone

XPhone Connect Directory configuration

Hint

Please configure the XPhone Connect Directory according to this guide.

Unified Communications Manager configuration

Create phone service

On the CUCM go to the administration interface and follow these steps:

  1. Go to Device > Device Settings > Phone Services.

  2. Click on Add New.

  3. Define a service name (e.g. XPhone Connect Directory).

  4. Enter the service URL. The service URL is displayed in the Client Interface configuration in the XPhone Connect Directory (in the last step).

    The URL looks like this:

    http://DIRECTORY-SERVER-OR-IP:389/vdirsearch.do
    
  5. As Service Category select XML-Service and as Service Type select Default-IP-Phone service.

  6. Activate the Enable checkbox.

  7. If you want the configuration to be set on all phones, check the Enterprise Subscription checkbox. If you do not want to do this, perform the configuration as described below.

  8. Clieck Save and Update Subscriptions.

Configuration of selected devices

If only selected devices are to have access to the XPhone Connect Directory, proceed as follows:

  1. Go to Device > Phone.

  2. Open the configuration of the corresponding device.

  3. Under Related Links go to Subscribe/Unsubscribe Services (right corner).

  4. As Service, select the Phone Service you created earlier. You will see: Create phone service.

  5. Click Next.

  6. Click Subscribe.

Hint

Due to technical limitations, access to personal contact data is not possible (no user authentication by end devices).

Knows limitations

  • Cisco Jabber for iPhone and iPad, with version 9.6.2 includes search functionality with XPhone Connect Directory, but contact images cannot be displayed.

  • Access to contacts of the personal folder (e.g. with Outlook) from Cisco IP Phones or Jabber Clients, in connection with XPhone Connect Directory, is not supported.

  • The Cisco Jabber Client for Mac, with version 10.5.1, supports the XPhone Connect Directory Integration. However, contact images and detailed information of logged in users are not displayed.

Have you found an mistake on this page?

Please send us a hint about this error by mail to doku@c4b.de. Thank you very much!