Cisco Collaboration システム 10.x ソリューション リファレンス ネットワーク デザイン(SRND)
シスコのボイス メッセージング
シスコのボイス メッセージング
発行日;2014/04/25 | 英語版ドキュメント(2013/11/23 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 27MB) | フィードバック

目次

シスコのボイス メッセージング

この章の新規情報

ボイス メッセージング ポートフォリオ

メッセージング配置モデル

単一サイト メッセージング

集中型メッセージング

分散型メッセージング

メッセージングと UnifiedCM 配置モデルの組み合わせ

Cisco Unity Connection メッセージングおよび Unified CM の配置モデル

集中型メッセージングと集中型呼処理

Cisco Unity Connection Survivable Remote Site Voicemail

分散型メッセージングと集中型呼処理

メッセージング配置モデルの組み合わせ

集中型メッセージングと WAN を介したクラスタリング

分散型メッセージングと WAN を介したクラスタリング

メッセージングの冗長性

Cisco Unity Connection

Cisco Unity Connection のフェールオーバーと WAN を介したクラスタリング

Cisco Unity Connection の冗長性と WAN を介したクラスタリング

集中型メッセージングと分散型 UnifiedCM クラスタ

Cisco Unity Express の配置モデル

Cisco Unity Express の概要

配置モデル

ボイスメール ネットワーキング

Cisco Unity Express のボイスメール ネットワーキング

複数の Cisco Unity Connection クラスタ間またはネットワーク間の相互運用性

Cisco Unity Connection の仮想化

ボイス メッセージングのベスト プラクティス

UnifiedCM を使用した Cisco Unity Connection のベストプラクティス

帯域幅の管理

ネイティブ トランスコーディング動作

Cisco Unity Connection の動作

Cisco UnifiedCM との統合

Cisco UnifiedCM Session Management Edition との統合

Cisco Unity Connection による IPv6 サポート

Cisco Unity Connection によるシングル インボックス

Cisco Unity Express の配置に関するベスト プラクティス

UnifiedCM とのボイスメール統合

Cisco Unity Express コーデックと DTMF のサポート

JTAPI、SIP トランクおよび SIP 電話機のサポート

サードパーティ製ボイスメールの設計

シスコのボイス メッセージング

この章では、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)についても説明します。

この章では、次のトピックについて取り上げます。

「ボイス メッセージング ポートフォリオ」

「メッセージング配置モデル」

「メッセージングと Unified CM 配置モデルの組み合わせ」

「ボイスメール ネットワーキング」

「ボイス メッセージングのベスト プラクティス」

「サードパーティ製ボイスメールの設計」

この章ではまず、Cisco メッセージング ソリューションのポートフォリオの各製品について簡単に説明した後、企業向け Unified Communications ソリューションにおける各製品の位置付けに関する簡単な概要を示します。次に、メッセージング配置モデルを基盤として、ボイスメール統合を説明します。ここではまず、さまざまなメッセージング配置モデルを定義した後、さまざまな Unified CM 呼処理配置モデルにおける各メッセージング配置モデルの位置付けを説明します。この項では、Cisco Unity Connection について説明します。Cisco Unity Express については、別に専用の項を設けて、サポートされる配置モデルを説明します。シスコのボイス メッセージング製品ポート フォリオ内で利用可能な相互運用性のための主要な設計ガイドラインについて説明します。仮想化、および仮想システム設計時に考慮する必要がある重要な設計上の要素について説明します。この項では、トランスコーディングや Unified CM とのさまざまな統合を含む、多くのシステムレベルの設計上の考慮事項およびベスト プラクティスについて説明します。さらに、この章では、サポートされている業界標準プロトコルを使用したサードパーティ製ボイスメール統合の詳細について説明します。

この章では、基本設計に関する説明を行います。また、Unified CM を使用してコラボレーション システムにボイス メッセージング製品をどのように組み込むかに重点を置いて説明します。各製品の詳細な設計ガイドラインおよびサードパーティ製のメッセージングとテレフォニー システムの相互運用性に関する情報については、次に示す Cisco Unity Connection の設計ガイドを参照してください。

http://www.cisco.com/en/US/products/ps6509/products_implementation_design_guides_list.html

この章の新規情報

表 19-1 に、この章に新しく追加されたトピック、またはこのマニュアルの以前のリリースから大幅に改訂されたトピックの一覧を示します。

表 19-1 新規情報、またはこのマニュアルの以前のリリースからの変更情報

新規トピックまたは改訂されたトピック
説明箇所
改訂日

Cisco Unity Connection クラスタ間のデジタルおよび HTTPS ネットワーク

「複数の Cisco Unity Connection クラスタ間またはネットワーク間の相互運用性」

2013 年 11 月 19 日

Cisco Unified Enhanced Survivable Remote Site Telephony(E-SRST)

この章の各項で説明

2013 年 11 月 19 日

ボイス メッセージング ポートフォリオ

Cisco Unified Communications のメッセージング ポートフォリオは、Cisco Unity Connection と Cisco Unity Express の 2 つの主なメッセージング製品で構成されます。それぞれの製品が対応する要件は異なりますが、互いに他の製品と重なり合う機能とスケーラビリティを備えています。また、ボイス メール ネットワーキングを使用して互いに連携する機能により、この章で後ほど説明するとおり、より高いスケーラビリティに加えてボイス メールの相互運用性を実現します。

これらの製品を検討する場合、それらに搭載されたメッセージング オプションを理解し、特定の配置要件に適したオプションを判断するためには、製品が該当するメッセージング タイプを考慮することが役立ちます。次の定義は、このようなメッセージング タイプの説明に役立ちます。

ボイスメール専用 とはメッセージング クライアント経由でボイスメールにアクセスしない利用環境でのテレフォニー ボイスメール統合を指します。

統合メッセージング とは、テレフォニー アクセス、およびメッセージ クライアントを介したボイスメールへのアクセスを備えたボイスメールを指します。

ユニファイド メッセージング とは、テレフォニー アクセス、およびメッセージング クライアントを介したボイスメール、電子メール、FAX へのアクセスを備えたボイスメールを指します。

表 19-2 は、これらのタイプのメッセージングをサポートするシスコ製品を示します。

表 19-2 各製品でサポートされるメッセージング環境

メッセージング タイプ
Cisco Unity Connection
Cisco Unity Express

ボイスメール専用

Yes

Yes

統合メッセージング

Yes

Yes

ユニファイド メッセージング

Yes

No


) Cisco Unity Connection を使用したユニファイド メッセージングの詳細については、「Cisco Unity Connection によるシングル インボックス」を参照してください。


上のメッセージング タイプと定義に基づき、次の 2 つのメッセージング製品のオプションが用意されています。

Cisco Unity Connection

このオプションは、20,000 ユーザ以下の中規模企業用に、ユニファイド/統合メッセージング、音声認識、およびコール転送ルールを 1 つのシステムに組み合わせて管理しやすくしたものです。また、デジタルまたは HTTP ネットワーク システムを使用して、複数の Cisco Unity Connection クラスタを組み合わせることができます。(必要であれば、さらに Voice Profile for Internet Mail(VPIM)ネットワーキング用の音声プロファイルを使用して、100,000 人以上のユーザをサポートするために 2 つの HTTP またはデジタル ネットワーク システムを結合することができます)。Cisco Unity Connection は、1 つのデジタル ネットワークまたは HTTPS ネットワーク上で最大 100,000 人のユーザをサポートできます。1,000 人以下のユーザを擁する組織向けに、Cisco Unity Connection は、Cisco Business Edition 6000 で使用できます。Cisco Business Edition の詳細については、「呼処理の設計上の考慮事項」を参照してください。

Cisco Unity Express

このオプションは、中小規模企業および 500 ユーザ以下の支社用に、特定の Cisco サービス統合型ルータで、コスト効率の高いボイス メッセージングおよび統合メッセージング、自動応答、および Interactive Voice Response(IVR; 音声自動応答装置)の各機能を提供します。

製品機能全体の比較については、 http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_data_sheets_list.html で入手可能な『 Cisco Messaging Products: Feature Comparison 』を参照してください。

表 19-3 に、スケーラビリティについての簡単な製品間の比較を示します。

 

表 19-3 ボイス メッセージング ソリューションの拡張

ソリューション
単一サーバでサポートされる最大ユーザ数(またはフェールオーバー配置やクラスタ配置)
デジタル ネットワーキング ソリューションでサポートされる最大ユーザ数
HTTPS ネットワーキング ソリューションでサポートされる最大ユーザ数
500
1,000
15,000
20,000
100,000
100,000

Cisco Unity Express

Yes

No

No

No

Yes

No

Cisco Business Edition 6000

Yes

Yes

No

No

No

No

Cisco Unity Connection(ユニファイド/統合メッセージング)

Yes

Yes

Yes

Yes

Yes

Yes


) サポートされる最大ユーザ数の増加に加え、HTTPS ネットワーキングはサーバ検出およびディレクトリ同期機能を提供します。


この章では、Cisco Unity Connection および Cisco Unity Express と Cisco Unified Communications Manager(Unified CM)の統合について、設計上の側面を中心に説明します。Cisco Unified CM には、Session Initiation Protocol(SIP)トランクの機能が搭載されているため、SIP プロキシ サーバを配置することなく、直接 Cisco Unity Connection と統合できます。

以前のリリースの Cisco Unity Connection、Unity Express、および Unified CM または Unified CM Express の詳細については、 http://www.cisco.com で入手可能な資料を参照してください。

上で説明したように、この章で扱う設計に関するトピックは、ボイスメールのみの設定、ユニファイド メッセージング設定、および統合メッセージング設定に適用されます。さらに、この章では、Microsoft Exchange(2003、2007、または 2010)と Cisco Unity Connection の配置の設計面について説明します。Cisco Unity Connection および Unity Express は外部メッセージ ストアに依存しません。

Cisco Unity Connection に関するその他の設計情報については、次の Web サイトで入手可能な『 Design Guide for Cisco Unity Connection 』を参照してください。

http://www.cisco.com/en/US/products/ps6509/products_implementation_design_guides_list.html

Cisco Unity Express に関するその他の設計情報については、次の Web サイトで入手可能な製品マニュアルを参照してください。

http://www.cisco.com/en/US/products/sw/voicesw/ps5520/index.html

メッセージング配置モデル

この章では、Cisco Unity Connection および Cisco Unity Express について、さまざまなメッセージング配置モデルの概要を示します。Cisco Unity Connection、およびさまざまなメッセージング コンポーネントに固有の配置モデルや設計上の考慮事項の詳細については、次の Web サイトで入手可能な『 Design Guide for Cisco Unity Connection 』を参照してください。

http://www.cisco.com/en/US/products/ps6509/products_implementation_design_guides_list.html

Cisco Unity Express については、次の Web サイトで入手可能な製品マニュアルを参照してください。

http://www.cisco.com/en/US/products/sw/voicesw/ps5520/index.html

Cisco Unity Connection は、次の 3 つの主なメッセージング配置モデルをサポートしています。

単一サイト メッセージング

集中型メッセージングを使用するマルチサイト配置

分散型メッセージングを使用するマルチサイト配置

Cisco Unity Express もまた、次の 3 つの主なメッセージング配置モデルをサポートしています。

単一サイト メッセージング

分散型メッセージングを使用するマルチサイト配置

Cisco Unified CME により分散型メッセージングを使用するマルチサイト配置


) Cisco Unity Express は、最大 10 の Unified CME を持つ集中型ボイス メッセージングをサポートします。詳細については、http://www.cisco.com/en/US/products/sw/voicesw/ps4625/index.html にある Cisco Unified Communications Manager Express のマニュアルを参照してください。


Cisco Unified CM と Unified CME の呼処理配置モデルは、Cisco Unity Connection および Unity Express のメッセージング配置モデルに依存しませんが、互いに対して考慮が必要な暗黙的要件があります。

アクティブ/アクティブ設定では、Cisco Unity Connection のメッセージング冗長性を利用できます。詳細については、次の Web サイトで入手可能な『 Design Guide for Cisco Unity Connection 』を参照してください。

http://www.cisco.com/en/US/products/ps6509/products_implementation_design_guides_list.html

すべてのメッセージング配置モデルが、ボイスメール、統合メッセージング、およびユニファイド メッセージングのインストールをサポートしています。

単一サイト メッセージング

このモデルでは、メッセージング システムとメッセージング インフラストラクチャ コンポーネントは同じサイトでアベイラビリティの LAN 上にすべて配置されます。サイトは、単一サイトである場合も、高速メトロポリタン エリア ネットワーク(MAN)を介して相互接続されたキャンパス サイトである場合もあります。メッセージング システムのクライアントもすべて、単一(またはキャンパス)サイトに置かれます。このモデルの際立った特徴は、リモート クライアントが存在しないことです。

集中型メッセージング

このモデルでは、単一サイト モデルと同様に、メッセージング システムとメッセージング インフラストラクチャ コンポーネントがすべて、同じサイトに置かれます。サイトは、1 つの物理的なサイトである場合も、高速 MAN を介して相互接続されたキャンパス サイトである場合もあります。ただし、単一サイト モデルとは異なり、メッセージング クライアントをローカルとリモートの両方に置くことができます。

分散型メッセージング

分散型メッセージング モデルは、共通のメッセージング バックボーンを持つ複数の単一サイト メッセージング システムで構成されます。複数のロケーションを持つことができ、各ロケーションに独自のメッセージング システムとメッセージング インフラストラクチャ コンポーネントが置かれます。すべてのクライアント アクセスが各メッセージング システムに対してローカルであり、メッセージング システムは、すべてのロケーションにまたがるメッセージング バックボーンを共有します。分散型メッセージング システムからのメッセージ送信は、フルメッシュ タイプまたはハブアンドスポーク タイプのメッセージ ルーティング インフラストラクチャによって、メッセージング バックボーンを介して行われます。

分散型メッセージングは、基本的に、共通のメッセージング バックボーンを持つ複数の単一サイト メッセージング モデルです。このルールの例外は、PBX-IP Media Gateway(PIMG)統合と T1-IP Media Gateway(TIMG)統合です。PIMG 統合と TIMG 統合は、設計に関するこのドキュメントでは説明しません。PIMG または TIMG の詳細については、次の Web サイトで入手可能な Cisco Unity Connection のインテグレーション ガイドを参照してください。

http://www.cisco.com/en/US/products/ps6509/index.html

分散型メッセージング モデルは、ローカルおよびリモートの GUI クライアント、TRaP、およびメッセージのダウンロードに関して、集中型メッセージングと同じ設計基準を持っています。

メッセージングと Unified CM 配置モデルの組み合わせ

ここでは、さまざまなメッセージング配置モデルを Unified CM 呼処理配置モデルに統合する場合の設計上の考慮事項について説明します。 表 19-4 では、Cisco Unity Connection および Unity Express によってサポートされるメッセージング配置モデルと呼処理配置モデルのさまざまな組み合わせを示します。

表 19-4 サポートされているメッセージングと Unified CM 呼処理配置モデルの組み合わせ

モデル タイプ
Cisco Unity Connection
Cisco Unity Express

単一サイト メッセージングと単一サイト呼処理

Yes

Yes

集中型メッセージングと集中型呼処理

Yes

No1

分散型メッセージングと集中型呼処理

Yes

Yes

集中型メッセージングと分散型呼処理

Yes

No1

分散型メッセージングと分散型呼処理

Yes

Yes

集中型メッセージングと WAN を介したクラスタリング

Yes

No

分散型メッセージングと WAN を介したクラスタリング

Yes

Yes

1.Unified CME による集中型ボイスメール メッセージングが Cisco Unity Express でサポートされていますが、これは Unified CM 呼処理配置モデルには適用されません。

この項では、次の項目について説明します。

Cisco Unity Connection メッセージングおよび Unified CM の配置モデル

Cisco Unity Express の配置モデル

各トピックではメッセージングと Unified CM の配置モデルの組み合わせを定義した後、そのモデルに適用可能なシスコのボイスメール メッセージング製品と、そのモデルの組み合わせに関する設計上の考慮事項について説明します。ここでは、各製品のすべての組み合わせを取り上げるわけではありません。いくつかの例を示し、各製品のベスト プラクティスと設計上の考慮事項を説明します。ここでの説明は、基本となるメッセージング配置モデルと Unified CM とのインタラクションの理解を促すためのものであり、すべての可能性を詳細に説明することは意図していません。

サイト分類の詳細、およびメッセージング配置モデルと呼処理配置モデルのサポートされている組み合わせの詳細な分析については、次の Web サイトで入手可能な『 Design Guide for Cisco Unity Connection 』を参照してください。

http://www.cisco.com/en/US/products/ps6509/products_implementation_design_guides_list.html

Cisco Unity Connection メッセージングおよび Unified CM の配置モデル

ここでは、Cisco Connection によってサポートされるメッセージング配置モデルと呼処理配置モデルのさまざまな組み合わせを示します。

集中型メッセージングと集中型呼処理

集中型メッセージングでは、ボイス メッセージング サーバを Unified CM クラスタと同じサイトに置くことができます。集中型呼処理では、サブスクライバがクラスタおよびメッセージング サーバに対して、リモートとローカルのどちらにも存在できます(図 19-1 を参照)。リモート ユーザが中央のサイトのリソース(音声ポート、IP Phone、Tail-End Hop-Off(TEHO; テールエンド ホップオフ)の場合の PSTN ゲートウェイなど)にアクセスする場合、そのコールはゲートキーパー コール アドミッション制御にとって透過的になります。したがって、Unified CM でリージョンとロケーションを設定して、コール アドミッション制御を提供する必要があります。(「帯域幅の管理」を参照)。IP Phone または MGCP ゲートウェイにリージョン間コールを発信する場合、IP フォンは設定済みのリージョン間コーデックを自動的に選択します。

図 19-1 集中型メッセージングと集中型呼処理

 

図 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

Cisco Unity Connection Survivable Remote Site Voicemail(SRSV)は、集中型 Cisco Unified Communications Manager および Cisco Unity Connection 展開モデルで使用され、WAN の障害時に支社サイト ユーザにボイスメール サービスのサバイバビリティを提供します。現在、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 サーバに再度転送されます。

SRSV 配置モデル

次の配置モデルが Survivable Remote Site Voicemail(SRSV)をサポートしています。

「集中型 Unified CM/Unity Connection で支社サイトに SRST または E-SRST があるモデル」

「集中型 Unified CM/Unity Connection で支社サイトに複数の SRST または E-SRST があるモデル」

集中型 Unified 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 集中型 Unified CM/Unity Connection で支社サイトに SRST または E-SRST があるモデル

 

集中型 Unified CM/Unity Connection で支社サイトに複数の SRST または E-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 で支社サイトに複数の SRST または E-SRST があるモデル

 


) 支社サイトで、複数の E-SRST サーバと単一の Cisco Unity Connection SRSV ブランチ サーバのペア化はサポートされていません。


Survivable Remote Site Voicemail の配置ガイドライン

サポートされるリモート サイトの最大数は、中央サイトの Cisco Unity Connection ごとに 10 個です。

このソリューションでは、SRST および拡張 SRST(E-SRST)の両方のフォール バック方式をサポートしています。Cisco Unity Connection SRSV ブランチ サーバは、Cisco Services-Ready Engine(SRE)900 と 910 ブレード サーバ、および Cisco Unified Computing System(UCS)または UCS E-Series などのサポートされている Cisco Unity Connection プラットフォームで動作します。Cisco Unity Connection SRSV ブランチ サーバと SRST または E-SRST ルータの両方が、単一の論理ユニットとして表示されます。ここで SRST ルータは、WAN の障害時にすべての制御シグナリングを処理します。

Cisco Unity Connection SRSV ブランチ サーバは、WAN リンクがダウンし、SRST がアクティブ状態の場合にアクティブになります。それ以外の場合は、アイドル状態のままです。

E.164 内線番号がサポートされています。

Cisco Business Edition 6000 はサポートされていません。

Cisco Unity Connection と Cisco Unity Connection SRSV との間で接続をセキュアに保つには、HTTP over Secure Socket Layer(SSL)プロトコルを使用します。


) SRSV ソリューションが機能するには、中央サイトの Cisco Unity Connection が 9.1(1) 以降のリリースである必要があります。Cisco Unity Connection SRSV サーバは、Unified CM と E-SRST バージョン 8.6 以降のリリースでサポートされています。


SRSV では、次のアクティビティを行う場合に WAN リンクの帯域幅が使用されます。

Cisco Unity Connection から Cisco Unity Connection SRSV への設定のアップロード

WAN リンクが復元された場合に、支社 Cisco Unity Connection SRSV サーバから中央 Cisco Unity Connection に音声メッセージをアップロード

分散型メッセージングと集中型呼処理

分散型メッセージングは、テレフォニー環境内に複数のメッセージング システムが分散されており、各メッセージング システムがローカル メッセージング クライアントだけにサービスを提供することを意味します。このモデルは集中型メッセージングとは異なります。集中型メッセージングでは、メッセージング システムに対してローカルなクライアントとリモートのクライアントの両方が存在します。

図 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 サイトで入手可能なマニュアルを参照してください。

http://www.cisco.com/en/US/products/sw/voicesw/ps2169/index.html

図 19-4 分散型メッセージングと集中型呼処理

 

図 19-4 の構成では、トランスコーダ リソースが各 Cisco Unity Connection メッセージ システム サイトに対してローカルである必要があります。リージョン 1 と 2 は、リージョン内コールに G.711 を使用し、リージョン間コールに G.729 を使用するように設定されています。

Unified CM サーバに設定されているコーリング サーチ スペースとデバイス プールによって、両方の Cisco Unity Connection サーバのボイス メッセージング ポートに、適切なリージョンとロケーションが割り当てられる必要があります。さらに、テレフォニー ユーザをボイスメール ポートの特定のグループに関連付けるために、Unified CM ボイスメール プロファイルを設定する必要があります。コーリング サーチ スペース、デバイス プール、およびボイスメール プロファイルを設定する方法の詳細については、次の Web サイトで入手可能な、該当するバージョンの『 Cisco Unified Communications Manager Administration Guide 』を参照してください。

http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_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 結合された配置モデル

 

図 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 サイトで入手可能な製品マニュアルを参照してください。

http://www.cisco.com/en/US/products/sw/voicesw/ps2169/index.html

集中型メッセージングと WAN を介したクラスタリング

ここでは、集中型メッセージングと、ローカル フェールオーバー機能を持つ 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 にボイスメール メッセージをダウンロードするようにする必要があります。

分散型メッセージングと WAN を介したクラスタリング

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

Cisco Unity Connection は、プライマリとセカンダリの 2 台のサーバをアクティブ/アクティブのサーバ ペアに設定したアクティブ/アクティブ冗長モデルで、メッセージング冗長性とロード バランシングをサポートします。アクティブ/アクティブ冗長モデルでは、プライマリとセカンダリの両方のサーバが、コールおよび HTTP 要求と IMAP 要求をアクティブに受け付けます。詳細については、次の Web サイトで入手可能な『 Design Guide for Cisco Unity Connection 』を参照してください。

http://www.cisco.com/en/US/products/ps6509/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 を介したクラスタリング

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 フェールオーバーの設定については、次の Web サイトで入手可能な『 Cisco Unity Connection Failover Configuration and Administration Guide 』を参照してください。

http://www.cisco.com/en/US/products/ps6509/index.html

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 サーバを配置する場合は、次の遅延および帯域幅要件を考慮してください。

異なるサイトにあるアクティブ/アクティブ ペア間の最大 RTT は 60 ms

異なるサイトにあるアクティブ/スタンドバイ ペア間の最大 RTT は 150 ms

50 ポートごとに最低 7 Mbps の帯域幅が必要(たとえば、250 ポートでは 35 Mbps が必要)


) 帯域幅および遅延の要件は、Cisco Unity Connection のバージョンによって異なることがあります。


すべての要件の詳細については、次の Web サイトで入手可能な『 System Requirements for Cisco Unity Connection 』の最新バージョンを参照してください。

http://www.cisco.com/en/US/products/ps6509/prod_installation_guides_list.html


) Cisco Unity Connection クラスタ機能も Cisco Business Edition 6000 でサポートされます。


集中型メッセージングと分散型 Unified CM クラスタ

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 を概観し、製品に関する情報を提供します。次に、配置モデルについての項では、集中型と分散型の両方の呼処理における分散型ボイス メッセージングを中心に、Cisco Unity Express に関してサポートされている 3 つの配置モデルを紹介し、次いで配置の特徴と設計ガイドラインを示します。最後に、Cisco Unity Express と Unified CM、さらには Cisco Unity Express と Unified SRST または E-SRST モードの間で使用されるシグナリング コール フローとさまざまなプロトコルについて説明します。

Cisco Unity Express の概要

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 サイトで入手可能な製品リリース ノートを参照してください。

http://www.cisco.com/en/US/products/sw/voicesw/ps5520/prod_release_notes_list.html

Unified CM と Unified CME の相互運用性の詳細については、「Unified CM と Unified CM Express の相互運用性」 を参照してください。

Unified CME でサポートされている配置モデルの詳細については、次の Web サイトで入手可能な Cisco Unified Communications Manager Express の設計に関する資料を参照してください。

http://www.cisco.com/en/US/products/sw/voicesw/ps4625/index.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 によって制御されるその他のサイトは、H.323 または 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 を使用してください。

WAN の可用性にかかわらず、ボイスメールとオート アテンダント(AA)アクセスのサバイバビリティを確保する必要がある。

利用可能な WAN の帯域幅が不十分なために、WAN を介して中央のボイスメール サーバにアクセスするボイスメール コールがサポートできない。

ローカル コミュニティに対して割り当てられている AA または支社サイトの PSTN の電話番号のカバレッジが地域的に制限されているため、市外通話料金を支払わずにこれらの番号をダイヤルして中央の AA サーバに接続できない。

PSTN を使用して支社にかけた場合、コールが支社の AA から同じ支社内の内線番号に転送される可能性が高い。

経営理念上、リモート オフィスが、独自のボイスメールや AA テクノロジーを選択することを許可されている。

集中型または分散型の Unified CM 配置では、Cisco Unity Express に対して次の特徴とガイドラインが適用されます。

単一の Cisco Unity Express は、単一の Unified CM クラスタに統合できます。

Cisco Unity Express は、JTAPI アプリケーションとコンピュータ テレフォニー インテグレーション(CTI)Quick Buffer Encoding(QBE)プロトコルを使用して、Unified CM に統合できます。CTI ポートと CTI ルート ポイントは、Cisco Unity Express ボイスメールと AA アプリケーションを制御します。

Cisco Unity Express は、Skinny Client Control Protocol(SCCP)を実行する Cisco Unified IP Phone に、ボイスメール機能を提供します。Cisco Unity Express は、Unified CM で Session Initiation Protocol(SIP)の IP フォンもサポートしています。

Cisco Unity Express 対応の Unified CM には、次の CTI ポートが定義されています。

自動応答機能エントリ ポイント(Cisco Unity Express は、最大 5 つの異なる AA を設定できるので、ルート ポイントも最大 5 つまで必要になることがあります)

ボイスメールのパイロット番号

グリーティング管理システム(GMS)パイロット番号(オプション。GMS を使用しない場合は、このルート ポイントを定義する必要はありません)

Unified CM 上で Cisco Unity Express にサポートされる CTI ポートとメールボックスの数は、ハードウェア プラットフォームによって異なります。詳細については、次の URL から入手できる Cisco Unity Express のデータ シートを参照してください。

http://www.cisco.com/en/US/products/sw/voicesw/ps5520/products_data_sheets_list.html

サポートされている最大数より多くのメールボックスが必要な Cisco Unity Express 配置では、Cisco Unity Connection またはその他のボイスメール ソリューションを使用することを検討してください。

各 Cisco Unity Express メールボックスは、必要に応じて最大 2 つの異なる内線に関連付けることができます。

Cisco Unity Express とともに配置されたオフィスでは、自動応答機能をそのオフィスに置くことも(Cisco Unity Express の AA アプリケーションを使用)、中央サイトに置くことも(ボイスメールのみに Cisco Unity Express を使用)できます。

Cisco Unity Express は、Voice Profile for Internet Mail (VPIM) version 2 経由で、他の Cisco Unity Express または Cisco Unity Connection とネットワーク接続できます。これにより、Cisco Unity Express サブスクライバは、別のリモート Cisco Unity Express または Cisco Unity Connection サブスクライバとの間で、メッセージの送受信や転送を行うことができます。

Cisco Unity Express では、フェールオーバー用の Unified CM を最大 3 つまで指定できます。3 つの Unified CM のいずれにも IP 接続できなくなった場合、Cisco Unity Express は、Survivable Remote Site Telephony(SRST)コール シグナリングに切り替えて、AA 応答サービス、IP フォンへのメールボックス アクセス、および支社に着信する PSTN コールを提供します。

Cisco Unity Express の自動応答機能は、内線によるダイヤルと名前によるダイヤルの機能をサポートしています。内線によるダイヤルの操作では、発信側が、ネットワーク内の任意のユーザ エンドポイントにコールを転送できます。名前によるダイヤル操作では、Cisco Unity Express 内部のディレクトリ データベースを使用し、外部の LDAP や Active Directory データベースとのインタラクションを行いません。

Unified CM を使用した集中型 Cisco Unity Express はサポートされていません。

Cisco Unity Express は、SIP 電話を制御する Cisco Unified CM や Unified CME がない純粋な SIP ネットワークではサポートされません。

Cisco Unity Express は、Unified CME または SRST ルータ、あるいは PSTN ゲートウェイと別のルータ上に配置できます。

Unified CME または SRST 以外のルータ上に Cisco Unity Express を配置する場合、コマンド、 allow-connections h323 to sip を使用して H.323 から SIP へのルーティングを行います。

図 19-14 は、Unified CM と Cisco Unity Express の間のコール フローに関係するプロトコルを示します。

図 19-14 Cisco Unity Express と Unified CM の間で使用されるプロトコル

 

図 19-14 は、次のシグナリングとメディア フローを示しています。

電話機は、Unified CM から SCCP または SIP を介して制御されます。

Cisco Unity Express は、Unified CM から JTAPI(CTI-QBE)を介して制御されます。

電話機のメッセージ待機インジケータ(MWI)は、メールボックスの内容の変化を CTI-QBE 経由で Unified CM に伝達する Cisco Unity Express と、それに対してランプの状態変更の MWI メッセージを電話機に送信する Unified CM によって制御されます。

音声ゲートウェイは、H.323、SIP、または MGCP 経由で Unified CM と通信します。

Real-Time Transport Protocol(RTP)ストリーム フローは、エンドポイント間の音声トラフィックを搬送します。

図 19-15 は、WAN リンクがダウンした場合に、SRST または E-SRST モードのルータと Cisco Unity Express の間のコール フローに関係するプロトコルを示しています。

図 19-15 Cisco Unity Express と SRST または E-SRST のルータの間で使用されるプロトコル

 

図 19-15 は、次のシグナリングとメディア フローを示しています。

電話機は、SRST または E-SRST モードのルータから SCCP または SIP 経由で制御されます。

Cisco Unity Express は、内部 SIP インターフェイス経由で SRST ルータと通信します。

以前のリリースの Cisco Unity Express では、SRST モードでの MWI の変更はサポートされていませんが、通常動作でボイス メッセージを送信および検索できます。しかし、Unified CM に電話機を再登録するまで、電話機の MWI ランプはそのままです。その時点で、すべての MWI ランプの状態が、ユーザの Cisco Unity Express ボイスメール ボックスの現在の状態に自動的に再同期されます。Cisco Unity Express も、SRST モードで MWI をサポートします。

Cisco Unity Express では、SIP Subscriber/Notify および Unsolicited Notify がサポートされており、MWI 通知を Unified CME モードと SRST モードの両方で生成できます。

RTP ストリーム フローは、エンドポイント間の音声トラフィックを搬送します。

SRST は、MWI 通知を受信するように登録された各 ephone-dns の MWI について、Cisco Unity Express にサブスクライブします。


) 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 のボイスメール ネットワーキング

Cisco Unity Express は、メッセージのルーティングでは VPIM を、メッセージ配信では SMTP を使用して、Cisco Unity Connection と通信します。Cisco Unity Express ボイスメール ネットワーキングは、次の機能を提供します。

サブスクライバは、発信側のシステム上でロケーション設定されたリモート Cisco Unity Express または Cisco Unity Connection サブスクライバとの間で、メッセージの送受信や転送を行うことができます。

サブスクライバはまた、リモート システムから受信したメッセージに対して返信できます。

サブスクライバは、配布リストの受信者にも、Cisco Unity Connection から発信される個別のメッセージの受信者にもなることができます。

特定の製品におけるボイスメール ネットワーキングの詳細については、次の Web サイトで入手可能な該当するボイスメール製品のマニュアルを参照してください。

http://www.cisco.com/en/US/products/ps6509/index.html

複数の Cisco Unity Connection クラスタ間またはネットワーク間の相互運用性

Cisco Unity Connection(デジタル ネットワーク、HTTPS ネットワーク、スタンドアロン サーバ、またはクラスタ)は、他の Cisco Unity Connection(デジタル ネットワークまたは HTTPS ネットワーク)と相互運用できます。これにより、ユーザは、ディレクトリを共有したり、簡単に管理を行ったり、その他の機能を使用したりできます。また、ノード(クラスタまたはスタンドアロン サーバ)の合計数を最大 25 まで拡張できます。

デジタル ネットワーキング

デジタル ネットワーク システムは、ディレクトリ レプリケーションおよびメッセージ転送の両方で Simple Mail Transfer Protocol(SMTP)を使用します。図 19-16 に示すように、複数の Unity Connection ノードはディレクトリ情報を共有するために完全メッシュ トポロジで結合されます。完全メッシュ トポロジだけが Cisco Unity Connection デジタル ネットワーキングでサポートされます。

ネットワーキングに完全メッシュ トポロジを使用するのに必要なのは、ノード間の情報の転送用のシングル ホップだけですが、ノード数と共にリンクの数も増えます。

図 19-16 デジタル ネットワーキング

 

Cisco Unity Connection デジタル ネットワーキングを配置する際には、次のガイドラインを考慮してください。

各 Cisco Unity Connection デジタル ネットワークでは、最大で 10 のサーバをサポートできます。

単一の Cisco Unity Connection デジタル ネットワークは、最大 100,000 人のユーザをサポートしますが、より多くのユーザをサポートするために Voice Profile for Internet Mail(VPIM)ネットワーキングを使用して複数のデジタル ネットワークを組み合わせることができます。デジタル ネットワーク システム内のいずれかの Cisco Unity Connection ノードで Cisco Unity Connection 7.0 が実行されている場合、サポートされる最大ユーザ数は 50,000 です。

1 つの Cisco Unity Connection は、1 つの Cisco Unity Connection デジタル ネットワークだけに属することができます。

複数の Cisco Unity Connection デジタル ネットワークは VPIM を使用して組み合わせることができます。各 Cisco Unity Connection デジタル ネットワークには、ブリッジヘッドまたはサイト ゲートウェイとして定義されたサーバが 1 台必要です。ブリッジヘッドまたはサイト ゲートウェイは他のデジタル ネットワークと通信するために使用されます。

HTTPS ネットワーキング

HTTPS ネットワーキングは、ツリー構造のデータ レプリケーションをイネーブルにするハブ アンド スポーク トポロジを使用します。ハブはすべてのリーフ スポークの通信のシングル ポイントです。すべてのディレクトリ レプリケーションは HTTPS プロトコルを使用して、ハブ経由で行われます。各スポークはハブからディレクトリ情報を収集するリーフ ノードです。1 つのスポークは、1 つのハブにのみ接続できます。図 19-17 に示すように、スポーク クラスタ A および B はハブ クラスタ H に接続されます。クラスタ A がディレクトリ情報を取得する必要がある場合は、ノード H にクエリーを送信します。ハブ ノード H は自己とノード B のディレクトリ情報をノード A に複製します。

図 19-17 HTTPS ネットワーキング

 

Cisco Unity Connection HTTPS ネットワーキングを配置する際には、次のガイドラインを考慮してください。

単一の Unity Connection ノードまたはクラスタを 1 つの HTTP ネットワークのみのメンバーにすることができます。

単一の HTTPS ネットワークは、最大 100,000 人のユーザと 150,000 の接続をサポートしますが、100,000 人以上のユーザや接続をサポートするために Voice Profile for Internet Mail(VPIM)ネットワーキングを使用して複数のデジタルまたは HTTPS ネットワークを組み合わせることができます。

単一の HTTPS ネットワーク システムは 1 つのサイトをサポートし、各サイトに最大 25 ノードを持つことができますが、VPIM を使用して複数の HTTPS ネットワーク システムを組み合わせることができます。

すべての Cisco Unity Connection サーバは HTTPS ネットワーキングをサポートするバージョン 10.0 以上である必要があります。

HTTPS のネットワークでは、Cisco Unity Connection ロケーションはハブ アンド スポーク トポロジを使用して結合されます。どのロケーションに対しても、HTTPS の直接リンクの数は 5 以下である必要があります。

HTTPS ネットワーキングを同じサイトでデジタル ネットワーキングと使用することはできません。ただし、単一の HTTPS ネットワークは VPIM を使用してデジタル ネットワークと通信できます。各 Cisco Unity Connection デジタルまたは HTTPS ネットワークには、ブリッジヘッドまたはサイト ゲートウェイとして定義されたサーバが 1 台必要です。ブリッジヘッドまたはサイト ゲートウェイは他のデジタルまたは HTTP(S) ネットワークと通信するために使用されます。

完全同期はノードまたはクラスタが HTTPS ネットワークに追加された後に実行されます。ディレクトリ データに不一致がある場合、再同期が行われます。HTTPS ネットワーキングは、手動および自動の両方による完全同期と再同期をサポートしています。自動同期の定期的な間隔は設定可能です。

ディレクトリ レプリケーションは Unity Connection のパブリッシャ ノードを介して行われます。パブリッシャがダウンすると、このパブリッシャ ノードを介したディレクトリ レプリケーションが停止し、サブスクライバ ノードがディレクトリ レプリケーションを提供します。

これらの相互運用性オプションの詳細については、次の Web サイトで入手可能な『 Networking Guide for Cisco Unity Connection 』の最新バージョンを参照してください。

http://www.cisco.com/en/US/products/ps6509/prod_maintenance_guides_list.html

Cisco Unity Connection の仮想化

Cisco Unified Computing System(UCS)は、総所有コスト(TCO)を削減してビジネスの機動性を向上させることを目的として設計された統合システムに、コンピューティング、ネットワーキング、ストレージ アクセス、および仮想化を一体化した、次世代のデータセンター プラットフォームです。Cisco Unity Connection は、Cisco Unified Computing System の VMware による仮想化をサポートします。

Cisco Unity Connection の仮想化には、次の主な設計上の考慮事項が適用されます。

最大 20,000 人のユーザがサポートされます。

Tested Reference Configuration には、選択された Cisco Unified Computing System(UCS)プラットフォームが含まれます。その他のプラットフォームは、仕様ベースのハードウェアのサポート ポリシーによりサポートされる場合があります。

仮想化には、VMware ESXi が必要です。

アクティブ/アクティブ クラスタのサーバは異なるブレードに配置する必要があります。可能であれば異なるシャーシに配置します。


) 物理サーバごとに 1 つの CPU コアをアイドルにして、ESXi スケジューラ用に予約しておく必要があります。


仮想システムでの Cisco Unified Communications および Cisco Unity Connection の配置の詳細については、次の Web サイトで入手可能な資料を参照してください。

http://www.cisco.com/go/uc-virtualized

仮想サーバ上での Unified Communications の配置の全般的な情報については、「仮想サーバでの Unified Communications の配置」のセクションでも確認できます。

Cisco Unity Connection の仮想化については、次の Web サイトで入手可能な最新バージョンの『 Design Guide for Cisco Unity Connection 』も参照してください。

http://www.cisco.com/en/US/products/ps6509/products_implementation_design_guides_list.html

ボイス メッセージングのベスト プラクティス

ここでは、これまでに言及されていないが、ソリューションの中で、製品の重要な側面として考慮すべき一般的なベスト プラクティスとガイドラインを説明します。Cisco Unity Connection のグループと、Cisco Unity Express の 2 つのグループにわかれています。

Unified CM を使用した Cisco Unity Connection のベストプラクティス

この項の説明は、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 ロケーションとリージョン

 

図 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 では、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 統合の際に、システムレベルの録音形式やアドバタイズされるコーデックについて決定する場合は、次の要因を検討してください。

大部分のエンドポイントと Cisco Unity Connection の間で、どのコーデックがネゴシエートされるか。これは、Cisco Unity Connection によるアドバタイズメントが必要なコーデックとそうでないコーデックの判断に役立ちます。次に、たとえば多くのクライアントを G.722 や iLBC によって Cisco Unity Connection に接続する必要がある場合など、大きな処理能力を必要とする Cisco Unity Connection のネイティブ トランスコーディングの代わりに、Unified CM が、ハードウェア トランスコーディング リソースを提供する必要がある場合を決定できます。

どのタイプのグラフィカル ユーザ インターフェイス(GUI)クライアント(Web ブラウザ、電子メール クライアント、メディア プレーヤーなど)で録音を取得するか、またその GUI クライアントはどのコーデックをサポートするか。

選択したコーデックは、どの程度の品質のサウンドを生成するか。コーデックの中には、他のコーデックより高品質なものがあります。たとえば、G.711 は G.729a より品質が高く、高い音質が求められる場合に適切です。

1 秒間の録音にどの程度のディスク容量が必要か。

表 19-5 では、Cisco Unity Connection がサポートするコーデック形式の特徴を概観します。

表 19-5 コーデックの特徴

録音形式(コーデック)
音質
サポート状況
使用ディスク領域

リニア PCM

高品質

広範なサポート

16 KBps

G.711 mu-law および a-law

中間

広範なサポート

8 KBps

G.729a

低品質

限定的なサポート

1 KBps

G.726

中間

中程度のサポート

3 KBps

GSM 6.10

中間

中程度のサポート

1.6 KBps

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 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 のアドミニストレーション ガイドを参照してください。

http://www.cisco.com/en/US/products/ps6509/index.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 ポートを指定する必要はありません。

Annex M.1 の詳細については、次の Web サイトで入手可能な『 Cisco Unified Communications Manager System Guide 』を参照してください。

http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_guides_list.html

Cisco Unified CM Session Management Edition との統合

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 ゲートウェイの着発信番号情報要素(IE)配信リダイレクト

SIP トランク上の着発信の Diversion ヘッダー配信リダイレクト

非 Q.SIG MGCP、H.323 または SIP トランクで送信される転送情報は、リダイレクト DN に割り当てられたボイスメール プロファイルのボイス メールボックス マスクで定義された発信側変換だけをピックアップします。ルート パターンまたはルート リスト、または発信の発呼側変換コーリング サーチ スペース(CSS)で定義された発信側変換は、転送情報に適用されません。

Q.SIG 対応トランク

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 システムで使用されるディレクトリ番号と同じ形式である必要があります。次に、例を示します。

4YYYY 形式の電話番号を持つユーザには、同じ 4YYYY 形式を使用した、対応するボイスメールボックス番号を設定する必要があります。

E.164 +XX4YYYY 形式の電話番号を持つユーザには、同じ +XX4YYY 形式を使用した、対応するボイスメール ボックス番号を設定する必要があります。

Cisco Unity Connection では、ユーザのボイス メール ボックスに代替内線番号を関連付けることができます。次に、例を示します。

プライマリ VM ボックス番号:4YYYY

+E.164 の代替 VM ボックス番号:+XX4YYY

Redirected Dialed Number Information Service(RDNIS)は、Q.SIG 対応 H.323 または SIP トランクではサポートされません。元の着信側番号またはリダイレクト番号は、RDNIS 経由ではなく、Q.SIG DivertingLegInformation2 APDU で送信されます。

Cisco TelePresence Video Communication Server との統合

Cisco Unity Connection は、Cisco TelePresence Video Communication Server(VCS)と通信し、Cisco VCS に接続されたビデオ エンドポイントを許可して Cisco Unity Connection をボイス メッセージング システムとして使用できます。Cisco Unified CM に接続されたユーザ、および Cisco VCS に接続されたユーザは、互いにボイス メッセージを残すことができます。Diversion ヘッダー情報は Cisco VCS ではサポートされていないことに注意してください。この制限により、図 19-20 に示すように、Cisco Unity Connection と Cisco VCS 間で直接 SIP トランクを有効にする必要があります。

図 19-20 Cisco Unity Connection と Cisco VCS との統合

 

Cisco Unified CM を介した Cisco VCS から Cisco Unity Connection へのコール

Unified CM は、SIP トランクにわたって Unity Connection への To ヘッダーと Request URI を保持しないため、Unified CM を介した Cisco VCS から Cisco Unity Connection への無応答コールまたはビジー コールの転送はサポートされていません。VCS は、Unified CM に To ヘッダー情報内のサブスクライバ内線番号を送信しますが、この情報は、SIP トランクにわたって Unified CM から Unity Connection に送信される情報では保持されません。Cisco Unity Connection は、To ヘッダー情報内の内線番号(この場合は Unity Connection のパイロット番号)を使用し、転送された発信者には、サブスクライバのパーソナル グリーティングの代わりに Unity Connection 初期プロンプトが聞こえます。

この問題を回避するには、次の項で説明されているように、Cisco Unity Connection と Cisco VCS 間で直接 SIP トランクを有効にします。

直接 SIP トランクを介して Cisco VCS から Cisco Unity Connection に転送されるコール

直接 SIP トランクが Cisco Unity Connection と Cisco VCS 間で有効にされると、Cisco VCS からの無応答コールまたはビジー コールが一般的な Unity Connection 初期グリーティングの代わりにサブスクライバのメールボックスに転送されます。このシナリオでは、To ヘッダーの内線情報はサブスクライバの DN となり、Request URI はボイスメール パイロットとなります。また、それらは異なります。Cisco Unity Connection は、ユーザ部分の To ヘッダー内の内線番号を使用して、Unity Connection のサブスクライバのメールボックスに発信者を転送します。


) Unified CM がかかわらない VCS 専用配置では、Cisco Unity Connection と Cisco VCS 間の直接 SIP トランクが上記で説明したように機能します。


Cisco Unity Connection を Cisco VCS で配置する際には、次のガイドラインを考慮してください。

Cisco Unity Connection は、FindMe のビジーまたは無応答ターゲット ボイスメール デバイスとして設定できます。

Cisco Unity Connection への SIP 接続が Cisco VCS でアクティブであることを確認します。

外部と内部の両方の発信者は、Cisco VCS または Unified CM に接続されたビデオ エンドポイントにボイスメールを残すことができます。

Cisco TelePresence System EX60 または EX90 のメッセージ待機インジケータ(MWI)ボタンは、ボイスメールを受信すると点滅します。サブスクライバは、MWI ボタンを押すか Unity Connection パイロット番号にダイヤルしてボイスメールにアクセスできます。

Cisco Unity Connection では英数字の内線番号がサポートされていないため、内線番号は数字である必要があります。内線番号を E.164 ENUM 番号または FindMe 発信者 ID と同じ番号にすることを推奨します。

VCS ユーザに Unified CM 電話機のメールボックスが存在するシナリオでは、VCS ユーザ名を Unified CM 電話機メールボックスへの代行内線番号として設定します。これにより、Unified CM と VCS の個別のメールボックスを持つ代わりに、単一のメールボックスを持つことができます。

Cisco Unity Connection では英数字の内線番号のメッセージ待機インジケータがサポートされていません。Cisco Unity Connection は、Cisco VCS の設定済み IP アドレスまたはホスト名(たとえば、4001@VCS.domain.comFY)で、設定された内線番号に SIP NOTIFY メッセージを送信します。次に、VCS は、この内線番号から SIP URI への変換のための ENUM ゾーンを使用して、適切なビデオ エンドポイントに転送します。

設定の詳細については、次の Web サイトで入手可能な『 Cisco VCS and Cisco Unity Connection Voicemail Integration 』の展開ガイドを参照してください。

http://www.cisco.com/en/US/partner/products/ps11337/products_installation_and_configuration_guides_list.html

Cisco Unity Connection による E.164 番号サポート

Cisco Unity Connection は次のフィールドの E.164 番号形式をサポートします。

エンド ユーザのプライマリ内線番号

エンド ユーザに対する転送ルールの内線番号

システム コール ハンドラの内線番号

ディレクトリ ハンドラの内線番号

インタビュー ハンドラの内線番号

エンド ユーザに対する通知デバイスの電話番号

エンド ユーザの個人的な連絡先電話番号

Cisco Unity Connection System に関するシステムの連絡先電話番号

Cisco Unity Connection System のパーソナル着信転送ルール(PCTR)電話番号

エンドユーザの代行内線番号

Cisco Unity Connection System の規制パターン

Cisco Unity Connection System のメッセージ待機インジケータ(MWI)内線番号

ユーザを E.164 形式のプライマリ電話番号を持つ LDAP からインポートする場合、電話番号を内線番号に変換する正規表現と置換パターンを使用します。このタスクの詳細については、次の Web サイトで入手可能な『 System Administration Guide for Cisco Unity Connection 』を参照してください。

http://www.cisco.com/en/US/products/ps6509/prod_maintenance_guides_list.html

Unified CM から、AXL 統合を経由して、E.164 形式の内線番号とともにユーザをインポートする場合、E.164 内線番号を Unified CM から、カンマ区切り値(CSV)ファイルにエクスポートする必要があり、Bulk Administration Tool(BAT)を使用して、それらの番号を Unity Connection にインポートする前に、代行内線番号で必要な変換(たとえば、Excel 形式)を実行しなければなりません。Cisco Unity Connection Bulk Administration Tool の使用の詳細については、次の Web サイトで入手可能な『 User Moves, Adds, and Changes Guide for Cisco Unity Connection 』を参照してください。

http://www.cisco.com/en/US/products/ps6509/prod_maintenance_guides_list.html

拡張メッセージ待機インジケータ(eMWI)

Enhanced Message Waiting Indicator(eMWI; 拡張メッセージ待機インジケータ)は、従来の MWI を拡張したものであり、ボイス メッセージの数が視覚的に表示されます。従来の MWI は、新しいボイス メッセージが到着したときに電話機のメッセージ ランプをオンにし、ユーザのボイスメール ボックスから新しいボイス メッセージが削除されたときにオフにするという 2 値形式の表示です。eMWI は、Cisco Unity Connection を使用し、Cisco Unified IP Phone 8900 および 9900 シリーズの SIP 電話機でサポートされます。

eMWI では、ユーザのボイスメール ボックス内の未再生メッセージが視覚的に表示され、メッセージのステータスが色付きで表示されます。未再生のメッセージは、電話機の画面で赤く表示されます。eMWI は、Unified CM において、Cisco Unity Connection の SIP および SCCP 統合でサポートされています。eMWI は、システムが SRST モードで実行されている場合には機能しません。Cisco Unity Connection との統合においては、Cisco Unity Connection サーバ上に保管されているメッセージだけが eMWI で通知され、外部の IMAP サーバに保管されているメッセージについては通知されません。

eMWI は、Unified CM を使用した分散型呼処理環境で動作します。1 つのクラスタがクラスタ間トランク(H.323 または SIP)経由でボイス メッセージング サーバへの接続を提供する、分散型呼処理と集中型ボイス メッセージング統合のシステムでは、クラスタ間トランク経由での eMWI 更新がサポートされており、エンド デバイスに表示されます(図 19-21 を参照)。


) eMWI は、クラスタ間トランク(H.323 または SIP)経由の、集中型メッセージングと分散型呼処理の環境でも動作します。


図 19-21 拡張メッセージ待機インジケータ(eMWI)

 

図 19-22 に、クラスタ間トランク(H.323 または SIP)経由の、分散型呼処理と集中型ボイス メッセージングの環境における eMWI を示します。

図 19-22 分散型呼処理と集中型ボイス メッセージングの eMWI

 

図 19-22 に示すように、クラスタ 2 およびそのボイス メッセージング ソリューションでは eMWI がサポートされますが、クラスタ 1 ではサポートされません。ボイス メッセージ数が含まれた eMWI 更新がボイス メッセージ ソリューションからクラスタ 2 の電話機に送信された場合、クラスタ 1 では、ボイス メッセージ数なしの標準 MWI だけがクラスタ 2 に転送されます。

eMWI には、次のガイドラインが適用されます。

すべてのクラスタで eMWI がサポートされている必要があります。中間クラスタで eMWI がサポートされていない場合、終端のクラスタでは、ボイス メッセージ数なしの標準 MWI だけが受信されます。

標準の MWI では、ランプ状態の変更(オンまたはオフ)だけが送信されるため、多くのトラフィックは生成されません。ただし、eMWI を有効にすると、メッセージング システムからメッセージ数も送信されるため、トラフィック量が増える可能性があります。トラフィック量は、メッセージ数と変更通知数に依存します。

Unified CM クラスタとの音声ポート統合

単一サイト メッセージング環境に Cisco Unity Connection を配置する場合、Unified CM クラスタとの統合は SCCP 音声ポートまたは SIP トランクを介して行われます。Unified CM サブスクライバに障害が発生した場合でも(Unified CM フェールオーバー)、ユーザおよび外部コールが引き続きボイス メッセージングにアクセスできるように、設計上の考慮事項には、Cisco Unified CM サブスクライバ間の音声ポートの適切な配置についても考慮する必要があります(図 19-23 を参照)。

図 19-23 Unified CM クラスタと統合された Cisco Unity Connection サーバ(専用バックアップ サーバなし)

 

図 19-23 の 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 用)の比率に関する設計上の詳細情報については、次の Web サイトで入手可能な『 Cisco Unity Connection System Administration Guide 』を参照してください。

http://www.cisco.com/en/US/products/ps6509/index.html


) デバイス名プレフィックスは、ポートのグループごとに一意で、Unified CM Administration に設定されているボイスメール ポートの命名規則と一致する必要があります。


Unified CM Administration では、この例のポートの半分が一意なデバイス名プレフィックス CiscoUM1 を使用して登録されるように設定され、残りの半分が一意のデバイス プレフィックス(CiscoUM2)を使用して登録されるように設定されています( 表 19-6 を参照)。 表 19-6 に示すように、ポートが Unified CM に登録される場合、半分がサブスクライバ サブ 1 に登録され、残りの半分がサブ 2 に登録されます。

表 19-6 Unified CM Administration でのボイスメール ポート設定

デバイス名
説明
デバイス プール
SCCP セキュリティ プロファイル
ステータス
IP アドレス

CiscoUM1-VI1

Unity Connection 1

デフォルト

Standard Profile

サブ 1 に登録

1.1.2.9

CiscoUM1-VI2

Unity Connection 1

デフォルト

Standard Profile

サブ 1 に登録

1.1.2.9

CiscoUM1-VI3

Unity Connection 1

デフォルト

Standard Profile

サブ 1 に登録

1.1.2.9

CiscoUM1-VI4

Unity Connection 1

デフォルト

Standard Profile

サブ 1 に登録

1.1.2.9

CiscoUM2-VI1

Unity Connection 1

デフォルト

Standard Profile

サブ 2 に登録

1.1.2.9

CiscoUM2-VI2

Unity Connection 1

デフォルト

Standard Profile

サブ 2 に登録

1.1.2.9

CiscoUM2-VI3

Unity Connection 1

デフォルト

Standard Profile

サブ 2 に登録

1.1.2.9

CiscoUM2-VI4

Unity Connection 1

デフォルト

Standard Profile

サブ 2 に登録

1.1.2.9


) Unified CM Administration でボイスメール ポートに使用される命名規則は、Cisco UTIM で使用されるデバイス名プレフィックスと一致する必要があります。一致しないと、ポートの登録に失敗します。


専用 Unified CM バックアップ サーバを使用する音声ポート統合

この Unified CM クラスタ構成では、各サブスクライバ サーバが 50% を超える呼処理負荷で動作できます。各プライマリ サブスクライバ サーバは、専用バックアップ サーバまたは共有バックアップ サーバを持ちます(図 19-24 を参照)。正常な動作時、バックアップ サーバはコールを処理しませんが、サブスクライバ サーバの障害時またはメンテナンス時に、バックアップ サーバはそのサブスクライバ サーバのすべての負荷を担います。

図 19-24 単一の 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 のアドミニストレーション ガイドを参照してください。

http://www.cisco.com/en/US/products/ps6509/index.html

Cisco Unity Connection による IPv6 サポート

現行の 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 は、IPv6 を介した自動検出機能を備え、Unity Connection が通信相手の Microsoft Exchange Server を検索できるようにします。

Cisco Unity Connection は、IPv6 Microsoft Exchange 2007 または 2010 サーバと統合してシングル インボックス機能をイネーブルにできます。

Cisco ViewMail for Outlook(VMO)は、IPv6 を介した Outlook と Cisco Unity Connection との通信をサポートします。

Cisco Unity Connection で受信されたボイス メッセージは、IPv6 上の Outlook などの IMAP クライアントを使用してアクセスできます。

Cisco Unity Connection は、IPv6 を介して LDAP と統合し、ユーザ情報をインポートできます。

Cisco Unity Connection はまた、IPv6 を介した Telephone Record and Playback(TRaP)機能を提供し、これによりユーザは 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 Server との相互運用性をサポートします。Unity Connection は、Microsoft Exchange Online を使用してシングル インボックス機能をイネーブルにします。詳細については、次の Web サイトで入手可能な『 Unified Messaging Guide for Cisco Unity Connection 』の最新バージョンを参照してください。

http://www.cisco.com/en/US/partner/products/ps6509/prod_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 Connection は、シスコのパートナーである Esnatech および Donoma のソフトウェアを使用して IBM Lotus Domino と統合し、シングル インボックス機能をイネーブルにできます。Esnatech Office-LinX TM Cloud Connect Edition および Donoma Unify for Lotus Notes は、いずれも Unity Connection と IBM Lotus Domino との統合を可能にします。これらの製品の設定、インストール、展開の詳細については、 http://www.esnatech.com/landing/cisco.htm および http://donomasoftware.com/donoma-unify-for-lotus-notes/ を参照してください。

Cisco Unity Connection はまた、Google Apps Gmail や VMware Zimbra といったクラウドベースのアプリケーションとの音声および FAX サービスの統合をサポートします。Unity Connection は、Esnatech Office-LinX TM Cloud Connect Edition を使用してこれらの電子メール アプリケーションと統合できます。このソリューションでは、Cisco Unity Connection とこれらの電子メール アプリケーションとの間で、ボイス メッセージの双方向同期が可能です。(図 19-25を参照)。

図 19-25 Cisco Unity Connection のクラウドベースの Google 電子メール アプリケーションとの配置

 

Esnatech Cloud Connect Edition は、サブスクライバおよびメッセージング情報の同期に Cisco Unity Connection Messaging Interface(CUMI)API と Cisco Unity Connection Provisioning Interface(CUPI)API を使用します。ユーザは、クリックツーダイヤル機能を使用して Gtalk によってコールを開始できます。この呼制御情報は CTI(TAPI)インターフェイスを介して Cisco Unified Communications Manager と交換されます。配置、インストールおよび設定について詳しくは、 http://www.esnatech.com/landing/cisco.htm で入手可能なマニュアルを参照してください。

Cisco Unity Express の配置に関するベスト プラクティス

Cisco Unity Express を配置する場合は、次のガイドラインとベスト プラクティスを使用してください。

ボイスメールの宛先として Cisco Unity Express を持つ IP フォンが、Cisco Unity Express をホストするルータと同じ LAN セグメントに置かれていることを確認します。

Cisco Unity Express を使用して配置するサイトで無停止の AA と電子メール アクセスが必要な場合は、Cisco Unity Express、SRST、および PSTN の音声ゲートウェイがすべて同じ物理サイトに置かれていることを確認します。ホットスタンバイ ルータ プロトコル(HSRP)やその他の冗長性ルータ設定は、現在、Cisco Unity Express ではサポートされていません。

各メールボックスは、プライマリ内線番号とプライマリ E.164 番号に関連付けることができます。通常、この番号は、PSTN の発信者が使用する Direct-Inward-Dial(DID)番号です。プライマリ E.164 番号が他の番号に設定されている場合、SRST モード時に正しいメールボックスに到達するように、Cisco IOS トランスレーション パターンを使用して、プライマリ内線番号かプライマリ E.164 番号に一致させます。

Unified CM とのボイスメール統合

各 Cisco Unity Express サイトは、ボイスメール用と AA 用(ライセンスされ、購入している場合)に CTI ルート ポイントを 1 つずつ関連付ける必要があります。またライセンスされた Cisco Unity Express ポートと同じ数の CTI ポートを設定する必要があります。Cisco Unity Express の数が、「呼処理」の章に示すスケーラビリティ ガイドラインを超えないことを確認します。

Cisco Unity Express は、Unified CM 上の JTAPI ユーザに関連付けられます。単一の JTAPI ユーザをシステム内の Cisco Unity Express の複数のインスタンスに関連付けることは可能ですが、Unified CM 内の専用の JTAPI ユーザをそれぞれ単一の Cisco Unity Express に関連付けることを推奨します。

Unified CM を以前のバージョンからアップグレードした場合、JTAPI ユーザのパスワードは、Unified CM で自動的にリセットされます。したがって、管理者は、アップグレードの後、JTAPI パスワードが Cisco Unity Express と Unified CM の間で同期化され、Cisco Unity Express を Unified CM に登録できることを確認する必要があります。

CTI ポートと CTI ルート ポイントは、特定の場所で定義できます。Unified CM と Cisco Unity Express の間で、ロケーションベースのコール アドミッション制御を使用することを推奨します。RSVP を使用することもできます。

Cisco Unity Express と Unified CM の間を通過する WAN のシグナリング トラフィックのための、適切な Quality of Service(QoS)と帯域幅を確保します。各 Cisco Unity Express サイトの CTI-QBE シグナリングのために、20kbps の帯域幅をプロビジョニングします。詳細については、「ネットワーク インフラストラクチャ」の章を参照してください。

Unified CM から Cisco Unity Express への CTI-QBE シグナリング パケットは、AF31(0x68)という DSCP 値でマーキングされています。Unified CM は、CTI-QBE シグナリングに TCP ポート 2748 を使用します。

Unified CM JTAPI ライブラリは、すべての発信 QBE シグナリング パケットに、適正な IP Precedence ビットを設定します。その結果、Cisco Unity Express と Unified CM の間のすべてのシグナリングに、適正な QoS ビットが設定されます。

Cisco Unity Express コーデックと DTMF のサポート

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 コールをサポートします。

JTAPI、SIP トランクおよび SIP 電話機のサポート

Cisco Unified CM は SIP トランク プロトコルをサポートしますが、Cisco Unity Express は Unified CM との通信に JTAPI を使用します。Cisco Unity Express は、SCCP 電話機と SIP 電話機の両方をサポートします。

SRST を使用できるように SIP トランクを設定し、(JTAPI によって)SIP 電話機をサポートするように Unified CM を設定します。

Cisco Unity Express は、トランスコーダ経由で G.729 SIP コールをサポートします。また Cisco IOS Release 12.3(11)XW で RFC 2833 がトランスコーダをパススルーする能力が追加されています。

Cisco Unity Express は、Unified CM からのスロースタート コールの場合、コール設定のためのディレイド メディア(delayed media、INVITE メッセージ内に SDP なし)をサポートします。

Cisco Unity Express は、ブラインド転送と打診転送の両方をサポートしますが、デフォルトの転送モードは、SIP コールで REFER を使用した打診転送(半自動)です。転送モードを、REFER を使用する打診転送または BYE/ALSO を使用するブラインド転送に明示的に変更するには、Cisco Unity Express コマンドライン インターフェイスを使用します。リモート エンドで REFER がサポートされていない場合は、BYE/ALSO が使用されます。

Cisco Unity Express は、ボイス メッセージ通知のためのアウトコールをサポートしています。また、打診転送もサポートしています。これらのいずれのコール設定時でも、Cisco Unity Express は INVITE に対する 3 xx 応答を受信できます。Cisco Unity Express は、INVITE に対する 301(Moved Permanently)と 302(Moved Temporarily)応答のみを処理します。これには、3 xx 応答の Contact ヘッダーに含まれ、新しい INVITE の送信に使用する URL が必要です。305(Use Proxy)応答は、サポートされていません。


) Cisco Unified CM と Cisco Unity Express との間の互換性については、http://www.cisco.com/en/US/docs/voice_ip_comm/unity_exp/compatibility/cuecomp.htm で入手可能な『Cisco Unity Express Compatibility Matrix』を参照してください。


Cisco Unity Express の詳細については、次の Web サイトで入手可能な製品マニュアルを参照してください。

http://www.cisco.com/en/US/products/sw/voicesw/ps5520/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)がありますが、ユーザ インターフェイスが使いにくく、アナログ テクノロジーが使用されており、機能も少ないことから、ほとんど使用されていません。