Cisco Collaboration 9.xソリューション リファレンス ネットワーク デザイン(SRND)
ゲートウェイ
ゲートウェイ
発行日;2013/10/03 | 英語版ドキュメント(2013/09/09 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 30MB) | フィードバック

目次

ゲートウェイ

この章の新規情報

Cisco ゲートウェイの概要

TDM ゲートウェイと IP トランキング ゲートウェイ

Cisco アナログ ゲートウェイ

Cisco デジタル トランク ゲートウェイ

Cisco TelePresence ISDN Link

ゲートウェイの選択

コア機能要件

呼制御用のゲートウェイ プロトコル

コア機能要件

DTMF リレー

付加サービス

UnifiedCM の冗長性

ビデオ テレフォニー用のゲートウェイ

専用ビデオ ゲートウェイ

統合ビデオ ゲートウェイ

UnifiedCM でのゲートウェイの設定

コール シグナリング タイマー

Cisco IOS 音声ゲートウェイのベアラ機能

ゲートウェイのベスト プラクティス

ゲートウェイ ゲイン設定の調整

PSTN からの着信コールのルーティング

PSTN への発信コールのルーティング

自動代替ルーティング(AAR)

最低料金選択機能

FAX とモデムのサポート

ゲートウェイ

ゲートウェイは、コラボレーション エンドポイントのネットワークを公衆電話交換網(PSTN)、従来型の PBX、または外部システムに接続するための複数の方法を提供します。音声およびビデオ ゲートウェイはエントリ レベルのスタンドアロン プラットフォームから、ハイエンドで機能が充実した統合ルータやシャーシ ベースのシステムまであります。

この章では、音声およびビデオ ネットワークに適切なプロトコルと機能サポートを提供するために Cisco ゲートウェイを選択する際に、考慮すべき重要な要素について説明します。この章は、次の項で構成されています。

「Cisco ゲートウェイの概要」

「ゲートウェイの選択」

「ビデオ テレフォニー用のゲートウェイ」

「ゲートウェイのベスト プラクティス」

「FAX とモデムのサポート」

この章の新規情報

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

 

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

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

ビデオ ゲートウェイに関する情報を追加

この章の各項で説明

2013 年 4 月 2 日

FAX とモデムのサポートに関する情報を削除

「FAX とモデムのサポート」

2013 年 4 月 2 日

Cisco Unified Videoconferencing 3500 ゲートウェイに関する情報を削除

この情報については、次の URL から入手可能な『 Cisco Unified Communications System 9.0 SRND 』の「 Gateways 」の章を参照してください。

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/9x/gateways.html

2013 年 4 月 2 日

Cisco Unified Communications システム Release 9.0 向けに変更なし

2012 年 6 月 28 日

Cisco ゲートウェイの概要

ここでは、次のタイプのゲートウェイの概要を示します。

「TDM ゲートウェイと IP トランキング ゲートウェイ」

「Cisco アナログ ゲートウェイ」

「Cisco デジタル トランク ゲートウェイ」

「Cisco TelePresence ISDN Link」

TDM ゲートウェイと IP トランキング ゲートウェイ

2006 年ごろまでは、企業内部の音声およびビデオネットワークを外部の音声サービスに接続するには、従来の PSTN に接続された TDM ゲートウェイを経由する以外に方法はありませんでした。シスコの製品ラインナップには、PSTN をはじめ、PBX や外部システムにもアナログおよびデジタル接続できる各種 TDM およびシリアル ゲートウェイが揃っています。TDM 接続では、低密度アナログ(FXS、FXO)、低密度デジタル(BRI)、高密度デジタル(T1、E1、T3)など、さまざまなインターフェイスを選択できます。

2006 年ごろから、一般に「SIP トランク サービス」と呼ばれる企業向けの新しい音声およびビデオ サービス オプションがサービス プロバイダーから提供されるようになりました。PSTN やその他の企業外部の宛先に SIP トランクを使用して接続するには、企業のネットワークのエッジで IP-to-IP 接続が必要です。この相互接続ポイントでは、これまで TDM またはシリアル ゲートウェイによって実現されていたものと同じ機能(境界の設定、コール アドミッション制御、QoS、トラブルシューティングの境界の確保、セキュリティのチェックなど)が引き続き必要となります。音声およびビデオ SIP トランキング接続では、企業とサービス プロバイダー ネットワーク間の相互接続ポイントにある Cisco Unified Border Element と Cisco Video Communication Server(VCS)がセッション ボーダー コントローラ(SBC)としてこれらの機能を実行します。

この章では、Cisco TDM ゲートウェイ プラットフォームの詳細について説明します。短い項でシスコのシリアル ゲートウェイについても説明します。Cisco Unified Border Element および Cisco Video Communication Server については、「Cisco Unified CM トランク」の章に詳細が記載されています。

Cisco ゲートウェイを使用すると、音声およびビデオ エンドポイントは非 IP および外部通信デバイスとの間で通信できるようになります。Cisco ゲートウェイには、アナログとデジタルの 2 種類があります。両方のタイプが音声コールをサポートしますが、デジタル ゲートウェイのみがビデオをサポートします。

Cisco アナログ ゲートウェイ

Cisco アナログ ゲートウェイには、ステーション ゲートウェイとトランク ゲートウェイがあります。

アナログ ステーション ゲートウェイ

アナログ ステーション ゲートウェイは、Unified CM を一般電話サービス(POTS)のアナログ電話機、IVR システム、FAX 機、およびボイスメール システムに接続します。ステーション ゲートウェイは、Foreign Exchange Station(FXS)ポートを備えています。

アナログ トランク ゲートウェイ

アナログ トランク ゲートウェイは、Unified CM を PSTN Central Office(CO; セントラル オフィス)または PBX トランクに接続します。アナログ トランク ゲートウェイは、PSTN、PBX、またはキー システムへのアクセス用の Foreign Exchange Office(FXO)ポート、および従来型の PBX とのアナログ トランク接続用の E&M(recEive and transMit、または ear and mouth)ポートを備えています。アナログ Direct Inward Dialing(DID; ダイヤルイン方式)および Centralized Automatic Message Accounting(CAMA)も、PSTN 接続に使用できます。

Cisco アナログ ゲートウェイは、次の製品およびシリーズで使用できます。

Cisco Voice Gateways VG204、VG224、および VG350

該当する PVDM およびサービス モジュールまたはカード付きの Cisco Integrated Services Routers Generation (ISR G2)1900、2900、および 3900 シリーズ

Cisco デジタル トランク ゲートウェイ

Cisco デジタル トランク ゲートウェイは、一次群速度インターフェイス(PRI)、基本速度インターフェイス(BRI)、シリアル インターフェイス(V.35、RS-449、および EIA-530)、または T1 個別線信号方式(CAS)などのデジタル トランクを経由して、Unified CM を PSTN または PBX に接続します。デジタル T1 PRI および BRI トランクは、ビデオおよび音声専用コールの両方に使用できます。

シスコのデジタル トランク ゲートウェイは、次の製品とシリーズで使用できます。

該当する PVDM およびサービス モジュールまたはカード付きの Cisco Integrated Services Routers Generation (ISR G2)1900、2900、および 3900 シリーズ

Cisco TelePresence ISDN GW 3241 および MSE 8321

Cisco TelePresence Serial GW 3340 および MSE 8330

Cisco TelePresence ISDN Link

Cisco TelePresence ISDN Link は、Cisco TelePresence EX、MX、SX、および C シリーズのエンドポイントをサポートする、室内 ISDN および外部ネットワーク接続性用のコンパクトなアプライアンスです。従来の音声およびビデオ ゲートウェイは多数のエンドポイントの PSTN と IP ネットワークの間の接続を提供する共有リソースですが、各 Cisco ISDN Link は単一の Cisco エンドポイントとペアになっています。詳細については、次の Web サイトで入手可能な Cisco TelePresence ISDN Link のマニュアルを参照してください。

http://www.cisco.com/en/US/products/ps12504/tsd_products_support_series_home.html

ゲートウェイの選択

音声およびビデオ ネットワーク用のゲートウェイを選択する場合は、次の点を考慮してください。

「コア機能要件」

「呼制御用のゲートウェイ プロトコル」

「コア機能要件」

コア機能要件

音声およびビデオ エンドポイントで使用するゲートウェイは、次のコア機能要件を満たす必要があります。

Dual Tone MultiFrequency(DTMF)リレー機能

付加サービス サポート

付加サービスは、保留、転送、および会議などの基本的なテレフォニー機能です。

FAX/モデム サポート

FAX over IP により、従来のアナログ FAX 機と IP テレフォニー ネットワークとの相互運用性が可能になります。FAX イメージは、アナログ信号から変換され、パケット ネットワークを介してデジタル データとして伝送されます。

冗長性のサポート

Cisco Unified Communications は、分散モデルに基づき、高いアベイラビリティを確保しています。Unified CM クラスタには、Unified CM の冗長性が用意されています。ゲートウェイは、プライマリ Unified CM に障害が発生した場合に、セカンダリ Unified CM への「re-home」機能をサポートする必要があります。一部のゲートウェイは Cisco VCS に登録されることがあります。この場合、ゲートウェイはプライマリ Cisco VCS に障害が発生した場合に、セカンダリへ「リホーム」する機能をサポートする必要があります。

企業での配置用に選択するゲートウェイがすべて、上記のコア要件を満たしていることを確認するには、ゲートウェイ製品の資料を参照してください。さらに、どのコラボレーションの実装についても、各サイト特有の機能要件(たとえば、アナログまたはデジタル アクセス、DID、およびキャパシティ要件)があります。

呼制御用のゲートウェイ プロトコル

Cisco Unified Communications Manager(Cisco Unified CM)は、ゲートウェイ用に次の IP プロトコルをサポートしています。

Session Initiation Protocol(SIP)

H.323

メディア ゲートウェイ コントロール プロトコル(MGCP)

Skinny Client Control Protocol(SCCP)

Cisco Video Communication Server(VCS)は、ゲートウェイに次の IP プロトコルをサポートしています。

Session Initiation Protocol(SIP)

H.323

SIP は、Cisco Collaboration ソリューション全体と新しい音声およびビデオ製品の方向性と一致しているため、コール シグナリング プロトコルとして推奨されます。ただし、プロトコルの選択は、サイト特有の要件と、現在の機器の設置ベースによって異なる場合があります。ゲートウェイ ハードウェアによって既存の配置が制限されたり、特定の機能用に別のシグナリング プロトコルが必要になったりすることがあります。

たとえば、Simplified Message Desk Interface(SMDI)は、ボイスメール システムを PBX または Centrex システムに統合するための標準です。SMDI を介してボイスメール システムに接続し、アナログ FXS またはデジタル T1 PRI を使用するには、SCCP または MGCP プロトコルが必要です。これは、H.323 または SIP デバイスは、ポートのグループから、使用される特定の回線を識別しないからです。この目的に H.323 または SIP ゲートウェイを使用すると、Cisco Message Interface は、着信コールに使用される実際のポートまたはチャネルと、SMDI 情報とを正常に関連付けることができません。

同様に、ネットワーク内の Cisco ビデオ ゲートウェイの配置は、既存の呼制御アーキテクチャによって異なります。Cisco ISDN およびシリアル ゲートウェイは両方とも、ビデオ コール用に最適化され、Cisco VCS を使用するように設計されました。図 5-1 に示されているように、H.323 を使用して Cisco VCS に登録するには、Cisco TelePresence Serial Gateway 8330 および 3340 プラットフォームを使用することをお勧めします。

図 5-1 Cisco VCS に登録されている Cisco TelePresence Serial Gateway

 

Cisco TelePresence ISDN Gateway 8321 および 3241 は、バージョン 2.2 以降から SIP をサポートしています。つまり、Cisco 8321 および 3241 ゲートウェイは H.323 を使用して VCS に登録したり(図 5-2 を参照)、SIP を使用して Unified CM に直接トランクしたり(図 5-3 を参照)することができます。

図 5-2 Cisco VCS に登録されている Cisco TelePresence ISDN Gateway

 

図 5-3 Cisco Unified CM に登録されている Cisco TelePresence ISDN Gateway

 

また、使用される Unified CM の配置モデルも、ゲートウェイ プロトコルの選択に影響を与える場合があります (「コラボレーションの配置モデル」の章を参照してください)。

コア機能要件

ここでは、各プロトコル(SCCP、H.323、MGCP、および SIP)が次のゲートウェイ機能要件をどのようにサポートするかについて説明します。

「DTMF リレー」

「付加サービス」

「Unified CM の冗長性」

DTMF リレー

DTMF は、信号に音声帯域内の特定の周波数ペアを使用するシグナリング方式です。64 kbps のパルス符号変調(PCM)音声チャネルは、これらの信号を容易に伝送できます。しかし、音声圧縮に低ビット レート コーデックを使用する場合、DTMF 信号の損失または歪みの可能性があります。IP インフラストラクチャを介して DTMF トーンを伝送するアウトバンド シグナリング方式は、コーデックにより誘発されるこれらの症状を簡単に解決します。

SCCP ゲートウェイ

Cisco VG248 は、伝送制御プロトコル(TCP)ポート 2002 を使用して、DTMF 信号をアウトオブバンドで伝送します。アウトオブバンド DTMF は、VG248 用のデフォルトのゲートウェイ コンフィギュレーション モードです。

H.323 ゲートウェイ

Cisco 3900 シリーズ製品などの H.323 ゲートウェイは、DTMF 信号をアウトオブバンドで交換するための拡張 H.245 機能を使用して、Unified CM と情報を交換できます。この機能は、3900 Series ゲートウェイのコマンドライン インターフェイスと、そのダイヤル ピアで使用可能な dtmf-relay コマンドを使用して有効に設定されます。

MGCP ゲートウェイ

Cisco IOS ベースのプラットフォームでは、Unified CM 通信に MGCP を使用できます。MGCP プロトコルには、 パッケージ の概念があります。MGCP ゲートウェイは、始動後、DTMF パッケージをロードします。MGCP ゲートウェイは、制御チャネルを介して、受信した DTMF トーンを表す シンボル を送信します。次に、Unified CM は、これらの信号を解釈し、アウトオブバンドでシグナリング エンドポイントに DTMF 信号を渡します。


) RFC 2833 を通じて DTMF を有効にするには、fm-package コマンドを使用します。このコマンドは、Cisco IOS Release 12.4(6)T 以降で使用できます。


SIP ゲートウェイ

Cisco IOS および ISDN ゲートウェイでは、Unified CM 通信に SIP を使用できます。これらのプラットフォームはさまざまな方式の DTMF をサポートしていますが、Unified CM との通信に使用できるのは次の方式だけです。

Named Telephony Events(NTE)、または RFC 2833

Unsolicited SIP Notify(UN)(Cisco IOS ゲートウェイのみ)

Key Press Markup Language(KPML)

DTMF に使用される方法は、ゲートウェイ CLI コマンド dtmf-relay をそれぞれの dial-peer の下で使用することで設定できます。

DTMF 方式の選択の詳細については、「SIP トランク上の DTMF リレー」の項を参照してください。

付加サービス

付加サービスは、保留、転送、および会議などのユーザ機能を提供します。これらは、基本的なテレフォニー機能と見なされ、ビデオ コールよりも音声コールのほうでよく使用されます。

SCCP ゲートウェイ

Cisco SCCP ゲートウェイは、完全な付加サービス サポートを提供します。SCCP ゲートウェイは、ゲートウェイと Unified CM 間のシグナリング チャネル、および SCCP を使用して、呼制御パラメータを交換します。

H.323 ゲートウェイ

H.323v2 は、Open/Close LogicalChannel 機能と emptyCapabilitySet 機能を実行します。H.323 ゲートウェイによる H.323v2 の使用により、付加サービスを提供する際に MTP が必須ではなくなりました。トランスコーダは、WAN 全体で G.729 ストリームを維持しつつ、G.711 のみのデバイスへのアクセスを提供するコール中に必要な場合にのみ、動的に割り当てられます。

H.323v2 コールが Cisco IOS ゲートウェイと IP エンドポイントの間に Unified CM を H.323 プロキシとして使用してセットアップされると、エンドポイントはベアラ接続を変更する要求を行えます。Real-Time Transport Protocol(RTP)ストリームは、Cisco IOS ゲートウェイからエンドポイントに直接接続されるため、サポートされるメディア コーデックをネゴシエートできます。

図 5-4 と次の手順では、2 台の IP Phone 間のコール転送を示しています。

1. 電話機 1 が Cisco IOS ゲートウェイから電話機 2 にコールを転送しようとする場合、電話機 1 は、SCCP を使用して Unified CM に転送要求を出します。

2. Unified CM は、この要求を H.323v2 CloseLogicalChannel 要求に変換して、Cisco IOS ゲートウェイに送信して、適切な SessionID を求めます。

3. Cisco IOS ゲートウェイは、電話機 1 との RTP チャネルをクローズします。

4. Unified CM は、SCCP を使用して、Cisco IOS ゲートウェイとの RTP 接続をセットアップする要求を、電話機 2 に出します。同時に、Unified CM は、新しい宛先パラメータを指定して(ただし、同じ SessionID を使用)、Cisco IOS ゲートウェイに OpenLogicalChannel 要求を出します。

5. Cisco IOS ゲートウェイがこの要求を確認した後、RTP 音声ベアラ チャネルが、電話機 2 と Cisco IOS ゲートウェイとの間で確立されます。

図 5-4 H.323 ゲートウェイの付加サービス サポート

 

MGCP ゲートウェイ

MGCP ゲートウェイは、MGCP プロトコルを使用して、保留、転送、および会議機能を完全にサポートします。MGCP プロトコルは、すべてのセッション機能を制御する、Unified CM とのマスター/スレーブ プロトコルであるので、Unified CM は、MGCP ゲートウェイの音声接続を容易に操作できます。IP テレフォニー エンドポイント(たとえば、IP Phone)が、セッションの変更(たとえば、コールを別のエンドポイントに転送する)を必要とする場合、そのエンドポイントは、セッションの変更を SCCP を使用して Unified CM に通知します。次に、Unified CM は、Session ID に関連した現在の RTP ストリームを終了し、新しいエンドポイント情報を使用して新しいメディア セッションを開始することを、MGCP ユーザ データグラム プロトコル(UDP)制御接続を使用して、MGCP ゲートウェイに通知します。図 5-5 では、プロトコルが MGCP ゲートウェイ、エンドポイント、および Unified CM 間で交換される様子を示しています。

図 5-5 MGCP ゲートウェイの付加サービス サポート

 

SIP ゲートウェイ

Cisco SIP ゲートウェイへの Unified CM SIP トランク インターフェイスは、保留、ブラインド転送、在席転送などの付加サービスをサポートしています。付加サービスのサポートは、INVITE や REFER などの SIP 方式によって実現されます。付加サービスを機能させるには、対応する SIP ゲートウェイによってこれらの方法がサポートされている必要もあります。詳細については、次のマニュアルを参照してください。

『Cisco Unified Communications Manager System Guide』

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

『Cisco IOS SIP Configuration Guide』

http://www.cisco.com/en/US/docs/ios/voice/sip/configuration/guide/12_4t/sip_12_4t_book.html

Cisco TelePresence ISDN Gateway のマニュアル

http://www.cisco.com/en/US/products/ps11448/tsd_products_support_series_home.html

Unified CM の冗長性

コラボレーション ソリューション アーキテクチャに不可欠なことは、高価な専有の従来型の PBX システムの代わりに、低コストの分散型 PC ベース システムを提供することです。この分散型設計は、クラスタ化された Unified CM の堅固なフォールト トレラント アーキテクチャに適しています。最も単純な形式(2 システムのクラスタ)であっても、セカンダリ Unified CM は、最初にプライマリ Unified CM によって管理されていたすべてのゲートウェイの制御を引き受ける必要があります。

SCCP ゲートウェイ

ブート後、Cisco VG224、VG248、および ATA 188 ゲートウェイには、Unified CM サーバ情報が提供されます。これらのゲートウェイが初期設定されるときに、Unified CM のリストがゲートウェイにダウンロードされます。このリストでは、プライマリ Unified CM とセカンダリ Unified CM に優先順位が付けられています。プライマリ Unified CM が通信不能になった場合、ゲートウェイはセカンダリ Unified CM に登録されます。

WAN リンク障害用の H.323 VoIP コール プリザベーション

WAN リンク障害用の H.323 コール プリザベーション拡張機能を使用すると、対向のエンドポイントとは異なるエンティティ(シグナリングをルーティングするゲートキーパーや、接続している 2 者間でシグナリングを仲介するコール エージェント(Cisco Unified CM など)など)によってシグナリングが処理される H.323 トポロジにおいて、接続性が維持されます。コール プリザベーションが役立つのは、ゲートウェイと他のエンドポイントは同じサイトにあるものの、コール エージェントがリモート サイトにあり、接続障害が起こりやすいような場合です。

H.323 コール プリザベーションは、次の種類の障害と接続に対応します。

障害の種類:

WAN リンクのフラッピングや性能低下などの WAN 障害

Cisco Unified CM ソフトウェアの障害(Unified CM サーバでの ccm.exe サービスのクラッシュなど)

LAN 接続の障害(障害がローカル ブランチで発生した場合を除く)

接続の種類:

Cisco Unified CM で制御された 2 つのエンドポイント間のコールで、次の条件に該当する場合

Unified CM がリロード中の場合

一方または両方のエンドポイントと Unified CM との間で H.225.0 または H.245 メッセージのシグナリングに使用される伝送制御プロトコル(TCP)接続が失われたか、フラッピングしている場合

エンドポイントがクラスタ内の異なる Unified CM に登録されていて、その 2 つの Unified CM 間の TCP 接続が失われた場合

同一サイトにある IP Phone と PSTN の間

Cisco IOS ゲートウェイとソフトスイッチによって制御されているエンドポイントの間のコールで、シグナリング(H.225.0、H.245、またはその両方)フローはゲートウェイとソフトスイッチ間で実行され、メディア フローはゲートウェイとエンドポイント間で実行される場合

ソフトスイッチがリロード中の場合

ゲートウェイとソフトスイッチ間の H.225.0 または H.245 TCP 接続が失われ、ソフトスイッチがエンドポイント上のコールをクリアしない場合

ソフトスイッチとエンドポイント間の H.225.0 または H.245 TCP 接続が失われ、ソフトスイッチがゲートウェイ上のコールをクリアしない場合

メディア フローアラウンド モードで動作している Cisco Unified Border Element がコール フローに含まれていて、その Cisco Unified Border Element がリロードしているか、ネットワークの残りの部分との接続を失った場合

メディアが保持された後、一方の通話者が電話を切るか、メディアがアクティブでないことが検出されると、コールは終了します。コンピュータによって生成されたメディア ストリーム(メディア サーバからの音楽ストリーミングなど)が存在する場合は、メディア非アクティビティ検出が機能せず、コールが終了しない可能性があります。Cisco Unified CM はこの状況に対処するため、このようなコールは保持しないようにゲートウェイに指示しますが、サードパーティ製デバイスや Cisco Unified Border Element はそうしたことは行いません。

この機能において、フラッピングは「IP 接続の一時的な喪失が何度も繰り返されること」と定義されています。このような現象は、WAN または LAN の障害によって発生する可能性があります。Cisco IOS ゲートウェイと Cisco Unified CM 間の H.323 コールは、フラッピングが起こると終了する場合があります。Unified CM は、TCP 接続が失われたことを検出すると、コールをクリアし、TCP FIN を送信してコールで使用されていた TCP ソケットを閉じます。このとき、H.225.0 Release Complete メッセージまたは H.245 End Session メッセージは送信しません。これを quiet clearing と呼びます。ネットワークが短時間で復帰した場合、Unified CM から送信された TCP FIN がゲートウェイに到達してしまう可能性があり、その場合ゲートウェイはコールを終了します。TCP FIN がゲートウェイに到達しなくても、ネットワークが復帰すると、ゲートウェイから送信された TCP キープアライブが Unified CM に到達する可能性があります。Unified CM はすでに TCP 接続を閉じているので、キープアライブに応答して TCP RST メッセージを送信します。ゲートウェイは RST メッセージを受け取ると、H.323 コールを終了します。

WAN リンク障害用の H.323 コール プリザベーション拡張機能の設定には、 call preserve コマンドの設定を含める必要があります。Cisco Unified CM を使用している場合は、Service Parameters ウィンドウから Allow Peer to Preserve H.323 Calls パラメータを有効にする必要があります。

call preserve コマンドを発行すると、H.225.0 または H.245 接続でのアクティブ コールに関するソケットの終了またはソケット エラーがゲートウェイで無視されるため、これらの接続を使用しているコールを終了せずにソケットを閉じることができます。

MGCP ゲートウェイ

MGCP ゲートウェイにも、プライマリ Unified CM との通信が失われた場合に、セカンダリ Unified CM にフェールオーバーする機能があります。フェールオーバーが起きても、アクティブ コールは保持されます。

MGCP ゲートウェイのコンフィギュレーション ファイル内で、プライマリ Unified CM は、 call-agent <hostname> コマンドを使用して指定され、セカンダリ Unified CM のリストは、 ccm-manager redundant-host コマンドを使用して追加されます。プライマリ Unified CM とのキープアライブは、MGCP アプリケーション レベルのキープアライブ メカニズムを介して行われます。このメカニズムでは、MGCP ゲートウェイは、空の MGCP notify(NTFY)メッセージを Unified CM に送信し、確認応答を待ちます。バックアップ Unified CM とのキープアライブは、TCP キープアライブ メカニズムを介して行われます。

プライマリ Unified CM が後で使用可能になると、MGCP ゲートウェイは、元の Unified CM に「re-home」(つまり復帰)できます。この復帰は、ただちに行われることもあれば、設定可能な時間が経過した後、または接続されているすべてのセッションが解除された後に行われることもあります。

SIP ゲートウェイ

Cisco IOS SIP ゲートウェイでの冗長性は、H.323 と同様の方法で実現できます。SIP ゲートウェイがプライマリ Unified CM との接続を確立できない場合、高い優先順位を持ち、別の dial-peer ステートメントで指定されるセカンダリ Unified CM との接続を試行します。

デフォルトでは、Cisco IOS SIP ゲートウェイは dial-peer で設定された Unified CM の IP アドレスに SIP INVITE 要求を 6 回送信します。SIP ゲートウェイは、その Unified CM から応答を受信しなかった場合、他の dial-peer で設定された、優先順位の高い Unified CM との接続を試行します。

Cisco IOS SIP ゲートウェイは、INVITE に対する SIP 100 応答を 500 ms 待ちます。デフォルトでは、Cisco IOS SIP ゲートウェイがバックアップ Unified CM に到達するまでに最大 3 秒かかります。SIP INVITE の再試行回数は、 sip-ua 設定で retry invite <number> コマンドを使用して変更できます。また、Cisco IOS SIP ゲートウェイが SIP INVITE 要求に対する SIP 100 応答を待つ期間は、 sip-ua 設定で timers trying < time > コマンドを使用して変更できます。

バックアップ Unified CM へのフェールオーバーを高速化する別の方法としては、 dial-peer 文での monitor probe icmp-ping コマンドの設定があります。Unified CM がインターネット制御メッセージ プロトコル(ICMP)エコー メッセージ(ping)に応答しなかった場合、そのダイヤル ピアはシャットダウンされます。このコマンドが役に立つのは、Unified CM が到達不能のときだけです。ICMP エコーメッセージは、10 秒ごとに送信されます。

Unified CM リリース 9.0 および ISDN Gateway リリース 2.2 以降から、Cisco ISDN Gateway は Unified CM に SIP トランクを介して接続できます。ISDN Gateway SIP 設定は、IP アドレス、ホスト名、DNS A レコード、またはアウトバウンド SIP 接続の DNS SRV レコードの入力から開始します。冗長性は、適切な重みと優先順位を付けて DNS SRV レコードを使用することによって達成できるため、最初の Unified CM が失敗すると、ISDN Gateway はアウトバウンド SIP コールを 2 番目の Unified CM に送信します。

ビデオ テレフォニー用のゲートウェイ

ビデオゲートウェイは、IP テレフォニー ネットワークまたは PSTN へのビデオコールを終端します。ビデオ ゲートウェイは、ビデオをサポートし、そのコールを H.323 や SIP などのプロトコルを使用して IP ネットワーク上のビデオ コールに変換する ISDN またはシリアル リンクとデータをやり取りする必要がある点で音声ゲートウェイとは異なります。企業は、音声コールとビデオ コールでゲートウェイを分けることを検討することも、音声コールとビデオ コールの両方をルーティングする統合ゲートウェイを設置することもできます。

次の点を考慮することによって、音声とビデオで別々のゲートウェイが必要なのか、統合ゲートウェイが必要なのかを判断できます。

ダイヤル プラン:ビデオ ユーザ用に別のダイヤル プランを用意できる場合は、既存のエンタープライズ ダイヤル プランを維持しながら、別のビデオ ゲートウェイを使用できます。

ビデオ ユーザ:主にビデオよりも音声を使用するユーザの方が圧倒的に多い場合は、別のビデオ ゲートウェイを使用してビデオ コール ユーザにサービスを提供することを推奨します。

ロケーション:多数のビデオ ユーザが地理的に分散している場合は、統合ゲートウェイを使用して総所有コスト(TCO)を削減することを推奨します。

ビデオ IVR、自動応答、トランク上でのボンディングなどの付加的なビデオ機能:統合ゲートウェイでサポートされない高度な機能をサポートするには、専用ビデオ ゲートウェイが必要です。

プロトコル:会社の方針や標準に合わせるために、ゲートウェイ プロトコルが重要な要素になる可能性があります。

デバイス管理:保守、管理、およびトラブルシューティングを容易にしておくことは重要な要素になる可能性があります。専用ゲートウェイはどちらかと言えば管理/設定用のユーザ インターフェイス(GUI)において優れており、統合ゲートウェイはトラブルシューティングにおいて優れています。ただし、こうした要素は製品によって異なります。

専用ビデオ ゲートウェイ

音声ゲートウェイを含む大規模な音声インフラストラクチャを所有する企業は、ユーザが専用ビデオ コールを PSTN に発信するためのビデオ ゲートウェイを追加できます。専用ビデオ ゲートウェイには、Cisco ISDN Gateway および Serial Gateways があります。これらの製品は音声のみのコールをサポートしていますが、これらはビデオ ユーザを特に念頭に置いて設計されました。さまざまなビデオ中心プロトコルおよび機能をサポートしています。

図 5-6 に、音声ゲートウェイ用に既存のプロトコルを使用しており、Unified CM ユーザが音声コールとビデオ コールを PSTN に発信できるようにビデオ ゲートウェイを追加できる、企業での展開の一例を示します。

図 5-6 音声と IP ビデオ テレフォニーに別々の PSTN 回線を使用する Unified CM システム

 

シスコ ビデオ ゲートウェイはビデオ コール用としては優れていますが、シスコ音声ゲートウェイが提供するすべての機能をサポートしているわけではありません。シスコのビデオ ゲートウェイには次の特性があります。

Serial Gateway は、IP 接続用に H.323 のみをサポートします。

ISDN Gateway は、IP 接続用に H.323 および SIP(リリース 2.2 以降)をサポートします。

T1/E1-PRI、BRI、V.35、RS-449、および EIA-530 をサポートします。

H.261、H.263、H.263+、および H.264 ビデオ コーデックをサポートします。

G.711、G.722、G.722.1、および G.728 をサポートしますが、G.729 オーディオはサポートしません。

H.320、H.233、H.234、H.235(AES)、H.239、H.221、FTP、RTP、HTTP、HTTPS、DHCP、SNMP、および NTP をサポートします。

このように製品間の違いがあるため、Cisco TDM および Serial Gateways は Cisco 音声ゲートウェイの代わりとしては推奨できません。IP テレフォニーのユーザが通信環境にビデオを追加するには、両方のタイプのゲートウェイを配置して、すべての音声コールに Cisco 音声ゲートウェイを使用し、ビデオ コールのみに Cisco ビデオ ゲートウェイを使用する必要があります。また、配置する Cisco ゲートウェイのモデルによっては、PSTN サービス プロバイダーから音声とビデオに別個の回線を調達する必要がある場合もあります。

また、トール バイパスを設けるためには IP ネットワーク内でコールをどのようにリモート ゲートウェイへルーティングするのか、および IP ネットワークが使用不能になるか、コールを完了できるだけの帯域幅がない場合に、PSTN 上でコールをどのように再ルーティングするのかを考慮してください。具体的には、ビデオ コール用の自動代替ルーティング(AAR)を起動するのか、といったことです。

統合ビデオ ゲートウェイ

推奨はされていませんが、企業は音声とビデオ両方のゲートウェイ機能を備えた統合デバイスを検討できます。このデバイスは、管理対象デバイスの数が少なくなり、ダイヤル プランが単純になるというメリットを企業にもたらします。このゲートウェイは、コールが音声の場合は音声コールとして処理し、コールがビデオの場合はビデオ コールとして処理します。

Cisco IOS、ISDN、および Serial Video ゲートウェイには、次のような特徴があります。

H.323 および SIP サポートを提供します(H.323 のみを提供する Serial Gateway を除く)。

H.261、H.263、H.263+、および H.264 ビデオ コーデックをサポートします。

さまざまな着信側および発信側変換機能を提供します。

さまざまなロギングおよびトラブルシューティング機能を提供します。

次の留意点は、Cisco IOS、ISDN、および Serial Video ゲートウェイの配置に適用されます。

追加のビデオ コール用の PSTN リンクに必要な容量を考慮してください。

Binary Flow Control Protocol(BFCP)などのコンテンツ共有を使用するためのデバイスが必要かどうかと、IP ネットワークで使用される追加の帯域幅を考慮してください。

ゲートウェイでサポートする必要がある会議で使用される遠端カメラ制御や DTMF などの機能が必要かどうかを考慮してください。

Unified CM でのゲートウェイの設定

次のいずれかの方法で Cisco TelePresence ISDN Gateway を設定できます。

ISDN ゲートウェイを指す SIP トランクを設定し(図 5-3 を参照)、その SIP トランクを指す、該当する Unified CM ルート パターンを追加します。

Unified CM から Cisco VCS に SIP トランクを設定します。H.323 を使用して VCS に ISDN ゲートウェイ(または、この場合は Serial ゲートウェイ)を登録します(図 5-2 を参照)。

Cisco TelePresence Serial Gateway を Unified CM に直接トランクさせることはできません。Cisco VCS に登録した後、SIP トランクを Unified CM に登録する必要があります。

どちらの方法でも最終的な目標は、各ゲートウェイが受信したすべての着信コールを Unified CM に送り、Unified CM がコールのルーティング方法を決定できるようにすることです。Unified CM と VCS の間で SIP トランクを設定する方法の詳細については、「Cisco Unified CM トランク」の章を参照してください。

コール シグナリング タイマー

H.320 ボンディングに固有の遅延のため、ビデオ コールは音声コールよりも接続に時間がかかる場合があります。Unified CM のいくつかのタイマーは、デフォルトで音声コールをできるだけ高速に処理するように調整されているため、それが原因でビデオ コールが失敗する場合があります。したがって、H.320 ゲートウェイ コールをサポートするには、次のタイマーをデフォルト値から変更する必要があります。

H.245TCSTimeout

Media Exchange Interface Capability Timer

Media Exchange Timer

これらの各タイマーを、Unified CM Administration の Service Parameters で 25 まで増やすことを推奨します。このパラメータはクラスタ全体のサービス パラメータであるため、既存の Cisco 音声ゲートウェイへの音声コールも含めて、あらゆるタイプのデバイスへのコールに影響を与えることに注意してください。

Cisco IOS 音声ゲートウェイのベアラ機能

H.323 コールは、どのタイプのコールを行うかを示すために、H.225/Q.931 Bearer Capabilities Information Element(bearer-caps)を使用します。音声専用コールでは、bearer-caps が「speech」または「3.1 KHz Audio」に設定され、ビデオ コールでは bearer-caps が「Unrestricted Digital Information」に設定されます。一部のデバイスでは、Unrestricted Digital Information の bearer-caps をサポートしていません。Unified CM が H.323 ビデオ コールとしてコールを試みると、これらのデバイスへのコールは失敗する場合があります。

Unified CM は、次の要因に基づいて、どの bearer-caps を設定するかを決定します。

発信側デバイスまたは着信側デバイス(あるいはその両方)がビデオ対応かどうか

それらのデバイス間のコールにビデオを許可するように Unified CM のリージョンが設定されているかどうか

Unified CM では、ビデオ コールをオーディオとして再試行する機能をサポートしており、この機能は設定を介して有効にできます。Unified CM がビデオ コールの bearer-caps を「Unrestricted Digital」に設定し、コールが失敗すると、Unified CM は同じコールの bearer-caps を「speech」に設定したオーディオ コールとして再試行します。

H.323 を使用する場合、Cisco IOS ゲートウェイは、コールの設定で受信するベアラ機能に基づいて、コールを音声またはビデオとして処理できます。SIP を使用する場合、ゲートウェイはコールのネゴシエーションのため、ISDN 機能を SDP に変換します。

Cisco 音声ゲートウェイが Unified CM との通信に MGCP を使用している場合、この問題は発生しません。それは、Unified CM の MGCP プロトコル スタック上ではビデオがサポートされておらず、しかも、MGCP モードでは、Unified CM が PSTN への D チャネル シグナリングを完全に制御するためです。

ゲートウェイのベスト プラクティス

ここでは、ゲートウェイに関する次のベスト プラクティスについて取り上げます。

「ゲートウェイ ゲイン設定の調整」

「PSTN からの着信コールのルーティング」

「PSTN への発信コールのルーティング」

「自動代替ルーティング(AAR)」

「最低料金選択機能」

ゲートウェイ ゲイン設定の調整

ゲートウェイを介して Cisco Unified Communications ネットワークを PSTN に接続するには、停電、インピーダンスの不整合、および遅延などによるエコーや信号の減衰から生じる、メディア品質問題に適切に対処する必要があります。このため、予期されるすべての音声パスに信号損失の状況を詳細に提供する Network Transmission Loss Plan(NTLP)を確立する必要があります。このプランを使用して、最適な声の大きさと効果的なエコー キャンセレーションを得るために信号の強さを調整する必要があるロケーションを識別できます。すべての通信事業者が同じ損失プランを使用するわけではないこと、また、セルラー ネットワークの存在が NTLP の作成をさらに複雑にすることに注意してください。このような NTLP を作成する前に、ゲートウェイで入力ゲインや出力衰退を調整することは推奨できません。詳細については、次の Web サイトで入手可能な『 Echo Analysis for Voice Over IP 』を参照してください。

http://www.cisco.com/en/US/docs/ios/solutions_docs/voip_solutions/EA_ISD.pdf

PSTN からの着信コールのルーティング

PSTN からの着信コールをルーティングするには、次のいずれかの方法を使用します。

ビデオおよび音声コールの両方に対して、単一のディレクトリ番号を各ユーザに割り当てます。この方法では、音声のみのコールを含む、ビデオ ゲートウェイの PSTN からすべてのコールが受信されるため、推奨されません。貴重なビデオ ゲートウェイ リソースが浪費され、拡張が困難です。

Unified CM クラスタ内にあるビデオ対応デバイスごとに、少なくとも 2 つの異なる電話番号を割り当て、1 つの回線を音声用、もう 1 つをビデオ用とします。この方法では、外部の(PSTN)発信者はビデオを有効にするために、正しい番号をダイヤルする必要があります。

ビデオ コールの場合は、外部の発信者にビデオ ゲートウェイのメイン番号をダイヤルしてもらいます。Cisco ISDN および Serial ゲートウェイは統合された自動応答機能を提供し、発信者に相手側の内線番号の入力を求めます。次に、Unified CM は、それがビデオ コールであることを認識し、宛先デバイスを呼び出します。この方法では、発信者はそれぞれの着信側ごとに 2 つの異なる DID 番号を覚える必要はありませんが、着信ビデオ コールをダイヤルするために余分な手順が増えます。


) 外部のビデオ エンドポイントは、IVR プロンプトに着信側の内線番号を入力するために、DTMF をサポートしている必要があります。


次の例は、2 番めの方法を示しています。

ユーザは、ビデオ機能が有効になっている Cisco Unified IP Phone を所有しています。IP Phone の内線番号は 51212 で、完全修飾 DID 番号は 1-408-555-1212 です。DID 番号をダイヤルするだけで、音声のみのコールで PSTN からそのユーザに到達できます。CO は、Cisco 音声ゲートウェイに接続した T1-PRI 回線(複数の場合もある)を通じて、その DID 番号にコールを送信します。ゲートウェイでコールが受信されると、Unified CM はゲートウェイが音声専用であることを認識し、そのコール用に 1 つの音声チャネルのみのネゴシエーションを行います。逆に、PSTN からビデオ コールのためにそのユーザに到達するには、ビデオ ゲートウェイのメイン番号をダイヤルした後、ユーザの内線番号を入力する必要があります。たとえば、1-408-555-1000 をダイヤルするとします。CO は、Cisco ISDN ビデオ ゲートウェイに接続されている T1-PRI 回線(複数の場合もある)を通じて、その番号にコールを送信します。ゲートウェイでコールが受信されると、自動応答プロンプトが発信元に、到達すべき相手の内線番号の入力を求めます。発信者が DTMF トーンで内線番号を入力すると、Unified CM はゲートウェイにビデオ機能があることを認識し、そのコール用に音声とビデオの両方のチャネルをネゴシエートします。

ゲートウェイの番号操作

Cisco TelePresence ISDN Gateways 8321 および 3241、Cisco TelePresence Serial Gateways 8330 および 3340 にはすべて、番号操作の機能があります。これらのビデオ ゲートウェイには、複数のダイヤル プラン ルールを設定できます。これらのルールは、発信番号および/または着信番号に基づいて照合され、IP から PSTN または PSTN から IP の方向のいずれかで機能します。着信コールが設定されたダイヤル プラン ルールと一致すると、ISDN または Serial ゲートウェイは次のいずれかの処理を実行できます。

コールの拒否

自動応答の開始

番号(または PSTN から IP へのコールの場合、IP アドレス、ホスト名、または URI)にコールする

アクションがある番号へのコールである場合、元の着信番号またはその一部を、コールする新しい番号に使用できます。

詳細については、次のマニュアルを参照してください。

次の Web サイトから入手可能な Cisco TelePresence ISDN Gateway のマニュアル

http://www.cisco.com/en/US/products/ps11448/tsd_products_support_series_home.html

次の Web サイトから入手可能な Cisco TelePresence Serial Gateway のマニュアル

http://www.cisco.com/en/US/products/ps11605/tsd_products_support_series_home.html

PSTN への発信コールのルーティング

発信コールを PSTN へルーティングするには、次のいずれかの方法を使用します。

音声コールとビデオ コールに異なるアクセス コード(異なるルート パターン)を割り当てます。たとえば、ユーザが 9 の後にコール先の PSTN 電話番号をダイヤルすると、それがコールを音声ゲートウェイに送るルート パターンと一致します。同様に、数字の 8 を、ビデオ ゲートウェイにコールを渡すルート パターンとして使用することもできます。

Unified CM クラスタ内にあるビデオ対応デバイスごとに、少なくとも 2 つの異なる電話番号を割り当て、1 つの回線を音声用、もう 1 つをビデオ用とします。その後、2 つの回線に異なるコーリング サーチ スペースを指定します。ユーザが第 1 の回線上でアクセス コード(たとえば 9)をダイヤルすると音声ゲートウェイにつながり、同じアクセス コードを第 2 の回線上でダイヤルするとビデオ ゲートウェイにつながります。この方法では、ユーザが 2 つの異なるアクセス コードを覚える必要がありませんが、コールの発信時に電話機で正しい回線を押す必要があります。ただし、すべてのシスコ ビデオ エンドポイントが現時点で複数回線をサポートしているわけではなく、その場合は、発信コールを PSTN にルーティングする方法として、プレフィックスの使用をお勧めします。

ビデオ ゲートウェイ コールの帯域幅

特定のプレフィックスを持つコールが PSTN への ISDN 接続である最大消費帯域に制限されるように、Cisco TelePresence ISDN Gateway のダイヤル プラン ルールを設定できます。これは、1 つのコールがすべての PRI リンクを独占できないようにする際に便利です。ゲートウェイにサービス プレフィックスを設定するときは、次のいずれかの最大速度を選択できます。

128 kbps

192 kbps

256 kbps

320 kbps

384 kbps

512 kbps

768 kbps

1152 kbps

1472 kbps

IP エンドポイントから PSTN へ向かうコールは、ゲートウェイがそのコールにどのサービスを使用するかを決定できるように、着信番号の先頭にサービス プレフィックスを含めることができます。オプションとして、番号の先頭にサービス プレフィックスを含んでいないコールに使用する、デフォルト プレフィックスを設定できます。この方法は、非常に複雑になる可能性があります。ユーザは、求めるコール速度を得るためにダイヤルすべきプレフィックスを覚えておく必要があるからです。また、管理者は、Unified CM で複数の(速度ごとに 1 つずつ)ルート パターンを設定する必要があります。


) Cisco TelePresence ISDN Gateway の 2 つのグローバル設定を使用して、着信および発信 ISDN コールの帯域幅の最小値または最大値を設定できます。ダイヤル プランによって、これよりも大きい最大帯域幅に上書きすることはできません。ただし、ダイヤル プランによって、特定のコールに対し、より小さい帯域幅を強制することはできます。


自動代替ルーティング(AAR)

IP ネットワークにコールを処理できるだけの帯域幅がない場合、Unified CM はコール アドミッション制御メカニズムを使用して、コールの処理方法を決定します。Unified CM は設定に従って、次のいずれかの処理を実行します。

コールに失敗し、発信側に対してビジー トーンを再生し、発信側の画面に Bandwidth Unavailable メッセージを表示します

ビデオ コールを音声のみのコールとして再試行します。

Automated Alternate Routing(AAR; 自動代替ルーティング)を使用し、PSTN ゲートウェイなどの代替パス上でコールを再ルーティングします。

Retry Video Call as Audio オプションは、終端(着信側)デバイスでのみ有効です。そのため、発信側デバイスでは宛先ごとに異なるオプション(再試行または AAR)を使用できる柔軟性があります。

帯域幅の制限が原因でビデオ コールが失敗した場合、自動代替ルーティング(AAR)が有効であれば、Unified CM は失敗したコールをビデオ コールとして AAR の宛先に再ルーティングしようとします。AAR が有効でない場合、失敗したコールによって、発信者にビジー トーンとエラー メッセージが送信されます (図 5-7 を参照)。

図 5-7 ビデオ コールで起こり得るシナリオ

 

音声コールまたはビデオ コールに AAR を使用できるようにするには、発信側デバイスと着信側デバイスを AAR グループのメンバーとして設定し、着信側デバイスに外部電話番号マスクを設定する必要があります。外部電話番号マスクによって、ユーザの内線番号用の完全修飾 E.164 アドレスが指定されます。また、AAR グループによって、コールが PSTN 上で正しくルーティングされるために、着信側デバイスの外部電話番号マスクの前に付加すべき数字が示されます。

たとえば、ユーザ A が San Jose AAR グループに属し、ユーザ B が San Francisco AAR グループに属しているとします。ユーザ B の内線番号は 51212 で、外部電話番号マスクは 6505551212 です。AAR グループは、San Jose と San Francisco の AAR グループ間のコールに対して、番号の前に 91 を付加するよう設定されています。この場合、ユーザ A が 51212 をダイヤルし、2 つのサイト間の IP WAN 上にそのコールを処理できるだけの帯域幅がない場合、Unified CM はユーザ B の外部電話番号マスクである 6505551212 を選択し、その前に 91 を付加して 916505551212 への新規コールを生成し、ユーザ A 用の AAR コーリング サーチ スペースを使用します。

Unified CM のデフォルトでは、すべてのビデオ対応デバイスで Retry Video Call as Audio オプションが有効(オン)になります。したがって、ビデオ コールで AAR を使用できるようにするには、Retry Video Call as Audio オプションを無効(オフ)にする必要があります。また、ロケーション間でリソース予約プロトコル(RSVP)に基づいたコール アドミッション制御ポリシーが使用されている場合は、RSVP ポリシーを音声ストリームとビデオ ストリームの両方について Mandatory に設定する必要があります。

さらに、Unified CM は、着信側デバイスだけを見て Retry Video Call as Audio オプションが有効か無効かを判断します。したがって、上記のシナリオで AAR プロセスが実行されるためには、ユーザ B の電話機で Retry Video Call as Audio オプションが無効にされている必要があります。

最後に、デバイスは 1 つの AAR グループだけに所属できます。AAR グループによって、どの数字を前に付加するかが決定されるため、再ルーティングされたコールにどのゲートウェイが使用されるかにも影響があります。前項で述べたように、PSTN への発信コール ルーティングの設定に何を選択したかに応じて、AAR によって再ルーティングされるビデオ コールは、ビデオ ゲートウェイでなく音声ゲートウェイに送られる可能性もあります。したがって、AAR グループと AAR コーリング サーチ スペースの構築は入念に行い、必ず正しい数字が付加され、AAR に正しいコーリング サーチ スペースが使用されるようにしてください。

こうした考慮事項により、大規模な企業環境での AAR の設定がかなり複雑になる可能性がありますが、エンドポイントのタイプが 2 つのどちらかに限定されている場合には、AAR の実装が容易です。エンドポイントが音声とビデオの両方のコールに対応している場合(Cisco Unified IP Phone 9971 または Cisco TelePresence System EX90)は、AAR の設定が非常に複雑になることがあります。したがって、音声とビデオのエンドポイントが混在する大企業では、ユーザごとに AAR の重要性をよく考え、専用のビデオ会議室や経営幹部用ビデオ システムなど、一部のビデオ デバイスだけに AAR を使用してください。 表 5-2 に、さまざまなデバイス タイプで AAR を使用するのが適切なシナリオのリストを示します。

表 5-2 デバイス タイプ別の AAR 使用条件

デバイス タイプ
デバイスを使用したコールの宛先
AAR の必要性
コメント

IP Phone

他の IP Phone およびビデオ対応デバイス

Yes

ビデオ対応デバイスにコールするときでも、発信元デバイスが音声専用なので、コールを音声ゲートウェイにルーティングするように AAR を設定できます。

Cisco Jabber または Cisco Unified IP Phone 9971

他のビデオ対応デバイスのみ

Yes

デバイスは必ずビデオ コールに使用されるので、AAR グループを設定できます。

IP Phone およびその他のビデオ対応デバイス

No

音声のみのコールではビデオ コールと異なるルーティングを行うように AAR グループを設定するのは困難です。

H.323 または SIP クライアント

他のビデオ対応デバイスのみ

Yes

デバイスは必ずビデオ コールに使用されるので、AAR グループを設定できます。

IP Phone およびその他のビデオ対応デバイス

No

音声のみのコールではビデオ コールと異なるルーティングを行うように AAR グループを設定するのは困難です。

最低料金選択機能

最低料金選択機能(LCR)とテールエンド ホップオフ(TEHO)は、VoIP ネットワークでは非常によく知られており、ビデオ コールにも利用できます。一般的にどちらの用語も、長距離電話番号へのコールが IP ネットワークを通じて宛先に最も近いゲートウェイにルーティングされ、通話料金が安くなるような、コール ルーティング ルールの設定方法を指しています。Unified CM は、次のような豊富な番号分析機能と番号操作機能のセットを使用して、この機能をサポートします。

パーティションとコーリング サーチ スペース

トランスレーション パターン

ルート パターンとルート フィルタ

ルート リストとルート グループ

LCR をビデオ コール用に設定するのは、音声コールの場合よりも少し複雑で、その理由は次のとおりです。

この章ですでに述べたように、ビデオ コールには独自の専用ゲートウェイが必要です。

ビデオ コールには、音声コールをはるかに上回る帯域幅が必要です。

専用ゲートウェイに関しては、LCR をビデオ コールに使用するかどうかを決めるための基礎となるロジックは、「自動代替ルーティング(AAR)」の項で説明したロジックとほとんど同じです。音声とビデオ用にさまざまなタイプのゲートウェイが必要になるため、LCR で音声コールを 1 つのゲートウェイに送り、ビデオ コールを別のゲートウェイに送るために必要なすべてのパーティション、コーリング サーチ スペース、トランスレーション パターン、ルート パターン、ルート フィルタ、ルート リスト、およびルート グループを設定するのは、かなり複雑な作業になる可能性があります。

帯域幅の要件に関しては、LCR を使用するかどうかは、特定のロケーションとの間を結ぶビデオ コールの LCR をサポートできるだけの帯域幅が、使用している IP ネットワークにあるかどうかで決まります。現在の帯域幅が十分でない場合は、IP ネットワークをアップグレードしてビデオ コール用の空きを作ったり、ローカル ゲートウェイを導入して PSTN 上でコールをルーティングしたりするためのコストと、ビデオ コールの利点を比較する必要があります。たとえば、ある中央サイトに 1.544 Mbps の T1 回線を介して支社が接続されているとします。その支社内には、20 人のビデオ機能を持つユーザがいます。1.544 Mbps の T1 回線は、最大でほぼ 4 つの 384 kbps ビデオ コールを処理できます。この場合、中央サイトまでビデオ コールをルーティングして、通話料金を節約することに意味があるかどうかが問題です。サポートするコールの数に応じて、1.544 Mbps の T1 回線をもっと高速のものにアップグレードしなければならない場合もあります。ビデオには、そうしたアップグレードに要する毎月の追加料金に見合うだけの重要性があるのでしょうか。ない場合は、その支社に Cisco ビデオ ゲートウェイを導入すると、LCR に煩わされずに済みます。しかし、各支社へのローカル Cisco ビデオ ゲートウェイの配置も安価には行えないため、最終的には、ビデオから公衆網へのコールがビジネスにとってどれほど重要であるかを判断しなければなりません。ビデオが重要でない場合は、帯域幅をアップグレードしたりビデオ ゲートウェイを購入したりするよりも、Retry Video Call as Audio 機能を使用し、使用可能な帯域幅を超過した場合にビデオ コールを音声専用コールとして再ルーティングした方がよいこともあります。コールが音声専用までダウングレードされると、LCR を実行するためのローカル ゲートウェイ リソースと帯域幅は、もっと手ごろな価格で設定しやすいものになります。

FAX とモデムのサポート

Cisco ゲートウェイ全体に対する FAX とモデムのサポートについては、次のマニュアルを参照してください。

次の Web サイトから入手可能な『 Cisco Unified Communications System 9.0 SRND 』の「 Gateways 」の章を参照してください。

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/9x/gateways.html

次の Web サイトから入手可能な『 Fax, Modem, and Text Support over IP Configuration Guide

http://www.cisco.com/en/US/docs/ios-xml/ios/voice/fax/configuration/15-2mt/vf-15-2mt-book.html