単方向音声問題のトラブルシューティング

概要

このドキュメントでは、Ciscoゲートウェイに関連するIPテレフォニーの片通話で発生する可能性のある一般的な問題について説明します。 

前提条件

要件

次の項目に関する知識があることが推奨されます。

• 音声ネットワークの基本的な知識があること
• Cisco IOS^®ゲートウェイおよびルータ、Catalystスイッチ、DT-24+ゲートウェイ

使用するコンポーネント

このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

表記法

表記法の詳細については、『シスコ テクニカル ティップスの表記法』を参照してください。

問題

このドキュメントは、次のような問題に対応し、そのシナリオとソリューションを提供しています。

• IPステーションからCisco IOS音声ゲートウェイまたはルータを経由して電話コールが確立されると、通話者の一方のみが音声を受信します（単方向通信）。

• 2 つのシスコのゲートウェイ間でトール バイパス コールが確立されると、通話者のうち 1 人だけが音声を受信します（単方向通信）。

• VPN 3002 ハードウェア クライアントの背後にある IP ステーションからの通話が確立されると、通話者のうち 1 人だけが音声を受信します（単方向通信）。

解決方法

IP テレフォニーの片通話の原因はさまざまですが、根本的な問題は通常、IP ルーティングの問題に関係します。このセクションでは、この領域で既知のシナリオとソリューションをいくつか取り上げます。

Cisco IOS ゲートウェイおよびルータで IP ルーティングがイネーブルになっていることを確認する

VG200 など、一部の Cisco IOS ゲートウェイは、デフォルトで IP ルーティングがディセーブルになっています。このデフォルト設定により、単方向音声の問題が生じます。

IP ルーティングをイネーブルにするには、Cisco IOS ゲートウェイ上でこのグローバル コンフィギュレーション コマンドを発行します。

voice-ios-gwy(config)#ip routing

基本的な IP 到達可能性の確認

最初に必ず、基本的な IP 到達可能性を確認します。Real-Time Transport Protocol(RTP)ストリームはコネクションレス型（UDP経由で転送される）であるため、一方向のトラフィックは正常に転送されますが、反対方向のトラフィックは失われます。次の図に、これが発生するシナリオを示します。

サブネット A とサブネット B はどちらもサブネット X に到達可能です。サブネット X はサブネット A とサブネット B に到達可能です。このため、端末（A および B）と Cisco CallManager との間で TCP 接続を確立できます。したがって、シグナリングは問題なく両方の端末に到達でき、A と B 間のコールを確立できます。

コールが確立されたら、音声を伝送する RTP ストリームは、端末間を両方向に流れる必要があります。サブネット B はサブネット A に到達可能ですが、サブネット A はサブネット B に到達できない場合があります。このため、A から B への音声ストリームがいつも失われます。

これは、基本的なルーティングの問題です。ゲートウェイ B から電話機 A への ping を正常に実行できる状態にするには、IP ルーティングのトラブルシューティング方法を使用します。ping は双方向の IP 到達性の検証手段であることを覚えておいてください。

このドキュメントでは、IP ルーティングのトラブルシューティングについては説明していません。ただし、次の手順を実行する必要があります。

• デフォルト ゲートウェイを端末で設定している。

• このデフォルト ゲートウェイ上の IP ルートが宛先ネットワークに到達している。

このリストでは、各種 Cisco IP Phone 上でデフォルト ルータまたはゲートウェイの設定を確認する方法について説明します。

• Cisco IP Phone 7910：[Settings] を押してオプション 6 を選択し、[Default Router] フィールドが表示されるまで [volume down] を押します。

• Cisco IP Phone 7960/40：[Settings] を押してオプション 3 を選択し、[Default Router] フィールドが表示されるまで下にスクロールします。

• Cisco IP Phone 2sp+/30vip：**# を押して、gtwy= が表示されるまで # を押します。

正しいメディア ターミネーション ポイント設定の確認

Intercluster Trunk（ICT）用にトランスコーディングを設定する場合、Media Termination Point（MTP; メディア ターミネーション ポイント）が、トランクに関連付けられたメディア リソース グループおよびメディア リソース グループ リストに設定されていることを確認します。MTP が不要な場合に MTP を指定したり、必要であっても MTP の設定に失敗したりすると、ICT 設定のために単方向音声の問題を引き起こすことがわかっています。

Cisco IOS ゲートウェイおよびルータでの特定の IP アドレスへの H.323 シグナリングのバインド

Cisco IOSゲートウェイに複数のアクティブなIPインターフェイスがある場合、H.323シグナリングの一部は1つのIPアドレスから発信され、他の部分は別の送信元アドレスを参照できます。これにより、さまざまな問題が生じます。このような問題の 1 つに片通話の問題があります。

この問題を回避するために、H.323 シグナリングを特定の送信元アドレスにバインドできます。送信元アドレスは、物理インターフェイスまたは仮想インターフェイス（ループバック）のものを使用できます。インターフェイスコンフィギュレーションモードでh323-gateway voip bind srcaddr ip-addressコマンドを使用します。Cisco CallManager が参照先とする IP アドレスを持つインターフェイスでこのコマンドを設定します。

このコマンドは、Cisco IOS ソフトウェア リリース 12.1(2)T で導入されました。詳細については、『仮想インターフェイスの H.323 のサポート』を参照してください。

Cisco IOS ゲートウェイでの MGCP メディア パケット送信元インターフェイスへの MGCP シグナリングのバインド

シグナリングおよびメディア パケット用の送信元インターフェイスを指定しないと、Media Gateway Control Protocol（MGCP; メディア ゲートウェイ コントロール プロトコル）ゲートウェイで単方向音声が発生することがあります。mgcp bind media source-interface interface-idを発行すると、MGCPメディアを送信元インターフェイスにバインドできます コマンドを発行した後、mgcp bind control source-interface interface-id コマンドを使用して、アップグレードを実行します。コマンドを発行した後、Cisco CallManager で MGCP ゲートウェイをリセットします。

mgcp bind コマンドが有効になっていない場合でも、IP レイヤは最適なローカル アドレスを提供します。

mgcp bind コマンドのガイドラインは次のとおりです。

• ゲートウェイにアクティブな MGCP コールがある場合、制御およびメディアに対する mgcp bind コマンドは拒否されます。

• バインド インターフェイスがアップ状態ではない場合、コマンドを受け入れますが、インターフェイスがアップ状態になるまでは有効になりません。

• バインド インターフェイスで IP アドレスが割り当てられていない場合、mgcp bind コマンドを受け入れますが、コマンドが有効になるのは、有効な IP アドレスが割り当てられた後に限られます。この間、MGCP コールがアップ状態である場合は、mgcp bind コマンドは拒否されます。

• インターフェイスの手動シャットダウンまたは操作上の失敗が原因で、バインドされたインターフェイスがダウン状態になると、そのインターフェイスでのバインド動作はディセーブルになります。

• Media Gateway Controller（MGC; メディア ゲートウェイ コントローラ）でバインドが設定されていない場合、MGCP 制御およびメディアの送信元として使用される IP アドレスが、最適に使用可能な IP アドレスです。

Telco またはスイッチが応答監視を正しく送受信することを確認する

Telco またはスイッチに接続する Cisco IOS ゲートウェイがある場合、Telco またはスイッチの背後にある着信側デバイスがコールに応答するときに応答監視が正しく送信されることを確認します。応答監視の受信に失敗すると、Cisco IOS ゲートウェイが順方向の音声パスのカットスルー（オープン）に失敗します。この失敗により、単方向音声が発生します。回避策は、voice rtp send-recv on コマンドを発行することです。

詳細については、『Cisco IOS ゲートウェイおよびルータで voice rtp send-recv コマンドを使用した双方向音声の早期カットスルー』を参照してください。

Cisco IOS ゲートウェイおよびルータで voice rtp send-recv コマンドを使用した双方向音声の早期カットスルー

RTP ストリームの開始時、逆方向の音声パスが確立されます。Cisco IOS ゲートウェイがリモート エンドから Connect メッセージを受信するまで、順方向の音声パスはカットスルーされません。

場合によっては、RTP チャネルがオープンされたらすぐに双方向音声パスの確立が必要なことがあり、この場合は、Connect メッセージを受信する前になります。このためには、voice rtp send-recv グローバル コンフィギュレーション コマンドを発行します。

Cisco IOS ゲートウェイおよびルータでのリンクごとの cRTP 設定の確認

この問題は、複数のCisco IOSルータまたはゲートウェイが音声パスに含まれ、圧縮RTP(cRTP)が使用されるトールバイパスなどのシナリオに適用されます。cRTPまたはRTPヘッダー圧縮は、帯域幅を取り戻すためにVoIPパケットヘッダーを小さくする方法です。cRTPは、VoIPパケット上の40バイトのIPまたはRTPヘッダーを2 ～ 4バイトに圧縮します。この圧縮により、cRTP を使用する G.729 エンコードされたコールの場合、約 12 kbps の帯域幅が空きます。cRTP の詳細は、『VoIP：コール単位の帯域幅の使用量』を参照してください。

cRTP は、ホップごとに圧縮解除と再圧縮を行って、ホップ単位に実行されます。ルーティングするために、各パケット ヘッダーを調べる必要があります。したがって、cRTP は IP リンクの両側でイネーブルにする必要があります。

また、cRTP がリンクの両端で意図したとおりに動作していることを確認することも重要です。Cisco IOS ソフトウェア リリースのレベルによっては、スイッチング パスおよび cRTP の同時サポートの点が異なります。

要約すると、次のような経過をたどっています。

• Cisco IOS ソフトウェア リリース 12.0(5)T よりも前の Cisco IOS ソフトウェア リリースでは、cRTP はプロセス スイッチングされます。

• Cisco IOS ソフトウェア リリース 12.0(7)T および Cisco IOS ソフトウェア リリース 12.1(1)T では、cRTP のファースト スイッチングおよび Cisco Express Forwarding（CEF）スイッチングのサポートが導入されました。

• Cisco IOS ソフトウェア リリース 12.1(2)T で、アルゴリズムによってパフォーマンスが改善されました。

Cisco IOSソフトウェアプラットフォーム（Cisco IOSソフトウェアリリース12.1）でcRTPを実行する場合は、Cisco Bug ID CSCds08210がCisco IOSソフトウェアリリースに影響を与えないことを確認します。この不具合の症状は、RTP ヘッダー圧縮を使用して動作する VoIP および Fax Over IP が失敗します。

シスコの内部バグ情報およびツールにアクセスできるのは、登録ユーザのみです。

Cisco IOS ゲートウェイでのクロッキング設定の確認

E1 インターフェイスまたは T1 インターフェイス上で show controller {e1 | t1}コマンドを使用してクロッキングを送信している場合は、音声ゲートウェイのクロッキング設定に矛盾がある可能性があります。『Cisco IOSベースの音声対応プラットフォームでのクロッキング設定』を参照して、音声ゲートウェイのクロッキング設定が正しいことを確認してください。

Cisco IOS ゲートウェイおよびルータでの NAT のための最小ソフトウェア レベルの確認

Network Address Translation（NAT; ネットワーク アドレス変換）を使用する場合は、ソフトウェア レベルの最小要件を満たす必要があります。以前のバージョンの NAT では Skinny プロトコル変換がサポートされていません。このような以前のバージョンでは、単方向音声の問題が発生します。

NAT を使用して Skinny および H.323 バージョン 2 を同時にサポートするには、Cisco IOS ゲートウェイに Cisco IOS ソフトウェア リリース 12.1(5)T 以降を稼働させる必要があります。詳細については、『Cisco CallManager に接続する IP Phone における NAT のサポート』を参照してください。

PIX Firewall 上で NAT と Skinny を同時に使用するために必要な最小ソフトウェア レベルは 6.0 です。詳細については、『Cisco PIX Firewall バージョン 6.0』を参照してください。

AS5350 および AS5400 での voice-fastpath の無効化

Cisco IOS ソフトウェアのコマンド voice-fastpath enable は、AS5350 および AS5400 の隠しグローバル コンフィギュレーション コマンドです。このコマンドはデフォルトでイネーブルになっています。ディセーブルにするには、no voice-fastpath enable グローバル コンフィギュレーション コマンドを発行します。

コマンドがイネーブルになっている場合、特定のコールに対してオープンになっている論理チャネルの IP アドレスと UDP ポート番号の情報をキャッシュします。このコマンドにより、RTP ストリームがアプリケーション層に到達しないようになります。代わりに、パケットは下位の層で転送されます。これによって、コールの量が多いシナリオでは、CPU 使用率を多少減少させることができます。

保留や転送などの補足サービスを使用する場合は、voice-fastpath コマンドにより、ルータがキャッシュされた IP アドレスおよび UDP ポートに音声を流すようになります。保留中のコールが再開された後、または転送が完了した後に生成される新しい論理チャネル情報は無視されます。この問題を回避するには、トラフィックが絶えずアプリケーション層に到達する必要があります。この結果、論理チャネルの再定義がアカウントに取り込まれ、新しい IP アドレスと UDP ポートのペアに音声が流れるようになります。したがって、補足サービスをサポートするには、voice-fastpath をディセーブルにしてください。

SoftPhone での VPN IP アドレスの設定

Cisco IP SoftPhone を使用すると、PC を Cisco IP Phone 7900 シリーズの電話のように動作させることができます。Virtual Private Network（VPN; バーチャル プライベート ネットワーク）を経由して企業ネットワークに接続するリモート ユーザは、単方向音声の問題を回避するために追加の設定をいくつか行う必要があります。これは、メディア ストリームが接続のエンド ポイントを識別する必要があるためです。

このソリューションは、ネットワーク音声設定で、ネットワーク アダプタの IP アドレスではなく、VPN の IP アドレスを設定することです。詳細は、『VPN 経由での Cisco IP SoftPhone の使用方法』を参照してください。

Network Extension Mode で動作させる VPN 3002 の設定

Cisco VPN 3002 Hardware Clientは、クライアントモードとネットワーク拡張モード(NEM)の2つのモードで動作できます。クライアントモードでは、Cisco VPN 3002クライアントの背後にあるすべてのホストは、VPN 3002クライアントの外部IPアドレスに変換されたポートアドレスになります。H.323はポートアドレス変換(PAT)では動作せず、IP電話がVPN 3002クライアントの背後に配置されると片通話になります。VPN 3002 が NEM で動作する場合、リモート ネットワークは、NAT ベースや PAT ベースの IP アドレスではなく、実際の IP アドレスを使用して相互に認識し合います。VPN 3002 が NEM で動作するように設定されている場合は、H.323 は動作可能です。つまり、VPN 3002 クライアントの背後にある IP Phone は、VPN 3002 が NEM で動作する場合だけ動作可能です。このため、VPN 3002 クライアントでの単方向音声を回避するには、NEM を使用するように VPN 3002 クライアントを設定します。

NEM を使用するように Cisco VPN 3002 Hardware Client を設定するには、[Configuration] > [Quick] > [PAT] を選択し、[PAT] ウィンドウで [No, use Network Extension mode] をクリックします。

詳細は、『Network Extension Mode で EzVPN を使用した Cisco IOS ルータへの Cisco VPN 3002 Hardware Client の設定』を参照してください。

その他の情報：単方向音声の確認

パケット フローの確認に使用する便利な 2 つのコマンドに、debug cch323 rtp コマンドと debug voip rtp コマンドがあります。debug cch323 rtp コマンドは、ルータが送信（X）および受信（R）したパケットを表示します。大文字は、送信または受信の成功を示します。小文字はドロップされたパケットを示します。

voice-ios-gwy#debug cch323 rtp

RTP packet tracing is enabled
voice-ios-gwy#
voice-ios-gwy#
voice-ios-gwy#
voice-ios-gwy#
voice-ios-gwy#

!--- This is an unanswered outgoing call. !--- Notice that the voice path only cuts through in the forward direction and 
!--- that packets are dropped. Indeed, received packets are traffic from the !--- IP phone to the PSTN phone. These are dropped until the call is answered. 
Mar 3 23:46:23.690: ****** cut through in FORWARD direction *****
XXXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr
XrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr
XrXrXXrrrrrrrrrrrrrrrr
voice-ios-gwy#
voice-ios-gwy#

!--- This is an example of an answered call:

voice-ios-gwy#
voice-ios-gwy#
*Mar 3 23:53:26.570: ****** cut through in FORWARD direction *****
XXXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr
XrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXr
XXrrrrrXrXrXrXrXrXrXrXrXrXrXrXrrXXrrXrXrXrXrXrXXXXXXXXXXXXXXXXrXXXXXXXXrXrXrXXrrXr
XrXrXrXrXrXrXrXrXXrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr

!--- At this point, the remote end picks up the phone.

*Mar 3 23:53:30.378: ****** cut through in BOTH direction *****
XRXRXRXRXRXRXRXRXXRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXXRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRXRXRXRXRXR
XXRRXRXRXXRRXRXRXRXRXXRXRXRXRXRXRRXRXXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRRRRRRRRRRRRRRRRRRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXXRRRRRRRRRRRRRRRRRRRRRRRRRRRRXRXRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRRXXRXRXRXRXRXRRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXXRRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR
XXRRRRRRRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXR
XRXRXRXRXRXRXRXRXRXRXRXRXXRRRXR

!--- This is the end of the conversation.

voice-ios-gwy#debug voip rtp

--------cut through in BOTH direction-------------------

*Mar 27 19:52:08.259: RTP(32886): fs rx d=10.48.79.181(20002),
pt=0, ts=4FFBF0, ssrc=8E5FC294
*Mar 27 19:52:08.275: RTP(247): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00C8D9, ssrc=1F1E5093
*Mar 27 19:52:08.279: RTP(32887): fs rx d=10.48.79.181(20002),
pt=0, ts=4FFC90, ssrc=8E5FC294
*Mar 27 19:52:08.295: RTP(248): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00C979, ssrc=1F1E5093
*Mar 27 19:52:08.299: RTP(32888): fs rx d=10.48.79.181(20002),
pt=0, ts=4FFD30, ssrc=8E5FC294
*Mar 27 19:52:08.315: RTP(249): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00CA19, ssrc=1F1E5093
*Mar 27 19:52:08.319: RTP(32889): fs rx d=10.48.79.181(20002),
pt=0, ts=4FFDD0, ssrc=8E5FC294
*Mar 27 19:52:08.335: RTP(250): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00CAB9, ssrc=1F1E5093
*Mar 27 19:52:08.339: RTP(32890): fs rx d=10.48.79.181(20002),
pt=0, ts=4FFE70, ssrc=8E5FC294
*Mar 27 19:52:08.355: RTP(251): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00CB59, ssrc=1F1E5093
*Mar 27 19:52:08.359: RTP(32891): fs rx d=10.48.79.181(20002),
pt=0, ts=4FFF10, ssrc=8E5FC294
*Mar 27 19:52:08.375: RTP(252): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00CBF9, ssrc=1F1E5093
*Mar 27 19:52:08.379: RTP(32892): fs rx d=10.48.79.181(20002),
pt=0, ts=4FFFB0, ssrc=8E5FC294
*Mar 27 19:52:08.395: RTP(253): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00CC99, ssrc=1F1E5093
*Mar 27 19:52:08.399: RTP(32893): fs rx d=10.48.79.181(20002),
pt=0, ts=500050, ssrc=8E5FC294
*Mar 27 19:52:08.976: RTP(282): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00DEB9, ssrc=1F1E5093
*Mar 27 19:52:08.980: RTP(32922): fs rx d=10.48.79.181(20002),
pt=0, ts=501270, ssrc=8E5FC294
*Mar 27 19:52:08.996: RTP(283): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00DF59, ssrc=1F1E5093
*Mar 27 19:52:09.000: RTP(32923): fs rx d=10.48.79.181(20002),
pt=0, ts=501310, ssrc=8E5FC294
*Mar 27 19:52:09.016: RTP(284): fs tx d=10.48.79.181(20002),
pt=0, ts=5D00DFF9, ssrc=1F1E5093

PIX Firewall を介するコール トラフィック情報の収集

PIX Firewall を通過するコール トラフィック情報を集めることで、単方向コールのトラブルシューティングを行うことができます。PIX の capture コマンドを使用して、コール発生時にオープンして使用されたポートを確認できます。PIX Firewall を通過する VoIP トラフィックについては、『PIX ファイアウォールでの VoIP トラフィックの処理』を参照してください。

Cisco Unified Communications Manager の片通話の問題

この問題は、MTP が必要な発信初期 SIP コール セットアップでのみ発生します。この場合、発信SIP INVITEメッセージにSDPオファーを含めることができます。この問題は、次のシナリオで発生する可能性があります。

• SIP トランクで [Media Termination Point Required] がオンになっている発信 SIP トランク コール

• IPv6 専用エンドポイントと IPv4 専用エンドポイント間のコール

解決方法

MTPリソースが断続的にリークし、MTPリソースを必要とするSIPコールが失敗する可能性があります。RTMT から使用可能な MTP リソース数が 0 に達し、MTP が必要なコールごとに MTP 割り当て失敗回数が増加します。初期INVITEのSDP部分に誤ってa=inactiveが含まれている可能性があります。

この問題を解決するには、次の手順を実行します。

1. 可能な場合は、SIP トランク設定の [Media Termination Point Required] をオフにします。

2. アーリー オファーが必要な場合は、アーリー オファーを設定しますが、[Media Termination Point Required] はオフのままにします。

3. IPv6 導入では、IPv6 専用エンドポイント以外のデュアル スタックを使用します。

関連情報

• CallManager H.323：転送後または保留後の単方向音声の問題
• IP Phone から Cisco CallManager への NAT サポート
• 仮想インターフェイスの H.323 のサポート
• EzVPN 機能を備えた Cisco IOS ルータに接続する Cisco VPN 3002 ハードウェア クライアントの Network Extension モードでの設定
• Cisco CallManagerを使用したCisco Unity：片通話
• Cisco Unity 用二重 NIC の設定およびトラブルシューティング
• 音声に関する技術サポート
• 音声とユニファイド コミュニケーションに関する製品サポート
• Cisco IP Telephony のトラブルシューティング
• シスコテクニカルサポートおよびダウンロード