Cisco IP テレフォニー ソリューション リファレンス ネットワーク デザイン Cisco CallManager Release 4.0 および 4.1

Cisco Unity Express の配置モデル

Cisco Unity Express は、すべての Cisco CallManager 配置モデル（単一サイト配置、集中型コール処理を使用するマルチサイト WAN、分散型コール処理を使用するマルチサイト WAN など）でサポートされています。図12-1 では Cisco Unity Express を組み込んだ集中型コール処理配置を示し、図12-2 では分散型コール処理配置を示しています。

図12-1 集中型コール処理配置における Cisco Unity Express

図12-2 分散型コール処理配置における Cisco Unity Express

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

Cisco Unity Express は、Cisco CallManager Express とプラットフォームを共有する構成のボイスメール ソリューションとしても配置できます。Cisco CallManager Express によって制御される Cisco Unity Express サイト、および Cisco CallManager によって制御される他のサイトは、同じネットワークで相互接続できます。Cisco Unity Express は Cisco CallManager または Cisco CallManager Express と統合できますが、両方と同時に統合することはできません。

集中型または分散型 Cisco CallManager 配置の Cisco Unity Express に関する特性とガイドラインは、次のとおりです。

• 単一の Cisco Unity Express を単一の Cisco CallManager クラスタと統合できる。

• Cisco Unity Express は、JTAPI アプリケーションおよび Computer Telephony Integration（CTI; コンピュータ/テレフォニー インテグレーション）Quick Buffer Encoding（QBE）プロトコルを使用して、Cisco CallManager と統合する。CTI ポートおよび CTI ルート ポイントは、Cisco Unity Express のボイスメールおよび自動応答アプリケーションを制御します。

• Cisco Unity Express は、Skinny Client Control Protocol（SCCP）の Cisco IP Phone にボイスメール機能を提供する。将来のリリースでは、Session Initiation Protocol（SIP）IP Phone をサポートする予定です。

• Cisco CallManager では、Cisco Unity Express 用に次の CTI ルート ポイントが定義される。

–自動応答エントリ ポイント（Cisco Unity Express は最大 5 つの別個の AA を含むことができるため、最大 5 つの異なるルート ポイントが必要です）。

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

–Greeting Management System（GMS）パイロット番号（オプション。GMS を使用しない場合、このルート ポイントを定義する必要はありません）。

• Cisco CallManager では、Cisco Unity Express 用に次の CTI ポートが定義される。

–12 個または 25 個のメールボックスのシステム（4 つのポート）

–50 個のメールボックスの AIM-CUE システム（4 つのポート）

–50 個のメールボックスの NM-CUE システム（8 つのポート）

–100 個のメールボックスのシステム（8 つのポート）

• 各 Cisco Unity Express サイトは、100 個以下のメールボックスを持つ。100 個を超えるメールボックスを必要とする配置では、Cisco Unity または他のボイスメール ソリューションの使用を検討してください。

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

• Cisco Unity Express を使用して配置される任意のオフィスの自動応答機能は、そのオフィスに対してローカルにすることも（Cisco Unity Express で AA アプリケーションを使用）、中央集中型にすることも（ボイスメールだけに Cisco Unity Express を使用）できる。

• Cisco Unity Express Release 2.0 以降では、単一の Cisco Unity Express が他の Cisco Unity Express または Cisco Unity に限ってネットワーク接続できる。これにより、Cisco Unity Express 加入者が別のリモートの Cisco Unity Express 加入者または Cisco Unity 加入者にメッセージを転送または送信できます。

• Cisco Unity Express では、フェールオーバー用に最大 3 つの Cisco CallManager を指定できる。3 つすべての Cisco CallManager への IP 接続が失われた場合、Cisco Unity Express は Survivable Remote Site Telephony（SRST）コール制御に切り替えます。したがって、AA コール応答サービスおよび IP Phone からメールボックスへのアクセスの提供、および支店への外線からの着信呼もボイスメールにメッセージを残すことができます。

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

図12-3 では、Cisco CallManager と Cisco Unity Express 間のコール フローに関係するプロトコルを示しています。

図12-3 Cisco Unity Express と Cisco CallManager の間で使用されるプロトコル

図12-3 では、次のシグナリング フローおよびメディア フローを示しています。

• 電話機は、Cisco CallManager から SCCP を介して制御される。

• Cisco Unity Express は、Cisco CallManager から JTAPI（CTI-QBE）を介して制御される。

• 電話機の Message Waiting Indicator（MWI; メッセージ待機インジケータ）は、CTI-QBE を介して Cisco CallManager にメールボックスの内容の変更を伝える Cisco Unity Express によって変わり、さらにランプの状態を変えるよう電話機に MWI メッセージを送信する Cisco CallManager によって変わる。

• 音声ゲートウェイは、H.323 または MGCP を介して Cisco CallManager と通信する。

• Real-Time Transport Protocol（RTP）ストリーム フローは、エンドポイント間の音声トラフィックを伝送する。

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

図12-4 Cisco Unity Express と SRST ルータの間で使用されるプロトコル

図12-4 では、次のシグナリング フローおよびメディア フローを示しています。

• 電話機は、SRST ルータから SCCP を介して制御される。

• Cisco Unity Express は、内部 SIP インターフェイスを介して SRST ルータと通信する。

• 現在、SRST モードにおいて MWI の変更はサポートされていない。正常な動作時と同様に、音声メッセージを送信したり取り出したりできますが、電話機が Cisco CallManager に再び登録されるまで、電話機の MWI ランプの状態は変わらないままです。登録された時点で、すべての MWI ランプの状態が、ユーザの Cisco Unity Express ボイスメール ボックスの現在の状態と自動的に再同期されます。

• 音声ゲートウェイは、H.323 を介して SRST ルータと通信する。

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

Cisco Unity Express を配置するためのベスト プラクティス

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

• Cisco Unity Express をボイスメールの宛先とする IP Phone は、Cisco Unity Express をホスティングするルータと同じ LAN セグメント上に置く。Cisco Unity Express は、それ自身と同じ場所にない電話機にメールボックスを提供できません。

• Cisco Unity Express を使用して配置するサイトで、中断されない AA およびボイスメール アクセスが必要な場合は、Cisco Unity Express ブレード、SRST、および公衆網音声ゲートウェイ インターフェイスのすべてを同じ物理ルータに統合する。Hot Standby Router Protocol（HSRP; ホットスタンバイ ルータ プロトコル）または他の冗長ルータ構成は、現在 Cisco Unity Express でサポートされていません。

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

• 各 Cisco Unity Express サイトは、少なくとも 2 つの CTI ルート ポイントおよび 4 つの CTI ポートに関連付けられる必要がある。Cisco Unity Express を使用するサイトの数が、「コール処理」に記載されている CTI スケーラビリティのガイドラインを超えないようにします。

• Cisco Unity Express を、Cisco CallManager 上の JTAPI ユーザと関連付ける。1 人の JTAPI ユーザをシステム内の複数の Cisco Unity Expresse と関連付けることができますが、Cisco CallManager 上の各専用 JTAPI ユーザを単一の Cisco Unity Express に関連付けることをお勧めします。

• Cisco Unity Express へのコールは G.711 だけを使用する。ローカル トランスコーダを使用して、WAN を通過する G.729 コールを G.711 コールに変換することをお勧めします。リージョン内コールには G.711 音声コーデックを使用し、リージョン間コールには G.729 音声コーデックを使用するように Cisco CallManager リージョンを設定できます。

• Cisco Unity Express サイトでトランスコーディング ファシリティを使用できない場合は、WAN を介した G.711 ボイスメール コールの必要数に合せて十分な帯域幅をプロビジョニングする。IP Phone と Cisco Unity Express デバイス（CTI ポートおよび CTI ルート ポイント）の間のコールに G.711 音声コーデックを使用するように Cisco CallManager リージョンを設定します。

• CTI ポートおよび CTI ルート ポイントは、特定のロケーションに定義できる。Cisco CallManager と Cisco Unity Express の間ではロケーションベースのコール アドミッション制御を使用することをお勧めします。

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

• Cisco CallManager から Cisco Unity Express への CTI-QBE シグナリング パケットは、AF31 の DSCP 値（0x68）でマーキングされる。ただし、Cisco Unity Express から Cisco CallManager への CTI-QBE シグナリング パケットはマーキングされません。Access Control List（ACL; アクセス コントロール リスト）を使用してこのような CTI-QBE パケットをマーキングし、適切な QoS を確保することをお勧めします。例12-1 では、CTI-QBE シグナリング パケットに対して適切な QoS を実現するための設定例を示しています。Cisco CallManager は、CTI-QBE シグナリングに TCP ポート 2748 を使用します。

例12-1 CTI-QBE シグナリング パケット用の QoS 設定

SMDI

Cisco CallManager では、次のいずれかの方法で SMDI を使用できます。

• 「Cisco Messaging Interface」

• 「Cisco VG248」

Cisco Messaging Interface

Cisco Messaging Interface（CMI）は、パブリッシャ サーバ上だけで実行する必要のある Cisco CallManager サービスです。このサービスは、ボイスメール用のコールを代行受信して、適切な SMDI メッセージを生成します。その後、この SMDI メッセージはサーバの Component Object Model（COM; コンポーネント オブジェクト モデル）ポートの 1 つに送信されます。CMI は、アナログ FXS ポートまたは T1 CAS E&M をサポートするどの MGCP ゲートウェイにも対応しています。ただし、WS-X6624 モジュールは、確実な接続解除監視（「確実な接続解除監視」を参照）をサポートする 2 つしかないゲートウェイの 1 つであるため、現在 CMI と共に使用することが推奨される唯一のゲートウェイです。

図12-5 では、Cisco CallManager 内の CMI を介して SMDI を使用する方法を示しています。

図12-5 Cisco CallManager を介した SMDI

Cisco CallManager は、CMI を介して、事実上、アナログ FXS ポートを備えた SMDI を提供できるどのボイスメール システムとの統合もサポートしています。このボイスメール システムには、次のようなものがあります。

• Octel 100、200/300、および 250/350

• Intuity Audix

• Siemens PhoneMail

• Centigram/BayPoint（OnePoint Messenger および NuPoint Messenger）

• Lyrix ECS

• IBM Message Center

Cisco VG248

Cisco VG248 は SCCP ゲートウェイであり、48 個のアナログ FXS ポートをサポートし、ローカルで SMDI を生成します（つまり、CMI サービスとは関係なく動作します）。WS-X6624 モジュールと同様に、VG248 も確実な接続解除監視をサポートしています。

図12-6 では、VG248 によって SMDI を使用する方法を示しています。

図12-6 VG248 を介した SMDI

VG248 を介したボイスメール統合では、次の機能および利点が提供されます。

• Cisco CallManager ごとに複数の SMDI リンク

• SMDI フェールオーバー機能

• ボイスメール システムのロケーションからの独立性

VG248 は、ボイスメール統合に使用されることのある他の 2 つのシリアル プロトコルもサポートできます。そのプロトコルとは、NEC Message Center Interface（MCI）および Ericsson MD110 専用プロトコルです。

FXS ポートを使用する場合の考慮事項

ボイスメール システムにアナログ FXS ポートが装備されている場合は、次の Cisco ゲートウェイを使用してボイスメール システムと統合します。

• WS-X6624

Catalyst 6500 シャーシ内にこのモジュールに使用できるスロットがある場合は、このモジュールを使用します。

• VG248

シリアル ポートおよび音声ポートに完全なフェールオーバーが必要な場合、SMDI 以外のシリアル プロトコル（たとえば、NEC MCI や Ericsson MD110）が必要な場合、または Catalyst 6500 シャーシのスロットが使用できない場合は、このゲートウェイを使用します。

Digital Set Emulation

Digital Set Emulation（DSE）は、PBX をボイスメール システムに統合するもう 1 つの方法です。このモードでは、ボイスメール ポートが PBX にとって専用デジタル受話器のように見えます。この統合方法は、アナログ FXS ポートを備えた SMDI を使用する場合よりも次の点で優れています。

• 音声パスとコール情報のシグナリングの両方で、回線が完全にデジタルである。

• 音声とシグナリングの両方が同じ物理回線を介して転送されるため、アウトバンド シグナリングがない。

• 一般に、コールの全体的な品質が高い。

Digital PBX Adapter（DPA）

シスコは、特に、Digital Set Emulation を介して Cisco CallManager をサードパーティ製のボイスメール システムと統合するために、Digital PBX Adapter（DPA）を開発しました。DPA は、基本的に、一方の側で IP 接続を持ちながら、もう一方の側で複数のデジタル PBX 内線として機能します。DPA を使用すると、既存のボイスメール システムとそのインターフェイスを保持しながら、Cisco CallManager に接続できます。

これら 2 種類の DPA があります。

• Avaya Definity G3 7400 シリーズのデジタル電話セットをエミュレートするための DPA 7630

• Nortel Meridian 1 2616 デジタル電話セットをエミュレートするための DPA 7610

（注） DPA は、Lucent/Avaya または Nortel の Digital Set Emulation を使用する場合に限り、Octel Aria 250/350 または Serenade 200/300 のボイスメール システムと連携します。

図12-7 では、Octel ボイスメール システムを Cisco CallManager と統合している DPA を示しています。

図12-7 Octel ボイスメールを Cisco CallManager と統合している DPA

二重 PBX 統合

二重 PBX 統合は、既存のボイスメール サービスを保持しながら、現在の PBX から IP テレフォニーに移行する企業にとって便利なオプションです。

（注） このシナリオは複雑であるため、ほとんどのボイスメール ベンダーはこのシナリオをサポートしていませんが、必要に応じて「サイト固有に」サポートするベンダーもあります。このソリューションを実装するには、事前にボイスメール ベンダーに問い合せてください。

Cisco VG248 には、二重統合を提供できるようにする固有の多重化機能が備わっています。VG248 は、既存のシリアル リンクからの情報を独自のリンクと結合してから、単一のシリアル ストリームをボイスメール システムに提供できます（図12-8 を参照してください）。

図12-8 VG248 と SMDI を介した二重統合

VG248 は、SMDI 機能とアナログ FXS ポートを備えた任意のボイスメール システムと連携します。二重統合が必要である場合は、実装する前に次の前提条件が必要となります。

• 統一されたダイヤル プラン

• 転送および再接続のシーケンス

• PBX と Cisco CallManager の間の接続

図12-9 に示しているように、Cisco DPA にも Digital Set Emulation を介して二重統合を実現する機能が備わっています。

図12-9 DPA を介した二重統合

DPA は、Octel の Digital Set Emulation と連携します。二重統合が必要である場合は、実装する前に次の前提条件が必要となります。

• 統一されたダイヤル プラン

• 転送および再接続のシーケンス

• PBX と Cisco CallManager の間の接続

集中型ボイスメール

集中型ボイスメール配置では、複数の PBX が単一のボイスメール システムを共有します。この共有は、ボイスメール システムを 1 つの PBX だけに統合してから、PBX 間のプライベート ネットワーキング プロトコルを利用して、ボイスメール サービスをリモート加入者まで拡張することによって実現されます。ネットワーク接続された PBX は、ボイスメール システムにとって、1 つの大規模な PBX のように見え、そのように機能します。さまざまな PBX 製造業者が、大規模なネットワーク全体の加入者に対する機能透過性を実現しながらそのようなサービスの提供を可能にする専用プロトコル（たとえば、Avaya DCS、Nortel MCDN、Siemens CorNet、Alcatel ABC、NEC CCIS、Fujitsu FIPN）を開発しました。

集中型ボイスメール システムを使用するための主な動機付けは、既存のボイスメール システムから IP テレフォニー加入者にボイスメール サービスを提供することで、加入者が新しい Telephony User Interface（TUI; 電話ユーザ インターフェイス）を学習する必要がないようにするという目的から来ています。

一部のボイスメール システムは、Simple Messaging Desktop Interface（SMDI）などのプロトコルを介して複数の PBX をサポートできます（二重 PBX 統合）。Cisco Digital PBX Adapter（DPA）など、二重統合を可能にする他のソリューションも導入されています。状況によっては、ボイスメール ベンダーがこの構成をサポートしないと決めたため、このようなソリューションを実現できないことがあります。また、ボイスメール システムが、異なる PBX 統合を同時にサポートできないため、二重統合が単に技術的に不可能な場合もあります。そのような場合は、集中型ボイスメール配置が、二重統合に代わるソリューションを提供します（図12-10 を参照してください）。

図12-10 Cisco CallManager と QSIG による集中型ボイスメール

「集中型ボイスメール」という用語は、ボイスメール システム自体を意味しているのではないことに注意してください。集中型ボイスメールは、ボイスメール機能の提供に必要な、PBX の PBX 間ネットワーキング プロトコル（Avaya DCS、Nortel MCDN、Siemens CorNet などの専用プロトコル、または QSIG や DPNSS などの規格ベース プロトコル）の機能です。

集中型ボイスメールには、次の重要な用語および概念が適用されます。

• メッセージ センター Private Integrated Services Network Exchange（PINX）：これは、ボイスメール システムを「ホスティング」する PBX です（ボイスメール システムに直接接続されている PBX）。

• サブスクライバ PINX：これは、ボイスメール システムから「リモート」である PBX です（ボイスメール システムに直接接続されていない PBX）。

集中型ボイスメール構成では、QSIG などの適切な PBX 間ネットワーキング プロトコルが必要です。このプロトコルは、次のような最小限の機能サポートも提供する必要があります。

• Message Waiting Indicator（MWI; メッセージ待機インジケータ）

• 転送：正しい発信者 ID と着信者 ID がボイスメール システムに送信されることを保証するために必要です。

• 宛先変更：正しい発信者 ID と着信者 ID がボイスメール システムに送信されることを保証するために必要です。

ボイスメール システムがどのように使用されるかに応じて、他の機能が必要になる場合もあります。たとえば、ボイスメール システムが自動応答機能も提供する場合は、ヘアピンコールを防ぐために、パス置換機能が必要となります。

すべての PBX がメッセージ センター PINX として機能できるわけではありません。PBX がメッセージ センター PINX として機能できない場合は、ボイスメール システムを Cisco CallManager の方に移動して、Cisco CallManager をメッセージ センター PINX として機能させ、PBX をサブスクライバ PINX として機能させることを検討します（図12-11 を参照してください）。

図12-11 Cisco CallManager がメッセージ センター PINX として機能する集中型ボイスメール

サポート

シスコは、他のベンダーの製品が特定の方法で動作することを保証できません。また、他のベンダーの製品に対する設定変更またはアップグレードに関して、何が必要であるかを指示できません。各製品のサプライヤやベンダーに直接質問をしたり確認を求めたりするのは、お客様の責任です。

シスコは、お客様がサプライヤやベンダーに尋ねるべき質問を決める際に、お役に立つことができます。たとえば、「QSIG を介して接続されるリモート PBX ユーザが、メールボックスを持ち、かつすべてのボイスメール機能（MWI など）にフル アクセスできるようにするには、PBX に対して何を行う必要がありますか」などの質問です。

PBX の相互運用性を支援するために、シスコはさまざまな PBX を Cisco CallManager とテストし、これらのテストをアプリケーション ノートという形で文書化しています。これらの文書は、成功を保証するものではありませんが、サポートされている機能および Cisco CallManager と PBX の両方の設定詳細に関して、ある程度のガイダンスを提供します。主な PBX に関して Cisco CallManager のアプリケーション ノートがすでに記述されており、その中で Cisco CallManager がメッセージ センター PINX として機能する集中型ボイスメールのシナリオが扱われています。アプリケーション ノートは、次の Web サイトで入手できます。

http://www.cisco.com/go/interoperability

（注） シスコは、メッセージ センター PINX として機能する他のベンダーの PBX をテストすることはできません。シスコには、このようなシステムを構成するファシリティも専門知識もありません。したがって、お客様がこれらの情報をサプライヤやベンダーに直接要求する必要があります。

要約

• 集中型ボイスメールは、ボイスメール システム自体ではなく、PBX 間ネットワーキング プロトコルの機能である。

• すべての PBX がメッセージ センター PINX として機能できるわけではない。お客様が PBX のサプライヤやベンダーにこの機能を確認する必要があります。シスコは、PBX のこの機能を提供することもサポートすることもできません。

• Cisco CallManager はメッセージ センター PINX として機能できるため、PBX がこの機能を実行できない場合、お客様に代替を提供できる。

• パス置換が必要であるかを確認する必要がある。Cisco CallManager Release 4.1 以降は、この機能をサポートしています。

確実な接続解除監視

確実な接続解除監視は、遠端のデバイスがオンフックになったことを示すために PBX ポートからボイスメール システムに送信される信号です。この信号は、通常、約 600 ms のループ電流切断という形を取ることによって、ボイスメール システムにセッションを終了させます。

この信号がないと、ボイスメール システムは遠端のデバイスがオンフックになったことを認識せず、この状況で PBX が提供するどのような監視トーンでも録音し続けます（たとえば、ダイヤル トーンを再生する PBX も、ビジー トーンを再生する PBX もあります）。ボイスメール システムは、メッセージの最大時間に達するまで、このようなトーンを録音し続けます（たとえば、メールボックスでメッセージごとの制限が 3 分であり、発信者が 30 秒後に電話を切った場合、確実な接続解除監視がないと、ボイスメール システムはその後 2 分 30 秒間このようなトーンを録音し続けます）。この不必要な録音によって、加入者がいらいらすることがあります。また、ディスク使用率が上がり、ポート使用時間が増えるため、システムのパフォーマンスが低下することもあります。ボイスメール システムの中には、既知のトーンを監視して、その後削除することにより、このシナリオに対処できるものもありますが、その場合でもシステム パフォーマンスへの影響は避けられません。

加入者がメールボックスにコールしてメッセージがないか調べる場合にも、同様の問題が発生します。接続解除監視がない場合にユーザが単に電話を切ると、ボイスメール システムは、アクティビティ タイマーが期限切れになるまで、セッションを終了させずに有効な応答を待ち続けます。このシナリオの場合、主な影響は追加のポート使用時間が発生することからもたらされます。

これらの理由から、ボイスメール システムに接続されているアナログ ポートが、確実な接続解除監視を提供する必要があります。

サードパーティ製ボイスメール統合の要約

ボイスメール システムを Cisco CallManager に接続する方法は他にもありますが（SMDI と併用する Microsoft TAPI および PRI ISDN トランクなど）、これらの方法は一般的ではありません。サードパーティ製ボイスメール統合の大部分は、Cisco VG248 を使用します。これがお勧めのソリューションです。

Cisco CallManager をボイスメール システムに統合する方法は、ボイスメール システムが現在どのように PBX に統合されているかによって異なります。現在アナログ ポートが使用されている場合、Cisco VG248 は優れた統合方法を提供します。ただし、Avaya または Nortel の Digital Set Emulation が使用されている場合は、Cisco DPA を導入すると、現在のボイスメール システムをアナログ FXS ポート用に設計し直さずに統合を行うことができるため、低コストでソリューションを実現できます。

（注） シスコは、サードバーティ製のボイスメール システムのテストおよび認定を行いません。一般に、業界では、このような製品をさまざまな PBX システムに対してテストしたり認定したりするのは、ボイスメール ベンダーの責任であると考えられています。もちろん、シスコは、接続されるサードバーティ製のボイスメール システムに関係なく、PBX システムに対してシスコのインターフェイスをテストし、そのインターフェイスをサポートします。