IBM Sametime Unified Telephony 9: 管理

IBM® Sametime® Unified Telephony サーバーとユーザーを管理して、デプロイメント内の機能への適切なアクセスを提供するようにします。

管理

このセクションでは、IBM Sametime Unified Telephony 環境をモニタ、プロビジョニング、更新する方法を説明します。

このタスクについて

Sametime Unified Telephony は、デプロイ済み環境をモニタおよび管理するための以下のツールを備えています。

  • Sametime Unified Telephony 管理コンソール

    このコンソールは、Integrated Solutions Console の一部です。 Sametime Unified Telephony 管理コンソールは、コールボリューム、ユーザーコールアクティビティ、ライセンス使用をモニタするために使用します。このコンソールには、サーバー状況の概要も示されます。 サーバーが実行中かどうかを判別するには、まず最初にここで確認できます。

  • SIP Proxy and Registrar 管理コンソール

    このコンソールも、Integrated Solutions Console の一部です。 SIP Proxy and Registrar 管理コンソールは、方式 (SIP または SIPS) やトランスポートプロトコルなどのプロキシのプロパティの表示および編集、または SIP レジストラの有効期限プロパティの設定のために使用します。

  • Common Management Portal

    Common Management Portal は、Sametime Unified Telephony コミュニケーションソリューション用の、ブラウザベースの構成インターフェースです。 これには、Sametime Unified Telephony デプロイ済み環境のコンポーネントを構成するために使用できる管理機能があります。Common Management Portal は、テレフォニー制御サーバー、アプリケーションサーバー、メディアサーバーの構成と、ビジネスグループ、番号計画、機能プロファイルの定義のために使用します。

テレフォニーアプリケーションサーバーの永続キャッシュの更新

IBM Sametime Unified Telephony デプロイメントでは、各テレフォニーアプリケーションサーバーの永続キャッシュを定期的に更新して、無効エントリを削除する必要があります。

始める前に

永続キャッシュを更新する前に、「テレフォニーアプリケーションサーバーでの永続キャッシュの初期化」の説明に従って、キャッシュを初期化する必要があります。
重要: Sametime Community Server 構成では、Sametime ID として使用される組織のディレクトリ属性を定義する必要があります。例えば、ユーザーのメールアドレスや識別名も当該ユーザーの Sametime ID として使用されます。 Sametime ID を変更する場合 (つまり、他の属性を選択する場合)、永続キャッシュが既に存在しているときは、既存のキャッシュを削除し、新しいキャッシュを初期化して、変更に対応する必要があります。

このタスクについて

永続キャッシュを初期化すると、テレフォニーアプリケーションサーバーにプロビジョニングされたすべてのユーザーが、Sametime サーバーに対して解決され、サーバーを再起動するたびにこの処理を繰り返す必要がないように、情報が永続キャッシュに保管されます。ある時点でキャッシュ内のエントリが無効になる場合があります。例えば、組織のディレクトリでユーザーのレコードが削除されたときや更新されたときです。永続キャッシュを更新することにより、保管済みのエントリが Sametime サーバーに対して解決され、必要に応じて更新されます。

Sametime Java™ Toolkit の CachedResolve コンポーネントには、CachedResolveRefreshUtility アプリケーションが用意されています。このアプリケーションは、無効なエントリのみを削除して、キャッシュを更新します。このユーティリティは、更新対象の名前が含まれた .CSV ファイルを使用します。Sametime 管理者が、1 つ以上の .CSV (コンマ区切り値) ファイルを作成して、Sametime サーバー上のユーザー名を更新するときはいつでも、これらのファイルを使用して (追加の変更を行うことなく) 永続キャッシュを更新できます。

.CSV ファイルでは、ユーザーデータは以下のように表示されます。
ID,,
"uid=user0,cn=load,cn=users,DC=TEAMSPACE,DC=COM", "uid=user0,cn=load,cn=users_new_group,DC=TEAMSPACE,DC=COM", "user0"
"uid=user1,cn=load,cn=users,DC=TEAMSPACE,DC=COM", "uid=user1,cn=load,cn=users_new_group,DC=TEAMSPACE,DC=COM", "user1"
"uid=user2,cn=load,cn=users,DC=TEAMSPACE,DC=COM", "uid=user2,cn=load,cn=users_new_group,DC=TEAMSPACE,DC=COM", "user2"
1 行目には、ファイルの種類とフォーマット定義が含まれます。1 行目が「ID」キャプションで始まっている場合は、Sametime ユーザー ID (STId) を更新する必要があります。 この場合、後続の行はそれぞれ、1 人のユーザーの Sametime ID の更新情報を示しています。
old_user_Sametime_ID, new_user_Sametime_ID, additional_user_attribute
例えば、additional_user_attribute は、リストされたサンプルファイルに示すように、表示名の場合があります。

手順

  1. .CSV ファイルを Sametime サーバーからテレフォニーアプリケーションサーバーにコピーします。
  2. Sametime サーバーを停止します。
  3. テレフォニーアプリケーションサーバーを停止します。
  4. 以下のように、テレフォニーアプリケーションサーバーで、refresh_resolve_cache.sh スクリプトを実行して、CachedResolveRefreshUtility アプリケーションをアクティブにし、CSV ファイルの情報を使用して永続キャッシュを更新します。
    /enterprise/ibm/tools/refresh_resolve_cache.sh "CSV_file_1;CSV_file2;CSV_file_n"
    ここで、
    • 永続キャッシュから削除する名前が含まれた CSV ファイルを含めます。
    • CSV ファイルのリストは引用符 (") で囲みます。
    • CSV ファイルの名前はセミコロン (;) で区切ります。
    • 各 CSV ファイルへのパスを含めます。
    例:
    /enterprise/ibm/tools/refresh_resolve_cache.sh "/downoads/refresh/users1.csv;/downoads/refresh/users2.csv;/downoads/refresh/users3.csv"
  5. Sametime サーバーを開始します。
  6. テレフォニーアプリケーションサーバーを起動します。

タスクの結果

CachedResolveRefreshUtility は .CSV ファイルを順次に処理します。.CSV ファイルに「ID」ヘッダーが含まれている場合、その .CSV ファイルにリストされたエントリは永続キャッシュから削除され、更新されたキャッシュが新しい永続ファイルにフラッシュされます。CachedResolveRefreshUtility で削除されたユーザー名を、後からテレフォニープレゼンスアダプタで解決する必要がある場合は、CachedResolve コンポーネントによって、これらの名前が Sametime サーバーに対して解決され、永続キャッシュに有効な名前が追加されます。

CSV ファイルに他のヘッダー (「RESOLVE」や「ORGANIZATION」名など) が含まれている場合、組織のディレクトリに大幅な変更が加えられており、キャッシュをクリーンアップする必要があることを示しています。ユーティリティによってメモリキャッシュがクリーンアップされ、空の永続キャッシュファイルが作成されます。この場合は、新しいキャッシュを初期化する必要があります。

加入者の追加

このセクションでは、ユーザーつまり加入者 を IBM Sametime Unified Telephony に追加する方法について説明します。

このタスクについて

加入者を追加する方法は 2 つあります。
  • LDAP ディレクトリから加入者データを抽出し、そのデータを Tivoli® Directory Integrator を使用して Sametime Unified Telephony にロードできます。 この方法は、大量の加入者を追加する場合に理想的です。 「Tivoli Directory Integrator を使用した加入者の追加」のセクションを参照してください。
  • また、Common Management Portal を使用して加入者を追加することもできます。 この方法は、インストール後にデプロイ済み環境をテストするため、少数の加入者を追加する場合に使用します。 "「加入者の管理」"のセクションを参照してください。

ID マッピングの使用可能化

IBM Sametime ユーザー ID がユーザーのメールアドレスではない場合、Sametime Unified テレフォニーアプリケーションサーバーの通信アダプタの構成で、ID マッピングを使用可能にする必要があります。例えば、Domino をユーザーディレクトリとして使用する場合、階層名が Sametime ユーザー ID のデフォルトになります。

このタスクについて
ID マッピングを使用可能にするには、Sametime Unified テレフォニーアプリケーションサーバーで以下の手順を実行します。
手順
  1. セキュアシェルセッションから、以下のコマンドを使用してフレームワークを停止します。
     /etc/init.d/framework stop
  2. /enterprise/ibm/sutbcomadapter.properties を編集し、STIEnableIDMapping 設定を true に変更します。
    STIEnableIDMapping=true
  3. /enterprise/ibm/sutbcomadapter.properties を保存して閉じます。
  4. フレームワークを再起動します。
    /etc/init.d/framework start

Tivoli Directory Integrator を使用した加入者の追加

IBM Sametime Unified Telephony 加入者およびそのデバイスは、会社の LDAP ディレクトリから、テレフォニーアプリケーションサーバーの加入者データベースにコピーする必要があります。 最初にすべての加入者、または加入者のサブセットを追加した後で、ディレクトリの変更に伴い自動的に加入者を更新できます。

このタスクについて
Sametime Unified Telephony をインストールおよび構成した後で、加入者の追加を開始できます。Sametime Unified Telephony は、Tivoli Directory Integrator (TDI) を使用してこれらの加入者を追加またはプロビジョニング します。プロビジョニングには 2 つのタイプがあります。
初期プロビジョニング

LDAP ディレクトリから加入者情報を抽出し、そのデータを Common Management Portal を使用してテレフォニーアプリケーションサーバーにインポートするために、初期プロビジョニングを実行します。 Sametime Unified Telephony では、加入者データを抽出し、適切にフォーマット設定された出力を作成する Tivoli Directory Integrator アセンブリ行が提供されます。

始める前に
加入者をプロビジョニングする前に、あらかじめテレフォニー制御サーバーとテレフォニーアプリケーションサーバーをインストールおよび構成しておく必要があります。 さらに LDAP ディレクトリへのアクセス権限が必要です。 テレフォニー制御サーバーには、以下のものが含まれている必要があります。
  • ビジネスグループ
  • 番号計画
  • デフォルトの機能プロファイル
  • オフィス番号
Tivoli Directory Integrator のインストールおよびプロビジョニングプロジェクトの実装

IBM Tivoli Directory Integrator (TDI) は、アプリケーションとディレクトリソース間の情報の同期および交換を行います。 これは、ソース LDAP システムから取得したユーザーを使ってテレフォニーアプリケーションサーバーに IBM Sametime Unified Telephony 加入者データベースの初期プロビジョニングを実行するために使用します。LDAP の変更に伴ってサーバーを最新に保つためにも使用します。

始める前に
TDI をインストールするマシンと、プロビジョニングプロジェクトのアセンブリ行では、テレフォニーアプリケーションサーバーと LDAP へのアクセス権限がなければなりません。 ./install.sh all コマンドを使用して Sametime Unified Telephony をインストールした場合には、この手順をスキップすることができます。 all オプションでは、TDI とプロビジョニングプロジェクトのアセンブリ行が組み込まれます。
./install.sh コマンドには、以下のオプションがあります。
  • ./install.sh all - TDI とプロビジョニングプロジェクトのアセンブリ行を含む、Sametime Unified Telephony のすべてをインストールします。
  • ./install.sh provisioning - TDI とプロビジョニングプロジェクトのアセンブリ行だけをインストールします。
  • ./install.sh tdi - TDI バージョン 6.1.1 だけをインストールします。
  • ./install.sh assemblyLines - プロビジョニングプロジェクトのアセンブリ行だけをインストールします。
このタスクについて
Tivoli Directory Integrator をインストールおよび構成するには、以下の手順に従います。
手順
  1. SSH クライアントを開き、root ユーザーとしてログインします。
  2. インストーラディレクトリから次のスクリプトを実行して、Tivoli Directory Integrator およびプロビジョニングプロジェクトのアセンブリ行をインストールします。
    ./install.sh provisioning
    注意:
    provisioning オプションを含めないときは、テレフォニーアプリケーションサーバーを再インストールすることになります。
    TDI は、/opt/IBM/tivoli/tdi/V6.1.1/ ディレクトリにインストールされます。このスクリプトでは、プロビジョニングプロジェクトを格納するソリューションディレクトリ /opt/IBM/Tivoli/tdi/solutions/ も作成されます。プロビジョニングに必要なすべてのスクリプトと構成ファイルは、プロジェクトディレクトリ /opt/IBM/tivoli/tdi/solutions/SUT/ にあります。
次のタスク
次に settings.xml ファイルを構成します。
設定の構成

加入者をプロビジョニングする前に、ソース LDAP の場所とグループ、出力 CSV ファイル名に関する詳細を指定することにより、settings.xml ファイルを変更する必要があります。 変更された settings.xml ファイルには、テレフォニーアプリケーションサーバーに必要な加入者データを作成するために必要な情報が格納されます。

始める前に
Tivoli Directory Integrator とプロビジョニングプロジェクトをインストールしておく必要があります。 ユーザープロビジョニング構成をインストールしている場合、設定ファイルは settings.xml.template という名前です。このファイルの名前を settings.xml に変更し、正しい情報を入力する必要があります。
このタスクについて
settings.xml ファイルには、以下の設定に関する詳細が格納されます。
  • LDAP 接続
  • 保守プロビジョニング用の SPML 接続設定
  • LDAP 検索フィルタ
  • 属性マッピング (これは別のトピックで解説します)
手順
  1. SSH クライアントを開き、root ユーザーとしてログインします。
  2. 次の SUT ディレクトリに移動します。
    cd /opt/IBM/tivoli/tdi/solutions/SUT/
  3. settings.xml ファイルを見つけます。
    ls settings.xml
  4. settings.xml を編集します。
    vi settings.xml
  5. プロビジョニングしている加入者が、入力 CSV ファイルと LDAP ディレクトリのどちらに含まれているかを指定します。 少数の加入者のプロビジョニングには、CSV ファイルが便利です。
    表 1.
    パラメータ 説明
    inputType LDAP ディレクトリから加入者をプロビジョニングしている場合には、ldap と入力する、または未指定のままにしておきます。 入力 CSV ファイルから加入者をプロビジョニングしている場合には、file と入力します。 file と入力する場合には、inputFilename パラメータも提供する必要があります。 また、inputType を LDIF として指定することもできます。 これにより、LDIF ファイルのインポートが可能になります。 LDIF ファイルには、LDAP からエクスポートされたデータが入ります。 inputFilename パラメータは、インポートする LDIF ファイルのロケーションと名前を指定します。 これは、SUT ディレクトリ (例えば、/opt/IBM/tivoli/tdi/solutions/SUT/) の相対ロケーションになります。値として data/users.ldif を指定した場合、構成は /opt/IBM/tivoli/tdi/solutions/SUT/data/users.ldif ファイルを開こうと試みます。 ldap
    inputFilename file または LDIFinputType パラメータに指定した場合は、ファイル名を提供する必要があります。

    サンプルの入力 CSV ファイル:
    cn;telnumber;mail;homePhone;voicemail;
    user1;+15555749601;user1@company.com;+15555769601;12035559601;
    user2;+15555749602;user2@company.com;+15555769602;12035559602;
    user3;+15555749603;user3@company.com;+15555769603;12035559603;
    user4;+15555749604;user4@company.com;+15555769604;12035559604;
    user5;+15555749605;user5@company.com;+15555769605;12035559605;

    属性名が最初の行にリ
    ストされています。
    これらの属性名は、
    LDAP 属性の場合
    と同様の方法で、
    settings.xml
    ファイルの属性マッ
    ピングで
    (type = "ldap"
    と指定することにより)
    参照できます。

  6. 設置場所に合わせた適切な値を使用して以下の出力ファイルと LDAP 接続のパラメータを変更します。
    パラメータ 説明 値の例
    名前 出力 CSV ファイルの名前を入力します。 これは、サブスクライバデータが含まれている CSV ファイルで、後ほどテレフォニーアプリケーションサーバーにインポートされます。 telephonyusers.csv
    Ldap ホスト名または IP アドレスと、ポート番号。 ldap://companydirectory.company.com:389
    ldapUsername LDAP 管理者のユーザー名を入力します。 ldapUsername と ldapPassword を両方ともブランクにすると、TDI 構成は匿名の認証を使用して LDAP に接続しようと試みます。 admin
    ldapPassword LDAP 管理者のパスワードを入力します。 ldapUsername と ldapPassword を両方ともブランクにすると、TDI 構成は匿名の認証を使用して LDAP に接続しようと試みます。  
  7. 設置場所に合わせた適切な値を使用して SPML 接続のパラメータを変更します。 ファイル内のこのパラメータセットは、おもに保守プロビジョニング用ですが、初期プロビジョニングを実行する前に設定する必要があります。

    SPML (Service Provisioning Markup Language) レスポンダは、LDAP ディレクトリ内で加入者が追加、削除、変更されたときに発生するプロビジョニングワークフローを自動化するための、プロビジョニング応答プロトコルです。 LDAP ディレクトリのテレフォニーグループ内でユーザーが追加または更新された場合、そのユーザーに関する情報を使ってテレフォニーアプリケーションサーバーの加入者データベースを更新する必要があります。 TDI プロビジョニングコードによって LDAP ディレクトリに更新がないかが検査され、この情報が SPML レスポンダを経由してテレフォニーアプリケーションサーバーにインポートされます。 テレフォニーグループ内で新規ユーザーが検出されたか、または既存ユーザーの属性が変更された場合、加入者を IBM Sametime Unified Telephony にプロビジョニングするワークフローが開始されます。

    settings.xml ファイルには、複数の Setting ブロックがあります。インストールプロセスの一環として、常駐テレフォニーアプリケーションサーバーの SPML URL、ユーザー名、パスワードがブランクの Setting ブロックに自動的に入力されます。

    注: 初期プロビジョニングプロセスでは、一部の属性データをテレフォニーアプリケーションサーバーから取得するために、SPML インターフェースへの接続も使用されます。
    パラメータ 説明 値の例
    spmlURL SPML レスポンダの URL を入力します。 http://nnn.nnn.nnn.nnn。 ここで nnn.nnn.nnn.nnn はテレフォニーアプリケーションサーバーが稼働するマシンの IP アドレスです。
    spmlUsername SPML インターフェースにアクセスするための認証ユーザー名を入力します。 テレフォニーアプリケーションサーバー管理者のユーザー名で十分です。 administrator@system
    spmlPassword テレフォニーアプリケーションサーバーの SPML インターフェースにアクセスするための認証パスワードを入力します。 これはテレフォニーアプリケーションサーバー管理者のパスワードで十分です。  
  8. 設置場所に合わせた適切な値を使用して LDAP 検索フィルタのパラメータを変更します。
    パラメータ 説明 値の例
    searchBase 検索対象の組織を入力します。 o=ibm.com
    searchFilter LDAP 内でテレフォニーユーザーを見つけるためのフィルタを入力します (ユーザーまたはグループ)。

    ユーザーの場合:
    objectClass=ePerson
    グループの場合:
    cn=Group1
    複数のグループの場合:
    (|(cn=Group1)(cn=Group2))

    isGroup プロビジョニングで 1 つのグループからユーザーを収集するかどうかを指定します。 true に設定したときは、プロビジョニングで searchFilter グループが繰り返し使用されます。groupSearchFilter はブランクでも構いません。 false に設定したときは、検索フィルタの内容を使用してユーザーが検索されます。  
    groupSearchFilter isGroup を true に設定している場合、ここで検索フィルタを指定して、searchFilter で指定したグループから一部のユーザーのみを取得できます。 c=ireland にすると、そのグループからアイルランド出身の人が検索されます。 そのグループに属するすべての人を検索するときには、groupSearchFilter を空にしておきます。
次のタスク
settings.xml ファイルの属性マッピングセクションを編集して、settings.xml ファイル構成を完成させます。
複数のテレフォニーアプリケーションサーバー用の settings.xml 例

以下の例は、複数のテレフォニーアプリケーションサーバーをプロビジョニングするよう構成された settings.xml ファイルを示しています。

IBM Sametime Telephony デプロイ済み環境に複数のテレフォニーアプリケーションサーバーがある場合、1 つの settings.xml で複数のテレフォニーアプリケーションサーバーをプロビジョニングする必要があります。 そのファイル内に、各サーバー独自の設定セクションが必要です。 各サーバーは固有の LDAP または LDAP グループ、および固有の出力ファイル名を使用して構成されます。 固有のオフィス番号とビジネスグループの値もサーバーごとに必要となる場合があります。
次の例では、2 つのテレフォニーアプリケーションサーバーをプロビジョニングします。 それぞれに固有の .CSV 出力ファイルおよび LDAP ディレクトリがあります。
<?xml version="1.0" encoding="UTF-8"?>

<!-- The following <Setting> blocks will produce 2 csv files, one per TAS -->
<ProvisioningSettings>
<Setting>
<Name>TAS_1.csv</Name>
<inputType>file</inputType>
<inputFilename>userDetails.csv</inputFilename>

<spmlPassword>seCret*123</spmlPassword>
<spmlUsername>administrator@system</spmlUsername>
<spmlURL>http://sut-tas01.company.com</spmlURL>

<attribute-mappings>
<mapping attribute="unifiedNumber" type="ldap">telephoneNumber</mapping>
<mapping attribute="officeCodeLength" type="string">7</mapping>
<mapping attribute="assignedBusinessGroup" type="string">BG_1</mapping>
<mapping attribute="featureProfile" type="string">FP_1</mapping>
<mapping attribute="numberingPlan" type="string">NP_1</mapping>
<mapping attribute="rateAreaID" type="string">ra_1</mapping>
<mapping attribute="phoneLanguage" type="string">English</mapping>
<mapping attribute="assignedBCFederation" type="string">TAS Node - Small Deployment</mapping>
<mapping attribute="userId" type="ldap">mail</mapping>
<mapping attribute="displayName" type="ldap">cn</mapping>
<mapping attribute="homeTimeZone" type="string">Europe/Dublin</mapping>
<mapping attribute="defaultLocale" type="string">en_GB</mapping>
<mapping attribute="password" type="string">seCret*456</mapping>
<mapping attribute="assignedVoicemail" type="script">voicemail.js</mapping>
<mapping attribute="softphonePrefix" type="string">00</mapping>
<mapping attribute="softphoneLabel" type="string">Sametime Computer Phone</mapping>
</attribute-mappings>

<Setting>
<Name>TAS_2.csv</Name>
<ldap>ldap://directory.company.com:389</ldap>
<ldapPassword></ldapPassword>
<ldapUsername></ldapUsername>
<searchBase>o=company.com</searchBase>
<searchFilter>cn=TAS2_Group</searchFilter>
<isGroup>true</isGroup>
<groupSearchFilter></groupSearchFilter>
<spmlPassword>seCret*678</spmlPassword>
<spmlUsername>administrator@system</spmlUsername>
<spmlURL>http://sut-tas02.company.com</spmlURL>

<attribute-mappings>
<mapping attribute="extension"type="script"> extension.js</mapping>
<mapping attribute="assignedOfficeCode" type="string">1555789</mapping>
<mapping attribute="uniqueEntry" type="ldap">uniquemember</mapping>
<mapping attribute="assignedBusinessGroup" type="string">BG_2</mapping>
<mapping attribute="featureProfile" type="string">FP_2</mapping>
<mapping attribute="numberingPlan" type="string">np_bg_2</mapping>
<mapping attribute="rateAreaID" type="string">ra_2</mapping>
<mapping attribute="phoneLanguage" type="string">French</mapping>
<mapping attribute="assignedBCFederation" type="string">TAS Node - Small Deployment</mapping>
<mapping attribute="userId" type="ldap">mail</mapping>
<mapping attribute="displayName" type="ldap">cn</mapping>
<mapping attribute="homeTimeZone" type="string">Europe/Dublin</mapping>
<mapping attribute="defaultLocale" type="string">en_GB</mapping>
<mapping attribute="password" type="string">Sup*rSecr3t</mapping>
<mapping attribute="assignedVoiceMail" type="ldap">Voicemail</mapping>
<mapping attribute="deskphone" type="ldap">deskTelNum</mapping>
<mapping attribute="softphonePrefix" type="string">00</mapping>
</attribute-mappings>
</Setting>

</ProvisioningSettings>
settings.xml の属性マッピングセクションの構成

settings.xml ファイルの属性マッピングセクションで、LDAP ユーザー属性を Sametime テレフォニー加入者データベースの属性にマップする必要があります。 Tivoli Directory Integrator はこのセクションの情報を使用して、出力 CSV ファイルを作成します。

始める前に
opt/IBM/tivoli/tdi/solutions/SUT/ にある settings.xml.template ファイルの名前を settings.xml に変更し、ファイルの LDAP 接続、SPML 接続、LDAP 検索フィルタの各セクションを入力しておきます。
このタスクについて
テレフォニーアプリケーションサーバーに加入者をプロビジョニングすると、表示名、ユーザー ID、ドメイン、統一番号といった、必要な属性が渡されます。 属性マッピングセクションで、入力属性と出力属性の間の適切なマッピングを指定します。
手順
  1. settings.xml ファイルの属性マッピングセクションまでスクロールダウンします。
  2. 入力属性を出力属性に一致させます。 各行は次の形式です。
    <mapping attribute = “attributeName” type = “attributeType” >Value</mapping>
    AttributeName は出力属性の名前です。 AttributeType は実行されるマッピングのタイプです。 Value はストリング、LDAP 属性名、スクリプト名です。 マッピングには次の 3 つのタイプがあります。
    • LDAP 属性 テレフォニー属性ごとにユーザーの LDAP 属性の名前を入力すると、その属性の最初の値がテレフォニー属性に割り当てられます。
      <mapping attribute="displayName" type="ldap">cn</attribute>
    • ストリング テレフォニー属性ごとにストリングを引用符で囲んで入力すると、そのストリングが割り当てられます。 次の例では、ストリング「system」が、すべてのユーザーのドメイン属性に割り当てられます。
      <mapping attribute name=domain type=string>system</mapping> 
    • スクリプト テレフォニー属性ごとにスクリプトの名前を入力すると、各ユーザーに対してスクリプトが実行され、戻り値がテレフォニー属性に割り当てられます。 ソース属性とテレフォニー属性の間に直接の 1 対 1 マッピングが存在しないときは、スクリプトを作成してください。 スクリプトの定義が必要ですが、サンプルが opt/IBM/tivoli/tdi/solutions/SUT/scripts/ ディレクトリに用意されています。
      <mapping attribute="extension" type="script">extension.js</attribute>
      次のようなスクリプトを参照する場合、
      "<mapping attribute="assignedVoicemail" type="script">voicemail.js</attribute>
      そのスクリプトは opt/IBM/tivoli/tdi/solutions/SUT/scripts/ に配置する必要があります。

      これらのスクリプトのいずれかでファイルシステムファイル (たとえば data.dat) を使用し、このファイルを opt/IBM/tivoli/tdi/solutions/SUT/ ディレクトリに配置している場合、スクリプトで、このファイルを SUT/data.dat として参照する必要があります。なぜなら、ソリューションディレクトリ (作業ディレクトリ) が opt/IBM/tivoli/tdi/solutions/ だからです。

次のタスク
初期プロビジョニングを実行します。
属性マッピング

このトピックでは、settings.xml ファイル内の Setting ブロックの属性マッピングセクションにあるすべての属性をリストします。

テレフォニーアプリケーションサーバーの属性 必須か ? 説明
unifiedNumber 必須 ユーザーの統一番号。この属性は officeCodeLength 属性と共に、番号のオフィス番号を派生するために使用します。統一番号は、「assignedOfficeCode」属性と「extension」属性を使用して指定することもできます。
officeCodeLength   統一番号のオフィス番号の長さ (桁数)。「unifiedNumber」属性を使用して統一番号を指定している場合、この属性は必須です。
softphonePrefix   この値が指定された場合には、ユーザーに新しい AllocatedDevice が作成されます。それは、UnifiedNumber 値の前に softphonePrefix 値を付けて形成されます。 このデバイスは Sametime コンピュータ電話に対応します (Sametime ソフトフォン)。
extension   ユーザーの統一番号の内線 (例えば、下 4 桁)。extension と assignedOfficeCode 属性が入力されていないか、空ストリングになっている場合には、unifiedNumber (officecode + extension) を使用して自動的にそれらの値が最終的な csv ファイルに入力されます。
assignedOfficeCode   ユーザーの統一番号のオフィス番号。 すべての電話オブジェクトには、officecode で始まる番号 (統一番号) が必要です。 たとえばオフィス番号が「1555678」であるときには、統一番号の形式は「1555678xxxx」とする必要があります。 extension と assignedOfficeCode 属性が入力されていないか、空ストリングになっている場合には、unifiedNumber (officecode + extension) を使用して自動的にそれらの値が最終的な csv ファイルに入力されます。
assignedBCFederation 必須 テレフォニーアプリケーションサーバーに属するフェデレーションの名前。 フェデレーションは、Common Management Portal の [Operation & Maintenance] > [Configuration & Monitoring] > [Overview] > [System Status] でリストされます。 例えば、「TAS Node - Small Deployment」。
assignedCommunicationSystem   通信システムは、テレフォニーアプリケーションサーバーとテレフォニー制御サーバーの間の CSTA リンクです。 この値が settings.xml で設定されていないときは、テレフォニーアプリケーションサーバーから取り込まれます (提供された SPML 資格情報および URL によって指定される)。 この値を取得するには、テレフォニーアプリケーションサーバーから CSV ファイルをエクスポートするという方法があります。 Common Management Portal にログインし、 [Operations and Maintenance] > [Recovery] > [Export] に進みます。 [Domain Management] を選択して、[Export] をクリックします。
userId 必須 ユーザーの Sametime ログイン ID。「@」記号は許可されず、自動的に「#」記号に変換されます。
displayName 必須 表示されるユーザー名。
softphoneLabel   コンピュータ電話に対応する、自動的に生成される AllocatedPhone の表示名を指定します。 この属性が指定されない場合には、コンピュータ電話の番号が表示名として使用されます。
    ユーザーの Common Management Portal パスワード。 Common Management Portal 内のすべてのユーザーにデフォルトのパスワードが与えられているのでなければ、これを定義してください。 ユーザーが Common Management Portal にログインすることが全くない場合でも、ユーザーはパスワードセットを持つ必要があります。 パスワードは、少なくとも 8 文字の長さで、少なくとも 1 つの特殊文字が必要です。
homeTimeZone 必須 ユーザーの初期タイムゾーン。 この属性は homeTimeZone と currentTimeZone の両方の属性を設定します。 これは zoneinfo 形式、すなわち olson または tz でなければなりません。 例えば、America/New_York です。
defaultLocale 必須 この属性は、allowedLocales のリストと照らし合わせて検査されます。 そのリストは、config フォルダ内の validation.properties ファイルの中の supportedLocales プロパティに指定されます。 指定されたロケールがリストにない場合には、プロビジョニングプロセスが打ち切りになります。 新しいロケールをリストに追加できます。 defaultLocale プロパティの構文は languageCode_countryCode に従う必要があります。ここで、languageCode は ISO 639-1 に準拠し、countryCode は ISO 3166-1 に準拠します。
rateAreaID   ユーザーの統一番号のレートエリア ID。 この属性の値はルーティングエリアに対応します。 使用可能なルーティングエリアは、Common Management Portal 内の [Telephony Control Server] > [Global Translation & Routing] > [Translation] > [Routing Areas] でリストされます。
phoneLanguage 必須 これは、Common Management Portal の [Telephony Control Server] > [Adminitration] > [Languages] で選択された言語に対応します。 プロビジョニング "config" フォルダに、プロパティファイルがあります。 それには、supportedPhoneLanguages というプロパティが含まれています。 このプロパティには、phoneLanguage 属性に設定できる、許可される言語のリストが含まれています。 このリストに含まれていない phoneLanguage 値を選択した場合、プロビジョニングプロセスは中止されます。新規の言語を組み込むためにプロパティを付加することができます。 追加した言語がいずれも Common Management Portal でサポートされていることを確認してください。
deskPhone 必須 ユーザーのデスクまたはオフィスの電話。 この番号は AllocatedPhone オブジェクトの番号に対応します。 指定される番号は CallForwardingDependable Target および PreferredDeviceAndTarget 属性に使用されます (それらの属性が明示的に定義されていない場合)。
deskPhoneLabel   deskPhone AllocatedPhone オブジェクトの displayName 属性を指定します。
preferredDeviceAndTarget   ユーザーの初期優先デバイス。 ブランクの場合 (推奨)、優先デバイスは device1 の値になります。 GNF 番号または番号自体ではなく、デバイスの ID を指定する必要があります。
callForwardingDependable Target   テレフォニーアプリケーションサーバーに障害が発生したときにコールされるデフォルトの番号。 これがブランクの場合 (推奨)、ディペンダブルターゲットは device1 の値です。番号自体ではなく、デバイスの ID を指定する必要があります。
assignedCallQueue   ユーザーに割り当てられたコールキューの番号。
assignedVoicemail 必須 ユーザーのボイスメール番号。 各ユーザーにボイスメール番号が必要です。
assignedBusinessGroup 必須 ビジネスグループ。番号がその一部に含まれます。 例えば「BG_SUT_01」です。ビジネスグループは、Common Management Portal の [Telephony Control Server] > [Business Groups] で参照できます。
domain   ユーザーとユーザーに属するオブジェクトのドメイン。 たとえば「system」。 この値が settings.xml で設定されていないときは、テレフォニーアプリケーションサーバーから取り込まれます (提供された SPML 資格情報および URL によって指定される)。 この値を取得するには、テレフォニーアプリケーションサーバーから CSV ファイルをエクスポートするという方法があります。 Common Management Portal にログインし、 [Operations and Maintenance] > [Recovery] > [Export] に進みます。 [Domain Management] を選択して、[Export] をクリックします。
uniqueEntry ユーザーを LDAP グループから取得する場合は必須です。 グループを繰り返し使用するために使用される、LDAP グループに属する属性。 これは常に「ldap」タイプでなければなりません。 例:「uniquemember」。
deviceX

ここで、X は 1 から 5 の番号です。例えば、device1、device2、device3 などで、device5 まで続きます。

  ユーザーごとに、最大 5 つの割り当てられた電話デバイスを追加でプロビジョンできます。
deviceXLabel

ここで、X は 1 から 5 の番号です。例えば、device1Label、device2Label、device3Label などで、device5Label まで続きます。

  deviceX 属性の表示名。この値は、その AllocatedPhone の displayName 属性になります。 ラベルが指定されない場合は、電話の番号がその displayName 属性として使用されます。
numberingPlan 必須 番号計画の名前。統一番号がその一部に含まれます。 これは Common Management Portal の [Telephony Control Server] > [Business Groups] にあります。
featureProfile 必須 ビジネスグループに割り当てられた機能プロファイル。 これは Common Management Portal の [Telephony Control Server] > [Business Groups] > [BG オプション (BG Options)] > [機能プロファイル (Feature Profiles)] にあります。 メインスクリーンに表示される名前を使用します。
classOfService   ユーザーの統一番号のダイヤル許可をセットアップするための属性。例: 「National」
displayedExtension   この属性は、ユーザーの統一番号のプライベートダイヤル計画フォーマットを指定する diversion ヘッダーを上書きします。これによって、ボイスメールシステムは転送されたコールのターゲットメールボックスを識別できるようになります。
スクリプトと属性マップ

特定の属性に必要な正確なデータを取得できない場合、JavaScript ファイルを作成して値を判別できます。このファイルの名前は、settings.xml ファイルで、その属性のマッピング定義で参照されます。

JavaScript ファイル内で、ソース属性の値に基づいて特定の値を返すロジックを作成できます。 JavaScript ファイルは /opt/IBM/tivoli/tdi/solutions/SUT/scripts/ ディレクトリに配置する必要があります。 カスタム JavaScript ファイルを作成するときは、必ず戻り値をスクリプトの最後に含めてください。 データソースからのデータ取得に役立つ以下の特殊関数を使用できます。

  • retrieveAttribute(attributeName) データソースから、指定した属性の最初の値を返します。
  • retrieveAttributeArray(attributeName) データソースから、指定した属性のすべての値が入った JavaScript 配列を返します。

サンプルのスクリプトが opt/IBM/tivoli/tdi/solutions/SUT/scripts/ に用意されています。

サンプルスクリプト
ユーザーの国を知っている場合には、以下の homeTimeZone.js のようなスクリプトを使用できますが、homeTimeZone 属性には Zoneinfo 値が必要です。 以下のスクリプトでは、国を確認して、該当するロケールの詳細を返します。
var country = retrieveAttribute("c");

var returnVal = "Europe/London";

     if(country=="Ireland"){returnVal = "Europe/Dublin";}
else	if(country=="China")   {returnVal = "Asia/Shanghai";}
else	if(country=="France")  {returnVal = "Europe/Paris";}
else	if(country=="US")      {returnVal = "America/New_York";}

return returnVal;
初期プロビジョニングプロセスの実行

初期プロビジョニングプロセスを実行して、加入者データの出力 CSV ファイルを作成する必要があります。

始める前に
settings.xml ファイルをあらかじめ構成しておく必要があります。
このタスクについて
初期プロビジョニングプロセスでは、UserProvisioning.xml という Tivoli Directory Integrator アセンブリ行ファイルが使用されます。これは TDI ディレクトリにあります。
手順
  1. SSH クライアントを開きます。
  2. TDI とプロビジョニングプロジェクトをインストールしたテレフォニーアプリケーションサーバーのマシンに、root ユーザーとしてログインします。
  3. 次のディレクトリに移動します。
    /opt/IBM/tivoli/tdi/solutions/SUT/
  4. 次のコマンドを入力して、TDI アセンブリ行を実行します。
    initial.sh

    このコマンドにより、出力ディレクトリに CSV ファイルが作成されます。作成された CSV ファイルの名前は settings.xml file の「Name」設定から取られます。

次のタスク
次に、作成された CSV ファイルを Sametime サブスクライバデータベースにインポートする必要があります。
CSV 出力ファイルのインポート

Tivoli Directory Integrator を使用して作成した加入者データの CSV ファイルを、IBM Sametime テレフォニー加入者データベースにインポートします。

始める前に
加入者情報が格納された output_file_name.csv ファイルをあらかじめ作成しておく必要があります。
手順
  1. CSV ファイルを作成したマシンでブラウザを開き、Common Management Portal のアドレスを入力します。
    https://Server_IP:port/management/
    ここで、Server_IP:port は Common Management Portal サーバーとポート番号です。
  2. [Operation & Maintenance] > [Recovery] > [インポートとエクスポート (Import & Export)] > [Import] をクリックします。
  3. [Browse] をクリックし、output_file_name.csv ファイルを見つけて、[Next] をクリックします。
    注: このファイル名は settings.xml ファイルの「Name」設定で定義したものです。
  4. 次のページで、以下の設定を確認します。
    • [Type of file to be imported]Common Management Portal に設定されていること。
    • [Included type of data]Domain Management に設定されていること。
    次に、[Import] をクリックします。
保守プロビジョニングの実行

保守プロビジョニングを定期的に実行することにより、テレフォニーアプリケーションサーバーの加入者レコードを更新し、それらと LDAP データの同期を保つことができます。 保守プロビジョニングを実行すると、新規加入者が追加され、不要になった加入者が削除され、既存の加入者に関する情報が最新に保たれます。

始める前に
始める前に、settings.xml ファイルの SPML 接続セクションを入力する必要があります。
このタスクについて
初期プロビジョニング以降、または最後に保守プロビジョニングを実行した後に生じた変更内容に関して、IBM Sametime テレフォニーユーザーデータベースを手動で更新するには、以下の指示に従ってください。
手順
  1. SSH クライアントを開きます。
  2. プロビジョニングプロジェクトがインストールされているテレフォニーアプリケーションサーバーに、root ユーザーとしてログインします。
  3. Tivoli Directory Integrator ソリューションディレクトリにナビゲートして、settngs.xml ファイルを見つけます。
    /opt/IBM/tivoli/tdi/solutions/SUT/settings.xml
  4. SPML の詳細が正確であることを確認します。
  5. 加入者の初期プロビジョニング以降、初めてユーザー保守を実行した場合には、-reset オプションを付けて保守シェルスクリプトを実行します。

    リセットすると、TDI の内部ストレージがテレフォニーアプリケーションサーバーの現在の状況と同期されます。 この時に既存の加入者の初期スナップショットが取られるので、既存の加入者の再プロビジョニングを回避できます。

    以下のコマンドを実行します。

    /opt/IBM/tivoli/tdi/solutions/SUT/maintenance.sh -reset
  6. 以下のコマンドを実行して保守プロビジョニングを実行し、[OK] をクリックします。
    /opt/IBM/tivoli/tdi/solutions/SUT/maintenance.sh

    この手順では、TDI の内部ストレージに格納されている現在のスナップショットを、LDAP から取得した新たに照会されたユーザーと比較し、テレフォニーアプリケーションサーバー上で実行されている SPML レスポンダに変更を通知します。

    保守プロビジョニングは、crontab ファイルを編集して適当なスケジュールを追加することにより、スケジュールに合わせて実行することもできます。

    1. 次のコマンドを入力して、crontab ファイルをエディタで開きます。
      crontab -e
    2. 適当なスケジュールを追加します。 以下の例では、保守プロビジョニングが月曜日から金曜日までの真夜中に実行されます。
      00 00 * * 1-5 /opt/IBM/tivoli/tdi/solutions/SUT/maintenance.sh > /opt/IBM/tivoli/tdi/solutions/SUT/logs/cron.log 2>&1
      この場合
      • 00 は分です
      • 00 は時です
      • * は日付です
      • * は月です
      • 1–5 は曜日です

セキュリティの管理

このセクションでは、IBM Sametime Unified Telephony コミュニティのためのセキュア通信をセットアップする手順を示します。

このタスクについて

Secure Sockets Layer (SSL) は Sametime Unified Telephony に、暗号化された通信を提供します。SSL プロトコルは、認証性、データ署名、データ暗号化を含むトランスポート層セキュリティを提供して、クライアントとサーバーの間の通信を保護します。 SSL の基本となるテクノロジは公開鍵暗号方式です。この方式は、あるエンティティが公開鍵を使用してデータを暗号化する場合に、それに対応する秘密鍵を持つエンティティだけがそのデータを暗号化解除できることを保証します。

通信と鍵の保護についての詳細、および証明書のインポート、作成、置き換えに関する完全な資料については、WebSphere Application Server インフォメーションセンターの「SSL による情報の保護 (Securing information using SSL)」を参照してください。

クラスタ管理とフェイルオーバーサポートに Tivoli System Automation for Multiplatforms (SAMP) を使用する場合には、仮想ホスト情報に基づいてホストに関連付けられた、デジタル署名された証明書を作成する必要があります。 通常は、マシン上のネットワークインターフェースに、実 ネットワークカード (eth0) と、ローカルホスト (lo) があります。Tivoli SAMP をインストールすると、第 3 のネットワークインターフェースが作成されます。 この仮想 ネットワークインターフェースは eth0:0 です。したがって、証明書を作成するときには、仮想 ホスト情報 (IP アドレスまたはホスト名) を使用してそれを行う必要があります。そうすれば、スタンバイノードへのサーバーのフェイルオーバーが起こったとしても、証明書は依然として有効です。 さらに、証明書を作成してそれを WebSphere® Application Server に適用するときには、テレフォニーアプリケーションサーバーの JRE 鍵ストアを更新する必要があります。 テレフォニーアプリケーションサーバーと WebSphere Application Server 間の信頼関係を再確立するために、鍵ストア内の新しい別名によって証明書を置き換えてください。 以下のタスクでは、仮想ホスト名または IP アドレスが入った新しい別名として、virtualinfo という別名を使用します。

注: 自己署名証明書を作成する場合は、以下の手順のうち、「認証局によって署名された証明書の要求」および「要求された証明書の受け取り」をスキップし、残りのタスクを実行することができます。認証局によって署名された証明書を使用する場合は、以下の手順のうち、「認証局によって署名された証明書の要求」から開始し、残りのタスクを完了させてください。

自己署名証明書の作成

Secure Sockets Layer (SSL) 通信を確保するために、サーバーは署名付き証明書を必要とします。 自己署名証明書を作成するか、証明書をインポートできます。 WebSphere Application Server は、実行時にハンドシェークプロトコルで証明書を使用します。 このタスクでは、自己署名証明書の作成方法について説明します。

始める前に
鍵ストアが既に存在していなければなりません。 WebSphere Application Server では、自己署名証明書はデフォルトの鍵ストアに置かれます。
このタスクについて
以下のタスクを IBM WebSphere Integrated Solutions Console で実行します。

通信と鍵の保護についての詳細、および証明書の要求、作成、置き換えに関する完全な資料については、WebSphere Application Server インフォメーションセンターの「SSL による情報の保護 (Securing information using SSL)」を参照してください。

手順
  1. [セキュリティ] > [SSL 証明書および鍵管理 (SSL certificate and key management)] をクリックします。
  2. [関連項目] で、[鍵ストアおよび証明書 (Key stores and certificates)] をクリックします。
  3. NodeDefaultKeyStore をクリックします。
  4. [追加プロパティ] で、[個人証明書 (Personal certificates)] をクリックします。
  5. [自己署名証明書の作成 (Create self-signed certificates)] をクリックします。
  6. [別名 (Alias)] フィールドに、別名 virtualinfo を入力します。

    別名は、鍵ストア内で認証要求を識別するために使用する名前です。

  7. 共通名 (CN) 値を入力します。

    CN 値は、Tivoli System Automation for Multiplatforms によって作成された仮想ネットワークインターフェースに関連付けられた仮想ホスト名または IP アドレスです。eth0:0 としてリストされます。 この情報が含まれていれば、サーバーのフェイルオーバーが起こったとしても、証明書は依然として有効です。

  8. [組織] フィールドに組織名を入力します。

    この値は、証明書の識別名における「組織」値です。

  9. [組織単位] フィールドに、識別名の「組織ユニット」の部分を入力します。
  10. [市町村] フィールドに、識別名の「市町村」の部分を入力します。
  11. [都道府県] フィールドに、識別名の「都道府県」の部分を入力します。
  12. [郵便番号] フィールドに、識別名の「郵便番号」の部分を入力します。
  13. [国または地域] ドロップダウンリストで、識別名の 2 文字の「国別コード」の部分を選択します。
  14. [OK] をクリックします。
次のタスク
これで、古い証明書をこの新しいものと交換できるようになりました。 「メッセージングプロパティファイルの変更」の説明に従って、メッセージングプロパティファイル内の別名を更新してください。

認証局の署名付きの証明書の要求

Secure Sockets Layer (SSL) 通信を確保するために、サーバーは署名付き証明書を必要とします。 自己署名証明書を作成するか、認証局 (CA) によって署名された証明書を要求できます。WebSphere Application Server は、実行時にハンドシェークプロトコルで証明書を使用します。このタスクでは、証明書の要求方法について説明します。

始める前に
個人証明書要求を含む鍵ストアが既に存在している必要があります。
このタスクについて
IBM WebSphere Integrated Solutions Console で、以下のタスクを実行してください。

通信と鍵の保護についての詳細、および証明書の要求、作成、置き換えに関する完全な資料については、WebSphere Application Server インフォメーションセンターの「SSL による情報の保護 (Securing information using SSL)」を参照してください。

手順
  1. [セキュリティー] > [SSL 証明書および鍵管理] > [関連項目] > [鍵ストアおよび証明書] > [NodeDefaultKeyStore]をクリックします。
  2. [追加プロパティー] で [個人証明書要求] をクリックします。
  3. [新規] をクリックします。
  4. [認証要求のファイル] フィールドで、認証要求が保管される場所の絶対パスと、ファイル名を入力します。

    例: /servercertreq.cer

  5. [鍵ラベル (Key label)] フィールドに、別名 virtualinfo を入力します。

    別名は、鍵ストア内で認証要求を識別するために使用する名前です。

  6. 共通名 (CN) 値を入力します。

    CN 値は、Tivoli System Automation for Multiplatforms によって作成された仮想ネットワークインターフェースに関連付けられた仮想ホスト名または IP アドレスです。eth0:0 としてリストされます。この情報が含まれていれば、サーバーのフェイルオーバーが起こったとしても、証明書は依然として有効です。

  7. [組織] フィールドに組織名を入力します。

    この値は、証明書の識別名における「組織」値です。

  8. [組織単位] フィールドに、識別名の「組織ユニット」の部分を入力します。
  9. [市町村] フィールドに、識別名の「市町村」の部分を入力します。
  10. [都道府県] フィールドに、識別名の「都道府県」の部分を入力します。
  11. [郵便番号] フィールドに、識別名の「郵便番号」の部分を入力します。
  12. [国または地域] ドロップダウンリストで、識別名の 2 文字の「国別コード」の部分を選択します。
  13. [OK] をクリックします。

    認証要求は、鍵ストアの指定されたファイルロケーションで作成されます。この要求は、手動で鍵ストア内に証明書を受け取るまでは、署名付き証明書の一時プレースホルダの役目を果たします。

    注: 鍵ストアツール (iKeyman および keyTool など) は、WebSphere Application Server の証明書要求によって生成された署名付き証明書を受信できません。同様に、WebSphere Application Server は、他の鍵ストアユーティリティの証明書要求で生成された証明書を受信できません。
  14. 署名を得るために認証要求ファイルを認証局に送信します。
  15. 鍵ストアファイルのバックアップコピーを作成します。このバックアップは、CA 署名付き証明書を鍵ストアで受信する前に作成してください。鍵ストアの場所のパス情報は、Integrated Solutions Console で知ることができます。
次のタスク
これで、鍵ストア内に CA 署名証明書を受け取って、サーバー用の署名付き証明書の生成処理を完了できるようになりました。

要求された証明書の受け取り

認証局 (CA) は認証要求を受け取ると、CA 発行の証明書の一時プレースホルダの役目を果たす新しい証明書を発行します。 鍵ストアは CA から証明書を受け取り、WebSphere Application Server が Secure Sockets Layer (SSL) セキュリティに使用できる CA 署名個人証明書を生成します。自己署名証明書を作成済みの場合は、このタスクをスキップできます。

始める前に
鍵ストアには、作成されて CA に送信された認証要求が含まれていなければなりません。 また、鍵ストアは CA から返された証明書にアクセスできなければなりません。
このタスクについて

通信と鍵の保護についての詳細、および証明書の要求、作成、置き換えに関する完全な資料については、WebSphere Application Server インフォメーションセンターの「SSL による情報の保護 (Securing information using SSL)」を参照してください。

手順
  1. [セキュリティ] > [SSL 証明書および鍵管理 (SSL certificate and key management)] をクリックします。
  2. [関連項目] で、[鍵ストアおよび証明書 (Key stores and certificates)] をクリックします。
  3. NodeDefaultKeyStore をクリックします。
  4. [追加プロパティ] で、[個人証明書 (Personal certificates)] をクリックします。
  5. [認証局から証明書を受信] をクリックします。 証明書には、Tivoli System Automation for Multiplatforms によって作成された仮想ネットワークインターフェースに関連付けられた仮想ホスト名または IP アドレスが含まれていなければなりません。この情報が含まれていれば、サーバーのフェイルオーバーが起こったとしても、証明書は依然として有効です。
  6. 証明書が含まれる鍵ストアファイルの完全修飾パスを入力します。
  7. リストからデフォルトのデータ型を選択します。
  8. [OK] をクリックします。
次のタスク
これで、テレフォニーアプリケーションサーバーの鍵ストアに、この証明書を追加できるようになりました。

証明書の置き換え

NodeDefaultKeyStore 内のこれまでの証明書を、受け取ったものまたは作成したものに置き換えます。

始める前に
自己署名証明書を作成するか、認証局から証明書を受け取ります。
手順
  1. [セキュリティ] > [SSL 証明書および鍵管理 (SSL certificate and key management)] をクリックします。
  2. [関連項目] で、[鍵ストアおよび証明書 (Key stores and certificates)] をクリックします。
  3. NodeDefaultKeyStore をクリックします。
  4. [追加プロパティ] で、[個人証明書 (Personal certificates)] をクリックします。
  5. SUT 証明書を選択し、[置換 (Replace)] をクリックします。
  6. [置換 (Replace)] フィールドで virtualinfo を選択します。
  7. [古い証明書の削除] を選択します。構成内で証明書別名が出現する部分がすべて、新しい証明書別名に置き換わります。
  8. [古い署名者の削除] を選択します。これまでの署名者証明書が出現する部分がすべて、新しい署名者証明書に置き換えられます。
  9. [OK] をクリックします。
次のタスク
テレフォニーアプリケーションサーバーの鍵ストアに証明書を追加します。

テレフォニーアプリケーションサーバーの鍵ストアに証明書を追加する

デフォルトの鍵ストアから virtualinfo 証明書を抽出し、テレフォニーアプリケーションサーバーの鍵ストアに追加します。

始める前に
既に認証局から署名付き証明書を受け取っている、または自己署名証明書を作成済みでなければなりません。
このタスクについて
テレフォニーアプリケーションサーバーと WebSphere Application Server 間の信頼関係を確立するには、テレフォニーアプリケーションサーバー JVM に関連付けられた鍵ストアを更新する必要があります。
手順
  1. [セキュリティ] > [SSL 証明書および鍵管理 (SSL certificate and key management)] をクリックします。
  2. [関連項目] で、[鍵ストアおよび証明書 (Key stores and certificates)] をクリックします。
  3. NodeDefaultKeyStoreTASDefaultKeyStore を選択します。
  4. [署名者の交換 (Exchange signers)] をクリックします。
  5. [NodeDefaultKeyStore] ボックスで virtualinfo 証明書を選択し、[追加] をクリックします。 証明書が TASDefaultKeyStore に追加されます。
  6. [OK] をクリックします。
次のタスク
メッセージングサービスプロパティファイルを更新します。

メッセージングプロパティファイルの変更

テレフォニーアプリケーションサーバーの鍵ストアで証明書別名を default から変更した場合、メッセージングプロパティを変更する必要があります。

始める前に
テレフォニーアプリケーションサーバーの鍵ストアに virtualinfo 証明書が追加されています。
このタスクについて
テレフォニーアプリケーションサーバーの次の 2 つの場所にある messagingservice.properties ファイルを更新します。
  • /enterprise/ibm/messagingservice.properties
  • /opt/IBM/WebSphere/AppServer/sutConfig/messagingservice.properties
手順
  1. テレフォニーアプリケーションサーバーに root ユーザーとしてログインします。
  2. エディタで /enterprise/ibm/messagingservice.properties を開きます。
  3. 証明書別名を確認または virtualinfo に変更します。
    com.lotus.sametime.messaging.certificateAlias = virtualinfo
  4. ファイルを保存して閉じます。
  5. エディタで /opt/IBM/WebSphere/AppServer/sutConfig/messagingservice.properties を開きます。
  6. 証明書別名を確認または virtualinfo に変更します。
    com.lotus.sametime.messaging.certificateAlias = virtualinfo
  7. ファイルを保存して閉じます。

フェイルオーバーのモニターと保守

このセクションでは、TAS 上でフェイルオーバークラスタをモニターおよび保守するときに必要なタスクについて説明します。

フェイルオーバー環境でのサービスの開始と停止

IBM Sametime Unified Telephony サービスをフェイルオーバー環境で開始および停止するには、 フェイルオーバー環境で稼働していないサーバーからの各種のコマンドが必要です。

SUT サービスの開始
Sametime Unified Telephony サービスをフェイルオーバー環境で開始するには、以下のコマンドを使用します。
chrg -o online SUT_BASE_TASx SUT_BASE_WASx CLUSTER_TASx
ここで x はノード ID です。
重要: テレフォニーアプリケーションサーバーが稼働しているときは、NOMINAL 状態のテレフォニーアプリケーションサーバーと IBM WebSphere Application Server の基本グループが常にオンラインであることが重要です。
SUT サービスの停止
Sametime Unified Telephony サービスをフェイルオーバー環境で停止するには、以下のコマンドを使用します。
chrg -o offline CLUSTER_TASx
ここで x はノード ID です。
上記のコマンドを発行すると、テレフォニーアプリケーションサーバー上で稼働しているサービスが停止します。 ただし、テレフォニーアプリケーションサーバーと WebSphere Application Server のマウントポイントは、 依然としてオンラインのままであり、SAMP に制御されています。 すべてを停止してディスクをアンマウントするには、以下のコマンドを使用します。
chrg -o offline SUT_BASE_TASx SUT_BASE_WASx CLUSTER_TASx
ここで x はノード ID です。

フェイルオーバークラスタの管理に関するガイドライン - 重要な注意

IBM Sametime Unified Telephony デプロイメントのフェイルオーバークラスタを管理するときは、 SAMP 制御コマンドを使用すること、および SAN ディスクの二重マウントを避けることが重要です。

管理のガイドライン

フェイルオーバークラスタを管理するときは、以下の基本的なガイドラインに従うことが重要です。

SAMP コマンドを使用して、テレフォニーアプリケーションサーバーを制御する

フェイルオーバークラスタでは、テレフォニーアプリケーションサーバーを制御するときに、 必ず IBM Tivoli System Automation for Multiplatforms (SAMP) コマンドを使用してください。

例:
  • Sametime Unified Telephony サービスを停止するには、以下の SAMP コマンドを使用します。
    - chrg -o offline CLUSTER_TASx
    以下のネイティブコマンドは使用しません。
    - /etc/init.d/framework stop
  • SAN ディスク (/enterprise) をアンマウントするには、以下の SAMP コマンドを使用します。
    - chrg -o offline SUT_BASE_TASx
    以下のネイティブコマンドは使用しません。
    - unmount /enterprise

クラスタを制御するためのコマンドは、「コマンドラインを使用した SAMP のモニターおよび保守」にすべて記載されています。

SAN ディスクの二重マウントを避ける

1 次ノードとスタンバイノードの両方で SAN ディスクを二重にマウントするのを避けることは、非常に重要です。 SAMP コマンドのみを使用してテレフォニーアプリケーションサーバーを制御すれば、こうした状況は決して発生しません。 SAMP は、クラスタサービスを制御している間、マウントポイントも制御していることに注意してください。

ネイティブコマンドを使用する前に、SAMP を手動モードに設定する
何らかの理由でテレフォニーアプリケーションサーバーをネイティブコマンドで制御する必要がある場合は、 以下の SAMP コマンドを実行して、最初に SAMP を手動モードに設定してください。
- samctrl -M T
これにより、ネイティブコマンドを使用して、そのテレフォニーアプリケーションサーバー用の Sametime Unified Telephony サービスを 停止および開始することができます。

コマンドラインを使用した SAMP のモニターと保守

このトピックでは、コマンドラインインターフェース (CLI) を使用して実行できる SAMP のモニタータスクと保守タスクについていくつか説明します。

SAMP には、CLI から使用する便利なコマンドがあります。それらを以下に示します。

  • すべての SAMP コマンドで UNIX man-pages が使用可能です。
    man command_name
  • クラスタの状態をモニターします。
    lssam
  • システムを永続的にモニターします。
    lssam -top 
  • 自動化を手動モードに設定します (インストールや更新などの場合)。
    samctrl -M T 
  • 自動化を自動モードに設定します。
    samctrl -M F
  • リソースの状態をリセットします (Failed Offline から復旧)
    • Failed Offline 状態になったときにリソース DB_MGR をリセットします。
      		resetrsrc -s 'Name="DB_MGR"' IBM.Application
    • すべてのリソースをリセットします。
      resetrsrc -s 'Name like "%"' IBM.Application
  • リソースグループ SUT_BASE_TASx を開始/停止します。

    (SUT_BASE_TASx は、/enterprise マウントポイントと TAS 仮想 IP アドレスを制御します)

    chrg -o online SUT_BASE_TASx
    chrg -o offline SUT_BASE_TASx
  • アクティブな TAS ノードをダウンさせます。
    chrg -o offline CLUSTER_TASx
    ここで x は、1、2、3... です。
  • 現在オフラインの TAS ノードを起動するには、以下のコマンドを使用します。
    chrg -o online CLUSTER_TASx
    ここで x は、1、2、3... です。
  • ポリシー操作
    • ポリシーの検査
      - sampolicy -c policy.xml
    • ポリシーのアクティブ化
      - sampolicy -a policy.xml
    • ポリシーの非アクティブ化
      - sampolicy -d
  • リソースを 1 次ノードからスタンバイノードに移動させます。

    リソースを 1 次ノードからスタンバイノードに移動させるには、以下のいずれかのコマンドを起動します。

    rgreq –o move –n primary_node_hostname SUT_BASE_TASx
    ここで x はノード ID です。または、
    rgreq –o move –n primary_node_hostname CLUSTER_TASx
    ここで x はノード ID です。
  • リソースをオフボード Media Server からスタンバイノードに移動させるには、 以下のいずれかのコマンドを起動します。
    rgreq –o move –n media _server_hostname SUT_BASE_MediaServerX
    ここで X はノード ID です。または、
    rgreq –o move –n media _server_hostname NODE_MGR_MediaServerX
    ここで X はノード ID です。

操作コンソールを使用した SAMP のモニターと保守

IBM Tivoli System Automation 操作コンソールは、異機種混合環境での操作の自動化やアプリケーションのモニターに対応したハブとして機能します。 通常、操作コンソールは、別個のサーバーにインストールされます。操作コンソールは Web ベースであり、エンドツーエンドのサポートを簡単かつ効率的に提供するように設計されています。 操作コンソールを使用した SAMP のモニターは、任意に行います。

SA 操作コンソールは、ブラウザベースのグラフィカルユーザーインターフェースであり、 IBM Integrated Solutions Console (ISC) に表示されます (ISC は、組み込み WebSphere Application Server に統合されています)。 このコンソールは、以下の部分から構成されます。

  • 組み込み WebSphere Application Server
  • Integrated Solutions Console (組み込み WebSphere Application Server のアプリケーションとして稼働します)
  • SA 操作コンソール (オペレータおよび管理者がモニターと管理のために使用する実際のグラフィカルユーザーインターフェースであり、 IBM Integrated Solutions Console 内で稼働します)。SA 操作コンソール自体は、Web ブラウザに表示されます。

SA 操作コンソールは、サポートされるすべての Tivoli System Automation ドメインにアクセスするための共通のコンソールです。つまり、オペレータには、さまざまなタイプのクラスタ (Linux クラスタ、AIX® クラスタなど) で稼働する自動化アプリケーションにアクセスするための、共通の外観を持つコンソールが用意されています。

操作コンソールのメインパネルのレイアウトを以下に示します。

操作コンソール

ページの最初には、クラスタとシステムを示すドメイントポロジが表示されています (これには、クラスタを横断する e-business アプリケーションの論理的な自動化ドメインも含まれます)。 この例では、この自動化ドメインは FriendlyE2E という名前であり、 トポロジツリーのルートとして表示されています。

トポロジツリーでの選択項目に応じて、ドメイントポロジの下のリソーステーブルに表示される内容が決まります。 リソーステーブルには、現在選択されているドメインまたはノードの自動化リソースが表示されます。 現在、トポロジツリーでは、自動化ドメイン FriendlyE2E が選択されています。 したがって、リソーステーブルには、自動化ドメインに定義された自動化アプリケーションが表示されています。

ここで、エンドツーエンドドメインに切り替えて、自動化 e-business アプリケーションを詳しく見てみます。 特定のリソースに関する詳細情報を表示するには、リソーステーブルでそのリソースを選択します。 アイコンに示されるように、Stock Trading Application は、e-business アプリケーション Stock Trading Application を 構成するいくつかのサブコンポーネントを含むグループです。

トポロジ

次のことに注意してください。
  • リソーステーブルには、Stock Trading Application に属するサブコンポーネントが表示されています。
  • リソーステーブルの上の階層リンクには、現在のコンテキストが表示されています。
  • トポロジツリーの [検出場所] 列で、 Stock Trading Application のコンポーネントが配布されるクラスタとシステムを確認できます。
  • 情報域には、現在選択されている Stock Trading Application に関する詳細情報が表示されます。

画面の情報域を見てみます。 情報域には、現在の選択項目に関する詳細情報が常に表示されています。 例えば、情報域には、正確な名前、クラス、所有者情報が表示されており、 このリソースに関する詳細な操作情報を参照できるハイパーリンクが含まれています。 状況セクションも重要です。 状況セクションには、現在監視されているリソースの状態と必須状態が表示されています。 ここでは、現在監視されているリソースの状態は「オンライン」になっています。 これは、Stock Trading Application が現在稼働中であることを意味しています。 必須状態は、自動化ポリシーに定義された自動化の目標を示しています。状況セクションでは、これらの 2 つの状態の前にリソースの要約情報 (複合状態とも呼ばれる) が表示されます。 監視された状態が必須状態に一致しているので、要約にはリソースが予定どおりに機能している旨が示され、 緑のアイコンが表示されています。

SAMP 操作コンソールのインストール

IBM Tivoli System Automation for Multiplatforms (SAMP) 操作コンソールをインストールします。

このタスクについて

操作コンソールのインストーラには、Linux 版と Microsoft Windows 2003 Server 版があります。 ハードウェア要件を含む詳しい説明については、SAMP V3.1 の『インストールおよび構成のガイド』を参照してください。インストールのステップは、以下の手順に要約されています。

手順
  1. setup.bin を開きます。
  2. インストールの言語を選択します。
  3. ご使用条件を受け入れます。
  4. インストールの宛先ディレクトリを選択します。
  5. IBM WebSphere Application Server 管理者のユーザー ID とパスワードを指定します。
  6. 組み込み WebSphere Application Server のデフォルトポートが次の画面に表示されます。 このシステムに他の WebSphere Application Server インストール済み環境が存在しない場合は、デフォルトポートを選択します。
  7. SAMP 操作コンソール管理者のユーザー ID、パスワード、名、姓を選択します。
  8. 次の画面で情報を検討し、正しいことを確認します。 次に [インストール] ボタンを選択してアプリケーションをインストールします。
  9. インストールを確認するために、Web ブラウザを開き、以下の URL にナビゲートして、SAMP 操作コンソールのログインページを表示します。
     http://fully_qualified_host_name:9060/ibm/console
SAMP 操作コンソールの構成

操作コンソールの構成は、単一のステップからなります。

このタスクについて
構成ダイアログを開始します。 詳細については、SAMP の『インストールおよび構成のガイド』の第 6 章を参照してください。
手順
  1. 以下のコマンドのいずれかを入力すると、操作コンソールの構成ダイアログが開始します。
    • Windows では、C:¥Program Files¥IBM¥tsamp¥eez¥bin¥ に移動して (cd を使用)、以下のコマンドを入力します。
      cfgdirect.bat
    • Linux では、以下のコマンドを実行します。
       cfgdirect
  2. [サーバー] タブで [イベント・ポート番号] を指定します。 デフォルトポートは、2002 です。
     [サーバー] タブ
    操作コンソールの構成が完了します。
SAMP 操作コンソールの基本コンポーネント自動化アダプタの構成

基本コンポーネント自動化アダプタの構成については、 『Configuring the end-to-end automation adapter of IBM Tivoli System for Multiplatforms』の第 14 章で詳しく説明されています。

このタスクについて
操作コンソールに直接アクセスするには、SAMP 基本コンポーネントの自動化アダプタを構成する必要があります。 エンドツーエンド自動化アダプタは、cfgsamadapter ユーティリティを使用して構成できます。
注: 自動化アダプタは、SAMP クラスタ内のどのノードからでも構成できます。
手順
  1. cfgsamadapter コマンドを使用して、アダプタを開始します。 次のダイアログが表示されます。
    最初の構成ダイアログ
    この画面では、以下のタスクを実行できます。
    • エンドツーエンド自動化アダプタを構成する。
    • エンドツーエンド自動化アダプタの構成ファイルを別のノードに複製する。
    • エンドツーエンド自動化アダプタの自動化ポリシーを定義して、 アダプタの自動化に必要なリソースを作成する。
    • エンドツーエンド自動化アダプタの自動化ポリシーを削除する。
  2. [構成] をクリックしてください。
    1. [アダプタ] タブでは、ホストを構成できます。以下の図は、「インストールおよび構成のガイド」から引用した、サンプルの [アダプタ] タブの画面キャプチャーです。
      [アダプタ] タブ
    2. [ホスト名または IP アドレス] フィールドには、アダプタが稼働するホスト名を入力します (アダプタが自動化されていない場合)。 これは、クラスタ内のどのノードでも構いません。IBM では、アダプタの可用性を高めるためにアダプタを自動化しています。そのため、この値は、 [自動化] タブの [アダプター IP アドレス] フィールドの値で自動的に更新されます。この値が更新されるのは、指定した 1 次ノードに障害が発生して、アダプタがクラスタ内の別のシステムにフェイルオーバーする場合です。
    3. [要求ポート番号][イベント・ポート番号] には、デフォルト値を使用します。
  3. [アダプター使用ホスト] タブで以下の作業を行います。
    アダプタを使用しているホスト
    1. [直接アクセス・オペレーション・コンソールの構成] オプションを選択します。
    2. 操作コンソールが稼働しているシステムの名前または IP アドレスを [ホスト名または IP アドレス] フィールドに 入力します。
    3. [イベント・ポート番号] には、デフォルトポートの 2002 を使用します。これは、操作コンソールの構成時に指定したポートです。
  4. 構成する次のタブは、[自動化] タブです。このタブでは、自動化アダプタの自動化ポリシーを構成できます。このタスクを実行すると、アダプタの可用性が高くなります。つまり、 アダプタが稼働中のノードに障害が発生した場合でも、アダプタはドメイン内の別のノードで再起動します。 詳細は、『インストールおよび構成のガイド』を参照してください。
    自動化
    1. [第 1 レベル自動化ドメインでのアダプター自動化] チェックボックスを選択します。
    2. [ドメイン照会] をクリックします。
    3. アダプタに付ける名前を [自動化リソースのプレフィックス] フィールドに入力します。
    4. クラスタ内のいずれかのシステムの仮想 IP アドレスを [アダプター IP アドレス] に入力します。
    5. AutomationPolicyResponsefile.txt に指定されたのと同じ値を使用して、クラスタのネットマスクを定義します。
  5. [保存] をクリックして、構成を保存します。 構成を保存すると、自動化アダプタの主画面に戻ります。
  6. [複製] をクリックして、ドメイン内の他のすべてのノードに自動化構成を複製します。以下のダイアログが表示されます。 (画面キャプチャは、『インストールおよび構成のガイド』から引用したものです。)
    複製
    1. 両方の [すべてを選択] ボタンをクリックして、すべての構成ファイルをすべてのノードに複製することを選択します。
      注: [すべて選択] オプションを選択して、ターゲットノードを選択するときは、ユーザー ID とパスワードがすべてのノードで同じなければなりません。各ノードのユーザー ID とパスワードが異なる場合は、ファイルを各ノードに個々に複製する必要があります。
    2. [複製] をクリックします。
    ドメインの他のノードに構成を複製すると、自動化アダプタの主画面に戻ります。
  7. [定義] をクリックします。 アダプタの自動化ポリシーを定義すると、アダプタを開始できます。 以上で基本コンポーネント自動化アダプタの構成が完了しました。
操作コンソールの開始と検証

このトピックでは、基本コンポーネント自動化アダプタをクラスタでオンラインに設定する方法、および操作コンソールからクラスタを管理できることを確認する方法について説明します。

手順
  1. 自動化アダプタを開始するには、クラスタのいずれかのノードにログオンし、 chrg コマンドを使用してアダプタをオンラインに設定します。
    		chrg –o online samadapter-rg
  2. lssam コマンドを使用して、アダプタがオンラインになっていることを確認します。 自動化アダプタリソースグループは、「lssam」の出力の下部に表示されます。 この出力には、アダプタが現在アクティブであるノードが示されます。
  3. 操作コンソールからドメインを管理することが可能になっています。 操作コンソールにログインして、クラスタが表示されることを確認します。

コールアクティビティおよび汎用サーバーの状況のモニタ

Integrated Solutions Console を使用して、IBM Sametime Unified Telephony のコール情報、テレフォニーサーバー、SIP 登録をモニタできます。

サーバーが実行中かどうかの判別

テレフォニーアプリケーションサーバー、テレフォニー制御サーバー、IBM Sametime サーバーの一般状況をモニターすると、各サーバーが実行中かどうかを判別できます。

このタスクについて

管理モジュールは、テレフォニーアプリケーションサーバーノード上で実行されている間に、フレームワークとリモートで対話します。リモートインターフェースを使用してフレームワークとテレフォニー制御サーバーをモニターすると、コール処理時のパフォーマンスが低下することがあります。このため、管理モジュールで提示される情報はリアルタイムでは表示されません。代わりに情報が取得され、一時的にキャッシュされます。2 分ごとにこのキャッシュの更新が試行され、古いデータが再び最新情報に置き換えられます。この照会自体にかなりの時間がかかることがあるため、キャッシュの更新には 2 分から 4 分かかる場合があります。

以下のいずれかに該当する場合、「停止中」の状況が表示されます。
  • 少なくとも 1 つの重大アラームが存在する
  • 少なくとも 10 個のメジャーアラームが存在し、重大アラームが存在しない
  • パッチの適用が進行中 (テレフォニー制御サーバー)
  • サーバーにアクセスできないか、状況を判別できない (例えば、初期化中であったり、フレームワークが使用できない場合)
状況の変更が有効になるためには、これらのアラームを Common Management Portal で解決する必要があります。

このアイコンは、重大アラームが存在せず、メジャーアラームが 10 個以下であり、現在システムにパッチが適用中でない場合にのみ「開始」の状況が表示されます。

手順
  1. Integrated Solutions Console にログインします。
  2. [テレフォニー] > [テレフォニーサーバー] をクリックします。
    サーバーの状況には、以下のものがあります。
    • 開始 サーバーが実行中で丸の中に矢印が表示される
    • 停止 サーバーが実行しておらず、丸の中に "x" が表示される
    • サーバーには現在パッチが適用されています サーバーが実行しておらず、丸の中に "x" が表示される
      注: この状況は、テレフォニー制御サーバーにのみ当てはまります。
  3. オプション: テレフォニーアプリケーションサーバー上のどのコンポーネントが実行中であるかを調べるには、サーバーのホスト名をクリックします。

    複数のコンポーネントがテレフォニーアプリケーションサーバー上で実行されています。

    コンポーネント 説明
    通信 Sametime サービスを使って着信コールアラートをオンラインユーザーに送出した後、ユーザーの設定に応じてコールを処理します。
    プレゼンス (在席確認) テレフォニープレゼンスを Sametime に公開します。
    フレームワーク すべてのコンポーネントの通信を制御する統一された通信プラットフォームです。

テレフォニー制御サーバー上のアラームのモニタ

テレフォニー制御サーバーのアラームの状況をモニタできます。

このタスクについて
テレフォニー制御サーバーのアラームは、次の結果として起こります。
  • 1 つ以上の障害がシステムで検出された。
  • 構成されたしきい値 (使用されるライセンス数、CPU 使用量など) の超過。
  • 過負荷状態。

以下の手順に従い、アラームをモニタします。

手順
  1. Integrated Solutions Console にログインします。
  2. [テレフォニー] > [テレフォニーサーバー] をクリックします。
  3. テレフォニー制御サーバーの名前をクリックします。
  4. スクロールダウンして、アラーム情報を参照します。 各アラームにはアラームレベル (重大、メジャー、マイナー) があります。 アラーム条件が終わると、アラームは自動的に消去されます。

コールボリュームのモニタ

テレフォニーアプリケーションサーバー上のコールのボリュームをモニタできます。

手順
  1. Integrated Solutions Console にログインします。
  2. [テレフォニー] > [コール情報] > [モニタコール] をクリックします。

    最近のコールでは、テレフォニーアプリケーションサーバーが最後に開始されてからの 250 の最近のコールがリストされます。 コールを行っているユーザーの詳細を調べるには、[ユーザー] 列でユーザー ID をクリックしてください。

オフラインコールレコードの削除

テレフォニーアプリケーションサーバー上に保管されたオフラインコールレコードを削除できます。

このタスクについて
オフラインコールとは、ユーザーが IBM Sametime Unified Telephony にログインしていないときに、そのユーザーに対して発信されたコールのことです。オフラインユーザーに対するコールは 20 件まで、そのユーザーが次回ログインするときまで、サーバー上の 1 つのレコードに一時的に保管されます。 ユーザーが次回ログインすると、レコードはユーザーのローカルコール履歴に自動的に転送され、サーバーから削除されます。

オフラインコールレコードを手動で削除するには、以下の手順に従います。

手順
  1. Integrated Solutions Console にログインします。
  2. [テレフォニー] > [コール情報] > [オフラインコールストレージ] をクリックします。
  3. オフラインコールストレージのレコードをリストから選択し、[削除] をクリックします。 この操作によりリストからレコードが消去され、サーバーからレコードが削除されます。 この結果、削除されたレコードはユーザーのローカルコール履歴には自動的に転送されません。

ライセンスのモニタ

IBM Sametime Unified Telephony ユーザーに割り振られているライセンス数をモニタできます。

このタスクについて
使用可能なライセンスの総数は、インストール時に決定されます。 この手順を使用して、割り振られているこのライセンス数を判別します。
手順
  1. Integrated Solutions Console にログインします。
  2. [テレフォニー] > [テレフォニーサーバー] をクリックします。
  3. テレフォニー制御サーバーの名前をクリックします。 テレフォニー制御サーバーの画面でスクロールダウンすると、ライセンス情報を参照できます。

ログインしているユーザーの判別

Sametime Connect クライアントを介して IBM Sametime Unified Telephony にログインしたユーザーを調べることができます。

このタスクについて
ユーザー SIP レジストリに、Sametime Unified Telephony にログインしたすべてのユーザーがリストされます。 レジストリは統一番号で表示されます。 ユーザーは電話コールを行わなくても、ただ Sametime Unified Telephony に接続するだけで登録されます。ユーザーがログインしたままでいる限り、ユーザーの Sametime Connect クライアントによって自動的に登録が延長されます。
手順
  1. Integrated Solutions Console にログインします。
  2. [テレフォニー] > [テレフォニーサーバー] > [ユーザー SIP 登録] をクリックします。 以下の情報が表示されます。
    列名 説明
    統一番号 これは Sametime Unified Telephony ユーザーに到達するための単一番号です。ユーザーは優先テレフォニーデバイス (デスクトップ電話、ソフト電話、携帯電話、自宅の電話など)、および各種デバイスへのコールのルーティング規則を設定します。
    ユーザー名 統一番号に関連付けられたユーザー名。
    登録位置 ユーザーが Sametime Unified Telephony にログインしたアドレス。登録位置 = (IP アドレス + : + Sametime Connect クライアントのポート番号)。
    有効期限 登録の有効期限が切れる時間 (ユーザーのログインクライアントが登録を自動的に延長するときを除く)。

ユーザーに関する詳細情報の検索

IBM Sametime Unified Telephony ユーザー (単一ユーザーまたは複数のユーザー) の登録情報、コール状況、設定を検索できます。

手順
  1. Integrated Solutions Console にログインします。
  2. [テレフォニー] > [ユーザーの検索] をクリックします。
  3. ユーザーのテレフォニー統一番号または Sametime ユーザー名を入力します。
  4. [検索] をクリックします。 以下の情報が表示されます。
    • [一般的なユーザー情報] ユーザーの姓名、Sametime Unified Telephony ユーザー名、統一番号。
    • [SIP 登録] ユーザーの現在の SIP 登録。 これは、有効期限まで有効になります。
    • [アクティブなコール] そのユーザーが接続しているコールすべてのリスト。 [削除] をクリックすると、コールの切断要求を送信できます。 ページが最新表示されるまで要求が実行されない可能性があるため、ページの再描画時に古い状況データが表示されることがあります。 要求の実行の待機時間が 60 秒以上かかることがあり、その後で Sametime Unified Telephony はリフレッシュデータの照会を開始します。
    • [オフラインコールストレージ] オフラインコールとは、ユーザーが Sametime Unified Telephony にログインしていないときに、そのユーザーに対して発信されたコールのことです。 オフラインユーザーに対するコールはすべて、そのユーザーが次回ログインするときまで、サーバー上の 1 つのレコードに一時的に保管されます。 ユーザーが次回ログインすると、レコードはユーザーのローカルコール履歴に自動的に転送され、サーバーから削除されます。 [削除] をクリックするとレコードが削除されます。この操作によりリストからレコードが消去され、サーバーからレコードが削除されます。
    • [優先使用番号] ユーザーの優先電話番号とデバイスのリスト。 ユーザーはこの情報を Sametime 接続クライアントに設定します。[呼び出しのタイムアウト] 欄の秒数は、ユーザーの Sametime Connect クライアントに表示される秒数よりも実際には長くなります。なぜなら、クライアントが情報をサーバーに送信するまでに数秒かかるためです。 [転送順序] は、デバイスが呼び出される順序のリストです。
    • [コールの転送ルール] Sametime Connect クライアントから提供される情報から得られた、サーバー上でのコールの転送ルールのリスト。 ユーザーはこれらのルールを Sametime Connect で設定しますが、これらのルールは管理者のコンソールでは異なって表示されます。 これらのルールは、着信コールを該当するデバイスまたは電話番号に経路指定する際に適用されます。 それぞれの Sametime 状況にはルールがあり、すべてのルールはロケーションごとに保管されます。 例えば、あるユーザーにはホームロケーション用に 1 つのルールセット、オフィスロケーション用に別のルールセットがあるかもしれません。 ルールはリストに表示される順序で、上から下へ評価されます。
呼び出し転送ルール

このトピックでは、クライアントの呼び出し転送ルールがサーバーの呼び出し転送ルールに変換される方法について概説します。

呼び出し転送ルールは、ユーザーの [呼び出し転送] 設定に基づきます。 ルールは、以下のようなときに、サーバーに保存されます。
  • ユーザーが IBM Sametime Connect クライアントに最初にログインするとき。 クライアントに保管されている、優先される番号とルールが、この時点でサーバー上に最初に作成されます。
  • ユーザーがクライアントで [呼び出し転送] 設定を編集するとき。

クライアントは 2 つのルールセットをサーバー上に作成します。 一方のセットには、ユーザーがオフラインのときに適用されるすべてのルールが含まれ、 他方のセットには、オンライン状況と現在のロケーションに適用されるすべてのルールが含まれています。 ロケーションが変わると、クライアントは現在のルールセットを更新します。 現在のロケーションに適用されるルールがない場合には、現在のルールセットは非アクティブになります。 ユーザーがログアウトすると、サーバーは自動的にオフラインルールセットをアクティブにします。 ユーザーが手動で優先デバイスを変更したときには、まず優先デバイスを鳴動させることによって、サーバーは現在のオンラインルールを非アクティブにし、これがリングアウトする場合にのみ、通常のオンラインルールが適用されます。

永続ルールは特殊なケースです (これは、[呼び出し転送] 設定でユーザーに表示される、ロックされているルールです)。 それはルールとしてサーバー上に保管されず、これによってクライアントは単に、ルール内でデバイスまたはデバイスリストへの優先ターゲットを設定します。 デバイスリストは最初に、管理者が Sametime Unified Telephony にユーザーを追加するときに決まります。 ユーザーが永続ルールを削除することはできませんが、ルールに関連付けられたデバイスや番号を変更することはできます。 [呼び出し転送] 設定にある他のルールについては、以下のような理由により、単一のクライアントルールから多くのサーバールールが生じる可能性があります。

  • クライアント側ルールの各条件には、それぞれ別個のサーバー側ルールが必要です。 例えば、「離席中」(Away) のクライアントルールは、実際には 2 つのサーバールールにマップされます。 その一方は STATUS_AWAY (クライアントが手動で「離席中」状況に設定する場合に使用されるルール) であり、もう一方は STATUS_NOT_USING (一定時間の非アクティブの後に、クライアントが自動的に「離席中」に変わる場合に使用されるルール) です。 発信者 ID を使用するルールでは、使用される電話番号ごとに異なるルールが必要です。 複数の状況と複数の発信者 ID の両方を使用するルールでは、サーバーは条件のそれぞれの組み合わせごとにルールを作成します。
  • 任意の状況のためのルールは一般に、オフライン用に 1 つのルールと、各オンライン状況用に 1 つずつという結果になります。
  • サーバールールは、ロケーション条件をサポートしません。 セレクタとしてロケーションだけを使用するクライアントルールについては、サーバーは条件のないルールを持つことができないため、クライアントはそれぞれの状況条件ごとにルールを作成します。

ルールはサーバーで作成されますが、クライアントがサーバーから呼び出し転送ルールを取り出すことは決してありません。 したがって、ユーザーがワークスペースを失った場合には、その人が次回にクライアントを開始するときには何のルールも持っていないことになります。

ログレベル

テレフォニーアプリケーションサーバーの問題および関連する問題を、IBM サポートが調査するための情報を収集します。

ランタイムログレベルを設定すると、テレフォニーアプリケーションサーバーを停止および再起動せずに、問題を素早くデバッグできます。問題の発生時に、対象となる領域のログを有効にすることができます。問題が再現したら、実行時のログ記録をただちに無効に戻す必要があります。詳細なログが出力されますが、ログファイルのサイズには制限があります。

このログは、IBM サポートに送付する必要があります。このログ記録メカニズムの対象となるのは、Sametime Unified Telephony フレームワークのみです。SIP または WebSphere Application Server のログの収集が必要な場合は、WebSphere Application Server 管理コンソールのトラブルシューティングのセクションに移動する必要があります。

ログ出力

[最大ファイルサイズ] この値は事前設定されていて、このインターフェースから変更することはできません。

[ファイルの最大数] この値は事前設定されていて、このインターフェースから変更することはできません。

[ファイル名] ログファイルを作成するロケーションとファイル名。複数のコンポーネントを選択した場合は、各ログのファイル名に固有の番号が追加されます。例えば、/log/sut-trace.log は、ファイルシステム内で /log/sut-trace.log.0 になります。OSGI フレームワークの sym ユーザーアカウントが書き込み権限を持つファイルのロケーションおよび名前を入力する必要があります。

コンポーネント
デバッグ対象のテレフォニーアプリケーションサーバーのコンポーネントを選択します。コンポーネントは、階層構造になっていません。 これらのコンポーネントの範囲は、特定の対象領域に絞られています。コンポーネント間で範囲が重複している場合もありますが、あるコンポーネントが別のコンポーネントの下位コンポーネントになっているわけではありません。
  • オフラインコール履歴
  • プレゼンス (在席確認) 管理
  • Sametime 接続設定
  • テレフォニー状況認識
  • Sametime 状況認識
  • Sametime ユーザー検索サービス
  • 通信管理
  • 管理サービス
  • リモート管理

SIP Proxy and Registrar のプロパティの設定

SIP (Session Initiation Protocol) は、IBM Sametime Unified Telephony のユーザー (複数可) とのセッションを作成、変更、終了するためのプロトコルです。

このタスクについて

SIP Proxy and Registrar のプロパティをモニタおよび更新できます。 セッションを作成するために使用される SIP 招待ではセッション記述が配信されるため、ユーザーはテレフォニータイプのセットについて合意できます。 SIP はプロキシサーバーという要素を利用して、ユーザーの現在の場所への要求のルーティング、テレフォニーサービスを提供するためのユーザー認証と許可、コールルーティングポリシーの実施、ユーザーへの Sametime Unified Telephony 機能の提供を支援します。さらに、プロキシサーバーが使用するユーザーの現在位置をユーザーが送信できるようにする登録機能も、SIP により提供されます。

SIP Proxy and Registrar コンポーネントは、Sametime デプロイメントの Media Manager の一部です。 SIP Proxy and Registrar のプロパティの設定については、Sametime Wiki で『Sametime product documentation』の「Managing SIP proxy properties」および「Managing SIP registrar properties」のトピックを参照してください。

サーバーの開始、停止、更新

このセクションでは、保守を実行したりサーバーソフトウェアを更新したりできるように、サーバーをオフラインにする方法を説明します。

テレフォニー制御サーバーソフトウェアの更新

テレフォニー制御サーバーに対して保守やソフトウェアのアップグレードを実行する場合は、一度に 1 つずつノードをオフラインにする必要があります。

このタスクについて
1 ノードずつノードをオフラインにして保守を実行することにより、環境の実動状態を常に維持できます。
手順
  1. SSH クライアントを開きます。
  2. テレフォニー制御サーバーに root ユーザーとしてログインします。
  3. 次のコマンドを入力して、ノード 1 を状態 3 (オフライン) に落とします。ノード 2 の状態は未変更のままにします (オンライン)。
    /unisphere/srx3000/srx/startup/srxctrl 3 0
  4. これで、ノード 1 のソフトウェアに対して更新または保守を安全に実行できます。 この時点で、更新の手順に従うことになります。
  5. 次のコマンドを入力して、ノード 1 をオンラインにし、ノード 2 を状態 3 (オフライン) に落とします。
    /unisphere/srx3000/srx/startup/srxctrl 4 3
  6. これで、ノード 2 のソフトウェアに対して更新または保守を安全に実行できます。 この時点で、更新の手順に従うことになります。
  7. 次のコマンドを入力して、ノード 1 の状態は未変更のまま (オンライン)、ノード 2 をオンラインに戻します。
    /unisphere/srx3000/srx/startup/srxctrl 0 4

Tivoli SAMP によるテレフォニーアプリケーションサーバーの管理

IBM Sametime Unified Telephony におけるフェイルオーバーを管理するために、Tivoli System Automation for Multiplatforms を使用します。

このタスクについて
System Automation for Multiplatforms は高可用性環境を提供し、その環境において Sametime Unified Telephony は連続的に使用可能であり、その自己修復インフラストラクチャによって、システム問題による故障時間の発生を防ぎます。 自己修復インフラストラクチャにより、不正な操作、トランザクション、プロセスが検出され、Sametime ユーザーを混乱させることなく修正アクションが開始されます。

これにより管理者の介入を必要とせずに迅速で一貫性のある回復ができるため、手動でモニタを実行する手間が省け、Sametime コンポーネントと関連を覚えておかなければならない煩わしさから解放されます。そのため管理者が過ちを犯すリスクが少なくなります。

銘記すべき重要な点として、使用可能なスタンバイノードがない場合に Sametime Unified Telephony 環境でフェイルオーバーが発生すると、テレフォニーアプリケーションサーバークラスタ全体がリブートし、クラスタがオフラインになります。 スタンバイノードで電源切れまたはネットワーク障害が発生した場合、スタンバイノードは使用不可になる可能性があります。

System Automation for Multiplatforms の全体的な資料については、http://publib.boulder.ibm.com/tividd/td/IBMTivoliSystemAutomationforMultiplatforms3.1.html を参照してください。

テレフォニーアプリケーションサーバーまたは WebSphere Application Server ソフトウェアの更新

テレフォニーアプリケーションサーバーまたは WebSphere Application Server に対して保守やソフトウェアの更新を行うときは、クラスタ全体をオフラインにする必要があります。

このタスクについて
次のタスクでは、ソフトウェアの更新を実行するため、IBM Tivoli System Automation for Muliplatforms を使用してテレフォニーアプリケーションサーバーのクラスタをオフラインにします。

Tivoli System Automation for Multiplatforms によって制御されるリソースは、適切な Tivoli System Automation for Multiplatforms コマンドを使用することによってのみ、安全に開始および停止できます。 リソースの状態の変更を Tivoli System Automation for Multiplatforms に反映できるのは、これらのコマンドだけです。リソースを、その「ネイティブ」コマンドを使用して開始または停止した場合、System Automation for Multiplatforms の自動化ポリシーではこのリソースが引き続き「古い」状態になっているため、最終的にはこのリソースを再度希望状態にするために、それに対して開始または停止コマンドがトリガーされます。

手順
  1. クラスタリソースグループを停止します。
    - chrg -o offline CLUSTER_TAS1

    ここで、CLUSTER_TAS1 はソフトウェア更新を必要とするクラスタです。

    注: テレフォニーアプリケーションサーバーと同じマシンにメディアサーバーがインストールされていない場合には、 テレフォニーアプリケーションサーバーを停止する前に、メディアサーバーが停止される必要があります。
    chrg -o offline NODE_MGR_MS1
  2. System Automation for Muliplatforms を手動モードにします。
    - samctrl -M T

  3. これで、ソフトウェアに対する更新を安全に実行できます。 この時点で、更新の指示に従います。
  4. 更新が完了したならば、Tivoli System Automation for Muliplatforms の手動モードを解除します。
    - samctrl -M F
  5. クラスタを再開します。
    - chrg -o online CLUSTER_TAS1
ノードのクラスタへの追加

以下の手順に従い、Tivoli System Automation for Multiplatforms がデプロイされているクラスタに、ノードを追加します。

手順
  1. すべてのノード上で次のコマンドを実行し、新規ノードとすべての既存ノードを組み込みます。
    - preprpnode nodeX nodeA nodeB nodeC

    ここで、nodeX は新規ノードのホスト名、nodeAnodeBnodeC は既存ノードです。

    preprpnode コマンドにより、クラスタに組み込まれたノードのセキュリティ設定が作成されます。 これを実行すると、ノード間で公開鍵が交換され、RMC アクセス制御リスト (ACL) が変更されて、そのクラスタのすべてのノードからクラスタリソースにアクセスできるようになります。

  2. クラスタ内の既存ノードの 1 つで、次のコマンドを実行します。
    - addrpnode nodeX

    このコマンドは、新規ノードをクラスタに追加するために使用されます。

  3. 既存のクラスタ内の、既にオンラインになっているノードの 1 つから、新規ノードを開始します。
    	- startrpnode nodeX
ノードの除外

IBM Sametime Unified Telephony のノードを停止する前に、そのノードを IBM Tivoli System Automation for Multiplatforms の自動除外リストに追加する必要があります。 Tivoli System Automation の新規フィックスパックに更新するとき、またはノードの再起動を必要とするセキュリティ更新のような何らかの保守がノードに必要なときに、ノードを除外する必要が生じる場合があります。

このタスクについて
自動除外リストにノードを追加すると、Tivoli System Automation for Multiplatforms のトリガーによりそのノード上で実行中のすべてのリソースが停止し、これらのリソースは別のノードに移動されます。 そのノード上のすべてのリソースがオフラインになった後、そのノードを安全に停止またはリブートできます。 これに失敗すると、停止またはリブートされるノード上で「クリティカルリソース」が実行中の場合には、即時にリブートされます。

以下の手順に従い、ノードを除外リストに追加します。

手順
  1. 以下のコマンドを実行して、ノードを除外リストに追加します。
    # samctrl -u a nodename
    これで、安全にノードを停止できます。

    Tivoli System Automation for Multiplatforms は、他のノードがオフラインであるとしても、除外リストにあるノード上のリソースを開始しません。そのため、ノードはメンテナンスの時だけ除外リストに含めてください。

  2. クラスタ内のノードが再びオンラインになった後、次のコマンドを使用して、除外リストからそのノードを削除します。
    # samctrl -u d nodename
  3. 次のコマンドを使用して、除外リストを確認します。
     # lssamctrl

課金対策におけるコールインターセプトの最適化

IBM Sametime Unified Telephony を最適化して、呼び出される側がコールに応答しない限り外部の発信者が課金されないようにできます。

始める前に

PBX が 302 Update をサポートしている必要があります。

このタスクについて

302 設定は課金対策において重要です。デフォルト設定が使用された場合、着信側が実際にはコールに応答しないにもかかわらず、発信者が不本意に課金される可能性があります。302 設定とインターセプトアナウンスを変更して、着信コールが即時に応答されるかどうか、およびコールがキューに入れられるかどうかを指定します。次の 2 つのオプションがあります。
  • (デフォルト) No 302ASK_ME インターセプト。発信者の立場で説明すると、着信側で使用デバイスとして [コンピュータ] が選択されている場合は、Sametime Unified Telephony へのコールはすぐに応答されます。着信側がコールに応答するかどうか、およびコールに応答する場所を決めている間、発信者には呼び出し音が聞こえます。
  • 302 Moved Temporarily を構成し、RINGBACK インターセプトを使用する。発信者の立場で説明すると、コールは応答されず、着信者が実際に応答するか電話を取ることを選択しない限り、課金されません。

302 Update メッセージを PBX に送るようにテレフォニー制御サーバーを構成し、キューデバイスの処置における応答属性をオフにします。

手順

  1. CLI を開始してログインします。
  2. メインメニューから、以下のメニューオプションを選択します。
    1. 「6」 と入力して、[アプリケーションレベルの管理] を選択します。
    2. 「5」 と入力して、[ゾーン管理] を選択します。
    3. 「2」 と入力して、[エンドポイントの変更] を選択します。 これにより、構成されているエンドポイント属性すべてのリストが表示されます。 このリストは長いので、すべての属性を確認するにはスクロールする必要があります。
    4. 以下の属性を変更します。
      注: [エンドポイント名 (Endpoint Name)] は、PBX への SIP トランクの SIP エンドポイントです。
       Endpoint Name <15 chars> (default: ): Name_of_SIP_endpoint
      Change SIP endpoint attributes as bitmap sums? (default: true): false
      Media Redirection using 302 Moved Temporarily override <0=false|1=true|-1=unchanged> (default: -1): 1
  3. [戻る] を押して続行します。
  4. CLI を終了します。
  5. キューデバイスの処置における応答属性をオフにします。
    1. Common Management Portal にログインします。
    2. [Telephony Control Server] タブをクリックします。
    3. [ビジネスグループ] をクリックします。
    4. ナビゲータで、[チーム] > [ハントグループ] をクリックします。
    5. キューデバイスの [加入者 ID] をクリックします。
    6. [全般] タブで、[インターセプトアナウンス (Intercept Announcement)]RINGBACK_TONE に変更します。

会議への参加のためのオプションの構成

IBM Sametime Unified Telephony で click-to-conference (ワンクリックでの会議参加) 機能を使用するときに、ユーザーにプロンプトが表示されるかどうかを構成します。

このタスクについて

Sametime Unified Telephony で、以下のオプションのいずれかを使用して、click-to-conference (ワンクリックでの会議参加) 機能のユーザーエクスペリエンスを構成します。
  • [了承¥拒否 (Accept¥reject)] - ユーザーは会議への招集アナウンスを聞いた後、会議に参加するには 1 を押すようにというプロンプトが表示されます。
  • [自動的に参加 (Join automatically)] - ユーザーは会議への招集アナウンスを聞いた後、ユーザーの側のアクションなしで、自動的に会議に加わります。
これらのオプションは、STICallOutMode オプションを使用して、sutbcomadapter.properties で構成されます。 デフォルトオプションは [了承¥拒否 (Accept¥reject)] (1) です。 以下の手順に従って、オプションを [自動的に参加 (Join automatically)] (2) に設定します。

手順

  1. テレフォニーアプリケーションサーバーに root ユーザーとしてログインします。
  2. エディタで /enterprise/ibm/sutbcomadapter.properties を開きます。
  3. STICallOutMode2 に変更して、会議に参加するために 1 を押すようにというプロンプトが表示されずに、ユーザーが会議に参加できるようにします。
    STICallOutMode=2
  4. ファイルを保存して閉じます。
  5. 変更を有効にするために、次のように OSGI コンポーネントを再起動します。
    /etc/init.d/framework restart

発信元と宛先のポート

主要なマシンとネットワークを保護するために、以下のポートが推奨されています。 専用化されたポートを使用すると、特定のアプリケーションが特定のポートだけにアクセスできるように、システムをロックする助けになります。

表 2. Sametime Unified Telephony
発信元 タイプ 宛先 使用法
AdminClient: 任意 TCP OSC: 443 Web ブラウザを介した Common Management Portal アクセス
AdminClient: 任意 TCP OSC: 22 管理/サービスのための IBM Sametime Unified Telephony サーバーへの SSH アクセス
OSC: 任意 UDP SIPSM: 5060 Sametime Unified Telephony 会議ブリッジからの SIP ベースの発信コール
SIPSM: 任意 UDP OSC: 5060 Sametime Unified Telephony SIPSM から Sametime Unified Telephony 会議ブリッジへの着信 SIP コール
OSC: 任意 TCP OAM: 22 Sametime Unified Telephony サーバーから Sametime Unified Telephony 管理インターフェースへの SSH アクセス (srx アカウントアクセス)
OSC: 任意 TCP OAM: 8767 Sametime Unified Telephony が使用する SOAP インターフェース
OSC: 任意 TCP OAM: 8768 Sametime Unified Telephony が番号変換のために使用する SOAP インターフェース
Sametime Unified Telephony サーバー: 任意 TCP Sametime Unified Telephony CSTA インターフェース: 1040 Sametime Unified Telephony アクセスへの CSTA リンク
Sametime Unified Telephony UDP OSC: 2427 r MRCP プロトコルアクセス Media Serve
表 3. デバイス
発信元 タイプ 宛先 使用法
OSC: 4000-4999 UDP デバイス: 任意 メディアサーバーとデバイスとの間の RTCP/RTP ボイストラフィック (エンドポイント/ゲートウェイ)
デバイス: 任意 UDP OSC: 4000 - 4999 メディアサーバーとデバイスとの間の RTCP/RTP ボイストラフィック (エンドポイント/ゲートウェイ)。 ポート番号は、メディアサーバー CMP プラグインに構成されているチャネルの数に依存します。
表 4. NTP サーバー
発信元 タイプ 宛先 使用法
OSC: 任意 TCP/UDP NTP サーバー: 123 Network Time Protocol (発信元は、例えば Windows ドメインサーバーが可能)