Cisco Unified Communications システム リリース 9.x SRND
Cisco Unified CM トランク
Cisco Unified CM トランク
発行日;2013/04/24 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 38MB) | フィードバック

目次

Cisco Unified CM トランク

この章の新規情報

UnifiedCM トランク ソリューション アーキテクチャ

SIP トランクおよび H.323 トランクの比較

SIP トランクの概要

配置に関する一般的な考慮事項

SIP トランクの機能と操作

SIP トランクで使用できる [Run on All Active UnifiedCM Nodes]

最大 16 の SIP トランク宛先 IP アドレス

SIP OPTIONS ping

UnifiedCM SIP トランクでの SIP アーリー オファー サポート

QSIG over SIP トランク

SIP トランク メッセージの正規化および透過性

すべてのアクティブな UnifiedCM ノードでのルート リストの実行

DNS を使用する SIP トランク

SIP トランクのハイ アベイラビリティ

発信元 SIP トランク コールに対する複数の送信元 UnifiedCM サーバ

SIP トランクごとの複数の宛先 IP アドレス

[Run on All Active UnifiedCM Nodes] を使用するときの設計の考慮事項

ルート リストとおよびルート グループを使用する複数の SIP トランク

SIP OPTIONS ping

SIP トランクのロード バランシング

単一の SIP トランク上の発信

複数の SIP トランク上の発信

SIP OPTIONS ping

SIP ディレイド オファーおよびアーリー オファー

メディア ターミネーション ポイント

DTMF 転送

SIP Trunk Transport Protocol

安全な SIP トランク

メディア暗号化

シグナリング暗号化

発呼側番号の変換および SIP トランク

SIP トランク サービス タイプ

SIP トランクの設計上の考慮事項

SIP クラスタ間トランクに関する考慮事項

SIP クラスタ間トランクによる標準の UnifiedCM Group の使用

SIP クラスタ間トランクでの [Run on All Active UnifiedCM Nodes] の使用

SIP クラスタ間トランクによる標準の UnifiedCM Group および [Run on All Active UnifiedCM Nodes] の使用

マルチクラスタ配置のトランクの種類と機能に関する推奨事項

すべて UnifiedCM8.5 以降のリリースを実行する複数のクラスタ

UnifiedCM8.5 以前のリリースを実行するマルチクラスタ

WAN を介したクラスタリングに関するトランク設計の考慮事項

リーフ クラスタ トランクがある WAN を介したクラスタリングに関する設計ガイドライン

UnifiedCM Session Management Edition クラスタ トランクがある WAN を介したクラスタリングに関する設計ガイドライン

その他の SIP トランク配置に関する考慮事項

H.323 トランクの概要

一般的な H.323 クラスタ間トランク配置に関する考慮事項

H.323 トランクの基本的な操作

H.323 トランク タイプ

クラスタ間トランク(非ゲートキーパー制御)

クラスタ間トランク(ゲートキーパー制御)

H.225 トランク(ゲートキーパー制御)

ゲートキーパー制御トランクのハイ アベイラビリティ

H.323 ゲートキーパー制御トランク上の発信のロード バランシング

H.323 発信 Fast Start コール接続

メディア ターミネーション ポイントを使用する H.323 トランク

DTMF 転送

H.323 トランク トランスポート プロトコル

安全な H.323 トランク

UnifiedCM における H.323 の動作

その他の H.323 トランクの設計上の考慮事項

一般的な SIP および H.323 トランク設計の考慮事項

UnifiedCM トランク上の確定的な発信ロード バランシング

IP トランク上でのコーデック選択

受信オファーのオーディオ コーデック プリファレンスの受け入れ

Cisco Unified CM と Cisco Unified Border Element SIP トランクのコーデック プリファレンス

その他の MTP の使用

Cisco UnifiedCM トランクおよび緊急サービス

UnifiedCM IP トランクのキャパシティ プランニング

サービス プロバイダー ネットワークに対する IP PSTN および IP トランク

Cisco Unified Border Element

トランクの集約プラットフォーム

UnifiedCM Session Management Edition

Cisco Unified SIP Proxy

トランク IP-PSTN 接続モデル

Cisco Unified CM トランク

トランクとは、Cisco Unified Communications Manager(Unified CM)における通信チャネルであり、Unified CM はトランクを使用することによって他のサーバと接続できます。1 つ以上のトランクを使用して、音声コール、ビデオ コール、および暗号化されたコールの送受信やリアルタイム イベント情報の交換など、Unified CM から呼制御サーバおよびその他の外部サーバとのさまざまな通信を行うことができます。

トランクは、Cisco Unified Communications 配置における重要かつ不可欠な部分であるため、利用可能なトランクの種類、それらの機能、および復元性、容量、ロード バランシングなどの設計と配置上の考慮事項について理解することが重要となります。

Unified CM で設定できる基本的なトランクには、次の 2 種類があります。

SIP トランクと H.323 トランク。いずれも、外部通信に使用できます。

クラスタ間トランク(ICT)。

この章では、これらのトランクの一般的な機能および特徴について説明します。Unified CM トランクの特定用途の詳細については、このマニュアルのその他の関連する章を参照してください。

この章では、次のトピックについて説明します。

「SIP トランクおよび H.323 トランクの比較」

「SIP トランクの概要」

「H.323 トランクの概要」

「一般的な SIP および H.323 トランク設計の考慮事項」

「サービス プロバイダー ネットワークに対する IP PSTN および IP トランク」

「トランクの集約プラットフォーム」

Unified CM トランクの用途の詳細については、次に示す章の各項を参照してください。

「Unified Communications の配置モデル」

「メディア リソース」

「コール アドミッション制御」

「IP ビデオ テレフォニー」

「Cisco IM and Presence」

この章の新規情報

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

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

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

Unified CM Session Management Edition クラスタ トランクがある WAN 上のクラスタリング

「Unified CM Session Management Edition クラスタ トランクがある WAN を介したクラスタリングに関する設計ガイドライン」

2012 年 8 月 31 日

オーディオ コーデック プリファレンス リスト

「オーディオ コーデック プリファレンス(受信オファーのオーディオ コーデック プリファレンス受け入れ)」

「受信オファーのオーディオ コーデック プリファレンスの受け入れ」

2012 年 6 月 28 日

正規化および透過性スクリプト

「Unified CM の正規化および透過性スクリプト」

2012 年 6 月 28 日

Cisco Unified Communications システム Release 9.0 向けの、その他の小規模な更新

この章の各項で説明

2012 年 6 月 28 日

Unified CM トランク ソリューション アーキテクチャ

Unified CM では、IP トランクのメカニズムを使用して、Unified Communications ソリューションの他のコンポーネントとコール関連情報を交換します。この点においてトランクは重要であるため、プロトコル、期待される機能およびサービス、パフォーマンス要件などを適切に考慮して IP トランクのシステム アーキテクチャを開発することが重要です。

図 14-1 に、システムの接続性の観点から IP トランクの役割を示します。この図には、Unified CM クラスタからのすべての接続が示されているわけではありません。

図 14-1 IP トランクによって提供される Unified CM への接続

 

コールは、ダイヤル プランでの定義に従って、ルート パターン コンストラクトを使用してトランクに転送されます。ルート パターンでは、直接トランクを使用することも、ルート リストを通してトランクを使用することもできます。ルート リストが使用される場合、そのルート リストは、それぞれが 1 つ以上のトランクを含む 1 つ以上のルート グループから構成されます。ルート グループ内の個別のトランクは、トップダウン的に選択されるように設定することも、循環的に選択されるように設定することもできます。発信コールでは、ルート パターンを使用して、このように関連付けられたトランクの 1 つが Unified CM によって選択されます。Unified CM では、着信コールを受け付ける前に、コールの発信元のリモート アドレスにトランクが定義されているかどうかが確認されます。

SIP トランクおよび H.323 トランクの比較

Cisco Unified CM トランク接続は、SIP と H.323 の両方のトランクをサポートしています。多くの場合、SIP または H.323 のいずれを使用するかは、各プロトコルで提供される固有な機能により異なります。また、お客様の好みや、異なるベンダーの製品間で提供される相互運用性におけるプロトコルの成熟度および品質など、トランク プロトコルの選択に影響を与える外部的要素もたくさんあります。

シスコ デバイス間のトランク接続の場合、H.323 または SIP のいずれを使用するかは、比較的、簡単に決定できます。他のベンダーの製品およびサービス プロバイダー ネットワークとのトランク接続の場合、お客様がどの機能を必要としているか、および 2 つのベンダーの製品間での相互運用性の範囲を理解することが重要です。

表 14-2 に、Unified CM クラスタ間での SIP および H.323 トランクを介して提供される機能の一部についての比較を示します。

表 14-2 Cisco Unified CM トランクでの SIP および H.323 機能の比較

機能
SIP
QSIG over SIP
H.323
H.323 を介した QSIG

発呼回線(番号)ID 表示

Yes

Yes

Yes

Yes

発呼回線(番号)ID 表示禁止

Yes

Yes

Yes

Yes

発信者名 ID 表示

Yes

Yes

Yes

Yes

発信者名 ID 表示禁止

Yes

Yes

Yes

Yes

接続回線(番号)ID 表示

Yes

Yes

Yes

Yes

接続回線(番号)ID 表示禁止

Yes

Yes

Yes

Yes

接続者名 ID 表示

Yes

Yes

Yes

Yes

接続者名 ID 表示禁止

Yes

Yes

Yes

Yes

呼び出し表示(Alerting Name)

Yes

Yes

No

Yes

転送(ブラインドまたは在席)

Yes/Yes

Yes/Yes

Yes/Yes

Yes/Yes

すべてのコールの転送

Yes

Yes

Yes

Yes

話中転送

Yes

Yes

Yes

Yes

自動転送(無応答)

Yes

Yes

Yes

Yes

呼完了(ビジーサブスクライバ)

No

Yes

No

Yes

呼完了(無応答)

No

Yes

No

Yes

サブスクライブ/通知、パブリッシュ - 表示

Yes

Yes

No

No

メッセージ待機インジケータ(MWI:ランプ点灯/消灯)

Yes

Yes

No

Yes

パス交換

No

Yes

No

Yes

コール保留/復帰

Yes

Yes

Yes

Yes

保留音(ユニキャストおよびマルチキャスト)

Yes

Yes

Yes

Yes

DTMF リレー

RFC 2833、KPML(OOB)、Unsolicited Notify(OOB)

RFC 2833、KPML(OOB)、Unsolicited Notify(OOB)

H.245 アウトオブバンド(OOB)1

H.245 アウトオブバンド(OOB)1

SIP アーリー オファー

Yes:MTP が必要な場合があります

Yes:MTP が必要な場合があります

該当なし

該当なし

SIP ディレイド オファー

Yes

Yes

該当なし

該当なし

H.323 Fast Start

該当なし

該当なし

Yes:発信 Fast Start のために常に MTP が必要

Yes:発信 Fast Start のために常に MTP が必要

H.323 Slow Start

該当なし

該当なし

Yes

Yes

音声コーデック

G.711、G.722、G.723、G.729、iLBC、AAC、iSAC

G.711、G.722、G.723、G.729、iLBC、AAC、iSAC

G.711、G.722、G.723、G.729

G.711、G.722、G.723、G.729

受信オファーのオーディオ コーデック プリファレンスの受け入れ

Yes

Yes

No

No

MTP でのコーデック

[Early Offer support for voice and video calls (insert MTP if needed)] がオンの場合、すべてのコーデックがサポートされます

[MTP Required] がオンの場合、G.711、G.729

[Early Offer support for voice and video calls (insert MTP if needed)] がオンの場合、すべてのコーデックがサポートされます

[MTP Required] がオンの場合、G.711、G.729

G.711、G.723、G.729

G.711、G.723、G.729

ビデオ

Yes

Yes

Yes

Yes

ビデオ コーデック

H.261、H.263、H.263+、H.264 AVC

H.261、H.263、H.263+、H.264 AVC

H.261、H.263、H.263+、H.264 AVC

H.261、H.263、H.263+、H.264 AVC

T.38 Fax

Yes

Yes

Yes

Yes

シグナリング認証

ダイジェスト、TLS

ダイジェスト、TLS

No

No

シグナリング暗号化

TLS

TLS

No

No

メディア暗号化(音声)

SRTP

SRTP

SRTP

SRTP

RSVP ベースの QoS およびコール アドミッション制御

Yes

Yes

No

No

+ 文字のサポート

Yes

Yes

No

No

着信コール:着信側:Significant Digit、Prefix-Digit

Yes

Yes

Yes

Yes

着信の発呼側設定:Strip Digit、番号タイプに基づく Prefix-Digit

SIP は番号タイプをサポートせず、すべてのコールに「Unknown」が使用されます

SIP は番号タイプをサポートせず、すべてのコールに「Unknown」が使用されます

Unified CM、Unknown、National、International、Subscriber

Unified CM、Unknown、National、International、Subscriber

着信の着呼側設定:Strip Digit、番号タイプに基づく Prefix-Digit

該当なし

該当なし

Unified CM、Unknown、National、International、Subscriber

Unified CM、Unknown、National、International、Subscriber

接続先変換

Yes

Yes

No

No

発信の発呼側変換

Yes

Yes

Yes

Yes

発信の着呼側変換

Yes

Yes

Yes

Yes

発信の発呼側/着呼側番号タイプの設定

SIP は番号タイプをサポートしません

SIP は番号タイプをサポートしません

Unified CM、Unknown、National、International、Subscriber

Unified CM、Unknown、National、International、Subscriber

発信の着呼側/発呼側番号計画の設定

SIP は番号計画をサポートしません

SIP は番号計画をサポートしません

Unified CM、ISDN、National Standard、Private、Unknown

Unified CM、ISDN、National Standard、Private、Unknown

トランクの宛先:状態検出メカニズム

OPTIONS ping

OPTIONS ping

コール別の試行

コール別の試行

1.H.323 トランクは、特定の接続の種類で、RFC 2833 に規定されたシグナリングをサポートします。

SIP トランクの概要

SIP トランクによって、ゲートウェイ、Cisco Unified CM Session Management Edition、SIP プロキシ、Unified Communications アプリケーション、その他の Unified CM クラスタなど、他の SIP デバイスに接続できます。現在、サービス プロバイダーや Unified Communications アプリケーションに接続するときに、最も一般的に選択されるプロトコルは、ほぼ間違いなく SIP です。Cisco Unified CM では、次の SIP トランクとコール ルーティングの拡張機能が提供されています。

すべての Unified CM ノードで実行可能

各トランクで最大 16 の宛先 IP アドレスをサポート

SIP OPTIONS ping キープアライブ

音声コールとビデオ コールに対する SIP アーリー オファー サポート(必要に応じて MTP を挿入)

オーディオ コーデック プリファレンス(受信オファーのオーディオ コーデック プリファレンス受け入れ)

QSIG over SIP

SIP トランクの正規化および透過性

SIP REFER 透過

すべての Unified CM ノードでルート リストの使用をサポート

最新リリースの Unified CM で使用できる SIP トランク機能によって、SIP は新規のトランク接続にも既存のトランク接続にも適した選択肢になりました。QSIG over SIP 機能は H.323 クラスタ間トランクにおけるものと同等を提供します。また、Cisco IOS ゲートウェイ(および QSIG ベースの TDM PBX)に対する QSIG over SIP トランク接続を提供するためにも使用されます。すべての Unified CM ノードで実行する機能、および最大 16 の宛先 IP アドレスを処理する機能によって、Unified CM クラスタからの発信の分配が改善され、クラスタおよびデバイス間に必要な SIP トランク数が減ります。SIP OPTIONS ping には、コール別の到達可能性の判断ではなく、SIP トランクの宛先に関するダイナミックな到達可能性を検出する機能があります。音声コールおよびビデオ コールに関する SIP アーリー オファーのサポート(必要に応じて MTP を挿入)によって、MTP を使用する必要性が軽減または排除され、SIP アーリー オファー トランク上で音声コール、ビデオ コール、および暗号化されたコールを処理できます。

SIP トランクの正規化および透過性によって、ネイティブの Unified CM とサードパーティのユニファイド コミュニケーション システム間、およびサードパーティ システム間の相互運用性が改善されます。正規化によって、着信および発信の SIP メッセージおよび SDP 情報を SIP トランクごとに変更できます。通過するメッセージの部分を Unified CM が理解またはサポートしていない場合でも、透過性によって、Unified CM は SIP ヘッダー、パラメータ、コンテンツ本文を SIP トランク コール レッグから別の宛先に渡すことができます。

これらの機能については、この項で詳しく後述します。

SIP トランクの新規拡張機能の全リストについては、次の Web サイトで入手可能な Cisco Unified Communications Manager の製品リリース ノートを参照してください。

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

配置に関する一般的な考慮事項

Unified CM SIP トランクは、H.323 クラスタ間トランクと比較すると機能数が多いため、クラスタ間トランク接続のプロトコルとして SIP を選択できるようになります(ただし、以前のソフトウェア バージョンを使用する Unified CM に対するクラスタ間トランク接続の場合には、H.323 Annex M1 の方が推奨されます)。また、業界では SIP が幅広くサポートされているため、サードパーティのアプリケーションやサービス プロバイダーと接続するには、一般的に SIP トランクが推奨されます。

SIP トランクの機能と操作

ここでは、Unified CM SIP トランクの設計および配置時に考慮する必要がある Unified CM SIP トランクの操作と、いくつかの主要な SIP トランク機能について説明します。

SIP トランクで使用できる [Run on All Active Unified CM Nodes]

SIP トランクで [Run on all Active Unified CM Nodes] オプションをオンにすると、Unified CM は、クラスタ内の呼処理サブスクライバごとに SIP トランク デーモンのインスタンスを作成します。そのため、どの呼処理サブスクライバでも SIP トランク コールを発信または着信できます (この機能を使用できるようになる前は、Unified CM Group を使用してトランクごとに最大 3 つのノードを選択できました)。[Run on all Active Unified CM Nodes] を有効にすると、発信 SIP トランク コールは、(たとえば電話またはトランクから)着信コールを受信したのと同じノードから発信します。すべての Unified CM SIP トランクと同様に、トランクに関連付けられている SIP デーモンは、トランクの宛先アドレス フィールドに定義された IP アドレスを持つエンド システムからの着信のみを受け入れます。大量のコールを処理するために SIP トランクが必要な場合、すべてのノードで SIP トランクを実行することが推奨されます。その結果、発信および着信の分配は、クラスタ内のすべての呼処理サブスクライバに均等に分散できます。また、同じ宛先に対する複数の SIP トランクが同じサブスクライバを使用している場合、各トランクが一意に識別されるために、トランクごとに一意の着信および発信のポート番号を定義する必要があります。

最大 16 の SIP トランク宛先 IP アドレス

SIP トランクは、最大 16 の宛先 IP アドレス、16 の完全修飾ドメイン名、または単一の DNS SRV エントリを使用して設定できます。追加の宛先 IP アドレスをサポートしているため、2 つの Unified Communications システム間のコール分配のために、ルート リストおよびルート グループに関連付けられた複数のトランクを作成する必要性が軽減されます。結果として、Unified CM トランク設計が単純になります (図 14-2 を参照)。この機能を [Run on all Active Unified CM Nodes] 機能、または標準の Unified CM Group を使用する SIP トランクと併用して、クラスタ内の最大 3 ノードで SIP デーモンを作成できます。ただし、Unified CM SIP トランクと関連付けられた SIP デーモンは、トランクの宛先アドレス フィールドに定義された IP アドレスを持つエンド システムからの着信のみを受け入れる点に注意してください。

図 14-2 すべてのアクティブ ノードで実行される複数の宛先 IP アドレスを持つ SIP トランク

 

SIP OPTIONS ping

SIP トランクに関連付けられた SIP プロファイルで SIP OPTIONS ping 機能を有効にして、トランクの宛先の状態をダイナミックに追跡できます。この機能を有効にすると、トランクの SIP デーモンを実行する各ノードは、トランクの各宛先 IP アドレスに対して OPTIONS 要求を定期的に送信して到達可能性を判断し、到達可能なノードにのみコールを送信します。宛先アドレスが OPTIONS 要求に応答しない場合、Service Unavailable(503)応答または Request Timeout(408)応答を送信する場合、または TCP 接続を確立できない場合、そのアドレスは「アウト オブ サービス」と見なされます。1 つ以上のノードが、1 つ以上の宛先アドレスから(408 または 503 以外の)応答を受信した場合、トランクの状態は「イン サービス」と見なされます。SIP トランク ノードは、トランクの設定済み宛先 IP アドレス、またはトランクの DNS SRV エントリの解決済み IP アドレスに対して OPTIONS 要求を送信できます。SIP OPTIONS ping の有効化はすべての SIP トランクで推奨されます。有効にすることで、Unified CM は、コールごとの状態やタイムアウトに基づくのではなく、動的にトランクの状態を追跡することができるためです。

Unified CM SIP トランクでの SIP アーリー オファー サポート

SIP はセッション記述プロトコル(SDP)によってメディア情報をネゴシエートします。これにより、一方が提示したメディア セットに他方が応答する形で、使用するメディアがある組み合わせに決定します。SIP では、発信側が初期 INVITE メッセージ(アーリー オファー)によって初期のオファーを送信するか、発信側がそうしなかった場合は着信側が最初の信頼性のある応答(ディレイド オファー)で初期のオファーを送信できます。

デフォルトで、Unified CM SIP トランクは、初期のオファー(ディレイド オファー)を伴わない INVITE を送信します。通常、音声、ビデオ、または暗号化メディアに対するディレイド オファー コールを確立するのに MTP は不要なため、Unified CM SIP トランクには、SIP ディレイド オファーが適切です。SIP アーリー オファーが必要な場合は、Unified CM には、SIP トランクが INVITE でオファーを送信できるようにする 2 つの設定可能なオプションがあります。

「メディア ターミネーション ポイントが必須(Media Termination Point Required)」

「音声コールおよびビデオ コールをサポートするアーリー オファー(必要に応じて MTP を挿入)」

メディア ターミネーション ポイントが必須(Media Termination Point Required)

SIP トランクで [Media Termination Point Required] オプションを有効にすると、トランクの Media Resources Group(MRG; メディア リソース グループ)からの MTP は各発信に割り当てられます (図 14-3 を参照)。この処理でスタティックに割り当てられた MTP は G.711 または G.729 コーデックのみをサポートするため、メディアは音声コールにのみ限定されます。

図 14-3 必要なメディア ターミネーション ポイントがある SIP アーリー オファー

 

音声コールおよびビデオ コールをサポートするアーリー オファー(必要に応じて MTP を挿入)

SIP トランクに関連付けられた SIP プロファイルで [Early Offer support for voice and video calls (insert MTP if needed)] を有効にして MTP が挿入されるのは、発信デバイスがアーリー オファーの作成に必要な特性を Unified CM に提示できない場合のみです。一般的に、[Media Termination Point Required] よりも [Early Offer support for voice and video calls (insert MTP if needed)] が推奨されるのは、この設定オプションによって MTP の使用量が減るためです(図 14-4 を参照)。このオプションを使用して設定した SIP アーリー オファー トランク上の Unified CM に登録されている古い SCCP ベースの電話からのコールは、MTP を使用してオファー SDP を作成します。また、このようなコールは、音声メディア、ビデオ メディア、および暗号化されたメディアをサポートします。SIP アーリー オファー トランクで拡張される SIP ディレイド オファー トランクまたは H.323 Slow Start トランクに対する着信は、MTP を使用してオファー SDP を作成します。ただし、このようなコールは最初のコール セットアップでのみ音声をサポートしますが、コール メディアを再ネゴシエートする場合(保留/再開後など)、ビデオおよび SRTP をサポートするためにコール中にエスカレーションできます。[Early Offer support for voice and video calls (insert MTP if needed)] を使用するタイミングのガイドラインについては、「SIP トランクの設計上の考慮事項」を参照してください。


) INVITE メッセージに初期のオファー SDP が含まれているかどうかにかかわらず、着信 INVITE メッセージに MTP リソースは必須ではありません。


図 14-4 アーリー オファーによる音声コールおよびビデオ コールのサポート

 

Unified CM に対する着信を次のいずれかの手段で受信した場合、SIP トランク上で発信アーリー オファー コールを作成するために、Unified CM が MTP を挿入する必要はありません。

アーリー オファーを使用する SIP トランク上

Fast Start を使用する H.323 トランク上

MGCP トランク上

Unified CM に登録されている SIP ベースの IP 電話から

Unified CM に登録されている、SCCP ベースの新しい Cisco Unified IP Phone モデルから

上記のデバイスの場合、Unified CM はエンドポイントのメディア機能を使用して、発信デバイスと発信 SIP トランクのリージョンペアに基づいてコーデック フィルタリング ルールを適用し、発信 SIP トランク コールのオファー SDP を作成します。ほとんどの場合、オファー SDP には、発信したエンドポイントの IP アドレスとポート番号が含まれます。そのため、発信デバイスと SIP トランクの間に共通のコーデックがない場合でも、DTMF の不一致、TRP の要件、またはトランスコーダの要件など、他の理由で Unified CM が MTP を挿入する必要はありません。

トランクの SIP プロファイルで [Early Offer support for voice and video calls (insert MTP if needed)] を設定している場合、古い SCCP ベースの電話、SIP ディレイド オファー トランク、および H.323 Slow Start トランクからのコールでは、Unified CM は、コールに MTP またはトランスコーダがまだ割り当てられていない場合、MTP を割り当てます。MTP は、有効なメディア ポートおよび IP アドレスを含むオファー SDP を生成するために使用されます。MTP は、発信 SIP トランクのメディア リソースではなく、発信デバイスに関連付けられたメディア リソースから割り当てられます (この処理で、メディア パスが発信 SIP トランクの MTP にアンカーされるのを回避します)。発信デバイスのメディア リソース グループ リスト(MRGL)から MTP を割り当てることができない場合、MTP の割り当ては SIP トランクの MRGL から試行されます。

Unified CM に登録されているより古い SCCP 電話からのコールの場合、発信デバイスの一部のメディア機能(サポート対象の音声コーデック、ビデオ コーデック、暗号化キーなど、サポートされる場合)は、セッション記述プロトコル(SDP)を介したメディア交換に使用できます。Unified CM は、エンドポイントおよび MTP コーデック機能のスーパーセットを作成し、適用可能なリージョンペア設定に基づいてコーデックのフィルタリングを適用します。発信オファー SDP は、MTP の IP アドレスとポート番号を使用します。また、音声メディア、ビデオ メディア、および暗号化されたメディアをサポートできます。パススルー コーデックをサポートするには、MTP を設定する必要があります。


) Cisco Unified IP Phone 7902、7905、7910、7912、7920、7935、7940、7960 など古い SCCP ベースの IP 電話機では、[Early Offer for voice and video (insert MTP if needed)] 機能をイネーブルにして SIP トランクを使用するときに、MTP を使用する必要があります。クラスタ内にこれらの電話機が相当数配置されている場合、クラスタ内の MTP リソースを、[Early Offer for voice and video (insert MTP if needed)] 機能を使用した SIP トランク経由の最繁忙時のコール数と同等にプロビジョニングします。


Unified CM が H.323 Slow Start または SIP ディレイド オファー トランクで着信を受信した場合、コールの開始時に発信デバイスのメディア機能を使用できません。この場合、Unified CM が MTP を挿入する必要があります。また、IP アドレスと UDP ポート番号を使用して、(リージョン ペアのフィルタリング後に)発信 SIP トランクで送信された最初の INVITE のオファー SDP で、サポート対象のすべての音声コーデックをアドバタイズします。アンサー SDP を SIP トランクで受信し、発信エンドポイントでサポートされるコーデックが含まれる場合、追加のオファー/アンサー トランザクションは不要です。コーデックが一致しない場合、Unified CM はトランスコーダを挿入して不一致に対処するか、reINVITE または UPDATE を送信してメディア ネゴシエーションをトリガーします。H.323 Slow Start または SIP ディレイド オファー トランクからのコールは、最初のコール セットアップでのみ音声をサポートしますが、コール メディアを再ネゴシエートする場合(保留/再開後など)、ビデオおよび SRTP をサポートするためにコール中にエスカレーションできます。

オーディオ コーデック プリファレンス(受信オファーのオーディオ コーデック プリファレンス受け入れ)

Cisco Unified CM 9. x には、設定可能なオーディオ コーデック プリファレンス リストが準備されており、リージョン内、リージョン間、クラスタ間でのコーデック プリファレンスの優先順位付けに使用できます。SIP トランクを介したコールの場合、設定可能な SIP プロファイル オプション [Accept Audio Codec Preference in Received Offer] によって、トランクのリージョンまたはリージョン ペアに設定されたコーデック プリファレンスをトランクに上書きさせ、クラスタ外デバイスからのオファー内で受信したコーデック プリファレンスを使用することができます。この機能は、SIP コールが 2 つ以上の Unified CM クラスタを通過する場合に特に役立ちます(たとえば、コール用にエンド コーデック プリファレンスを保持する必要がある SME 配置など)。コーデックの優先順位については、「IP トランク上でのコーデック選択」 で詳しく説明しています。

QSIG over SIP トランク

Unified CM は、SIP メッセージに QSIG コンテンツをカプセル化できるため、SIP QSIG クラスタ間トランク上および Cisco IOS ゲートウェイに対する SIP QSIG トランク上で、コール バック、MWI、パス交換などの機能を呼び出すことができます (図 14-5 を参照)。QSIG over SIP トランクは、H.323 Annex M1 クラスタ間トランクおよび MGCP QSIG トランクに設定されている QSIG 機能と同等を提供します (QSIG の ISO および ECMA のバリエーションは、トランク別にサポートされます)。

図 14-5 QSIG over SIP トランク

 

SIP トランク メッセージの正規化および透過性

正規化および透過性は、SIP トランクに強力なスクリプトベースの機能を提供します。この機能を使用すると、Unified CM を通過するときに SIP メッセージおよびメッセージ ボディの内容を透過的に転送または変更できます。正規化および透過性のスクリプトは、SIP の相互運用性の問題に対処するように設計されているため、Unified CM は SIP ベースのサードパーティ PBX、アプリケーション、および IP PSTN サービスと相互運用できます。

SIP トランクの正規化

正規化によって、Unified CM を通過するときに着信および発信 SIP メッセージを変更できます。正規化は、コールに関係する他のエンドポイントで使用されるプロトコルに関係なく、スクリプトが関連付けられた SIP トランクを通過するすべてのコールに適用されます。たとえば、SIP トランクの正規化スクリプトは、SIP ライン デバイスから SIP トランクに対するコール、SCCP ベースのデバイスから SIP トランクに対するコール、MGCP から SIP トランクに対するコール、H.323 から SIP トランクに対するコールなどで実行できます (図 14-6 を参照)。正規化にはエンドツーエンドの SIP は必要ありません。

図 14-6 SIP トランクの正規化

 

SIP トランクの透過性

通過するメッセージの部分を Unified CM が理解またはサポートしていない場合でも、透過性によって、Unified CM は SIP ヘッダー、パラメータ、コンテンツ本文を SIP トランク コール レッグから別の宛先に渡すことができます。透過性(または透過的なパススルー)を適用できるのは、Unified CM を通過するコールが、図 14-7 のように SIP トランクから SIP トランクへの場合のみです。

図 14-7 SIP トランクの透過性

 

正規化と透過性のスクリプトは、強力、高速、軽量、そして埋め込み可能なスクリプティング言語である Lua を使用して、SIP トランク上の SIP メッセージと SDP ボディの内容を変更します (Lua の詳細については、 http://lua-users.org/wiki/LuaOrgGuide で入手可能なマニュアルを参照してください)。

シスコでは、Lua ベースの SIP メッセージ API のライブラリを作成しました。このライブラリを使用して、SIP メッセージおよび SDP ボディに指定されている情報の取得、変更、置換、削除、パススルー、無視、追加、変換などを行うことができます。基礎となる Lua 言語では、取得した情報を変数として格納できます。また、If、elseif、while、do、<、>、= などの一連の演算を使用して処理できます。このスクリプティング方法では、スクリプトの決定のマーキングに複数の変数と状態固有のコンテキストをサポートします。シスコの SIP メッセージ ライブラリ API と Lua 言語の基礎となる機能を組み合わせると、ほとんどすべての SIP メッセージや SDP ボディの内容を変更できる強力なスクリプティング環境になります。

SIP トランクでの着信メッセージの場合、正規化および透過性スクリプトの処理は、ネットワークからメッセージを受信した直後に実行されます。発信メッセージの場合、スクリプト メッセージングは、ネットワークにメッセージを送信する直前に実行されます。

Lua スクリプト内では、コールバック機能(メッセージ ハンドラとも呼ばれます)は、関係するメッセージ タイプを要求するために使用されます。Cisco Lua 環境は、要求(inbound_INVITE など)のメッセージの方向およびメソッドに基づいて、また応答(outbound_180_INVITE など)の(CSeq ヘッダーの)メッセージの方向、応答コード、およびメソッドに基づいて、メッセージ ハンドラの名前を構築します。メッセージ オブジェクト(msg など)は、メッセージ ハンドラに渡されるため、スクリプトでメッセージ(inbound_INVITE(msg) など)を変更できます。

コールバック関数(メッセージ ハンドラ)の例:

inbound_INVITE()

outbound_INVITE()

inbound_UPDATE()

outbound_SUBSCRIBE()

inbound_3XX_INVITE()

outbound_180_INVITE()

次に、Lua スクリプトで、シスコの SIP メッセージ ライブラリを使用して、メッセージ パラメータのアクセスと操作を行います。次に、例を示します。

getHeader ( header-name ) はヘッダー値または "" を返します

getHeaderValues ( header-name ) はヘッダー値のテーブルを返します

addHeaderValueParameter ( header-name , parameter-name , [ parameter-value ])

getUri ( header-name ) は指定したヘッダーから URI を取得します

block() は指定した SIP メッセージをブロックします

applyNumberMask ( header-name, mask ) は指定したヘッダーを取得し、指定した番号マスクを URI に適用します

getSdp() は SDP の内容を返します

sdp:getLine(start of line, line contains ) は、「start of line」で始まり、「line contains」という文字列も含む SDP の行を返します。

sdp:modifyLine(start of line, line contains, new-line ) は、「start of line」で始まる SDP の行を検索し、「line contains」と一致する行は new-line パラメータで置換されます

次に、SIP メッセージ API スクリプトの使用例を示します。

例 14-1 SIP メッセージ API:getRequestLine

getRequestLine() はメソッド、Request-URI、およびバージョンを返します。

このメソッドは次の 3 つの値を返します。

メソッド名

Request-URI

プロトコルのバージョン

スクリプト例:

1 行目

M = {}

2 行目

function M.outbound_INVITE(message)

3 行目

local method, ruri, ver = message:getRequestLine()

4 行目

end

5 行目

return M

1 行目で、コールバック関数セットを空の値に初期化します。この M というコールバック関数セットは、基本的に Lua テーブルです。

2 ~ 4 行目で、メッセージ ハンドラを定義します。このコールバック関数が実行されるのは、発信 INVITE が Unified CM から送信されるときです。次に、要求の行からメソッド、Request-URI、およびバージョンを取得し、その値を格納します。

スクリプトで複数のメッセージ ハンドラを定義できます。メッセージ ハンドラの名前は、特定の SIP メッセージに対して呼び出されるメッセージ ハンドラがあれば、そのハンドラを示します。

最後の行は、コールバック セットを返します。この行は必須です。

メッセージ:

INVITE sip:1234@10.10.10.1 SIP/2.0
 

出力と結果:

method == "INVITE"
ruri == "sip:1234@10.10.10.1"
version == "SIP/2.0"
 

例 14-2 発信 INVITE の「Cisco-Guid」ヘッダーを削除するのみのスクリプト

1 行目

M = {}

2 行目

function M.outbound_INVITE(message)

3 行目

message:removeHeader("Cisco-Guid")

4 行目

end

5 行目

return M

1 行目で、コールバック関数セットを空の値に初期化します。この M というコールバック関数セットは、基本的に Lua テーブルです。

2 ~ 4 行目で、メッセージ ハンドラを定義します。このコールバック関数が実行されるのは、発信 INVITE が Unified CM から送信されるときです。スクリプトで複数のメッセージ ハンドラを定義できます。メッセージ ハンドラの名前は、特定の SIP メッセージに対して呼び出されるメッセージ ハンドラがあれば、そのハンドラを示します。

最後の行は、コールバック セットを返します。この行は必須です。

メッセージ:

INVITE sip:1234@10.10.10.1 SIP/2.0
.
P-Asserted-Identity: "1234" <1234@10.10.10.1>
Cisco-Guid: 1234-4567-1234
Session-Expires: 1800
 

出力と結果:

INVITE sip:1234@10.10.10.1 SIP/2.0
.
P-Asserted-Identity: "1234"
 

SIP トランクの正規化および透過性のスクリプトについて詳しくは、次のサイトで入手可能な『 Developer Guide for SIP Transparency and Normalization 』を参照してください。

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/sip_tn/8_5_1/sip_t_n.html

Unified CM の正規化および透過性スクリプト

多数の正規化および透過性スクリプトが Unified CM にプリロードされており、次のスクリプトはそのうちの代表的な例です。

Refer-passthrough スクリプト:このスクリプトを使用して、ブラインド転送(ダイアログ内参照使用)が 2 つの SIP トランク間で呼び出されたときに、Unified CM をコール シグナリング パスから削除できます。

ContactHeader スクリプト:このスクリプトは、着信ディレイド オファーの通話中再参加内の Contact ヘッダーから音声とビデオの属性を削除します。

HCS-PCV-PAI-passthrough スクリプト:このスクリプトは、IMS ベースのネットワークとの統合に使用され、INVITE、UPDATE & 200 OK メッセージの P-Charging-Vector ヘッダーをパススルー/追加します。

Diversion-Counter スクリプト:このスクリプトは、さまざまな Call Forward シナリオ用に Diversion カウンタを調整する機能を提供します。

VCS-interop script:このスクリプトは、Video Communication Server(VCS)に登録されたエンドポイントの相互運用性を提供します。

すべてのアクティブな Unified CM ノードでのルート リストの実行

これは具体的には SIP トランク機能ではありませんが、すべてのノードでルート リストを実行すると、ルート リストおよびルート グループ内のトランクに利点があります。「ルート ローカル」ルールを使用してすべてのノードでルート リストを実行すると、発信の分配が改善され、不要なクラスタ内トラフィックを回避できます。

ルート リストの場合、ルート ローカル ルールは次のように動作します。

ルート リスト(および関連するルート グループとトランク)を使用する発信の場合、登録されている電話からのコールまたは着信トランクが、ルート リスト インスタンスがあるノードに到達したときに、選択した発信トランクのインスタンスがルート リストと同じノードに存在するかどうかが Unified CM によって確認されます。存在する場合、Unified CM はそのノードを使用して発信トランク コールを確立します。

ルート リストとトランクの両方で [Run on all Active Unified CM Nodes] が有効の場合、発信の分配は、着信が到達したノードによって決定されます。すべてのノードでの実行ではなく、選択した発信トランクが Unified CM Group を使用すると、選択した発信トランクのインスタンスが、着信が到達した同じノードに存在する場合に、Unified CM はルート ローカル ルールを適用します。トランクのインスタンスがそのノードに存在しない場合、Unified CM は(クラスタ内の)コールをトランクがアクティブなノードに転送します。

ルート リストで [Run on all Active Unified CM Nodes] を有効にしていない場合、ルート リストのインスタンスはクラスタ内の 1 つのノード(ルート リストの Unified CM Group のプライマリ ノード)でアクティブになり、ルート ローカル ルールはそのノードに適用されます。この設定では、ルート リストに関連付けられたいずれかのトランクの Unified CM Group に、ルート リストの Unified CM Group のプライマリ ノードを使用しないよう推奨します。これにより発信コールの分配が最適でなくなる場合があるためです。

一般的な推奨事項として、[Run on all Active Unified CM Nodes] はすべてのルート リストで有効にしてください (図 14-8 を参照)。

図 14-8 すべてのアクティブな Unified CM ノードで実行されるルート リスト

 

DNS を使用する SIP トランク

次のような特定の状況では、複数の宛先 IP アドレスを定義するよりも、SIP トランクの宛先として DNS SRV エントリを使用する方が推奨されます。

SRV ホストの優先順位付けが必要な場合

SRV ホストの重み付けが必要な場合

必要な宛先 IP アドレス数が 16 を超える場合

DNS SRV の解決が、宛先 Unified Communications システムの要件の場合


) 設定オプション [Destination Address is an SRV] が選択されている場合、トランクの宛先として単一の SRV エントリのみを追加できます (たとえば、Destination Address = cluster1.cisco.com、 Port = 0 です)。


図 14-9 に、DNS SRV を使用して、アドレスを宛先 Unified CM クラスタに解決する SIP トランクのコール フローを示します。ただし、この宛先は、サードパーティのユニファイド コミュニケーション システムの場合もあります。

図 14-9 DNS SRV を使用したクラスタ間 SIP トランクのコール フロー

 

図 14-9 は、このコール フローにおける次の手順を示しています。

1. Cluster1 内の IP Phone が 87522001 にコールします。

2. コールはルート パターン 8752XXXX と一致し、このパターンは cluster2.foo.com の DNS SRV を使用した SIP トランクを指しています。Cluster1 の CCM3 は、このコールを処理するノードです。その SIP トランクはこのノードに登録されているためです。CCM3 は、cluster2.foo.com の DNS SRV ルックアップを送信します。

3. DNS サーバは、CCM-A.cluster2.foo.com と CCM-B.cluster2.foo.com の 2 つのレコードで応答します。CCM-A.cluster2.foo.com のプライオリティの方が高いため、コールはその Unified CM に対して試みられます。SIP INVITE が送信される前に、CCM-A.cluster2.foo.com に関して別の DNS ルックアップが行われます。

4. CCM3 は、SIP INVITE を 87522001@cluster2.foo.com に送信します。宛先アドレスは CCM-A の IP アドレスに設定されます。

5. Unified CM は、このコールをローカル コールとして解釈します。ユニフォーム リソース識別子(URI)のホスト部分が Cluster FQDN エンタープライズ パラメータと一致しているためです。Cluster2 には、CCM3 の宛先が設定された SIP トランクがありません。したがって、DNS SRV を使用して SIP トランクに設定されたすべてのドメインに対して、DNS SRV ルックアップを行います。その場合、例では cluster1.foo.com の DNS SRV の宛先を持つ単一のトランクが示されています。

6. DNS サーバは 2 つのエントリを返し、そのうちの 1 つが INVITE の送信元 IP アドレスと一致します。クラスタはコールを受け入れ、内線 87522001 にコールをルーティングします。

SIP トランクのハイ アベイラビリティ

SIP トランクを使用したハイ アベイラビリティの設定には、多様な Unified CM オプションを使用できます。そのすべてを組み合わせて、SIP トランクの送信元サーバおよび宛先サーバの両方に冗長性と復元力を提供できます。これらのオプションは次のように分類できます。

「発信元 SIP トランク コールに対する複数の送信元 Unified CM サーバ」

「SIP トランクごとの複数の宛先 IP アドレス」

「ルート リストとおよびルート グループを使用する複数の SIP トランク」

「SIP OPTIONS ping」

発信元 SIP トランク コールに対する複数の送信元 Unified CM サーバ

標準の Unified CM Group の使用

個々のトランクに関連付けられている Unified CM Group 内に定義されたノードによって、トランク経由でコールを送受信できるサーバのセットが構成されます。1 つの Unified CM グループには 3 つまでノードを定義できるため、トランク自体のハイ アベイラビリティが確保されます。

[Run on All Active Unified CM Nodes] の使用

[Run on all Active Unified CM Nodes] 機能を使用すると、クラスタ内の各呼処理サブスクライバで SIP トランク インスタンスが作成され、有効になるため、そのノードのトランク上で発信または着信できます。

発信 SIP トランク コールに関する Unified CM ルート ローカル機能とサブスクライバの選択の影響

Unified CM のルート ローカル機能は、クラスタ内トラフィックを減らすために設計されています。この機能は、次の示す例のように動作します。

電話機などのデバイスが SIP トランク 1 上で発信すると、SIP トランク 1 のインスタンスが、電話機の登録先と同じノードでアクティブな場合、クラスタ内の別のノード上にある別の SIP トランク 1 インスタンスに対してコールを内部的にルーティングするのではなく、常にこの同居する SIP トランク 1 インスタンスを使用します。

ノードの選択に関するルート ローカル機能の影響は、Unified CM Group と [Run on all Active Unified CM Nodes] のいずれがトランクに設定されているかによって変わります。[Run on all Active Unified CM Nodes] を設定したトランクの場合、発信デバイスの登録先ノードは、発信 SIP トランク コールの発信に使用されます。Unified CM Group がトランクに使用されているときに、発信デバイスが、トランクの Unified CM Group のノードの 1 つに登録されている場合、ルート ローカル ルールが適用されます。発信デバイスが、トランクの Unified CM Group のノードの 1 つに登録されていない場合、Unified CM は、トランクの Unified CM Group のノード上でコールをランダムに分配します。

SIP トランクの場合、[Run on all Active Unified CM Nodes] の使用が推奨される方法です。この方法を使用すると、ノード間のコールの分配を発信元デバイスが決定でき、クラスタ内のトラフィックが最小限に抑えられるためです。

SIP トランクごとの複数の宛先 IP アドレス

単一の SIP トランクには、最大 16 の宛先 IP アドレスを設定できます。Unified CM は、SIP トランク上で発信するときに、設定済みの宛先 IP アドレスに対してランダムな分配を使用します。SIP トランクで複数の IP アドレスを使用すると、ルート リストおよびルート グループを使用して複数のトランクを配置する必要性を軽減できます。

[Run on All Active Unified CM Nodes] を使用するときの設計の考慮事項

[Run on All Active Unified CM Nodes] と複数の宛先アドレスを併用する場合、着信を受け入れるには、SIP トランクで受信した着信の送信元 IP アドレスが、着信トランクに設定されている宛先 IP アドレスと一致する必要がある点に注意してください。たとえば、[Run on all Active Unified CM Nodes] が各クラスタ内の SIP クラスタ間トランクで設定されている場合、各トランクは、宛先クラスタ内の各アクティブ ノードの対応する宛先アドレスを使用して設定する必要があります。WAN を介したクラスタリング設計を展開し、地理的なコールの分配およびフェールオーバーが必要な場合、複数のクラスタ間トランク(それぞれ最大 3 つの宛先 IP アドレスを使用)上で標準の Unified CM Group を使用し、さらにルート リストとルート グループを併用します。

ルート リストとおよびルート グループを使用する複数の SIP トランク

複数の優先順位が付けられた SIP トランクが必要になるのは、多くの場合、Unified Communications 設計でのアドレス エラーのシナリオです。これらのトランクは、1 つのルート リスト内の複数のルート グループに設定し、ルート パターンに関連付ける必要があります。Unified CM は、リスト内の選択したトランク上で発信できない場合、リスト内の次のトランクを使用します。一般的な推奨事項として、[Run on all Active Unified CM Nodes] はすべてのルート リストで有効にしてください。

SIP OPTIONS ping

SIP トランクに関連付けられた SIP プロファイルで SIP OPTIONS ping を有効にして、トランクの宛先の状態をダイナミックに追跡できます。このオプションを有効にすると、トランクの SIP デーモンを実行する各ノードは、トランクの各宛先 IP アドレスに対して OPTIONS 要求を定期的に送信して到達可能性を判断します。SIP OPTIONS ping の有効化は、ハイ アベイラビリティが必要なすべての SIP トランクで推奨されます。有効にすることで、Unified CM は、コールごとの状態やタイムアウトに基づくのではなく、動的にトランクの状態を追跡することができるためです。

SIP トランクのロード バランシング

SIP トランクのロード バランシングを設計する場合、コールの送信元となるノードとその宛先の両方について考慮します。Unified CM SIP トランクでは、発信に使用されるノードは、ルート ローカル ルール、発信トランクがアクティブなノード数、およびルート リストを複数の発信トランクと併用するかどうかによって決定されます。このような考慮事項について、次の項で説明します。

単一の SIP トランク上の発信

単一の SIP トランクは、Unified CM Group で最大 3 つの Unified CM ノードを実行できます。または、クラスタ内のすべてのアクティブな Unified CM ノードで実行できます。発信の送信元ノードを選択するために、Unified CM は次の決定プロセスを適用します。

トランクのインスタンスがすべてのノードで実行される場合、ルート ローカル ルールが適用され、各発信に使用されるノードはコールが到達するノードによって決定されます(たとえば、発信元電話が登録されているノードや、着信トランク コールが到達したノード)。

Unified CM Group を使用する場合、ルート ローカル ルールは、トランクの Unified CM Group と同じノードに登録されている発信元デバイスに適用されます。クラスタ内の他のサーバに登録されている発信元デバイスの場合、Unified CM は、トランクの Unified CM Group のノード間でコールを分配します。Unified CM は、トランクの設定済み宛先アドレス間でラウンドロビン式コールの分配を使用します。SIP トランクには、最大 16 の宛先 IP アドレスを設定できます。

複数の SIP トランク上の発信

SIP トランクはすべてのアクティブな Unified CM ノードで実行でき、最大 16 の宛先アドレスを設定できるので、一般的に、2 つの Unified Communications システム間でコールを均等に分配するために、複数の SIP トランクを使用する必要はありません。複数のトランクと、ルート リストおよびルート グループを併用する場合、すべてのアクティブな Unified CM ノードで実行するには、ルート リストを有効にする必要があります。多くの場合、PSTN に対して、または WAN 上に配置されるクラスタの一部として異なるサイトにある Unified CM サーバのグループに対してフェールオーバー機能を提供するために、複数の SIP トランクとルート リストが併用されます。発信 SIP トランク コールの発信に使用される Unified CM ノードの選択、およびトランクの設定済み宛先 IP アドレス上のコールの分配は、単一のトランクの場合と同様の方法で決定されます。WAN を介したクラスタリング設計を展開し、地理的なコールの分配およびフェールオーバーが必要な場合、複数のクラスタ間トランク(それぞれ最大 3 つの宛先 IP アドレスを使用)と標準の Unified CM Group を、ルート リストおよびルート グループと併用します。

SIP OPTIONS ping

OPTIONS ping を使用して、ダイナミックに各 SIP トランク上の各宛先 IP アドレスの状態、およびトランク全体の総合的な状態を追跡します。宛先アドレスが到達不能の場合、Unified CM はそのデバイスにコールを転送しません。すべての宛先が到達不能の場合、SIP トランクはアウトオブサービスと見なされます。

SIP ディレイド オファーおよびアーリー オファー

Cisco Unified CM は、RFC 3264 で規定されているように、SIP セッションの確立に SIP オファー/アンサー モデルを使用します。この場合、オファーは、SIP メッセージのボディ部で送信されるセッション記述プロトコル(SDP)フィールドに含まれます。このオファーは、通常、デバイスでサポートされるメディア特性(メディア ストリーム、コーデック、方向属性、IP アドレス、使用されるポート)を定義します。オファーを受信するデバイスは、対応する一致メディア ストリームおよびコーデック、これを受け入れるかどうか、メディア ストリーム受信に使用する IP アドレスおよびポートに関するアンサーを、その SIP 応答の SDP フィールドで送信します。Unified CM は、このオファー/アンサー モデルを使用して、主要な SIP 標準、RFC 3261 で規定されているように、SIP セッションを確立します。

RFC 3261 は、SDP メッセージをオファーおよびアンサーで送信できる 2 つの方式を規定しています。これらの方式は、一般的にディレイド オファーおよびアーリー オファーとして知られていて、この仕様では、ユーザ エージェント クライアント/サーバにより両方の方式がサポートされていなければなりません。簡単に言うと、メッセージ ボディで SDP を使用して送信される初期 SIP Invite は、アーリー オファーを定義し、メッセージ ボディで SDP を含まずに送信される初期 SIP Invite は、ディレイド オファーを定義します。

アーリー オファーでは、セッションの開始側(発信側デバイス)は、初期 Invite に含まれる SDP でその機能(たとえば、サポートされるコーデック)を送信します(これにより、着信側デバイスは、セッションに適切なコーデックを選択できます)。ディレイド オファーでは、セッションの開始側は、その機能を初期 Invite で送信せず、着信側デバイスからその機能(たとえば、着信側デバイスでサポートされるコーデックのリスト)が送られるまで待機します(これにより、発信側デバイスは、セッションで使用されるコーデックを選択できます)。

ディレイド オファーおよびアーリー オファーは、メディア機能の交換にすべての標準ベースの SIP スイッチで使用できる 2 つのオプションです。ほとんどのベンダーは、ディレイド オファーまたはアーリー オファーのいずれかを選択しています。また、それぞれに独自の利点や制限事項があります。Unified CM SIP トランクの場合、SIP ディレイド オファーと SIP アーリー オファーの両方がサポートされます。Unified CM ディレイド オファー トランクの SIP オファー/アンサー交換に MTP は必要ではありません。Unified CM アーリー オファー トランクの場合、[MTP Required] を使用した SIP アーリー オファーではなく、SIP の [Early Offer for voice and video (insert MTP if needed)] が優先コンフィギュレーション オプションになります。アーリー オファー トランク経由のコール確立には、通常 MTP リソースが必要ないためです。


) Unified CM は、一方でディレイド オファーをサポートし、SIP トランク上のもう一方でアーリー オファーをサポートできます。この機能は、SIP トランク経由で Unified CM に接続された SIP スイッチによって、着信と発信両方のコールのために提供され選択されたコーデックを制御する場合に役立つことがあります。


アーリー メディア

場合によって、SIP セッションで、2 つの SIP エンドポイント間でのメディア能力交換を終了する前に、メディア パスをセットアップする必要があります。そのため、SIP プロトコルでは、初期のオファーがエンドポイントで受信された後で、アーリー メディアを確立できます。アーリー メディアを使用する理由は、次のようにいくつかあります。

着信側デバイスでは、一定時間を超えるシグナリング遅延が発生したコールに対するオーディオ カットスルー遅延(クリッピング)の効果を軽減させるか、ネットワークベースのボイス メッセージを発信側に提供する場合に、アーリー メディア RTP パスを確立します。

発信側デバイスでは DTMF または音声での音声自動応答(IVR)システムにアクセスする場合に、アーリー メディア RTP パスを確立します。

一方向アーリー メディア送信の要求は、サービス プロバイダーがアーリー オファー SIP コールのみを受け付ける IP PSTN サービスを提供する理由の 1 つです。アーリー オファーを使用すると、サービス プロバイダーは、発信者のメディア特性を含む SDP ボディを持つ最初の INVITE の受信後、発信者に一方向メディアをストリーミングすることができます。発信者にアーリー メディアをストリーミングする必要がある例として、発信者が存在しない番号をコールし、サービス プロバイダーが試行されたコールに課金せずに発信者にネットワーク通知を送信する場合などがあります(通常、双方向メディアが確立され、最終 ACK が受信されたときに課金開始)。Unified CM は、SIP アーリー オファーコールによる一方向メディアの受信をサポートします。

双方向のアーリー メディア カットスルーも、Provisional Reliable Acknowledgement(PRACK)を各 SIP Unified Communications システムでイネーブルにすることによっても実現できます。PRACK は、SIP オファーおよびアンサーが暫定応答(1XX 応答など)で確実に送信されるようにし、双方向メディア確立のために交換する必要のあるメッセージの数を減らします。

Unified CM は、アーリー オファーおよびディレイド オファーの両方のコールに対して PRACK ベースのアーリー メディアをサポートしています。

アーリー メディアのカットスルーをサポートする SIP トランクの場合、トランクに関連付けられている SIP プロファイルの [SIP Rel1XX Options] 機能で、PRACK を有効にする必要があります。


) 「アーリー オファー」と「アーリー メディア」は混乱しやすい用語ですが、同じではないので注意してください。


メディア ターミネーション ポイント

MTP は次の用途で Unified CM に使用されます。

SIP トランク上で SIP アーリー オファーを配信する場合

DTMF 転送の不一致に対処する場合

RSVP エージェントとして動作する場合

信頼されたリレー ポイント(TRP)として動作する場合

音声 RTP ストリームに対して IPv4 と IPv6 の変換を提供する場合

次のいずれかの方法を使用して、SIP トランク上でアーリー オファーを有効にできます。

SIP トランクで [MTP Required] チェックボックスをオンにする。

この場合、各発信に MTP が使用されます。また、単一のコーデックを使用する音声コールのみがサポートされます。

SIP トランクに関連付けられた SIP プロファイルで [Early Offer support for voice and video calls (insert MTP if needed)] チェックボックスをオンにする。

この方法で MTP が挿入されるのは、発信デバイスまたはトランクから、最初の SIP INVITE(たとえば、SIP ディレイド オファーまたは H.323 Slow Start トランクから Unified CM に対する着信)でメディア機能に関するすべての情報を送信できない場合のみです。この場合に MTP を使用すると、MTP のパススルー コーデックを使用して、最初のコール セットアップで追加の音声コーデックをサポートできます。確立後は、コールのメディアを再ネゴシエートする場合(保留/再開後など)、ビデオおよび暗号化をサポートするように音声コールをエスカレーションできます。MTP が不要な場合、すべてのコールは音声メディア、ビデオ メディア、および暗号化されたメディアをサポートします。

Unified CM SIP ディレイド オファーおよびアーリー オファーに関する推奨事項

Cisco Unified CM SIP トランクは、デフォルトでディレイド オファー(SDP なしの INVITE)をサポートします。一般的に、メディア ターミネーション ポイント(MTP)は Unified CM SIP トランクからのディレイド オファー コールの場合は不要なので、音声コール、ビデオ コール、および暗号化されたコールのすべてがサポートされます。

SIP アーリー オファーが Unified CM SIP トランクで必要な場合、[Early Offer support for voice and video calls (insert MTP if needed)] を推奨します。これは、[MTP Required] と比較すると、必要な MTP リソースが少ないためです。MTP が [Early Offer support for voice and video calls (insert MTP if needed)] で使用される場合、音声、ビデオ、および暗号化メディアに対するサポートを提供できます。

IP PSTN SIP トランク接続の場合、通常、SIP アーリー オファーはサービス プロバイダーによって要求されます。IP PSTN が大量の同時発生コールのサポートを必要とする設計では、Unified CM SIP トランクでアーリー オファーを使用する代わりに Cisco Unified Border Element の SIP ディレイド オファーからアーリー オファーへの変換機能を使用できるため、MTP の使用をなくすことも可能です。

Unified CM からのコール発着信では、エンドポイントは、RFC 2833 またはアウトオブバンド DTMF 方式(たとえば、KPML)エンドツーエンドのいずれを使用するかネゴシエートできます。エンドポイント間で共通の DTMF メソッドをネゴシエートできない場合、Unified CM は MTP をダイナミックに挿入します。

MTP は、次の 3 種類の形式で利用できます。

Cisco IOS ゲートウェイのソフトウェア MTP。任意の Cisco IOS T-train ソフトウェア リリースで使用できます。また、Route Processor RP2 を搭載した Cisco ASR 1000 シリーズ アグリゲーション サービス ルータでは、5,000 セッション(コール)まで拡張できます。

Cisco IOS ゲートウェイでのハードウェア MTP。対応する Cisco IOS ソフトウェア リリースで使用できます。ハードウェア MTP は、オンボード DSP リソースを使用し、Cisco ルータ プラットフォームでサポートされる DSP 数に従ってコールを拡張します。

Cisco Media Convergence Server(MCS)で Cisco IP Voice Media Streaming Application を使用する Cisco Unified CM ソフトウェア MTP。

一般的に、Unified CM MTP 上では Cisco IOS MTP が推奨されます。これは、Cisco IOS MTP が、追加のコーデック タイプやパススルー コーデックのサポートなど、追加機能を提供するためです (詳細については、「メディア ターミネーション ポイント(MTP)」を参照してください)。

次の設定例は、Cisco IOS ソフトウェアベース MTP の場合の例です。

!
sccp local Vlan5
sccp ccm 10.10.5.1 identifier 5 version 5.0.1
! Communications Manager IP address (10.10.5.1)
sccp
!
sccp ccm group 5
bind interface Vlan5
associate ccm 5 priority 1
associate profile 5 register MTP000E83783C50
! MTP name (MTP000E83783C50) ... must match the Unified CM MTP name.
!
dspfarm profile 5 mtp
description software MTP
codec g711ulaw
codec pass-through
maximum sessions software 500
associate application SCCP
 

DTMF 転送

DTMF 情報を SIP エンドポイント間で転送する方法はいくつかあります。一般的に、これらの方法は、アウトオブバンド(OOB)およびインバンド シグナリングに分類できます。インバンド DTMF 転送方式では、RTP ストリーム内でそのままの、またはシグナリングされた DTMF トーンのいずれかが送信されます。これらは、発信側または着信側、あるいはその両方のエンドポイントで処理および解釈される必要があります。アウトオブバンド シグナリング方式では、DTMF トーンは RTP パス外で、エンドポイントに対して直接転送されるか、必要に応じてこれらのトーンの解釈または転送、あるいはその両方を行う Cisco Unified CM などのコール エージェントを介して転送されます。

アウトオブバンド(OOB)SIP DTMF シグナリング方式には、Unsolicited Notify(UN)、Information(INFO)および Key Press Markup Language(KPML)が含まれます。KPML(RFC 4730)は、シスコが推奨する OOB シグナリング方式ですが、現時点では、市場で広く利用されていません。現在、KPML をサポートするとされる製品は、Cisco Unified CM、Cisco IOS ゲートウェイ(Release 12.4 以降)、および Cisco IP Phone の一部のモデルだけです。INFO は、Unified CM ではサポートされていません。

インバンド DTMF 転送方式は、RTP メディア ストリームのそのままのトーン、または RFC 2833 を使用した RTP ペイロードのシグナリングされたトーンのいずれかで DTMF トーンを送信します。RFC 2833 は、SIP 製品ベンダーにおいて、主流の DTMF トーン送受信方式となっていて、シスコ音声製品の大部分でサポートされています。

インバンド シグナリング方式では、RTP メディア ストリームの DTMF トーンが送信されるため、セッションの SIP エンドポイントは、使用される転送方式(たとえば、RFC 2833)をサポートするか、このインバンド シグナリングを解釈し変換する方式を提供しなければなりません。2 つのエンポイントで、呼制御にバックツーバック ユーザ エージェント(B2BUA)サーバ(たとえば、Cisco Unified CM)が使用されていて、これらのエンドポイントで、各デバイスと呼制御ボックス間で異なる DTMF 方式がネゴシエートされる場合、DTMF の違いをどのように扱うか、つまり、MTP 挿入または OOB 方式のいずれを介するかが、コール エージェントにより決定されます。Unified CM では、DTMF 転送方式の不一致(たとえば、インバンドとアウトオブバンド DTMF)は、メディア ターミネーション ポイント(MTP)を挿入することで解決されます。MTP は、インバンド DTMF シグナリング(RFC 2833)で RTP ストリームを終端させ、RTP ストリームから DTMF トーンを抽出して、これらのトーンをアウトオブバンドで Unified CM に転送します。ここで、これらのトーンは、アウトオブバンド シグナリングをサポートするエンドポイントに転送されます。この場合、DTMF 変換ではどの MTP コーデックも使用できるため、MTP は、2 つのエンドポイント間のメディア パスに常に存在します。

インバンド DTMF トーンは、RTP メディア ストリームでそのままの(可聴)トーンとして転送することもできます。ただし、この転送方式は、シスコ製品では広くサポートされていないため、通常、エンドツーエンド DTMF 転送メカニズムとしては推奨できません。インバンド オーディオ DTMF トーンは、通常、G.711 a-law または mu-law コーデックを使用した場合だけ、その再生成が信頼できるため、低帯域幅コーデックでの使用には適していません。インバンド オーディオだけが、唯一使用できる DTMF 転送メカニズムである場合、Cisco Unified Border Element を使用して、インバンド オーディオ DTMF シグナリングを RFC 2833 シグナリングに変換できます。

Unified CM SIP トランクでは、DTMF Signaling Method を No Preference に設定することを推奨します。このように設定することで、Unified CM は、最適な DTMF 転送方式を選択し、MTP 割り当てを最小に抑えることができます。

SIP Trunk Transport Protocol

SIP トランクは、メッセージ トランスポート プロトコルとして TCP、TLS(TCP を介して実行)、または UDP のいずれかを使用できます。接続状態を維持するための信頼性の高い接続指向プロトコルとして、Cisco Enterprise Unified Communications ネットワーク内では TCP が推奨されます。UDP は接続指向ではなく、信頼性も高くありません(メッセージの伝送が保証されない)。遠端デバイスの障害の検出と応答は SIP INVITE の再試行回数と SIP Trying タイマーに依存しています。SIP OPTIONS ping を使用して、ダイナミックに各 SIP トランク上の各宛先 IP アドレスの状態、およびトランク全体の総合的な状態を追跡します。

SIP トランク タイマーの調整の詳細については、次に示す設定例およびテクニカル ノートを参照してください。

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_configuration_example09186a008082d76a.shtml


) TCP が Cisco Enterprise Unified Communications ネットワーク内で推奨される転送プロトコルですが、ほとんどのサービス プロバイダーは、処理オーバーヘッドが TCP より低い UDP の使用を好みます。Cisco Unified Border Element は、Enterprise Unified Communications ネットワークに TCP ベースの SIP トランク接続を、サービス プロバイダー ネットワークに UDP ベースの SIP トランク接続を提供するために使用できます。


安全な SIP トランク

安全な SIP トランクには次の 2 つのプロセスが必要です。

メディアを暗号化するようにトランクを設定する(「メディア暗号化」を参照)

シグナリングを暗号化するようにトランクを設定する(「シグナリング暗号化」を参照)

メディア暗号化

メディア暗号化を SIP トランクで設定するには、トランクの [SRTP allowed] チェックボックスをオンにします。[SRTP allowed] をオンにすると、コールのメディアは暗号化されますが、トランクのシグナリングは暗号化されない点に注意してください。結果として、安全なメディア ストリームの確立に使用されるセッション キーは暗号化されていない状態で送信されます。そのため、Unified CM と宛先 SIP トランク デバイス間のシグナリングも暗号化し、キーや他のセキュリティ関連の情報がコールのネゴシエーション中に漏洩しないようにすることが重要です。

シグナリング暗号化

SIP トランクはシグナリング暗号化に TLS を使用します。TLS は SIP トランクに関連付けられた SIP セキュリティ プロファイルで設定します。また、TLS は X.509 証明書の交換を使用してトランク デバイスを認証し、シグナリング暗号化を可能にしています。

証明書は、次のいずれかの処理が実行されます。

各 Unified CM ノードの SIP トランク デーモンに対して TLS 接続を確立したい各デバイスから、そのノードに対してインポートします。

認証局(CA)から署名されます。この場合、リモート デバイスの証明書をインポートする必要はありません。インポートする必要があるのは CA 証明書のみです。

Unified CM には、証明書の一括インポートおよびエクスポート機能があります。ただし、[Run on all Active Unified CM Nodes] および最大 16 の宛先アドレスを使用する SIP トランクの場合、認証局を使用するほうが、管理上の負荷の少ない集中管理的な方法で SIP トランクにシグナリング暗号化を設定できます。

SIP トランクの TLS の詳細については、次のサイトで入手可能な最新バージョンの『 Cisco Unified Communications Manager Security Guide 』を参照してください。

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

認証局については、次のサイトで入手可能な最新バージョンの『 Cisco Unified Communications Operating System Administration Guide 』で認証局(CA)の情報を参照してください。

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

システムが安全なメディアまたはシグナリング パスを確立でき、さらにエンド デバイスが SRTP をサポートする場合、システムは SRTP 接続を使用します。システムが安全なメディアまたはシグナリング パスを確立できないか、1 つ以上のデバイスが SRTP をサポートしない場合、システムは RTP 接続を使用します。SRTP から RTP へのフォールバック(またはその逆)は、安全なデバイスから安全ではないデバイスへの転送の場合、または会議、トランスコーディング、保留音などの場合に発生する可能性があります。

SRTP が設定されたデバイスでは、デバイスの [SRTP Allowed] チェックボックスがオンで、そのコールでデバイスの SRTP 機能が正常にネゴシエートされた場合、Unified CM はコールを暗号化済みと分類します。これらの条件を満たさない場合、Unified CM はコールを安全ではないと分類します。デバイスが、セキュリティ アイコンを表示できる電話に接続されている場合、コールが暗号化されているときは電話機に鍵アイコンが表示されます。


) [MTP Required] チェックボックスを使用して、スタティックに SIP トランクに割り当てられている MTP は、パススルー コーデックをサポートしないため、SRTP をサポートしません。


すべてのコールで SRTP をサポートするには、ディレイド オファーについて SIP トランクを設定します。

[Early Offer support for voice and video calls (insert MTP if needed)] が設定されている場合、暗号化をサポートするデバイスについて、MTP を使用する必要のないすべてのコールが SRTP をサポートできます。MTP をコール パスに挿入する場合、このダイナミックに挿入された MTP はパススルー コーデックをサポートするため、次の場合に暗号化されたコールがサポートされます。

古い SCCP ベースの電話が発信元デバイスとして Unified CM に登録されている場合、最初のコール セットアップ時に SRTP をネゴシエートできます。

ディレイド オファー SIP トランクまたは H.323 Slow Start トランクで Unified CM に対してコールを着信した場合、最初のコール セットアップ時に SRTP はネゴシエートされません。これは、使用できるセキュリティ キーがないためです。ただし、コール メディアを再ネゴシエートする場合(保留/再開後など)、SRTP をサポートするようにコール中にコールをエスカレーションできます。

アーリー オファー以外の理由(信頼されたリレー ポイントのためや、RSVP エージェントとしてなど)で、Unified CM がダイナミックに MTP を挿入する場合、パススルー コーデックをサポートする MTP で SRTP がサポートされます。

MTP を使用する dtmf-relay は(MTP が、インバンドおよびアウトオブバンド DTMF 信号を変換する必要がある場合)、メディア ストリームの DTMF パケットを復号化できないため、SRTP では機能しないので注意してください。


) SRTP は SAF 対応 SIP トランクではサポートされません。


発呼側番号の変換および SIP トランク

Unified CM には、ゲートウェイおよびトランクを介して着信するコールの発呼側番号を正規化形式に変換する機能があります。通常、この形式は、E.164 仕様に従ってグローバルにルーティングできる国際的な番号表現にします。

正規化のプロセスは、着信コールの番号および関連する番号タイプに依存します。番号タイプ パラメータは、発呼側番号のプレフィックスとして付加する適切な番号を選択するときに使用できます。番号タイプは、Unknown、Subscriber、National、または International のいずれかです。これらの番号タイプがどのように使用されるかについての詳細および例については、「ダイヤル プラン」の章を参照してください。

Unified CM の H.323 トランクおよび H.323 ゲートウェイの設定ページで 4 つの番号タイプのそれぞれに対してプレフィックス番号を指定できます。H.323 では、これらの番号タイプをシグナリング時に転送できます。対照的に、SIP では、番号タイプ情報をそのシグナリング時に転送できません。そのため、SIP トランク上の SIP ゲートウェイを介して Unified CM に着信するコールでは、発呼側番号が local、regional、national のいずれかであるかが示されません。番号タイプ情報がない場合、Unified CM は、発呼側番号に正しいプレフィックスを適用できません。

SIP トランクでは番号タイプを転送できないため、発呼側番号の正規化は、コールが Unified CM に送られる前に実行する必要があります。この変換は、たとえば、着信 SIP ゲートウェイで実行できます。次の設定例は、このような変換を実行するために Cisco IOS ゲートウェイで定義できる変換ルールを示しています。

voice translation-rule 1
rule 1 // /+4940/ type subscriber subscriber
rule 2 // /+49/ type national national
rule 3 // /+/ type international international
...
voice translation-profile 1
translate calling 1
...
dial-peer voice 300 voip
translation-profile outgoing 1
destination-pattern .T
session protocol sipv2
session target ipv4:9.6.3.12
...
 

上記の例のように設定されている場合、Unified CM との通信に SIP を使用する Cisco IOS ゲートウェイは、+ 記号を含む、E.164 形式に正規化された発信側情報番号を送信します。この Unified CM 設定では、番号タイプが「unknown」のすべてのコールが、このゲートウェイから受信されます。プレフィックスを追加する必要はありません。

変換ルールの設定の詳細については、次のサイトから利用できる『 Voice Translation Rules 』マニュアルを参照してください。

http://www.cisco.com/en/US/tech/tk652/tk90/technologies_tech_note09186a0080325e8e.shtml

Unified CM は、発信コールの発呼側番号を、正規化されたグローバル形式に設定できます。SIP トランクから発信されるコールの番号タイプは「unknown」になります。Cisco IOS ゲートウェイは、除去が行われない場合はこの番号タイプを International に変更し、接続サービス プロバイダーにより要求された場合は除去と番号タイプ変更の両方を実行しなければなりません。

SIP トランク サービス タイプ

ほとんどの SIP トランクは、他の Cisco Unified CM、Cisco Unified Border Element、Cisco Unified Gateway などのさまざまな SIP サーバに接続できる、汎用目的トランクです。これらの汎用目的トランク以外に、Unified CM には、特定のサービス専用の SIP トランクも用意されています。これらの特殊目的トランクによって、次のようなテクノロジーを使用できるようになります。

Cisco Intercompany Media Engine(IME)

「Cisco Intercompany Media Engine」を参照してください。

Cisco IOS Service Advertisement Framework(SAF)による Cisco Unified Communications Call Control Discovery(CCD; 呼制御ディスカバリ)

「Service Advertisement Framework(SAF)」を参照してください。

Cisco Extension Mobility Cross Cluster(EMCC)

「クラスタ間のエクステンション モビリティ(EMCC)」を参照してください。

SIP トランクの設計上の考慮事項

SIP クラスタ間トランクに関する考慮事項

クラスタ間トランク接続の場合、各クラスタに設定されている SIP トランクは標準の Unified CM Group または [Run on all Active Unified CM Nodes] 機能を使用している可能性があります。各機能を使用する理由は、一般的にクラスタで使用されている Unified CM バージョンによって決定されます。または、WAN を介したクラスタリングが展開され、地理的な位置に基づくコールの分配が必要な場合に決定されます。

SIP クラスタ間トランクによる標準の Unified CM Group の使用

この種類の配置では、標準の Unified CM Group は各クラスタ内の SIP クラスタ間トランクによって使用されます。標準の Unified CM Group を使用してこの種類のトランクを定義する場合、リモート クラスタの宛先 IP アドレスとして、最大 3 つのリモート Unified CM サーバを定義する必要があります。トランクは、定義されているすべてのリモート Unified CM サーバで自動的にロード バランシングされます。リモート クラスタでは、Unified CM Group 内で、最初のクラスタ内のリモート宛先 Unified CM サーバとして定義されているものと同じ Unified CM ノードを持つ、対応する SIP クラスタ間トランクを設定することが重要です。

たとえば、クラスタ 1 にクラスタ 2 への SIP トランクがあり、クラスタ 2 にクラスタ 1 への SIP トランクがある場合は、次の設定が必要になります(図 14-10 を参照)。

クラスタ 1

サーバ B、C、および D を、クラスタ 2 への SIP トランクに関連付けられたデバイス プールで定義されている Unified CM Group のメンバーとして設定します。

SIP トランクには、宛先としてクラスタ 2 のリモート サーバ G、H、および I が設定されています。

クラスタ 2

サーバ G、H、および I を、クラスタ 1 への SIP トランクに関連付けられたデバイス プールで定義されている Unified CM Group のメンバーとして設定します。

SIP トランクには、宛先としてクラスタ 1 のリモート サーバ B、C、および D が設定されています。

図 14-10 Unified CM Group による SIP クラスタ間トランク

 

SIP クラスタ間トランクでの [Run on All Active Unified CM Nodes] の使用

この種類の配置では、各クラスタ内の SIP クラスタ間トランクによって [Run on all Active Unified CM Nodes] が使用されます。この種類のトランクを定義する場合、同一の宛先クラスタに最大 16 個のリモート Unified CM サーバを定義できます (定義する必要があるリモート サーバの数は、宛先クラスタ内のアクティブな Unified CM ノード数によって変わります)。トランクによって、定義済みリモート宛先サーバ全体のコールが自動的にロード バランシングされます。リモート クラスタの場合、[Run on all Active Unified CM Nodes] が設定された対応する SIP クラスタ間トランクを設定することが重要です。この場合、これらのノードは、最初のクラスタのリモート宛先 Unified CM サーバとして定義されます。

たとえば、クラスタ 1(4 つのアクティブなノードあり)にクラスタ 2 に対する SIP トランクがあり、クラスタ 2(5 つのアクティブなノードあり)にクラスタ 1 に対する SIP トランクがある場合、次の設定が必要です(図 14-11 を参照)。

クラスタ 1 には、4 つのアクティブな Unified CM ノードがあります(A、B、C、および D)。

[Run on all Active Unified CM Nodes] を有効にすると、サーバ A、B、C、および D では、アクティブな SIP トランク デーモンがクラスタ 2 に対する SIP トランクと関連付けられます。

SIP トランクには、宛先としてクラスタ 2 のリモート サーバ E、F、G、H、および I が設定されています。

クラスタ 2 には、5 つのアクティブな Unified CM ノードがあります(E、F、G、H、および I)。

[Run on all Active Unified CM Nodes] を有効にすると、サーバ E、F、G、H、および I では、アクティブな SIP トランク デーモンがクラスタ 1 に対する SIP トランクと関連付けられます。

SIP トランクには、クラスタ 1 のリモート サーバ A、B、C、および D が設定されています。

図 14-11 すべてのアクティブな Unified CM ノードで実行される SIP クラスタ間トランク

 

SIP クラスタ間トランクによる標準の Unified CM Group および [Run on All Active Unified CM Nodes] の使用

この種類の配置では、1 つのクラスタ内の SIP クラスタ間トランクで [Run on all Active Unified CM Nodes] が使用され、他のクラスタ内の SIP クラスタ間トランクでは標準の Unified CM Group が使用されます。このようなトランクを設定する場合、定義するリモート Unified CM サーバの宛先の数は、宛先クラスタの対応するトランクに関連付けられたアクティブな Unified CM ノードの数と一致する必要があります。トランクによって、定義されているすべてのリモート宛先 Unified CM サーバでコールが自動的にロード バランシングされます。リモート クラスタの場合、アクティブな SIP デーモンを持つ Unified CM ノードがある、対応する SIP クラスタ間トランクを設定することが重要です。この場合、これらのノードは、最初のクラスタのリモート宛先 Unified CM サーバとして定義されます。

たとえば、クラスタ 1 にクラスタ 2 へのトランクがあり、クラスタ 2 にクラスタ 1 へのトランクがある場合は、次の設定が必要になります(図 14-12 を参照)。

クラスタ 1 には、5 つのアクティブな Unified CM ノードがあります(A、B、C、D、および E)。

[Run on all Active Unified CM Nodes] を有効にすると、サーバ A、B、C、D、および E では、アクティブな SIP トランク デーモンがクラスタ 2 に対する SIP トランクと関連付けられます。

SIP トランクには、宛先としてクラスタ 2 のリモート サーバ G、H、および I が設定されています。

クラスタ 2 には 5 つのアクティブな Unified CM ノードがあり、ノード G、H、および I を含む Unified CM Group と共にクラスタ間トランクを使用しています。

サーバ G、H、および I を、クラスタ 1 への SIP トランクに関連付けられたデバイス プールで定義されている Unified CM Group のメンバーとして設定します。

SIP トランクには、宛先としてクラスタ 1 のリモート サーバ A、B、C、D、および E が設定されています。

図 14-12 Unified CM Groups および [Run on All Active Unified CM Nodes] を使用する SIP クラスタ間トランク

 

マルチクラスタ配置のトランクの種類と機能に関する推奨事項

すべて Unified CM 8.5 以降のリリースを実行する複数のクラスタ

すべてのクラスタが Unified CM 8.5 以降のリリースを実行している場合、適用可能な場合は次の SIP トランク機能を使用する必要があります(図 14-13 を参照)。

SIP OPTIONS ping

SIP ディレイド オファー

音声およびビデオをサポートするアーリー オファー(必要に応じて MTP を挿入)

すべてのアクティブな Unified CM ノードで実行

複数の宛先 IP アドレス

オーディオ コーデック プリファレンス リスト

QSIG over SIP

SIP の正規化および透過性

これらの機能を展開すると、MTP の使用が軽減され、ハイ アベイラビリティを実現し、コールを均等に分配し、SIP トランク障害をダイナミックに検出できます。Unified CM SIP トランクの場合、SIP ディレイド オファーと SIP アーリー オファーの両方を使用できます。Unified CM ディレイド オファー トランクの SIP オファー/アンサー交換に MTP は必要ではありません。Unified CM アーリー オファー トランクの場合、[MTP Required] を使用した SIP アーリー オファーではなく、SIP の [Early Offer for voice and video (insert MTP if needed)] が優先コンフィギュレーション オプションになります。アーリー オファー トランク経由のコール確立には、通常 MTP リソースが必要ないためです。

通常、ディレイド オファー コールを確立するのに MTP は不要なため、Unified CM SIP トランクからの発信コールでは、ディレイド オファーが適切です。Unified CM SIP トランクへの着信コールでは、アーリー オファーまたはディレイド オファー(あるいはアーリー オファーとディレイド オファー両方の混在)を使用できます。

SIP クラスタ間トランクは、Unified CM クラスタ間で音声メディア、ビデオ メディア、および暗号化されたメディアをサポートします。また、上記のすべての機能を使用できます。ルート リストで複数のトランクを使用する場合、ルート リストで [Run on All Active Unified CM Nodes] 機能を有効にします。

IP PSTN に対する SIP トランクの場合、一般的に、SIP アーリー オファーはサービス プロバイダーによって要求され、ほとんどのプロバイダーは音声コールのみをサポートします。ただし、必要に応じて、ビデオ コールおよび暗号化されたメディアもサポートされます。SIP アーリー オファーがサービス プロバイダーによって要求される場合、Unified CM SIP トランクでアーリー オファーを設定する代わりに Cisco Unified Border Element(SIP ディレイド オファーからアーリー オファーへの変換機能)を使用できます。Unified CM SIP トランクへの着信コールでは、アーリー オファーまたはディレイド オファー(あるいはアーリー オファーとディレイド オファー両方の混在)を使用できます。サービス プロバイダーの IP PSTN ネットワークに接続する場合、エンタープライズ エッジ セッション ボーダー コントローラとして Cisco Unified Border Element を使用し、企業ネットワークとサービス プロバイダーのネットワーク間に制御された境界およびセキュリティ ポイントを用意することが強く推奨されます。

サードパーティのユニファイド コミュニケーション システムに対する SIP トランクは、音声メディア、ビデオ メディア、および暗号化されたメディアをサポートする可能性があります。エンド システムの機能を確認して、サポートする SIP トランク機能およびメディア機能を判断してください。Unified CM SIP トランクからの発信コールでは、ディレイド オファーまたはアーリー オファーを使用できます。Unified CM SIP トランクへの着信コールでは、アーリー オファーまたはディレイド オファー(あるいはアーリー オファーとディレイド オファー両方の混在)を使用できます。


) Cisco IOS ゲートウェイ上の SIP トランクは、常にアーリー オファーを送信します。


IP PSTN およびサードパーティのユニファイド コミュニケーション システムに対する SIP トランク接続の場合、正規化と透過性のスクリプトを使用して、SIP の相互運用性に関する問題に対処できます。

図 14-13 Unified CM 8.5 以降のリリースによるマルチクラスタ配置

 

Unified CM 8.5 以前のリリースを実行するマルチクラスタ

リーフ クラスタが、旧リリースの Unified CM を実行中のリーフ クラスタと Unified CM 8.5 以降のリリースを組み合わせて実行している場合、次のトランクの種類と機能を使用する必要があります(図 14-14 を参照)。

リーフ クラスタが旧バージョン(8.5 よりも前)の Unified CM を実行し、音声、ビデオ、および暗号化が必要な場合、必要に応じて、H.323 Slow Start クラスタ間トランクおよび Annex M1(QSIG)を使用します。標準の Unified CM Group および最大 3 つの宛先 IP アドレスを使用して、1 つまたは複数の H.323 Slow Start クラスタ間トランクを配置します。ルート リストで複数のトランクを使用する場合、ルート リストの Unified CM Group に含まれるプライマリ サーバが、関連する発信 H.323 トランクと同じノードに存在しないように、ルート ローカル ルール(前述を参照)を設定します。

Unified CM 8.5 以降のリリースを実行するリーフ クラスタの場合、SIP ディレイド オファー トランクまたはアーリー オファー(音声およびビデオ用(必要な場合 MTP を挿入))クラスタ間トランクを使用し、[Run on All Active Unified CM Nodes] をイネーブルにし、ハイ アベイラビリティと均等なコール配分のために複数宛先の IP アドレスと SIP OPTIONS ping を使用します。ルート リストで複数のトランクを使用する場合、ルート リストで [Run on All Active Unified CM Nodes] 機能を有効にします。

Unified CM 8.5(以降)リーフ クラスタで SIP ディレイド オファーまたはアーリー オファー(音声およびビデオ用(必要な場合 MTP を挿入))クラスタ間トランクを使用し、旧バージョンの Unified CM を使用するリーフ クラスタで H.323 Slow Start クラスタ間トランクを使用すると、クラスタ間で音声コール、ビデオ コール、および暗号化コールを実行でき、必要な MTP 数が軽減されます。

IP PSTN に対する SIP トランクの場合、一般的に、SIP アーリー オファーはサービス プロバイダーによって要求され、ほとんどのプロバイダーは音声コールのみをサポートします。ただし、必要に応じて、ビデオ コールおよび暗号化されたメディアもサポートされます。SIP アーリー オファーがサービス プロバイダーによって要求される場合、Unified CM SIP トランクでアーリー オファーを設定する代わりに Cisco Unified Border Element(SIP ディレイド オファーからアーリー オファーへの変換機能)を使用できます。Unified CM SIP トランクへの着信コールでは、アーリー オファーまたはディレイド オファー(あるいはアーリー オファーとディレイド オファー両方の混在)を使用できます。サービス プロバイダーの IP PSTN ネットワークに接続する場合、エンタープライズ エッジ セッション ボーダー コントローラとして Cisco Unified Border Element を使用し、企業ネットワークとサービス プロバイダーのネットワーク間に制御された境界およびセキュリティ ポイントを用意することが強く推奨されます。

サードパーティのユニファイド コミュニケーション システムに対する SIP トランクは、音声メディア、ビデオ メディア、および暗号化されたメディアをサポートする可能性があります。エンド システムの機能を確認して、サポートする SIP トランク機能およびメディア機能を判断してください。Unified CM SIP トランクからの発信コールでは、ディレイド オファーまたはアーリー オファーを使用できます。Unified CM SIP トランクへの着信コールでは、アーリー オファーまたはディレイド オファー(あるいはアーリー オファーとディレイド オファー両方の混在)を使用できます。


) Cisco IOS ゲートウェイ上の SIP トランクは、常にアーリー オファーを送信します。


IP PSTN およびサードパーティのユニファイド コミュニケーション システムに対する Unified CM SIP トランク接続の場合、正規化と透過性のスクリプトを使用して、SIP の相互運用性に関する問題に対処できます。

図 14-14 Unified CM 8.5 以前のリリースによるマルチクラスタ配置

 

WAN を介したクラスタリングに関するトランク設計の考慮事項

空間的な復元力と冗長性のために WAN を介したクラスタリングを展開する場合、OPTIONS ping、音声およびビデオのためのアーリー オファーのサポート(必要に応じて MTP を挿入)、QSIG などの SIP トランク機能を必要に応じて適切に使用できます。[Run on all Unified CM Nodes] や複数の宛先アドレスなどの SIP および H.323 トランク機能は、主にトランクが着信コールの識別と受け入れに使用するメカニズムのため、慎重に使用する必要があります (着信の送信元 IP アドレスが、宛先 IP アドレスとして定義されているアドレスのいずれかに一致すると、トランクはコールを受け入れます)。

地理的な位置に基づいて、異なるグループの Unified CM ノードにコールをルーティングする必要がある、WAN を介したクラスタリングの展開の場合、着信と発信の両方についてトランク設定を慎重に検討する必要があります。この点については、WAN 上でクラスリングされる Unified CM Session Management Edition クラスタを例に使用して、次の項で説明します。

リーフ クラスタ トランクがある WAN を介したクラスタリングに関する設計ガイドライン

各リーフ クラスタでルート リストに複数の SIP トランクを作成し、優先順位を付けて、各データセンター内の Unified CM Session Management Edition ノードの各グループにコールを分配し、すべてのノードでルート リストを実行します (図 14-15 を参照)。

各リーフ クラスタの SIP トランクで [Run on all Nodes] を有効にします(各 SIP トランクは一意の着信ポート番号を使用する必要があります)。地理的なコール分配のために、トランクごとに宛先 IP アドレスを定義します。

図 14-15 リーフ クラスタから Unified CM Session Management Edition へのコール

 

Unified CM Session Management Edition クラスタ トランクがある WAN を介したクラスタリングに関する設計ガイドライン

各リーフ クラスタで、Unified CM Session Management Edition クラスタ上に単一の SIP トランクを作成します。この SME トランクで [Run on all Unified CM Nodes] を有効にし、リーフ クラスタ内の各呼処理ノードの宛先 IP アドレスを設定します。(図 14-16 を参照)。

図 14-16 Unified CM Session Management Edition からリーフ クラスタに対するコール

 

その他の SIP トランク配置に関する考慮事項

監視されている場合、音声クリッピングは、トランクで PRACK を有効にすることで、最小化または削減できます。PRACK 機能は、SIP トランクの [SIP Profile Configuration] の [Trunk Specific Configuration] セクションの [SIP Rel1XX Options] でイネーブルにできます。両方の SIP Unified Communications システムで PRACK がサポートされている必要があることに注意してください。

セキュリティ設定や SIP トランクを介して受け入れられるメッセージのタイプなどの他の操作パラメータは、SIP Trunk Security Profile で有効にできます。ここでは、TLS およびダイジェスト認証のパラメータだけでなく、トランクが Presence Subscription、Out-Of-Dialog REFER メッセージ、Replaces ヘッダー、または Unsolicited Notification メッセージを受け入れるかどうかを指定するパラメータも設定できます。

SIP トランクは、SIP プレコンディションを使用するトポロジ対応の RSVP コール アドミッション制御と、基礎となる WAN トポロジを意識しないロケーションベースのコール アドミッション制御をサポートします。

サービス プロバイダー ネットワークに接続する場合、Cisco Unified Border Element を使用することを推奨します。企業とサービス プロバイダーのネットワーク間への境界ポイント提供のほか、Cisco Unified Border Element は、2 つのネットワーク間でのアドレスの隠蔽と SIP シグナリング相互運用性の拡張にも使用できます。

Cisco Unified Border Element の詳細については、次のサイトで入手可能なマニュアルを参照してください。

http://www.cisco.com/en/US/products/sw/voicesw/ps5640/index.html

H.323 トランクの概要

H.323 トランクは、ゲートウェイ、Unified CM Session Management Edition、ゲートキーパー、Unified Communications アプリケーション、その他の Unified CM クラスタなど、他の H.323 デバイスに接続を提供します。Cisco Unified CM は、すべての H.323 トランク タイプについて、次のようにコール ルーティングを拡張します。

すべての Unified CM ノードでルート リストを実行

この機能に加え、H.323 非ゲートキーパー制御のクラスタ間トランクも、次の機能をサポートします。

すべての Unified CM ノードで実行

各トランクで最大 16 の宛先 IP アドレスをサポート

これら 2 つの機能によって、Unified CM クラスタからの発信の分配が改善され、クラスタ間に必要な H.323 非ゲートキーパー制御のクラスタ間トランク数が軽減されます。

これらの機能とその動作について詳しくは、この項で後述します。

H.323 トランクの新規拡張機能の全リストについては、次の Web サイトで入手可能な最新の Cisco Unified Communications Manager の製品リリース ノートを参照してください。

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

一般的な H.323 クラスタ間トランク配置に関する考慮事項

Unified CM 8.5 よりも前のリリースでは、H.323 Annex M1 トランクは Unified CM クラスタ間の接続によく使用される選択肢でした。Unified CM SIP トランクは、H.323 クラスタ間トランクと比較してより多くの機能を提供しているため、クラスタ間トランクの接続に使用するプロトコルとして SIP が選択されるようになりました。ただし、旧ソフトウェア バージョンを使用する Unified CM クラスタの多数は、H.323 Annex M1 クラスタ間トランクで配置される可能性が高いため、このようなクラスタに使用するクラスタ間トランク タイプが決まる可能性があります。

H.323 トランクの基本的な操作

H.323 トランクは、他の Unified CM クラスタや、ゲートウェイなどの他の H.323 デバイスに対する接続性を提供します。H.323 トランクは、Unified CM がクラスタ内通信用にサポートするオーディオおよびビデオ コーデックのほとんどをサポートします。ただし、ワイドバンド オーディオおよびワイドバンド ビデオについてはサポートしません。

H.323 トランクは、Empty Capabilities Set(ECS)を使用して、保留/保留解除や転送などの付加コール サービスを提供します。この方式は、メディア ストリーム(またはチャネル)を停止または終了し、同一または別のエンドポイント アドレスに対してメディア ストリームを開始または起動するための標準の H.245 メカニズムです。この方式を使用すると、Unified CM は、コールをアクティブにしたままでも、メディア ストリームの送信元および宛先を迅速に制御できます。

たとえば、H.323 トランクを使用した 2 つのクラスタ(A と B)間のコールについて考えます。クラスタ A のユーザがクラスタ B のユーザを保留にした場合、2 人のユーザ間のメディア ストリームは終了し、クラスタ B のユーザはクラスタ A の保留音(MoH)サーバに接続されます。MoH サーバは、ユーザにメディア(音楽ファイル)を送信するよう指示されます。クラスタ A のユーザがコールを保留解除すると、MoH ストリームが終了し、2 人のユーザ間で双方向メディア ストリームが再開されます (Unified CM は、付加コール サービス用に H.450 をサポートしていません)。このケースでは、MoH は ECS 動作の一例です。H.323 トランクはマルチキャスト MoH をサポートするため、H.323 トランクのメディア リソース グループ リスト(MRGL)は、ユニキャストおよびマルチキャスト両方の MoH 送信元を含む可能性があります (詳細については、「保留音(Music on Hold)」を参照してください)。

H.323 トランク上のコールに使用される帯域幅を制御するには、Unified CM で設定される、各トランクに割り当てられるリージョンを使用します。音声についてはリージョン間の最大音声ビット レートを指定し、ビデオ(音声込み)についてはリージョン間の最大ビデオ コール ビット レート設定を指定することで、コールに割り当てられる帯域幅の量が制限されます。1 つのリージョンと別のリージョン間のコールは、指定された帯域幅の制限内にする必要があります。H.323 トランク上でコールを発信するデバイスが、より限定的なリージョン内にある場合や、ビデオなどの特定のコーデックをサポートしない場合、そのデバイスはそのコールに使用可能なコーデックのサブセットになっています。

H.323 トランク タイプ

Unified CM では、次の主要なタイプの H.323 トランクを設定できます。

「クラスタ間トランク(非ゲートキーパー制御)」

「クラスタ間トランク(ゲートキーパー制御)」

「H.225 トランク(ゲートキーパー制御)」

これらの各 H.323 トランク タイプとその具体的な設計の考慮事項については、次の項で説明します。

クラスタ間トランク(非ゲートキーパー制御)

このトランクは、最も単純な H.323 トランク タイプで、単一のマルチクラスタ キャンパスまたは分散型呼処理配置で他の Unified CM クラスタに接続するために使用されます。このトランクは、コール アドミッション制御にゲートキーパーを使用しません。ただし、帯域幅制御が必要な場合は、Unified CM で設定されたロケーションを使用できます。

Cisco Unified CM は、次のトランク機能と、H.323 非ゲートキーパー制御のクラスタ間トランクに関するコール ルーティングの強化をサポートしています。

すべてのアクティブな Unified CM ノードで実行

各トランクで最大 16 の宛先 IP アドレスをサポート

すべての Unified CM ノードでルート リストを実行

これらの機能については、次の項で説明します。

すべてのアクティブな Unified CM ノードで実行される H.323 非ゲートキーパー クラスタ間トランク

H.323 非ゲートキーパー クラスタ間トランクで [Run on all Active Unified CM Nodes] オプションがオンの場合、Unified CM は各呼処理 Unified CM Group で H.323 トランク デーモンのインスタンスを作成します。これによって、H.323 非ゲートキーパー クラスタ間トランク コールは、どの呼処理サブスクライバでも発着信できます。[Run on all Active Unified CM Nodes] を有効にすると、発信 H.323 非ゲートキーパー クラスタ間トランク コールは、(電話やトランクなどからの)着信を受信したのと同じサーバから発信されます。すべての Unified CM H.323 非ゲートキーパー クラスタ間トランクと同様に、トランクに関連付けられている H.323 デーモンは、トランクの宛先アドレス フィールドに定義されている IP アドレスを持つエンド システムからの着信のみを受け入れます。大量のコールを処理するために、H.323 非ゲートキーパー クラスタ間トランクが必要な場合、すべてのノードで H.323 非ゲートキーパー クラスタ間トランクを実行することが推奨されます。これによって、発信および着信の分配を、クラスタ内のすべての呼処理サブスクライバに均等に分散できます。ただし、(SIP トランクとは異なり)H.323 非ゲートキーパー クラスタ間トランクでは固定の宛先ポートと一時的な送信元を使用するため、 H.323 非ゲートキーパー クラスタ間トランクはポート番号を使用して区別できません。H.323 非ゲートキーパー クラスタ間トランクを設定し、[Run on all Active Unified CM Nodes] を有効にする場合、各トランクが異なる宛先 IP アドレスを使用するようにしてください。

1 つの H.323 非ゲートキーパー クラスタ間トランクあたり最大 16 の宛先 IP アドレス

H.323 非ゲートキーパー クラスタ間トランクには、最大 16 の宛先 IP アドレスを設定できます。追加の宛先 IP アドレスをサポートしているため、2 つの Unified Communications システム間のコール分配のために、ルート リストおよびルート グループに関連付けられた複数のトランクを作成する必要性が軽減されます。結果として、Unified CM トランク設計が単純になります この機能は、[Run on all Active Unified CM Nodes] 機能と併用できます。ただし、Unified CM H.323 非ゲートキーパー クラスタ間トランクに関連付けられた H.323 デーモンの場合、トランクの宛先アドレス フィールドに定義された IP アドレスを持つエンド システムからの着信のみを受け入れる点に注意してください。

すべてのアクティブな Unified CM ノードで実行されるルート リスト

これは具体的には H.323 非ゲートキーパー クラスタ間トランク機能ではありませんが、すべてのノードでルート リストを実行すると、ルート リストおよびルート グループ内のトランクに利点があります。ルート ローカル ルールを使用してすべてのノードでルート リストを実行すると、発信の分配が改善され、不要なクラスタ内トラフィックを回避できます。

ルート リストの場合、ルート ローカル ルールは次のように動作します。

ルート リストおよび関連するルート グループとトランクを使用する発信の場合、登録されている電話または着信トランクからのコールが、発信に選択されたトランクに関連付けられたルート リスト インスタンスがあるノードに到達したときに、選択した発信トランクのインスタンスがルート リストと同じノードに存在するかどうかが Unified CM によって確認されます。存在する場合、Unified CM はそのノードを使用して発信トランク コールを確立します。

ルート リストと選択した発信トランクの両方で [Run on all Active Unified CM Nodes] が有効の場合、発信の分配は、着信が到達したノードによって決定されます。すべてのノードでの実行ではなく、選択した発信トランクが Unified Group を使用すると、選択した発信トランクのインスタンスが、着信が到達した同じノードに存在する場合に、Unified CM はルート ローカル ルールを適用します。トランクのインスタンスがそのノードに存在しない場合、Unified CM は(クラスタ内の)コールをトランクがアクティブなノードに転送します。

ルート リストで [Run on all Active Unified CM Nodes] を有効にしていない場合、ルート リストはクラスタ内の 1 つのノード(ルート リストの Unified Group のプライマリ ノード)でアクティブになり、ルート ローカル ルールはそのノードに適用されます。

一般的な推奨事項として、[Run on all Active Unified CM Nodes] はすべてのルート リストで有効にしてください。

H.323 非ゲートキーパー クラスタ間トランクに関する設計ガイドライン

クラスタ間トランクの接続の場合、各クラスタに設定されている H.323 非ゲートキーパー クラスタ間トランクは標準の Unified CM Group または [Run on all Active Unified CM Nodes] 機能を使用している可能性があります。各機能を使用する理由は、一般的にクラスタで使用されている Unified CM バージョンによって決定されます。または、WAN を介したクラスタリングが展開され、地理的な位置に基づくコールの分配が必要な場合に決定されます。

H.323 非ゲートキーパー クラスタ間トランクによる標準の Unified CM Group の使用

この種類の配置では、標準の Unified CM Group は各クラスタ内の H.323 非ゲートキーパー クラスタ間トランクによって使用されます。標準の Unified CM Group を使用してこの種類のトランクを定義する場合、宛先クラスタで最大 3 つのリモート Unified CM サーバを定義する必要があります。トランクによって、リモート宛先アドレスとして定義されているすべてのサーバでコールが自動的にロード バランシングされます。リモート クラスタでは、Unified CM Group 内で、最初のクラスタ内のリモート宛先 Unified CM サーバとして定義されているものと同じ Unified CM ノードを持つ、対応するクラスタ間トランク(非ゲートキーパー制御)を設定することが重要です。

たとえば、クラスタ 1 にクラスタ 2 へのトランクがあり、クラスタ 2 にクラスタ 1 へのトランクがある場合は、次の設定が必要になります(図 14-17 を参照)。

クラスタ 1

サーバ B、C、および D を、クラスタ 2 への非ゲートキーパー制御トランクに関連付けられたデバイス プールで定義されている Unified CM Group のメンバーとして設定します。

非ゲートキーパー制御トランクには、宛先としてクラスタ 2 のリモート サーバ G、H、および I が設定されています。

クラスタ 2

サーバ G、H、および I を、クラスタ 1 への非ゲートキーパー制御トランクに関連付けられたデバイス プールで定義されている Unified CM Group のメンバーとして設定します。

非ゲートキーパー制御トランクに、宛先としてクラスタ 1 のリモート サーバ B、C、および D を設定します。

図 14-17 標準の Unified CM Group を使用する H.323 非ゲートキーパー クラスタ間トランク

 

H.323 非ゲートキーパー クラスタ間トランクによる [Run on All Active Unified Nodes] の使用

この種類の配置では、各クラスタ内の H.323 非ゲートキーパー クラスタ間トランクによって [Run on all Active Unified CM Nodes] が使用されます。この種類のトランクを定義する場合、同一の宛先クラスタに最大 16 個のリモート Unified CM サーバを定義できます (必要なリモート サーバの数は、宛先クラスタ内のアクティブな Unified CM ノード数によって変わります)。トランクによって、定義済みリモート宛先 Unified CM サーバ全体のコールが自動的にロード バランシングされます。リモート クラスタの場合、[Run on all Active Unified CM Nodes] が設定された対応するクラスタ間トランク(非ゲートキーパー制御)を設定することが重要です。この場合、これらのノードは、最初のクラスタのリモート宛先 Unified CM サーバとして定義されます。

たとえば、クラスタ 1(4 ノード)にクラスタ 2 へのトランクがあり、クラスタ 2(5 ノード)にクラスタ 1 へのトランクがある場合は、次の設定が必要になります(図 14-18 を参照)。

クラスタ 1 には、4 つのアクティブな Unified CM ノードがあります(A、B、C、および D)。

[Run on all active Unified CM Nodes] を有効にすると、サーバ A、B、C、および D では、アクティブな H.323 トランク デーモンがクラスタ 2 に対する非ゲートキーパー制御トランクと関連付けられます。

非ゲートキーパー制御トランクには、宛先としてクラスタ 2 のリモート サーバ E、F、G、H、および I が設定されています。

クラスタ 2 には、5 つのアクティブな Unified CM ノードがあります(E、F、G、H、および I)。

[Run on all active Unified CM Nodes] を有効にすると、サーバ E、F、G、H、および I では、アクティブな H.323 トランク デーモンがクラスタ 2 に対する非ゲートキーパー制御トランクと関連付けられます。

非ゲートキーパー制御トランクに、クラスタ 1 のリモート サーバ A、B、C、および D を設定します。

図 14-18 [Run on All Active Unified Nodes] を使用する H.323 非ゲートキーパー クラスタ間トランク

 

H.323 非ゲートキーパー クラスタ間トランクによる標準の Unified CM Group および [Run on All Active Unified CM Nodes] の使用

この種類の配置では、1 つのクラスタ内の H.323 非ゲートキーパー クラスタ間トランクで [Run on all Active Unified CM Nodes] が使用され、他のクラスタ内の H.323 非ゲートキーパー クラスタ間トランクでは標準の Unified CM Group が使用されます。このようなトランクを設定する場合、定義するリモート Unified CM サーバの宛先の数は、宛先クラスタの対応するトランクのアクティブな Unified CM ノードの数と一致する必要があります。トランクによって、定義されているすべてのリモート宛先 Unified CM サーバでコールが自動的にロード バランシングされます。リモート クラスタの場合、アクティブな H.323 デーモンを持つ Unified CM ノードがある、対応するクラスタ間トランク(非ゲートキーパー制御)を設定することが重要です。この場合、これらのノードは、最初のクラスタのリモート宛先 Unified CM サーバとして定義されます。

たとえば、クラスタ 1 にクラスタ 2 へのトランクがあり、クラスタ 2 にクラスタ 1 へのトランクがある場合は、次の設定が必要になります(図 14-19 を参照)。

クラスタ 1 には、5 つのアクティブな Unified CM ノードがあります(A、B、C、D、 および E)。

[Run on all Active Unified CM Nodes] を有効にすると、サーバ A、B、C、D、および E では、アクティブな H.323 トランク デーモンがクラスタ 2 に対する非ゲートキーパー制御トランクと関連付けられます。

非ゲートキーパー制御トランクには、宛先としてクラスタ 2 のリモート サーバ G、H、および I が設定されています。

クラスタ 2 には 5 つのアクティブな Unified CM ノードがあり、ノード G、H、および I を含む Unified CM Group と共にクラスタ間トランクを使用しています。

サーバ G、H、および I を、クラスタ 1 への非ゲートキーパー制御トランクに関連付けられたデバイス プールで定義されている Unified CM Group のメンバーとして設定します。

H.323 非ゲートキーパー クラスタ間トランクには、宛先としてクラスタ 1 のリモート サーバ A、B、C、D、および E が設定されています。

図 14-19 標準の Unified CM Group と [Run on All Active Unified CM Nodes] を使用する H.323 非ゲートキーパー クラスタ間トランク

 

非ゲートキーパー制御クラスタ間トランクのハイ アベイラビリティ

H.323 非ゲートキーパー クラスタ間トランクのハイ アベイラビリティと冗長性を提供するには、発信に複数の送信元 Unified CM サーバと、トランクごとに複数の宛先 IP アドレスを使用します。

H.323 非ゲートキーパー クラスタ間トランク コールに対する複数の送信元 Unified CM サーバ

標準の Unified CM Group の使用

個々のトランクに関連付けられている Unified CM Group 内に定義されたノードによって、トランク経由でコールを送受信できるサーバのセットが構成されます。1 つの Unified CM グループには 3 つまでノードを定義できるため、トランク自体のハイ アベイラビリティが確保されます。

[Run on all Active Unified CM Nodes] の使用

[Run on all Active Unified CM Nodes] 機能を使用すると、クラスタ内の各呼処理サブスクライバで H.323 トランク インスタンスが作成され、有効になるため、そのノードのトランク上で発信または着信できます。

発信の H.323 非ゲートキーパー クラスタ間トランクに関する Unified CM ルート ローカル機能とサブスクライバの選択の影響

Unified CM のルート ローカル機能は、クラスタ内トラフィックを減らすために設計されています。この機能の動作について説明します。電話機などのデバイスが H.323 クラスタ間トランク ICT 1 上で発信すると、H.323 ICT 1 のインスタンスが、電話機の登録先と同じノードでアクティブな場合、クラスタ内の別のノード上にある別の H.323 ICT 1 インスタンスに対してコールを内部的にルーティングするのではなく、常にこの同居する H.323 ICT 1 インスタンスを使用します。

ノードの選択に関するルート ローカル機能の影響は、Unified CM Group と [Run on all Active Unified CM Nodes] のいずれがトランクに設定されているかによって変わります。[Run on all Active Unified CM Nodes] を設定したトランクの場合、発信デバイスの登録先ノードは、発信 H.323 クラスタ間トランク コールの発信に使用されます。Unified CM Group がトランクに使用されているときに、発信デバイスが、トランクの Unified CM Group のノードの 1 つに登録されている場合、ルート ローカル ルールが適用されます。発信デバイスが、トランクの Unified CM Group のノードの 1 つに登録されていない場合、Unified CM は、トランクの Unified CM Group のノード上でコールをランダムに分配します。

一般的に、H.323 クラスタ間トランクの場合、[Run on all Active Unified CM Nodes] の使用を推奨します。この方法を使用すると、ノード間のコールの分配が発信元デバイスによって決定され、クラスタ内のトラフィックが最小限に抑えられるためです。

1 つの H.323 非ゲートキーパー クラスタ間トランクあたりの複数の宛先 IP アドレス

単一の H.323 非ゲートキーパー クラスタ間トランクには、最大 16 の宛先 IP アドレスを設定できます。H.323 非ゲートキーパー クラスタ間トランク上で発信するときに、Unified CM では設定済み宛先 IP アドレスにラウンドロビン式の分配を使用します。

[Run on All Active Unified CM Nodes] を使用するときの設計の考慮事項

[Run on All Active Unified CM Nodes] と複数の宛先アドレスを併用する場合、着信を受け入れるには、H.323 トランクで受信した着信の送信元 IP アドレスが、着信トランクに設定されている宛先 IP アドレスと一致する必要があることに注意してください。WAN を介したクラスタリング設計を展開し、地理的なコールの分配およびフェールオーバーが必要な場合、複数のクラスタ間トランク(それぞれ最大 3 つの宛先 IP アドレスを使用)上で標準の Unified CM Group を使用し、さらにルート リストとルート グループを併用します。

H.323 非ゲートキーパー クラスタ間トランクのロード バランシング

H.323 非ゲートキーパー クラスタ間トランクのロード バランシングを設計する場合、コールの送信元ノードと宛先の両方について考慮します。H.323 非ゲートキーパー クラスタ間トランクでは、発信に使用されるノードは、ルート ローカル ルール、発信トランクがアクティブなノード数、およびルート リストを複数の発信トランクと併用するかどうかによって決定されます。次に、これらの考慮事項について説明します。

単一の H.323 非ゲートキーパー クラスタ間トランク上の発信

単一の H.323 非ゲートキーパー クラスタ間トランクは、Unified CM Group で最大 3 つの Unified CM ノードを実行できます。または、クラスタ内のすべてのアクティブな Unified CM ノードで実行できます。発信の送信元ノードを選択するために、Unified CM は次の決定プロセスを適用します。

トランクのインスタンスがすべてのノードで実行される場合、ルート ローカル ルールが適用され、各発信に使用されるノードはコールが到達するノードによって決定されます(たとえば、発信元電話が登録されているノードや、着信トランク コールが到達したノード)。Unified CM Group を使用する場合、ルート ローカル ルールは、トランクの Unified CM Group と同じノードに登録されている発信元デバイスに適用されます。クラスタ内の他のサーバに登録されている発信元デバイスの場合、Unified CM は、トランクの Unified CM Group のノード間でコールを分配します。Unified CM は、トランクの設定済み宛先アドレス間でラウンドロビン式コールの分配を使用します。1 つの H.323 非ゲートキーパー クラスタ間トランクには、最大 16 の宛先 IP アドレスを設定できます。

複数の H.323 非ゲートキーパー クラスタ間トランク上の発信

H.323 非ゲートキーパー クラスタ間トランクはすべてのアクティブな Unified CM ノードで実行でき、最大 16 の宛先アドレスを設定できるので、一般的に、2 つの Unified Communications システム間でコールを均等に分配するために、複数の H.323 非ゲートキーパー クラスタ間トランクを使用する必要はありません。複数のトランクと、ルート リストおよびルート グループを併用する場合、すべてのアクティブな Unified CM ノードで実行するには、ルート リストを有効にする必要があります。多くの場合、PSTN に対して、または WAN を介したクラスタリングの展開の一部として異なるサイトにある Unified CM サーバのグループに対してフェールオーバー機能を提供するために、複数の H.323 トランクとルート リストが併用されます。発信トランク コールの発信に使用される Unified CM ノードの選択、およびトランクの設定済み宛先 IP アドレス上のコールの分配は、単一のトランクの場合と同様の方法で決定されます。WAN を介したクラスタリング設計を展開し、地理的なコールの分配およびフェールオーバーが必要な場合、複数のクラスタ間トランク(それぞれ最大 3 つの宛先 IP アドレスを使用)と標準の Unified CM Group を、ルート リストおよびルート グループと併用します。

クラスタ間トランク(ゲートキーパー制御)

非ゲートキーパー制御トランクの代わりにクラスタ間ゲートキーパー制御トランクを使用することで、大量の Unified CM クラスタを相互接続できます。ゲートキーパー制御トランクを使用する主な利点は、クラスタとフェールオーバー時間を全体的に管理できることです。非ゲートキーパー制御トランクでは、クラスタ内のサブスクライバ サーバが到達不能になると、コールの試行時に 5 秒(デフォルト)のタイムアウトがあります。クラスタ全体が到達不能になった場合、コール障害または PSTN を介した再ルーティングのいずれかが発生するまでの試行回数は、トランク用に定義されたリモート サーバの数と、ルート リストまたはルート グループ(存在する場合)内のトランクの数によって異なります。リモート サーバと非ゲートキーパー制御トランクの数が多いと、コール遅延が過剰になることがあります。

H.323 ゲートキーパー制御トランクを使用する場合は、ゲートキーパーに登録されている他のすべてのクラスタとゲートキーパーを介して通信できるトランクを 1 つだけ設定します。クラスタまたはサブスクライバが到達不能になった場合、ゲートキーパーは自動的に、コールをクラスタ内の別のサブスクライバに送信するか、または他のサブスクライバが存在しなければコールを拒否します。その結果、ほとんど遅延させることなく、PSTN を介して(必要な場合)コールを再ルーティングできます。単一の Cisco ゲートキーパーを使用すると、100 のクラスタすべてが、それぞれ 1 つのトランクを、相互にコールできるすべてのクラスタに登録できます。クラスタ間ゲートキーパー制御トランクは、他の Unified CM と通信する場合だけ使用する必要があります。これは、このトランクを他の H.323 デバイスで使用すると、付加サービスに問題が発生することがあるためです。


) ゲートキーパー制御トランクは、[Run on All Active Unified CM Nodes] 機能をサポートしません。標準の Unified CM Group のみがサポートされます。宛先アドレスは、ゲートキーパーによって Unified CM に返されます。ゲートキーパー制御トランクをルート リストで使用する場合、ルート リストで [Run on All Active Unified CM Nodes] 機能を有効にすることを推奨します。


H.225 トランク(ゲートキーパー制御)

H.225 ゲートキーパー制御トランクは、本質的にはクラスタ間ゲートキーパー制御トランクと同じですが、Unified CM クラスタのほか、ゲートウェイ、会議システム、およびクライアントなどの他の H.323 デバイスと連携動作する機能を持つ点が異なります。この機能は、コールごとに検出メカニズムを通じて実現されます (この検出プロセスの詳細については、「Unified CM における H.323 の動作」を参照してください)。


) ゲートキーパー制御トランクは、[Run on All Active Unified CM Nodes] 機能をサポートしません。標準の Unified CM Group のみがサポートされます。宛先アドレスは、ゲートキーパーによって Unified CM に返されます。ゲートキーパー制御トランクをルート リストで使用する場合、ルート リストで [Run on All Active Unified CM Nodes] 機能を有効にすることを推奨します。


ゲートキーパー制御トランクのハイ アベイラビリティ

冗長性は、設計の要件に応じて、複数の方法で実現できます。最も簡単に実現するには、ゲートキーパー制御トランクを設定し、そのトランクに割り当てられたデバイス プールに関連付けられている Unified CM Group に、最大 3 つのサブスクライバを割り当てます。この設定により、すべてのサーバが、同じテクノロジー プレフィックスとともに、同じゾーン内の同じゲートキーパーに登録されます。ただし、h323_id に使用される H.323 トランクの名前には、「_ n 」というサフィックスが付加されます。ここで、 n はクラスタ内のノード番号です。この ID は自動的に生成され、変更できません。単一のトランクを設定しても、ゲートキーパーは、複数のトランク、つまり Unified CM Group 内のサブスクライバごとに 1 つのトランクを登録します。

追加の冗長性要件がある場合は、別のゲートキーパー制御トランクに、Unified CM Group にある別の名前と別のサブスクライバを設定できますが、それ以外のパラメータはすべて最初のトランクと同じになります。この 2 つめのトランクによって、追加のサブスクライバがゲートキーパーに登録されます。

標準のサブスクライバ ペアを構成する 2 台のサーバから Unified CM Group を構成し、このグループを含むデバイス プールを割り当てることを推奨します (サブスクライバの冗長性の詳細については、「呼処理サブスクライバの冗長性」を参照してください)。各クラスタ全体で完全な冗長性を実現するには、4 つの異なるデバイス プールを使用する 4 つのトランクが必要になります。結果的に、8 つのサブスクライバがゲートキーパーに登録されます (3 つのトランクとさらに大きい Unified CM Group を使用しても同じ結果となります)。

登録時、Unified CM とゲートキーパー間では複数のパラメータが受け渡しされます。Unified CM は、ゲートキーパーの Registration Admission Status(RAS)メッセージ用に、一時的なユーザ データグラム プロトコル(UDP)ポートを使用します。このポートは、通常であれば、UDP 1719 です。ただし、Unified CM は、特定のサーバからの RAS メッセージの発信元での H.323 デーモンを正確に特定できる必要があります。したがって、Unified CM は一定範囲の UDP ポートを使用して、動的に割り当てます。

登録プロセス時、トランクは、その Unified CM Group にある他のサブスクライバに関する次の情報を登録します。

H.225 コール シグナリング ポート

h323_id

CanMapAlias サポート

テクノロジー プレフィックス

H.225 コール シグナリング アドレス

推奨されるクラスタ化ゲートキーパーが使用されている場合、ゲートキーパーは、代替ゲートキーパー アドレスのリストを返します。このリストは、プライマリ ゲートキーパーで障害が発生した場合や使用可能なリソースが不足した場合に使用されることがあります。

図 14-20 は、Gatekeeper Update Protocol(GUP)を使用して通信する、ゲートキーパーのクラスタを示しています (ゲートキーパーの詳細については、「呼処理」の章を参照してください)。

図 14-20 ゲートキーパー クラスタ

 

H.323 トランクの Unified CM Group にサブスクライバが 1 つだけ含まれている場合、Unified CM の設定済みゲートキーパーとゲートキーパー クラスタの間の接続は 1 つだけになります(図 14-21 を参照)。

図 14-21 単一の Unified CM サブスクライバを使用する H.323 トランク

 

トランクに関連付けられた Unified CM Group に複数のサブスクライバが含まれている場合、Unified CM クラスタとゲートキーパー クラスタ間には追加の接続が確立されます(図 14-22 を参照)。

図 14-22 複数の Unified CM サブスクライバを使用する H.323 トランク

 

このアプローチによってサブスクライバ障害やゲートキーパー障害に対する冗長性が確保されるのは、登録完了後です。これは、トランクの登録時に代替ゲートキーパーの通信が行われるためです。ただし、このアプローチでは、設定済みのゲートキーパーが初期登録時やリセット後に使用不能である場合には、冗長性が確保されません。これは、代替ゲートキーパーのリストがダイナミックであり、データベースに格納されないためです。冗長性のレベルを上げたりロード バランシングを追加したりするには、ゲートキーパー クラスタにある追加のゲートキーパーを Unified CM で設定します。たとえば、元のトランクがエレメント 2 に登録されている場合は、追加のゲートキーパーをエレメント 4 として設定できます(図 14-23 を参照)。

図 14-23 ロード バランシングと追加の冗長性のために設定された追加のゲートキーパー

 

図 14-23 の例の場合、Unified CM の設定には次のコンポーネントが含まれます。

エレメント 2 とエレメント 4 の 2 つのゲートキーパー

サブスクライバ サーバ A および B を含む Unified CM Group に対して定義された 2 つの H.323 トランク

このアプローチを使用すると、初期設定時にエレメント 2 またはエレメント 4 が到達不能であっても(つまり、起動中またはトランクのリセット中でも)、引き続き Unified CM クラスタが登録できるようになります。

Unified CM クラスタに着信するコールのロード バランシングは、デフォルトで自動的に行われます。これは、ゲートキーパーが、ゾーン内の登録済みサブスクライバのいずれかをランダムに選択するためです。この動作が期待と異なる場合は、ゲートキーパーで gw-priority コンフィギュレーション コマンドを使用して、このデフォルト動作を変更できます(例 14-3 を参照)。

例 14-3 gw-priority コマンドを使用してコールを特定のトランクに送信する

gatekeeper
zone local SJC cisco.com 10.0.1.10
zone prefix SJC 1408....... gw-priority 10 sjc-trunk_2
zone prefix SJC 1408....... gw-priority 9 sjc-trunk_3
zone prefix SJC 1408....... gw-default-priority 0
gw-type-prefix 1#* default-technology
arq reject-unknown-prefix
no shutdown
endpoint ttl 60
 

例 14-3 では、H.323 トランクは Unified CM で sjc-trunk として設定されています。また、クラスタ内のサブスクライバのノード番号を示すために、「_2」と「_3」のサフィクスが Unified CM サブスクライバによって自動的に付加されています。したがって、この例では、最初の選択肢としてノード 2 を使用します。このノードは、このトランクの Unified CM Group において最もプライオリティの高い Unified CM となる必要があります。このケースでは、ノード 3 は 2 番めの選択肢となります。

gw-default-priority 0 を使用するかどうかは任意です。この例で使用したのは、このゾーンで登録するよう不用意に設定される可能性のある他のトランクが一切使用されないようにするためです。

H.323 ゲートキーパー制御トランク上の発信のロード バランシング

Unified CM H.323 ゲートキーパー制御トランクでは、発信に使用されるノードは、ルート ローカル ルール、発信トランクがアクティブなノード数、およびルート リストを複数の発信トランクと併用するかどうかによって決定されます。次に、これらの考慮事項について説明します。

単一の H.323 ゲートキーパー制御トランクを配置する場合の発信のロード バランシング

単一の H.323 ゲートキーパー制御トランク上で発信を開始する場合、ルート ローカル ルールが適用され、Unified CM クラスタ内の次の要素によって、選択されるサーバが決定されます。

どの Unified CM サーバに、選択されたトランクのアクティブ H.323 デーモンがあるか

選択されたサーバのアクティブ H.323 デーモンがある Unified CM サーバに、コールを発信する電話が登録されているか

単一の H.323 ゲートキーパー制御トランクの場合、発信のサーバ選択のルート ローカル プロセスは次のように動作します。

選択されたトランクのアクティブ H.323 デーモンが、コールを発信する電話またはデバイスが登録される Unified CM サーバにある場合(つまり、このサーバがトランクの Unified CM Group にリストされているサーバに含まれる場合)、H.323 コールを発信するサーバとして、この Unified CM サーバを使用します。

選択されたトランクのアクティブ H.323 デーモンが、コールを発信する電話またはデバイスが登録される Unified CM サーバにない場合、選択されたトランクの Unified CM Group から、ラウンドロビン方式でサーバを 1 台選択します。

ルート リストを H.323 ゲートキーパー制御トランクと共に配置する場合の発信のロード バランシング

発信のトランクを選択するためにルート リストを採用する設定では、すべてのルート リストで [Run on all Active Unified CM Nodes] を有効にします。ルート ローカル ルールを使用してすべてのノードでルート リストを実行すると、発信の分配が改善され、不要なクラスタ内トラフィックを回避できます。ルート リストの場合、ルート ローカル ルールは次のように動作します。

ルート リスト(および関連するルート グループとトランク)を使用する発信の場合、(登録されている電話または着信トランク)からのコールが、発信トランク コールに関連付けられたルート リスト インスタンスがあるノードに到達したときに、選択した発信トランク コールのインスタンスがルート リストと同じノードに存在するかどうかが Unified CM によって確認されます。存在する場合、Unified CM はそのノードを使用して発信トランク コールを確立します。

ルート リストで [Run on all Active Unified CM Nodes] が有効の場合:Unified CM Group を使用するゲートキーパー制御トランクでは、選択した発信トランクのインスタンスが、着信が到達した同じノードに存在する場合にルート ローカル ルールが適用されます。トランクのインスタンスがそのノードに存在しない場合、Unified CM は(クラスタ内の)コールをトランクがアクティブなノードに転送します。

ルート リストで [Run on all Active Unified CM Nodes] を有効にしていない場合、ルート リストはクラスタ内の 1 つのノード(ルート リストの Unified CM Group のプライマリ ノード)でアクティブになり、ルート ローカル ルールはそのノードに適用されます。

H.323 発信 Fast Start コール接続

長い遅延がある大規模な WAN トポロジを介して IP Phone から発信されるコールに対して、着信側がオフフックで応答する場合、音声クリッピングが発生します。H.323 トランクまたはゲートウェイが、Unified CM サーバから分離されている場合、コールのセットアップ時に大量の H.245 メッセージが交換されるため、著しい遅延が発生します。

Fast Start 機能を使用すると、2 つのパーティ間でメディア接続を確立するために必要な情報が、コール セットアップの H.225 段階で交換されるため、H.245 メッセージが不要になります。この接続では、コール セットアップ時に 1 回のラウンドトリップ WAN 遅延が発生しますが、着信側がコールに応答するときに、発信側で音声クリッピングが発生することはありません。

Unified CM は、H.323 発信 Fast Start コールを確立するために、メディア ターミネーション ポイント(MTP)を使用します。Unified CM は、MTP を割り当て、受信チャネルを開くことで、発信 Fast Start コールを開始します。次に、H.323 Fast Connect プロシージャにより、Fast Start 要素を含む SETUP メッセージが着信側エンドポイントに送信されます。この Fast Start 要素には、MTP の受信チャンネルに関する情報が含まれています。

デフォルトでは、H.323 Fast Start は無効になります。H.323 Fast Start を有効にするには、H.323 トランクで [MTP Required] および [Enable Outbound FastStart] のチェックボックスをオンにし、目的の [Codec For Outbound Fast Start] を選択します。また、[Enable Inbound FastStart] チェックボックスとは別に、着信 Fast Start が有効になっていることに注意してください (着信 Fast Start に MTP またはコーデックの選択は必要ありません)。


) H.323 Fast Start が有効の場合、各発信 H.323 トランク コール用に MTP が割り当てられます。H.323 Fast Start に使用される MTP は単一の音声コーデックのみをサポートするため、音声コールおよび暗号化されたコールはサポートされません。デフォルトでは、H.323 Fast Start は H.323 トランクで無効になっています。MTP は、発信コールまたは着信コールには必要ありません。原則として、音声コール、ビデオ コール、および暗号化されたコールが H.323 トランク接続上でサポートされるように、このデフォルトの H.323(Slow Start)トランクの設定が適切です。


メディア ターミネーション ポイントを使用する H.323 トランク

メディア ターミネーション ポイント(MTP)は、一般に、H.323 トランクの通常動作には必要ありません。ただし、通信相手のデバイスが、H.323 Version 1 である場合、付加サービス用に Empty Capabilities Set(ECS)をサポートしていない場合、または H323 Fast Start を必要とする場合には必要です。

MTP が必要かどうかをテストするには、次の簡単な手順を使用します。

1. 電話機から H.323 トランクを介して他のデバイスにコールを発信します。このコールは通常どおりに発信する必要があります。

2. コールを保留にしてから、保留解除します。コールがドロップする場合は、Unified CM と他のデバイス間の相互運用性を保証するために MTP を使用することを推奨します。

DTMF 転送

H.323 トランクは、H.245 を使用したアウトオブバンド DTMF と RTP Named Telephone Event(RFC 2833)を使用したインバンド DTMF の両方で DTMF シグナリングをサポートします。設定オプションはありません。必要に応じて、アウトオブバンド DTMF リレーとインバンド DTMF リレーを変換するために、動的に MTP が割り当てられます。H.323 トランクがどのような場合にどの方式を使用するか、MTP がどのような場合に必要かについては、「メディア リソース」を参照してください。

H.323 トランク トランスポート プロトコル

H.323 トランクは、H.225 呼制御および H.245 メディア制御シグナリングに TCP を使用し、ゲートキーパー H.225 Registration Admission Status(RAS)シグナリングには UDP を使用します。

安全な H.323 トランク

H.323 トランクをセキュリティで保護するには、メディアを暗号化するためのトランクの設定と、シグナリングを暗号化するためのトランクの設定という 2 つのプロセスがあります。

メディア暗号化

メディア暗号化を H.323 トランクで設定するには、トランクの [SRTP allowed] チェックボックスをオンにします。[SRTP allowed] チェックボックスをオンにすると、コールのメディアは暗号化されますが、トランクのシグナリングは暗号化されない点に注意してください。結果として、安全なメディア ストリームの確立に使用されるセッション キーは暗号化されていない状態で送信されます。そのため、Unified CM と宛先 H.323 トランク デバイス間のシグナリングも暗号化し、キーや他のセキュリティ関連の情報がコールのネゴシエーション中に漏洩しないようにすることが重要です。

シグナリング暗号化

H.323 トランクはシグナリング暗号化に IPSec を使用します。ネットワーク インフラストラクチャで IPSec を設定するか、Cisco Unified Communications Manager(Unified CM)およびリモート ゲートウェイまたはトランク間で IPSec を設定できます。IPSec を設定するために 1 つの方式を実装する場合、他の方式を実装する必要はありません。Unified CM サーバで IPSec を使用すると、サーバのパフォーマンスに大きな影響が生じる可能性があるため、Unified CM 自体ではなく、ネットワーク インフラストラクチャに IPSec をプロビジョニングすることが推奨されます。

システムが安全なメディアまたはシグナリング パスを確立でき、さらにエンド デバイスが SRTP をサポートする場合、システムは SRTP 接続を使用します。システムが安全なメディアまたはシグナリング パスを確立できないか、1 つ以上のデバイスが SRTP をサポートしない場合、システムは RTP 接続を使用します。SRTP から RTP へのフォールバック(またはその逆)は、安全なデバイスから安全ではないデバイスへの転送、会議、トランスコーディング、保留音などの場合に発生する可能性があります。

SRTP が設定されたデバイスでは、デバイスの [SRTP Allowed] チェックボックスがオンで、そのコールでデバイスの SRTP 機能が正常にネゴシエートされた場合、Unified CM はコールを暗号化済みと分類します。前述の条件を満たさない場合、Unified CM はコールを安全ではないと分類します。デバイスが、セキュリティ アイコンを表示できる電話に接続されている場合、コールが暗号化されているときは電話機に鍵アイコンが表示されます。

[MTP Required] チェックボックスを使用して、スタティックに H.323 トランクに割り当てられている MTP は、パススルー コーデックをサポートしないため、SRTP をサポートしません。すべてのコールで SRTP をサポートするには、H.323 発信 Fast Start に H.323 トランクを設定しないでください(つまり、[MTP Required] は選択しないでください)。SRTP は着信 Fast Start でサポートされます (着信 Fast Start に MTP またはコーデックの選択は必要ありません)。

Unified CM における H.323 の動作

この項では、H.323 プロトコルを Unified CM で使用および実装する方法、および特定の機能が所定どおりに動作する仕組みとその理由について説明します。

理解するうえで最も重要な点は、どのサブスクライバがコール シグナリング デーモンを実行するかということです。このデーモンは、H.323 コールを発信および受信する部分的なコードです。通常、このデーモンは H.323 デーモンまたは H.225 デーモン(H.323D または H.225D)と呼ばれます。H.225 は、H.323 プロトコルの一部で、主に呼制御を担当します。H.245 は、H.323 のもう 1 つの主要コンポーネントで、コールのメディア制御を担当します。

多くの H.323 デバイスでは、特定の H.323 デバイスの Unified CM Group に含まれるサブスクライバによって、デーモンを実行するサブスクライバと実行するタイミングが決定されます。H.323 非ゲートキーパー制御クラスタ間トランクの場合、標準の Unified CM Group を使用するか、[Run on All Active Unified CM Nodes] を有効にできます。この場合、デーモンはすべてのアクティブなノードで実行されます。

Unified CM Group を使用するデバイスの場合、不適切なサブスクライバに送信されたコールは拒否される可能性があるため、H.225 デーモンを実行するノードを認識することが重要です。たとえば、この状況が発生するのは、Cisco IOS H.323 ゲートウェイに、Unified CM クラスタ内のサブスクライバ C にコールを送信するダイヤル ピアが設定されているものの、そのゲートウェイの Unified CM Group のリストにはサブスクライバ A および B しか含まれていない場合です。そのような場合、コールは失敗するか、またはデーモンがサブスクライバ上に設定されていれば H.323 トランク デーモンによって処理されます。

次のシナリオは、H.225D がサブスクライバ上に作成される仕組みとその時期について説明しています。

H.323 クライアント

H.225D は、H.323 クライアントに関連付けられた Unified CM Group で使用可能な、最もプライオリティの高いサブスクライバ上だけでアクティブになります。

H.323 クライアントがゲートキーパー制御の場合、RasAggregator デバイスは、ゲートキーパー制御の H.323 クライアントに関連付けられた Unified CM Group で使用可能な、最もプライオリティの高いサブスクライバから登録されます。

RasAggregator は、次の 2 つの特殊機能を提供するためにゲートキーパー ゾーンで登録される特殊なデバイスです。

H.323 クライアントが DHCP を使用している場合は、DNS を使用している Unified CM でそのクライアントを使用できません。ただし、クライアントが Dynamic DNS をサポートしている場合は除きます。RasAggregator を使用すると、Unified CM は、コールを発信するたびに、ゲートキーパーに登録されている特定の H.323 クライアントの IP アドレスを取得できます。ゲートキーパー登録は、H.323 クライアントの E.164 アドレスを含む標準の RAS ARQ メッセージを使用して行われます。ゲートキーパーは、E.164 アドレスを解決し、IP アドレスを ACF メッセージで Unified CM に返します。

また、RasAggregator を使用すると、H.323 クライアントによるコールはすべて Unified CM を経由するようになり、クライアント自身の間では直接やり取りされないことが保証されます。これにより、ダイヤリング規則とコーデック制限が適用されることが保証されます。

H.323 ゲートウェイ

H.225D は、H.323 ゲートウェイに関連付けられた Unified CM Group にあるすべてのサブスクライバ上でアクティブになります。

H.323 ゲートキーパー制御トランク

H.225D は、H.323 トランクに関連付けられた Unified CM Group にあるすべてのサブスクライバ上でアクティブになります。RAS デーモンは、関連付けられている Unified CM Group にあるすべてのサブスクライバから、トランクをゲートキーパーに登録します。

Unified CM Group を使用する H.323 非ゲートキーパー制御トランク

H.225D は、H.323 トランクに関連付けられた Unified CM Group にあるすべてのサブスクライバ上でアクティブになります。

[Run on All Active Unified Nodes] を使用する H.323 非ゲートキーパー制御トランク

H.225D は、クラスタ内のすべてのアクティブな Unified CM サブスクライバでアクティブです。

Unified CM クラスタ内のサブスクライバに H.323 コールが着信すると、コールを受け入れるかまたは拒否するか、受け入れる場合はどの H.225D がコールを受信するかなど、さまざまな決定が下されます。図 14-24 は、このプロセスの仕組みを示しています。

図 14-24 H.323 コールの受け入れまたは拒否を判別するプロセス

 

 

Unified CM の H.323 プロトコルには、次の追加機能が含まれています。

Protocol Auto Detect

この機能では、コールごとに、発信側デバイスが Cisco Unified CM を使用しているかどうかを判別できます。コールを受信するたびに、Unified CM は H.225 User-to-User Information Element(UUIE)を検索します。この UUIE は、もう一方の側が別の Unified CM であるかどうかを示します。UUIE が見つかった場合、Cisco Unified CM は常に Intercluster Trunk Protocol を使用します。UUIE が見つからない場合は、設定済みのプロトコルをそのデバイスに対して使用します。この機能を使用すると、H.225 ゲートキーパー制御トランクは、コールごとに Intercluster Trunk Protocol と H.225 を切り替えることができます。これにより、Unified CM クラスタと他の H.323 デバイスを組み合わせてゲートキーパーを使用できます。Intercluster Trunk Protocol は、H.225 と類似していますが、特定の機能を Unified CM クラスタ間で正しく動作させる仕組みが異なります。

Tunneled QSIG または H.323 Annex M1(トランクごとにサポートされる ISO および ECMA バリエーション)

この機能は、すべての H.323 トランクで有効にできます。これにより、特定の H.323 Annex M1 機能を、Unified CM クラスタと、同じく H.323 Annex M1 をサポートする他の確認済みシステムとの間に実装できます。これらの機能には、次のものがあります。

パス交換

メッセージ待機インジケータ(MWI)

コールバック

代替エンドポイント

この機能をサポートするゲートキーパー、たとえば Cisco Multimedia Conference Manager(MCM)Gatekeeper などに登録する場合、Unified CM はゲートキーパーに対し、H.323 トランクへのコールの代替宛先を通知できます。この代替エンドポイントまたは代替宛先は、この H.323 トランクが呼び出されたときに、ゲートキーパーによって発信側デバイスに送信されます。代替エンドポイントは、ゲートキーパーに登録されている H.323 トランクに関連付けられた Unified CM Group のリストに含まれている他のサブスクライバです。

代替ゲートキーパー

この機能をサポートするゲートキーパーに H.323 トランクが登録される場合(たとえば、Cisco ゲートキーパー クラスタ)、Unified CM には、このゲートキーパーが失敗した場合や独自のリソースを使い果たした場合に、登録、コール アドミッション要求、および他の RAS 機能を処理できる他のゲートキーパーに関する情報が動的に通知されます。

CanMapAlias

H.323 トランクは、ゲートキーパーに許可要求(ARQ)を送信すると、アドミッション確認(ACF)で異なる E.164 番号を受信する場合があります。このことは、元の着信番号をこの新しい番号で置き換える必要があることを示しています。この機能では、Gatekeeper Transaction Message Protocol(GKTMP)を使用して Cisco ゲートキーパーと通信するルート サーバが必要になります。


) CanMapAlias は、着信番号に関してだけサポートされます。


帯域幅要求

H.323 トランクは、ゲートキーパーの帯域幅情報をアップデートし、特定のコールに割り当てられた帯域幅の要求量が変更されたことを示すことができます。この機能は、デフォルトでは無効になっています。この機能を制御するには、H.323 セクションにある Unified CM サービス パラメータ BRQ Enabled True に設定します。この機能は、H.323 トランク上でビデオを使用するときに特に重要です。これは、元の帯域幅要求が許容最大限の量を要求するためです。この機能を有効にすると、コール アドミッション制御が、コールのセットアップ中にネゴシエートされた実際の帯域幅を使用することが保証されます。

その他の H.323 トランクの設計上の考慮事項

Unified CM SIP トランクは H.323 クラスタ間トランクと比較すると機能数が多いため、クラスタ間トランク接続のプロトコルとしては SIP が選択されています。ただし、以前のソフトウェア バージョンを使用した Unified CM クラスタとのクラスタ間トランク接続の場合は、H.323 Annex M1 の方が推奨されます。マルチクラスタにクラスタ間トランクを配置する方法、および WAN を介したクラスタリング環境の詳細については、「SIP トランクの設計上の考慮事項」を参照してください。

一般的な SIP および H.323 トランク設計の考慮事項

この項では、次の一般的な設計上の考慮事項について取り上げます。

「Unified CM トランク上の確定的な発信ロード バランシング」

「IP トランク上でのコーデック選択」

「その他の MTP の使用」

Unified CM トランク上の確定的な発信ロード バランシング

多くの場合、[Run on all Active Unified CM Nodes] を使用するか、Unified CM Group をデバイスに割り当てることで、呼処理サブスクライバからトランク上で発信されるコールの分割を十分に処理できます。ルート ローカル ルールのために、トランク コールは呼処理サブスクライバからランダムに開始されるように見える場合がありますが、このようにコールがランダムに開始される見返りとして、クラスタ内の呼処理と Intra-Cluster Communication Signaling(ICCS)トラフィックが減ります。

呼処理サーバにおける発信 IP トランク コールの確定的ロード バランシングは可能ですが、逆効果となることがあります。これは、クラスタ内での予測可能なコール発信によりもたらされるメリットよりも、発信 IP トランク コールを発信させるためにクラスタ内の別のサーバに通信を拡張する 1 つのサブスクライバの登録電話からのコールにより増加する ICCS トラフィック量によるデメリットが上回るためです。

予測可能で確定的なサブスクライバに基づいた発信 IP トランク コールのロード バランシングは、次のように実現できます。

発信トランク コールをクラスタの呼処理サーバの 1 つのサブセットで確定的にロード バランシングするには、複数のトランクを定義して、各トランクの Unified CM Group にサブスクライバを 1 つだけ割り当てます。これらのトランクをルート グループに配置し、循環コール分配を使用します。

たとえば、発信トランク コールをクラスタの 4 つのサブスクライバに分散するには、次のタスクを実行します。

個々に Unified CM Group を持つ 4 つの H.323 トランクまたは 4 つの SIP トランクを設定し、これらすべてを、循環コール分配を使用するルート グループに含めます。

Unified CM Group は、次のように定義されます。

グループ A: サブスクライバ A

グループ B: サブスクライバ B

グループ C: サブスクライバ C

グループ D: サブスクライバ D

バックアップ サブスクライバが定義されていない場合、指定されたトランクのプライマリ サブスクライバで障害が発生すると、Unified CM は、ルート グループの次のトランクに発信コールを再ルーティングします。

発信トランク コールをクラスタの 8 つのすべてのサブスクライバに分散するには、次のタスクを実行します。

個々に Unified CM Group を持つ 8 つの H.323 トランクまたは 8 つの SIP トランクを設定し、各グループにサブスクライバを 1 つだけ含め、すべてのトランクを循環ルート グループに含めます。

Unified CM Group は、次のように定義されます。

グループ A: サブスクライバ A

グループ B: サブスクライバ B

グループ C: サブスクライバ C

グループ D: サブスクライバ D

グループ E: サブスクライバ E

グループ F: サブスクライバ F

グループ G: サブスクライバ G

グループ H: サブスクライバ H

IP トランク上でのコーデック選択

通信エンティティ間でメディアを確立するには、これらのエンティティが、使用するコーデックに同意する必要があります。このコーデック(音声とビデオの両方が使用される場合には複数のコーデック)は、該当する通信エンティティでサポートされているコーデックのうち共通するもの、および設定されている Unified CM のポリシーから導出されます。Unified CM のポリシーは、リージョン設定で指定されます。

Unified CM 9. x のリージョン設定は、設定可能なオーディオ コーデックのプリファレンス リストを提供します。リージョンの [Link Loss Type] で選択できるデフォルトの [Lossy] および [Low Loss] オーディオ コーデック プリファレンス リストに加え、複数のカスタム オーディオ コーデック プリファレンス リストも設定できます。オーディオ コーデック プリファレンス リストは、リージョン内およびリージョン間のコールのコーデック選択に使用できます。[Maximum Audio Bit rate] は依然としてリージョン内およびリージョン間のコールに適用されますが、(以前の Unified CM リリースのように)最大ビット レート設定に基づいて音声品質が最も高いコーデックを使用するのではなく、オーディオ コーデック プリファレンス リストとエンドポイントがサポートするコーデックに基づいてコーデックが選択されます。(図 14-25 を参照)。

オーディオ コーデック プリファレンス リストは、Unified CM でサポートされているすべてのコーデック タイプのリストです。コーデック リストの優先順位は、カスタム プリファレンス リストとして変更して保存できます。(オーディオ コーデック プリファレンス リストからコーデックは削除できません) コール セットアップ時のコーデック ネゴシエーションに使用されるコーデックのリストは、デバイスによってサポートされコーデック プリファレンス リストに存在するコーデックのサブセットで、リージョンまたはリージョン ペアの最大オーディオ ビット レートによって制限されます。

図 14-25 コール セットアップ中のコーデック ネゴシエーションのコーデック選択方法の例

 

SIP または H.323 クラスタ間トランクでの 2 台の Unified CM クラスタ間のコールでは、音声コーデック プリファレンス リストを使用することで、発信側と着信側デバイスのコーデックの優先順位に基づいてコールのコーデックを選択することができます。各クラスタ内のデバイスをコーデック プリファレンスに基づいてリージョンにグループ化することで、単一のクラスタ間トランクを、それぞれが特定のコーデックを使用する複数のコールをサポートするために使用できます。(図 14-26 を参照)。

図 14-26 2 つの Unified CM クラスタ間の音声コールと FAX コール用のオーディオ コーデック プリファレンス リスト

 


) それぞれのクラスタで、各デバイス タイプ リージョンに同等のオーディオ コーデック プリファレンス リストを設定して、コールの向きやトランク設定にかかわらず各デバイス タイプに共通のコーデックが選択されるようにする必要があります。各クラスタのオーディオ コーデック プリファレンス リストが同等でない場合、コールごとに使用されるコーデックはコールの方向とトランク設定によって異なる場合があります。(通常、コーデックの優先順位はコーデックの優先順位リストを受信するクラスタによって遵守されません)



) [MTP Required] または H.323 トランクを使用する、アーリー オファーに設定された SIP トランクを Fast Start をイネーブルにして使用することは避けてください。これらのトランク設定は、発信コールに MTP を挿入し、1 種類のオーディオ コーデックだけにコールを制限し、コーデックの優先順位や選択を上書きします。このような場合、最大音声ビット レート設定は、このコーデックを使用できるよう、適切に設定する必要があります。


受信オファーのオーディオ コーデック プリファレンスの受け入れ

コールが複数の Unified CM クラスタを通過する配置(SME 配置など)では、中間 Unified CM クラスタのリージョン間オーディオ コーデック プリファレンス リストが、発信側と着信側のデバイス間の優先コーデック選択を上書きできます。コールが SME を通過するときにエンドポイントのコーデックの優先順位が尊重されるようにするには、SIP プロファイル機能 [Accept Audio Codec Preferences in Received Offer] をすべての SME SIP トランクでイネーブルにします。(図 14-27 を参照)。

図 14-27 SIP トランクで [Accept Audio Codec Preferences in Received Offer] を使用する SME 配置

 


) [Accept Audio Codec Preferences in Received Offer] 機能は、SIP トランクでのみ利用できます(SIP プロファイル機能)。SME クラスタが SIP、H.323 や MGCP トランクを使用する SME 配置で使用された場合、この機能は一貫した結果になりません。したがって、[Accept Audio Codec Preferences in Received Offer] 機能は、SME クラスタが SIP トランクのみを使用して配置されている場合に使用する必要があります。



) Unified CM 8.5 以降のリリースでは、SIP が最も豊富な機能セットを提供しているため、H.323 および MGCP トランクの代わりに SIP トランクを使用することを推奨します。(SIP および H.323 クラスタ間トランクの比較については、表 14-2 を参照してください。SIP、H.323、MGCP トランクの機能比較については、次の Web サイトで入手可能な『Cisco Unified Communications Manager Session Management Edition Deployment Guide』を参照してください。http://www.cisco.com/en/US/products/ps10661/products_implementation_design_guides_list.html


Cisco Unified CM と Cisco Unified Border Element SIP トランクのコーデック プリファレンス

Unified CM オーディオ コーデック プリファレンス リストは、Unified CM から CUBE SIP トランクの設定をシンプルにするために、Cisco Unified Border Element(CUBE)を使用した Unified Communications 配置に使用できます。たとえば、音声および FAX コール用に CUBE への専用 SIP トランクを使用する代わりに、コールが CUBE を通過するときに各デバイス タイプのコーデック プリファレンスが尊重されるようにした、単一の Unified CM SIP トランクを使用できます。

図 14-28 では、CUBE の着信と発信のダイヤル ピアに定義された音声クラスのコーデック プリファレンス リストは、受信したオファーでリストされたコーデックの優先順位を変更しません。CUBE は受信したオファーに対し、着信と発信のダイヤル ピア両方にコーデック フィルタリングを行い、ピア レッグへの着信オファーで受信したのと同じ優先順位で共通コーデックを伝えます。

オファー内で受信したものに加え、音声クラスのコーデック リストでコーデックが定義されている場合、それらのコーデックは順序付きリストで受け取ったものに付加され、送信オファーで送出されます。

したがって、単一の着信および発信ダイヤル ピアを、すべてのデバイス タイプについて CUBE で設定できます。シスコでは、着信およびダイヤル ピアの両方に、サービス プロバイダーとのネゴシエートに使用するコーデックを含む同一の音声クラス コーデック プリファレンス リストを使用しすることを推奨します。前述のように、コーデックの順序はまず着信オファーで受信した順序に左右され、その後音声クラス コーデック プリファレンス リストで定義された順番に左右されることになります。

図 14-28 Cisco Unified CM と Cisco Unified Border Element SIP トランクのコーデック プリファレンス

 

その他の MTP の使用

MTP は、トランク上でコールを発信する他のデバイスからのメディア ストリームを終端させる場合や、同じ音声ペイロードでメディア ストリームを再発信する場合に非常に役立ちます。ただし、そのような場合、IP アドレスは MTP のアドレスに変更されます。この事実に留意して、次のシナリオで MTP を使用します。

企業内の電話機、ゲートウェイ、および他のデバイスがすべて RFC 1918 プライベート アドレスを使用する場合は、すべての音声およびビデオ デバイスにネットワーク アドレス変換(NAT)を使用しなくても、引き続きパブリック ネットワーク上の他のシステムに接続できます。パブリック ネットワークと通信する Unified CM サブスクライバがパブリック IP アドレスを使用している場合、シグナリングはルーティングされます。また、すべての MTP もパブリック アドレスを使用している場合、RFC 1918 アドレスを持つデバイスからのメディアは MTP で終端され、再度発信されます。ただし、今度は、パブリック ネットワーク上でルーティング可能なパブリック アドレスが割り当てられます。このアプローチを使用すると、RFC 1918 アドレスを持つ何万台ものデバイスが、パブリック ネットワークと通信できるようになります。この同じ方式を使用すると、企業ネットワークにあるデバイスが他の企業またはサービス プロバイダーと通信するときに、そのデバイスの実際の IP アドレスを隠すことができます。

信頼性境界を設定すると、ファイアウォールを通過させることや、アクセス コントロール リスト(ACL)を使用したアクセスを許可できます。通常、メディアがファイアウォールを通過できるようにするには、アプリケーション層ゲートウェイ(ALG)またはフィックスアップを使用して、動的にメディア ストリームにアクセス許可を与えるか、または、ファイアウォールを越えて通信する必要のある音声デバイスすべてで使用するための広範囲のアドレスおよびポートを割り当てます。トランクを使用し、ファイアウォールまたは ACL を通過するすべてのコールには、MTP から発信されるメディアが割り当てられます。このメディアでは、単一の IP アドレスまたは狭い範囲の IP アドレスを使用できます。

これらの方法を両方使用する場合、[MTP Required] チェックボックスをオンにすると、デフォルトで、SIP および H.323 トランク上のコールが許可されます。このことは、MTP リソースが使用不能の場合や、使い果たされた場合でも同様です。このデフォルト動作により、コールの音声パスが使用不能になる場合があります。この動作を変更するには、SIP および H.323 セクションにある Unified CM サービス パラメータ Fail Call if MTP allocation fails True に設定します。

Cisco Unified CM トランクおよび緊急サービス

IP トランクは、緊急 911 コールを送信できない場合があります。また、中央集中型 PSTN トランクのように、発信側のロケーションに適した Public Safety Answering Point(PSAP)に緊急 911 コールを送信できない場合があります。そのため、お客様は、緊急 911 コールおよび発信側のロケーションを適切な PSAP に送信できるかどうか、IP トランク サービス プロバイダーの機能を注意して調査する必要があります。Cisco Emergency Responder を使用すると、緊急 911 コールに対する、ロケーションに固有な発呼側番号を IP トランク サービス プロバイダーに提供できる場合があります。

また、中央集中型 IP または PSTN トランクが、WAN 輻輳または障害のために、リモート ロケーションからの緊急 911 コールに一時的に応答できなくなることもあります。そのため、リモート ロケーションでは、常に、緊急 911 コールを送信できる PSTN へのローカル ゲートウェイを使用できなければなりません。詳細については、「緊急サービス」を参照してください。

Unified CM IP トランクのキャパシティ プランニング

Cisco 7800 Series Media Convergence Server では、次のトランク容量がサポートされます。

MCS-7845 クラスタまたは Cisco Unified Computing System(UCS)と同等のクラスタでは、最大 2100 トランクがサポートされます。

MCS-7835 クラスタでは、最大 1100 のトランクがサポートされます。

MCS-7825 クラスタでは、最大 1100 のトランクがサポートされます。

MCS-7816 クラスタでは、最大 200 のトランクがサポートされます。

上記の値は通常の最大容量を表していますが、実際のトランクのスケーラビリティおよびパフォーマンスは、最終的には、個々のサブスクライバで処理されている他のすべてのアプリケーションおよびタスクや、トランクにおける最繁時呼数(BHCA)などのいくつかの要因によって決定されます。全体的なシステム容量を決定するには、Cisco Unified Communications Sizing Tool(Unified CST)を使用します。このツールは、シスコ従業員と代理店が適切なログイン認証を経て次の Web サイトから入手できます。

http://tools.cisco.com/cucst

クラスタのトランクのスループットを最大にするには、着信と発信の両方におけるトランクの負荷が、可能なかぎりクラスタ内のすべてのサブスクライバに均等に分散されるようにします。

サービス プロバイダー ネットワークに対する IP PSTN および IP トランク

サービス プロバイダーは、企業の顧客に対して非 TDM PSTN 接続のサービスを増やしています。非 TDM インターフェイスを配置することで得られるコスト削減という重要なメリットのほかに、これらの IP ベース PSTN 接続では、従来の PSTN インターフェイスと比較して優れた音声機能が提供されます。

SIP ベースのサービスは使用可能なサービスの中で優位を占め、旧 H.323 サービスは特定の地域で使用できましたが、段階的に使用されなくなっています。これは主として、企業内で SIP の人気が高まっていることに加え、プレゼンスなどの追加機能や多くのリッチ メディア アプリケーション(インスタント メッセージングなど)のサポートが提供されることが背景にあります。長期的に見ると、SIP は、Unified Communications プロトコルとして最も幅広く使用されるようになると思われます。

サービス プロバイダーの IP PSTN ネットワークに接続する場合、エンタープライズ エッジ セッション ボーダー コントローラとして Cisco Unified Border Element を使用し、企業ネットワークとサービス プロバイダーのネットワーク間に制御された境界およびセキュリティ ポイントを用意することが強く推奨されます。

Cisco Unified Border Element

Cisco Unified Border Element は、企業およびサービス プロバイダーの Cisco Unified Communications ネットワーク間に、多様なシグナリングおよびメディア機能があります。Cisco Unified Border Element は、次のものを対象として、セッション ボーダー コントローラのネットワーク間インターフェイス ポイントを提供します。

アドレスおよびポート トランスレーション(プライバシーおよびレベル 7 のトポロジ隠蔽)

SIP ディレイド オファーからアーリー オファーへの変換

プロトコルのインターワーキング(H.323 および SIP)および正規化

メディアのインターワーキング(DTMF、Fax、コーデックのトランスコーディング、および音量と制御取得のトランスレーティング)

コール アドミッション制御(合計のコール、メモリ、コール到達のスパイク検出、または宛先あたりの最大コール数)

セキュリティ(SIP の不正パケット検出、非ダイアログの RTP パケット ドロップ、SIP リスニング ポートの設定、ダイジェスト認証、同時コール数制限、コール レート制限、料金詐欺の防止、および複数のシグナリングとメディアの暗号化オプションなど)

サービス プロバイダーとの PPI/PAI/プライバシーおよび RPID インターワーキング

QoS および帯域幅管理(ToS/DSCP を使用した QoS マーキング、および RSVP やコーデック フィルタリングによる帯域幅拡張)

複数のサービス プロバイダーからの SIP トランクに対する同時接続

ボックス内またはボックス間のフェールオーバー オプションによるハイ アベイラビリティ(プラットフォームおよびリリースによって変わります)

請求の統計情報と CDR の収集

Cisco Unified Border Element は、Cisco Integrated Service Routers Generation 2(ISR G2)、Cisco AS5000XM Media Gateways、および Cisco 1000 シリーズ アグリゲーション サービス ルータ(ASR)で使用できる正規の Cisco IOS アプリケーションです。選択したハードウェア プラットフォームに応じて、Cisco Unified Border Element は、ボックス内またはボックス間のフェールオーバー オプションで、最大 16,000 の同時音声コールについてセッション スケーラビリティを提供できます。

Cisco Unified Border Element の詳細については、次のサイトで入手可能なマニュアルを参照してください。

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

トランクの集約プラットフォーム

多くの場合、大規模な IP PSTN 展開では、多数の Unified Communications システムからトランクを集約してから、サービス プロバイダーの IP PSTN に対して Cisco Unified Border Element を使用して接続する必要があります。ほとんどの場合、集約プラットフォームの選択は、エンド システムが使用しているプロトコルによって変わります。Cisco Unified CM Session Management Edition および Cisco Unified SIP Proxy は 2 つの共通して使用される集約プラットフォームです。詳細については、この項で説明します。シスコの H.323 ゲートキーパーも選択肢の 1 つですが、IP PSTN 接続には SIP が選択されるようになったので、現在ではあまり広く使用されていません (シスコの H.323 ゲートキーパー オプションについては、「H.323 トランク タイプ」の項で説明されています)。

Unified CM Session Management Edition

Unified CM Session Management Edition を使用する Unified Communications の配置は、マルチサイトの分散型呼処理の配置モデルにおけるバリエーションで、通常、大量の Unified Communications システムと相互接続するため、および IP PSTN に対して接続を提供するために採用されます。

Cisco Unified CM Session Management Edition は基本的に、トランク インターフェイスだけを使用し、IP エンドポイントを使用しない Unified CM クラスタです。このクラスタには、リーフ システムと呼ばれる、複数のユニファイド コミュニケーション システムを集約できます (図 14-29 を参照)。

図 14-29 Cisco Unified CM Session Management Edition

 

Unified CM Session Management Edition の配置は、複数の PBX 配置とそれに関連する電話を、IP 電話があり比較的少数のトランクを持つ Unified CM クラスタに移行するために使用できます。Unified CM Session Management Edition クラスタをサードパーティの PBX を相互接続する多数のトランクで開始し、何千もの IP 電話を持つ Unified CM クラスタ配置に徐々に移行することも可能です。また、Unified CM Session Management Edition を使用して、IP PSTN 接続、集中型のユニファイド コミュニケーション アプリケーションなど、サードパーティのユニファイド コミュニケーション システムに接続できます

Unified CM Session Management Edition は、次の機能をサポートします。

SIP トランク

H.323 トランク

MGCP トランク

ボイスコール

ビデオ コール

暗号化されたコール

FAX コール

Unified CM Session Management Edition は Unified CM と同じソフトウェアを使用するため、スケーラビリティ、可用性、ロード バランシング、SIP メッセージの正規化、コール ルーティング、番号の変更などのすべての Unified CM 機能は、Unified CM Session Management Edition クラスタに対して使用できます。

Cisco Unified CM Session Management Edition の詳細については、「Unified Communications の配置モデル」の章を参照してください。

Cisco Unified SIP Proxy

Cisco Unified SIP Proxy は、Cisco 3800 シリーズのサービス統合型ルータ(ISR)のネットワーク モジュール スロットに差し込むことができる Cisco NME-522 ネットワーク モジュールで SIP プロキシ機能を提供します。この ISR は、ネットワーク モジュールのホスティングやプロキシの実行専用にする必要はなく、上記の Cisco Unified Border Element の実行など、その他のネットワーク機能にも同時に使用できます。

Cisco Unified SIP Proxy は、Unified CM SIP トランクを使用するネットワークに次のような利点を提供します。

集約とルーティング

Unified SIP Proxy は、各サーバがフルメッシュ構成で他のすべてのサーバに接続する必要なしに、SIP サーバを相互に接続できます。

拡張性

Unified SIP Proxy は、企業や IP PSTN サービス プロバイダーとのコールを終端するために使用できます。プロキシは次に、そのコールを Unified Border Element のプールに分配します。Unified Border Element を追加して容量を増やすこともできます。

可用性とロード バランシング

Unified SIP Proxy は、使用可能な Unified Border Element のプールにコールを分配し、各 Unified Border Element のステータスをモニタリングすることで、信頼できるコールの完了を実現します。

メッセージの正規化

Unified SIP Proxy は、メッセージが Unified SIP Proxy を通過する際に、そのヘッダーや内容を操作する手段を提供することにより、SIP プロトコルのメッセージングにおける違いを隠す役割を果たします。

Cisco Unified SIP Proxy と Cisco Unified Border Element を配置する場合は、次の設計上の考慮事項を検討する必要があります。

接続されている Unified Border Element がいずれも過負荷にならないように、Unified SIP Proxy 上でロード バランシングの方式を設定します。

Unified CM または Unified Border Element の障害を検出して対処できるように、Unified SIP Proxy にトランクのモニタリングをセットアップします。

図 14-30 に、Cisco Unified SIP Proxy と Cisco Unified Border Element を使用したコール フローを示します。

図 14-30 Cisco Unified SIP Proxy と Cisco Unified Border Element のコール フロー

 

サービス プロバイダーへのコールを発信するために、Unified CM は Unified SIP Proxy にコールを送信します。Unified SIP Proxy は要求が Unified CM から発信されたと判断し、Unified Border Element にコールを転送します。Unified Border Element はコールを終端および再発信して Unified SIP Proxy に戻します。Unified SIP Proxy はコールが Unified Border Element から発信されたと判断し、今度はサービス プロバイダーにコールを転送します。このように、メディアは Unified Border Element を介して、発信した電話機からサービス プロバイダーまで直接確立されます。

大規模なセッション ボーダー コントローラ

ハードウェア プラットフォームに応じて、単一のハードウェア シャーシ上の Cisco Unified Border Element は、1 つまたは複数のプロバイダーから、SIP トランク上で同時に 16,000 コールを集約できます。また必要に応じて、冗長シャーシ間にステートフル フェールオーバーを使用できます。

トランク IP-PSTN 接続モデル

トランクは、必要なアーキテクチャに応じて、さまざまな方法で IP PSTN サービス プロバイダーに接続されます。この接続における最も一般的なアーキテクチャには、中央集中型トランクと分散型トランクの 2 つがあります。

中央集中型トランクは、Cisco Unified Border Element などのセッション ボーダー コントローラ(SBC)を使用し、1 つの論理接続を通してサービス プロバイダー(SP)に接続します(ただし、冗長性を確保するために複数の物理接続が存在する場合があります) (図 14-31 を参照)。会社へのすべてのコール、および会社からのすべてのコールでは、このトランクのセットが使用されます。会社において、中央の Unified CM クラスタが 1 つ本社にホストされており、リモートの支店が WAN 経由で本社に接続する場合、各サイト間の PSTN コールのメディアおよびシグナリングは WAN を通過します。

図 14-31 中央集中型または集約型 SIP トランク モデル

 

分散型トランクは、複数の論理接続経由でサービス プロバイダーに接続します (図 14-32 を参照)。会社の各支店は、サービス プロバイダーへの独自のローカル トランクを保有しています。支店からのメディアは WAN を通過する必要はなく、ローカル SBC 経由でサービス プロバイダー インターフェイスへと送信されます。

図 14-32 分散型 SIP トランク モデル

 

これらの接続モデルには、それぞれ利点と欠点があります。通常、中央集中型トランクは、物理的な機器および設定の複雑さの面でより容易に展開できます。分散型トランクには、メディアをローカル ハンドオフできる利点があり、またローカル プロバイダーからの番号の可搬性が高まります。図 14-33 に示すように、いくつかの支店をグループ化して接続したり、マルチクラスタ配置で各 Unified CM クラスタからトランクを提供したりするハイブリッド接続モデルでは、両方の配置形式の利点が実現されます。

図 14-33 リージョンによる集約を行ったハイブリッド SIP トランク モデル