Cisco Jabber

Allgemeine Informationen

XPhone Connect Directory

Mit XPhone Connect Directory haben Sie zentralen Zugriff auf alle Firmenkontakte, auch wenn sie über verschiedene Standorte, Datenbanken, öffentliche Verzeichnisse oder in unterschiedlichen Anwendungen z. B. CRM & ERP verteilt sind. Mit XPhone Connect Directory haben die Benutzer direkten und schnellen Zugriff auf die Original-Daten. Eine Daten-Replikation ist nicht notwendig.

  • Suchen und finden

    Kontaktdaten jeder unterstützer Datenbank, direkt im Cisco Jabber Client.

  • Erweiterte Such-Logik

    Die Möglichkeit, erweiterte Suchbegriffe direkt in bestehende Jabber Clients einzugeben - genau wie bei Suchmaschinen mit der Möglichkeit Suchbegriffe zu kombinieren oder auszuschließen (-), z.B.:

    • „company town“

    • „Mycompany –Deutschland sales“

    • „Taxi Hamburg“

    • „Cartis Bern“

    Tipp

    Suchanfragen, für öffentliche Verzeichnisse, können durch das Voransetzen eines Punktes durchgeführt werden, z. B.: “ .Taxi Hamburg“.

  • Freitextsuche - die Alternative zu Wildcards

    Suchanfragen müssen nicht alle Zeichen eines Suchwortes enthalten, die Anfangszeichen sind ausreichend (Wildcards mit einem Wort werden nicht unterstützt). Die Suchanfrage An am ergibt Anna Amberg als Suchergebnis, die Anfrage na berg würde es nicht.

  • Zugriff auf verteilte Kontaktdaten

    Das XPhone Connect Dirextory ermöglicht den Zugriff auf unterschiedlichste Arten von Kontaktdaten, wie z. B. aus Groupware-Lösungen, CRM-Systemen, ERP-Systemen oder unterstützte Cloud Dienste. Der Zugriff auf diese breite Palette von Kontakten, verbessert die Alltagstauglichkeit und den Wert der UCC-Clients in der Arbeitswelt.

  • Integration

    XPhone Connect wird als reine Server-Lösung integriert. Es wird dafür keine Software oder Roll-Out auf den Arbeitsplatzrechnern der Benutzer benötigt.

Cisco Jabber

Erweiterte Suchfunktion mit Freitextsuche im Cisco Jabber Client

Kontaktdaten bilden die Grundlage für jede Form der Unternehmenskommunikation. Um mit Kunden, Partnern und Lieferanten kommunizieren zu können ist es wichtig, schnell und einfach auf die Kontaktdaten zugreifen zu können. Diese Informationen sind typischerweise auf unterschiedliche Anwendungen bzw. Datenbanken verteilt. Neben dem Echtzeit-Zugriff auf all diese Kontaktdaten bietet die Software von C4B außerdem eine Freitextsuche, mit der sich alle Datenquellen frei durchsuchen lassen.

  • Noch mehr Kontakte finden

    Mit XPhone Connect Directory haben Sie Zugriff auf alle öffentlichen Microsoft Outlook sowie auf alle firmenweiten Anwendungen (SAP, CRM, ERP, HR etc.), Datenbanken (ODBC, SQL, MySQL…) oder Cloud-Dienste wie beispielsweise Das Telefonbuch Deutschland, ETV Inside (Telefonbuchdienst für die Schweiz) und Google Apps for Business.

  • Verbesserte Suchfunktionen

    XPhone Connect Directory erweitert Ihren Jabber Client um eine Freitextsuche und bietet Ihnen viele neue Möglichkeiten Kontaktdaten zu finden. Alle Datenquellen Ihres Unternehmens lassen sich beliebig durchsuchen. Ausschlusskriterien ermöglichen eine gezielte Suche.

  • Erweiterte Anrufer-Identifizierung

    Mit XPhone Connect Directory nutzt Ihr Jabber Client die Daten aus allen Ihren Geschäftsanwendungen, um Anrufer bei eingehenden Telefonaten zu erkennen. Im Anrufer-Popup Ihres Clients sehen Sie sofort wer anruft. Das bietet Ihnen die Möglichkeit, jeden Anrufer persönlich zu begrüßen.

  • Nie wieder unbekannte Rufnummern

    Sollten Sie einmal nicht die Möglichkeit haben, einen Anruf entgegenzunehmen, nutzt Ihr Jabber Client XPhone Connect Directory auch für die Anrufer Erkennung im Anrufjournal beispielsweise anhand der Daten aus ihrem ERP-, CRM- oder HR-System. Das bietet Ihnen einen perfekten Überblick über alle entgangenen Anrufe und die Möglichkeit entscheiden zu können, welchen Kontakt Sie zuerst zurückrufen.

  • Rufnummern immer im richtigen Format

    XPhone Connect Directory greift in Echtzeit auf Ihre originalen Daten zu, erkennt dabei automatisch die unterschiedlichsten Rufnummern-Schreibweisen und stellt die Daten im Jabber Client so zur Verfügung, dass Sie gleich telefonieren können und sich keine Gedanken machen müssen, in welchem Format die Daten in den verschiedensten Datenbanken gespeichert sind.

  • Jabber und mehr

    Die Suchfunktion ist nicht nur an Cisco Jabber Clients gebunden, sondern sie steht auch verschiedensten LDAP Applikationen und Geräten (Festnetztelefone, Web- und Smartphone-Browsern) zu Verfügung.

Cisco IP Phones

Mit XPhone Connect Directory können Sie auch mit Ihrem Cisco Telefon, unabhängig vom PC, alle Datenbanken Ihres Unternehmens (ERP-, CRM-, HR-System u.v.m.) oder öffentliche Verzeichnisse, wie Das Telefonbuch Deutschland oder ETV Inside (Schweizer Telefonbuch), durchsuchen und für die Kommunikation nutzen. So ermöglichen Sie auch Mitarbeitern, die keinen PC-Arbeitsplatz haben z. B. in Krankenhäusern, im Lager oder einfach nur in Besprechungsräumen, den Zugriff auf alle Kontaktdaten Ihres Unternehmens.

  • Freitextsuche für Ihr Cisco Telefon

    Die Freitextsuche an Ihrem Cisco Endgerät bietet Ihnen maximalen Komfort bei der Suche nach Telefonnummern. Sie finden die gewünschten Kontakte ganz einfach, ohne hierfür in separaten Feldern suchen zu müssen. Die Freitextsuche bezieht sich automatisch auf die Felder Firma, Vor- und Nachname.

  • Mit dem Cisco Telefon in allen oder in ausgewählten Adressbüchern suchen

    Sie entscheiden, ob Sie gleichzeitig in allen angeschlossenen Datenquellen suchen oder sich direkt für ein Adressbuch entscheiden. Wenn Sie einen Kontakt Ihres Kunden suchen, dann können Sie beispielsweise direkt in Ihrem CRM-System suchen. Wenn Sie einfach nur einen Pizzalieferanten oder einen Taxi Service benötigen, wählen Sie das Telefonbuch aus.

  • Datenbank Priorisierung für ein perfektes Suchergebnis

    Firmeneigene Kontaktdaten haben in der Regel eine höhere Relevanz für die Kommunikation als öffentliche Verzeichnisse, wie beispielsweise ein Telefonbuch. Mit XPhone Connect Directory lassen sich die angeschlossenen Datenquellen priorisieren, so dass Sie immer das bestmögliche Suchergebnis haben.

Planung und Ausbaustufen

Lizenzierung

  • 1x XPhone Connect Server

  • XPhone Connect Contact: je Benutzer

Unterstützte Client Versionen

  • Cisco Jabber Client: Version 12, 11.9, 11.8, 11.0 und 10.6.0 für Windows

  • Cisco Jabber Client: Version 11.8 und 10.6.0 für Mac

  • Cisco Jabber Client: Version 10.5.2 für iOS (iPhone & iPad)

Unterstützte IP-Phones Versionen

IP-Phones mit der „Cisco IP Phone Services“-Schnittstelle werden unterstützt.

  • Serie 79xx

  • Serie 89xx

  • Serie 99xx

Hinweis

Weiterführende Informationen: Systemvoraussetzungen XPhone Connect Server

Konfiguration

Cisco Jabber

LDAP-Anbindunsvariationen

Cisco unterscheidet bei der Kontaktdatenanbindung zwischen drei Varianten, die unabhängig voneinander Konfiguriert werden können bzw. müssen.

  1. BDI: Ist die Anbindung, welche, bis auf den Windows-Jabber-Client, alle anderen Jabber-Clients verwenden können, um auf LDAP-Server zugreifen zu können.

  2. EDI: Ist die LDAP-Anbindung, welche nur vom Windows-Jabber-Client verwendet wird.

  3. UDS: Ist eine nicht auf LDAP basierende Kontaktdatenintegration. Diese wird von uns nicht unterstützt.

Kontakteigenschaften

Der Jabber Client reagiert auf einige Eigenschaften der gefundenen Kontakte besonders. Im folgendem wird die EDI-Eigenschaft an erster Stelle genannt und in Klammern die BDI-Eigenschaft.

UserAccountName (BDIUserAccountName)

In dieser Eigenschaft erwartet der Jabber-Client den CUCM-Anmeldenamen (ohne die Präsenzdomäne).

Vorsicht

  • Dieser darf weder Leerzeichen noch die Zeichen *()/\%ß²³´ enthalten.

  • Zusammen mit der Präsenzdomäne darf er die Länge von etwa 450 Zeichen nicht überschreiten.

  • Dem Client dient dieses Feld als Index zum Kontakt.

  • Demzufolge muss der Inhalt über alle Kontakte eindeutig (ohne Beachtung der Groß/Kleinschreibung) und suchbar sein.

Per Default erwartet der Jabber-Client den Inhalt dieses Feldes im LDAP-Attribut sAMAccountName. Daher bietet das Jabber-Client-Interface genau dieses Feld in der Konfiguration an. Da der Jabber-Client nach diesem Feld sucht, muss es im Directory mit einem Directory-Attribut verbunden werden, welches indiziert ist. Da der Jabber-Client dieses Feld als Index-Feld verwendet, erzeugt das Jabber-Client-Interface automatisch einen eindeutigen Wert, wenn eine Datenquelle keinen eigenen Wert liefert. Das Attribut sAMAccountName des Jabber-Client Interfaces ist auf das Directory-Feld Sonstiges 5 gemappt.

Die Kontaktkarte des Jabber-Clients zeigt dieses Feld als Chat-Adresse an. Dabei wird dem Inhalt die Präsenzdomäne angehängt.

Der Jabber-Client verwendet dieses Feld nicht, wenn die Konfigurationseinstellung UseSIPURIToResolveContacts (BDIUseSIPURIToResolveContacts) auf true gesetzt wird. In diesem Fall wird SipUri verwendet. Default ist jedoch false.

SipUri (BDISipUri)

Der Jabber-Client verwendet dieses Feld nur, wenn die Konfigurationseinstellung UseSIPURIToResolveContacts (BDIUseSIPURIToResolveContacts) auf true gesetzt wird. Steht diese Option auf false (default), so wird UserAccountName verwendet.

Hinweis

Das Feld dient dem Jabber-Client als Index zum Kontakt. Es muss daher über alle Kontakte eindeutig sein (ohne Beachtung der Groß/Kleinschreibung). Es darf weder Leerzeichen noch die Zeichen *()/\%ß²³´ enthalten und nicht länger als etwa 450 Zeichen sein. Zudem muss es ein gültiges IM-Adressformat aufweisen, also irgendetwas@domäne.

Wenn dieses Feld verwendet werden soll, muss der Jabber-Client so konfiguriert werden, dass er nach dem LDAP-Attribut „chat“ sucht. Dieses Attribut wird vom Jabber-Client-Interface angeboten. Das Client Interface sorgt dafür, dass, wenn eine Datenquelle darin keinen Wert liefert, mit einem eindeutigen Wert belegt wird. Da der Jabber-Client nach diesem Feld sucht, muss es im Directory mit einem indizierten Attribut verbunden sein. Das Attribut „chat“ des Jabber-Client Interfaces ist auf das Directory-Feld „XMPP Adresse“ gemappt.

Die Kontaktkarte des Jabber-Clients zeigt dieses Feld als Chat-Adresse an.

Zur Verwendung dieses Feldes müssen im jabber-client.xml diese Werte gesetzt werden:

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

Nur mit dieser Einstellung ist es möglich, dass in der Detailansicht von Kontakten aus dem Directory chat-Adressen aus fremden Domänen angezeigt werden können. Damit solche Kontakte der Kontaktliste des Jabber-Clients hinzugefügt werden können, muss auf den Cisco-Servern Federation aktiviert sein.

DirectoryUri (BDIDirectoryUri)

Der Inhalt dieses Feldes wird vom Jabber-Client zum Wählen per URI verwendet. Der Jabber-Client erwartet den Inhalt normalerweise im LDAP-Attibut mail.

Um einfacher den Inhalt von E-Mail-Adressen trennen zu können, bietet das Jabber-Client Interface das Attribut ipPhone an. Das Attribut ipPhone des Jabber-Client Interfaces ist auf das Directory-Feld SIP Adresse gemappt. Um dieses zu verwenden müssen in der jabber-client.xml diese Werte gesetzt werden:

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

In der Kontaktkarte erscheint der Inhalt dieses Feldes als zusätzlich Büro-Rufnummer.

Angezeigt werden nur Werte, die in einem gültigen (E-Mail-)Format vorliegen. Insbesondere dürfen keine Leerzeichen enthalten sein.

EmailAddress (BDIEmailAddress)

Der Jabber-Client erwartet den Inhalt dieses Feldes im LDAP-Attribut mail. Angezeigt werden nur Werte, die in einem gültigen (E-Mail-)Format vorliegen. Insbesondere dürfen keine Leerzeichen enthalten sein.

In der Implementierung des Clients gibt es einen Kontakt-Cache, der während der Laufzeit des Clients alle schon mal gefundenen Kontakte enthält. Bevor Suchtreffer an der Oberfläche angezeigt werden, werden diese mit den Kontakten im Cache verglichen. Ist der Cache der Meinung ein soeben gefundener Kontakt sei schon im Cache, wird anstelle des Suchtreffers, der Kontakt aus dem Cache angezeigt. Der genaue Algorithmus, mit dem Kontakte verglichen werden, ist uns natürlich nicht bekannt. Aus Tests ergab sich jedoch, dass ein Kontakt als „identisch“ gilt sobald die E-Mail-Adressen übereinstimmen. Dabei bleiben leere E-Mail-Adressen unberücksichtigt.

Hinweis

Infolge ist es also zwingend notwendig, dass sich die E-Mail-Adressen aller Kontakte unterscheiden müssen. Ist dies nicht der Fall, so kann es passieren, dass Suchanfragen, die Treffer mit nicht leeren und nicht eindeutigen E-Mail-Adressen nicht nachvollziehbare Kontakte als Treffer anzeigen.

Da es insbesondere bei externen Adressquellen vorkommen kann, dass bei Kontakten nicht eindeutige E-Mail-Adressen angegeben werden (z.B. info@c4b.de) kann man per atlas.xml das Jabber-Client-Interface so konfigurieren, dass bestimmte E-Mail-Adressen nicht geliefert werden:

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

Durch diese Einstellung unterdrückt das Jabber-Client Interface alle E-Mail-Adressen, die mit info@ und contact@ beginnen.

PhotoSource (BDIPhotoSource)

Der Jabber-Client erwartet in dieser Eigenschaft Informationen über das Kontaktbild. Der Client unterstützt hierbei, dass das Bild direkt im LDAP-Attribut geliefert wird aber auch, dass das LDAP-Attribut einen Web-Link auf das Bild enthält.

Das Jabber-Client Interface liefert Bilder ausschließlich direkt im LDAP-Attribut. Es stellt das Bild in den Attributen thumbnailPhoto und jpegPhoto zur Verfügung. Im ersteren erwartet es der Jabber-Client standermäßig.

Ob der Jabber-Client das Bild direkt erwartet, wird von der Konfigurationseinstellung PhotoUriSubstitutionEnabled (BDIPhotoUriSubstitutionEnabled) geregelt. Im Default steht es auf false, was den Client veranlasst in der Eigenschaft direkt das Bild zu erwarten.

Auch wenn es nicht notwendig ist, sollte daher im jabber-config.xml dieses stehen:

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

Der Jabber-Client speichert die Bilder im Verzeichnis C:\Users\<account>\AppData\Local\Cisco\Unified Communications\Jabber\CSF\Contacts zwischen. Der Dateiname setzt sich dabei aus der Uri des Kontakts und einer kurzen Erweiterung zusammen. Datei werden alle Zeichen im Dateinamen, die nicht in der Menge {a-z;0-9} enthalten sind, durch drei Zeichen lange Kodierung ersetzt. Überschreitet die Länge des gesamten Pfades auf eine Bilddatei die Länge 256, so werden keine Bilder angezeigt.

Einstellungen

Zur Konfiguration der LDAP-Anbindung des Jabber-Clients sind einige wichtige Konfigurationseinstellungen vorzunehmen. Im Folgenden ist immer zuerst die EDI-Einstellung genannt und in Klammern die BDI-Einstellung:

  • DirectoryServerType

    Diese Einstellung darf nicht auf dem Wert „UDS“ stehen. Es ist nicht notwendig explizit EDI oder BDI anzugeben. Am besten ist es also, wenn die Einstellung nicht vorhanden ist.

  • PrimaryServerName (BDIPrimaryServerName)

    Diese Einstellung gibt die IP-Adresse oder den Rechnernamen des Jabber-Client Interfaces an:

    <PrimaryServerName>192.168.33.162</PrimaryServerName>

  • ServerPort1 (BIDServerPort1)

    Hier wird der Port angegeben an dem das Jabber-Cient Interface zu erreichen ist:

    <ServerPort1>3891</ServerPort1>

  • BDILDAPServerType

    Dies muss auf „AD“ konfiguriert sein:

    <BDILDAPServerType>AD</BDILDAPServerType>

    Für EDI gibt es keine entsprechende Einstellung.

  • UseWindowsCredentials

    Muss auf 0 konfiguriert sein:

    <UseWindowsCredentials>0</UseWindowsCredentials>

    Für BDI gibt es keine entsprechende Einstellung

  • BDIUseJabberCredentials

    Muss auf false konfiguriert sein:

    <BDIUseJabberCredentials>false</BDIUseJabberCredentials>

    Für EDI gibt es keine entsprechende Einstellung.

  • UseSSL (BDIEnableTLS)

    Regelt ob die Client per TLS/SSL Verbindung zum Jabber-Client Interface aufnehmen. Dies muss mit der Konfiguration des Jabber-Client Interfaces übereinstimmen. Das am Jabber-Client Interface angegebene Zertifikat muss am Client vertrauenswürdig sein:

    <UseSSL>0</UseSSL>
<BDIEnableTLS>false</BDIEnableTLS>

  • UseSecureConnection

    Muss auf 0 konfiguriert sei:

    <UseSecureConnection>0</UseSecureConnection>

    Für BDI gibt es die Einstellung nicht.

  • ConnectionUsername, ConnectionPassword (BDIConnectionUsername, BDIConnectionPassword)

    Mit diesen Konfigurationswerten können Anmeldedaten hinterlegt werden. Wird nichts angegeben, so versucht der Client eine anonyme Verbindung zum Client Interface aufzubauen.

  • SearchBase1 (BDISearchBase1)

    Muss auf vdir=VDir gesetzt werden:

    <SearchBase1>vdir=VDir</SearchBase1>
<BDISearchBase1>vdir=VDir</BDISearchBase1>

  • BaseFilter (BDIBaseFilter)

    Muss auf „(&amp;(objectCategory=Person)“ gesetzt werden:

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

  • PredictiveSearchFilter

    Muss auf anr gesetzt sein:

    <PredictiveSearchFilter>anr</PredictiveSearchFilter>

    Für BDI gibt es diese Einstellung nicht.

  • UseWildcards

    Muss auf 0 gesetzt sein:

    <UseWildcards>0</UseWildcards>

    Für BDI gibt es diese Einstellung nicht.

  • DisableSecondaryNumberLookups

    Muss auf 1 gesetzt werden. Das Jabber-Client Interface sucht immer in allen Rufnummern eines Kontakts:

    <DisableSecondaryNumberLookups>1</DisableSecondaryNumberLookups>

    Für BDI gibt es diese Einstellung nicht.

  • PhoneNumberMasks

    Wenn im Directory sowohl bei den Datenquellen als auch beim Jabber-Client Interface Wahlparameter angegeben werden, ist die Konfiguration von PhoneNumberMasks nicht notwendig. Für BDI gibt es diese Einstellung nicht.

  • BDIUseANR

    Muss auf true gesetzt sein:

    <BDIUseANR>true</BDIUseANR>

    Für EDI gibt es diese Einstellung nicht

  • UseSipUriToResolveContacts (BDIUseSipUriToResolveContacts)

    Ist dieser Wert auf „false“ gesetzt, ergibt sich die Chat-Adresse aus dem Inhalt von UserAccountName (BDIUserAccountName) und der angehängt Präsenzdomäne. Ist dieser Wert auf true gesetzt, ergibt sich die Chat-Adresse aus dem Inhalt von SipUri (BDISipUri).

  • PhotoUriSubstitutionEnabled (BDIPhotoUriSubstitutionEnabled)

    Muss auf false stehen:

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

Client-Interface Mappings

Die Tabelle zeigt die wichtigsten Jabber-Client Interface Attribute und mit welchen Directory-Feldern diese verbunden sind.

Jabber Client-Interface

Directory

sAMAccountName

Sonstiges 5

jid

Sonstiges 5

chat

XMPP Adresse

ipPhone

SIP Adresse

jpegPhoto

Bild

thumbnailPhoto

Bild

Directory Anbindung

Die wichtigste zu treffende Entscheidung ist, ob UseSipUriToResolveContacts (BDIUseSipUriToResolveContacts) auf true gesetzt werden soll. Dies bestimmt, wie Jabber-Clients einen Kontakt wieder finden, um ihn z.B. in der Kontaktansicht anzuzeigen oder ihn in der Kontaktliste nach dem Neustart zu aktualisieren. Ändert man dies nachträglich, so erscheinen zuvor in die Kontaktliste hinzugefügte Kontakte nur noch mit ihrer Chat-Adresse. Die Einstellung kann nur mittels jabber-config.xml auf true gesetzt werden.

Ist UseSipUriToResolveContacts false, erfragt der Jabber-Client vom Directory keine Chat-Adressen sondern nur Cisco-Anmeldenamen. Die Chat-Adresse aller Kontakte wird dann aus dem Anmeldenamen und der eigenen Präsenz-Domäne gebildet. Für externe Kontakte erfindet das Directory daher Anmeldenamen und wenn in der Datenquelle möglicherweise sogar eine externe Chat-Adresse vorhanden wäre. Federation mit einem Kontakt ist so nicht möglich. Möchte man mit UseSipUriToResolveContacts false arbeiten so ist dazu kein Eintrag in jabber-config.xml notwendig. Ebenso sollte es darin dann auch keinen Eintrag für SipUri (BDISipUri) geben.

Ist UseSipUriToResolveContacts true, so arbeitet der Jabber-Client mit den Chat-Adressen der Kontakte. Jeder Kontakt muss dann eine eindeutige und syntaktisch korrekte Chat-Adresse haben. Ist diese in einer Datenquelle nicht vorhanden, so erfindet das Directory eine solche. Damit Kontakte aus anderen Präsenzdomänen (externe Kontakte) in der Kontaktliste gespeichert werden, muss auf den Cisco-Servern Federation aktiviert sein. Ist dem nicht so, gibt es beim Versuch den Kontakt zu speichern eine kryptische Fehlermeldung. Möchte man UseSipUriToResolveContacts auf true setzen muss man in der jabber-config.xml zusätzlich SipUri (BDISipUri) auf chat stellen.

Möchte man vermeiden, dass die E-Mail-Adresse eines Kontakts auch immer als zusätzliche Bürorufnummer erscheint, muss man in der jabber-config.xml die Einstellung DirectoryUri (BDIDirectoryUri) auf ipPhone stellen.

Anbindung des Active Directory

Für die Anbindung des Active Directory an das Directory zur Unterstützung der Suche in Jabber-Clients sind ein paar wenige Änderungen am Mapping der Datenquelle notwendig.

Die folgenden Mapping-Empfehlungen gehen davon aus, dass am Mapping des Jabber-Client Interfaces nichts verändert wurde.

  1. Das AD-Attribut sAMAccountName muss auf das Directory-Feld Sonstiges 5 gemappt werden. Die Jabber-Clients erwarten hier den Cisco-Anmeldenamen.

  2. Auf das Directory-Feld SIP Adresse sollte ein AD-Attribut gemappt werden, dessen Inhalt der URL entspricht über der der Benutzer per URL-Wahl erreicht werden kann, der Inhalt als zusätzliche Bürorufnummer im Jabber-Client angezeigt wird. Oftmals entspricht diese der E-Mail des Benutzers. In diesem Fall sollte dann das AD-Attribut mail auf SIP Adresse gemappt werden. Andernfalls muss man eventuell aus dem AD-Attribut sAMAccountName und einer Verkettung des Inhalts im Mapping mit einem statischen Text die korrekte URL zusammensetzen.

  3. Auf das Directory-Feld XMPP Adresse sollte ein AD-Attribut gemappt werden, dessen Inhalt der Chat-Adresse des Cisco-Benutzers entspricht. Wenn das IM-Adress-Schema im Cisco Server auf Domain URL steht, ist dies genau das Feld, welches im Cisco IM-Adress-Schema-Dialog auch ausgewählt wurde. Wurde in der Cisco-Konfiguration als IM-Adress-Schema account@domäne eingestellt, so gibt es u.U. im AD kein Attribut, welches die Chat-Adresse der Benutzer enthält. In diesem Fall muss man XMPP Adresse mit dem AD-Attribut sAMAccountName verbinden und die Präsenzdomäne per Verkettung im Mapping als statischen Text hinzufügen.

  4. Im Active Directory sind Kontaktbilder entweder im Attribut jpegPhoto oder im Attribut thumbnailPhoto gespeichert. Das Directory erwartet das Bild im Feld jpegPhote. Demzufolge muss das Mapping der Datenquelle entsprechend angepasst werden.

In den meisten Fällen sollten folgende Änderungen im Mapping der Active Directory Datenquelle zum Ziel führen:

Active Directory Attribut

Directory Feld

sAMAccountName

Sonstiges 5

mail

XMPP Adresse

mail

SIP Adresse

thumbnailPhoto

Bild
Anbindung anderer Datenquellen

Zur korrekten Funktion erwarten die Jabber Clients in den Directory Feldern Sonstiges 5 und XMPP Adresse einen über alle Kontakte eindeutigen Wert, der zudem einigen Einschränkungen unterlegen ist. Die Werte dürfen weder Leerzeichen noch die Zeichen *()/\%ß²³´ enthalten und müssen kürzer als etwa 450 Zeichen sein. XMPP Adresse muss zudem der Domänensyntax (name@domäne) entsprechen.

Wenn das Jabber Client Interface aus den Datenquellen in diesen Feldern keinen Wert erhält, erzeugt es selbst einen passenden. Aufgrund der Längenbeschränkung von Bilddateinamen, können Bilder dabei nur angezeigt werden, wenn der Wert des Directory Feldes entryID und die Eindeutige Kennung der Datenquelle zusammen kürzer als etwa 80 Zeichen ist. Die oben genannte Grenze von etwa 450 Zeichen wird bei automatisch erzeugten Werten erreicht, wenn entryID und die Eindeutige Kennung der Datenquelle etwa 300 Zeichen lang ist. Würde der vom Jabber Client Interface erzeugte Wert länger als 450 Zeichen werden, wird too_long@nrp.com geliefert. Ein so markierter Kontakt zeigt kein Bild und kann nicht der Kontaktliste hinzugefügt werden.

Stören diese Einschränkungen nicht, so ist es nicht notwendig ein Mapping auf die Directory Felder Sonstiges 5, XMPP Adresse und SIP Adresse anzulegen. Die Felder können unverknüpft bleiben. Ansonsten muss versucht werden durch geschicktes Mapping der Datenquellenfelder Werte zu erhalten, die den obigen Kriterien entsprechen.

Ist auf den Cisco-Server Federation aktiviert und enthält die Datenquelle Chat-Adressen, so sollte das Directory Feld XMPP Adresse auf die Chat-Adresse gemappt werden.

Enthält die Datenquelle ein Feld, dessen Inhalt von den Jabber-Clients per URL wählbar ist, so sollte dieses Feld mit dem Directory Feld SIP Adresse verknüpft werden.

Cisco Unified CM Administration

Die Verzeichnisanbindung an Jabber-Clients kann entweder über Service Profiles oder über jabber-config.xml erfolgen.

Per UC-Services und Service Profiles

Zur Anbindung des Directory per Service Profiles müssen zuerst zwei UC-Services erstellt werden.

UC Service für BDI:

cisco1

UC Service für EDI:

cisco2

Die Einstellungen sollten exakt so übernommen werden. Es muss nur die korrekte IP-Adresse/Name und Port der Jabber-Client Interfaces eingetragen werden.

In dem Service Profile, welches den Benutzern zugeordnet ist, muss die Sektion Directory Profile konfiguriert werden:

cisco3

Auch hier sollten die Einstellungen exakt so übernommen werden.

Weisen Sie nun dem Benutzer das Service Profile zu:

cisco4

Je nach gewünschter Betriebsart (Federation oder nicht), müssen noch Einstellungen in jabber-config.xml getätigt werden:

cisco5

Im Knoten Directory brauchen dabei nie mehr als höchstens diese sechs Einstellungen vorhanden sein und diese auch nur dann, wenn das entsprechende Verhalten explizit gewünscht ist.

Ausschließlich per jabber-config.xml

Sind im Service Profile eines Benutzers keine Einstellungen in der Sektion Directory Profile gewünscht, so kann die vollständige Konfiguration auch in jabber-config.xml enthalten sein.

Wichtig

Wichtig zu wissen ist, dass Einstellungen, die über Service Profile kommen, Vorrang vor den Einstellungen in der jabber-config.xml haben.

Im Beispiel die umfassende Konfiguration per jabber-config.xml:

cisco6

Es reicht darin den Namen/IP Adresse und Port des Jabber-Client Interfaces einzusetzen.

Fehlerbehebung

Bilder werden nicht angezeigt

Als erstes ist zu überprüfen ob das Mapping der Datenquelle auf das Datenquellenfeld zeigt, welches auch wirklich das Bild enthält. Sollte im Active Directory das Bild im Attribut thumbnailPhoto stehen, muss das Mapping in der Datenquelle von jpegPhoto auf thumbnailPhoto umgestellt werden.

Der Jabber-Client speichert die Bilder im Verzeichnis zwischen:

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

Der Dateiname setzt sich dabei aus der Uri des Kontakts und einer kurzen Erweiterung zusammen. Datei werden alle Zeichen im Dateinamen, die nicht in der Menge {a-z;0-9} enthalten sind, durch eine drei Zeichen lange Kodierung ersetzt. Überschreitet die Länge des gesamten Pfades auf eine Bilddatei die Länge 255, so werden keine Bilder angezeigt. Zur Kontrolle kann man die Datei DirectoryRSCache im Verzeichnis öffnen:

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

cisco10

Die 1 bei Photo Blob gibt an, ob vom Directrory für den Kontakt ein Bild geliefert wurde oder nicht. Die zweite Markierung zeigt genau den Wert, der nicht zu lange und nur gültige Zeichen enthalten darf.

Steht bei dem Kontakt nicht Photo Blob sondern Photo Uri, so erwartet der Client das Bild zum Download in einer URL. In diesem steht in jabber-config.xml die Option PhotoUriSubstitutionEnabled (BDIPhotoUriSubstitutionEnabled) auf true.

Aus der zweiten Markierung ergibt sich der Dateiname der Photodateien. Nach der Kodierung ergibt sich daraus dieser Dateiname:

ActiveDirectory%3Anrp1%2D121ckl6mvu0w9c%3A2k%40nrp%2Ecom_small32.png
Kontakt kann nicht in die Kontaktliste aufgenommen werden

Kontakte können nur in die Kontaktliste aufgenommen werden, wenn sie eine korrekt formatierte Chat-Adresse haben.

Kontakte mit einer Chat-Adresse aus externen Domänen können nur in die Kontaktliste aufgenommen werden, wenn an den Cisco-Servern Federation aktiviert wurde.

Nach dem Neustart zeigt der Client für die Kontakte in der Kontaktliste nur die Chat-Adresse

Dies passiert, wenn der Client die Kontakte nicht mehr im Directory finden konnte. Dies ist dann der Fall, wenn

  • Das Jabber-Client Interface deaktiviert ist.

  • Die Chat-Adresse des Kontakts ungültige Zeichen enthält, zu lang ist oder nicht der Domänensyntax entspricht.

  • Die Einstellung UseSipUriToResolveContacts in jabber-config.xml verändert worden ist.

  • Im Mapping der Datenquelle die Zuordnung für Sonstiges 5 oder XMPP Adresse geändert wurde.

Es gibt einen Fehler beim Versuch einen Kontakt aus der Kontaktliste zu löschen

Überschreitet die Chat-Adresse eines Kontakts eine Länge von etwa 450 Zeichen, so kann man den Kontakt möglicherweise der Kontaktliste hinzufügen aber er lässt sich weder Löschen noch in eine andere Gruppe verschieben.

Bei einer Suche erscheinen unerklärliche Treffer

Das Jabber-Client Interface führt immer eine Volltextsuche über alle Eigenschaften der Kontakte im Directory durch. Daher kann es auch sein, dass ein Suchbegriff in einer Eigenschaft gefunden wurde, die im Jabber-Client nicht angezeigt wird.

Die Jabber-Clients halten intern einen Cache der, schon mal gefundenen, Treffer. Dieser Cache ist intern u.a. nach E-Mail-Adressen sortiert. Wenn die Kontakte aus dem Directory keine eindeutigen E-Mail-Adressen haben, so kann es zu vollständig unerklärlichen Treffern kommen.

Der Jabber Client ignoriert neue Konfigurationseinstellungen

Der Jabber Client holt sich neue Konfigurationseinstellungen oft nur beim Neuanmelden oder beim Neustart des Clients. Nach Konfigurationsänderungen sollte man also immer den Client neu starten.

Zudem speichert der Jabber Client manche Einstellungen lokal. So z.B. Bilder oder schon mal gefundene Kontakte. Um sicherzustellen, dass bei Konfigurationsänderungen Kontakte tatsächlich vom Directory geholt werden, empfiehlt es sich diesen lokalen Cache zu löschen. Im abgemeldeten Zustand bietet der Client dazu diese Option:

cisco11

Nach Modifikationen der jabber-config.xml kann es schon mal passieren, dass diese einen ungültigen Inhalt bekommt. Um zu kontrollieren, ob der Jabber-Client tatsächlich die Werte in der jabber-config.xml bekommt, kann man diese in der Datei cachedTFTPConfigStore.xml im Verzeichnis kontrollieren:

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

In der cachedUcm90ConfigStore.xml im obigen Verzeichnis speichert der Client die Einstellung ab, die er aus dem Service Profile erhalten hat.

Cisco IP Phone

XPhone Connect Directory Konfiguration

Hinweis

Konfigurieren Sie bitte das Xphone Connect Directory nach dieser Anleitung.

Unified Communications Manager Konfiguration

Phone Service erstellen

Auf dem CUCM gehen Sie zur Administrationsoberfläche und folgende diesen Schritten:

  1. Gehen Sie zu Device > Device Settings > Phone Services.

  2. Klick auf Add New.

  3. Definieren Sie einen Service Namen (z. B. XPhone Connect Directory).

  4. Geben Sie die Service URL ein. Die Service URL wird Ihnen in der Client Interface Konfiguration im XPhone Connect Directory (im letzten Schritt) angezeigt.

    Die URL sieht wie folgt aus:

    http://DIRECTORY-SERVER-OR-IP:389/vdirsearch.do

  5. Als Service Category wählen Sie XML-Service und als Service Type wählen Sie Default-IP-Phone service.

  6. Aktivieren Sie die Checkbox Enable.

  7. Wenn die Konfiguration auf allen Telefonnen gesetzt werden soll, aktivieren Sie die Enterprise Subscription Checkbox. Wenn Sie dies nicht wünschen so führen Sie die Konfiguration wie unten beschrieben durch.

  8. Klicken Sie Save and Update Subscriptions.

Konfiguration von ausgewählten Geräten

Wenn nur ausgewählte Geräte Zugriff auf das XPhone Connect Directory haben sollen, gehen Sie wie folgt vor:

  1. Gehen Sie zu Device > Phone.

  2. Öffnen Sie die Konfiguration des entsprechenden Gerätes.

  3. Unter Related Links gehen Sie zu Subscribe/Unsubscribe Services (rechte Ecke).

  4. Als Service, wählen Sie den zuvor erstellten Phone Service. Sie sehen: Create phone service.

  5. Klick Next.

  6. Klick Subscribe.

Hinweis

Auf Grund von technischen Einschränkungen, ist der Zugriff auf persönliche Kontaktdaten nicht möglich (keine Benutzer-Authentifizierung durch Endgeräte).

Bekannte Einschränkungen

  • Cisco Jabber für iPhone und iPad, mit der Version 9.6.2 umfasst die Such-Funktionalität mit XPhone Connect Directory, jedoch können Kontakt-Bilder nicht angezeigt werden.

  • Der Zugriff auf Kontakte des persönlichen Ordners (z. B. bei Outlook) von Cisco IP Phones oder Jabber Clients, in Verbindung mit XPhone Connect Directory, wird nicht unterstützt.

  • Der Cisco Jabber Client für Mac, mit der Version 10.5.1, unterstützt die XPhone Connect Directory Integration. Jedoch werden Kontakt-Bilder und Detail-Informationen, angemeldeter Benutzer, nicht angezeigt.

Haben Sie einen Fehler auf dieser Seite entdeckt?

Bitte schicken Sie uns einen Hinweis auf diesen Fehler per Mail an doku@c4b.de. Vielen Dank!