Cisco Unified Communications システム リリース 8.x SRND
シスコのボイス メッセージング
シスコのボイス メッセージング
発行日;2012/12/18 | 英語版ドキュメント(2012/07/30 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 39MB) | フィードバック

目次

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

この章の新規情報

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

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

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

集中型メッセージング

分散型メッセージング

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

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

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

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

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

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

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

メッセージングの冗長性

Cisco Unity

Cisco Unity Connection

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

離れたデータセンターに配置された Cisco Unity のフェールオーバー

WAN 経由での Cisco Unity Connection の冗長性とクラスタリング

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

Cisco Unity Express の配置モデル

Cisco Unity Express の概要

配置モデル

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

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

Cisco Unified Messaging Gateway によるボイスメール ネットワーキング

ボイスメールの相互運用性

Cisco Unity と Cisco Unity Connection の相互運用性

Cisco Unity Connection と Cisco Unity Connection の相互運用性

Cisco Unity と Unity Connection の仮想化

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

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

帯域幅の管理

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

Cisco Unity の動作

Cisco Unity でのネイティブ トランスコーディングの無効化

Cisco Unity Connection の動作

UnifiedCM との統合

Cisco Unity Connection による IPv6 サポート

Cisco Unity Connection による単一受信トレイ

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

UnifiedCM とのボイスメール統合

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

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

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

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

この章では、Cisco Unified Communications システムで利用可能なボイス メッセージング ソリューションについて説明します。この章では、シスコのボイス メッセージング製品である Cisco Unity、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 呼処理配置モデルにおける各メッセージング配置モデルの位置付けを説明します。さらに、さまざまな冗長性オプションの設計、および Survivable Remote Site Voicemail について説明します。この項では、Cisco Unity と Unity Connection を一緒に説明します。Cisco Unity Express については、別に専用の項を設けて、それがサポートする配置モデルを説明します。シスコのボイス メッセージング製品ポート フォリオ内で利用可能な相互運用性のための主要な設計ガイドラインについて説明します。新しい概念である仮想化、および仮想システム設計時に考慮する必要がある重要な設計上の要素について説明します。この項では、トランスコーディングや Cisco Unified Communications Manager とのさまざまな統合を含む、多くのシステムレベルの設計上の考慮事項およびベスト プラクティスについて説明します。さらに、この章では、サポートされている業界標準プロトコルを使用したサードパーティ製ボイスメール統合の詳細について説明します。

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

Cisco Unity Connection 設計ガイド

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

Cisco Unity 設計ガイド

http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_implementation_design_guides_list.html

この章の新規情報

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

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

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

Cisco Unity の販売終了およびサポート終了日

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

2012 年 7 月 31 日

Survivable Remote Site Voicemail(SRSV)の販売終了およびサポート終了日

「Survivable Remote Site Voicemail」

2012 年 4 月 30 日

Voice Profile for Internet Mail(VPIM)機能の販売終了およびサポート終了日

「Cisco Unified Messaging Gateway によるボイスメール ネットワーキング」

2012 年 4 月 30 日

仮想化

「Cisco Unity と Unity Connection の仮想化」

2011 年 7 月 29 日

Cisco Unity Connection での E.164 サポート

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

2011 年 6 月 2 日

Cisco Unity Connection での IPv6 サポート

「Cisco Unity Connection による IPv6 サポート」

2010 年 11 月 15 日

Cisco Unity Connection 用の単一受信トレイ

「Cisco Unity Connection による単一受信トレイ」

2010 年 11 月 15 日

Cisco Unity と Unity Connection の冗長性

「メッセージングの冗長性」

2010 年 4 月 2 日

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

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

2010 年 4 月 2 日

Survivable Remote Site Voicemail(SRSV)

「Survivable Remote Site Voicemail」

2010 年 4 月 2 日

仮想化

「Cisco Unity と Unity Connection の仮想化」

2010 年 4 月 2 日

ボイスメールの相互運用性

「ボイスメールの相互運用性」

2010 年 4 月 2 日

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

Cisco Unified Communications のメッセージング ポートフォリオは、Cisco Unity、Cisco Unity Connection、および Cisco Unity Express の 3 つの主なメッセージング製品で構成されます。それぞれの製品が対応する要件は異なりますが、互いに他の製品と重なり合う機能とスケーラビリティを備えています。Voice Mail Networking を使用することで連携して動作することもできます。また、Cisco Unified Messaging Gateway を利用して、非常にスケーラブルな形でこれを実現することも可能です。これについては、この章で後ほど説明します。

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

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

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

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

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

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

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

ボイスメール専用

Yes

Yes

Yes

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

Yes

Yes

Yes

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

Yes

Yes

No


) Cisco Unity Connection を使用したユニファイド メッセージングの詳細については、「Cisco Unity Connection による単一受信トレイ」を参照してください。


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

Cisco Unity

このソリューション オプションは、大企業の組織が抱えるニーズにも対応可能な拡張性を持っており、Microsoft Exchange(Exchange 2007/2010 を含む)に統合可能な強力なボイス メッセージング、ユニファイド メッセージング、ユニファイド メッセージングのオプションを提供します。

Cisco Unity Connection

このオプションは、20,000 ユーザ以下の中規模企業用に、ユニファイド メッセージング、音声認識、およびコール転送ルールを 1 つのシステムに組み合わせて管理しやすくしたものです。また、デジタル ネットワーク システムに最大 10 のノードをネットワーク接続できます (必要であれば、さらに 2 つのデジタル ネットワークを結合して最大 20 ノードをサポートできます)。Cisco Unity Connection は、1 つのデジタル ネットワークで最大 100,000 ユーザまたは連絡先をサポートできます。500 ユーザ以下の組織では、Cisco Unity Connection をシングル サーバ ソリューションとして、Cisco Business Edition 3000 および 5000 で使用できます。Cisco Business Edition の詳細については、「呼処理の設計上の考慮事項」を参照してください。

Cisco Unity Express

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


) Cisco Unity は販売終了(EoS)およびサポート終了日(EoL)に達しました。現時点では、Cisco Unity に代わるものはありません。詳細については、次の URL にある販売終了およびサポート終了日のお知らせを参照してください。
http://www.cisco.com/en/US/prod/collateral/voicesw/ps6789/ps5745/ps6509/end_of_life_notice_c51-681593.html


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

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

 

表 21-3 ボイス メッセージング ソリューションのスケーラビリティ

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

Cisco Unity Express

Y

N

N

Y

Y

Cisco Business Edition

Y

N

N

N

N

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

Y

Y

Y

Y

N

Cisco Unity(ユニファイド メッセージングおよびボイス メッセージング)

Y

Y

N

Y

Y

1.Cisco Unified Messaging Gateway を使用してさまざまな製品をネットワーク接続すると、サポートされるユーザ数が大幅に増加します。サポートされるユーザ数は、ネットワーク接続されたノード数および Unified Messaging Gateway でサポートされる最大ユーザ数に直接関連します。Cisco Unified Messaging Gateway のスケーラビリティの詳細については、http://www.cisco.com/en/US/products/ps8605/products_data_sheets_list.html で入手可能な『Cisco Unified Messaging Gateway data sheet』を参照してください。


) Voice Profile for Internet Mail(VPIM)プロトコルおよびデジタル ネットワーキングのいずれを使用してもサポートされる最大ユーザ数が大幅に増加しますが、デジタル ネットワーキングでは、追加のサーバ検出機能およびディレクトリ同期化機能が提供されます。


スケーラビリティの詳細については、「Cisco Unified Messaging Gateway によるボイスメール ネットワーキング」を参照してください。

Cisco Unified Messaging Gateway によるボイスメール ネットワーキング

Cisco Unified Messaging Gateway(UMG)は、インテリジェント ボイス メッセージング ルーティング、システム ディレクトリの管理、メッセージング形式、およびスケーラブルなボイス メッセージング フレームワークを提供することによって、エンドツーエンドのネットワーク接続されたボイス メッセージング ソリューションを可能にします。Cisco UMG は、Cisco Unity、Cisco Unity Express、Cisco Unity Connection、および Avaya Interchange をサポートします。

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

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

上で説明したように、この章で扱う設計に関するトピックは、ボイスメールのみの設定、ユニファイド メッセージング設定、およびユニファイド メッセージング設定に適用されます。加えて、この章では、Microsoft Exchange(2003、2007、または 2010)および Microsoft Windows(2003)を使用した Cisco Unity または Cisco Unity Connection の配置の設計面についても説明します。また、Microsoft Active Directory(AD)2008 のサポートも Cisco Unity 7. x 以降のリリースで追加されました。この章では、Microsoft NT 4.0 や Exchange 5.5 による配置、および Microsoft NT 4.0 や Exchange 5.5 からのアップグレードにおける設計については説明しません。Cisco Unity Connection および Unity Express は外部メッセージ ストアに依存しません。Cisco Unity Connection 8. x は、Exchange 統合をサポートしますが、Cisco Unity と異なり、Exchange 統合に依存しません。


) Microsoft Exchange 2010 および Active Directory 2008 R2 をサポートする Cisco Unity の正確なバージョンについては、Cisco Unity のリリース ノート(http://www.cisco.com/en/US/products/sw/voicesw/ps2237/prod_release_notes_list.html)を参照してください。


シスコ以外のメッセージング システムとの統合など、Cisco Unity または Cisco Unity Connection に関するその他の設計情報については、 http://www.cisco.com で入手可能な『 Design Guide for Cisco Unity 』または『 Design Guide for Cisco Unity Connection 』をそれぞれ参照してください。

Cisco Unity Express に関するその他の設計情報については、 http://www.cisco.com で入手可能な製品マニュアルを参照してください。

シスコ以外のメッセージング システムとの統合など、Cisco Unified Messaging Gateway に関するその他の設計情報については、 http://www.cisco.com で入手可能な Cisco Unified Messaging Gateway の製品マニュアルを参照してください。

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

この章では、Cisco Unity、Cisco Unity Connection、および Cisco Unity Express について、さまざまなメッセージング配置モデルの概要を示します。Cisco Unity、Unity Connection、およびさまざまなメッセージング コンポーネントに固有の配置モデルや設計上の考慮事項の詳細については、 http://www.cisco.com で入手可能な『 Design Guide for Cisco Unity 』または『 Design Guide for Cisco Unity Connection 』をそれぞれ参照してください。Cisco Unity Express については、 http://www.cisco.com で入手可能な製品マニュアルを参照してください。

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

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

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

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

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

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

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

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


) Cisco Unity Express は、最大 10 の Unified CME を持つ集中型ボイス メッセージングをサポートします。詳細については、http://www.cisco.com で Cisco Unified Communications Manager Express の資料を参照してください。


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

3 つのメッセージング配置モデルに加えて、Cisco Unity はメッセージング冗長性もサポートしています (「メッセージングの冗長性」を参照)。アクティブ/アクティブ設定では、Cisco Unity Connection のメッセージング冗長性も利用できます。詳細については、 http://www.cisco.com で入手できる『 Design Guide for Cisco Unity Connection 』を参照してください。

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

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

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

集中型メッセージング

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

メッセージング クライアントはメッセージング システムのローカルで使用されることもリモートで使用されることもあるため、ViewMail for Outlook(VMO)を使用する場合、および Telephone Record and Playback(TRaP; 電話での録音および再生)機能とメッセージ ストリーミング機能を Cisco Unity で使用する場合は、これらのグラフィカル ユーザ インターフェイス(GUI)クライアントには設計上特別に考慮する必要がある事項があります。リモート クライアントは、TRaP を使用すべきではありません。また、リモート クライアントは、再生前にメッセージをダウンロードするように設定する必要があります。ローカル クライアントとリモート クライアントで機能や操作が異なるとユーザが混乱するおそれがあるため、音声ポートで TRaP を無効にし、クライアントがローカルであるかリモートであるかに関係なく、メッセージをダウンロードするように設定し、TRaP を使用しないように GUI クライアントを設定する必要があります。このことは、Cisco Unity IMAP クライアントの ViewMail for Outlook(VMO)に対して当てはまります。これらの設計上の考慮事項は、Cisco Unity に固有の事項です。

Cisco Unity Telephone User Interface(TUI; 電話ユーザ インターフェイス)は、ローカル クライアントとリモート クライアントの両方に対して同様に動作します。

分散型メッセージング

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

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

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

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

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

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

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

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

Yes

Yes

Yes

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

Yes

Yes

No2

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

Yes

Yes

Yes

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

Yes

Yes

No1

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

Yes

Yes

Yes

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

Yes

Yes

No

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

Yes

Yes

Yes

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

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

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

Cisco Unity Express の配置モデル

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

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

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

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

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

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

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

 

図 21-1 では、リージョン 1 と 2 が、リージョン内コールに G.711 を使用し、リージョン間コールに G.729 を使用するように設定されています。Cisco Unity サーバ上でネイティブ トランスコーディングは無効になっています。

図 21-1 で示しているように、内線番号 200 からリージョン 1 のボイスメール ポートにコールが発信されると、エンドポイントではリージョン間の G.729 コーデックが使用されますが、RTP ストリームがトランスコードされ、音声ポート上では G.711 が使用されます。この例では、Cisco Unity サーバ上のネイティブ トランスコーディングが無効になっています。Unified CM トランスコーディング リソースは、ボイスメール システムと同じサイトに置く必要があります。

AAR によってルーティングされるボイスメール コールで RDNIS が送信されないことによる影響

集中メッセージング環境では、WAN がオーバーサブスクリプションの状態になった場合に、Unified CM の機能である Automated Alternate Routing(AAR; 自動代替ルーティング)が、PSTN を介してコールを中央サイトのメッセージング ストアにルーティングできます。ただし、PSTN を介してコールが再ルーティングされる場合、Redirected Dialed Number Information Service(RDNIS)が損なわれることがあります。Cisco Unity または Unity Connection がメッセージング クライアントに対してリモートである場合は、正しくない RDNIS 情報によって、AAR が外線を介して再ルーティングするボイスメール コールに影響が及ぼされることがあります。RDNIS 情報が正しくない場合、コールはダイヤル先のユーザのボイスメール ボックスに到達せず、自動アテンダント プロンプトを受信します。発信者は、到達を試みているユーザの内線番号を再入力するように要求されることがあります。この動作は、主に、電話通信事業者がネットワークを介した RDNIS を保証できない場合の問題です。通信事業者が RDNIS の正常な送信を保証できない理由は数多くあります。通信事業者に問い合わせて、回線のエンドツーエンドで RDNIS の送信を保証しているかどうかを確認してください。オーバーサブスクリプションの状態になった WAN に対して AAR を使用する代わりの方法は、単に、オーバーサブスクリプションの状況で発信者にリオーダー トーンが聞こえるようにすることです。

Survivable Remote Site Voicemail

Survivable Remote Site Voicemail(SRSV)では、集中型メッセージングと集中型呼処理配置において、バックアップ ボイスメール サービスが提供されます。SRSV では、サイト間の接続が利用できない場合に、支店ロケーションにある Cisco Unity Express を利用して、本社にある Cisco Unity Connection に代わるバックアップ ボイスメール サービスを提供します。(図 21-2 を参照)。通常の動作において、本社の Cisco Unified Messaging Gateway は設定(SRST 電話機、ユーザ、メールボックスの情報など)を Cisco Unified CM および Cisco Unity Connection から取得し、設定されたスケジュールに基づいて Cisco Unity Express SRSV のメールボックスをプロビジョニングおよび更新します。Cisco Unity Express SRSV は、SRST がアクティブである場合にだけアクティブとなり、それ以外の場合にはアイドルとなります。サイト間のネットワーク接続が復元されると、Cisco Unity Express SRSV から Cisco Unity Connection にすべてのメッセージ(新規メッセージ、保存されたメッセージ、削除されたメッセージなど)がアップロードされます。

図 21-2 一般的な Survivable Remote Site Voicemail 配置

 


) Survivable Remote Site Telephony(SRST)および Cisco Unity Express SRSV は 1 つの論理ユニットであり、SRST ルータに Cisco Unity Express SRSV がインストールされます。



) Cisco Unified Messaging Gateway SRSV 機能は、販売終了(EoS)およびサポート終了日(EoL)に達しました。現時点では、SRSV 機能に代わるものはありません。詳細については、次の URL にある販売終了およびサポート終了日のお知らせを参照してください。
http://www.cisco.com/en/US/prod/collateral/voicesw/ps6789/ps5745/ps8605/end_of_life_notice_c51-695653.pdf


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

Unified CM および Cisco Unity Connection から Cisco Unity Express SRSV への設定のアップロード

WAN リンクが復元された場合の Cisco Unity Express SRSV から Cisco Unity Connection へのボイス メッセージのアップロード

既存の音声ネットワークへの SRSV トラフィックの影響を最小限に抑えるために、SRSV トラフィック(設定およびボイス メッセージのアップロード)をベストエフォートとして分類します。SRSV ソフトウェアでは、どのネットワーク パケットもマーキングされません。音声トラフィックやその他の優先順位の高いトラフィックを優先するために、ネットワーク エッジ ルータで SRSV トラフィックを IP Precedence 0(DSCP 0 または PHB BE)とマークすることを推奨します。さらに影響を少なくするために、設定のアップロードはピーク時以外の時間(夜間や週末など)にスケジュールすることを推奨します。スケジュールは、Unified Messaging Gateway SRSV Web インターフェイスで設定できます。

SRSV を配置する場合、次のルールが適用されます。

Unified Messaging Gateway SRSV では、最大で 1,000 の Cisco Unity Express SRSV ノードがサポートされます。

SRSV では、Cisco Unified CM Business Edition はサポートされません。

Cisco Unity Express SRSV は、SRST ルータ、または SRST モードで実行されている Unified CME にインストールします。

支店内に複数の SRST ルータを配置することはできますが、各ルータに独自の Cisco Unity Express SRSV が必要です。また、各ルータには 1 つの Cisco Unity Express SRSV だけを設定できます。

ボイス メッセージのアップロードでハイ アベイラビリティを確保するには、冗長な Unified Messaging Gateway SRSV を配置します。Unified Messaging Gateway SRSV では、設定のアップロードにおけるハイ アベイラビリティはサポートされていません。

Unified Messaging Gateway SRSV と Cisco Unity Express SRSV との間の接続でセキュリティを確保するには、Secure Socket Layer(SSL)プロトコルを使用します。

SRSV では、Cisco Unity はサポートされていません。

SRSV の詳細については、 http://www.cisco.com/go/srsv で入手可能なマニュアルを参照してください。

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

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

図 21-3 では、集中型呼処理を使用する分散型メッセージング モデルを示しています。他のマルチサイト呼処理モデルと同様に、WAN 帯域幅を管理するためにリージョンとロケーションを使用する必要があります。このモデルでは、Cisco Unity でネイティブ トランスコーディングを無効にする必要もあります。

SRST モードの Cisco Unified Communications Manager Express(Unified CME)は、IP 電話および Cisco Unity または Unity Connection ボイスメール ポートの両方の呼処理バックアップに使用されます。このフォールバック サポートは、リモート サイト(たとえば、図 21-3 のリージョン 2)に配置され、WAN 障害などのために電話機と Unified CM との接続が失われた場合に、バックアップの呼処理を提供します。またリモート サイトのユーザに対し、WAN 障害時に、ローカルの Cisco Unity または Unity Connection サーバへのアクセスと MWI のサポートを提供します。SRST モードの Unified CME の詳細については、 http://www.cisco.com で入手可能な Unified CME の製品マニュアルを参照してください。

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

 

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

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

メッセージング システムは相互に「ネットワーク接続」され、内部ユーザと外部ユーザの両方に単一のメッセージング システムを提供します。分散 Unity サーバ向けの Cisco Unity ネットワーク機能については、次の Web サイトで入手可能な『 Networking in Cisco Unity Guide 』を参照してください。

http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_feature_guides_list.html

Cisco Unity Connection では、デジタル ネットワーキングがサポートされており、複数の Cisco Unity Connection システムを相互にネットワーク接続できます。デジタル ネットワーク システムでは、最大で 10 のノード(単一ノードまたはアクティブ/アクティブ ペア)を接続できます。また、必要に応じて 2 つのデジタル ネットワークを結合して、最大で 20 のノードをサポートできます。デジタル ネットワークでは、ディレクトリの最大 100,000 のエンティティがサポートされます。Cisco Unity Connection は、Microsoft Active Directory などの企業ディレクトリに統合して、ユーザを同期化し、デジタル ネットワーキングを同時に使用できます。この設定では、各 Cisco Unity Connection サーバまたはサーバ ペアが、企業ディレクトリから最大 20,000 ユーザを同期化できます。Cisco Unity Connection でのデジタル ネットワーキングまたはディレクトリ統合の詳細については、 http://www.cisco.com で入手できる『 Design Guide for Cisco Unity Connection 』を参照してください。

Cisco Unity と Unity Connection および SRST モードの Unified CME

SRST モードの Unified CME を使用すると、Cisco Unity サーバと Unity Connection サーバの両方をリモート サイトに置き、中央サイトの Unified CM に登録して、リモート ロケーションにある Unified CME にフォールバックできます。WAN リンクがダウンし、電話機が SRST モードの Unified CME にフェールオーバーすると、Cisco Unity と Unity Connection のボイスメール ポートも SRST モードの Unified CME にフェールオーバーします。これにより、リモートサイトのユーザが、WAN の障害時に、MWI 機能も含めてボイスメールにアクセスできるようになります。

このシナリオには、次の各項目が必要です。

Cisco Unified CME 4.0 以降

Cisco Unity 4.0(5) 以降と TSP バージョン 8.1(3) 以降

Cisco Unity Connection 2. x 以降


) Unified CM から SRST モードの Unified CME へ、またはその逆方向にフェールオーバーが発生した場合、Cisco Unity または Unity Connection サーバから MWI を再同期する必要があります。


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

複数のメッセージング モデルを同じ配置で組み合わせることができます。ただし、その配置は、上記の項で示したすべてのガイドラインに従う必要があります。図 21-4 では、集中型メッセージングと分散型メッセージングの両方が同時に採用されるユーザ環境を示しています。

図 21-4 結合された配置モデル

 

図 21-4 では、2 つのメッセージング モデルの組み合わせを示しています。リージョン 1 と 3 は集中型メッセージングと集中型呼処理を使用し、リージョン 2 は分散型メッセージングと集中型呼処理を使用しています。すべてのリージョンが、リージョン内コールに G.711 を使用し、リージョン間コールに G.729 を使用するように設定されています。

図 21-4 では、中央サイトとサイト 3 の間で、集中型メッセージングと集中型コール シグナリングが使用されています。中央サイトのメッセージング システムは、中央サイトとサイト 3 の両方のクライアントにメッセージング サービスを提供します。サイト 2 は、集中型呼処理を使用する分散型メッセージング モデルを使用しています。サイト 2 に置かれているメッセージング システム(Unity2)は、サイト 2 の中にいるユーザだけにメッセージング サービスを提供します。この配置では、両方のモデルが、この章に記載されているそれぞれの設計上のガイドラインに従っています。トランスコーディング リソースは各メッセージング システム サイトに対してローカルに置かれ、サイト 2 のユーザが中央サイトのユーザにメッセージを残す場合のように、(メッセージング システムに対して)リモートのサイトからメッセージング サービスにアクセスするクライアントをサポートします。

また、SRST モードの Cisco Unified Communications Manager Express(Unified CME)は、IP 電話および Cisco Unity または Unity Connection ボイスメール ポートの両方の呼処理バックアップに使用されます。このフォールバック サポートは、リモート サイト(たとえば、図 21-4 のリージョン 2)に配置され、WAN 障害などのために電話機と Unified CM との接続が失われた場合に、バックアップの呼処理を提供します。またリモート サイトのユーザに対し、WAN 障害時に、ローカルの Cisco Unity または Unity Connection サーバへのアクセスと MWI のサポートを提供します。SRST モードの Unified CME の詳細については、 http://www.cisco.com で入手可能な製品マニュアルを参照してください。

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

ここでは、集中型メッセージングと、ローカル フェールオーバー機能を持つ WAN を介した Unified CM クラスタリングを一緒に配置する場合の Cisco Unity の設計上の問題について説明します。このモデルで WAN に障害が発生した場合は、WAN が復元されるまで、すべてのリモート メッセージング サイトがボイスメール機能を失います (図 21-5 を参照)。

WAN を介したクラスタリングは、ローカル フェールオーバーをサポートしています。ローカル フェールオーバーでは、各サイトが、物理的にそのサイトに置かれているバックアップ サブスクライバ サーバを持ちます。ここでは、Cisco Unity 集中型メッセージングと、WAN を介したクラスタリングのローカル フェールオーバーを一緒に配置する方法を中心に説明します。

詳細については、「IP WAN を介したクラスタリング」の項を参照してください。

図 21-5 Cisco Unity 集中型メッセージングと、ローカル フェールオーバー機能を持つ WAN を介したクラスタリング

 

クラスタリングされたサーバ間の最小帯域幅の要求については、「ローカル フェールオーバー配置モデル」の項を参照してください。

Unified CM による WAN 経由のクラスタリングでは、Cisco Unity と同様、最大 8 サイトがサポートされます。ボイスメール ポートは、Cisco Unity メッセージング システムが置かれているサイトだけに設定されます(図 21-5 を参照)。ボイスメール ポートは、WAN を介してリモート サイトに登録されません。他のサイトのメッセージング クライアントは、プライマリ サイトのすべてのボイスメール リソースにアクセスします。WAN に障害が発生すると、リモート サイトは集中型メッセージング システムにアクセスできなくなるため、WAN を介してリモート サイトに音声ポートを設定してもメリットがありません。ユニファイド メッセージングの場合、帯域幅を考慮して、ボイスメール ポートで TRaP を無効にし、すべてのメッセージング クライアントがそのローカル PC にボイスメール メッセージをダウンロードするようにする必要があります。

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

Cisco Unity メッセージング サーバも配置されたローカル フェールオーバー サイトでは、集中型メッセージング モデルと同様に、音声ポートがローカル Unified CM サブスクライバ サーバに登録されます。音声ポートの設定については、「Unified CM クラスタとの音声ポート統合」および 「専用 Unified CM バックアップ サーバを使用する音声ポート統合」を参照してください。

図 21-6 Cisco Unity 分散型メッセージングと、ローカル フェールオーバー機能を持つ WAN を介したクラスタリング

 

WAN を介したクラスタリングを含む単純分散型メッセージング実装では、クラスタ内の各サイトに、独自の Cisco Unity メッセージング サーバとメッセージング インフラストラクチャ コンポーネントが置かれます。すべてのサイトにローカル Cisco Unity メッセージング システムが置かれるわけではなく、一部のサイトで、ローカル メッセージング クライアントがリモート メッセージング サーバを使用する場合、その配置は分散型メッセージングと集中型メッセージングの組み合わせモデルとなります (「メッセージング配置モデルの組み合わせ」 を参照)。このモデルで WAN に障害が発生した場合は、WAN が復元されるまで、集中型メッセージングを使用するすべてのリモート サイトがボイスメール機能を失います。

ローカル メッセージング サーバを持たない各サイトは、そのすべてのメッセージング クライアントに対して単一のメッセージング サーバを使用する必要がありますが、そのようなサイトのすべてが同じメッセージング サーバを使用する必要はありません。たとえば、サイト 1 とサイト 2 のそれぞれがローカル メッセージング サーバを持っているとします。その場合、サイト 3 のすべてのクライアントがサイト 2 のメッセージング サーバを使用し(そのメッセージング サーバに登録し)、サイト 4 のすべてのクライアントがサイト 1 のメッセージング サーバを使用するようにできます。ローカル Cisco Unity メッセージング サーバを持つサイトには、トランスコーダ リソースが必要です。

他の分散型呼処理配置と同様に、これらのサイト間のコールはゲートキーパー コール アドミッション制御にとって透過的です。したがって、Unified CM でリージョンとロケーションを設定してコール アドミッション制御を提供する必要があります (「帯域幅の管理」 を参照)。

分散配置された Cisco Unity サーバは、デジタルでネットワーク接続することもできます。このトピックの詳細については、 http://www.cisco.com で入手可能な『 Cisco Unity Networking Guide 』を参照してください。配置される特定のメッセージング ストアに固有の Networking Guide が用意されています。

メッセージングの冗長性

ここでは、Cisco Unity と Cisco Unity Connection に関するメッセージングの冗長性について説明します。Cisco Unity Express は、メッセージングの冗長性をサポートしていません。

Cisco Unity

Cisco Unity は、2 種類の冗長性をサポートしています。1 つめは単純に Unity フェールオーバー(ローカル メッセージング フェールオーバー)と呼ばれ、システム障害のフェールオーバーが提供されます。2 つめは、スタンバイ冗長性と呼ばれ、地理的な複数の場所にわたるディザスタ リカバリ機能を提供します。Cisco Unity フェールオーバーとスタンバイ冗長性の比較については、『 Cisco Unity Design Guide 』を参照してください。

Cisco Unity フェールオーバーは、プライマリとセカンダリの 2 台のサーバがアクティブ/パッシブ冗長ペアとして設定されます。プライマリ サーバはアクティブの状態でコールを受け付け、セカンダリは非アクティブでコールを受け付けません。プライマリ サーバでサブスクライバや設定に関するデータを変更されると、その変更内容がセカンダリ サーバに自動的に複製されます。何らかの理由でプライマリ サーバが機能しなくなった場合、セカンダリ サーバが自動的にアクティブ サーバになりコールの受け付けを開始します。その間、プライマリ サーバは一時的に非アクティブになります。

図 21-7 に示しているように、ローカル メッセージング フェールオーバーを実装できます。ローカル フェールオーバーでは、プライマリ Cisco Unity サーバとセカンダリ Cisco Unity サーバの両方が、アベイラビリティの高い同じ LAN 上の同じサイトに置かれます。

図 21-7 Cisco Unity メッセージングのローカル フェールオーバー

 

Cisco Unity Standby Redundancy はまた、地理的な複数の場所にわたるディザスタ リカバリ機能も提供します。この場合もプライマリとセカンダリの 2 台のサーバを使用しますが、それらは通常、別の都市にある異なるデータセンターにインストールされます。プライマリ サーバがインストールされたデータセンターが自然災害やその他の大規模災害に遭遇した場合、ディザスタ リカバリ設備にいる(またはリモートでアクセスできる)誰かが、セカンダリ サーバを手動でアクティブ化すると、セカンダリ サーバがコールの受付を開始します。スタンバイ冗長性またはフェールオーバー(ローカル メッセージング フェールオーバー)の要件に関する詳細については、 http://www.cisco.com で入手できる適切なバージョンの『 System Requirements for Cisco Unity 』を参照してください。

Cisco Unity Connection

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

図 21-8 は、Cisco Unity Connection のアクティブ/アクティブ メッセージング冗長性を示します。

図 21-8 Cisco Unity Connection メッセージングの冗長性

 

Cisco Unity と Cisco Unity Connection の SIP トランクの実装には、いずれもメッセージング冗長機能のためのコール分岐(転送)が必要です。現在、Unified CM が SIP トランクのコールの分岐(転送)をサポートしていないため、Unified CM で SIP トランクが使用されている場合、Cisco Unity フェールオーバーは利用できません。ただし、アクティブ/アクティブ冗長性の Cisco Unity Connection サーバ ペアで SIP トランクを使用している場合は、2 つの異なる SIP トランクをサーバ ペアの各サーバに 1 つずつ設定し、それらを同じルート リストに関連付けられた同じルート グループに追加することを推奨します。このルート グループは、トップダウンの順で設定して、コールが最初にプライマリ Unity Connection サーバに送信され、次にセカンダリ Unity Connection サーバにオーバーフローされるようにする必要があります。

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

Cisco Unity ローカル フェールオーバーと WAN を介したクラスタリングを配置する場合は、「集中型メッセージングと WAN を介したクラスタリング」および 「分散型メッセージングと WAN を介したクラスタリング」で説明している設計プラクティスを適用します。正常な動作時、プライマリ Cisco Unity サーバからの音声ポートは WAN を通過しません。

図 21-9 では、Cisco Unity ローカル フェールオーバーを示しています。プライマリ Cisco Unity サーバとセカンダリ Cisco Unity サーバの両方が物理的に同じサイトに置かれていることに注意してください。Cisco Unity フェールオーバーは、Unified CM の WAN を介したクラスタリングで使用可能な最大数までリモート サイトをサポートします。

図 21-9 Cisco Unity ローカル フェールオーバーと WAN を介したクラスタリング

 

Cisco Unity フェールオーバーの設定については、 http://www.cisco.com で入手できる『 Cisco Unity Failover Configuration and Administration Guide 』を参照してください。

離れたデータセンターに配置された Cisco Unity のフェールオーバー

すでに述べたように、WAN 経由のハイ アベイラビリティを運用するために Cisco Unity フェールオーバーを設定できますが、この配置にはいくつかの要件があります。たとえば、地理的に離れた複数のデータセンターでの完全な冗長性が重要な場合、この設定でインストール操作を成功させるために、満たすべき特定の要件があります。図 21-10 に、地理的に離れたデータセンターにおける Cisco Unity のフェールオーバーを示します。

図 21-10 地理的に離れたデータセンターにおける Cisco Unity のフェールオーバー

 

図 21-10 に示す設定には、次の要件が適用されます。

プライマリとセカンダリの Cisco Unity サーバ間の最大 Round Trip Time(RTT; ラウンドトリップ時間)は 10 ms

最低 1 ギガビットの帯域幅

Cisco Unity サーバおよび各メッセージング サーバとの間の最大 RTT は 10 ms

Cisco Unity サーバおよびドメイン コントローラまたはグローバル カタログ サーバは同じ場所に設置

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

http://www.cisco.com/en/US/products/sw/voicesw/ps2237/prod_installation_guides_list.html

WAN 経由での Cisco Unity Connection の冗長性とクラスタリング

Cisco Unity Connection では、アクティブ/アクティブ型のクラスタリングを使用した冗長性がサポートされており、WAN 経由で配置できます。アクティブ/アクティブ設定、つまり「ハイ アベイラビリティ」設定では、ハイ アベイラビリティと冗長性の両方が提供されます。アクティブ/アクティブ ペアの両方のサーバでは Cisco Unity Connection アプリケーションが実行され、コールおよびクライアントからの HTTP 要求や IMAP 要求を受け付けます。クラスタの各サーバは、WAN 経由で異なるサイトに配置できます。その場合、以降に示す設計上の考慮事項に従う必要があります。図 21-11 に、地理的に離れたデータセンターにおける Cisco Unity Connection のアクティブ/アクティブ配置を示します。

図 21-11 2 つのサイト間でハイ アベイラビリティが確保された Cisco Unity Connection

 

異なるサイトに Cisco Unity Connection サーバを配置した場合には、次の要件が適用されます。

異なるサイトにあるアクティブ/アクティブ ペア間の最大 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 3000 および 5000 とともに使用することはできません。


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

Cisco Unity および Unity Connection は、複数の Unified CM クラスタによる集中型メッセージング設定に配置することもできます(図 21-12 を参照)。複数統合および複数の Unified CM クラスタに伴う MWI の考慮事項の詳細については、「テレフォニー統合」 の項を参照してください。

図 21-12 Cisco Unity または Unity Connection と複数の Unified CM クラスタの統合

 

図 21-12 の設定では、クラスタ 1 とクラスタ 2 の両方のサイトのメッセージング クライアントが、物理的にクラスタ 1 に置かれている Cisco Unity または Unity Connection メッセージング インフラストラクチャを使用します。

Cisco Unity Express の配置モデル

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

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 のサポートされているハードウェア プラットフォームおよび容量の詳細については、 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 でサポートされている配置モデルの詳細については、 http://www.cisco.com で入手可能な Cisco Unified Communications Manager Express の設計に関する資料を参照してください。

配置モデル

Cisco Unity Express は、単一のサイトとして配置することも、Cisco Unified Communications Manager(Unified CM)または Unified Communications Manager Express(Unified CME)の分散型ボイスメールおよび自動応答(AA)ソリューションとして配置することもできます。ただし、Cisco Unity Express は、次のようなすべての Cisco Unified CM 配置モデルでサポートされます。

単一サイト配置

集中型呼処理を使用するマルチサイト配置

分散型呼処理を使用するマルチサイト配置

図 21-13 は、Cisco Unity Express を統合した集中型呼処理配置を、図 21-14 は、分散型呼処理配置を示しています。

Unified CME によって制御される Cisco Unity Express サイト、および Unified CM によって制御されるその他のサイトは、H.323 または SIP トランキング プロトコルを使用して相互接続できます。Cisco Unity Express は Unified CM または Unified CME のいずれかと統合できますが、両方と同時に統合はできません。


) Cisco Unity Express は、最大 10 の Unified CME を持つ集中型配置モデルをサポートします。


図 21-13 集中型呼処理配置における Cisco Unity Express

 

図 21-14 分散型呼処理配置における Cisco Unity Express

 

Cisco Unity Express を使用した最も一般的な配置モデルは、集中型呼処理を使用したマルチサイト WAN モデルです。このモデルでは、Cisco Unity Express が、小規模なリモート オフィスでボイスメール機能を提供し、中央の Cisco Unity システムが本社および大規模なリモート サイトにボイスメール機能を提供します。

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 アプリケーションと Computer Telephony Integration(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 2.3 以降のリリースは、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 またはその他のボイスメール ソリューションを使用することを検討してください。

各 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 Expresses または Cisco Unity とネットワーク接続できます。これにより、Cisco Unity Express サブスクライバは、別のリモート Cisco Unity Express または Cisco Unity サブスクライバとの間で、メッセージの送受信や転送を行うことができます。

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 へのルーティングを行います。

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

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

 

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

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

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

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

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

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

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

図 21-16 Cisco Unity Express と SRST または SRST モードの Unified CME のルータの間で使用されるプロトコル

 

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

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

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

以前のリリースの Cisco Unity Express では、SRST モードでの MWI の変更はサポートされていませんが、通常動作でボイス メッセージを送信および検索できます。しかし、Unified CM に電話機を再登録するまで、電話機の MWI ランプはそのままです。その時点で、すべての MWI ランプの状態が、ユーザの Cisco Unity Express ボイスメール ボックスの現在の状態に自動的に再同期されます。Cisco Unity Express 3.0 以降のリリースでは、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、Cisco Unity Connection、および Cisco Unity Express を含むボイスメール ネットワーキングに関する留意点について説明します。また、Cisco Unified Messaging Gateway を使用したボイスメール ネットワーキングの概要についても説明します。Cisco Unity または Cisco Unity Connection のボイスメール ネットワーキングに固有の情報については、 http://www.cisco.com で入手可能な『 Design Guide for Cisco Unity 』または『 Design Guide for Cisco Unity Connection 』をそれぞれ参照してください。

ボイスメール ネットワーキングでは、Cisco Unity、Cisco Unity Connection、Cisco Unity Express などのシステム間で、組み込みの Simple Mail Transfer Protocol(SMTP; シンプル メール転送プロトコル)サーバおよび Voice Profile for Internet Mail(VPIM)バージョン 2 プロトコルのサブセットを使用して、ボイスメール メッセージの送受信、返信、転送を行えます。3 つのボイスメール メッセージング製品はすべて、VPIM メッセージングにより、製品間の相互運用性をサポートしています。

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

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

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

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

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

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

Cisco Unified Messaging Gateway によるボイスメール ネットワーキング

Cisco Unified Messaging Gateway は、Cisco Integrated Services Router(ISR)の Cisco ネットワーク モジュール上で実行される Linux ベースのソフトウェアです。Unified Messaging Gateway は、Cisco Unity、Cisco Unity Connection、Cisco Unity Express のハブとして動作して、VPIM v2 ボイスメール システムをハブアンドスポーク構造または階層構造でネットワーク化できます。このアプローチにより、ボイスメール システム間の VPIM 接続を劇的に削減し、各システムでの設定作業を簡素化できます。各ボイスメール システム(Cisco Unity、Cisco Unity Connection、Cisco Unity Express、または Avaya Interchange と Message Networking サーバ)は、それ自体と Cisco Unified Messaging Gateway との接続を設定するだけで十分です。これにより、Unified Messaging Gateway がシステム間のメッセージのルーティングと配信を処理します。中規模から大規模の分散した拠点を持つ企業が、Cisco Unified Communications ソリューションに移行するためには、このエンドツーエンドのメッセージ ネットワーキング機能が必要です。

Cisco Unified Messaging Gateway には、次の利点があります。

VPIM を使用した複数の自律的ボイスメール ネットワークで、インテリジェント ルーティングを可能にします。

スケーラブルなボイスメール ネットワークを提供し、VPIM ネットワークを介してサードパーティ製のボイスメール システム(Avaya Interchange など)との相互運用性を確保します。

ボイスメール VPIM ネットワークの追加や拡張が容易になります。

Cisco Unified Messaging は、最大で 1000 ノードと 50,000 サブスクライバをサポートできます。サブスクライバの数は、Unified Messaging Gateway に登録された 1 つの Cisco Unity Express が 50 人のサブスクライバをサポートすると想定して計算されています。Unified Messaging Gateway の容量は、サポートする最大ノード数と最大サブスクライバ数の両方に関係しており、一方が増加するともう一方が減少します。たとえば、ネットワーク上に多数のサブスクライバを持つ Cisco Unity や Avaya のエンドポイントがある場合、Unified Messaging Gateway に登録できるノードの数は非常に少なくなります。

Cisco Unified Messaging Gateway を配置する場合は、次のガイドラインに従ってください。

ネットワーク モジュールをより容量の大きいネットワーク モジュールにアップグレードすることはできないため、1 つのネットワーク モジュールの最大容量を超える可能性がある配置を行う場合には、ネットワークのアップグレードを事前に計画します。

Cisco Unity Express 3.1 以降のリリースは、Cisco Unified Messaging Gateway に自動的に登録し、ディレクトリの情報を交換しますが、Cisco Unity、Cisco Unity Connection、Avaya Interchange または Message Networking サーバは、Unified Messaging Gateway 上で手動でプロビジョニングする必要があります。

冗長性のために 2 つの Unified Messaging Gateway(プライマリとバックアップ)を配置します。

最大 10,000 ノードの大規模な配置の場合、最大 20 の Messaging Gateway(10 のプライマリと 10 のバックアップ)を配置します。


) Cisco Unified Messaging Gateway を使用したボイスメール ネットワーキングは、小規模企業向け Cisco Unified Communications 500 シリーズには該当しません。これは、Cisco Unified Communications 500 シリーズが、分散型環境でわずか 5 つのサイトしかサポートしないからです。



) Cisco Unified Messaging Gateway VPIM 機能は、販売終了(EoS)およびサポート終了日(EoL)に達しました。現時点では、VPIM 機能に代わるものはありません。詳細については、次の URL にある販売終了およびサポート終了日のお知らせを参照してください。
http://www.cisco.com/en/US/prod/collateral/voicesw/ps6789/ps5745/ps8605/end_of_life_notice_c51-695654.pdf


小規模企業向け Cisco Unified Communications 500 シリーズの配置に関する詳細については、 http://www.cisco.com で入手可能な製品マニュアルを参照してください。

分散型メッセージング ソリューションとしての VPIM の詳細、および Cisco Unified Messaging Gateway の設計上のガイドラインについては、 http://www.cisco.com で入手可能な製品マニュアルを参照してください。

ボイスメールの相互運用性

Cisco Unity および Cisco Unity Connection の両方において、優れたスケーラビリティ オプションと相互運用性サポートが提供されます。Cisco Unity(スタンドアロンまたはクラスタ)を使用した配置の多くは、次の機能を備えるように拡張または移行できます。

Cisco Unity と Cisco Unity Connection との相互運用性

Cisco Unity Connection と Cisco 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 Unity サーバまたはデジタル ネットワークと相互運用できます。

1 つの Cisco Unity Connection デジタル ネットワークは、1 つの Cisco Unity または Unity Connection デジタル ネットワークとだけ結合できます。

いずれの相互運用システムにおいても、最大ユーザ数または連絡先数は 100,000 です。この数に達した後は、削除および変更だけが可能です。

Cisco Business Edition 3000 および 5000 は、サポートされていません。

2 つの Cisco Unity Connection および Cisco Unity デジタル ネットワークからそれぞれ 1 台のサーバをブリッジヘッドまたはサイト ゲートウェイとして指定します。

サイト ゲートウェイとして指定された Cisco Unity Connection サーバのバージョンは 8.0 以上である必要があります。

Cisco Unity にデジタル的にネットワーク接続されるすべての Cisco Unity Connection サーバのバージョンは 8.0 以上である必要があります。

サイト ゲートウェイとして指定された Cisco Unity サーバのバージョンは 8.0 以上である必要があります。

Cisco Unity と Cisco Unity Connection の相互運用性

Cisco Unity と Cisco Unity Connection(デジタル ネットワーク)をデジタル的に結合して相互運用すると、ユーザはディレクトリを共有したり、簡単に管理を行ったり、その他の機能を使用したりできます。Cisco Unity と Cisco Unity Connection のネットワークを設計する場合には、次の考慮事項が適用されます。

Cisco Unity Connection ネットワークのすべてのノードのバージョンは 8.0 以上である必要があります。

バージョン 5.0 以上では、Cisco Unity デジタル ネットワークにサイト ゲートウェイ以外のサーバを配置できます。

Microsoft Exchange Server には、Interoperability Gateway for Microsoft Exchange をインストールする必要があります。

Microsoft Exchange Server は 2010、2007、2003、または Microsoft Business Productivity Online Services(BPOS)専用クラウド ソリューション(Cisco Unity Connection 8.6 以降のリリースのバックエンドの場合のみ Exchange 2010)にできます。Microsoft Exchange のバージョンの詳細については、次の URL で入手可能な Cisco Unity Connection に関する設計ガイドを参照してください。

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

IBM Domino はサポートされていません。

Cisco Unity Connection ネットワークには、最大で 10 のノードを配置できます。Cisco Unity Connection クラスタでは、パブリッシャ サーバだけがネットワークに参加するため、各サイトにおける 10 ノードの制限をカウントする場合、クラスタは 1 ノードとしてカウントされます。

Cisco Unity Connection と Cisco Unity Connection の相互運用性

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

デジタル ネットワーク システム内のいずれかの Cisco Unity Connection ノードで Cisco Unity Connection 7.0 が実行されている場合、サポートされる最大ユーザ数は 50,000 です。

IBM Domino はサポートされていません。

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

Cisco Unity と Unity Connection の仮想化

Cisco Unified Computing System(UCS)は、Total Cost of Ownership(TCO; 総所有コスト)を削減してビジネスの機動性を向上させることを目的として設計された統合システムに、コンピューティング、ネットワーキング、ストレージ アクセス、および仮想化を一体化した、次世代のデータセンター プラットフォームです。Cisco Unity と 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、および 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 の仮想化については、次の Web サイトで入手可能な最新バージョンの『 Design Guide for Cisco Unity Virtualization 』も参照してください。

http://www.cisco.com/en/US/products/sw/voicesw/ps2237/products_implementation_design_guides_list.html

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

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

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

この項の説明は、Cisco Unity と Unity Connection に適用されます。Cisco Unity Express については、「Cisco Unity Express の配置に関するベスト プラクティス」 を参照してください。

帯域幅の管理

Unified CM は、帯域幅を管理するためのさまざまな機能を備えています。リージョン、ロケーション、およびゲートキーパーさえも使用して、Unified CM は、WAN リンクを介して伝送される音声コールの数によって既存の帯域幅がオーバーサブスクリプションの状態になることがなく、音声品質が低下しないことを保証できます。Cisco Unity および Unity Connection は、帯域幅の管理とコールのルーティングを Unified CM に依存しています。コール(音声ポート)が WAN リンクを通過することのある環境に Cisco Unity または Unity Connection を配置する場合、このようなコールはゲートキーパーベースのコール アドミッション制御にとって透過的になります。このような状況は、Cisco Unity または Unity Connection サーバが分散クライアントにサービスを提供している場合(分散型メッセージングまたは分散型呼処理)、または Unified CM がリモートに置かれている場合(分散型メッセージングまたは集中型呼処理)、いつでも発生します。Unified CM は、コール アドミッション制御用のリージョンとロケーションを提供します。

図 21-17 では、集中型メッセージングと集中型呼処理を使用する小規模なサイトで、リージョンとロケーションを連携させて使用可能な帯域幅を管理する方法を示しています。リージョンとロケーションの詳細については、「コール アドミッション制御」(P.11-1)の章を参照してください。

図 21-17 ロケーションとリージョン

 

図 21-17 では、リージョン 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 と Unity Connection では、IP エンドポイントと Cisco Unity または Unity Connection サーバとの間でコールがネゴシエートされたコーデックと、録音または再生のコーデック形式が異なる場合、ネイティブ トランスコーディングが行われます。コールが G.729 でネゴシエートされ、システム全体の録音形式が G.711 で行われる場合、サーバはそのコールをネイティブにトランスコードする必要があります。Cisco Unity と Unity Connection のネイティブ トランスコーディングは、外部ハードウェア トランスコーダを使用せず、サーバのメイン CPU を使用します。ネイティブ トランスコーディングという名称はここから来ています。

Cisco Unity の動作

デフォルトで、Cisco Unity サーバは、Skinny Client Control Protocol(SCCP)や SIP 経由のテレフォニー統合で、G.711 と G.729 をサポートします。Cisco Unity ではまた、デフォルトのシステム全体のメッセージング録音形式が G.711 に設定されています。ネイティブ トランスコーディングを無効にするには、システムの録音形式と SCCP または SIP 統合コーデックのアドバタイズメントを同一に設定することを推奨します。たとえば、Unified CM の SCCP ポートまたは SIP トランクを使用して Cisco Unity を実装する場合、アドバタイズされるコーデックから G.729 を削除して、ポートまたはトランクが G.711 のみをアドバタイズするように設定できます。またデフォルトのシステム全体の録音形式を G.711 のままにすることにより、このシステムとネゴシエートされたすべてのコールが G.711 になり、録音もその形式で行われるため、メッセージング サーバ上でネイティブにトランスコードする必要がなくなります。

Cisco Unity でのネイティブ トランスコーディングの無効化

Cisco Unity での SCCP 統合の場合に限り、Unified CM がハードウェア トランスコーダを音声ポート コールに割り当てるようにするには、レジストリ設定によって、Cisco Unity サーバ上でネイティブ トランスコーディングを無効(オフ)にする必要があります。このレジストリ設定は Audio - Enable G.729a codec support と呼ばれます。これを設定するためのツールは、 http://www.CiscoUnityTools.com で入手可能な Advanced Settings Tool です (SIP で統合するときに Cisco Unity のネイティブ トランスコーディングを無効にする方法の詳細については、 http://www.cisco.com で入手可能な特定の Cisco Unity リリースの『 Cisco Unified Communications Manager SIP Trunk Integration Guide for Cisco Unity 』を参照してください。

デフォルトでは、コーデック レジストリ キーが存在しないため、ネイティブ トランスコーディングは有効(オン)です。Advanced Settings Tool により、使用可能な 2 つのコーデックのうちのどちらか 1 つを選択できる新しいレジストリ キーが追加されます。その後、Cisco Unity は、1 つのコーデックだけをサポートすることを Unified CM に「アドバタイズ」します。音声ポートを終端または起点とするコールが、Cisco Unity サーバに設定されているタイプと異なるコーデックを使用している場合、Unified CM はそのコールに外部トランスコーディング リソースを割り当てます。Unified CM 上でトランスコーディング リソースを設定する方法の詳細については、「メディア リソース」の章を参照してください。


) 現在、Unified CM 対応の Cisco Unity TAPI Service Provider(TSP)は、Skinny Client Control Protocol(SCCP)音声ポートに対して G.729 と G.711 mu-law だけをサポートしています(a-law はサポートされていません)。mu-law から a-law への変換には、Unified CM 自体やサービス統合型ルータ(ISR)など、ソフトウェアのメディア ターミネーション ポイント(MTP)が必要です。


Advanced Settings Tool を使用して 1 つのコーデックだけをアドバタイズする場合は、Cisco Unity サーバのシステム プロンプトが、使用されるコーデックと同じである必要があります。デフォルトでは、システム プロンプトは G.711 です。コーデックが G.711 に設定されている場合、システム プロンプトは正常に機能します。ただし、G.729 が選択されている場合は、システム プロンプトを変更する必要があります。システム プロンプトを変更する方法の詳細については、 http://www.cisco.com で入手可能な『 Cisco Unity System Administration Guide 』を参照してください。システム プロンプトが、レジストリで選択されているコーデックと同じでない場合は、エンド ユーザに、理解不能なシステム プロンプトが聞こえます。

Cisco Unity Connection の動作

Cisco Unity Connection は、Cisco Unity と異なる方法でトランスコーディング操作を処理します。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 がデフォルト)。したがって、Cisco Unity Connection では、トランスコーディングの全体的な影響が、Cisco Unity の場合と大きく異なります。この章ではこれ以降、発信側デバイスと 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 がライン上のデバイスで使用されている場合は、リニア Pulse Code Modulation(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 秒間の録音にどの程度のディスク容量が必要か。

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

表 21-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 が SIP または SCCP ポートでサポートするコーデックをアドバタイズする方法を変更するには、Cisco Unity とは異なる設定を行います。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 』をそれぞれ参照してください。

Unified CM との統合

Cisco Unified CM は、Cisco Unity と Unity Connection のどちらにも SCCP または SIP で統合できます。ここでは、電話機、SIP トランク、および音声ポートに関して、その統合の詳細を説明します。

テレフォニー統合

Cisco Unity は、複数の異なるテレフォニー統合をサポートするので、ユーザを特定のテレフォニー統合に関連付けることができます。Message Waiting Indication(MWI; メッセージ待機インジケータ)ポートも特定の統合に関連付けられるので、その特定の統合に関連付けられたポートを通じて MWI 要求が行われます。

Cisco Unity Connection でも、この機能はほぼ同じです。ユーザは、1 つ以上のポート グループを含む電話機システムに関連付けられます。ポート グループは、MWI ポートに関連付けられているので、MWI 要求は、その特定のポート グループに関連付けられたポートを通じて行われます。

Cisco Unity テレフォニー統合は、Cisco Unity Telephony Integration Manager(UTIM)によって設定し、Cisco Unity Connection の電話システムとポート グループは、System Administrator によって設定します。

Cisco Unity と Unity Connection がサポートできるテレフォニー統合の数が無制限になり、システムあたりのポート数によってのみ制限されるようになりました。この機能は、SCCP 統合と SIP 統合のいずれでも同じ方法で動作します。詳細については、 http://www.cisco.com で入手可能な該当する Cisco Unity または Cisco Unity Connection のアドミニストレーション ガイドを参照してください。

複数クラスタを接続するオプションとして、クラスタごとに Cisco Unity に統合を追加するという方法と別に、Unified CM は Annex M.1(Message Tunneling for QSIG のメッセージ トンネリング)をサポートしています。これにより、管理者は、Unified CM クラスタの間にあるクラスタ間トランク(ICT)で QSIG を有効にできます。ICT で QSIG を有効にすると、複数のクラスタがサポートされている場合でも、Cisco Unity は 1 つの Unified CM クラスタのみに統合され、この 1 つのクラスタでのみ、MWI をオン/オフするポートを指定する必要があります。Unified CM の Annex M.1 機能によって、MWI 要求をそれらの ICT 経由で伝搬し、適切な Unified CM クラスタとそのクラスタ内の電話機に伝達できます。他のクラスタから発信されたすべてのコールは、その 1 つのクラスタに統合された Cisco Unity サーバに転送できます。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 Unity Connection による E.164 番号サポート

Cisco Unity Connection 8.6 以降のリリースでは、次のフィールドに対してのみ E.164 番号形式をサポートします。

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

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

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

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

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

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

Cisco Unity Connection System の規制パターン

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

E.164 形式の番号と連動する代行内線番号ラーニング機能に関しては、次の規制テーブルを更新する必要があります。

User-Defined and Automatically-Added Alternate Extensions

Default Outdial

E.164 電話番号を使用する場合は、次の点にも考慮します。

エンド ユーザ アカウント(ボイスメール ボックスを使用するユーザ)の内線番号は、E.164 形式にできません。このフィールドで、「+」文字はサポートされません。

E.164 形式のプライマリ電話番号とともに LDAP からユーザをインポートする場合、サポートされる正規表現を使用してトランスレーション パターンを設定します。

電話番号の内線番号への変換については(Cisco Unity Connection 8.5 以降のリリースのみ)、次の Web サイトで入手可能な『 System Administration Guide for Cisco Unity Connection 』の最新バージョンを参照してください。

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

Cisco Unified Communications Manager(Unified CM)から、AXL 統合を経由して、E.164 形式の内線番号とともにユーザをインポートする場合、E.164 内線番号を Unified CM から、Comma-Separated Value(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 と Cisco Unity Connection の両方で動作し、Cisco Unified IP Phone 8900 および 9900 シリーズ SIP 電話機でサポートされています。

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

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


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


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

 

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

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

 

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

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

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

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

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

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

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

 

図 21-20 の Unified CM クラスタは、1 対 1 のサーバ冗長性および 50/50 のロード バランシングを採用しています。正常な動作時には、各サブスクライバ サーバがアクティブで、サーバの全呼処理負荷の最大 50% を処理します。1 台のサブスクライバ サーバに障害が発生すると、残りのサブスクライバ サーバが、障害の発生したサーバの負荷を担います。

この設定では、ボイスメール ポートのグループが 2 つ使用され、各グループに、ライセンスのある音声ポートの合計数の半分が含まれています。1 つのグループは、プライマリ サーバがサブ 1 で、セカンダリ(バックアップ)サーバがサブ 2 になるように設定されています。もう 1 つのグループは、サブ 2 がプライマリ サーバで、サブ 1 がバックアップになるように設定されています。

MWI 専用ポートや他の特殊なポートが、2 つのグループ間で等しく分散されていることを確認してください。音声ポートの設定中は、命名規則に特に注意してください。Cisco Unity Telephony Integration Manager(UTIM)ユーティリティでポートの 2 つのグループを設定する場合は、必ずデバイス名プレフィックスがグループごとに一意となるようにし、Unified CM Administration でボイスメール ポートを設定するときと同じデバイス名を使用します。この例では、デバイス名プレフィックスがポートのグループごとに一意になっています。グループ サブ 1 ではデバイス名プレフィックスとして CiscoUM1 が使用され、サブ 2 では CiscoUM2 が使用されています。

着信ボイスメール ポートと発信ボイスメール ポート(MWI、メッセージ通知、および TRaP 用)の比率に関する設計上の詳細情報については、 http://www.cisco.com で入手可能な『 Cisco Unity System Administration Guide 』を参照してください。


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


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

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

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

CiscoUM1-VI1

Unity1

デフォルト

Standard Profile

サブ 1 に登録

1.1.2.9

CiscoUM1-VI2

Unity1

デフォルト

Standard Profile

サブ 1 に登録

1.1.2.9

CiscoUM1-VI3

Unity1

デフォルト

Standard Profile

サブ 1 に登録

1.1.2.9

CiscoUM1-VI4

Unity1

デフォルト

Standard Profile

サブ 1 に登録

1.1.2.9

CiscoUM2-VI1

Unity1

デフォルト

Standard Profile

サブ 2 に登録

1.1.2.9

CiscoUM2-VI2

Unity1

デフォルト

Standard Profile

サブ 2 に登録

1.1.2.9

CiscoUM2-VI3

Unity1

デフォルト

Standard Profile

サブ 2 に登録

1.1.2.9

CiscoUM2-VI4

Unity1

デフォルト

Standard Profile

サブ 2 に登録

1.1.2.9


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


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

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

図 21-21 単一の Unified CM クラスタと統合された Cisco Unity サーバ(バックアップ サブスクライバ サーバを使用)

この場合のボイスメール ポートの設定は、50/50 のロード バランシング クラスタに似ています。ただし、もう 1 台のサブスクライバ サーバをセカンダリ サーバとして使用するように音声ポートを設定せず、個別の共有バックアップ サーバまたは専用バックアップ サーバを使用します。共有バックアップ サーバと共にクラスタリングされた Unified CM では、両方のサブスクライバ サーバのセカンダリ ポートが、単一のバックアップ サーバを使用するように設定されます。

音声ポート名(デバイス名プレフィックス)は、Cisco UTIM グループごとに一意で、Unified CM サーバ上で使用されるデバイス名と同じである必要があります。

Cisco Unity でボイスメール ポートを設定するには UTIM ツールを使用します。Cisco Unity Connection では、Unity Connection Administration コンソールの Telephony Integration セクションを使用します。詳細については、 http://www.cisco.com で入手可能な Cisco Unity または Cisco Unity Connection のアドミニストレーション ガイドを参照してください。

Cisco Unity Connection による IPv6 サポート

現行の IP アドレッシングに対する要件は、現行バージョンの IP アドレッシングである IPv4 で使用可能な IP アドレスのセットを上回っています。そのため、ほとんどの IP ベースのソリューションが、IPv4 より多くの IP アドレスが使用可能な IPv6 のサポートを取り込む方向に進んでいます。Cisco Unity Connection は、SCCP または SIP 経由の Cisco Unified Communications Manager システム統合を使用して IPv6 アドレッシングをサポートします。コンポーネント レベルでは、呼制御とメディア経由でのみ、デュアル スタック アドレッシング(IPv4 と IPv6 の両方)がサポートされます。


) ボイス メッセージは .wav ファイルとして保存されるため、IPv6 や IPv4 とは無関係です。


IPv6 サポートはデフォルトで無効になっていますが、システム管理者は Cisco Unified Operating System Administration とコマンドライン インターフェイス(CLI)のどちらかで IPv6 を有効にして、IPv6 アドレス設定値を構成できます。Cisco Unity Connection は、ルータ アドバタイズメントと DHCP のどちらかを経由して、または、Cisco Unified Operating System Administration と CLI のどちらかで手動で設定されたアドレスから、IPv6 アドレスを取得できます。

IPv4 と IPv6 の両方が実装されますが、同時に動作することはできません。Cisco Unity Connection は、「IPv6 のみ」のサーバ設定をサポートしていません。また、Cisco Unity Connection は、IPv6 専用のユニキャストをサポートしています。


) Cisco Unity Connection は、Cisco Business Edition 3000 および 5000 でのデュアル スタック アドレッシング モード(IPv4 と IPv6 の両方)をサポートしていません。


Cisco Unity Connection による単一受信トレイ

Cisco Unified Communications Manager 8.5 以降のリリースでは、Cisco Unity Connection および Microsoft Exchange 2003、2007、または 2010(クラスタ化または非クラスタ化)を使用した単一受信トレイ機能がサポートされているため、ボイスメールのユニファイド メッセージングが提供されます。Cisco Unity Connection は、この 3 つすべての Microsoft Exchange バージョンを同時にサポートすることも、いずれかを個別にサポートすることもできます。Cisco Unity Connection ViewMail for Microsoft Outlook から送られてくるものも含め、すべてのボイス メッセージが Cisco Unity Connection に保存されてから、すぐに受信者の 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 を配置する場合は、次のガイドラインとベスト プラクティスを使用してください。

ボイスメールの宛先として 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 の詳細については、 http://www.cisco.com で入手可能な製品マニュアルを参照してください。

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

この項では、サードパーティ製ボイスメール システムを Cisco Unified Communications とともに配置する場合のさまざまなオプションについて説明します。統合とメッセージングの両方について説明します。


) この項では、ポートやストレージに関するサードパーティ製ボイスメール システムのサイジング方法については説明しません。この情報については、ボイスメール ベンダーに連絡してください。ボイスメール ベンダーは、具体的なトラフィック パターンに基づいて、各ベンダーのシステムにおける個別の要件をより適切に判断できます。


統合

統合 は、ボイスメール システムとその関連する PBX または呼処理エージェントとの間の物理的な接続として定義されます。統合によって、これらの間にフィーチャ セットも提供されます。

ボイスメール ベンダーは数多くあり、Cisco Unified CM を配置する場合に既存のボイスメール システムを引き続き使用することも一般的です。この要件に留意し、シスコでは、Simplified Message Desk Interface(SMDI)という業界標準のボイスメール プロトコルをサポートしています。SMDI は、ボイスメール システムが適切にコールに応答するために必要なすべてのコール情報を提供するシリアル プロトコルであり、さまざまなベンダーの異なるシステム間でのボイスメール統合において配置される最も一般的な方式です。


) シスコでは、サードパーティ製ボイスメール システムのテストや認証は行っていません。通常、この業界では、さまざまな PBX システムに対して自社の製品をテストまたは認証することはボイスメール ベンダーの責任であるとされています。シスコでは、そのような機器とのシスコのインターフェイスをテストし、どのようなサードパーティ製ボイスメール システムが接続されるかにかかわらずこれらのインターフェイスをサポートします。


ボイスメール統合における SMDI の代替選択肢として、QSIG があります。QSIG を使用しても、一次群速度インターフェイス(PRI)T1/E1 トランク経由でサードパーティ製 PBX から Unified CM に接続できます。各方式にはそれぞれの利点と欠点があり、使用する方式はボイスメール システムと現在の PBX との統合方法に大きく依存します。

ボイスメール システムと Unified CM を接続する他の方式(PRI ISDN トランクと SMDI を組み合わせる方式など)もありますが、それらは一般的ではありません。

現在、ボイスメール統合に使用できる他の方法には、H.323 や SIP があります。ただし、ベンダーにおけるさまざまな実装方式、サポートされる機能、およびその他の要因によって、これらのサードパーティ製ボイスメール統合は、お客様が評価する必要があります。これらのオプションの詳細については、シスコのアカウント チームまたはシスコ代理店に連絡してください。

メッセージ

メッセージング は、ボイスメール システム間でのメッセージの交換として定義されます。メッセージングの目的で使用できるいくつかのオープンな標準があります。

異なるシステム間でのメッセージングを可能にするために配置される最も一般的なプロトコルは、Voice Profile for Internet Mail(VPIM)です。VPIM の仕様は何度か更新されており、最新ではないバージョン 2 が現在でも最も広く採用されているようです。VPIM よりも前から存在するメッセージング プロトコルに Audio Messaging Interchange Specification - Analog(AMIS-A)がありますが、ユーザ インターフェイスが使いにくく、アナログ テクノロジーが使用されており、機能も少ないことから、ほとんど使用されていません。