IBM Sametime Unified Telephony 9: 概要と計画

IBM® Sametime® Unified Telephony について学習し、デプロイメントを計画します。

概要

IBM Sametime Telephony は、複数のベンダーが提供する構内交換機 (PBX) システムの間でテレフォニーを統合することにより、統一されたエンドユーザーエクスペリエンス (統合されたソフトフォン、電話と IM のプレゼンス (在席確認) 状況、コール制御とルールベースコール管理など) を実現します。

Sametime Unified Telephony のアクセシビリティ機能

アクセシビリティ機能は、運動機能または視覚などに障害をお持ちの方が IT 製品を快適に使用できるように サポートします。IBM は、年齢や障害の有無に関わらず、すべてのユーザーにとって使いやすい製品を提供するように努めています。

アクセシビリティ機能 

IBM Sametime Unified Telephony デプロイメントのテレフォニーアプリケーションサーバーは、IBM WebSphere® Application Server Integrated Solutions Console をベースとしており、以下に示す同じアクセシビリティ機能を共有しています。

アクセシビリティに関する IBM の取り組みに従い、この版の製品資料はアクセシビリティ機能に対応しています。この製品資料のアクセシビリティ対応バージョンは、IBM Sametime wiki にあります。

注: 最適なアクセシビリティ機能を実現するためには、スクリーンリーダーとブラウザのどちらについても最新バージョンを使用してください。
  • 次に示すものは、視覚障害を持つユーザー向けの機能です。
    • キーボードのみを使用して操作できる
    • すべての情報を色に依存せずに伝達する
    • スクリーンリーダーと画面拡大機能で一般的に使用されるインターフェースをサポートする
    • 代替出力装置の接続をサポートする
    • アクセス可能な形式でヘルプ情報を提供する
    • 白い背景を使用したハイコントラストをサポートする (一部のアイコンは色付きの背景では正しく表示されない可能性があります)
      重要: コントラストのレベルを変更するときは、変更を有効にするために Sametime クライアントを再起動する必要があります。

      Sametime Web ブラウザのユーザーが画面の共有を選択すると、画面全体の共有、画面の一部の共有、特定のアプリケーションの共有という 3 つのオプションを示すプロンプトがユーザーに表示されます。このプロンプトからスクリーンリーダーにアクセスできるようにするには、ユーザーは Java™ Access Bridge をインストールする必要があります。インストールの詳細については、Oracle の Web サイトを参照してください。

  • 次に示すものは、運動障害を持っているか、両手の使用が制限されるユーザー向けの機能です。
    • ユーザーが、時間制限のある応答を完了するための時間をより多く要求できるようにする
    • キーボードのみを使用して操作できる
    • 代替入出力装置の接続をサポートする
  • 次に示すものは、聴覚障害を持っているか、難聴のユーザー向けの機能です。
    • 音声情報の代わりの方法をサポートする
    • 調整可能なボリューム制御機能をサポートする
  • コンソールで、てんかん性発作を誘発する可能性のある周期で画面を点滅させない
Integrated Solutions Console のヘルプシステムは、次のアクセシビリティー機能を備えています。
  • ヘルプを表示するために使用するブラウザによって提供されるアクセシビリティサポートを使用する機能
  • キーボードを使用することによりナビゲーションを可能にする機能
ヒント: Sametime 製品 Wiki は、アクセシビリティに対応しています。wiki のアクセシビリティ機能については、Getting started with product documentation in the wiki を参照してください。

キーボードナビゲーション

特定のページでコントロール間を移動するには、Tab キーを使用します。

キーボードを使用してページ上のリンクまたはコントロールをクリックするには、リンクまたはコントロールにナビゲートして [Enter] キーを押します。

チェックボックスで選択を行うには、スペースキーを使用します。

キーボードを使用してナビゲーションビューを変更するには、次の手順を実行します。

  1. Tab を押して、表示選択リストに移動します。
  2. 上下矢印を使用して、選択リストの値を変更します。
  3. [Enter] キーを押します。
ナビゲーションに表示されるタスクは、ユーザーの選択に応じて変化します。

関連アクセシビリティ情報

WebSphere Application Server の設定を管理する場合、Integrated Solutions Console で作業します。コンソールのアクセシビリティの詳細については、WebSphere Application Server インフォメーションセンターを参照してください。

IBM とアクセシビリティ

IBM におけるアクセシビリティの取り組みの詳細については、IBM Human Ability and Accessibility Center を参照してください。

ソリューションの概要

企業は、製品およびサービスをより速く提供して顧客サービスを強化すると共に、迅速な意思決定を行う必要があります。生産性およびビジネスの即応性を向上させる鍵は、一貫性を持った意味のあるコンテキスト内でコミュニケーションとコラボレーションを行うツールを提供することにあると、企業は認識し始めています。広い意味での企業コミュニケーションプラットフォームにテレフォニーを統合することで、意思決定およびビジネスプロセス処理が加速されます。テレフォニー統合により、ユーザー対ユーザーと複数ユーザー間の相互作用が可能になります。

IBM Sametime Unified Telephony ソフトウェアは、即時性のあるインスタントメッセージ機能を電話機能と共にユーザーのデスクトップ上に提供することで、ユーザーが他のユーザーをより効率的に探し、連絡し、コラボレーションできるようにします。統合されたプレゼンス (在席確認) 状況、ソフトフォン、コール制御、ルールベースコール管理などのテレフォニー機能は、さまざまな電話システムと共に使用できます。 Unified Telephony ソフトウェアのミドルウェア層は、企業のテレフォニーインフラストラクチャや IP テレフォニーへの移行の有無とは無関係に、複数の電話システム (IP 構内交換機 (PBX) システムと既存の時分割多重方式 (TDM) システムの両方) への接続を提供します。

機能

このセクションでは、IBM Sametime Unified Telephony の利点と機能について説明します。

利点
  • ユーザーがリアルタイムコラボレーションソフトウェアの内部からテレフォニー機能にアクセスできるようにします。IBM Sametime Unified Telephony ソフトウェアのフロントエンドユーザー機能は、直観的に操作でき、Sametime クライアントの内部からテレフォニー機能に簡単にアクセスできるように設計されています。
  • 単純で一貫性を持ったユーザーコミュニケーションエクスペリエンスを実現します。これには、テレフォニープレゼンス、着信コール管理とコール制御、ワンクリックでのコール発信とソフトフォンが含まれます。ユーザーは、単一のクライアントの内部から、接続先の電話システムとは無関係に、共通の機能およびユーザーエクスペリエンスを利用できます。ユーザーは、他のユーザーが応答可能かどうかを確認でき、さまざまなロケーションのさまざまな番号を調べなくても、より効率的で信頼性が高い方法で他のユーザーに連絡できます。
  • アプリケーション内でのコミュニケーションとコラボレーションを促進して、ユーザーによるビジネスプロセスを迅速化します。Sametime および IBM Sametime Unified Telephony ソフトウェアを使用すると、希望する作業スタイルに対応した意味のあるコンテキスト内で、コミュニケーションとコラボレーションを行うことができます。ユーザーは、Sametime または IBM Notes® クライアント、 Microsoft Outlook、Microsoft Exchange、Microsoft Office アプリケーション、あるいはエンタープライズアプリケーションからアクセスし、コミュニケーションを管理できます。
  • 現在のテレフォニーインフラストラクチャや IP テレフォニーへの移行の有無とは無関係に、既存のエンタープライズアプリケーションおよびテレフォニーシステムの価値を最大限に活用できるようにします。このソフトウェアは、IP PBX システムと既存の TDM システムの両方を統合します。
  • ソフトフォン、コール管理、集約プレゼンス (在席確認) 状況によって、通信コストを削減できるようにします。ソフトフォン機能を通じたコールには、PBX 電話料金がかかりません。コール管理機能は、ユーザーの使用デバイスにコールを送信できるため、他のユーザーはいくつものデバイスを呼び出さなくても目的のユーザーを見つけることができます。プレゼンス (在席確認) 情報 (インスタントメッセージまたは電話コールにユーザーが応答可能かどうか) の集約により、他のユーザーは、無駄なコール (相手のユーザーが受けられないコール) を避けることができます。ワンクリックでの会議参加機能により、その場限りの会議に対する高価なオーディオ会議サービスのコストを削減できます。
機能
  • プレゼンス (在席確認) 状況 - テレフォニー状況が含まれます。ユーザーは、電話状況 (電話中、電話中以外など) やオンラインプレゼンス (在席確認) 状況 (応答可能、離席中、会議中、応答不可など) を一目で確認できます。これにより、インスタントメッセージまたは電話/会議コールを通じてリアルタイム通話を開始するのが適切かどうかを簡単に判断できます。
  • テレフォニーおよびボイス — Sametime Unified Telephony ソフトウェアのフロントエンドユーザー機能は、ユーザーが直観的に操作でき、Sametime クライアントの内部からテレフォニー機能に簡単にアクセスできるように設計されています。このソフトウェアは、即時性のあるインスタントメッセージ機能と電話機能を、ユーザーのデスクトップから直接使用できるようにします。ユーザーは、他のユーザーが応答可能かどうかを確認でき、相手の番号を調べなくても、より効率的で信頼性が高い方法で他のユーザーに連絡できます。相手が動き回っていても問題ありません。
    • ソフトフォンユーザーは、Sametime Unified Telephony の組み込みソフトフォンを使用して、自分の PC のマイクロホンおよびスピーカーを通じて、電話コールを開始および管理できます。
    • ワンクリックでのコール発信およびワンクリックでの会議参加 — ユーザーは、連絡先リストから 1 つまたは複数の名前を選択して、PBX 電話システムを通じて、コールまたはオーディオ会議を開始できます。インスタントメッセージを通じてコラボレーションしている複数のユーザーは、ワンクリックでのコール発信機能およびワンクリックでの会議参加機能を使用して、インスタントメッセージからコールまたはオーディオ会議にエスカレートできます。
    • 着信コール管理 — Sametime Unified Telephony ソフトウェアを使用すると、ユーザーは、自分がどのユーザーに連絡する必要があるかを考えるだけで済みます。相手がどこにいるか、どのデバイスを使用しているかを考慮する必要はありません。各ユーザーに単一の統一電話番号を割り当てることで、そのユーザーの現在のロケーションおよび現在使用しているデバイスに、コールを自動的に転送できます。ユーザーは、コールを転送するためのルールおよび設定 (携帯電話へのコールのリダイレクトなど) を簡単に設定できます。Sametime ソフトウェアはプレゼンス (在席確認) とロケーション認識機能を備えているため、Sametime Unified Telephony ソフトウェアは、状況表示とロケーション認識に基づいて、連絡先の使用デバイスを自動的に設定できます。
    • コール制御 — このソフトウェアには、参加者とモデレータ用のコール制御機能が組み込まれています。
      • 参加者コール制御
        • ワンクリックでのコール発信
        • ワンクリックでの会議参加
        • 着信コールの受信、拒否、リダイレクト
        • コールの転送
        • ボリュームの上げ下げ
        • ミュートとミュート解除
        • 別のデバイスへのコールの移動
        • コールのマージ
        • 保留と再開
        • 切断
      • モデレータコール制御
        • 1 人またはすべての参加者のミュート
        • コールのロック
        • ユーザーを招待
        • 全員のコールを終了
    • デスクトップクライアント上での単純で一貫性を持ったユーザーコミュニケーションエクスペリエンス。Sametime Unified Telephony ソフトウェアでサポートされるユーザーは、接続先の電話システムとは無関係に、共通の機能セットおよびユーザーエクスペリエンスを利用できます。しかも、これらの機能を単一のクライアントの内部から利用できます。他のオファリングで提供されるソフトフォンは、特定のベンダーが提供する PBX でしか利用できません。また、統一されたコミュニケーション/コラボレーション機能の共通セットをユーザーに提供する前に、IP テレフォニーへの完全移行が必要になります。
  • 統一されたコミュニケーションおよびコラボレーションのためのプラットフォーム
    • Sametime Unified Telephony ソフトウェアのバックエンドミドルウェア層により、複数の電話システムへの接続が提供されるため、バックエンド統合の複雑性を意識する必要がなくなります。
    • このソフトウェアは、Session Initiation Protocol (SIP) を通じて、SIP を使用する複数のベンダーが提供する SIP 準拠 PBX に接続します。また、SIP ゲートウェイを通じて、既存の TDM 電話システムに接続します。
    • テクノロジおよび通信担当のマネージャは、既存の電話システムを置き換えるのではなく、拡張することで、アクセス先の電話システムとは無関係に、統一されたコミュニケーション機能の共通セットをサポート対象ユーザーに提供できます。
    • 企業は、VoIP テレフォニーへの移行がまだ完了していなくても、ミドルウェアアプローチを利用することで、統一されたコミュニケーションの利点を事実上すべてのユーザーに提供できます。
    • Sametime Unified Telephony ソフトウェアは、数百人から数十万人までのユーザーに対応する信頼性とスケーラビリティを実現するように設計されています。

      コール制御要素は、高可用性を提供するように設計されており、コールを確実に完了できるように支援します。システムのその他の要素は、冗長性、クラスタ化、ロードバランシングをサポートして、パフォーマンスの最適化およびコンポーネント障害発生時のユーザーへのサービス提供の継続を支援します。内蔵の IBM Tivoli® System Automation for Multiplatforms (SAMP) ソフトウェアは、複数の異機種混合環境にわたるアプリケーションおよびサービスのポリシーベースの高度な自動化を実現することで、高いレベルの可用性を提供し、サービス中断の頻度および期間を低減できるように支援します。

    • Sametime Unified Telephony は、デプロイ済み環境を構成、モニター、管理するためのツールを備えています。ブラウザベースの構成インターフェースでは、テレフォニー制御サーバー、アプリケーションサーバー、Media Server の構成と、ビジネスグループ、番号計画、機能プロファイルの定義を支援します。管理コンソールは、サーバー状況をチェックし、コールボリューム、ユーザーコールアクティビティ、ライセンス使用状況をモニターし、SIP プロキシプロパティを表示および編集するために使用できます。
緊急コール

IBM が Siemens AG からライセンス交付された OpenScape ソースとは実装が異なるため、緊急コール機能の IBM 実装は、本資料の「管理」セクションにある「緊急コール」のトピックの説明どおりに機能しない場合があります。

Sametime Unified Telephony では、緊急コールは以下のように機能します。

社内ネットワークから緊急コールが発信されると、該当する PSAP (Public Safety Answering Point) の管轄区域がサービスを提供しているゲートウェイにそのコールを転送する機能が、Sametime Unified Telephony のビルトイン E911 (拡張 911) サポートによって提供されます。PSAP の ALI (Automatic Location Identification) データベースに登録されたロケーション ID が伝達されることにより、PSAP オペレータは通話者の Unified 番号の地理的ロケーションに関する情報を取得し、緊急コールの発信者または指定されたオンサイト宛先のいずれかに応答コールを行うことができます。

注: これは、発信側のデバイスの地理的ロケーションではありません。これは、Unified 番号の登録されたロケーションです。通話者が緊急コールを発信すると、その通話者に対して警告メッセージが表示され、実際の地理的ロケーションが PSAP に認識されていないことが通知されます。

Sametime Unified Telephony の緊急コールサービスは、エンタープライズシステムのほとんどの緊急規制の要件に該当します。例えば、ロケーション ID 番号とコールバック番号は、長さが 25 桁までのプロビジョン可能な番号です。

E911 アプリケーションは、Sametime Unified Telephony の汎用ソフトウェアに組み込まれており、緊急コール表と呼ばれます。このアプリケーションは組み込みであるため、独立したサーバーはなく、E911 の機能を実装するための追加の費用も発生しません。パフォーマンスは、エンタープライズネットワーク内のシステムおよびリモートゲートウェイの回復力に直接影響します。

Sametime Unified Telephony を会社のネットワーク上に配置すれば、そのユーザーが発信した E911 コールのルーティングと正しいユーザーロケーションの報告が可能になります。

ロケーションの識別
デバイスまたはクライアントによって緊急番号がダイヤルされると、E911 サービスは加入者のロケーションに関連付けられた ELIN (Enhanced Location Identification Number) と、PSAP への正しいルートを調べます。ELIN は、以前に追加情報と共に PSAP に登録されています。ロケーションは、加入者の DN から導出できます。
ソースのロケーションベースの変換とルーティング
Sametime Unified Telephony でのコールのルーティングは、通常、加入者の割り当てられた PNP (私設網番号計画) によって決められます。加入者の物理的ロケーションとは関係なく (オフィスや支店の中、ホテルからの接続や自宅からであっても)、Sametime Unified Telephony への IP 接続が可能であればいつでも、加入者はシステムに対して認証することができ、同じ PNP にバインドされます。他のプロセスや外部アプリケーションによって例外が適用されない限り、ダイヤルされた番号は必ず同じ方法で変換でされ、その結果発信されたコールは同じ宛先にルーティングされます。

サポートされるインターフェース、プロトコル、PBX デバイス、ゲートウェイ

IBM Sametime Unified Telephony では、さまざまなインターフェース、プロトコル、PBX デバイス、ゲートウェイがサポートされています。

システム要件全般については、「Sametime Unified Telephony システム要件」を参照してください。

テスト済みの PBX とゲートウェイの詳細なリストについては、Wiki の記事「Sametime Unified Telephony Tested PBXs and Gateways」を参照してください。以下のリストには、代表的なサンプルが示されています。

プロトコル
  • 専有プロトコル:
    • Virtual Places (VP) - クライアント/サーバーアプリケーションと Sametime サーバーの間の通信のために Sametime で使用される、専有プロトコル。
  • 標準プロトコル:
    • Hypertext Transfer Protocol (HTTP) - インターネットについての情報を転送するための通信プロトコル。
    • Session Initiation Protocol (SIP) - マルチメディア通信セッションのセットアップおよび分割のために使用されるシグナリングプロトコル。
    • Media Gateway Control Protocol (MGCP) - 分散 Voice over IP システム内で使用されるシグナリングおよびコール制御のプロトコル。
    • Simple Object Access Protocol (SOAP) - アプリケーションが HTTP 上で情報を交換できるようにする単純な XML ベースのプロトコル。
    • Computer-Supported Telecommunications Applications (CSTA) - 通信アプリケーション用の抽象化層。
    • SIMPLE
    • T.120
    • XMPP
    • H.323
PBX デバイス
  • IP PBX - データネットワーク上で音声を配信し、通常の公衆交換電話網 (PSTN) と相互作用します。
  • テレフォニーゲートウェイ – 別のプロトコルを使用する別のネットワークとのインターフェースを可能にする通信ネットワークノード。以下の種類があります。
    • PSTN - 世界の公衆回線交換式電話網のネットワーク。
    • TDM PBX – 一定数のチャネルおよびチャネルごとの固定帯域幅が指定されている回線モード通信で使用される時分割多重方式。
ゲートウェイ
  • Siemens ゲートウェイ
    • 非 IP PBX サイト用の SIP ゲートウェイ
    • ゲートウェイ RG8702 - 2 個の E1/T1 ポート - 60 個または 46 個の IP チャネル
    • ゲートウェイ RG8708 - 8 個の E1/T1 ポート - 240 個または 184 個の IP チャネル
    • ゲートウェイ RG8716 - 16 個の E1/T1 ポート - 480 個または 368 個の IP チャネル
    • ソフトウェア RG7800
  • Dialogic ゲートウェイ
    • DMG2030DTI - 1 個の E1/T1 ポート - 30 個の IP チャネル
    • DMG2060DTI - 2 個の E1/T1 ポート - 60 個の IP チャネル
    • DMG2120DTI - 4 個の E1/T1 ポート - 120 個の IP チャネル
仮想化

仮想化デプロイメントの場合は、VMware ESXi 4.0 仮想化プラットフォームを使用してください。必ず仮想化デプロイメントの計画の仮想化要件をお読みください。

次の作業

次に、「Sametime Unified Telephony コンポーネント」を確認します。

コンポーネントの概要

このセクションでは、IBM Sametime Unified Telephony 製品の構成要素であるコンポーネント (サーバー、クライアント、外部テレフォニーデバイスを含む) について説明します。

Sametime Unified Telephony は、いくつかのコンポーネントで構成されています。以下の図に、Sametime Unified Telephony のシステム体系を示します。IBM Sametime 製品は、以下のテレフォニーコンポーネントを提供します。
  • Sametime クライアント (テレフォニープラグインとソフトフォンを含む)
  • Sametime SIP Proxy and Registrar
  • Sametime Community Server
  • Sametime テレフォニーアプリケーションサーバー (REST API、プレゼンスアダプタ、通信アダプタ、Media Server、管理機能を含む)
  • Sametime テレフォニー制御サーバー (PBX 抽象化層と SIP B2BUA 機能を含む)
以下の外部テレフォニーコンポーネントは、サードパーティのベンダーによって提供されます。
  • IP PBX (ボイスオーバー IP プロトコルをサポートする構内交換機)
  • テレフォニーゲートウェイ
  • PSTN (公衆交換電話網)
  • TDM PBX (時分割多重方式をサポートする構内交換機)
Sametime コンポーネントと外部コンポーネントの両方を示す Sametime Unified Telephony システム体系図

主要なコンポーネントについては、個別のトピックで説明します。

  • テレフォニーアプリケーションサーバー
  • メディアサーバー
  • テレフォニー制御サーバー
  • SIP Proxy and Registrar

Sametime Community Server

Sametime サーバーを使用すると、ユーザーのコミュニティでリアルタイムアクティビティのコラボレーションが可能になります (イントラネットまたはインターネット経由のオンラインミーティング、プレゼンス (在席確認)、チャット、VoIP など)。

Sametime Connect クライアントまたは Sametime 組み込みクライアント

Sametime Connect クライアントは、コミュニティユーザーがリアルタイムアクティビティ (イントラネットまたはインターネット経由のプレゼンス (在席確認)、チャット、VoIP など) のコラボレーションをできるようにするためのエンドユーザークライアントです。

外部テレフォニーデバイス

  • IP PBX – データネットワーク上で音声を配信し、通常の公衆交換電話網 (PSTN) と相互作用するビジネス電話システム。
  • PSTN – 世界の公衆回線交換式電話網のネットワーク。
  • テレフォニーゲートウェイ – 別のプロトコルを使用する別のネットワークとのインターフェースを可能にする通信ネットワークノード。

テレフォニーアプリケーションサーバー

テレフォニーアプリケーションサーバーは、Sametime Connect クライアントを通じて、IBM Sametime Unified Telephony ユーザーにテレフォニーサービスを提供します。テレフォニーアプリケーションサーバーは、Sametime Community Server、エンタープライズディレクトリ、テレフォニー制御サーバーとのインターフェースが可能です。

テレフォニーアプリケーションサーバー

テレフォニーアプリケーションサーバーは、ユーザーのコールを処理するためのワークフローを実行します。 Sametime Unified Telephony を使用する前に、特定のテレフォニーアプリケーションサーバーにプロビジョニングされていなければなりません。ユーザーが Sametime Connect にログオンすると、テレフォニーアプリケーションサーバーに通知が送信されます。次に、そのユーザー用にチャネルが開かれ、テレフォニーサービスが使用可能であるという通知がユーザーに送信されます。

Sametime Unified Telephony の各デプロイメントには、最大 128 台のテレフォニーアプリケーションサーバーを配置することができます。

それぞれのテレフォニーアプリケーションサーバーは、最大 15,000 人のユーザーをモニターします。ユーザーアフィニティは、ユーザーが Sametime Unified Telephony クライアントを使用して Sametime サーバーにログオンすると確立されます。Sametime サーバーがテレフォニーアプリケーションサーバーにイベントを通知すると、テレフォニーアプリケーションサーバーは、Sametime Unified Telephony 機能が使用可能になるように、Sametime Connect クライアントに対するチャネルを開きます。

ユーザーは、自分自身のための使用デバイスおよび電話番号を必要な数だけ用意できます。ユーザーは、ユーザールールを使用して、時間帯、ロケーション、プレゼンス (在席確認) 状況の任意の組み合わせに応じてどのデバイスの呼び出しを希望するかを決定できます。テレフォニーアプリケーションサーバーは、高度なプレゼンス (在席確認) 機能とこのユーザールールに基づいて、これらのデバイスのいずれかを呼び出すことができます。テレフォニーアプリケーションサーバーは、サーバー障害に対する冗長性を提供するために、少なくとも 1 台のウォームスタンバイサーバーと共にデプロイされます。1 台のウォームスタンバイサーバーを使用して、1 台または 8 台すべてのテレフォニーアプリケーションサーバーに対する冗長性を提供できます。より高度な冗長性が必要な場合は、ウォームスタンバイサーバーの数を増やしてテレフォニーアプリケーションサーバーと同数にすることができます。

コンポーネント
SIP Proxy/Registrar
バージョン 8.5.2 以降、テレフォニーアプリケーションサーバーでは SIP Proxy/Registrar が提供されなくなりました。代わりに、Sametime Unified Telephony デプロイメントでは、Media Manager によって Sametime Standard デプロイメントに提供される SIP Proxy and Registrar サーバーを使用するようになりました。これにより、すべての Sametime サービス向けに、統合された SIP Proxy and Registrar が提供されます。Sametime Standard デプロイメントに Media Manager が含まれていない場合は、Sametime Unified Telephony で使用する SIP Proxy and Registrar コンポーネントを個別にデプロイすることができます (Sametime Wiki のトピック「Installing a Sametime Media Manager」を参照してください)。
プレゼンスアダプタ
このコンポーネントは、テレフォニープレゼンスを Sametime コミュニティに公開します。
通信アダプタ
このコンポーネントは、2 者間コールとオーディオ/ビデオ機能を開始、管理します。 通信アダプタは Sametime Connect クライアントに SIP レジストラの IP アドレスを通知し続けます。
Media Server
このコンポーネントは、電話会議メッセージのトーンおよびアナウンスを提供します。
管理
このコンポーネントは、メインコンポーネントの状況を表示し、ユーザーセッションおよび登録済みデバイスのリアルタイムモニターを提供します。
REST API
REST (Representational State Transfer Convention) は、Web サービスを構築するための規格です。 REST インターフェースを使用すると、ワンクリックでのコール発信およびワンクリックでの会議参加機能をサードパーティのアプリケーションと統合できます。
機能
テレフォニーアプリケーションサーバーは、以下の機能を実行します。
  • 着信コールの転送に関連するワークフローを管理するすべてのアプリケーションロジックを実行して、コールが使用デバイスに常に転送されるようにします。
  • クライアントへのすべてのコール関連イベントを開始します。Sametime Connect クライアントがオンラインである場合、テレフォニーアプリケーションサーバーは、ユーザーが着信コールに現在の使用デバイスで応答するかコールを別のデバイスに転送するかを選択できるように、ポップアップウィンドウを表示します。
  • ユーザーが送受信するすべてのコールの個人コール履歴レコードを提供します。
  • オーディオ会議のすべてのコール制御とフロー制御を処理します。
  • すべてのユーザーと構成データを管理する。
  • 初期構成の一部としてシステムに提供されるデータと、ユーザーによって管理されるデータがあります。
  • Media Server コンポーネントと連携して、限定的なオーディオ会議機能を提供します。主要なユースケースは、小規模なアドホックミーティングです。この機能は構成可能です。
  • リモート管理機能を提供できるようにします。

Media Server

IBM Sametime Unified Telephony Media Server は、テレフォニー制御サーバーフレームワークに統合されたアプリケーションです。Media Server は、テレフォニーアプリケーションサーバー (オンボード) または専用のハードウェア (オフボード) 上にインストールできます。専用のハードウェアにより、Media Server パフォーマンスが向上します。

Media Server は、以下のサービスをホストおよび実行します。
  • テレフォニー制御サーバーのアナウンスサービスをさまざまな言語で提供します。
  • 以下のオーディオコーデックをサポートし、種類が異なるコード間でトランスコードを実行できます。
    • G.711 A-Law (欧州およびその他の地域で使用)
    • G.711 μ-Law (北米および日本で使用)
    • G.729 AB

各 Media Server ノードが処理できるメディアチャネルの最大数は、あらかじめ規定されています。メディアチャネルは、アクティブ RTP ベースメディアストリームを使用するアクティブコールです。

Media Server のスケーラビリティ
以下の表は、サーバープロファイル別の Media Server のスケーラビリティを示しています。必要なハードウェア、RAM、 1 日で最も繁忙な時間帯における 1 時間当たりの最大コール速度を示しています。
表 1. サーバープロファイル別の Media Server のスケーラビリティ
サーバープロファイル CPU RAM (GB) 最大 G.711 チャネル数 最大 G.729 チャネル数 BHCA 速度
小規模サーバー デュアルコアシステム、Intel Xeon 3060 または 5030 (>= 2.33 GHz) など 4 150 50 3,000
ミッドレンジサーバー クワッドコアシステム、Intel Xeon 5345 (>= 2.33 GHz) など 4 300 100 6,000
ハイエンドサーバー IBM 3550、2 x Intel 5450 (クワッドコア 3 GHz) 8 500 160 10,000

各テレフォニーアプリケーションサーバーには、そのテレフォニーアプリケーションサーバーでの Media Server のニーズを処理するために、付属の Media Server が 1 つ提供されます。

テレフォニーアプリケーションサーバー (およびそれに対応する Media Server) が複数ある環境に拡張する場合は、特定のテレフォニーアプリケーションサーバー上で構成されたユーザーに対するトーンおよびアナウンス用にそのテレフォニーアプリケーションサーバーに対応した Media Server を使用するように、テレフォニー制御サーバーを構成する必要があります。

以下の図は、最大 100,000 人のユーザーをサポートできる標準的な Sametime Unified Telephony 環境を示しています。この環境をサポートするには、7 台のテレフォニーアプリケーションサーバーを使用し、各サーバーで最大 15,000 人のユーザーをサポートする必要があります。中央にあるのは、二重テレフォニー制御サーバーシステムです。

注: この図では、1 台のテレフォニーアプリケーションサーバーがフェイルオーバーサーバーとして使用されますが、必要とされるまではアクティブになりません。

Sametime サーバーは、運用プロファイルに応じて、30,000 人から 50,000 人のユーザーをサポートします。Sametime クラスタのサポートは、必要に応じて拡大/縮小できます。

テレフォニーアプリケーションサーバーは、1 台の Sametime サーバーまたはクラスタコミュニティに接続できます。

テレフォニーアプリケーションサーバーおよび Media Server のスケーラビリティ
Media Server 会議:
Media Server は、アドホック会議をサポートします。ユーザーがオーディオ/ビデオ機能を開始すると、Media Server 内の会議ブリッジが参加者に電話をかけます。ユーザーによってアドホック会議が開始された後で、Media Server 内の会議ブリッジは、会議ブリッジへの着信電話を受信することができます。Media Server 会議機能には、一連の独自の仕様があります。
  • 同時アドホック会議の数には、固定された制限はありません。制限は、許可される会議参加者の合計の最大数に基づきます。
  • 必要な場合、Media Server は、種類が異なるコーデック間でトランスコードを実行します。
  • 1 つの会議での会議参加者の数を構成できます。デフォルトのユーザー数は 6 人です。
  • オンボード Media Server は、400 人分の並行会議レグを処理できます。例えば、ユーザー 4 人ずつの会議を 100 件、ユーザー 5 人ずつの会議を 80 件などです。
Media Server: オフボード

Sametime Unified Telephony クラスタは、最大 8 個の外部 (オフボード) Media Server をサポートできます。テレフォニーアプリケーションサーバーと Media Server の割合は、常に 1 対 1 です。1 台のテレフォニー制御サーバーに対して、テレフォニーアプリケーションサーバーの数は最大で 8 台に制限されます。

注: トーンおよびアナウンス用の別個の Media Server を使用するように、テレフォニー制御サーバー自体を構成できます。ただし、この Media Server を会議用に使用することはできません。

フェイルオーバーの目的から、テレフォニーアプリケーションサーバーと Media Server は同じサブネット上にある必要があります。

オフボード Media Server が処理できる最大数は、以下のとおりです。
  1. 500 人分の同時電話会議レグ (G.711 コーデックを使用)
  2. 160 人分の同時電話会議レグ (G.729 コーデックを使用)

SIP Proxy and Registrar

IBM Sametime Unified Telephony は、IBM Sametime が提供する SIP Proxy and Registrar を使用します。

SIP (Session Initiation Protocol) プロトコルは、Sametime Unified Telephony のユーザー (複数可) とのセッションを作成、変更、終了するために使用されます。SIP はプロキシサーバーという要素を使用して、ユーザーのコンピュータへの要求のルーティングの支援、アプリケーション間の認証、ユーザーの許可を行います。 さらに、ユーザーが自分の現在の位置に関する情報をプロキシサーバーに送信できるようにするレジストラ機能も、SIP により提供されます。

IBM Sametime と Sametime Unified Telephony は、統合された SIP Proxy and Registrar を共有します。これにより、製品間の SIP ベースの通信が単純化されます。SIP Proxy and Registrar は、Sametime に Media Manager のコンポーネントとしてデプロイされます。IBM Sametime デプロイメントに Media Manager が含まれていない場合は、その SIP Proxy and Registrar コンポーネントを個別にデプロイして Sametime Unified Telephony で使用することができます (詳しくは、Sametime Wiki を参照してください)。

テレフォニー制御サーバー

IBM Sametime Unified Telephony デプロイメントでは、テレフォニー制御サーバーは、着信要求を受信する役割を果たします。 また、テレフォニー制御サーバーは、統一番号サービスを提供し、統一番号に着信するすべてのコールの転送を処理します。テレフォニー制御サーバーのコンテナは、バックツーバックユーザーエージェント (B2BUA) であり、その PBX 抽象化層を通じてテレフォニーアプリケーションサーバーと連携できます。

仕様

テレフォニー制御サーバーは VoIP 接続を処理します。 このサーバーは、フェイルオーバーシステムとして機能する二重構成の一部です。テレフォニー制御サーバーは、RAID ハードディスクドライブを使用した二重構成内に通常デプロイされるため、高可用性を実現できます。

テレフォニー制御サーバーには統一番号機能があります。この機能により、ユーザーの統一番号からのコールの受信についてテレフォニーアプリケーションサーバーに通知されます。さらにそのユーザーが Sametime Connect クライアントを経由して発信するすべてのコールにおいてその番号が使用されます。統一番号は、ユーザーのテレフォニーデバイスにコールを転送するための単一の電話番号です。

テレフォニー制御サーバーは、CSTA (Computer Supported Telecommunications Application) を使用して、テレフォニーアプリケーションサーバーと通信します。テレフォニーアプリケーションサーバーでは、コール関連イベントが起動および処理されます。コールがテレフォニー制御サーバーに着信し、統一番号である場合、テレフォニー制御サーバーは、CSTA を通じてテレフォニーアプリケーションサーバーに通知します。さらにテレフォニー制御サーバーは、テレフォニーアプリケーションサーバーがコールの転送先の番号を返すのを待機します。この通信はすべて CSTA を通じて行われます。

テレフォニー制御サーバーには、以下の機能コンポーネントがあります。
  • SIP B2BUA – SIP バックツーバックユーザーエージェント (B2BUA) は、SIP コールの 2 つのエンドポイントに対するユーザーエージェントです。B2BUA は、コール開始からコール終了まで、エンドポイント間でのすべての SIP シグナリングを処理します。
  • CSTA – Sametime Unified Telephony の抽象化層により、電話とコンピュータでの相互作用を統合できます。
  • 仮想化デプロイメント: 1 台または 2 台の物理サーバー (1 台になるか 2 台になるかは、デプロイメントのタイプによって異なります)。それぞれの物理サーバーで VMware ESXi 4.0 が実行されます。

    詳細は、「仮想化デプロイメントの計画」を参照してください。

  • オペレーティングシステム: SUSE Linux Enterprise Server バージョン 10 SP3 64 ビットが、Sametime Unified Telephony ソフトウェアバンドルに含まれています。
  • ソフトウェア: テレフォニー制御サーバーは、Sametime Unified Telephony の Telephony Connect コンポーネントにパッケージされています。
  • テレフォニー制御サーバーには、8 個のギガビットイーサネットポートがあり、2 セットの物理イーサネットスイッチと 3 つの仮想 LAN (課金、管理、シグナリング) が必要です。また、高可用性を保証するために、2 本のサーバー間直接相互接続ケーブルも必要です。
  • 2 台のテレフォニー制御サーバーは、以下の要件を満たす同じ第 2 層サブネット上にある必要があります。
    • 相互接続には、待ち時間が短くエラー率が低いネットワークリンクを使用する必要があります。
    • 相互接続には、5 秒以上のネットワーク障害が発生する可能性があるネットワークを使用しないようにする必要があります。
  • テレフォニー制御サーバーは、最大 100,000 人のユーザーを処理できます。テレフォニー制御サーバーは、最大 15,000 本の SIP トランクを処理できます。
  • テレフォニー制御サーバーは、PBX 間の SIP B2BUA として機能します (IP PBX と非 IP PBX の間は SIP ゲートウェイを経由します)。
  • テレフォニー制御サーバーは、SIP ゲートウェイを経由して PSTN に接続できます。テレフォニー制御サーバーは、SIP トランクを経由して IP PBX、非 IP PBX、ゲートウェイに接続されます。
  • テレフォニー制御サーバーは最大 128 台のアクティブテレフォニーアプリケーションサーバーをサポートでき、各テレフォニーアプリケーションサーバーは最大 15,000 人のユーザーをサポートできます。ユーザーの総数が 100,000 人を超えることはできません。
次の作業

標準的な「Sametime Unified Telephony デプロイメントのシナリオ」に進み、内容を参照します。

デプロイメントのシナリオ

以下の各セクションでは、Sametime Unified Telephony システムでサポートされるデプロイメントのシナリオについて説明します。

サポートされるデプロイメントのシナリオは、以下のとおりです。

最小サーバーデプロイメント

最小の IBM Sametime Unified Telephony デプロイメントは、フェイルオーバー用の 2 台のテレフォニーアプリケーションサーバー、単一の Media Server、標準の二重テレフォニー制御サーバークラスタから構成されます。

Sametime クライアントは、Domino Sametime サーバー、フェイルオーバー用に構成されたテレフォニーアプリケーションサーバーの一方、Media Server に接続されます。Media Server は、テレフォニーアプリケーションサーバー上または別個のサーバー上でホストできます。

テレフォニーアプリケーションサーバーは、テレフォニー制御サーバーに接続されています。このテレフォニー制御サーバーは、通常の PBX 装置アレイ (デスクトップ電話、時分割多重方式電話、IP-PBX システムに接続された IP 電話と携帯電話から構成される VoIP 電話) に接続されています。この最小デプロイメントは、最大 15,000 人のユーザーに対応できます。

複数のテレフォニーアプリケーションサーバーのデプロイメント

さらに複雑な IBM Sametime Unified Telephony のデプロイメントでは、複数のテレフォニーアプリケーションサーバーと、1 台のスタンバイテレフォニーアプリケーションサーバーを使用します。このフェイルオーバーソリューションでは、別のサーバーで障害が発生するとオンラインになるスタンバイテレフォニーアプリケーションサーバーが採用されています。フェイルオーバーソリューションは、IBM Tivoli® System Automation for Multiplatforms (SAMP) を使用して実装されます。

このシステムの基本原理は、すべての個別のテレフォニーアプリケーションサーバーのアプリケーション構成の詳細を、ストレージエリアネットワーク (SAN) 上の個別のパーティションに格納することです。ある特定のテレフォニーアプリケーションサーバーで障害が起こった場合、スタンバイテレフォニーアプリケーションサーバーは、SAN 上の特定のロケーションから、必要な構成設定およびアプリケーションをロードするように指示されます。

テレフォニーアプリケーションサーバーシステムが自己復元するためにかかる時間は、再ロードする必要があるユーザー数に正比例します。

IP PBX 環境でのデプロイメント

Sametime Unified Telephony ソフトウェアは、複数の混合 PBX 環境への接続をサポートします。Sametime Unified Telephony ソフトウェアは、SIP RFC 3261、3264、4566 を使用する SIP 準拠 PBX への接続をサポートするように設計されています。また、ゲートウェイを使用して 1 次群インターフェース (PRI) および基本インターフェース (BRI) をサポートする PBX への接続もサポートします。

デスクトップ電話に転送されるすべてのコールは、Sametime Unified Telephony システムによってインターセプトされる必要があります。Sametime Unified Telephony 加入者ルールに基づいて、コールが転送されます。PBX と電話の間には、ゲートウェイがあります。

PBX システムへのコールは、Sametime Unified Telephony システムを経由して、デスクトップに転送されます。お客様は、現在の電話番号を保持するか、Sametime Unified Telephony インストール済み環境用の一連の新規番号を取得するかを選択できます。多くのお客様は、通信環境での混乱を回避するために、現在の番号を保持することを選択します。電話番号は、Sametime Unified Telephony フォーマットに変換されます。これには、特殊な接頭部が含まれることがあります。コールは、使用クライアントデバイスに送信されます。

  • PBX からデスクトップ電話に転送されるコールは、デスクトップ電話に直接送信されるのではなく、Sametime Unified Telephony に転送されます。
  • Sametime Unified Telephony からデスクトップ電話へのコールは、電話に直接転送されます。
  • Sametime Unified Telephony からその他の宛先へのコールは、PBX に (および必要な場合にはその後 PSTN に) 転送されます。
  • デスクトップ電話からのコールは、必要に応じて Sametime Unified Telephony に転送する PBX に直接戻すことができます。

非 IP PBX 環境でのデプロイメント

非 IP PBX 環境での Sametime Unified Telephony デプロイメントは、最も単純な Sametime Unified Telephony インストール済み環境です。PBX とデスクトップ電話の間でコールを代行受信する必要があります。

電話からのコールは、非 IP PBX を通じて他の電話に転送されるか、公衆交換電話網 (PSTN) に転送されます。

デスクトップ電話へのすべてのコールは、代行受信される必要があり、Sametime Unified Telephony システムにリダイレクトされる必要があります。その後で、Sametime Unified Telephony は、加入者ルールに基づいて、コールの転送先を決定します。いくつかのオプションがあります。
  • 非 IP PBX に SIP インターフェースがある場合、このインターフェースは、IP 環境と時分割多重方式 (TDM) 環境の間の統合ポイントとして、ゲートウェイと同様に機能することができます。
  • PBX で SIP インターフェースを使用できない場合、SIP ゲートウェイを使用できます。この案を採用する場合、ゲートウェイは、既存の TDM トラフィックとの互換性を持つ必要があります。また、ゲートウェイと非 IP PBX の間に既知の相互運用性問題がないことを確認してください。
ゲートウェイ図
次の作業

これで、製品コンポーネントと標準的なデプロイメントシナリオを確認しました。Sametime Unified Telephony デプロイメントの計画の準備ができました。

VMware を使用する仮想化サーバー

VMware ESXi 4.x 以上の仮想化プラットフォームを使用して、仮想マシンを使用する IBM Sametime Unified Telephony をデプロイします。

仮想化デプロイメントは、物理デプロイメントと非常によく似ていますが、いくつかの追加的な制約があります。仮想化の観点から見た場合の最も重要な部分は、クロスケーブル接続です。この接続でのネットワーク遅延が原因で、断続的な障害が発生する可能性があります (あるノードが、別のノードで障害が発生したと判断してリカバリモードになる場合があります)。そのため、ノード間におけるクラスター間接続は、通常、専用のサブネット上で行われます。ただし、物理的な制限に近づいている仮想ホストに対して、断続的に過大な負荷がかかることがあり、その結果として、仮想ネットワークのパフォーマンスが影響を受ける場合があります。仮想ホストのサイズを変更する場合は、このことを考慮する必要があります。ここで、2 つの方法が考えられます。1 つは、両方のテレフォニー制御サーバーノードを、リソースが過剰に使用されないことがわかっている単一の物理ホストにデプロイする方法で、もう 1 つは、各テレフォニー制御サーバーを別々の物理ホストにデプロイする方法です (この場合は、物理ホストとそれらのホスト間のネットワークのいずれにおいても、遅延は発生しません)。システムが仮想システムであるか物理システムであるかに関わらず、シグナリングネットワーク、管理ネットワーク、課金ネットワークについて、同じネットワークオプションが用意されています。

重要: 最良の結果を得るため、最小構成の仮想化デプロイメントでは、2 つの物理ホストを組み込み、それぞれのホストでテレフォニー制御サーバーとテレフォニーアプリケーションサーバーをホスティングすることにより (例えば、第 1 のサーバーに tcs_node1/tas_node1 を配置し、第 2 のサーバーに tcs_node2/tas_node2 を配置することにより)、フェイルオーバー機能を提供する必要があります。

以下に示すいずれかの構成に、テレフォニー制御サーバーノードをデプロイすることができます。

1 台の物理サーバー上に併置
  • 管理、課金、シグナリング用に 3 つのサブネットが予約されている
  • 仮想スイッチによってクロスケーブル接続されている
2 台の物理サーバー上に併置
  • 3 つのサブネット + 1 つのプライベートの場合:
    • 管理、課金、シグナリング用に予約された 3 つのサブネットと、クロスケーブル用の 1 つのプライベート
    • ノード間のクロスケーブル接続
  • 4 つのサブネットの場合
    • 管理、課金、シグナリング、クロスケーブル用に 4 つのサブネットが予約されている
    • レイヤー 2 スイッチを使用してクロスケーブル接続が行われる

2 台の物理サーバー上で地理的に分離

ノードごとに 4 つのサブネット (合計 8 個のサブネット)
  • ノード 1 の管理、課金、シグナリング、クロスケーブル用に 4 つのサブネットが予約されている
  • ノード 2 の管理、課金、シグナリング、クロスケーブル用に 4 つのサブネットが予約されている

計画

IBM Sametime Unified Telephony デプロイメントをインストールする前に、このセクションをお読みください。

システム要件

IBM Sametime Unified Telephony デプロイメントの計画を作成する際には、必ずシステム要件を確認して、必要なハードウェアとソフトウェアがすべて揃っていることを確認してください。

すべての IBM Sametime 製品のシステム要件は、「Detailed system requirements for Sametime and Sametime Unified Telephony」という IBM 技術情報に記載されています。

仮想化の要件

VMware ESXi 4.x 以上の仮想化プラットフォームを使用する仮想化デプロイメントの場合、すべてのコンポーネントが仮想化デプロイメントの計画に記載されている最小要件を満たしている必要があります。

注: ソフトウェアとハードウェアの詳細な推奨事項については、『VMware Compatibility Guides』を参照してください。仮想マシンのオーバーヘッド特性に関する情報は、VMware 資料のページで、VMware の各バージョンに対応する『VMware リソース管理ガイド』を参照してください。

仮想化デプロイメントの計画

専用のハードウェアを使用してデプロイするのではなく、最初に VMware ESXi 4.x 以上の仮想化プラットフォームを任意のサポートされるハードウェアにインストールしてから、Sametime Unified Telephony サーバーを VMware ホストにデプロイすることにより、IBM Sametime Unified Telephony の仮想化デプロイメントを作成することができます。

始める前に

仮想化された Sametime Unified Telephonyサーバーをホストする各サーバーに、VMware ESXi 4.x 以上の仮想化プラットフォームをインストールします。ソフトウェアとハードウェアの詳細な推奨事項については、『VMware Compatibility Guides』を参照してください。仮想マシンのオーバーヘッド特性に関する情報は、VMware 資料のページで、VMware の各バージョンに対応する『VMware リソース管理ガイド』を参照してください。

このタスクについて

仮想マシンとは、別個のコンピュータと同様に動作する自己完結型オペレーティングシステムのことです。仮想環境は、ハードウェアには依存せず、仮想化プラットフォームに依存して、必要なハードウェアの動作を模倣します。Sametime Unified Telephony は、標準の二重構成 (併置および地理的分離) 用に、VMware 仮想化プラットフォームの使用をサポートします。使用されるハードウェアは、すべて VMware 互換性リストに登録されている必要があります。

注: 仮想化デプロイメントはハードウェアには依存しないため、IBM は、ユーザーのデプロイメントでどのハードウェアが使用されるかを予測することはできません。本書に記載されている例では、IBM System x3550 M4 サーバー (the x3550 M2 と x3550 M3 はサポートされていますが、使用できない可能性があります) のインストールとセットアップについて説明しています。

仮想マシンの仕様は、CPU、メモリ、ハードディスクに関しては、基本的に物理マシンと同じですが、仮想システムの CPU 上ではハイパースレッドが使用不可になっている必要があるという点が異なります。これは、非常に重要な相違点です。

仮想化された Sametime Unified Telephony デプロイメントには、以下に示す固有の特性があります。
  • 「データストア」と呼ばれる、ストレージエリア内の Sametime Unified Telephony イメージをサポートします。
  • ハードウェアに依存しません。
  • メンテナンスコントローラインターフェース (RSA、IMM、iRMC、VMK) はありません。
  • ハードウェアアラームをサポートしません。
  • 現在サポートされ、必要とされる (仮想) イーサネットポートの数は 4 個で、この数字は固定されています。
  • 併置されている 2 ノードのクラスタリングと、ネットワークで地理的に分離されている 2 ノードのクラスタリングをサポートします。
  • 1 台のホスト (同じ物理ホスト上に両方のノードが存在する) または 2 台のホストに併置してデプロイすることも、2 台のホスト上に地理的に分離されたシステムとしてデプロイすることもできます。
  • 内部ストレージを使用することも、SAN ストレージを使用することもできます。
  • VMware との互換性があります。使用されるハードウェアは、すべて VMware 互換性リストに登録されている必要があります。
  • 140 GB 以上の仮想マシンディスクが必要です。
仮想化デプロイメントには、以下の制限があります。
  • ハイパースレッドが CPU 上で使用不可になっている必要があります。
  • ISO イメージファイルからのインストール時に、仮想化イメージ DVD ISO とノード構成ファイルを配置するために、ノードのデータストアに 5 GB 以上のディスクスペースを割り振る必要があります。
  • 仮想マシンはハードウェアには依存しないため、物理サーバーと仮想化プラットフォームのインストール、管理、保守は、お客様側で行うことを前提としています。本書では、物理サーバーや VMware 仮想化プラットフォームをデプロイする方法については説明していません。
  • 仮想 Sametime Unified Telephony サーバーは、1 つのディスクと 4 つのイーサネットポートがあることを前提としています。
  • ディスクのロケーション (ローカルまたはネットワーク)、ディスク冗長性 (RAID)、ハードウェア冗長性、ネットワーク冗長性 (ボンディングドライバ) は、仮想 Sametime Unified Telephony サーバーの制御の範囲外であるため、お客様側でインストールする必要があります。
重要: VMware プラットフォームは、標準の Sametime Unified Telephony サーバーよりも広範囲のハードウェアをサポートしますが、使用しているサーバーが、ここで説明する最小要件を満たしているかどうかを確認する必要があります。これらの要件を満たしていない場合、パフォーマンスが低下したり、製品が機能しない可能性があります。

手順

以下の手順を実行して、仮想化環境を正しく準備してください。

  1. このサブセクションに記載されている仮想化の要件を確認します。
  2. 使用している物理サーバーハードウェアが VMware でサポートされていることを確認します。
  3. SAN (ストレージエリアネットワーク) ドライブをデプロイするか、物理サーバーのローカルハードディスクを使用するかを決定します。
  4. SAN に接続する場合は、SAN が VMware によってサポートされていることを確認します。
  5. テレフォニー制御サーバーアプリケーションのインストール用に node.cfg ファイルをビルドして仮想フロッピーディスクに配置するために、使用可能な Microsoft Windows システムまたは Linux システムが稼働していることを確認してください。
  6. ネットワーク冗長性が必要な場合は、NIC チーミングを使用して VMware ホストを構成し、ネットワークポートと VMNIC とのマッピングを決定します。
  7. 実行するインストール構成のタイプを決定します (併置タイプまたは地理的分離タイプのいずれか)。
  8. 併置構成の場合、ゲストサーバーを 1 台の物理ホストサーバーで実行するか、2 台の物理ホストサーバーで実行するかを決定します。
  9. 上記ステップで決定した構成に基づいて、ネットワークケーブル接続を決定します。
  10. VMware リリース情報に記載されている仕様に従って、ゲスト仮想マシンを作成します。
  11. テレフォニー制御サーバーイメージを各仮想マシンにインストールします。

仮想化されたテレフォニー制御サーバーの要件

仮想化されたテレフォニー制御サーバーは、ハードウェアには依存しません。ただし、製品を正しく機能させるには、使用する物理サーバーが、特定の一連の最小要件を満たしている必要があります。

仮想化されたテレフォニー制御サーバーをインストールする前に、物理サーバーが以下の最小要件を満たしていることを確認してください。

仮想マシンをホストするための物理サーバーの要件

1 つ以上の仮想マシンをホストする各物理サーバーは、パフォーマンスを確保するために、一連の要件を満たす必要があります。以下に記載する数値は最小要件であり、デプロイメント環境でサポートされるユーザー数によって変わります。ここでは、標準的なエンタープライズフィーチャーが、連続トレース/分散登録/別個のサーバー上のノード/アクティブスタンバイモードなしで設定されていることを前提としています。

オーバーヘッド要件

各物理サーバーは、以下のオーバーヘッド要件を満たしている必要があります。一部の値は、物理サーバーの構成に依存するため、ここでは予測できないことに注意してください。

表 2. 仮想化オーバーヘッド要件. 各要件は各物理サーバーに適用されます。
ハードウェア 説明 サイズ
ハードディスク VMware システムディスクオーバーヘッド 17 GB
ハードディスク すべての予約されていない VM メモリのスワップスペースのオーバーヘッド 不明 (GB)

この値を厳密に定義することはできません。一部のメモリを予約していない他の VM を、物理サーバーがホストしている可能性があるためです。

ハードディスク スナップショットのオーバーヘッド (使用されている場合) 不明 (GB)

この値を厳密に定義することはできません。ユーザーがスナップショットを使用するかどうかによって異なるためです。

RAM VMware システムオーバーヘッド 2.5 GB
CPU VMware システムオーバーヘッド 不明 (MHz)

VSphere リソース管理ガイド』を参照してください。

一般要件

各物理サーバーがホストする仮想マシンに適切なリソースが割り当てられるように、各物理サーバーは以下の一般要件を満たしている必要があります。

表 3. 物理サーバーの一般要件. 各要件は各物理サーバーに適用されます。
要件 1 - 1.000 ユーザー 1001 - 5,000 ユーザー 5001 - 10,000 ユーザー 10,001 - 15,000 ユーザー
影響を受けるサーバー 各物理サーバー (各ノード) 各物理サーバー (各ノード) 各物理サーバー (各ノード) 各物理サーバー (各ノード)
ゲストオペレーティングシステム SLES 10 SP3 SLES 10 SP3 SLES 10 SP3 SLES 10 SP3
リアルタイムアプリケーション
注: 可用性を保証するため、リアルタイムアプリケーション用にリソースが予約されている必要があります。
Y Y Y Y
vNIC の数 4 4 4 4
ネットワーク帯域幅 (Kbps) 319 1598 3194 16000
手動 MAC を使用 はい はい はい Yespda
注: 次のことに注意してください。
  • ライセンスバインディングには固定 MAC アドレスが必要です。固定 (手動) MAC アドレスを使用すると、どの VMware 機能によっても MAC アドレスが変更されることはありません。
  • ネットワーク使用量は、コールの使用量とデプロイされている機能に基づいて変わる場合があります。
  • 合計帯域幅 (KB/s) 要件の数式は cps*46 です。cps (1 秒当たりのコール数) の数式は、ユーザー数 * 5 / 3600 * 5 です (1 時間当たりユーザー 1 人につき 5 回のコール、フィーチャーの負荷率は 5)。
  • 別個の物理サーバーにノードをデプロイして、ハードウェア冗長性を提供することをお勧めします。複数のノードが同じ物理サーバー上に存在する場合、X チャネルのトラフィックは物理ネットワークを使用しません。
  • X チャネル帯域幅 (KB/s) 要件の数式は cps*35 です。cps は、前述の数式によって計算されます。
ディスク要件

各物理サーバーがホストする仮想マシンが適切なリソースが割り当てられるように、各物理サーバーは以下の構成要件を満たしている必要があります。

表 4. 物理サーバーのディスク要件. 各要件は各物理サーバーに適用されます。
要件 1 - 1,000 ユーザー 1001 - 5,000 ユーザー 5001 - 10,000 ユーザー 10,001 - 15,000 ユーザー
仮想マシンのディスクスペース 140 GB 140 GB 140 GB 140 GB
IOPS - 1 秒当たりの入出力操作数 (ストレージ I/O)
注:VMware リソース管理ガイド』より: 自動ストレージ階層化機能のあるアレイによってバックアップされるデータストアに対してストレージ入出力制御を使用する前に、VMware の『ストレージ/SAN 互換性ガイド』を調べて、ご使用の自動階層ストレージアレイに、ストレージ入出力制御との互換性があることを認証済みであるかどうかを確認してください。
共有 = N + 無制限 IOPS (デフォルト) 共有 = N + 無制限 IOPS (デフォルト) 共有 = N + 無制限 IOPS (デフォルト) 共有 = N + 無制限 IOPS (デフォルト)
ディスクスループット (Kbps) 23 113 225 1129
仮想ディスクモード 独立永続 独立永続 独立永続 独立永続
仮想ディスクフォーマットタイプ
注: シック (Lazy Zeroed) 仮想ディスクを使用すると、最初にブロックがディスクに書き込まれるときの遅延が短縮され、作成時に確実にすべてのスペースが割り振られて初期化されるようになります。Fault Tolerance を使用するには、「シンディスク」を「シック (Eager Zeroed)」に変換する必要があります。
"シック (Lazy Zeroed)" "シック (Lazy Zeroed)" "シック (Lazy Zeroed)" "シック (Lazy Zeroed)"
イメージ、パッチセット、大規模プロビジョニングファイル、復元 CD などを保持するための、追加のハードディスクスペースがサーバー/SAN 上に必要です。 10 GB 10 GB 10 GB 10 GB
注: 次のことに注意してください。
  • ログファイルとトレースファイルを保管するための追加のディスクスペースが必要になる場合があります (/software ディレクトリ内)。
  • ディスク使用量は、コールの使用量とデプロイしている機能に基づいて変わる場合があります。
  • ハードディスク (KB/s) の数式は cps*3.25 です。cps (1 秒当たりのコール数) の数式は、ユーザー数 * 5 / 3600 * 5 です (1 時間当たりユーザー 1 人につき 5 回のコール、フィーチャーの負荷率は 5)。
CPU 要件

各物理サーバーがホストする仮想マシンが適切なリソースが割り当てられるように、各物理サーバーは以下の構成要件を満たしている必要があります。

表 5. 物理サーバーの CPU 要件. 各要件は各物理サーバーに適用されます。
要件 1 - 1.000 ユーザー 1001 - 5,000 ユーザー 5001 - 10,000 ユーザー 10,001 - 15,000 ユーザー
vCPU 2 2 4 8
vCPU 共有 (H= 高、N= 標準) H H H H
vCPU 予約 (MHz) 5000 5000 10000 20000
vCPU 制限 (MHz) 5000 5000 10000 20000

8 個の CPU が必要な場合、CPU が 4 つしかない仮想ホストでも、8 個の CPU をエミュレートする仮想マシンを作成できます。ただし、これにより CPU のコンテンションが発生することがあり、マシンの負荷はそれほど重くないように見えても、そのコンテンションのためにパフォーマンスが悪化します。例えば、オンボード Media Server を持つテレフォニーアプリケーションサーバーには、8 個のコア (4 コア CPU が 2 個) が必要です。基礎となる物理ホストマシンで、少なくともこの数のコアが使用可能になっていない場合、CPU の競合が発生します。

メモリ要件

各物理サーバーがホストする仮想マシンが適切なリソースが割り当てられるように、各物理サーバーは以下の構成要件を満たしている必要があります。

表 6. 物理サーバーのメモリ要件. 各要件は各物理サーバーに適用されます。
要件 1 - 1.000 ユーザー 1001 - 5,000 ユーザー 5001 - 10,000 ユーザー 10,001 - 15,000 ユーザー
VM メモリー (GB) 4 4 8 8
VM メモリ共有 (H= 高、N= 標準) N N N N
VM メモリ予約 (GB) 4 4 8 8
VM メモリ制限 (GB) 4 4 8 8
サポートされる機能

各物理サーバーがホストする仮想マシンが適切なリソースが割り当てられるように、各物理サーバーは以下の構成要件を満たしている必要があります。

表 7. 物理サーバーのサポートされる機能. 各要件は各物理サーバーに適用されます。
機能 1 - 1.000 ユーザー 1001 - 5,000 ユーザー 5001 - 10,000 ユーザー 10,001 - 15,000 ユーザー
VMware 手動 MAC が使用される Y Y Y Y
VMware VMotion がサポートされる 将来の更新時に計画 将来の更新時に計画 将来の更新時に計画 将来の更新時に計画
VMware High Availability がサポートされる 将来の更新時に計画 将来の更新時に計画 将来の更新時に計画 将来の更新時に計画
VMware Fault Tolerance がサポートされる N N N N
VMware Distributed Resource Scheduler (DRS) がサポートされる vMotion で必須 vMotion で必須 vMotion で必須 vMotion で必須
VMware Data Recovery がサポートされる N (vApp で計画) N (vApp で計画) N (vApp で計画) N (vApp で計画)
VMXNET3 仮想ネットワークアダプタがサポートされる
注: サポートされる場合は、VMXNET3 の製品固有のインストール/構成資料のセクションを参照してください。
N (vApp で計画) N (vApp で計画) N (vApp で計画) N (vApp で計画)
仮想マシンのハードディスク要件

仮想マシンごとに必要なディスクスペースの量は、スナップショット、インストールイメージ、VMware 自体のスペースなど、さまざまな要因によって異なります。以下の情報を参照して、各仮想マシンをホストする物理サーバーで必要な最小ディスクスペースを判別してください。

ここに示す情報は、仮想マシンをホストするための物理サーバーの要件仮想マシンをホストするためのその他の要件に記載されている一般的なハードディスク要件の補足です。

仮想化された IBM Sametime Unified Telephony では、仮想マシンがターゲット (0:0) 上の単一の SCSI ディスクを表す必要があります。仮想マシンのディスクサイズは 140 GB でなければなりません。ただし、VMware 自体が追加で 40 GB を必要とするため、専用物理サーバー上の単一の Sametime Unified Telephony 仮想マシンの場合、ホストサーバーのディスクドライブは 180 GB 以上にする必要があります (140 GB + 40 GB)。

単一の物理サーバー上で併置の仮想マシンを構成する場合、追加の仮想マシン用にさらに 140 GB のディスクスペースが必要になるため、合計で 320 GB (140 GB + 140 GB + 40 GB) になります。

VMware と ISO のイメージ用の割り当て量を含めた物理ハードディスクサイズは、以下の項目に基づいて計算されます。
  • アップグレード時の新規イメージ + 古いイメージ: 10GB
  • 復元 CD: 100 MB
  • VMware マシンのオーバーヘッド用の割り当て: 3 GB (140 GB の VM ディスクサイズ)
  • VMware システムディスクオーバーヘッド用の割り当て: 17 GB
注: 物理ハードディスクサイズの計算には、スナップショットで必要になるスペースと、メモリを予約しない他の仮想マシンで必要となるスワップスペース用のスペースは含まれていません。

仮想 SCSI コントローラは、LSI Logic パラレルタイプでなければなりません。物理ディスクは、ホストでオンボードになっていても、SAN で接続されていてもかまいません。どのレベルの RAID も使用できます。ディスク予約パラメータは、デフォルト設定のままにしておく必要があります。

仮想マシンのネットワーク要件

仮想化された IBM Sametime Unified Telephony デプロイメントでは、仮想マシンの作成時に、4 個のサブネットがラベルとして提示される必要があります。これらのラベルは、Sametime Unified Telephony に対して提示されるため、それぞれ異なるサブネット内に存在する必要があります。これらのサブネットは、テレフォニー制御サーバーをインストールするための node.cfg ファイルをビルドする際に使用されます。

VMware を使用する仮想化サーバーで説明しているように、インストールする構成のタイプに基づいてサブネットを構成することができます。それぞれのケースで、以下に示す 4 つのサブネットが必要です (各サブネットは、特定のネットワークインターフェースカードに割り当てられます)。

  • 管理サブネット (NIC1 に割り当てられます)

    管理情報と保守情報で使用されます。

  • シグナリングサブネット (NIC2 に割り当てられます)

    SIP/CSTA/MGCP 信号に使用されます。

  • クロス接続 (NIC3 に割り当てられます)
    コール状態の同期で使用されます。
    • 複数の仮想マシンが同一のホスト上に併置されている場合、これは仮想スイッチ専用の接続になります。
    • 複数の仮想マシンが個別のホストに併置されている場合、これはギガビット品質の直接イーサネットケーブルクロス接続になります。
    • 複数の仮想マシンが地理的に分離されたシステムである場合、これは L2 ブリッジ接続でも L3 routed 接続でもかまいません。
  • 課金サブネット (NIC4 に割り当てられます)

    CDR を課金サーバーに送信するために使用されます。

重要: 実際のネットワークへのラベルの接続は、ユーザーのネットワーク構成によって異なります。これは、フラットネットワークでもセグメント化されたネットワークでもかまいません。また、VMware VLAN 機能を使用することもできます。必要な場合は、VMware ネットワークインターフェース冗長性を使用することもできます。ただし、クロス接続リンクは除きます。トラフィックが重いことと、併置または地理的に分離された L2 ブリッジ接続の L2 としての特性が原因で、このリンクは専用リンクでなければなりません。

サブネットは、仮想マシン内で E1000 タイプとして作成する必要があります。

仮想マシンをホストするためのその他の要件

構成に使用されるパラメータを除き、ほとんどの仮想マシンパラメータは、デフォルトの設定値のままにしておく必要があります。ただし、以下で説明するように、いくつかの例外があります。

仮想化デプロイメントで最高のパフォーマンスを実現するには、以下の仮想マシンパラメータを、説明に従って設定する必要があります。

  • ハイパースレッドをオンにする必要があります (使用可能な場合)。
  • 重要: CDROM は仮想デバイスノード IDE(0:0) 上になければなりません。これはデフォルト設定ではないため、必ず設定を更新してください。
  • インストールを容易にする場合は、電源投入時に接続するように CDROM を設定する必要があります。
  • インストールを容易にする場合は、ブートオプションで [次回のリブート時に BIOS フラグを強制 (force BIOS flag on next reboot)] フラグを設定する必要があります。

仮想化されたテレフォニーアプリケーションサーバーの要件

仮想化されたテレフォニーアプリケーションサーバーは、ハードウェアには依存しません。ただし、製品を正しく機能させるには、使用する物理サーバーが、特定の一連の最小要件を満たしている必要があります。

テレフォニーアプリケーションサーバーの場合、仮想化は、標準の二重デプロイメントについてのみサポートされます。仮想化されたテレフォニーアプリケーションサーバーをインストールする前に、物理サーバーが以下の最小要件 (最大 15,000 人のユーザーをサポート) を満たしていることを確認してください。

  • ハードディスクサイズ: 140 GB
  • コアの数: 8
  • CPU 共有: 高
  • 周波数: 21280 MHz
  • RAM: 10GB
注: 次のことに注意してください。
  • テレフォニーアプリケーションサーバーは 32 ビットをサポートしないため、VM は 64 ビットモードで実行する必要があります。
  • 複数の仮想マシンを同じ物理サーバーに格納する場合、各仮想マシンには 10 GB の RAM が必要になります。また、合計サイズよりも 2 GB 分だけ多く予約する必要があります。例えば、物理サーバーで 2 つの仮想マシンをホストする場合、このサーバーには 10 GB + 10 GB + 2 GB = 22 GB の RAM が必要になります。
  • 実稼働環境では、必要な量の RAM をサーバー上で物理的に使用可能な状態にし、ノード用に予約しておくことを強くお勧めします。
  • 必要な数の CPU リソースを予約しておくことを強くお勧めします。予約する CPU 周波数は、ノードで必要になるコア数に、VMware 構成で必要になるプロセッサ周波数を乗算することによって計算できます。例: 標準二重 (小規模) ノードの仕様で、2.66 GHz の CPU で 8 個のコアが必要になる場合は、21280 MHz (8×2660 MHz) を予約する必要があります。

サーバーアップグレードの計画

IBM Sametime Unified Telephony をアップグレードする前に、全体的なアップグレードプロセスを確認しておく必要があります。

Sametime Unified Telephony は、Sametime の機能を拡張するための製品であり、同製品のコンポーネントに依存します。Sametime のアップグレードが正常に完了するまで、Sametime Unified Telephony のアップグレードを実行しないでください。

重要: IBM WebSphere Application Server が大幅に変更されたため、既存のテレフォニーアプリケーションサーバーをアップグレードすることはできません。WebSphere Application Server 7 をアンインストールし、WebSphere Application Server 8.5 を使用してフレッシュインストールを実行してから、新しいテレフォニーアプリケーションサーバーをインストールする必要があります。

アップグレードの対象となる項目

Sametime Unified Telephony デプロイメントをアップグレードするには、すべてのテレフォニー制御サーバー、テレフォニーアプリケーションサーバー、Media Server、SIP Proxy and Registrar をアップグレードする必要があります。各サーバーは別個にアップグレードする必要があります。アップグレードプロセスの実行中はユーザーがデプロイメントを利用できないため、アップグレードは需要の少ない期間に行う必要があります。

アップグレードプロセスについて

アップグレードは、以下のように段階的に行います。
  1. すべてのテレフォニー制御サーバーとテレフォニーアプリケーションサーバーのシステム全体のバックアップを行います。
  2. コンポーネントをインストールおよびアップグレードします。
  3. システム構成を実行します。
  4. ユーザーに対してサービスを復元します。

システムアップグレードの実行手順については、セクション8.5.2 Interim Feature リリース 1 からのアップグレードで説明します。

次の作業

アップグレードの計画を立てたら、Sametime Unified Telephony のアップグレードの準備は完了です。

Jabra と Plantronics が提供する推奨ヘッドセット

ユーザーが自分のコンピュータを電話コールで使用する場合、標準装備のマイクとスピーカーを使用することができます。ただし、エコーやバックグラウンドノイズを減らし、通話内容の漏れを防ぐために、ヘッドセットを使用することを強くお勧めします。 Jabra と Plantronics は、IBM Sametime Unified Telephony と IBM Sametime Unified Telephony Lite Client の両方でテストされ、正しく機能するヘッドセットを提供します。

Jabra が提供する推奨ヘッドセット

推奨ヘッドセットについては、Jabra の Web サイトにある互換性ガイドを参照してください。「クイックセレクタ」で、メーカーとして [IBM] を選択し、モデルとして [IBM Sametime Unified Telephony] (表示される任意のバージョン) を選択します。

Plantronics が提供する推奨ヘッドセット

推奨ヘッドセットを調べるには、以下のいずれかを実行します。
注: 無料で Symphony をダウンロードできます。