連絡先ソース

連絡先ソースとは

連絡先ソースとはユーザに関するデータの集合です。ユーザが連絡先を検索したり、Cisco Jabber クライアントに連絡先を追加するときに、連絡先ソースから連絡先情報が読み取られます。

Cisco Jabber は連絡先ソースから連絡先情報を取り出して連絡先リストに入力し、クライアントの連絡先カードと連絡先情報を表示する他の領域を更新します。インスタント メッセージや音声/ビデオ コールなどの着信をクライアントが受信したときに、連絡先ソースを使用して連絡先情報が解決されます。

連絡先ソースサーバー


(注)  

Jabber のすべてのクライアントで、ディレクトリ統合の LDAPv3 標準がサポートされます。この標準をサポートするディレクトリ サーバは、次のクライアントと互換性があります。


Cisco Jabberで、次の連絡先ソースサーバーを使用できます:

  • Active Directory Domain Services for Windows Server 2012 R2

  • Active Directory Domain Services for Windows Server 2008 R2

  • Cisco Unified Communications Managerユーザデータサーバ (UDS)Cisco Jabberは、Cisco Unified Communications Managerのバージョン 10.5以降を使用して UDS をサポートします。

  • OpenLDAP

  • Active Directory ライトウェイト ディレクトリ サービス(AD LDS)または Active Directory アプリケーション モード(ADAM)

連絡先ソースが必要な理由

Cisco Jabber は連絡先ソースを次のように使用します。
  • 連絡先のユーザの検索:クライアントは入力された情報を取得して、連絡先ソースを検索します。情報は連絡先ソースから取得され、クライアントはその連絡先とやり取りするために使用可能な方法を表示します。

  • クライアントが着信通知を受信:クライアントは着信通知から情報を取得して、URI 番号を解決し、連絡先ソースから連絡先と JabberID を取得します。クライアントはアラートに連絡先の詳細を表示します。

連絡先の送信元サーバを設定するタイミング


(注)  

Active Directory ドメインに登録されているワークステーションにCisco Jabber をインストールします。この環境では、Cisco Jabber をディレクトリに接続するように設定する必要がありません。クライアントはディレクトリを自動的に検出し、そのドメイン内のグローバル カタログ サーバに接続します。


次のいずれかのサービスを連絡先ソースとして使用する場合は、Cisco Jabber をディレクトリサービスに接続するように設定します。

  • Active Directoryサービス

  • Cisco Unified Communications Manager User Data Service

  • OpenLDAP

  • Active Directory ライトウェイト ディレクトリ サービス

  • Active Directory Application Mode; Active Directory アプリケーション モード

オプションで、次のようにディレクトリ統合を設定できます。

  • デフォルト属性マッピングを変更します。

  • ディレクトリのクエリー設定を調整します。

  • クライアントが連絡先写真を取得する方法を指定します。

  • イントラドメイン フェデレーションを実行します。

Cisco Directory Integration 向け連絡先ソースのオプション。

オンプレミス展開では、クライアントがユーザ情報のディレクトリ検索を解決するために次の連絡先ソースのいずれかを要求します。

  • Lightweight Directory Access Protocol(LDAP):社内ディレクトリがある場合は、次の LDAP ベースの連絡先ソース オプションを使用してディレクトリを連絡先ソースとして設定できます。

    • Cisco ディレクトリ統合(CDI):すべてのクライアントを展開する場合に、この連絡先ソース オプションを使用します。

  • Cisco Unified Communications Manager User Data Service(UDS):社内ディレクトリがない場合、または展開に Expressway Mobile and Remote Access と接続しているユーザが含まれている場合は、このオプションを使用できます。

軽量ディレクトリ アクセス プロトコル

Cisco Directory IntegrationがLDAPと協力する方法

CDI はサービス検出を使用して LDAP サーバを決定します。

CDI を使用したオンプレミス展開用のデフォルト設定は次のとおりです。

  • Cisco Jabber は連絡先ソースとして Active Directory と統合します。

  • Cisco Jabber は自動的にグローバル カタログを検出して接続します。

自動サービス検出: 推奨

サービス検出を使用し、グローバルカタログ (GC) サーバまたはLDAP サーバに自動的に接続および認証することをお勧めします。展開をカスタマイズする場合は、LDAP サーバ情報を提供するオプションと使用可能な認証オプションを確認します。Jabber は最初に GC ドメインに DNS クエリを送信して GC サーバを検出します。GC サーバが検出されない場合、Jabber は ldap ドメインに DNS クエリを送信して LDAP サーバを検出します。

CDI の図

GC がある場合、クライアントは次のように実行します。

  1. DNS ドメインをワークステーションから取得し、GC の SRV レコードを検索します。

  2. SRV レコードから GC のアドレスを取得します。

  3. ログインしているユーザのクレデンシャルで GC に接続します。

グローバルカタログドメインを使用した探索

Jabber は、DNS SRV クエリを使用して GC サーバを検出しようとします。まず、Jabber は GC ドメインを取得します。

  1. 利用可能な場合、Jabber は GCドメインとしてDNSFORESTNAME 環境変数を使用します。

  2. DNSFORESTNAMEが利用できない場合、JABBER は GC ドメインについて次のことを確認します。

    • Windows では、Jabber は Windows DsGetDcName API を呼び出して、DnsForestNameを取得します。

    • Windows 以外のプラットフォームでは、Jabberはjabber-config LdapDNSForestDomainから読み取ります。

Jabber は GC ドメインを取得すると、次のように DNS SRV クエリを送信して GC サーバアドレスを取得します。

  • Windows では、Jabber はSiteNameが Windows DsGetSiteName API を通じて利用可能かどうかを確認します。

    • SiteNameが存在する場合、JABBER は DNS SRV クエリを送信して、_gc _tcp を送信します。_Sites。GCDomainは、GC サーバアドレスを取得します。

    • SiteNameが存在しない場合、または_gc._tcp.SiteName._sites.GCDomainに対して SRV レコードが返されない場合、Jabber は DNS SRV クエリ _gc を_gc._tcp.GCDomainに送信し、GC サーバアドレスを取得します。

  • Windows 以外のプラットフォームでは、Jabber は DNS SRV クエリ_gc._tcp.GCDomainを送信して、GC サーバアドレスを取得します。

LDAP ドメインを使用した検出

Jabber が GC サーバを検出できない場合は、次のようにして LDAP ドメインを検出します。

  1. 利用可能な場合、Jabber は LDAP ドメインとしてUSERDNSDOMAIN 環境変数を使用します。

  2. USEDNSDOMAINが利用できない場合、jabber はLdapUserDomainjabber-config.xmlから読み取ります。

  3. LdapUserDomainが利用できない場合、jabber は、ユーザが LDAP ドメインとしてログインに使用した電子メールドメインを使用します。

Jabber がLDAP ドメインを取得すると、次のように DNS SRV クエリを送信して LDAP サーバアドレスを取得します。

  • Windows では、Jabber は SiteName が Windows DsGetSiteName API を介して利用可能かどうかを確認します。

    • SiteName が存在する場合、Jabber は DNS SRV クエリ_ldap._tcp.SiteName.sites.LdapDomainを送信して、LDAP サーバアドレスを取得します。

    • SiteNameが存在しない場合、または _ldap._tcp.SiteName.sites.LdapDomainに対して SRV レコードが返されない場合、Jabber は DNS SRV クエリを送信し、_ldap._tcp.LdapDomainLDAP サーバアドレスを取得します。

  • Windows 以外のプラットフォームでは、Jabber は DNS SRV クエリを送信して、_ldap._tcp.LdapDomainLDAP サーバアドレスを取得します。

Jabber が LDAP サーバに接続したら、使用する認証メカニズムのリストと順序が指定された SupportedSaslMechanisms 属性を読み取ります。

LDAPサービスに対する手動設定

LDAPサービスに対する手動設定

  1. PrimaryServerName パラメータを設定すると、Jabber が接続する特定の LDAP サーバを定義できます。

  2. jabber-config.xml ファイルの LdapSupportedMechanisms パラメータを設定すると、supportedSaslMechanisms 属性のリストを上書きできます。

    連絡先サービスとLDAPサーバーは、これらメカニズムのそれぞれをサポートする必要があります。複数の値はスペースで区切ります。

    • GSSAPI – Kerberos v5

    • EXTERNAL – SASL external

    • PLAIN(デフォルト)– LDAP シンプル バインド。匿名はシンプル バインドの一部です。

    例:

    <LdapSupportedMechanisms>GSSAPI EXTERNAL PLAIN</LdapSupportedMechanisms>
  3. 必要であれば、Jabber が LDAP サーバの認証に使用するドメインを設定するために、LdapUserDomain パラメータを設定してください。次に例を示します。

    CUCMUsername@LdapUserDomain

LDAP の考慮事項

基本ディレクトリ統合(BDI)と拡張ディレクトリ統合(EDI)の各パラメータは、Cisco ディレクトリ統合(CDI)パラメータに置き換えられます。CDI パラメータはすべてのクライアントに適用されます。

Cisco Jabberの展開シナリオ

シナリオ 1:Jabber 11.8 を初めて使用する場合

サービス検出を使用し、LDAP サーバに自動的に接続および認証することをお勧めします。展開をカスタマイズする場合は、LDAP サーバ情報を提供するオプションと使用可能な認証オプションを確認します。

シナリオ 2:EDI 設定から 11.8 にアップグレードする場合

EDI パラメータのみを使用する設定の場合、Jabber は EDI パラメータを読み取り、ディレクトリ ソース統合でこのパラメータを使用します。EDI パラメータをアップグレードして、同等の CDI パラメータで置き換えることをお勧めします。

シナリオ 3:BDI 設定から 11.8 にアップグレードする場合

BDI パラメータのみを使用する設定の場合、BDI パラメータを同等の CDI パラメータに更新する必要があります。たとえば、BDIPrimaryServerName の場合、このパラメータを PrimaryServerName で置き換える必要があります。BDIEnableTLSUseSSL パラメータに置き換えられます。

シナリオ 4:EDI と BDI の混合設定から 11.8 にアップグレードする場合

EDI と BDI の両方を使用する設定の場合、Jabber が LDAP サーバに接続する場合に EDI パラメータを使用しているかを BDI の設定を確認する必要があります。

ディレクトリ パラメータ

次の表に、BDI と EDI のパラメータを示し、CDI パラメータ名、または Jabber 11.8 以降に適用されないかどうかも示します。

BDI パラメータ

EDI パラメータ

CDI パラメータ

-

DirectoryServerType

DirectoryServerType

-

ConnectionType

-

BDILDAPServerType

-

-

BDIPresenceDomain

PresenceDomain

PresenceDomain

BDIPrimaryServerName

PrimaryServerName

PrimaryServerName

-

SecondaryServerName

SecondaryServerName

BDIServerPort1

ServerPort1

ServerPort1

-

ServerPort2

ServerPort2

-

UseWindowCredentials

-

BDIUseJabberCredentials

-

-

BDIConnectionUsername

ConnectionUsername

ConnectionUsername

BDIConnectionPassword

ConnectionPassword

ConnectionPassword

BDIEnableTLS

UseSSL

UseSSL

-

UseSecureConnection

-

BDIUseANR

UseANR

UseANR

BDIBaseFilter

BaseFilter

BaseFilter

BDIGroupBaseFilter

GroupBaseFilter

GroupBaseFilter

BDIUseANR

-

-

BDIPredictiveSearchFilter

PredictiveSearchFilter

PredictiveSearchFilter

-

DisableSecondaryNumberLookups

DisableSecondaryNumberLookups

-

SearchTimeout

SearchTimeout

-

UseWildcards

UseWildcards

-

MinimumCharacterQuery

MinimumCharacterQuery

BDISearchBase1

SearchBase1、SearchBase2、SearchBase3、SearchBase4、SearchBase5

SearchBase1、SearchBase2、SearchBase3、SearchBase4、SearchBase5

BDIGroupSearchBase1

GroupSearchBase1、GroupSearchBase2、GroupSearchBase3、GroupSearchBase4、GroupSearchBase5

GroupSearchBase1、GroupSearchBase2、GroupSearchBase3、GroupSearchBase4、GroupSearchBase5

BDIUseSipUriToResolveConta cts

UseSipUriToResolveContacts

UseSipUriToResolveContacts

BDIUriPrefix

UriPrefix

UriPrefix

BDISipUri

SipUri

SipUri

BDIPhotoUriSubstitutionEnab led

PhotoUriSubstitutionEnabled

PhotoUriSubstitutionEnabled

BDIPhotoUriSubstitutionToken

PhotoUriSubstitutionToken

PhotoUriSubstitutionToken

BDIPhotoUriWithToken

PhotoUriWithToken

PhotoUriWithToken

BDIPhotoSource

PhotoSource

PhotoSource

LDAP_UseCredentialsFrom

LDAP_UseCredentialsFrom

LDAP_UseCredentialsFrom

LDAPUserDomain

LDAPUserDomain

LDAPUserDomain

-

-

LdapSupportedMechanisms

BDICommonName

CommonName

CommonName

BDIDisplayName

DisplayName

DisplayName

BDIFirstname

Firstname

Firstname

BDILastname

Lastname

Lastname

BDIEmailAddress

EmailAddress

EmailAddress

BDISipUri

SipUri

SipUri

BDIPhotoSource

PhotoSource

PhotoSource

BDIBusinessPhone

BusinessPhone

BusinessPhone

BDIMobilePhone

MobilePhone

MobilePhone

BDIHomePhone

HomePhone

HomePhone

BDIOtherPhone

OtherPhone

OtherPhone

BDIDirectoryUri

DirectoryUri

DirectoryUri

BDITitle

Title

Title

BDICompanyName

CompanyName

CompanyName

BDIUserAccountName

UserAccountName

UserAccountName

BDIDomainName

DomainName

DomainName

BDICountry

Country

Country

BDILocation

Location

Location

BDINickname

Nickname

Nickname

BDIPostalCode

PostalCode

PostalCode

BDICity

City

City

BDIState

状態

State

BDIStreetAddress

StreetAddress

StreetAddress

Cisco Unified Communications Manager User Data Service

User Data Service(UDS)は、連絡先解決を提供する Cisco Unified Communications Manager の REST インターフェイスです。

UDS は次のような状況で連絡先解決に使用されます。

  • クライアント コンフィギュレーション ファイルの UDS の値を使用するように DirectoryServerType パラメータを設定した場合。

    この設定では、企業のファイアウォールの内側または外側のクライアントが連絡先解決に UDS を使用します。

  • Expressway for Remote and Mobile Access を展開した場合。

    この設定では、企業のファイアウォールの外側のクライアントが自動的に連絡先解決に UDS を使用します。

ディレクトリ サーバから Cisco Unified Communications Manager に連絡先データを同期します。そうすると、Cisco Jabber が自動的に UDS からその連絡先データを取得します。

UDS の図

複数のクラスタでの連絡先の解決

複数の Cisco Unified Communications Manager クラスタを使用した連絡先解決では、社内ディレクトリ上のすべてのユーザを各クラスタに同期させます。該当するクラスタでそのようなユーザのサブセットをプロビジョニングします。

たとえば、組織のユーザが 40,000 人とします。20,000 人のユーザが北米にいます。20,000 人のユーザがヨーロッパにいます。組織は、拠点ごとに次の Cisco Unified Communications Manager クラスタを配置しています。
  • cucm-cluster-na(北米)

  • cucm-cluster-eu(ヨーロッパ)

この例では、40,000 人のユーザすべてを両方のクラスタに同期させます。北米の 20,000 人のユーザを cucm-cluster-na に、ヨーロッパの 20,000 人のユーザを cucm-cluster-eu にプロビジョニングします。

ヨーロッパのユーザが北米のユーザに発信すると、Cisco Jabber が cucm-cluster-na からヨーロッパのユーザの連絡先詳細を取得します。

北米のユーザがヨーロッパのユーザに発信すると、Cisco Jabber が cucm-cluster-eu から北米のユーザの連絡先詳細を取得します。

UDS 拡張連絡先ソース

UDS から LDAP サーバに連絡先検索を拡張します。Cisco Unified Communications Manager 11.5(1) 以降では、Jabber が LDAP サーバを検索するかどうかを設定できます。

LDAP の前提条件

Cisco Jabber はさまざまな属性を使用して連絡先ソースを検索しますが、これらの属性すべてがデフォルトでインデックス化されるわけではありません。効率的に検索するために、Cisco Jabber で使用される属性をインデックス化する必要があります。

デフォルトの属性マッピングを使用する場合は、次の属性が LDAP サーバ上でインデックス化されていることを確認します。

  • sAMAccountName

  • displayName

  • sn

  • 名前

  • proxyAddresses

  • [mail]

  • 部署

  • givenName

  • telephoneNumber

  • otherTelephone

  • mobile

  • homePhone

  • msRTCSIP-PrimaryUserAddress

LDAP サービス アカウント

Jabber を LDAP サーバに接続するには、LDAP による Jabber ユーザの認証方法を定義する必要があります。

  • サービス プロファイルまたは jabber-config.xml ファイルでクレデンシャルを定義した場合、常にデフォルト オプションが優先されます。デフォルト オプションは、Jabber は Kerberos またはクライアント証明書(SASL External)を使用して連絡先サーバーに自動的に接続されます。このオプションは安全性に優れているため使用することをお勧めします。

  • LdapSupportedMechanisms パラメータに PLAIN 値を設置しても、ディレクトリ プロファイルのユーザ名またはパスワードを設定しなければ、ユーザはディレクトリ クレデンシャルをクライアント ディレクトリに入力できます。

  • それ以外の場合、セキュア ポートをサービス プロファイルに接続したら、jabber-config.xml ファイルの LDAP_UseCredentialsFrom 設定パラメータの Cisco Unified Communications Manager クレデンシャルを指定することで、Jabber をディレクトリ サーバに接続する方法を定義できます。

  • 前述のオプションが使用できない場合は、サービス プロファイルまたは jabber-config.xml ファイルで提供される既知のクレデンシャル セットを使用します。これは安全性が最も低いオプションです。Cisco Jabber は、アカウントを使用して連絡先ソースサーバーを認証します。このアカウントは、ディレクトリへの読み取りアクセス専用にして、一般的なパブリック クレデンシャル セットにすることを推奨します。この場合、すべての Jabber ユーザは、これらの資格情報を検索に使用します。


(注)  

Cisco Unified Communications Manager 12.0 以降では、サービス プロファイルでユーザ名とパスワードを設定することはできません。Jabber ユーザは、ディレクトリ サービスを使用して自身を認証するためのオプションを取得します。ユーザが Jabber に初めてサインインすると、ユーザに通知が送信されます。最初に自分自身を認証しない場合、連絡先リストにアクセスしようとすると警告が表示されます。


Jabber ID 属性マッピング

ユーザ ID の LDAP 属性は sAMAccountName です。これがデフォルト属性です。

ユーザ ID の属性が sAMAccountName 以外の場合で、Cisco Unified Communications Manager IM and Presence サービス でデフォルトの IM アドレス スキームが使用されている場合は、次のようにクライアント コンフィギュレーション ファイルでパラメータの値として属性を指定する必要があります。

CDI パラメータはUserAccountNameです。<UserAccountName>attribute-name</UserAccountName>

設定で属性を指定せず、属性が sAMAccountName 以外の場合、クライアントはディレクトリ内の連絡先を解決できません。この結果、ユーザはプレゼンスを取得せず、インスタント メッセージを送信または受信できません。

Jabber ID の検索

Cisco Jabber は Jabber ID を使用して、ディレクトリ内の連絡先情報を検索します。ディレクトリ内の検索を最適化するオプションがいくつかあります。

  • 検索ベース—デフォルトでは、クライアントはディレクトリ ツリーのルートから検索を開始します。検索ベースを使用して、別の検索開始を指定したり、特定のグループに対する検索を制限したりできます。たとえば、ユーザのサブセットにはインスタント メッセージング機能だけがあります。これらのユーザを OU に含め、この OU を検索ベースとして指定します。

  • ベース フィルタ—ディレクトリのサブキー名のみを指定し、ディレクトリへのクエリーの実行時にユーザ オブジェクト以外のオブジェクトを取得します。

  • 予測検索フィルタ—検索クエリーをフィルタするために、複数のカンマ区切り値を定義できます。デフォルト値は ANR(Ambiguous Name Resolution)です。

これらオプションについての詳細については、Cisco Jabber向けパラメータリファレンスガイドのディレクトリ統合に関する章を参照してください。

ローカル連絡先ソース

Cisco Jabber には、ローカル連絡先ソースにアクセスして検索する機能があります。これらのローカル連絡先ソースには次のものがあります。
  • Microsoft Outlook に保存されているローカル連絡先には Cisco Jabber for Windows からアクセスします。

  • IBM Notes に保存されているローカル連絡先には Cisco Jabber for Windows(リリース 11.1 以降)からアクセスします。

  • ローカル アドレス帳の連絡先には、Cisco Jabber for Mac、Cisco Jabber for Android、Cisco Jabber for iPhone and iPad からアクセスします。

カスタム連絡先ソース

すべてのクライアントの Cisco Jabber は、クライアントにカスタム連絡先をインポートする機能をユーザに提供します。

連絡先のキャッシュ

Cisco Jabber は、ローカルキャッシュを作成します。特に、キャッシュには、ユーザの連絡先リストが保存されています。ユーザが連絡先リストで連絡先を検索するとき、Jabber はローカル キャッシュで一致する連絡先を検索してから、ディレクトリ検索を開始します。

ユーザが連絡先リストに存在しない連絡先を検索している場合、Jabber はまずローカル キャッシュを検索し、その後社内ディレクトリを検索します。そしてユーザがその連絡先とチャットまたは通話を開始すると、Jabber は連絡先情報をローカル キャッシュに追加します。

ローカル キャッシュ情報は 24 時間で期限切れになります。

重複する連絡先の解決

Jabber の連絡先は異なるソースから取得できます。Jabber では、複数の連絡先ソースで同じ連絡先の一致が検出される可能性があります。この場合、Jabber は、同じ人物に一致するレコードを判断し、その人物のすべてのデータを結合します。いずれかの連絡先ソースのレコードが連絡先に一致しているかどうかを確認するために、Jabber は次の順序でこれらのフィールドを探します。

  1. Jabber ID (JID): レコードに JID が含まれている場合、Jabber はそのベースのレコードに一致します。Jabber は、メールまたは電話番号のフィールドに基づいた比較は行いません。

  2. メール: レコードにメールフィールドがある場合、Jabber はその基準に一致するレコードを検索します。Jabber は、電話番号に基づいてレコードをそれ以上比較することはありません。

  3. 電話番号:レコードに電話番号が含まれる場合、Jabberは電話番号に基づいて照合されます。

Jabber は、レコードを比較し、同じ人物に一致するレコードを特定するため、連絡先のデータを結合して 1 つの連絡先レコードを作成します。

ダイヤル プランのマッピング

Cisco Unified Communications Manager のダイヤル ルールがディレクトリのダイヤル ルールと確実に一致するように、ダイヤル プランのマッピングを設定します。

アプリケーション ダイヤル ルール

アプリケーション ダイヤル ルールにより、ユーザがダイヤルする電話番号の桁数の追加および削除が自動的に行われます。アプリケーション ダイヤル ルールにより、ユーザがクライアントからダイヤルする番号が操作されます。

たとえば、7 桁の電話番号の先頭に自動的に 9 を追加して外線にアクセスするように、ダイヤル ルールを設定できます。

ディレクトリ検索ダイヤル ルール

ディレクトリ検索ダイヤル ルールによって、発信者 ID の番号が、クライアントがディレクトリで検索できる番号に変換されます。定義する各ディレクトリ検索ルールには、先頭の数字および番号の長さに基づいてどの数字を変換するかを指定します。

たとえば、10 桁の電話番号から市外局番と 2 桁の局番を自動的に削除するディレクトリ検索ルールを作成できます。このタイプのルールでは、たとえば、408902313923139 に変換します。

Cisco Unified Communication Manager UDS for Mobile and Remote Access

Cisco Unified Communication Manager UDS は、Cisco Jabber が Expressway Mobile and Remote Access を使用して接続している際に使用される連絡先ソースです。企業ファイアウォールの内側に LDAP を展開する場合は、LDAP ディレクトリ サーバを Cisco Unified Communications Manager と同期させ、ユーザが企業ファイアウォールの外側にいるときにクライアントを UDS に接続できるようにすることをお勧めします。

クラウドの連絡先ソース

Cisco Webex 連絡先ソース

クラウド展開では、連絡先データは Cisco Webex Messenger 管理ツールで設定されるか、またはユーザの更新によって設定されます。連絡先情報は Cisco Webex Messenger 管理ツールを使用してインポートすることができます。詳細については、Cisco Webex Messenger 管理ガイドのユーザー管理のセクションを参照してください。

連絡先の写真の形式と寸法

Cisco Jabber で最適な結果を得るには、連絡先写真を特定の形式と寸法にする必要があります。サポートされる形式と最適な寸法を確認してください。クライアントが連絡先の写真に対して行う調整について説明します。

連絡先の写真の形式

Cisco Jabber は、ディレクトリ内の連絡先写真に関する次の形式をサポートしています。

  • JPG

  • PNG

  • BMP


重要

Cisco Jabber では、GIF 形式の連絡先写真のレンダリングを向上させるための変更は適用されません。その結果、GIF 形式の連絡先写真が不正にレンダリングされたり最適な品質にならない場合があります。最適な品質を得るには、連絡先写真として PNG 形式を使用します。


連絡先の写真の寸法


ヒント

連絡先写真の最適な寸法は、アスペクト比 1:1 の 128 x 128 ピクセルです。

Microsoft Outlook でのローカル連絡先写真の最大寸法は 128 X 128 ピクセルです。


次の表に、Cisco Jabber での連絡先写真のさまざまな寸法を示します。

参照先

寸法

音声コール ウィンドウ

128 x 128 ピクセル

次のような招待やリマインダ

  • 着信コール ウィンドウ

  • 会議リマインダ ウィンドウ

64 x 64 ピクセル

次のような連絡先のリスト

  • 連絡先リスト

  • 参加者リスト

  • コール履歴

  • ボイスメール メッセージ

32 x 32 ピクセル

連絡先の写真の調整

Cisco Jabber は次のように連絡先写真を調整します。
  • サイズ変更:ディレクトリ内の連絡先写真が 128 X 128 ピクセル以外のサイズである場合、クライアントによって写真のサイズが自動的に変更されます。たとえば、ディレクトリ内の連絡先写真が 64 x 64 ピクセルであるとします。Cisco Jabber でディレクトリから連絡先写真を取得すると、その写真のサイズが 128 X 128 ピクセルに変更されます。


    ヒント

    連絡先写真のサイズ変更により、最適な解像度が得られない場合があります。このため、クライアントによって連絡先写真のサイズが自動的に変更されないように、128 X 128 ピクセルの連絡先写真を使用してください。


  • トリミング:Cisco Jabber では、正方形以外の連絡先写真を正方形のアスペクト比(つまり、幅と高さが同じであるアスペクト比 1:1)に自動的にトリミングします。

  • ディレクトリ内の連絡先写真が縦方向である場合、クライアントは上端から 30 %、下端から 70 % をトリミングします。

    たとえば、ディレクトリ内の連絡先写真が幅 100 ピクセル、高さ 200 ピクセルである場合、アスペクト比が 1:1 となるように Cisco Jabber では高さから 100 ピクセルをトリミングする必要があります。この場合、クライアントは写真の上端から 30 ピクセルを、写真の下端から 70 ピクセルをトリミングします。

  • ディレクトリ内の連絡先写真が横方向である場合、クライアントで両方の側から 50 % をトリミングします。

    たとえば、ディレクトリ内の連絡先写真が幅 200 ピクセル、高さ 100 ピクセルである場合、アスペクト比が 1:1 となるように Cisco Jabber では幅から 100 ピクセルをトリミングする必要があります。この場合、クライアントは写真の右側から 50 ピクセルを、写真の左側から 50 ピクセルをトリミングします。