この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
この章では、Cisco Unified Communications システムで利用可能なボイス メッセージング ソリューションについて説明します。この章では、シスコのボイス メッセージング製品である Cisco Unity Connection、および Cisco Unity Express を取り上げ、これらの製品を Cisco Unified Communications Manager(Unified CM)とともに配置するための設計ガイドラインとベスト プラクティスを説明します。また、この章では、業界標準プロトコルを使用した、サードパーティ製ボイスメール システムとの統合についても説明します。
このガイドでは、Unified CM に関するメッセージング配置のシナリオが中心ですが、特に、集中型 Unified CM 配置の Survivable Remote Site Telephony(SRST)フォールバック サポートで使用される場合には、適宜、Cisco Unified Communications Manager Express(Unified CME)についても説明します。
この章ではまず、Cisco メッセージング ソリューションのポートフォリオの各製品について簡単に説明した後、企業向け Unified Communications ソリューションにおける各製品の位置付けに関する簡単な概要を示します。次に、メッセージング配置モデルを基盤として、ボイスメール統合を説明します。ここではまず、さまざまなメッセージング配置モデルを定義した後、さまざまな Unified CM 呼処理配置モデルにおける各メッセージング配置モデルの位置付けを説明します。この項では、Cisco Unity Connection について説明します。Cisco Unity Express については、別に専用の項を設けて、サポートされる配置モデルを説明します。シスコのボイス メッセージング製品ポート フォリオ内で利用可能な相互運用性のための主要な設計ガイドラインについて説明します。仮想化では、仮想システム設計時に考慮する必要がある重要な設計上の要素についても説明します。この項では、トランスコーディングや Unified CM とのさまざまな統合を含む、多くのシステムレベルの設計上の考慮事項およびベスト プラクティスについて説明します。さらに、この章では、サポートされている業界標準プロトコルを使用したサードパーティ製ボイスメール統合の詳細について説明します。
この章では、基本設計に関する説明を行います。また、Unified CM を使用してコラボレーション システムにボイス メッセージング製品をどのように組み込むかに重点を置いて説明します。各製品の詳細な設計ガイドラインおよびサードパーティ製のメッセージングとテレフォニー システムの相互運用性に関する情報については、次に示す Cisco Unity Connection の設計ガイドを参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unity-connection/products-implementation-design-guides-list.html
Cisco Unified Communications のメッセージング ポートフォリオは、Cisco Unity Connection と Cisco Unity Express の 2 つの主なメッセージング製品で構成されます。それぞれの製品が対応する要件は異なりますが、互いに他の製品と重なり合う機能とスケーラビリティを備えています。また、ボイス メール ネットワーキングを使用して互いに連携する機能により、この章で後ほど説明するとおり、より高いスケーラビリティに加えてボイスメールの相互運用性を実現します。
これらの製品を検討する場合、それらに搭載されたメッセージング オプションを理解し、特定の配置要件に適したオプションを判断するためには、製品が該当するメッセージング タイプを考慮することが役立ちます。次の定義は、このようなメッセージング タイプの説明に役立ちます。
表 19-1 は、これらのタイプのメッセージングをサポートするシスコ製品を示します。
|
|
|
---|---|---|
(注) Cisco Unity Connection を使用したユニファイド メッセージングの詳細については、Cisco Unity Connection による単一受信トレイを参照してください。
上のメッセージング タイプと定義に基づき、次の 2 つのメッセージング製品のオプションが用意されています。
このオプションは、20,000 ユーザ以下の中規模企業用に、ユニファイド/統合メッセージング、音声認識、およびコール転送ルールを 1 つのシステムに組み合わせて管理しやすくしたものです。また、デジタルまたは HTTP ネットワーク システムを使用して、複数の Cisco Unity Connection クラスタを組み合わせることができます。(必要であれば、さらに Voice Profile for Internet Mail(VPIM)ネットワーキングを使用して、100,000 人を超えるユーザをサポートするために 2 つの HTTP またはデジタル ネットワーク システムを結合することができます)。Cisco Unity Connection は、1 つのデジタル ネットワークまたは HTTPS ネットワーク上で最大 100,000 人のユーザをサポートできます。Cisco Unity Connection は、Cisco Business Edition でも利用できます。Cisco Business Edition 6000 は、最大 1,000 人のユーザまでサポートします。Cisco Business Edition 7000 では、通常の Cisco Unity Connection のキャパシティ プランニング ルールが適用されます。Cisco Business Edition の詳細については、呼処理の設計上の考慮事項を参照してください。
このオプションは、中小規模企業および 500 ユーザ以下の支社用に、特定の Cisco サービス統合型ルータ(ISR)で、コスト効率の良いボイス メッセージングおよび統合メッセージング、自動応答、および自動音声応答(IVR)の各機能を提供します。Cisco Business Edition 4000 の一部として、Cisco ISR 4321 上のコンテナとして展開された Unity Express は最大で 200 人のユーザをサポートします。
製品機能の比較については、次の場所にある機能比較資料を参照してください。
https://www.cisco.com/c/en/us/products/unified-communications/unity-connection/datasheet-listing.html
ボイス メッセージング製品のスケーラビリティの詳細については、コラボレーション ソリューション サイジング ガイダンスの章のボイス メッセージングの項を参照してください。
この章では、Cisco Unity Connection および Cisco Unity Express と Cisco Unified Communications Manager(Unified CM)の統合について、設計上の側面を中心に説明します。Cisco Unified CM には、Session Initiation Protocol(SIP)トランクの機能が搭載されているため、SIP プロキシ サーバを配置することなく、直接 Cisco Unity Connection と統合できます。
上で説明したように、この章で扱う設計に関するトピックは、ボイスメールのみの設定、ユニファイド メッセージング設定、およびユニファイド メッセージング設定に適用されます。さらに、この章では、Microsoft Exchange(2003、2007、または 2010)と Cisco Unity Connection の配置の設計面について説明します。Cisco Unity Connection および Unity Express は外部メッセージ ストアに依存しません。
Cisco Unity Connection に関するその他の設計情報(他のシスコ以外のメッセージング システムとの統合など)については、次の場所にある『 Design Guide for Cisco Unity Connection 』の最新版を参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unity-connection/products-implementation-design-guides-list.html
Cisco Unity Express に関するその他の設計情報(他のシスコ以外のメッセージング システムとの統合など)については、次の Web サイトで入手可能な適当な製品マニュアルを参照してください。
https://www.cisco.com/c/en/us/products/unified-communications/unity-express/index.html
この章では、Cisco Unity Connection および Cisco Unity Express について、さまざまなメッセージング配置モデルの概要を示します。Cisco Unity Connection に固有の配置モデルや設計に関する考慮事項とさまざまなメッセージング コンポーネントの詳細については、次の場所にある『 Design Guide for Cisco Unity Connection 』の最新版を参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unity-connection/products-implementation-design-guides-list.html
Cisco Unity Express については、次の Web サイトで入手可能な適当な製品マニュアルを参照してください。
https://www.cisco.com/c/en/us/products/unified-communications/unity-express/index.html
Cisco Unity Connection は、次の 3 つの主なメッセージング配置モデルをサポートしています。
Cisco Unity Express もまた、次の 3 つの主なメッセージング配置モデルをサポートしています。
(注) Cisco Unity Express は、最大 10 の Unified CME を持つ集中型ボイス メッセージングをサポートします。詳細については、https://www.cisco.com/c/en/us/products/unified-communications/unified-communications-manager-express/index.html にある Cisco Unified Communications Manager Express のマニュアルを参照してください。
Cisco Unified CM と Unified CME の呼処理配置モデルは、Cisco Unity Connection および Unity Express のメッセージング配置モデルに依存しませんが、互いに対して考慮が必要な暗黙的要件があります。
アクティブ/アクティブ設定では、Cisco Unity Connection のメッセージング冗長性を利用できます。詳細については、次の場所にある『 Design Guide for Cisco Unity Connection 』の最新版を参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unity-connection/products-implementation-design-guides-list.html
すべてのメッセージング配置モデルが、ボイスメール、ユニファイド メッセージング、およびユニファイド メッセージングのインストールをサポートしています。
このモデルでは、メッセージング システムとメッセージング インフラストラクチャ コンポーネントがすべて、同じサイトのアベイラビリティの高い同じ LAN 上に置かれます。サイトは、単一サイトである場合も、高速メトロポリタン エリア ネットワーク(MAN)を介して相互接続されたキャンパス サイトである場合もあります。メッセージング システムのクライアントもすべて、単一(またはキャンパス)サイトに置かれます。このモデルの際立った特徴は、リモート クライアントが存在しないことです。
このモデルでは、単一サイト モデルと同様に、メッセージング システムとメッセージング インフラストラクチャ コンポーネントがすべて、同じサイトに置かれます。サイトは、1 つの物理的なサイトである場合も、高速 MAN を介して相互接続されたキャンパス サイトである場合もあります。ただし、単一サイト モデルとは異なり、メッセージング クライアントをローカルとリモートの両方に置くことができます。
分散型メッセージング モデルは、共通のメッセージング バックボーンを持つ複数の単一サイト メッセージング システムで構成されます。複数のロケーションを持つことができ、各ロケーションに独自のメッセージング システムとメッセージング インフラストラクチャ コンポーネントが置かれます。すべてのクライアント アクセスが各メッセージング システムに対してローカルであり、メッセージング システムは、すべてのロケーションにまたがるメッセージング バックボーンを共有します。分散型メッセージング システムからのメッセージ送信は、フルメッシュ タイプまたはハブアンドスポーク タイプのメッセージ ルーティング インフラストラクチャによって、メッセージング バックボーンを介して行われます。
分散型メッセージングは、基本的に、共通のメッセージング バックボーンを持つ複数の単一サイト メッセージング モデルです。このルールの例外は、PBX-IP Media Gateway(PIMG)統合と T1-IP Media Gateway(TIMG)統合です。PIMG 統合と TIMG 統合は、設計に関するこのドキュメントでは説明しません。PIMG または TIMG の詳細については、次の場所にある最新の Cisco Unity Connection の統合ガイドを参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unity-connection/products-installation-and-configuration-guides-list.html
分散型メッセージング モデルは、ローカルおよびリモートの GUI クライアント、TRaP、およびメッセージのダウンロードに関して、集中型メッセージングと同じ設計基準を持っています。
ここでは、さまざまなメッセージング配置モデルを Unified CM 呼処理配置モデルに統合する場合の設計上の考慮事項について説明します。 表 19-2 では、Cisco Unity Connection および Unity Express によってサポートされるメッセージング配置モデルと呼処理配置モデルのさまざまな組み合わせを示します。
|
|
|
---|---|---|
X1 |
||
なし 1 |
||
1.Unified CME による集中型ボイスメール メッセージングが Cisco Unity Express でサポートされていますが、これは Unified CM 呼処理配置モデルには適用されません。 |
各トピックではメッセージングと Unified CM の配置モデルの組み合わせを定義した後、そのモデルに適用可能なシスコのボイスメール メッセージング製品と、そのモデルの組み合わせに関する設計上の考慮事項について説明します。ここでは、各製品のすべての組み合わせを取り上げるわけではありません。いくつかの例を示し、各製品のベスト プラクティスと設計上の考慮事項を説明します。ここでの説明は、基本となるメッセージング配置モデルと Unified CM とのインタラクションの理解を促すためのものであり、すべての可能性を詳細に説明することは意図していません。
サイト分類の詳細と、サポートされているメッセージング配置モデルと呼処理配置モデルの組み合わせの詳細な分析については、次の場所にある『 Design Guide for Cisco Unity Connection 』の最新版を参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unity-connection/products-implementation-design-guides-list.html
ここでは、Cisco Connection によってサポートされるメッセージング配置モデルと呼処理配置モデルのさまざまな組み合わせを示します。
集中型メッセージングでは、ボイス メッセージング サーバは Unified CM クラスタと同じサイトに配置されます。集中型呼処理では、サブスクライバがクラスタおよびメッセージング サーバに対して、リモートとローカルのどちらにも存在できます(図 19-1 を参照)。リモート ユーザが中央のサイトのリソース(音声ポート、IP Phone、テールエンド ホップオフ(TEHO)の場合の PSTN ゲートウェイなど)にアクセスする場合、そのコールはゲートキーパー コール アドミッション制御にとって透過的になります。したがって、Unified CM でリージョンとロケーションを設定して、コール アドミッション制御を提供する必要があります。(帯域幅の管理を参照)。IP フォンまたは MGCP ゲートウェイにリージョン間コールを発信する場合、IP フォンは設定済みのリージョン間コーデックを自動的に選択します。
図 19-1 では、リージョン 1 と 2 が、リージョン内コールに G.711 を使用し、リージョン間コールに G.729 を使用するように設定されています。
図 19-1 で示しているように、内線番号 200 からリージョン 1 のボイスメール ポートにコールが発信されると、エンドポイントではリージョン間の G.729 コーデックが使用されますが、RTP ストリームがトランスコードされ、音声ポート上では G.711 が使用されます。Unified CM トランスコーディング リソースは、ボイスメール システムと同じサイトに置く必要があります。
AAR によってルーティングされるボイスメール コールで RDNIS が送信されないことによる影響
集中メッセージング環境では、WAN がオーバーサブスクリプションの状態になった場合に、Unified CM の機能である Automated Alternate Routing(AAR; 自動代替ルーティング)が、PSTN を介してコールを中央サイトのメッセージング ストアにルーティングできます。ただし、PSTN を介してコールが再ルーティングされる場合、Redirected Dialed Number Information Service(RDNIS)が損なわれることがあります。Cisco Unity Connection がメッセージング クライアントに対してリモートである場合は、正しくない RDNIS 情報によって、AAR が PSTN を介して再ルーティングするボイスメール コールに影響が及ぶことがあります。RDNIS 情報が正しくない場合、コールはダイヤル先のユーザのボイスメール ボックスに到達せず、自動アテンダント プロンプトを受信します。発信者は、到達を試みているユーザの内線番号を再入力するように要求されることがあります。この動作は主に、電話通信事業者がネットワークを介した RDNIS を保証できない場合の問題です。通信事業者が RDNIS の正常な送信を保証できない理由は数多くあります。通信事業者に問い合わせて、回線のエンドツーエンドで RDNIS の送信を保証しているかどうかを確認してください。オーバーサブスクリプションの状態になった WAN に対して AAR を使用する代わりの方法は、単に、オーバーサブスクリプションの状況で発信者にリオーダー トーンが聞こえるようにすることです。
Cisco Unity Connection Survivable Remote Site Voicemail(SRSV)は、WAN の障害時に支社サイト ユーザにボイスメール サービスのサバイバビリティを提供する、集中型 Cisco Unified Communications Manager および Cisco Unity Connection 展開モデルで使用されます。現在、Cisco Unity Connection は、Cisco Unified Messaging Gateway を使用せずに、中央サイトで SRSV 機能をネイティブでサポートしています。Cisco Unity Connection SRSV は、Cisco Unity Express SRSV の代替オプションです。Cisco Unity Connection は、通常の動作中に、電話機とユーザ メールボックスに関する情報を支社サイト SRSV サーバに更新します。WAN の障害時に Unity Connection SRSV ブランチ サーバは、バックアップ自動応答およびボイスメール ストレージとして機能します。すべての着信中の無応答コールおよびビジー コールは、外部発信者または内部発信者がボイス メッセージを残す可能性がある Unity Connection SRSV ブランチ サーバに転送されます。
WAN が回復すると、すべてのボイスメールが支社サイト SRSV から削除され、中央 Cisco Unity Connection サーバにアップロードされます。アップロードが完了すると、支社サイト SRSV がアイドル状態に移行します。すべての着信中の無応答コールおよびビジー コールが、中央 Cisco Unity Connection サーバに再度転送されます。
次の配置モデルが Survivable Remote Site Voicemail(SRSV)をサポートしています。
集中型 Unfied CM および Unity Connection がある支社サイトの SRST または E-SRST
図 19-2 に示すように、中央サイトには、正常な状態でプライマリ呼処理およびボイス メッセージ サービスを提供するための Cisco Unified CM および Unity Connection が含まれています。支社サイトでは、Cisco Unified Enhanced Survivable Remote Site Telephony(E-SRST)および Cisco Unity Connection SRSV ブランチ サーバが、WAN 障害時のバックアップ コール エージェントとボイス メッセージング サーバとしてインストールされています。中央サイトにインストールされている Cisco Unity Connection は、すべての電話機とボイス メールボックスの情報を支社サイト SRSV サーバにアップロードします。中央サイトへの接続が失われるまで、SRST または E-SRST はアイドル状態のままです。支社サイトが中央サイトから分離され、電話機と Unified CM 間のキープアライブ タイマーの期限が切れると、未応答のコールとビジー コールを Unity Connection SRSV ブランチ サーバに送信するように事前設定された E-SRST または SRST ルータに支社の電話機が復帰します。サブスクライバは、ボイスメールにアクセスして WAN の障害時に残されたボイス メッセージを聞くことができます。WAN が回復すると、すべてのボイス メッセージは、中央 Cisco Unity Connection のサブスクライバ メールボックスにアップロードされます。
図 19-2 集中型 Unfied CM および Unity Connection がある支社サイトの SRST または E-SRST
集中型 Unified CM/Unity Connection がある支社サイトの複数の E-SRST または SRST サーバ
この配置モデルは、最初のシナリオに似ていますが、複数の E-SRST と Cisco Unity Connection SRSV ブランチ サーバがロード バランシングのために支社サイトでペアになっています(図 19-3 を参照)。管理者は、Unified CM の 2 つの異なる SRST 参照を使用して 2 つの E-SRST サーバにわたって支社サイト ユーザを手動で分割し、ロード バランシングを実現する必要があります。Cisco Unity Connection は、メールボックス情報をペア化されている適切な Cisco Unity Connection SRSV ブランチ サーバにプッシュします。この設定では、各 Cisco Unity Connection SRSV ブランチ サーバに 1 つの支社 E-SRST のユーザのメールボックスが含まれます。
各 Cisco Unity Connection SRSV ブランチ サーバは、WAN 障害時にペア化された E-SRST ルータから転送されたコールを処理します。最初のシナリオと同様に、Cisco Unity Connection SRSV ブランチ サーバは、WAN の回復時に中央 Cisco Unity Connection のサブスクライバ メールボックスにすべてのボイスメールをアップロードします。
図 19-3 集中型 Unified CM/Unity Connection がある支社サイトの複数の E-SRST または SRST サーバ
(注) 支社サイトで、複数の E-SRST サーバと単一の Cisco Unity Connection SRSV ブランチ サーバのペア化はサポートされていません。
https://www.cisco.com/c/en/us/support/unified-communications/unity-connection/products-installation-guides-list.html
分散型メッセージングは、テレフォニー環境内に複数のメッセージング システムが分散されており、各メッセージング システムがローカル メッセージング クライアントだけにサービスを提供することを意味します。このモデルは集中型メッセージングとは異なります。集中型メッセージングでは、メッセージング システムに対してローカルなクライアントとリモートのクライアントの両方が存在します。
図 19-4 では、集中型呼処理を使用する分散型メッセージング モデルを示しています。他のマルチサイト呼処理モデルと同様に、WAN 帯域幅を管理するためにリージョンとロケーションを使用する必要があります。
E-SRST モードの Cisco Unified Communications Manager Express は、IP フォンおよび Cisco Unity Connection ボイスメール ポートの両方の呼処理バックアップに使用されます。このフォールバック サポートは、リモート サイト(たとえば、図 19-4 のリージョン 2)に配置され、WAN 障害などのために電話機と Unified CM との接続が失われた場合に、バックアップの呼処理を提供します。またリモート サイトのユーザに対し、WAN 障害時に、ローカルの Cisco Unity Connection サーバへのアクセスと MWI のサポートを提供します。E-SRST モードの詳細については、次の Web サイトで入手可能なマニュアルを参照してください。
https://www.cisco.com/c/en/us/products/unified-communications/unified-survivable-remote-site-telephony/index.html
図 19-4 の構成では、トランスコーダ リソースが各 Cisco Unity Connection メッセージ システム サイトに対してローカルである必要があります。リージョン 1 と 2 は、リージョン内コールに G.711 を使用し、リージョン間コールに G.729 を使用するように設定されています。
Unified CM サーバに設定されているコーリング サーチ スペースとデバイス プールによって、両方の Cisco Unity Connection サーバのボイス メッセージング ポートに、適切なリージョンとロケーションが割り当てられる必要があります。さらに、テレフォニー ユーザをボイスメール ポートの特定のグループに関連付けるために、Unified CM ボイスメール プロファイルを設定する必要があります。コーリング サーチ スペース、デバイス プール、およびボイスメール プロファイルの設定方法の詳細については、次の場所にある『 Administration Guide for Cisco Unified Communications Manager and IM and Presence Service 』の該当する版を参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-maintenance-guides-list.html
Cisco Unity Connection は、相互に通信するために WAN にある複数の Unity Connection クラスタをイネーブルにするデジタルおよび HTTPS ネットワーキングをサポートしています。デジタルまたは HTTPS ネットワーキングを使用して、複数の Unity Connection クラスタでは、共通のディレクトリ情報を共有できます。これにより、複数のクラスタ上のユーザはボイスメールを相互に残しておくことができます。Cisco Unity Connection クラスタは、Microsoft Active Directory などの企業ディレクトリと統合してユーザ情報を同期し、デジタルまたは HTTPS ネットワーキングを使用してディレクトリ情報を同時に共有できます。
E-SRST による Cisco Unity Connection
E-SRST を使用すると、Cisco Unity Connection サーバをリモート サイトに置き、中央サイトの Unified CM に登録して、リモート ロケーションにある E-SRST にフォールバックできます。WAN リンクがダウンし、電話機が E-SRST ルータにフェールオーバーすると、Cisco Unity Connection のボイスメール ポートも E-SRST モードにフェールオーバーします。これにより、リモート サイトのユーザが、WAN の障害時に、MWI 機能も含めてボイスメールにアクセスできるようになります。
(注) Unified CM から E-SRST モード、またはその逆方向にフェールオーバーが発生した場合、Cisco Unity Connection サーバから MWI を再同期する必要があります。
複数のメッセージング モデルを同じ配置で組み合わせることができます。ただし、その配置は、上記の項で示したすべてのガイドラインに従う必要があります。図 19-5 では、集中型メッセージングと分散型メッセージングの両方が同時に採用されるユーザ環境を示しています。
図 19-5 では、2 つのメッセージング モデルの組み合わせを示しています。リージョン 1 と 3 は集中型メッセージングと集中型呼処理を使用し、リージョン 2 は分散型メッセージングと集中型呼処理を使用しています。すべてのリージョンが、リージョン内コールに G.711 を使用し、リージョン間コールに G.729 を使用するように設定されています。
図 19-5 では、中央サイトとサイト 3 の間で、集中型メッセージングと集中型コール シグナリングが使用されています。中央サイトのメッセージング システムは、中央サイトとサイト 3 の両方のクライアントにメッセージング サービスを提供します。サイト 2 は、集中型呼処理を使用する分散型メッセージング モデルを使用しています。サイト 2 に置かれているメッセージング システム(Unity Connection 2)は、サイト 2 の中にいるユーザだけにメッセージング サービスを提供します。この配置では、両方のモデルが、この章に記載されているそれぞれの設計上のガイドラインに従っています。トランスコーディング リソースは各メッセージング システム サイトに対してローカルに置かれ、サイト 2 のユーザが中央サイトのユーザにメッセージを残す場合のように、(メッセージング システムに対して)リモートのサイトからメッセージング サービスにアクセスするクライアントをサポートします。
さらに、E-SRST モードは、IP フォンおよび Cisco Unity Connection ボイスメール ポートの両方のコール処理バックアップに使用されます。このフォールバック サポートは、リモート サイト(たとえば、図 19-5 のリージョン 2)に配置され、WAN 障害などのために電話機と Unified CM との接続が失われた場合に、バックアップの呼処理を提供します。またリモート サイトのユーザに対し、WAN 障害時に、ローカルの Cisco Unity Connection サーバへのアクセスと MWI のサポートを提供します。E-SRST の詳細については、次の Web サイトで入手可能な製品マニュアルを参照してください。
https://www.cisco.com/c/en/us/products/unified-communications/unified-survivable-remote-site-telephony/index.html
ここでは、集中型メッセージングと、ローカル フェールオーバー機能を持つ WAN を介した Unified CM クラスタリングを一緒に配置する場合の Cisco Unity Connection の設計上の問題について説明します。このモデルで WAN に障害が発生した場合は、WAN が復元されるまで、すべてのリモート メッセージング サイトがボイスメール機能を失います(図 19-6 を参照)。
WAN を介したクラスタリングは、ローカル フェールオーバーをサポートしています。ローカル フェールオーバーでは、各サイトが、物理的にそのサイトに置かれているバックアップ サブスクライバ サーバを持ちます。ここでは、Cisco Unity Connection 集中型メッセージングと、WAN を介したクラスタリングのローカル フェールオーバーを一緒に配置する方法を中心に説明します。
詳細については、IP WAN を介したクラスタリングの項を参照してください。
図 19-6 Cisco Unity Connection 集中型メッセージングと、ローカル フェールオーバー機能を持つ WAN を介したクラスタリング
クラスタリングされたサーバ間の最小帯域幅の要求については、ローカル フェールオーバー配置モデルの項を参照してください。
Unified CM による WAN を介したクラスタリングでは、Cisco Unity Connection と同様、最大 8 サイトがサポートされます。ボイスメール ポートは、Cisco Unity Connection メッセージング システムが置かれているサイトだけに設定されます(図 19-6 を参照)。ボイスメール ポートは、WAN を介してリモート サイトに登録されません。他のサイトのメッセージング クライアントは、プライマリ サイトのすべてのボイスメール リソースにアクセスします。WAN に障害が発生すると、リモート サイトは集中型メッセージング システムにアクセスできなくなるため、WAN を介してリモート サイトに音声ポートを設定してもメリットがありません。ユニファイド メッセージングの場合、帯域幅を考慮して、ボイスメール ポートで TRaP を無効にし、すべてのメッセージング クライアントがそのローカル PC にボイスメール メッセージをダウンロードするようにする必要があります。
Cisco Unity Connection メッセージング サーバも配置されたローカル フェールオーバー サイトでは、集中型メッセージング モデルと同様に、音声ポートがローカル Unified CM サブスクライバ サーバに登録されます。音声ポートの設定については、Unified CM クラスタとの音声ポート統合および専用 Unified CM バックアップ サーバを使用する音声ポート統合を参照してください。
図 19-7 WAN を介した Cisco Unity Connection 分散型メッセージングおよびクラスタリング
WAN を介したクラスタリングを含む単純分散型メッセージング実装では、クラスタ内の各サイトに、独自の Cisco Unity Connection メッセージング サーバとメッセージング インフラストラクチャ コンポーネントが置かれます。すべてのサイトにローカル Cisco Unity Connection メッセージング システムが置かれるわけではなく、一部のサイトで、ローカル メッセージング クライアントがリモート メッセージング サーバを使用する場合、その配置は分散型メッセージングと集中型メッセージングの組み合わせモデルとなります。(メッセージング配置モデルの組み合わせを参照)。このモデルで WAN に障害が発生した場合は、WAN が復元されるまで、集中型メッセージングを使用するすべてのリモート サイトがボイスメール機能を失います。
ローカル メッセージング サーバを持たない各サイトは、そのすべてのメッセージング クライアントに対して単一のメッセージング サーバを使用する必要がありますが、そのようなサイトのすべてが同じメッセージング サーバを使用する必要はありません。たとえば、サイト 1 とサイト 2 のそれぞれがローカル メッセージング サーバを持っているとします。その場合、サイト 3 のすべてのクライアントがサイト 2 のメッセージング サーバを使用し(そのメッセージング サーバに登録し)、サイト 4 のすべてのクライアントがサイト 1 のメッセージング サーバを使用するようにできます。ローカル Cisco Unity Connection メッセージング サーバを持つサイトには、トランスコーダ リソースが必要です。
他の分散型呼処理配置と同様に、これらのサイト間のコールはゲートキーパー コール アドミッション制御にとって透過的です。したがって、Unified CM でリージョンとロケーションを設定してコール アドミッション制御を提供する必要があります(帯域幅の管理を参照)。
分散配置された Cisco Unity Connection サーバは、デジタルまたは HTTPS でネットワーク接続することもできます。
ここでは、Cisco Unity Connection に関するメッセージングの冗長性について説明します。Cisco Unity Express は、メッセージングの冗長性をサポートしていません。
Cisco Unity Connection は、プライマリとセカンダリの 2 台のサーバをアクティブ/アクティブのサーバ ペアに設定したアクティブ/アクティブ冗長モデルで、メッセージング冗長性とロード バランシングをサポートします。アクティブ/アクティブ冗長モデルでは、プライマリとセカンダリの両方のサーバが、コールおよび HTTP 要求と IMAP 要求をアクティブに受け付けます。詳細については、次の場所にある『 Design Guide for Cisco Unity Connection 』の最新版を参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unity-connection/products-implementation-design-guides-list.html
図 19-8 は、Cisco Unity Connection のアクティブ/アクティブ メッセージング冗長性を示します。
図 19-8 Cisco Unity Connection メッセージングの冗長性
Cisco Unity Connection の SIP トランクの実装には、メッセージングの冗長性の機能にコールの分岐(転送)が必要です。Cisco Unified Communications Manager は、複数の宛先 SIP トランク機能をサポートします。この複数の宛先 SIP トランク機能により、管理者は、Cisco Unified CM と Cisco Unity Connection 間のフルメッシュ トランキングを定義し、冗長性を実現できます。また、ペアのそれぞれのサーバに対する 2 つの個別の SIP トランクを設定し、同じルート リストに関連付けられている同じルート グループに追加できます。このルート グループは、トップダウンの順で設定して、コールがプライマリ Unity Connection サーバに送信され、オーバーフロー コールがセカンダリ Unity Connection サーバに送信されるようにする必要があります。
(注) 正しく機能するには、SIP OPTIONS ping を Cisco Unity Connection フェールオーバーの Cisco Unified CM SIP トランクで有効にする必要があります。
Cisco Unity Connection のローカル フェールオーバーと WAN を介したクラスタリングを配置する場合は、集中型メッセージングと WAN を介したクラスタリングおよび分散型メッセージングと WAN を介したクラスタリングで説明している設計プラクティスを適用します。正常な動作時、プライマリ Cisco Unity Connection サーバからの音声ポートは WAN を通過しません。
図 19-9 は、Cisco Unity Connection ローカル フェールオーバーを示しています。プライマリとセカンダリ両方の Cisco Unity Connection サーバが物理的に同じサイトに置かれていることに注意してください。Cisco Unity Connection フェールオーバーは、Unified CM の WAN を介したクラスタリングで使用可能な最大数までリモート サイトをサポートします。
図 19-9 Cisco Unity Connection のローカル フェールオーバーと WAN を介したクラスタリング
Cisco Unity Connection は、冗長性のためにアクティブ/アクティブとアクティブ/スタンバイの両方のクラスタリングをサポートし、WAN に配置できます。アクティブ/アクティブ設定、つまり「ハイ アベイラビリティ」設定では、ハイ アベイラビリティと冗長性の両方が提供されます。アクティブ/アクティブ ペアの両方のサーバでは Cisco Unity Connection アプリケーションが実行され、コールおよびクライアントからの HTTP 要求や IMAP 要求を受け付けます。Cisco Unity Connection プライマリ サーバはアクティブ/スタンバイ展開のすべての着信コールや管理上の変更を処理します。セカンダリ サーバがこのシナリオのコールを処理するのは、プライマリ サーバが障害状態にあるか、または使用できない場合だけです。クラスタの各サーバは、WAN 経由で異なるサイトに配置できます。その場合、以降に示す設計上の考慮事項に従う必要があります。図 19-10 は、地理的に分離されたデータセンター向けの WAN 経由のクラスタリングの Cisco Unity Connection の配置を示します。
図 19-10 2 つのサイト間でハイ アベイラビリティが確保された Cisco Unity Connection
異なるサイトに Cisco Unity Connection サーバを配置する場合は、次の遅延および帯域幅要件を考慮してください。
(注) 帯域幅および遅延の要件は、Cisco Unity Connection のバージョンによって異なることがあります。
すべての要件の詳細については、次の Web サイトで入手可能な最新バージョンの『 System Requirements for Cisco Unity Connection 』を参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unity-connection/products-installation-guides-list.html
(注) Cisco Unity Connection クラスタ機能も Cisco Business Edition 6000 でサポートされます。
Cisco Unity Connection は、複数の Unified CM クラスタによる集中型メッセージング設定に配置することもできます(図 19-11 を参照)。複数統合および複数の Unified CM クラスタに伴う MWI の考慮事項の詳細については、Cisco Unified CM との統合の項を参照してください。
図 19-11 Cisco Unity Connection と複数の Unified CM クラスタの統合
図 19-11 の設定では、クラスタ 1 とクラスタ 2 の両方のサイトのメッセージング クライアントが、物理的にクラスタ 1 に置かれている Cisco Unity Connection メッセージング インフラストラクチャを使用します。
ここではまず、Cisco Unity Express を概観し、製品に関する情報を提供します。次に、配置モデルについての項では、集中型と分散型の両方の呼処理における分散型ボイス メッセージングを中心に、Cisco Unity Express に関してサポートされている 3 つの配置モデルを紹介し、次いで配置の特徴と設計ガイドラインを示します。最後に、Cisco Unity Express と Unified CM、さらには Cisco Unity Express と Unified SRST または E-SRST モードの間で使用されるシグナリング コール フローとさまざまなプロトコルについて説明します。
Cisco Unity Express は、Cisco Integrated Services Router(ISR)の Cisco ネットワーク モジュール上で実行される Linux ベースのソフトウェアです。Cisco Unified Communications Manager(Unified CM)、Cisco Unified SRST、または Cisco Unified Communications Manager Express(Unified CME)とともに配置できる、エントリレベルの自動応答(AA)およびボイスメール ソリューションです。以前のリリースでは、Cisco Unity Express は Unified CME または Survivable Remote Site Telephony(SRST)ルータとの共存配置に限定されていました。ただし、Cisco IOS Release 12.3(11)T で H.323-to-SIP コール ルーティング機能が導入されたため、Unified CM または Unified CME とともに配置する場合に、Cisco Unity Express と SRST または Unified CME を 2 つの異なるルータに配置できるようになりました。Cisco Unity Express は、SIP を使用して Cisco Unified Communications Manager Express(Unified CME)と通信し、JTAPI を使用して Cisco Unified Communications Manager(Unified CM)に接続します。
Cisco Unity Express のサポートされているハードウェア プラットフォームおよび容量の詳細については、次の Web サイトで入手可能な製品リリース ノートを参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unity-express/products-release-notes-list.html
Unified CM と Unified CME の相互運用性の詳細については、複数の呼処理エージェントの統合を参照してください。
Unified CME でサポートされている配置モデルの詳細については、次の Web サイトで入手可能な適当な Cisco Unified Communications Manager Express の設計に関する資料を参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-express/products-implementation-design-guides-list.html
Cisco Unity Express は、単一のサイトとして配置することも、Cisco Unified Communications Manager(Unified CM)または Unified Communications Manager Express(Unified CME)の分散型ボイスメールおよび自動応答(AA)ソリューションとして配置することもできます。ただし、Cisco Unity Express は、次のようなすべての Cisco Unified CM 配置モデルでサポートされます。
図 19-12 は、Cisco Unity Express を統合した集中型呼処理配置を、図 19-13 は、分散型呼処理配置を示しています。
Unified CME によって制御される Cisco Unity Express サイト、および Unified CM によって制御されるその他のサイトは、SIP トランキング プロトコルを使用して相互接続できます。Cisco Unity Express は Unified CM または Unified CME のいずれかと統合できますが、両方と同時に統合はできません。
(注) Cisco Unity Express は、最大 10 の Unified CME を持つ集中型配置モデルをサポートします。
図 19-12 集中型呼処理配置における Cisco Unity Express
図 19-13 分散型呼処理配置における Cisco Unity Express
Cisco Unity Express を使用した最も一般的な配置モデルは、集中型呼処理を使用したマルチサイト WAN モデルです。このモデルでは、Cisco Unity Express が、小規模なリモート オフィスで分散型ボイスメール機能を提供し、中央の Cisco Unity Connection システムが本社および大規模なリモート サイトにボイスメール機能を提供します。
Unified CM ネットワーク配置に次の条件のいずれかが該当する場合は、分散型ボイスメール ソリューションとして Cisco Unity Express を使用してください。
集中型または分散型の Unified CM 配置では、Cisco Unity Express に対して次の特徴とガイドラインが適用されます。
– 自動応答機能エントリ ポイント(Cisco Unity Express は、最大 5 つの異なる AA を設定できるので、ルート ポイントも最大 5 つまで必要になることがあります)
– グリーティング管理システム(GMS)パイロット番号(オプション。GMS を使用しない場合は、このルート ポイントを定義する必要はありません)
https://www.cisco.com/c/en/us/products/unified-communications/unity-express/datasheet-listing.html
図 19-14 は、Unified CM と Cisco Unity Express の間のコール フローに関係するプロトコルを示します。
図 19-14 Cisco Unity Express と Unified CM の間で使用されるプロトコル
図 19-14 は、次のシグナリングとメディア フローを示しています。
図 19-15 は、WAN リンクがダウンした場合に、SRST または E-SRST モードのルータと Cisco Unity Express の間のコール フローに関係するプロトコルを示しています。
図 19-15 Cisco Unity Express と SRST または E-SRST のルータの間で使用されるプロトコル
図 19-15 は、次のシグナリングとメディア フローを示しています。
(注) Unified CM MWI(JTAPI)は、SIP MWI 方式に依存しません。
この項では、Cisco Unity Connection および Cisco Unity Express を含むボイスメール ネットワーキングに関する留意点について説明します。
ボイスメール ネットワーキングでは、Cisco Unity Connection、Cisco Unity Express などのシステム間で、組み込みのシンプル メール転送プロトコル(SMTP)サーバおよび Voice Profile for Internet Mail(VPIM)バージョン 2 プロトコルのサブセットを使用して、ボイスメール メッセージの送受信、返信、転送を行えます。いずれのボイスメール メッセージング製品も、VPIM メッセージングにより、製品間の相互運用性をサポートしています。
Cisco Unity Express は、メッセージのルーティングでは VPIM を、メッセージ配信では SMTP を使用して、Cisco Unity Connection と通信します。Cisco Unity Express ボイスメール ネットワーキングは、次の機能を提供します。
特定の製品におけるボイスメール ネットワーキングの詳細については、次の Web サイトで入手可能な該当するボイスメール製品のマニュアルを参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unity-connection/products-maintenance-guides-list.html
Cisco Unity Connection(デジタル ネットワーク、HTTPS ネットワーク、スタンドアロン サーバ、またはクラスタ)は、他の Cisco Unity Connection(デジタル ネットワークまたは HTTPS ネットワーク)と相互運用できます。これにより、ユーザは、ディレクトリを共有したり、簡単に管理を行ったり、その他の機能を使用したりできます。また、ノード(クラスタまたはスタンドアロン サーバ)の合計数を最大 25 まで拡張できます。
デジタル ネットワーク システムは、ディレクトリ レプリケーションおよびメッセージ転送の両方で Simple Mail Transfer Protocol(SMTP)を使用します。図 19-16 に示すように、複数の Unity Connection ノードはディレクトリ情報を共有するために完全メッシュ トポロジで結合されます。完全メッシュ トポロジだけが Cisco Unity Connection デジタル ネットワーキングでサポートされます。
ネットワーキングに完全メッシュ トポロジを使用するのに必要なのは、ノード間の情報の転送用のシングル ホップだけですが、ノード数と共にリンクの数も増えます。
Cisco Unity Connection デジタル ネットワーキングを配置する際には、次のガイドラインを考慮してください。
HTTPS ネットワーキングは、ツリー構造のデータ レプリケーションをイネーブルにするハブ アンド スポーク トポロジを使用します。ハブはすべてのリーフ スポークの通信のシングル ポイントです。すべてのディレクトリ レプリケーションは HTTPS プロトコルを使用して、ハブ経由で行われます。各スポークはハブからディレクトリ情報を収集するリーフ ノードです。1 つのスポークは、1 つのハブにのみ接続できます。図 19-17 に示すように、スポーク クラスタ A および B はハブ クラスタ H に接続されます。クラスタ A はディレクトリ情報を取得する必要がある場合、ノード H にクエリを送信します。ハブ ノード H は、自身のディレクトリ情報とノード B のディレクトリ情報を ノード A に複製します。
Cisco Unity Connection HTTPS ネットワーキングを配置する際には、次のガイドラインを考慮してください。
これらの相互運用性オプションの詳細については、次の Web サイトで入手可能な『 Networking Guide for Cisco Unity Connection 』の最新バージョンを参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unity-connection/products-maintenance-guides-list.html
Cisco Unified Computing System(UCS)は、総所有コスト(TCO)を削減してビジネスの機動性を向上させることを目的として設計された統合システムに、コンピューティング、ネットワーキング、ストレージ アクセス、および仮想化を一体化した、次世代のデータセンター プラットフォームです。Cisco Unity Connection は、Cisco Unified Computing System の VMware による仮想化をサポートします。
Cisco Unity Connection の仮想化には、次の主な設計上の考慮事項が適用されます。
(注) VMware vSphere ESXi 5.1 以前の場合は、1 つ以上のプロセッサ コアを VMware ESXi ハイパーバイザ/スケジューラのために予約する必要があります。VMware vSphere ESXi 5.5 以降では、仮想マシンの遅延を軽減するために、遅延感度機能が搭載されています。遅延感度の値を高く設定した場合は、ESXi ハイパーバイザやスケジューラ用に未使用のプロセッサ コアを予約する必要はありません。
仮想システムでの Cisco Unified Communications および Cisco Unity Connection の配置の詳細については、次の Web サイトで入手可能な資料を参照してください。
http://www.cisco.com/go/virtualized-collaboration
仮想サーバ上での Unified Communications の配置の全般的な情報については、仮想サーバでの Unified Communications の配置の項でも確認できます。
Cisco Unity Connection の仮想化については、次の Web サイトで入手可能な最新バージョンの『 Design Guide for Cisco Unity Connection 』も参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unity-connection/products-implementation-design-guides-list.html
ここでは、これまでに言及されていないが、ソリューションの中で、製品の重要な側面として考慮すべき一般的なベスト プラクティスとガイドラインを説明します。Cisco Unity Connection のグループと、Cisco Unity Express の 2 つのグループにわかれています。
この項の説明は、Cisco Unity Connection に適用されます。Cisco Unity Express については、Cisco Unity Express の配置に関するベスト プラクティスを参照してください。
Unified CM は、帯域幅を管理するためのさまざまな機能を備えています。リージョン、ロケーション、およびゲートキーパーさえも使用して、Unified CM は、WAN リンクを介して伝送される音声コールの数によって既存の帯域幅がオーバーサブスクリプションの状態になることがなく、音声品質が低下しないことを保証できます。Cisco Unity Connection は、帯域幅の管理とコールのルーティングを Unified CM に依存しています。コールまたは音声ポートが WAN リンクを通過することのある環境に Cisco Unity Connection を配置する場合、このようなコールはゲートキーパーベースのコール アドミッション制御にとって透過的になります。このような状況は、Cisco Unity Connection サーバが分散クライアントにサービスを提供している場合(分散型メッセージングまたは分散型呼処理)、または Unified CM がリモートに置かれている場合(分散型メッセージングまたは集中型呼処理)、いつでも発生します。Unified CM は、コール アドミッション制御用のリージョンとロケーションを提供します。
図 19-18 では、集中型メッセージングと集中型呼処理を使用する小規模なサイトで、リージョンとロケーションを連携させて使用可能な帯域幅を管理する方法を示しています。リージョンとロケーションの詳細については、帯域幅管理の章を参照してください。
図 19-18 では、リージョン 1 と 2 が、リージョン内コールに G.711 を使用し、リージョン間コールに G.729 を使用するように設定されています。ロケーション 1 と 2 は、両方 24 kbps に設定されています。ロケーションの帯域幅は、ロケーション間コールの場合にだけ配分されます。
リージョン内(G.711)コールは、ロケーションの使用可能な帯域幅に対して配分されません。たとえば、内線番号 100 が内線番号 101 をコールする場合、このコールはロケーション 1 の使用可能帯域幅 24 kbps に対して配分されません。ただし、G.729 を使用するリージョン間コールは、ロケーション 1 とロケーション 2 の両方の帯域幅割り当て 24 kbps に対して配分されます。たとえば、内線番号 100 が内線番号 200 をコールすると、このコールは接続されますが、追加の(同時)リージョン間コールでは、リオーダー(ビジー)トーンが聞こえます。
Cisco Unity Connection では、IP エンドポイントと Cisco Unity Connection サーバとの間でコールがネゴシエートされたコーデックと、録音または再生のコーデック形式が異なる場合、ネイティブ トランスコーディングが行われます。コールが G.729 でネゴシエートされ、システム全体の録音形式が G.711 で行われる場合、サーバはそのコールをネイティブにトランスコードする必要があります。Cisco Unity Connection のネイティブ トランスコーディングは、外部ハードウェア トランスコーダを使用せず、サーバのメイン CPU を使用します。ネイティブ トランスコーディングという名称はここから来ています。
Cisco Unity Connection では、Cisco Unity Connection SCCP または SIP シグナリングによってサポートされているすべてのコーデック形式(G.711 mu-law、G.711 a-law、G.729、iLBC、および G.722)のコールは、常にリニア PCM にトランスコードされます。リニア PCM の録音は、General Configuration の設定でシステムワイドに指定されたシステムレベルの録音形式(リニア PCM、G.711 mu-law/a-law、G.729a、または G.726)にエンコードされます(G.711 mu-law がデフォルト)。この章ではこれ以降、発信側デバイスと Unity Connection の間でネゴシエートされるコーデックを「ライン コーデック」、システムレベルの録音形式として設定されたコーデックを「録音コーデック」と呼びます。
トランスコーディングは、本来すべての接続で発生するので、ライン コーデックと録音コーデックが違っても、システムへの影響にほとんど違いはありません。ただし、iLBC または G.722 を使用する場合は例外です。G.722 と iLBC は、トランスコードに要する処理能力が大きいので、システムに対する影響も大きくなります。G.722 と iLBC は、G.711 mu-law の約 2 倍のリソースを必要とします。そのため、G.722 または iLBC 接続の場合、システムは G.711 mu-law 接続の半分しかサポートできません。
原則として、デフォルトのコーデックは G.711 のままにしておくことを推奨します。設定がディスク容量に制約される場合は、G.729a や G.726 などの低ビット レート コーデックを録音形式として設定できますが、オーディオ品質は G.711 オーディオの忠実度とは異なることに留意してください。また、G.722 がライン上のデバイスで使用されている場合は、リニア パルス符号変調(PCM)が、録音のオーディオ品質を高めるオプションです。ただし、この場合はディスク使用量が増加し、ディスク容量に影響を及ぼします。
また録音コーデックを変更したり、特定のライン コーデックのみをアドバタイズしたりする理由がいくつかあります。SCCP 統合または SIP 統合の際に、システムレベルの録音形式やアドバタイズされるコーデックについて決定する場合は、次の要因を検討してください。
表 19-3 では、Cisco Unity Connection がサポートするコーデック形式の特徴を概観します。
|
|
|
|
---|---|---|---|
Cisco Unity Connection がコーデックをアドバタイズする方法の変更の詳細については、『 System Administration Guide for Cisco Unity Connection 』を参照してください。アドバタイズするコーデックとして選択できるのは、G.711 mu-law、G.711 a-law、G.729、iLBC、および G.722 です。また優先順位の高い順にコーデックを記載したリストもあります。SCCP 統合では、コーデックがアドバタイズされ、ネゴシエートされるコールのポートとデバイスのロケーションに基づいて Unified CM がコーデックをネゴシエートするので、コーデックの順序は意味を持ちません。しかし SIP 統合では、順位のリストが意味を持ちます。コーデックに優先順位を設定すると、Cisco Unity Connection は両方のプロトコルをサポートするものの、指定された一方のみの使用が適していることをアドバタイズします。
Cisco Unity Connection Administration でシステムレベルの録音形式を変更する方法の詳細については、『 System Administration Guide for Cisco Unity Connection 』をそれぞれ参照してください。
Cisco Unified CM は、Cisco Unity Connection と SCCP または SIP で統合できます。ここでは、電話機、SIP トランク、および音声ポートに関して、その統合の詳細を説明します。
Cisco Unity Connection では、ユーザは 1 つ以上のポート グループを含む電話機システムに関連付けられます。ポート グループは、MWI ポートに関連付けられているので、MWI 要求は、その特定のポート グループに関連付けられたポートを通じて行われます。Cisco Unity Connection の電話システムとポート グループは、System Administrator に設定されます。
Cisco Unity Connection は、同時に最大 90 個の同時電話システムおよびポート グループをサポートします。Unity Connection のタッチトーン カンバセーション(電話ユーザ インターフェイス(TUI))および音声認識(Voice User Interface(VUI))機能だけを使用している場合は、シスコは最大 90 個のポート グループを使用することを推奨しています。カレンダーや音声合成(TTS)などのその他すべての機能を使用している場合、Unity Connection は最大 60 個の同時電話システムをサポートします。この機能は、SCCP 統合と SIP 統合のいずれでも同じ方法で動作します。詳細については、次の Web サイトで入手可能な該当する Cisco Unity Connection のアドミニストレーション ガイドを参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unity-connection/products-maintenance-guides-list.html
複数クラスタを接続するオプションとして、Cisco Unity Connection で新しい Unified CM クラスタごとに統合を追加するという方法と別に、Unified CM は Annex M.1(QSIG のメッセージ トンネリング)をサポートしています。これにより、管理者は、Unified CM クラスタの間にあるクラスタ間トランク(ICT)で QSIG を有効にできます。ICT で QSIG を有効にすると、複数のクラスタがサポートされている場合でも、Cisco Unity Connection は 1 つの Unified CM クラスタのみに統合され、この 1 つのクラスタでのみ、MWI をオン/オフするポートを指定する必要があります。Unified CM の Annex M.1 機能によって、MWI 要求をそれらの ICT 経由で伝搬し、適切な Unified CM クラスタとそのクラスタ内の電話機に伝達できます。他のクラスタから発信されたすべてのコールは、その 1 つのクラスタに統合された Cisco Unity Connection サーバに転送できます。ICT で Annex M.1 が有効になっていれば、他のクラスタで MWI ポートを指定する必要はありません。
Cisco Unity Connection は、Cisco Unified CM Session Management Edition と統合して、すべてのリーフ Unified Communications クラスタに関連付けられたユーザにボイス メッセージング サービスを提供できます。(図 19-19 を参照)。
図 19-19 Unified CM Session Management Edition を使用した Cisco Unity Connection 配置
次の情報が、Unified Communications リーフ クラスタと Unified CM Session Management Edition との間のクラスタ間トランク、および Cisco Unity Connection への SIP トランクで送信される必要があります。
非 Q.SIG トランクの場合、元の着信側番号またはリダイレクト番号を提供するため、次の設定をイネーブルにする必要があります。
非 Q.SIG MGCP、H.323 または SIP トランクで送信される転送情報は、リダイレクト DN に割り当てられたボイスメール プロファイルのボイス メールボックス マスクで定義された発信側変換だけをピックアップします。ルート パターンまたはルート リスト、または発信の発呼側変換コーリング サーチ スペース(CSS)で定義された発信側変換は、転送情報に適用されません。
Q.SIG 対応の SIP、MGCP および H.323 トランクの場合、元の着信側番号は Q.SIG 転送レッグ情報のアプリケーション プロトコル データ ユニット(APDU)で送信されます。
Q.SIG 対応の H.323、MGCP および SIP トランクでは、発信番号、着信番号、リダイレクト番号の情報はすべてカプセル化された Q.SIG メッセージで送信され、外部 H.323 メッセージや SIP ヘッダーでは送信されません。送信される転送情報は、発信側変換を使用せず、ボイス メール マスク設定を反映しません。Q.SIG トンネリング対応トランクは、Q.SIG APDU での「+」文字の転送をサポートしません。このような制限のため、ユーザのボイス メール ボックス番号は、リーフ Unified Communications システムで使用されるディレクトリ番号と同じ形式である必要があります。次に例を示します。
Cisco Unity Connection では、ユーザのボイス メールボックスに代替内線番号を関連付けることができます。次に例を示します。
Redirected Dialed Number Information Service(RDNIS)は、Q.SIG 対応 H.323 または SIP トランクではサポートされません。元の着信側番号またはリダイレクト番号は、RDNIS 経由ではなく、Q.SIG DivertingLegInformation2 APDU で送信されます。
Cisco Unity Connection は次のフィールドの E.164 番号形式をサポートします。
ユーザを E.164 形式のプライマリ電話番号を持つ LDAP からインポートする場合、電話番号を内線番号に変換する正規表現と置換パターンを使用します。このタスクの詳細については、次の場所にある『 System Administration Guide for Cisco Unity Connection 』の最新版で、電話番号から内線番号への変換に関するセクションを参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unity-connection/products-maintenance-guides-list.html
Cisco Unified Communications Manager(Unified CM)から、AXL 統合を経由して、E.164 形式の内線番号とともにユーザをインポートする場合、E.164 内線番号を Unified CM から、カンマ区切り値(CSV)ファイルにエクスポートする必要があり、Bulk Administration Tool(BAT)を使用して、それらの番号を Unity Connection にインポートする前に、代行内線番号で必要な変換(たとえば、Excel 形式)を実行しなければなりません。
Cisco Unity Connection は、代行内線番号への SIP URI ダイヤルをサポートしています。SIP URI ダイヤルによって、ユーザは、Unity Connection を呼び出している間に、SIP URI 電話機から自動的にボイスメールにアクセスできます。英数字のアドレスに広く使用されている方式は、 ユーザ @ ホスト という簡略化された SIP URI で、左側(LHS、ユーザ部分)は英数字、右側(RHS、ホスト部分)はドメイン名です。SIP URI は、Unity Connection でユーザの代行内線番号として設定されます。
HTTPS およびデジタル ネットワーキングでは、代行内線番号用の SIP URI は SIP URI をサポートするノードでのみ複製されます。
Cisco Unity Connection の SIP URI は次の機能をサポートしています。
管理者は、LDAP ディレクトリまたは Cisco Unified CM との AXL 統合から URI を Unity Connection にインポートできます。
(注) 管理者は、電話タイプがディレクトリ URI の代行内線番号を削除または編集できません。この代行内線番号は、元の送信元(LDAP ディレクトリまたはユーザのインポート元の Cisco Unified Communications Manager)からのみ編集または削除できます。
拡張メッセージ待機インジケータ(eMWI)は、従来の MWI を拡張したものであり、ボイス メッセージの数が視覚的に表示されます。従来の MWI は、新しいボイス メッセージが到着したときに電話機のメッセージ ランプをオンにし、ユーザのボイスメール ボックスから新しいボイス メッセージが削除されたときにオフにするという 2 値形式の表示です。eMWI は、Cisco Unity Connection を使用し、Cisco Unified IP Phone 8900 および 9900 シリーズの SIP 電話機でサポートされます。
eMWI では、ユーザのボイスメール ボックス内の未再生メッセージが視覚的に表示され、メッセージのステータスが色付きで表示されます。未再生メッセージは電話機の画面に赤色で表示されます。eMWI は、SIP および SCCP の統合を通じて Cisco Unity Connection の Unified CM でサポートされます。eMWI は、システムが SRST モードで動作している場合は機能しません。Cisco Unity Connection との統合においては、Cisco Unity Connection サーバ上に保管されているメッセージだけが eMWI で通知され、外部の IMAP サーバに保管されているメッセージについては通知されません。
eMWI は、Unified CM を使用した分散型呼処理環境で動作します。1 つのクラスタがクラスタ間トランク(H.323 または SIP)経由でボイス メッセージング サーバへの接続を提供する、分散型呼処理と集中型ボイス メッセージング統合のシステムでは、クラスタ間トランク経由での eMWI 更新がサポートされており、エンド デバイスに表示されます(図 19-20 を参照)。
(注) eMWI は、クラスタ間トランク(H.323 または SIP)経由の、集中型メッセージングと分散型呼処理の環境でも動作します。
図 19-21 に、クラスタ間トランク(H.323 または SIP)経由の、分散型呼処理と集中型ボイス メッセージングの環境における eMWI を示します。
図 19-21 分散型呼処理と集中型ボイス メッセージングの eMWI
図 19-21 に示すように、クラスタ 2 およびそのボイス メッセージング ソリューションでは eMWI がサポートされますが、クラスタ 1 ではサポートされません。ボイス メッセージ数が含まれた eMWI 更新がボイス メッセージ ソリューションからクラスタ 2 の電話機に送信された場合、クラスタ 1 では、ボイス メッセージ数なしの標準 MWI だけがクラスタ 2 に転送されます。
単一サイト メッセージング環境に Cisco Unity Connection を配置する場合、Unified CM クラスタとの統合は SCCP 音声ポートまたは SIP トランクを介して行われます。Unified CM サブスクライバに障害が発生した場合でも(Unified CM フェールオーバー)、ユーザおよび外部コールが引き続きボイス メッセージングにアクセスできるように、設計上の考慮事項には、Cisco Unified CM サブスクライバ間の音声ポートの適切な配置についても考慮する必要があります(図 19-22 を参照)。
図 19-22 Unified CM クラスタと統合された Cisco Unity Connection サーバ(専用バックアップ サーバなし)
図 19-22 の Unified CM クラスタは、1 対 1 のサーバ冗長性および 50/50 のロード バランシングを採用しています。正常な動作時には、各サブスクライバ サーバがアクティブで、サーバの全呼処理負荷の最大 50 % を処理します。1 台のサブスクライバ サーバに障害が発生すると、残りのサブスクライバ サーバが、障害の発生したサーバの負荷を担います。
この設定では、ボイスメール ポートのグループが 2 つ使用され、各グループに、ライセンスのある音声ポートの合計数の半分が含まれています。1 つのグループは、プライマリ サーバがサブ 1 で、セカンダリ(バックアップ)サーバがサブ 2 になるように設定されています。もう 1 つのグループは、サブ 2 がプライマリ サーバで、サブ 1 がバックアップになるように設定されています。
MWI 専用ポートや他の特殊なポートが、2 つのグループ間で等しく分散されていることを確認してください。音声ポートの設定中は、命名規則に特に注意してください。Cisco Unity Connection でポートの 2 つのグループを設定する場合は、必ずデバイス名プレフィックスがグループごとに一意となるようにし、Unified CM Administration でボイスメール ポートを設定するときと同じデバイス名を使用します。この例では、デバイス名プレフィックスがポートのグループごとに一意になっています。グループ サブ 1 ではデバイス名プレフィックスとして CiscoUM1 が使用され、サブ 2 では CiscoUM2 が使用されています。
着信ボイスメール ポートと発信ボイスメール ポート(MWI、メッセージ通知、および TRaP 用)の比率に関する設計上の詳細情報については、次の場所にある『 Cisco Unity Connection System Administration Guide 』の最新版を参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unity-connection/products-maintenance-guides-list.html
(注) デバイス名プレフィックスは、ポートのグループごとに一意で、Unified CM Administration に設定されているボイスメール ポートの命名規則と一致する必要があります。
Unified CM Administration では、この例のポートの半分が一意なデバイス名プレフィックス CiscoUM1 を使用して登録されるように設定され、残りの半分が一意のデバイス プレフィックス(CiscoUM2)を使用して登録されるように設定されています( 表 19-4 を参照)。 表 19-4 に示すように、ポートが Unified CM に登録される場合、半分がサブスクライバ サーバ サブ 1 に登録され、残りの半分がサブ 2 に登録されます。
|
|
|
|
|
|
---|---|---|---|---|---|
(注) Unified CM Administration でボイスメール ポートに使用される命名規則は、Cisco UTIM で使用されるデバイス名プレフィックスと一致する必要があります。一致しないと、ポートの登録に失敗します。
この Unified CM クラスタ構成では、各サブスクライバ サーバが 50 % を超える呼処理負荷で動作できます。各プライマリ サブスクライバ サーバは、専用バックアップ サーバまたは共有バックアップ サーバを持ちます(図 19-23 を参照)。正常な動作時、バックアップ サーバはコールを処理しませんが、サブスクライバ サーバの障害時またはメンテナンス時に、バックアップ サーバはそのサブスクライバ サーバのすべての負荷を担います。
図 19-23 単一の Unified CM クラスタと統合された Cisco Unity Connection サーバ(バックアップ サブスクライバ サーバを使用)
この場合のボイスメール ポートの設定は、50/50 のロード バランシング クラスタに似ています。ただし、もう 1 台のサブスクライバ サーバをセカンダリ サーバとして使用するように音声ポートを設定せず、個別の共有バックアップ サーバまたは専用バックアップ サーバを使用します。共有バックアップ サーバと共にクラスタリングされた Unified CM では、両方のサブスクライバ サーバのセカンダリ ポートが、単一のバックアップ サーバを使用するように設定されます。
音声ポート名(デバイス名プレフィックス)は、Cisco UTIM グループごとに一意で、Unified CM サーバ上で使用されるデバイス名と同じである必要があります。
Cisco Unity Connection のボイスメール ポートを設定するには、Unity Connection Administration コンソールの [テレフォニー統合(Telephony Integration)] セクションを使用します。詳細については、次の Web サイトで入手可能な Cisco Unity Connection のアドミニストレーション ガイドを参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unity-connection/products-maintenance-guides-list.html
現行の IP アドレッシングに対する要件は、現行バージョンの IP アドレッシングである IPv4 で使用可能な IP アドレスのセットを上回っています。そのため、ほとんどの IP ベースのソリューションが、IPv4 より多くの IP アドレスが使用可能な IPv6 のサポートを取り込む方向に進んでいます。Cisco Unity Connection は、SCCP または SIP 経由の Cisco Unified Communications Manager システム統合を使用して IPv6 アドレッシングをサポートします。コンポーネント レベルでは、呼制御とメディア経由でのみ、デュアル スタック アドレッシング(IPv4 と IPv6 の両方)がサポートされます。
Cisco Unity Connection は、次の IPv6 アドレス タイプをサポートします。
(注) ボイス メッセージは.wav ファイルとして保存されるため、IPv6 や IPv4 とは無関係です。
IPv6 サポートはデフォルトで無効になっていますが、システム管理者は Cisco Unified Operating System Administration とコマンドライン インターフェイス(CLI)のどちらかで IPv6 を有効にして、IPv6 アドレス設定値を構成できます。Cisco Unity Connection は、ルータ アドバタイズメントと DHCP のどちらかを経由して、または、Cisco Unified Operating System Administration と CLI のどちらかで手動で設定されたアドレスから、IPv6 アドレスを取得できます。Cisco Unity Connection Administration、Cisco Personal Communications Assistant は IPv6 アドレスを使用してアクセスできます。
(注) IPv6 アドレッシングは、Cisco Unity Connection のインストールまたはアップグレード時にイネーブルにできません。Cisco Unity Connection は、「IPv6 のみ」のサーバ設定をサポートしていません。また、Cisco Unity Connection は、IPv6 専用のユニキャストをサポートしています。
IPv6 を介した Cisco Unity Connection は、次の機能をサポートします。
Cisco Unity Connection は、Microsoft Exchange 2003、2007、2010(クラスタ版または非クラスタ版)とのシングル インボックス機能をサポートし、ボイスメールに Unified Messaging を提供します。Cisco Unity Connection は、この 3 つすべての Microsoft Exchange バージョンを同時にサポートすることも、いずれかを個別にサポートすることもできます。Unity Connection では、Microsoft Business Productivity Online Suite(BPOS)専用サービスおよび Microsoft Office 365 クラウドベース Exchange サーバとの相互運用性もサポートされています。Unity Connection は、Microsoft Exchange Online を使用してシングル インボックス機能をイネーブルにします。詳細については、次の Web サイトで入手可能な最新バージョンの『 Unified Messaging Guide for Cisco Unity Connection 』を参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unity-connection/products-maintenance-guides-list.html
Cisco Unity Connection ViewMail for Microsoft Outlook から送られてくるものも含め、すべてのボイス メッセージが Cisco Unity Connection に保存されてから、すぐに受信者の Microsoft Exchange メールボックスに複製されますが、複製はオプションです。また、この機能はユーザ単位で設定可能です。
Cisco Unity Connection でボイスメール用のユニファイド メッセージングをサポートするには、いくつかの設計上の留意点があります。ユーザの電子メールは、電子メールとボイスメールを含むすべてのメッセージに対する単一のコンテナになります。メッセージが受信トレイ下の別のフォルダに移動されても、Cisco Unity Connection から削除されることはありません。ただし、ユーザがボイス メッセージを受信トレイ フォルダ下ではない Outlook フォルダに移動した場合は、Cisco Unity Connection からそのメッセージが削除されますが、コピーが Outlook 内に残っているため、ViewMail for Outlook で再生できます。ユーザがメッセージを受信トレイ フォルダまたは受信トレイ フォルダ下のフォルダに移動すると、そのメッセージがユーザの Cisco Unity Connection メールボックスに表示されます。また、ユーザが Cisco Unity Connection からボイス メッセージを削除した場合、または、メッセージの有効期限が切れたために Cisco Unity Connection から自動的に削除された場合は、そのメッセージが Microsoft Exchange からも削除されます。同様に、Microsoft Exchange からボイス メッセージが削除された場合は、Cisco Unity Connection からも削除されます。
メッセージが保護対象かつプライベートとしてマークされている場合は、実メッセージが Microsoft Exchange に複製されません。代わりに、そのメッセージに関する簡単な説明付きのプレースホルダーが作成されます。実メッセージの唯一のコピーが Cisco Unity Connection 上に保存され、ユーザがそのメッセージを取り出すと、通常のメッセージの場合と違って、ローカル ソースではなく、Cisco Unity Connection から直接再生されます。これは、オーディオ ファイルが Outlook からボイスメール経由でアクセスされた場合は、ローカル アクセスできないことも意味します。保護対象でプライベートのメッセージを受信トレイおよび受信トレイ下のフォルダ以外のフォルダに移動した場合は、そのメッセージが完全に削除されるため、取り出せなくなります。
(注) メッセージング展開の種類に関係なく、すべての音声メッセージが Cisco Unity Connection サーバ上に保存されます。Cisco Unity Connection は、ボイス メッセージング トラフィック、通知、および同期化の信頼できるソースです。
1 つのボイスメール メッセージに割り当て可能なスペース容量は、メッセージの有効期限と同様に、Cisco Unity Connection サーバ上で設定されます。ボイスメール メッセージの最大サイズは Microsoft Exchange サーバ上で設定されます。一般的に、Microsoft Exchange サーバには、メールボックスに同期される Cisco Unity Connection よりも大きなサイズが保存されます。そのため、Microsoft Exchange 上のメッセージの最大サイズは、Cisco Unity Connection 上の最大サイズよりも大きくする必要があります。
Cisco Unity Connection と Microsoft Exchange 間の通信のセキュリティ面から、デフォルト オプションとして HTTPS が選択されます。HTTP もサポートされていますが、セキュリティが低下するうえ、Microsoft Exchange 上で余分な設定が必要になる場合があるため、推奨できません。その一方で、証明書サーバへのアクセスが可能な場合に、Microsoft Exchange 証明書を確認するためのオプションが用意されています。
Cisco Unity Express を配置する場合は、次のガイドラインとベスト プラクティスを使用してください。
Cisco Unity Express へのコールは、G.711 のみを使用します。ローカルのトランスコーダを使用して、WAN を通過する G.729 コールを G.711 コールに変換することを推奨します。Unified CM リージョンは、リージョン内コールに G.711 音声コーデックを、リージョン間コールに G.729 音声コーデックを使用するように設定できます。
Cisco Unity Express サイトにトランスコーディング機能がない場合、必要な数の G.711 ボイスメールに対応する十分な帯域幅を WAN 上にプロビジョニングします。IP フォンと Cisco Unity Express デバイス(CTI ポートと CTI ルート ポイント)の間のコールに G.711 音声コーデックを使用するように、Unified CM リージョンを設定します。
Cisco Unity Express は、DTMF リレーのみをサポートし、インバンド DTMF トーンはサポートしていません。Cisco Unity Express では、DTMF は、SIP または JTAPI のいずれかの呼制御チャネルを介してアウトオブバンドで搬送されます。Cisco Unity Express 2.3 は、RFC 2833 を使用した、Cisco Unity Express への G.711 SIP コールをサポートします。
Cisco Unified CM は SIP トランク プロトコルをサポートしますが、Cisco Unity Express は Unified CM との通信に JTAPI を使用します。Cisco Unity Express は、SCCP 電話機と SIP 電話機の両方をサポートします。
(注) Cisco Unified CM と Cisco Unity Express 間の互換性については、https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/unity_exp/compatibility/cuecomp.html にある『Cisco Unity Express Compatibility Matrix』を参照してください。
Cisco Unity Express の詳細については、次の Web サイトで入手可能な製品マニュアルを参照してください。
https://www.cisco.com/c/en/us/products/unified-communications/unity-express/index.html
この項では、サードパーティ製ボイスメール システムを Cisco Unified Communications とともに配置する場合のさまざまなオプションについて説明します。統合とメッセージングの両方について説明します。
(注) この項では、ポートやストレージに関するサードパーティ製ボイスメール システムのサイジング方法については説明しません。この情報については、ボイスメール ベンダーに連絡してください。ボイスメール ベンダーは、具体的なトラフィック パターンに基づいて、各ベンダーのシステムにおける個別の要件をより適切に判断できます。
統合 は、ボイスメール システムとその関連する PBX または呼処理エージェントとの間の物理的な接続として定義されます。統合によって、これらの間にフィーチャ セットも提供されます。ボイスメール ベンダーは数多くあり、Cisco Unified CM を配置する場合に既存のボイスメール システムを引き続き使用することも一般的です。
(注) シスコでは、サードパーティ製ボイスメール システムのテストや認証は行っていません。通常、この業界では、さまざまな PBX システムに対して自社の製品をテストまたは認証することはボイスメール ベンダーの責任であるとされています。シスコでは、そのような機器とのシスコのインターフェイスをテストし、どのようなサードパーティ製ボイスメール システムが接続されるかにかかわらずこれらのインターフェイスをサポートします。
Cisco Unified CM は QSIG を使用してサードパーティの PBX と統合でき、これにより、サードパーティの PBX を 一次群速度インターフェイス(PRI)T1/E1 トランクを介して Unified CM に接続できます。各方式にはそれぞれの利点と欠点があり、使用する方式はボイスメール システムと現在の PBX との統合方法に大きく依存します。
現在、ボイスメール統合に使用できる他の方法には、H.323 や SIP があります。ただし、ベンダーにおけるさまざまな実装方式、サポートされる機能、およびその他の要因によって、これらのサードパーティ製ボイスメール統合は、お客様が評価する必要があります。これらのオプションの詳細については、シスコのアカウント チームまたはシスコ代理店に連絡してください。
メッセージング は、ボイスメール システム間でのメッセージの交換として定義されます。メッセージングの目的で使用できるいくつかのオープンな標準があります。
異なるシステム間でのメッセージングを可能にするために配置される最も一般的なプロトコルは、Voice Profile for Internet Mail(VPIM)です。VPIM の仕様は何度か更新されており、最新ではないバージョン 2 が現在でも最も広く採用されているようです。VPIM よりも前から存在するメッセージング プロトコルに Audio Messaging Interchange Specification - Analog(AMIS-A)がありますが、ユーザ インターフェイスが使いにくく、アナログ テクノロジーが使用されており、機能も少ないことから、ほとんど使用されていません。