この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
ゲートウェイは、コラボレーション エンドポイントのネットワークを公衆電話交換網(PSTN)、従来型の PBX、または外部システムに接続するための複数の方法を提供します。音声およびビデオ ゲートウェイはエントリ レベルのスタンドアロン プラットフォームから、ハイエンドで機能が充実した統合ルータ、シャーシ ベースのシステム、および仮想化アプリケーションまであります。
この章では、音声およびビデオ ネットワークに適切なプロトコルと機能サポートを提供するために Cisco ゲートウェイを選択する際、考慮すべき重要な要素について説明します。この章は、次の項で構成されています。
表 5-1 に、この章に新しく追加されたトピック、またはこのマニュアルの以前のリリースから大幅に改訂されたトピックの一覧を示します。
|
|
|
---|---|---|
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 Expressway シリーズが、企業とサービス プロバイダー ネットワーク間の相互接続ポイントとしてこれらの機能を実行します。
この章では、Cisco TDM および Serial ゲートウェイ プラットフォームと Cisco Expressway の詳細について説明します。Cisco Unified Border Element についても簡単に説明します。
Cisco ゲートウェイを使用すると、音声およびビデオ エンドポイントは外部通信デバイスと通信できるようになります。Cisco TDM ゲートウェイには、アナログとデジタルの 2 種類があります。両方のタイプが音声コールをサポートしますが、デジタル ゲートウェイのみがビデオをサポートします。
Cisco アナログ ゲートウェイには、ステーション ゲートウェイとトランク ゲートウェイがあります。
アナログ ステーション ゲートウェイは、Unified CM を一般電話サービス(POTS)のアナログ電話機、IVR システム、FAX マシン、およびボイスメール システムに接続します。ステーション ゲートウェイは、Foreign Exchange Station(FXS)ポートを備えています。
アナログ トランク ゲートウェイは、Unified CM を PSTN セントラル オフィス(CO)または PBX トランクに接続します。アナログ トランク ゲートウェイは、PSTN、PBX、またはキー システムへのアクセス用の Foreign Exchange Office(FXO)ポート、および従来型の PBX とのアナログ トランク接続用の E&M(受信(recEive)/送信(transMit)、または ear and mouth)ポートを備えています。アナログ Direct Inward Dialing(DID; ダイヤルイン方式)および Centralized Automatic Message Accounting(CAMA)も、PSTN 接続に使用できます。
Cisco アナログ ゲートウェイは、次の製品およびシリーズで使用できます。
Cisco デジタル トランク ゲートウェイは、一次群速度インターフェイス(PRI)、基本速度インターフェイス(BRI)、シリアル インターフェイス(V.35、RS-449、および EIA-530)、または T1 個別線信号方式(CAS)などのデジタル トランクを経由して、Unified CM を PSTN または PBX に接続します。デジタル T1 PRI および BRI トランクは、ビデオおよび音声専用コールの両方に使用できます。
Cisco TelePresence ISDN Link は、Cisco TelePresence EX、MX、SX、および C シリーズのエンドポイントをサポートする、室内 ISDN および外部ネットワーク接続用のコンパクトなアプライアンスです。従来の音声およびビデオ ゲートウェイは多数のエンドポイントの PSTN と IP ネットワークの間の接続を提供する共有リソースですが、各 Cisco ISDN Link は単一の Cisco エンドポイントとペアになっています。詳細については、次の URL から入手可能な Cisco TelePresence ISDN Link のマニュアルを参照してください。
https://www.cisco.com/en/US/products/ps12504/tsd_products_support_series_home.html
Cisco Unified Communications Manager(Unified CM)は、ゲートウェイ用に次の IP プロトコルをサポートしています。
Cisco Expressway シリーズおよび Cisco TelePresence Video Communication Server(VCS)は、ゲートウェイに次の IP プロトコルをサポートしています。
SIP は、Cisco Collaboration ソリューション全体と新しい音声およびビデオ製品の方向性と一致しているため、コール シグナリング プロトコルとして推奨されます。ただし、プロトコルの選択は、サイト特有の要件と、現在の機器の設置ベースによって異なる場合があります。ゲートウェイ ハードウェアによって既存の配置が制限されたり、特定の機能用に別のシグナリング プロトコルが必要になったりすることがあります。
たとえば、ネットワーク内の 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 の配置モデルも、ゲートウェイ プロトコルの選択に影響を与える場合があります(コラボレーションの配置モデルの章を参照してください)。
音声およびビデオ エンドポイントで使用するゲートウェイは、次のコア機能要件を満たす必要があります。
付加サービスは、保留、転送、および会議などの基本的なテレフォニー機能です。
Cisco Unified Communications は、分散モデルに基づき、高いアベイラビリティを確保しています。Unified CM クラスタには、Unified CM の冗長性が用意されています。ゲートウェイは、プライマリ Unified CM に障害が発生した場合に、セカンダリ Unified CM への「リホーム」機能をサポートする必要があります。一部のゲートウェイは Cisco VCS に登録されることがあります。この場合、ゲートウェイはプライマリ Cisco VCS に障害が発生した場合に、セカンダリへ「リホーム」する機能をサポートする必要があります。
企業での配置用に選択するゲートウェイがすべて、上記のコア要件を満たしていることを確認するには、ゲートウェイ製品の資料を参照してください。さらに、どのコラボレーションの実装についても、各サイト特有の機能要件(たとえば、アナログまたはデジタル アクセス、DID、およびキャパシティ要件)があります。
DTMF は、信号に音声帯域内の特定の周波数ペアを使用するシグナリング方式です。64 kbps のパルス符号変調(PCM)音声チャネルは、これらの信号を容易に伝送できます。しかし、音声圧縮に低ビット レート コーデックを使用する場合、DTMF 信号の損失または歪みの可能性があります。IP インフラストラクチャを介して DTMF トーンを伝送するアウトオブバンド シグナリング方式は、コーデックにより誘発されるこれらの症状を簡単に解決します。
Cisco VG300 シリーズは、伝送制御プロトコル(TCP)ポート 2002 を使用して、DTMF 信号をアウトオブバンドで伝送します。アウトオブバンド DTMF は、VG310、VG320、および VG350 用のデフォルトのゲートウェイ コンフィギュレーション モードです。
Cisco 4000 シリーズ製品などの H.323 ゲートウェイは、DTMF 信号をアウトオブバンドで交換するための拡張 H.245 機能を使用して、Unified CM と情報を交換できます。この機能は、4000 シリーズ ゲートウェイのコマンドライン インターフェイスと、そのダイヤル ピアで使用可能な dtmf-relay コマンドを使用して有効に設定されます。
Cisco IOS ベースのプラットフォームでは、Unified CM 通信に MGCP を使用できます。MGCP プロトコルには、 パッケージ の概念があります。MGCP ゲートウェイは、始動後、DTMF パッケージをロードします。MGCP ゲートウェイは、制御チャネルを介して、受信した DTMF トーンを表す シンボル を送信します。次に、Unified CM は、これらの信号を解釈し、アウトバンドでシグナリング エンドポイントに DTMF 信号を渡します。
DTMF に使用される方法は、ゲートウェイ CLI コマンドを使用して設定できます。
mgcp dtmf-relay voip codec all mode { DTMF method }
(注) MGCP ゲートウェイを、インバンド DTMF のみをアドバタイズするように設定することはできません。インバンド DTMF リレーを有効にすると、MGCP ゲートウェイはインバンドおよびアウトオブバンド(OOB)両方の DTMF 方式をアドバタイズします。Unified CM は、どの方式を選択すべきかを判断し、MGCP シグナリングを使用してゲートウェイに通知します。両方のエンドポイントが MGCP である場合は、インバンド DTMF を有効にした後、両方のサイドでインバンドおよび OOB DTMF の方式を Unified CM にアドバタイズするため、DTMF リレー用のインバンドを呼び出す機能がありません。インバンドおよび OOB の機能がエンドポイントでサポートされている場合、Unified CM は常に OOB を選択します。
Cisco IOS および ISDN ゲートウェイでは、Unified CM 通信に SIP を使用できます。これらのプラットフォームはさまざまな方式の DTMF をサポートしていますが、Unified CM との通信に使用できるのは次の方式だけです。
DTMF に使用される方式は、ゲートウェイ CLI コマンド dtmf-relay をそれぞれの dial-peer の下で使用することで Cisco IOS で設定できます。Cisco ISDN ゲートウェイは、DTMF で RFC 2833 および KPML をサポートしています。
DTMF 方式の選択の詳細については、SIP トランク経由のコールの項を参照してください。
付加サービスは、保留、転送、および会議などのユーザ機能を提供します。これらは、基本的なテレフォニー機能と見なされ、ビデオ コールよりも音声コールのほうでよく使用されます。
Cisco SCCP ゲートウェイは、完全な付加サービス サポートを提供します。SCCP ゲートウェイは、ゲートウェイと Unified CM 間のシグナリング チャネル、および SCCP を使用して、呼制御パラメータを交換します。
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. IP 電話機 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 プロトコルは、すべてのセッション機能を制御する、Unified CM とのマスター/スレーブ プロトコルであるので、Unified CM は、MGCP ゲートウェイの音声接続を容易に操作できます。IP テレフォニー エンドポイント(たとえば、IP Phone)が、セッションの変更(たとえば、コールを別のエンドポイントに転送する)を必要とする場合、そのエンドポイントは、セッションの変更を SCCP を使用して Unified CM に通知します。次に、Unified CM は、Session ID に関連した現在の RTP ストリームを終了し、新しいエンドポイント情報を使用して新しいメディア セッションを開始することを、MGCP ユーザ データグラム プロトコル(UDP)制御接続を使用して、MGCP ゲートウェイに通知します。図 5-5 では、プロトコルが MGCP ゲートウェイ、エンドポイント、および Unified CM 間で交換される様子を示しています。
Cisco SIP ゲートウェイへの Unified CM SIP トランク インターフェイスは、保留、ブラインド転送、在席転送などの付加サービスをサポートしています。付加サービスのサポートは、INVITE や REFER などの SIP 方式によって実現されます。付加サービスを機能させるには、対応する SIP ゲートウェイによってこれらの方法がサポートされている必要もあります。詳細については、次のマニュアルを参照してください。
https://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_guides_list.html
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/sip/configuration/15-mt/sip-config-15-mt-book.html
https://www.cisco.com/en/US/products/ps11448/tsd_products_support_series_home.html
コラボレーション ソリューション アーキテクチャに不可欠なことは、高価な専有の従来型の PBX システムの代わりに、低コストの分散型 PC ベース システムを提供することです。この分散型設計は、クラスタ化された Unified CM の堅固なフォールト トレラント アーキテクチャに適しています。最も単純な形式(2 システムのクラスタ)であっても、セカンダリ Unified CM は、最初にプライマリ Unified CM によって管理されていたすべてのゲートウェイの制御権を引き受ける必要があります。
ブート後、Cisco VG310、VG320、および VG350 ゲートウェイには、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 コール プリザベーションは、次の種類の障害と接続に対応します。
– 一方または両方のエンドポイントと Unified CM との間で H.225.0 または H.245 メッセージのシグナリングに使用される伝送制御プロトコル(TCP)接続が失われたか、フラッピングしている場合
– エンドポイントがクラスタ内の異なる Unified CM に登録されていて、その 2 つの Unified CM 間の TCP 接続が失われた場合
– IP Phone 間のコールで、PSTN が同じサイトにある場合
– ゲートウェイとソフトスイッチ間の H.225.0 または H.245 TCP 接続が失われ、ソフトスイッチがエンドポイント上のコールをクリアしない場合
– ソフトスイッチとエンドポイント間の H.225.0 または H.245 TCP 接続が失われ、ソフトスイッチがゲートウェイ上のコールをクリアしない場合
メディアが保持された後、一方の通話者が電話を切るか、メディアがアクティブでないことが検出されると、コールは終了します。コンピュータによって生成されたメディア ストリーム(メディア サーバからの音楽ストリーミングなど)が存在する場合は、メディア非アクティビティ検出が機能せず、コールが終了しない可能性があります。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 ゲートウェイにも、プライマリ 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 に「リホーム」(つまり復帰)できます。この復帰は、ただちに行われることもあれば、設定可能な時間が経過した後、または接続されているすべてのセッションが解除された後に行われることもあります。
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 またはシリアル リンクとデータをやり取りする必要がある点で音声ゲートウェイとは異なります。企業は、音声コールとビデオ コールでゲートウェイを分けることを検討することも、音声コールとビデオ コールの両方をルーティングする統合ゲートウェイを設置することもできます。
次の点を考慮することによって、音声とビデオで別々のゲートウェイが必要なのか、統合ゲートウェイが必要なのかを判断できます。
音声ゲートウェイを含む大規模な音声インフラストラクチャを所有する企業は、ユーザが専用ビデオ コールを PSTN に発信するためのビデオ ゲートウェイを追加できます。専用ビデオ ゲートウェイには、Cisco ISDN Gateway および Serial Gateways があります。これらの製品は音声のみのコールをサポートしていますが、これらはビデオ ユーザを特に念頭に置いて設計されました。さまざまなビデオ中心プロトコルおよび機能をサポートしています。
図 5-6 に、音声ゲートウェイ用に既存のプロトコルを使用しており、Unified CM ユーザが音声コールとビデオ コールを PSTN に発信できるようにビデオ ゲートウェイを追加できる、企業での展開の一例を示します。
図 5-6 音声と IP ビデオ テレフォニーに別々の PSTN 回線を使用する Unified CM システム
シスコ ビデオ ゲートウェイはビデオ コール用としては優れていますが、シスコ音声ゲートウェイが提供するすべての機能をサポートしているわけではありません。シスコのビデオ ゲートウェイには次の特性があります。
このように製品間の違いがあるため、Cisco TDM および Serial Gateway は Cisco 音声ゲートウェイの代わりとしては推奨できません。IP テレフォニーのユーザが通信環境にビデオを追加するには、両方のタイプのゲートウェイを配置して、すべての音声コールに Cisco 音声ゲートウェイを使用し、ビデオ コールのみに Cisco ビデオ ゲートウェイを使用する必要があります。また、配置する Cisco ゲートウェイのモデルによっては、PSTN サービス プロバイダーから音声とビデオに別個の回線を調達する必要がある場合もあります。
また、トール バイパスを設けるためには IP ネットワーク内でコールをどのようにリモート ゲートウェイへルーティングするのか、および IP ネットワークが使用不能になるか、コールを完了できるだけの帯域幅がない場合に、PSTN 上でコールをどのように再ルーティングするのかを考慮してください。具体的には、ビデオ コール用の自動代替ルーティング(AAR)を起動するのか、といったことです。
推奨はされていませんが、企業は音声とビデオ両方のゲートウェイ機能を備えた統合デバイスを検討できます。このデバイスは、管理対象デバイスの数が少なくなり、ダイヤル プランが単純になるというメリットを企業にもたらします。このゲートウェイは、コールが音声の場合は音声コールとして処理し、コールがビデオの場合はビデオ コールとして処理します。
次のいずれかの方法で Cisco TelePresence ISDN Gateway を設定できます。
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 ゲートウェイ コールをサポートするには、次のタイマーをデフォルト値から変更する必要があります。
これらの各タイマーを、Unified CM Administration の Service Parameters で 25 まで増やすことを推奨します。このパラメータはクラスタ全体のサービス パラメータであるため、既存の Cisco 音声ゲートウェイへの音声コールも含めて、あらゆるタイプのデバイスへのコールに影響を与えることに注意してください。
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 がビデオ コールの 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 アクセスの両方で、IP ベースのユニファイド コミュニケーションを幅広く展開しています。これによって、企業およびテレフォニー サービス プロバイダー両方による TDM ベースの回線から、ユニファイド コミュニケーション用の IP ベース トランクへの大幅な移行が可能になりました。IP ベースのテレフォニー トランクの中核には、RFC 3261 に基づく業界標準の通信プロトコルであり、音声、ビデオ、ユニファイド メッセージング、ボイスメール、会議などのマルチメディア通信セッションの制御に幅広く使用されている Session Initiation Protocol(SIP)があります。
これらの PSTN SIP トランクは、ファイアウォールが 2 つのデータ ネットワークを分割する方法と同様に、企業側で企業とサービス プロバイダーの IP ネットワーク間の責任分界点として機能するセッション ボーダー コントローラ(SBC)で終端します。Cisco Unified Border Element(CUBE)Enterprise はシスコの SBC サービスであり、次を提供することで企業向けの豊富なマルチメディア コミュニケーションを実現します。
CUBE は、IP トラフィックを SIP トランク経由でさまざまな企業およびサービス プロバイダーのネットワークに伝送する際に相互運用性、セキュリティ、およびサービス保証を確保するために必要な機能を提供します。これは Back-to-Back User Agent(B2BUA)で、Cisco ISR G2 800 シリーズ プラットフォームでの Cisco IOS インフラストラクチャ、ASR 1000 シリーズの Cisco IOS-XE、Cisco ISR 4000 シリーズ、およびシスコ クラウド サービス ルータ(CSR)1000V シリーズの CUBE(仮想 CUBE すなわち vCUBE)の一部です。図 5-7 に、企業の CUBE の展開を示します。
図 5-7 Cisco Unified Border Element の展開
Cisco Unified Border Element の詳細については、次のサイトで入手可能なマニュアルを参照してください。
インターネットを使用したコラボレーション サービスは、人気が高く、既存のレガシー ISDN ビデオ システムおよびゲートウェイがどんどん置き換えられています。インターネット ベースのコラボレーション サービスに使用されている 2 つの主なプロトコルは SIP と H.323 です。インターネットは、リモート ユーザとモバイル ユーザを、バーチャル プライベート ネットワーク(VPN)を使用せずに、音声、ビデオ、IM and Presence、およびコンテンツ共有サービスに接続するためにも使用されます。
Expressway-C と Expressway-E のペアは次の機能を実行します。
Expressway-C と Expressway-E は、連携してインターネット経由の Business-to-Business(B2B)コミュニケーション用のコア コンポーネントであるファイアウォール トラバーサル ソリューションを形成するように設計されています。Expressway-C は、企業ネットワークの内部(信頼された側)に配置され、Expressway-E へのセキュアで信頼できる各種の標準規格に準拠した接続手段を提供する役割を果たします。また、その背後にあるすべてのデバイスへのトラバーサル クライアントとしての機能を果たします。このソリューションは、アウトバウンド通信用に開かれた少数のポートにすべてのメディアを多重化することによって、大量のメディア ポートを使用するデバイスの問題を解決します。また、Expressway-C から Expressway-E までのトラバーサル ゾーンに関するキープアライブを送信することによって、社内から社外への認証された信頼できる接続を実現します。また、すべてのインターネット通信に対して一括窓口を提供することで、セキュリティ リスクを最小化します。
SIP、H.323、XMPP などのリアルタイムや準リアルタイムの通信プロトコルでは、ファイアウォールの背後に設置されたデバイスとの通信ニーズは解決されません。このようなプロトコルを使用した典型的な通信には、シグナリングとメディア内にデバイス IP アドレスが含まれており、それぞれが TCP パケットと UDP パケットのペイロードになります。これらのデバイスが、内部的にルーティング可能な同じネットワーク上に存在する場合は、相互に直接通信することができます。TCP パケットのペイロードで伝送されるシグナリング IP アドレスは送信デバイスに戻すルーティングが可能であり、その逆もできます。ただし、送信デバイスがパブリックまたはネットワーク エッジ ファイアウォールの背後の別のネットワーク上に存在する場合は、2 つの問題が発生します。1 つ目の問題は、受信デバイスが、パケットの復号化後に、ペイロードで伝送された内部 IP アドレスに応答することです。この IP アドレスは、通常、ルーティング不可能な RFC 1918 アドレスであり、絶対に返信先に到達しません。2 つ目の問題は、返信先 IP アドレスがルーティング可能であっても、メディア(RTP/UDP)が外部ファイアウォールによってブロックされることです。このことは、Business-to-Business(B2B)コミュニケーションと、モバイル & リモート アクセスの通信の両方に当てはまります。
Expressway-E は DMZ 内のネットワーク エッジに配置されます。これは、標準の相互運用性を維持しながら、SIP、H323、および XMPP に関するシグナリングとメディアの両方のルーティング問題を解決する役割を果たします。Expressway-E は、ネットワーク内部のエンドポイント、デバイス、およびアプリケーション サーバの代わりにメディアとシグナリングを処理するために該当するヘッダーと IP アドレスを変更します。
Cisco Expressway シリーズの標準導入には、Business-to-Business(B2B)コミュニケーション用の少なくとも 1 つの Expressway-C と Expressway-E のペアの展開が必要です。復元力を高めるためには、Expressway-C と Expressway-E の両方をクラスタ内に展開する必要があります。各クラスタでのサーバ数は、同時コール数によって異なります。(詳細については、コラボレーション ソリューション サイジング ガイダンスの章を参照してください)。
しばしば、地理的範囲とスケーリングのために複数のペアの Expressway-C と Expressway-E が展開され、これにより、コラボレーション サービスの複数のインスタンスへのアクセスが可能になります。Unified CM がインターネット上のユニファイド ビジネス コミュニケーション アクセス用の SIP トランク経由で Expressway-C に接続されます。エンタープライズ セキュリティ ポリシーに基づいて、さまざまな展開モデルを実装できます。このマニュアルでは、デュアル ネットワーク インターフェイスを備えた Expressway-E の DMZ 展開を中心に説明します。これは、この展開が最も一般的でセキュアな展開モデルだからです。その他の展開モデルについては、次の URL から入手可能な最新バージョンの『 Cisco Expressway Basic Configuration Deployment Guide 』を参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/expressway-series/products-installation-and-configuration-guides-list.html
Expressway-C と Expressway-E は、ファイアウォール トラバーサル機能を提供します。ファイアウォール トラバーサルは次のように動作します。
1. Expressway-E は企業の DMZ 内に設置されるトラバーサル サーバで、Expressway-C は企業ネットワーク内に設置されるトラバーサル クライアントです。
2. Expressway-C は、セキュアなログイン クレデンシャルを使用して、ファイアウォールを通って Expressway-E 上の特定のポートに至るトラバーサル アウトバウンド接続を開始します。ファイアウォールがほとんどの場合の動作と同様にアウトバウンド接続を許可している場合は、企業のファイアウォールで追加のポートを開く必要はありません。
ポートの詳細については、最新バージョンの『 Unified Communications Mobile and Remote Access via Cisco Expressway Deployment Guide 』を参照してください。このマニュアルには、Business-to-Business(B2B)およびモバイル アクセスとリモート アクセスのシナリオで Expressway によって使用されるすべてのポートが含まれています。このガイドは、次の URL から入手できます。
https://www.cisco.com/c/en/us/support/unified-communications/expressway-series/products-installation-and-configuration-guides-list.html
3. 接続が確立されると、Expressway-C がキープアライブ パケットを定期的に Expressway-E に送信して接続を維持します。
4. Expressway-E が着信コールやその他のコラボレーション サービス要求を受け取ると、着信要求を Expressway-C に発行します。
5. その後で、Expressway-C がその要求を Unified CM またはその他のコラボレーション サービス アプリケーションにルーティングします。
6. 接続が確立され、アプリケーション トラフィック(音声メディアとビデオ メディアを含む)が既存のトラバーサル接続経由で安全にファイアウォールを通過します。
ファイアウォール トラバーサルが機能するためには、Expressway-C 上でトラバーサル クライアント ゾーンを設定し、Expressway-E 上でトラバーサル サーバ ゾーンを設定する必要があります。図 5-8 に、Expressway-E のデュアル インターフェイスの展開シナリオにおけるファイアウォール トラバーサル プロセスをまとめます。
図 5-8 デュアル インターフェイスの展開におけるファイアウォール トラバーサル
デュアルインターフェイス展開シナリオでは、Expressway-E が次の 2 つのファイアウォール間の DMZ 内に配置されます。インターネット ファイアウォールはインターネット向けの NAT サービスを提供し、イントラネット ファイアウォールは企業信頼ネットワークへのアクセスを提供します。
Expressway-E は次の 2 つの LAN インターフェイスを備えています。1 つはインターネット ファイアウォール向け(外部インターフェイスとも呼ばれる)で、もう 1 つはイントラネット ファイアウォール向け(内部インターフェイスとも呼ばれる)です。外部または内部インターフェイスにパケットをルーティングするには、Expressway-E でスタティック ルートを作成します。スタティック ルートを作成する最も簡単な方法は、Expressway-E のデフォルト ゲートウェイを外部の LAN インターフェイスのデフォルト ゲートウェイと同等に設定し、すべての内部ネットワークに対しスタティック ルートを作成することです。このようにして、内部トラフィックは内部インターフェイスに送信され、スタティック ルートで設定されたネットワーク範囲に一致しないすべてのトラフィックがインターネットに送信されます。
外部インターフェイスにパブリック IP アドレスを割り当てる必要はありません。これは、NAT によってアドレスを静的に変換できるためです。この場合は、Expressway-E 自体にパブリック IP アドレスを設定する必要があります。Expressway-E の外部インターフェイスは NAT によって静的に変換できますが、Expressway-E の内部インターフェイスは、Expressway がクラスタ化されていない場合にのみ NAT によって静的に変換できます。Expressway-C のインターフェイスは NAT によって変換できます。
Expressway-C とバックエンド アプリケーション サービス間の Business-to-Business(B2B)コミュニケーション用のインターネットからの接続は、その設定と会社の方針に基づいて暗号化される場合とされない場合があります。このケースでは、企業とリモート両方の Business-to-Business(B2B)パーティが公開証明書を使用した暗号化をサポートしている場合にのみ、通信がエンドツーエンドで暗号化されることに注意してください。これ以外のケースでは、ビデオ コールが暗号化されずに送信されるか、または Expressway-E の設定ポリシーに基づいて廃棄されます。
Business-to-Business(B2B)コミュニケーションには、URI ルーティングの目的でリモート組織のドメインを検索できる機能が必要です。これは、Expressway-E 上で DNS ゾーンを作成することによって実現されます。このゾーンはデフォルト設定で構成する必要があります。デフォルトで SIP と H.323 の両方が設定されます。Expressway-C と Expressway-E は、コールを開始するために使用されたプロトコルを使用しますが、Expressway 上で SIP/H.323 間ゲートウェイ インターワーキングが有効になっている場合は自動的に別のプロトコルを使用しようとします。
Expressway-E の場合、SIP/H.323 間のインターワーキングは [オン(On)] に設定する必要があります。これにより、コールが H.323 コールとして受信された場合に、Expressway-E がそのコールを SIP に接続し、Unified CM への残りのコール レッグにネイティブ SIP を使用できます。同様に、H.323 システムへの発信コールは、Expressway-E に到達して H.323 に接続されるまで SIP コールを維持します。
インターネット経由で Business-to-Business(B2B)コミュニケーションを受信するには、外部 SIP レコードと H.323 DNS レコードが必要です。これらのレコードを使用すれば、他の組織は URI のドメインをそのコール サービスを提供している Expressway-E に解決できます。シスコの検証済みデザインには、Business-to-Business(B2B)コミュニケーション用の SIP レコード、SIPS SRV レコード、および H.323 SRV レコードが含まれています。H.323 SRV レコードは、エンドポイントが登録用のゲートキーパーを探すために使用するもので、Expressway-E には必要ありません。
表 5-2 に、URI のドメインを解決するために使用される DNS SRV レコードを示します。
|
|
|
|
---|---|---|---|
|
|||
|
|||
|
|||
Expressway-E 上での DNS ゾーンの設定方法については、次の URL で入手可能な最新バージョンの『 Cisco Expressway Basic Configuration Deployment Guide 』を参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/expressway-series/products-installation-and-configuration-guides-list.html
発信コールは、Cisco Unified CM で「*」に設定されている SIP ルート パターンを使用します。ローカルの Unified CM クラスタまたは ILS テーブル内に一致が見つからない SIP URI は、ダイヤル プランの章に定義されているルーティング ルール ロジックに従って、この SIP ルート パターンを介して送信されます。ターゲットとして Expressway-C クラスタに対するルート リストを含めるように、この SIP ルート パターンを設定します。
Business-to-Business(B2B)コミュニケーション用の次の 2 つのルールを含めるように Expressway-C を設定します。
Expressway-E で、Business-to-Business(B2B)コミュニケーション用の次の 2 つのルールを設定します。
ユーザが、Unified CM に接続されているエンドポイントから、ある文字列の後に外部ドメインをダイヤルすると、SIP ルート パターンに一致します。Unified CM は Expressway-C にコールを送信し、Expressway-C はそのコールを Expressway-E に送信します。Expressway-E はパブリック DNS で DNS SRV ルックアップを実行します。DNS は SRV レコードを解決し、Expressway-E はコールを未知のリモート エンドに転送できます。
着信コールは、デフォルト ゾーンで Expressway-E によって受信され、上記で指定した検索ルールに基づいて、Expressway-E はコールを Expressway-C に送信し、Expressway-C はそのコールを Cisco Unified CM に送信します。
モデル タイプまたは音声/ビデオ機能に関係なく、Cisco Unified CM に接続されている Cisco エンドポイントはすべて到達可能であることに注意してください。
エンドポイントに関連付けられている SIP URI がない場合は、文字列 < DN >@< domain > を介して到達可能です。< DN > は Cisco Unified CM に設定されているディレクトリ番号で、< domain > は企業の SIP ドメインです。
デバイスに、DN に関連付けられている対応する英数字の SIP URI がある場合、同じデバイスは英数字の SIP URI をダイヤルすることでも到達できます。
IP ベース ダイヤリングは、特に H.323 エンドポイントを使ってダイヤルする場合のほとんどのシナリオで使用されるよく知られた機能です。シスコ コラボレーション アーキテクチャでは、SIP URI を使用するため、IP ベース ダイヤリングは必要ありません。ただし、コールの発着信に IP アドレスしか使用できない他の組織のエンドポイントと対話する場合は、シスコ コラボレーション アーキテクチャで着信コールと発信コールの両方に IP ベース ダイヤリングを使用できます。
アウトバウンド IP ダイヤリングは Expressway-E と Expressway-C ではサポートされますが、Cisco Unified CM では完全なネイティブ サポートはありません。ただし、ここで説明するように、IP ベース ダイヤリングを使用するように Unified CM をセットアップすることができます。
IP アドレス単独でダイヤルする代わりに、Cisco Unified CM 上のユーザは、10.10.10.10@ip のように SIP URI ベースの IP アドレスにダイヤルすることができます。ここで、「@ip」は、リテラルで、「external」、「offsite」、またはその他の意味のある単語に置き換えることができます。
Unified CM は「ip」架空ドメインを Expressway-C にルーティングするように設定された SIP ルート パターンに一致します。Expressway-C はドメイン「@ip」を除外して、そのコールを IP アドレス ダイヤリング用にも設定されている Expressway-E に送信します。
Expressway -E 上の不明な IP アドレス宛てのコールは [直接(Direct)] に設定する必要があります。コール制御が展開されていない場合は IP ベース アドレス ダイヤリングのほとんどが H.323 エンドポイントで設定されるため、Expressway-E は H.323 コールをパブリック IP アドレスにあるエンドポイントに直接送信できます。コールは Expressway-E 上で接続されるまで SIP コールを維持します。
または、架空ドメインを追加する代わりに、ユーザはドットをアスタリスク文字に置き換えることができます。たとえば、10*10*10*10 のようになります。
Unified CM は、!*!*!*! と定義されたルート パターンに一致し、コールを Expressway-C に送信します。Expressway-C は「アスタリスク」文字をドットに置き換えます。この場合、検索ルールは正規表現 (\d\d?\d?)(\*)(\d\d?\d?)(\*)(\d\d?\d?)(\*)(\d\d?\d?) に一致し、置換文字列として \1\.\3\.\5\.\7 を持ちます。
IP ベースの着信コールは、Expressway-E に設定されたフォールバック エイリアスを使用します。インターネット上のユーザが Expressway-E 外部 LAN インターフェイスの IP アドレスにダイヤルすると、Expressway-E がそのコールを受信して、フォールバック エイリアス設定で設定されたエイリアスに送信します。たとえば、フォールバック エイリアスがコールを会議番号 80044123 または会議エイリアス meet@example.com に送信するように設定されている場合は、着信コールはその会議を担当するアプリケーションまたはデバイスに送信されます。
IP アドレスとフォールバック エイリアス間の静的マッピングが制限されている場合は、フォールバック エイリアスを Cisco Unity Connection または Cisco Unified Contact Center Express(UCCX)のパイロット番号に設定できます。この方法では、Unity Connection 自動応答機能または UCCX IVR の機能を使用して、DTMF 経由で、あるいは、Unity Connection でサポート可能な場合は音声認識によって、最終宛先を指定できます。Unity Connection が Expressway-E の IP アドレスにダイヤルする外部エンドポイントの自動応答機能として使用されている場合は、Unity Connection の Unified CM トランク設定で [再ルーティング用コーリング サーチ スペース(Rerouting Calling Search Space)] に設定することを忘れないでください。
Expressway-C と Expressway-E はクラスタで展開することをお勧めします。クラスタごとに最大 6 つの Expressway ノードと最大 N+2 の物理冗長性を設定できます。クラスタ内のすべてのノードがアクティブです。クラスタ設定については、次の URL で入手可能な最新バージョンの『 Cisco Expressway Cluster Creation and Maintenance Deployment Guide 』を参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/expressway-series/products-installation-and-configuration-guides-list.html
Expressway クラスタでは、設定の冗長性が提供されます。クラスタで設定された最初のノードがマスターとなります。設定はマスター内で実行され、自動的に他のノードにレプリケートされます。Expressway クラスタは、コール ライセンス共有と回復力を提供します。すべてのリッチ メディア セッション ライセンスがクラスタ内の全ノードで等しく共有されます。コール ライセンスはノードごとに設定されたライセンスによって供与されます。
仮想マシンとして展開された Expressway-C と Expressway-E は VMware VMotion をサポートします。VMwareVMotion は、物理サーバ間の実行中の仮想マシンのライブ マイグレーションを可能にします。仮想マシンの移動中は、Expressway-C サーバと Expressway-E サーバが、シグナリングのみを処理するとき、または、シグナリングとメディアの両方を処理するときにアクティブ コールを維持します。これにより、Expressway ノードのハイ アベイラビリティだけでなく、Cisco Unified Computing System(UCS)ホスト全体でのコール回復力も提供されます。
次のルールが Expressway クラスタリングに適用されます。
Expressway-C は内部ネットワークに、Expressway-E は DMZ に展開されるため、Expressway-C は、Business-to-Business(B2B)コール用のトラバーサル ゾーンを介して Expressway-E に接続される必要があります。モバイルおよびリモート アクセスには、 Unified Communication トラバーサル ゾーン と呼ばれる別のトラバーサル ゾーンが必要です。トラバーサル サーバ ゾーンとトラバーサル クライアント ゾーンには Expressway-C と Expressway-E のすべてのノードが含まれているため、ノードのいずれかが到達不能になった場合は、代わりにクラスタの別のノードが使用されます。
Expressway-C 上に設定されたトラバーサル クライアント ゾーンには、対応する Expressway-E クラスタのすべてのクラスタ ノードの完全修飾ドメイン名を含める必要があります。同様に、トラバーサル サーバ ゾーンはすべての Expressway-C クラスタ ノードに接続する必要があります。これは、Expressway-C 証明書のサブジェクトの別名に Expressway-C クラスタ ノードの FQDN を含め、TLS 検証サブジェクト名を Expressway-C クラスタの FQDN と同一に設定することによって実現されます。これにより、トラバーサル ゾーン全体にクラスタ ノードのメッシュ構成が形成され、最後のクラスタ ノードが使用不能になるまでトラバーサル ゾーンのハイ アベイラビリティが維持されます。
Expressway-C はネイバー ゾーン経由で Unified CM に接続して、Business-to-Business(B2B)の着信コールと発信コールをルーティングします。Unified CM は Expressway-C へのトランキングも行います。ハイ アベイラビリティを維持するために、各 Expressway-C クラスタ ノードの完全修飾ドメイン名を Unified CM 上のトランク設定に列挙する必要があります。Unified CM がクラスタ化されている場合は、クラスタの各メンバーの完全修飾ドメイン名(FQDN)を Expressway-C のネイバー ゾーン プロファイルにリストする必要があります。
ここでも、メッシュ状のトランク構成が形成されます。Unified CM は、SIP Options Ping 経由でトランク設定内のノードのステータスをチェックします。あるノードが使用できなくなると、Unified CM はそのノードを運用停止にして、そのノードに対するコールをルーティングしなくなります。Expressway-C も SIP OPTIONS Ping 経由で Unified CM からのトランクのステータスをチェックします。コールは、アクティブかつ使用可能として示されているノードにのみルーティングされます。これにより、トランク設定の両側にハイ アベイラビリティが提供されます。
DNS SRV レコードは、インバウンド Business-to-Business(B2B)トラフィックに対する Expressway-E の可用性を高めることができます。ハイ アベイラビリティを維持するためには、クラスタ内のすべてのノードを SRV レコード内に同じ優先度と重要度でリストする必要があります。これにより、すべてのノードを DNS クエリで返すことができます。DNS SRV レコードは、クライアントがルックアップに費やす時間を最小にするために役立ちます。これは、DNS 応答に SRV レコード内に列挙されたすべてのノードを含めることができるためです。通常は、遠端サーバまたは遠端エンドポイントが DNS 応答をキャッシュし、応答が受信されるまで DNS クエリで返されたすべてのノードを試します。これにより、コールが成功する確率が高まります。
さらに、Expressway クラスタは、クラスタ全体でのリッチ メディア ライセンス共有をサポートします。クラスタからノードが削除された場合は、そのコール ライセンスの共有が次の 2 週間だけ継続されます。
どの Expressway も、その物理能力を上回るライセンスを保持することはできても、その物理能力を上回る Rich Media ライセンスを処理することはできません。
Expressway-C と Expressway-E 上のセキュリティは、ネットワーク レベルとアプリケーション レベルでさらに分割することができます。ネットワーク レベルのセキュリティにはファイアウォール ルールや侵入からの保護などの機能が含まれるのに対して、アプリケーション レベルのセキュリティには認可、認証、および暗号化が含まれます。
Expressway-C と Expressway-E のネットワーク レベル保護は、2 つの主なコンポーネント(ファイアウォール ルールと侵入防御)で構成されます。ファイアウォール ルールは次の機能を有効にします。
悪意のあるトラフィックを検出およびブロックし、辞書ベースでの不正ログイン攻撃から Expressway を保護するためには、自動侵入保護機能を使用する必要があります。自動化された侵入保護は、システム ログ ファイルを解析して、SIP、SSH、Web/HTTPS などの特定のサービス カテゴリへのアクセスの連続的な失敗を検出することによって機能します。指定された時間内の失敗回数が設定されたしきい値を超えた場合は、送信元ホスト IP アドレス(侵入者)と宛先ポートが、指定された期間ブロックされます。その期間が過ぎると、自動的にホスト アドレスのブロックが解除されるため、一時的に設定が間違っていた正規のホストがロックアウトされなくなります。
アプリケーション レベルのセキュリティは、次のように分割できます。
Business-to-Business(B2B)コミュニケーションの保護には、認証、暗号化、および認可が含まれます。Business-to-Business(B2B)コミュニケーションでは、デフォルトで、認証されたトラバーサル リンクが使用されます。トラバーサル リンクは、Expressway-C と Expressway-E の間で相互に認証された Transport Layer Security(MTLS)接続によって確認された公開キー インフラストラクチャ(PKI)の利用による恩恵を受けることもできます。Business-to-Business(B2B)トラバーサル リンクがモバイル & リモート アクセスと同じ Expressway-C および Expressway-E インフラストラクチャに展開される場合は、トラバーサル ゾーンが Expressway-C および Expressway-E のクラスタ ノードの FQDN を使用することを確認してください。これによって、トラバーサル接続用の証明書信頼に対して提供された証明書を検証するために各サーバの証明書を容易に使用できるようになります。
シグナリングとメディアの暗号化は Business-to-Business(B2B)コールにとって重要ですが、コールの受信機能を限定または制限しないように慎重に展開する必要があります。通信先の旧式の SIP または H.323 システムの中には、シグナリングまたはメディアの暗号化をサポートしていないものが多数含まれています。
ゾーン設定に基づいて、暗号化ポリシーを強制([暗号化を強制(force encrypted)])、推奨([ベスト エフォート(best effort)])、非許可([非暗号化を強制(force unencrypted)])に設定するか、またはエンドポイントの判断に任せる([自動(auto)])ようにすることができます。
[暗号化を強制(force encrypted)] がターゲット ゾーンで設定され、Expressway がそのリモート ゾーンでエンドポイントのコールを受信すると、Expressway は暗号化されたコールをセットアップします。リモート パーティが暗号化されていないコールのみを受け入れる場合、コールはドロップされます。発信側のエンドポイントが TCP を使用して暗号化されていないメディアを送信している場合に、[暗号化を強制(force encrypted)] がターゲット ゾーンに設定されると、Expressway はコール レッグを終了し、TLS および暗号化を使用して宛先に別のコール レッグをセットアップします。
Expressway は SRTP に対して RTP を実行するときに、Business-to-Business(B2B)コールに Back-to-Back User Agent(B2BUA)を使用します。B2BUA はシグナリングおよびメディアの両方を終了し、宛先への新しいコール レッグをセットアップします。B2BUA は、メディア暗号化モードが [自動(auto)] 以外に設定された場合に使用されます。SIP TLS と TCP のインターワーキングに B2BUA が必要となるのは、メディアが暗号化されて送信される場合だけです。そうでなければ、B2BUA は必要ありません。Expressway-E に影響する次のシナリオの場合にのみ、例外が発生します。インバウンド ゾーンとアウトバウンド ゾーンが同じ暗号化メディア タイプに設定され、これらのゾーンの 1 つがトラバーサル サーバ ゾーンである場合、Expressway-E は、関連付けられているトラバーサル クライアント ゾーンの値をチェックします。これら 3 つのゾーンがすべて同じ値に設定されている場合、Expressway-E は B2BUA を使用しません。この場合、B2BUA は Expressway-C でのみ使用されます。[ベスト エフォート(best effort)] に設定されている場合、Expressway は暗号化されたコールをセットアップできなければ、暗号化されていないコールにフォールバックします。
要件に応じて、さまざまなメディア暗号化ポリシーを設定できます。社内の適用ポリシーが設定されていない場合は、メディア暗号化モードとして [自動(auto)] が指定されているゾーンをセットアップすることを推奨します。[自動(auto)] に設定すると、エンドポイントに暗号化の決定が委託され、Expressway は RTP/SRTP 間の変換を実行しません。
暗号化ポリシーが Expressway で適用されると、次のシナリオに示すように、コールは B2BUA の関与によって多くのコール レッグに分けられます。
たとえば、Unified CM が混在モードで使用されていて、発信エンドポイントが暗号化に対応するように設定されているとします。このシナリオでは、Unified CM 上のセキュアなエンドポイントがインターネット上の非暗号化エンドポイントを呼び出します。この呼び出しは、次のコール レッグからなります。
1. Unified CM エンドポイント~ Expressway-C B2BUA、暗号化される
2. Expressway-C B2BUA ~ Expressway-E B2BUA、暗号化される
3. Expressway-E B2BUA ~インターネット、未知のリモート エッジまたは最終宛先まで、暗号化されない
4. リモート エッジ~最終宛先、着信側パートナーの設定に応じて暗号化されるまたは暗号化されない
コール レッグ 1 ~ 3 が暗号化されると、ロック アイコンが正しく表示されます。これらのレッグの 1 つが暗号化されていない場合、ロック アイコンは表示されません。最後のコール レッグは他社の制御下にあり、ロック ステータスには影響しないことに注意してください。
各企業は他の企業のエッジまでの暗号化を制御しており、エンドポイントはエンドポイントからリモート エッジへの暗号化されたコールを確立することができます。[暗号化を強制(force encrypted)] が Expressway で設定されている場合、暗号化ポリシーはインターネット上のメディアを保護できますが、コールがリモート エッジに達すると、コールが着信側エンドポイントに送信される前にエッジ レベルで復号化される可能性があります。
インターネット上の望ましくないユーザからの合法的なコール試行、スパム コール、SIP または H.323 スキャンをブロックするために、呼処理言語(CPL)ルールを Expressway-E で使用することができます。CPL ルールはインターネットからのコール試行にのみ適用できます。
これを行うためには、トラバーサル クライアント ゾーンからのトラフィックを [認証(authenticated)] に設定し、インターネットからのトラフィックを [未認証(non-authenticated)] に設定します。CPL ルールは、認証されていないトラフィックのみに適用でき、内部ネットワークまたはインターネット上の信頼されたネイバーからのトラフィックの検査は回避されます。図 5-9 は、これについて説明しています。
CPL ルールはトップダウン方式を使用して処理されます。次の 2 つのポリシーのセットを作成できます。
許可ベースのポリシーは、正規表現(regex)を CPL に適用して、コールが内部的に設定された数字の範囲または英数字の URI 形式に一致する場合にのみ、そのコールを許可します。最後の CPL ルールはすべてのコールをブロックします。
拒否ベースのポリシーは、ゲートウェイやボイスメールなどの特定のサービスに対するコールを拒否する一方で、ドメインが企業ドメインに一致する場合に残りのすべてを許可します。すべてのコールをブロックするデフォルトの CPL ルールは、最後のルールとして設定されます。
拒否ベースのポリシーの例として、コールが範囲 80XXXXXX にある一連のデバイスのみに許可され、ゲートウェイ アクセスや外部のインターネット宛先からの他のサービス(ここでは 0 と 9 で示す)は禁止される企業を想定します。この場合、ルールは 表 5-3 に示すように設定できます。
|
|
|
---|---|---|
さらに、発信側 ID に基づいてコールを拒否することも可能です。電気通信プロバイダーが発信者番号を確保する PSTN とは異なり、インターネットは自由であり、誰もユーザのアイデンティティをチェックしていません。したがって、発信側エイリアスに企業のドメインや Expressway-E の IP アドレスが含まれる場合は、Business-to-Business(B2B)の着信コールを拒否できます。
表 5-4 に記載する例は Cisco Expressway リリース 8.9 をベースにしています。
|
|
|
|
---|---|---|---|
表 5-4 の 10.10.10.10 は、Expressway-E のパブリック アドレスを表します。これらのルールは、前のリストの「許可」ルール直前に追加できます。このようにすると、インターネットからのコールに企業のドメインや IP アドレスが含まれる場合、そのコールは拒否されるため、個人情報盗難が緩和されることになります。
デフォルト ゾーンが Business-to-Business(B2B)着信コールのターゲットであることから、デフォルト ゾーンの認証ポリシーは「クレデンシャルをチェックしない」ように設定する必要があります。このように設定すると、Business-to-Business(B2B)コールは認証されていないと見なされるため、ルールに照らし合わせてチェックされることになります。デフォルト ゾーンの認証ポリシーが「認証済みとして扱う」ように設定されている場合、トラバーサル ゾーンから発信された内部トラフィックは、このチェックをバイパスします(図 5-9 を参照)。
複数のインターネット エッジが展開されている場合は、コラボレーション トラフィックを最も近いインターネット エッジに送信するためのルーティング ルールを正しく設定することが重要です。
Business-to-Business(B2B)コミュニケーションの拡張性は、複数の Expressway-C クラスタと Expressway-E クラスタを同じ物理位置にまたは地理的に分散して追加することによって解決できます。複数の Expressway-C と Expressway-E のペアが展開されている場合は、Unified CM が発信コールを発信側エンドポイントに最も近いエッジ サーバに転送できるため、内部 WAN トラフィックが最低限に抑えられます。大規模展開では、モバイル & リモート アクセスから分離した Expressway-C と Expressway-E のペア上で Business-to-Business(B2B)コミュニケーションをホストした方が適切な場合があります。これにより、サーバ リソースを外部インターネット通信専用にすることができます。
複数のインターネット エッジが展開されている場合は、それらの間の負荷分散方法を理解しておくことが重要です。インターネット エッジが同じデータセンターまたは同じエリアに展開されている場合は、DNS SRV レベルでロード バランシングを実行できます。たとえば、企業ネットワークに Business-to-Business(B2B)コミュニケーション用の 3 つのインターネット エッジが含まれており、それぞれが 2 つの Expressway-E ノードと Expressway-C ノードのクラスタで構成されている場合は、_sips._tcp.example.com レコードと _sip._tcp.example.com レコードに 6 つすべての Expressway-E レコードが同じ優先度と重要度で追加されます。これにより、登録とコールがさまざまな Expressway-E クラスタと Expressway-C クラスタに均等に分配されます。
ただし、Expressway クラスタが地理的地域全体に展開されている場合は、エンドポイントが確実に最も近い Expressway-E クラスタを使用するようにするため、DNS SRV の優先度と重要度のレコードに加えて何らかのインテリジェント メカニズムが必要になります。たとえば、ある企業が 2 つの Expressway クラスタを使用しており、1 つは米国(US)に、もう 1 つはヨーロッパ(EMEA)に設置されている場合、US に住んでいるユーザは US 内の Expressway-E クラスタに転送され、ヨーロッパに住んでいるユーザはヨーロッパ内の Expressway-E クラスタに転送されるのが理想的です。これは、GeoDNS サービスを実装することによって容易に実現できます。GeoDNS サービスはコスト効率が高く、設定が簡単です。GeoDNS を使用すれば、位置(IP アドレス ルーティング)や最小遅延などの複数のポリシーに基づいてトラフィックをルーティングできます。
次に、GeoDNS サービス用の DNS を設定する例を示します。
このシナリオでは、2 つのインターネット エッジ Expressway クラスタを US とヨーロッパに 1 つずつ展開し、それぞれが 2 つの Expressway-C サーバと Expressway-E サーバで構成されます。発信側エンドポイントとヨーロッパ エッジ間で測定された遅延がエンドポイントと US エッジ間の遅延を下回っている場合、またはエンドポイントの IP アドレスが US の範囲に一致する場合、エンドポイントは設定されたポリシー(遅延または IP アドレス)に基づいてヨーロッパ エッジに転送されて登録されます。
一部の GeoDNS プロバイダーは、SRV レコードで GeoDNS サービスをサポートしていますが、多くのプロバイダーは CNAME または A レコードに対してのみ GeoDNS を許可しています。シンプルな構成と容易なトラブルシューティングを可能にするために、SRV レコードに GeoDNS サービスを実装することを推奨します。SRV レコードへの GeoDNS 設定を次の例に示します。
発信ユーザが米国にいる場合、コールは米国に送信されますが、米国のデータセンターが停止している場合、コールは EMEA に送信されます。この設定では、図 5-10 に示すように地理的冗長性が考慮されます。
CNAME レコードのみに対し GeoDNS サービスを指定し、SRV レコードに対しサービスを指定しないことを GeoDNS プロバイダーが許可している場合で、CNAME が GeoDNS サービスでサポートされている場合にのみ GeoDNS を設定する方法を次の例で示します。
このシナリオに従うと、DNS SRV レコードは CNAME レコードに解決されて、その CNAME レコードは A レコードに解決されます。CNAME レコードには地理的な場所を割り当てることができます。一例として、米国内に Expressway-E クラスタがあり、EMEA 内に別の Expressway-E クラスタがあるとします。SIP TLS の SRV レコード _sips._tcp.example.com や _sip._tcp.example.com は、Business-to-Business(B2B)コール用に設定されています。このレコードは CNAME レコード alias1.example.com に解決されます。
GeoDNS 設定に基づき、CNAME レコードには、そのレコードが有効な地域を識別するラベルが適用されます。この例では、CNAME は、優先度が高い(この例では 10)米国の A レコードと EMEA の別の A レコードに解決されます。これらの A レコードが、両方の地域にあるクラスタの最初のピアに対応します。
2 番目の CNAME レコードは、次に優先度が高い、米国および EMEA クラスタのピアに解決されます。このプロセスは、クラスタ内のすべてのピアが含まれるまで繰り返す必要があります。
地理的な冗長性を持たせるために、バックアップ CNAME エイリアスを作成する必要があります。図 5-11 の例では、 backup-alias1.example.com が米国ユーザ用に最初の EMEA Expressway ピアに、EMEA ユーザ用に最初の US Expressway ピアに解決されることによって、両方の地域で地理的な冗長性が生まれます。バックアップ エイリアスのプロセスも、クラスタのすべてのピアが含まれるまで繰り返す必要があります。DSN SRV は低い優先度(この例では 20)に設定されているため、これらのバックアップ レコードが使用されるのは、最初のレコードが応答しない場合のみです。
図 5-11 に、CNAME レコードに適用される GeoDNS サービスの DNS レコード構造を示します。
図 5-11 地理的な冗長性を持つ CNAME レコードの GeoDNS レコード構造
GeoDNS 方式を採用することが推奨されますが、GeoDNS を展開できない場合があります。たとえば、DNS レコードが GeoDNS サービスを提供していないサービス プロバイダーによって管理されている場合、または複数のエッジがエッジ間で選択する GeoDNS の容量より少ない地域で展開される場合などです。たとえば、GeoDNS は発信側エンドポイントの場所がカリフォルニアにあるかペンシルバニアにあるかを識別することはできても、発信側ロケーション エンドポイントがサンノゼにあるかサンディエゴにあるかを識別することはできない場合があります。したがって、2 つの Expressway クラスタがサンノゼとサンディエゴにある場合、GeoDNS は使用できないことがあります。
別のソリューションとしては、宛先のエンドポイントまたはデバイスに最も近いエッジを返すように設計します。この場合は、宛先エンドポイントの位置を検索または確認して、該当するエッジを返す必要があります。このソリューションのメリットは、最短の内部パスをエンドポイントに提供することによって顧客ネットワーク上の帯域幅の使用が最小限に抑えられることです。
このシナリオでは、Business-to-Business(B2B)SRV レコードはすべての Expressway サーバで同じ優先度と重要度で設定されます。
たとえば、EMEA 内の 2 つの Expressway-C クラスタと Expressway-E クラスタと、APJC 内の別の 2 つの Expressway-C クラスタと Expressway-E クラスタについて考えます。EMEA 内の Expressway-C トランク上の Unified CM インバウンド コーリング サーチ スペースには、EMEA 電話機のパーティションは含まれますが、APJC 電話機のパーティションは含まれません。同様に、APJC 内の Expressway-C トランク上のインバウンド コーリング サーチ スペースには、APJC 電話機のパーティションは含まれますが、EMEA 電話機のパーティションは含まれません。EMEA 内のインターネット上のユーザが APJC にある企業エンドポイントにコールした場合は、そのコールが EMEA または APJC の Expressway クラスタに送信されます。
この例では、コールが EMEA Expressway-E クラスタに送信されると仮定します。EMEA Expressway-E と Expressway-C はそのコールを宛先に送信しようとしますが、Expressway-C トランクのインバウンド コーリング サーチ スペースがそのコールをブロックします。次に EMEA Expressway-E はそのコールを APJC Expressway E に転送します。こうして、コールが宛先に配信されます。これは、APJC Expressway-C のインバウンド コーリング サーチ スペースに APJC エンドポイントのパーティションが含まれているためです。
EMEA 内の Expressway-E がシグナリングとメディアのパスからそれ自体を削除できるようにするには、Expressway-E EMEA クラスタ上に TCP/TLS 変換または RTP/SRTP 変換が確実に存在しないようにし、すべての Expressway-C と Expressway-E ノードでコール シグナリング最適化パラメータを確実に [オン(On)] に設定することが重要です。
これは確定的プロセスではないため、Expressway エッジが 3 つ以上の場合は、検索メカニズムに時間がかかりすぎることがあります。したがって、この設定は Expressway エッジが 2 つ以下の場合にお勧めします。3 つ以上のエッジが必要な場合は、Directory Expressway アーキテクチャを導入することを推奨します。Directory Expressway アーキテクチャについては、このマニュアルでは説明しません。
図 5-12 に、宛先エンドポイントに最も近いエッジの選択を可能にする Expressway エッジ設計を示します。
図 5-12 宛先に最も近い Expressway クラスタの選択
このアーキテクチャは、3 つ以上のサイトに拡張でき、Directory Expressway と呼ばれる中央の Expressway ノードが必要です。Directory Expressway は、異なる地域の Expressway 間でトランジット ノードとして機能する Expressway です。Directory Expressway アーキテクチャについては現在、このマニュアルでは説明していません。
発信コールは発信側のエンドポイントに最も近い Expressway-C に転送する必要があります。これは、コーリング サーチ スペースやパーティションなどの Cisco Unified CM メカニズムを使用して実現できます。図 5-13 に、Unified CM の設定を示します。
図 5-13 最も近い Expressway-C クラスタに発信コールを転送し、最も近いクラスタが使用できない場合にバックアップ クラスタを使用する Unified CM の設定
Unified CM ローカル ルート グループ機能は、複数のサイトが複数の Expressway-C クラスタにアクセスする場合にこのソリューションのスケーリングに役立ちます。このメカニズムは、ISDN ゲートウェイおよび Cisco Unified Border Element にも適用されます。設定の詳細は、Cisco Unified Border Element や音声ゲートウェイにも当てはまるため、次の 2 つのセクションで説明します。
ここでは、ゲートウェイに関する次のベスト プラクティスについて取り上げます。
ゲートウェイを介して Cisco Unified Communications ネットワークを PSTN に接続するには、停電、インピーダンスの不整合、および遅延などによるエコーや信号の減衰から生じる、メディア品質問題に適切に対処する必要があります。このため、予期されるすべての音声パスに信号損失の状況を詳細に提供する Network Transmission Loss Plan(NTLP)を確立する必要があります。このプランを使用して、最適な声の大きさと効果的なエコー キャンセレーションを得るために信号の強さを調整する必要があるロケーションを識別できます。すべての通信事業者が同じ損失プランを使用するわけではないこと、また、セルラー ネットワークの存在が NTLP の作成をさらに複雑にすることに注意してください。このような NTLP を作成する前に、ゲートウェイで入力ゲインや出力衰退を調整することは推奨できません。詳細については、次の Web サイトで入手可能な『 Echo Analysis for Voice Over IP 』を参照してください。
https://www.cisco.com/en/US/docs/ios/solutions_docs/voip_solutions/EA_ISD.pdf
PSTN からの着信コールをルーティングするには、次のいずれかの方法を使用します。
(注) 外部のビデオ エンドポイントは、IVR プロンプトに着信側の内線番号を入力するために、DTMF をサポートしている必要があります。
ユーザは、ビデオ機能が有効になっている 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 Gateway 8321 および 3241、Cisco TelePresence Serial Gateway 8330 および 3340 にはすべて、番号操作の機能があります。これらのビデオ ゲートウェイには、複数のダイヤル プラン ルールを設定できます。これらのルールは、発信番号および/または着信番号に基づいて照合され、IP から PSTN または PSTN から IP の方向のいずれかで機能します。着信コールが設定されたダイヤル プラン ルールと一致すると、ISDN または Serial ゲートウェイは次のいずれかの処理を実行できます。
アクションがある番号へのコールである場合、元の着信番号またはその一部を、コールする新しい番号に使用できます。
https://www.cisco.com/en/US/products/ps11448/tsd_products_support_series_home.html
https://www.cisco.com/en/US/products/ps11605/tsd_products_support_series_home.html
発信コールを PSTN へルーティングするには、次のいずれかの方法を使用します。
特定のプレフィックスを持つコールが PSTN への ISDN 接続で特定の最大消費帯域に制限されるように、Cisco TelePresence ISDN Gateway のダイヤル プラン ルールを設定できます。これは、1 つのコールが PRI リンク全体を独占できないようにする際に便利です。ゲートウェイにサービス プレフィックスを設定するときは、次のいずれかの最大速度を選択できます。
IP エンドポイントから PSTN へ向かうコールは、ゲートウェイがそのコールにどのサービスを使用するかを決定できるように、着信番号の先頭にサービス プレフィックスを含めることができます。オプションとして、番号の先頭にサービス プレフィックスを含んでいないコールに使用する、デフォルト プレフィックスを設定できます。この方法は、非常に複雑になる可能性があります。ユーザは、求めるコール速度を得るためにダイヤルすべきプレフィックスを覚えておく必要があるからです。また、管理者は、Unified CM で複数の(速度ごとに 1 つずつ)ルート パターンを設定する必要があります。
(注) Cisco TelePresence ISDN Gateway の 2 つのグローバル設定を使用して、着信および発信 ISDN コールの帯域幅の最小値または最大値を設定できます。ダイヤル プランによって、これよりも大きい最大帯域幅に上書きすることはできません。ただし、ダイヤル プランによって、特定のコールに対し、より小さい帯域幅を強制することはできます。
IP ネットワークにコールを処理できるだけの帯域幅がない場合、Unified CM はコール アドミッション制御メカニズムを使用して、コールの処理方法を決定します。Unified CM は設定に従って、次のいずれかの処理を実行します。
Retry Video Call as Audio オプションは、終端(着信側)デバイスでのみ有効です。そのため、発信側デバイスでは宛先ごとに異なるオプション(再試行または AAR)を使用できる柔軟性があります。
帯域幅の制限が原因でビデオ コールが失敗した場合、自動代替ルーティング(AAR)が有効であれば、Unified CM は失敗したコールをビデオ コールとして AAR の宛先に再ルーティングしようとします。AAR が有効でない場合、失敗したコールによって、発信者にビジー トーンとエラー メッセージが送信されます(図 5-14 を参照)。
音声コールまたはビデオ コールに 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-5 に、さまざまなデバイス タイプで AAR を使用するのが適切なシナリオのリストを示します。
|
|
|
|
---|---|---|---|
|
ビデオ対応デバイスにコールするときでも、発信元デバイスが音声専用なので、コールを音声ゲートウェイにルーティングするように 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 を実行するためのローカル ゲートウェイ リソースと帯域幅は、もっと手ごろな価格で設定しやすいものになります。
Cisco ゲートウェイ全体に対する FAX とモデムのサポートについては、次のマニュアルを参照してください。
https://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/9x/gateways.html
https://www.cisco.com/en/US/docs/ios-xml/ios/voice/fax/configuration/15-mt/vf-15-mt-book.html