C H A P T E R
5
Cisco Unified CM トランク
Cisco Unified Communications Manager（Unified CM、旧称 Cisco Unified CallManager）は、外部デ
バイスとの接続用に何種類かの IP トランクをサポートしています。Unified CM で設定できるトランク
は、H.225（H.323）、SIP、およびクラスタ間トランクの 3 種類あります。この章では、これらのトラ
ンクの一般的な機能および特徴について説明します。Unified CM トランクの特定用途の詳細について
は、このマニュアルのその他の関連する章を参照してください。
この章では、次のトピックについて説明します。
• 「H.323 および SIP トランクの比較」（P.5-2）
• 「H.323 トランク」（P.5-7）
• 「SIP トランク」（P.5-19）
• 「Cisco Unified CM トランクおよび緊急サービス」（P.5-26）
Unified CM トランクの用途の詳細については、次に示す章の各項を参照してください。
• 「Unified Communications の配置モデル」（P.2-1）
• 「メディア リソース」（P.6-1）
• 「コール アドミッション制御」（P.9-1）
• 「IP ビデオ テレフォニー」（P.16-1）
• 「Cisco Unified Presence」（P.22-1）
この章の新規情報
表 5-1 に、この章に新しく追加されたトピック、またはこのマニュアルの以前のリリースから大幅に改
訂されたトピックの一覧を示します。
表 5-1
新規情報、またはこのマニュアルの以前のリリースからの変更情報
新規トピックまたは改訂されたト
ピック
説明箇所
発番号の正規化
「発番号の正規化および SIP トランク」（P.5-24）
Cisco Unified SIP Proxy
「Cisco Unified SIP Proxy」（P.5-6）
コーデック タイプの選択
「IP トランク上でのコーデック選択」（P.5-25）
設計に関する推奨事項
「IP トランクを配置するときの設計に関する推奨事項」
（P.5-26）
SIP トランクの拡張機能
「SIP トランクの概要」（P.5-4）
Cisco Unified Communication SRND （Cisco Unified Communications Manager 7.x）
OL-16394-06-J
5-1
第5章
Cisco Unified CM トランク
H.323 および SIP トランクの比較
表 5-1
新規情報、またはこのマニュアルの以前のリリースからの変更情報 （続き）
新規トピックまたは改訂されたト
ピック
説明箇所
ルート リストを使用する場合の発信 「発信コールのロード バランシング」（P.5-12）
コールのロード バランシング
SRTP および SIP トランク
「SIP トランクでの SRTP」（P.5-24）
H.323 および SIP トランク経由のビ
デオ コーデックのサポート
表 5-2
H.323 および SIP トランクの比較
Cisco Unified CM トランク接続は、H.323 と SIP の両方のトランクをサポートしています。多くの場
合、H.323 または SIP のいずれを使用するかは、各プロトコルで提供される固有な機能により異なりま
す。また、お客様の好みや、異なるベンダーの製品間で提供される相互運用性におけるプロトコルの成
熟度および品質など、トランク プロトコルの選択に影響を与える外部的要素もたくさんあります。
シスコ デバイス間のトランク接続の場合、H.323 または SIP のいずれを使用するかは、比較的、簡単
に決定できます。他のベンダーの製品およびサービス プロバイダー ネットワークとのトランク接続の
場合、お客様がどの機能を必要としているか、および 2 つのベンダーの製品間での相互運用性の範囲を
理解することが重要です。
表 5-2 に、Unified CM クラスタ間での H.323 および SIP トランクを介して提供される機能の一部につ
いての比較を示します。
表 5-2
Cisco Unified CM トランクでの H.323 および SIP 機能の比較
機能
H.323
H.323 を介した
QSIG
SIP
発呼回線（番号）ID 表示
あり
あり
あり
発呼回線（番号）ID 表示禁止
あり
あり
あり
発信者名 ID 表示
あり
あり
あり
発信者名 ID 表示禁止
あり
あり
あり
接続回線（番号）ID 表示
あり
あり
あり
接続回線（番号）ID 表示禁止
あり
あり
あり
接続者名 ID 表示
あり
あり
あり
接続者名 ID 表示禁止
あり
あり
あり
アラート名
なし
あり
あり
転送（ブラインドまたは在席）
あり / あり
あり / あり
あり / あり
自動転送（すべて）
あり
あり
あり
自動転送（通話中）
あり
あり
あり
自動転送（無応答）
あり
あり
あり
呼完了（ビジーサブスクライバ）
なし
あり
なし
呼完了（無応答）
なし
あり
なし
サブスクライブ / 通知、パブリッシュ - 表示
なし
なし
あり
Cisco Unified Communication SRND （Cisco Unified Communications Manager 7.x）
5-2
OL-16394-06-J
第5章
Cisco Unified CM トランク
H.323 および SIP トランクの比較
表 5-2
Cisco Unified CM トランクでの H.323 および SIP 機能の比較 （続き）
機能
H.323
H.323 を介した
QSIG
SIP
メッセージ待機インジケータ（MWI：ランプ点灯 / 消
灯）
なし
あり
あり
パス交換
なし
あり
なし
コール保留 / 復帰
あり
あり
あり
Music On Hold（ユニキャストおよびマルチキャスト）
あり
あり
あり
DTMF リレー
H.245 アウトオブバ H.245 アウトオブバ RFC 2833、KPML
（OOB）、
ンド（OOB）1
ンド（OOB）1
Unsolicited Notify
（OOB）
SIP Early Offer
該当なし
該当なし
あり：発信コールの
ための MTP が必要
SIP ディレイドオファー
H.323 Fast Start
該当なし
該当なし
あり
あり：発信 Fast
Start のための MTP
あり：発信 Fast
Start のための MTP
該当なし
が必要
が必要
H.323 Slow Start
あり
あり
該当なし
オーディオ コーデック
G.711、G.722、
G.723、G.729、
G722
G.711、G.722、
G.723、G.729、
G722
G.711、G.722、
G.723、G.729、
G722、iLBC、AAC
MTP でのコーデック
G.711、G.722、
G.723、G.729
G.711、G.722、
G.723、G.729
G.711、G.729
ビデオ
あり
あり
あり
ビデオ コーデック
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
あり
あり
あり
シグナリング認証
なし
なし
ダイジェスト、TLS
シグナリング暗号化
なし
なし
TLS
メディア暗号化
SRTP
SRTP
SRTP
1. H.323 トランクは、特定の接続の種類で、RFC 2833 に規定されたシグナリングをサポートします。
H.323 トランクの概要
H.323 トランクは、他の Unified CM クラスタや、ゲートウェイなどの他の H.323 デバイスに対する接
続性を提供します。H.323 トランクは、Unified CM がクラスタ内通信用にサポートするオーディオお
よびビデオ コーデックのほとんどをサポートします。ただし、ワイドバンド オーディオおよびワイド
バンド ビデオについてはサポートしません。
H.323 トランクは、Empty Capabilities Set（ECS）を使用して、保留 / 保留解除や転送などの補足コー
ル サービスを提供します。この方式は、メディア ストリーム（またはチャネル）を停止または終了し、
同一または別のエンドポイント アドレスに対してメディア ストリームを開始または起動するための標
準の H.245 メカニズムです。この方式を使用すると、Unified CM は、コールをアクティブにしたまま
でも、メディア ストリームの送信元および宛先を迅速に制御することができます。
Cisco Unified Communication SRND （Cisco Unified Communications Manager 7.x）
OL-16394-06-J
5-3
第5章
Cisco Unified CM トランク
H.323 および SIP トランクの比較
たとえば、H.323 トランクを使用した 2 つのクラスタ（A と B）間のコールについて考えます。クラス
タ A のユーザがクラスタ B のユーザを保留にした場合、2 人のユーザ間のメディア ストリームは終了
し、クラスタ B のユーザはクラスタ A の Music On Hold（MoH）サーバに接続されます。MoH サー
バは、ユーザにメディア（音楽ファイル）を送信するよう指示されます。クラスタ A のユーザがコー
ルを保留解除すると、MoH ストリームが終了し、2 人のユーザ間で双方向メディア ストリームが再開
されます（Unified CM は、補足コール サービス用に H.450 をサポートしていません）。このケースで
は、MoH は ECS 動作の一例です。Cisco Unified CM 7.1(2) から、H.323 トランクがマルチキャスト
MoH をサポートするようになったので、H.323 トランクの Media Resource Group List（MRGL; メ
ディア リソース グループ リスト）にはユニキャストとマルチキャスト MoH リソースの両方を含める
ことができます（詳細については、「Music on Hold」（P.7-1）を参照してください）。
H.323 トランク上のコールに使用される帯域幅を制御するには、Unified CM で設定される、各トラン
クに割り当てられるリージョンを使用します。リージョンは、そのリージョンのコールごとの音声コー
デック タイプとビデオ帯域幅を指定することで、コールに割り当てられる帯域幅の量を制限します。
そのリージョンと別のリージョン間のコールは、指定された帯域幅の制限内にする必要があります。
H.323 トランク上でコールを発信するデバイスが、より限定的なリージョン内にある場合や、ビデオな
どの特定のコーデックをサポートしない場合、そのデバイスはそのコールに使用可能なコーデックのサ
ブセットになっています。
H.323 トランクは、H.245 を使用したアウトオブバンド DTMF と RTP Named Telephone Event
（RFC-2833）を使用したインバンド DTMF の両方で DTMF シグナリングをサポートします。設定オ
プションはありません。H.323 トランクがどのような場合にどの方式を使用するかについては、「メ
ディア リソース」（P.6-1）を参照してください。
SIP トランクの概要
SIP トランクは、ゲートウェイ、プロキシ、ボイスメール システム、および他の Unified CM クラスタ
など、他の SIP デバイスへの接続性を提供します。Cisco Unified CM 5.x 以降のリリースでは、SIP ト
ランクの主な拡張機能が提供され、Cisco Unified CM 4.x での制限（たとえば、単一コーデックのサ
ポート、ビデオ サポートの欠如、RFC 2833 DTMF サポートに必須のメディア ターミネーション ポイ
ント（MTP）など）が解消されています。
Cisco Unified CM 6.x での SIP トランクに対する主な拡張機能としては、iLBC および AAC コーデッ
クや SIP PUBLISH のサポートがあります。SIP PUBLISH は、パフォーマンスを向上させることで、
SIP トランクを介して IP Phone プレゼンス情報を Cisco Unified Presence に送信するための、Cisco
Unified CM 6.x に適したメカニズムを提供します。
Cisco Unified CM 7.x での SIP トランクに対する主な拡張機能としては、次のものがあります。
• 初期 SIP INVITE 要求の発信における G.729 コーデックのサポート
• コンテンツをシグナリングして、発信側および送信側の名前や番号を表示するかどうかを指定す
る、Privacy、P-Asserted-Identity および P-Preferred-Identity ヘッダーの使用
• Secure Real-Time Transport Protocol（SRTP）を使用したメディア暗号化
• 発信側番号の正規化のサポート
SIP トランクの新規拡張機能の全リストについては、次の Web サイトで入手可能な Cisco Unified
Communications Manager の製品リリース ノートを参照してください。
http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_release_notes_list.html
クラスタ間トランキングに使用した場合、SIP トランクは Annex M1 を使用した QSIG Tunneling をサ
ポートしません。
H.323 トランクと同様に、SIP トランク経由のコール用に選択されるコーデックは、SIP コール セット
アップ メッセージから取得したリモート エンドポイントの機能、ローカル エンドポイントの機能、ト
ランクとローカル エンドポイント間のリージョン間コーデック設定によって決定されます。
Cisco Unified Communication SRND （Cisco Unified Communications Manager 7.x）
5-4
OL-16394-06-J
第5章
Cisco Unified CM トランク
H.323 および SIP トランクの比較
（注）
可能であれば、G.729 などの低品質なコーデックよりも、G.722 や G.711 などの高品質なコーデックが
選択されます。このルールの例外は、リージョン間のリンクが lossy としてマークされている場合で
す。この場合は、可能であれば iLBC コーデックが使用されます。
サービス プロバイダー ネットワークに対する IP PSTN および IP トランク
Cisco Unified CM では、H.323 と SIP の両方のトランクがサポートされるため、サービス プロバイ
ダーは、企業カスタマーへの非 TDM PSTN 接続の提供を開始できます。非 TDM インターフェイスを
配置することで得られるコスト削減という明らかなメリットのほかに、多くの場合、これらの IP ベー
ス PSTN 接続では、従来の PSTN インターフェイスより優れた音声機能が提供されます。
IP トランキング プロトコルとして H.323 または SIP のいずれを採用するかは、通常、サービス プロバ
イダーによって異なりますが、現在では SIP ベースのサービスが利用可能なサービスの中心になってき
ています。これは主として、企業内で SIP の人気が高まっていることに加え、プレゼンスなどの追加機
能や多くのマルチメディア アプリケーション（インスタント メッセージングなど）のサポートが提供
されることが背景にあります。長期的に見ると、SIP のほうが、Unified Communications プロトコル
として幅広く使用されるようになると思われます。
SIP と H323 の規格はいずれも、一定の統合においてオープン スタンダードとなっているので（オプ
ションおよび必須の要件が数多くあります）、ベンダー間における相互運用性の程度は、通常、これら
のプロトコルの成熟度が高まるにつれて改善されます。そのため、Cisco Unified Border Element（旧
称 Cisco Multiservice IP-to-IP Gateway Software）は、相互運用性に関する数多くの機能、および他の
ベンダーの H323 および SIP ネットワークと接続するときのセッション ボーダー コントローラとして
通常の境界ポイントを提供します。
Cisco Unified Border Element
Cisco Unified Border Element（旧称 Cisco Multiservice IP-to-IP Gateway Software）は、企業および
サービス プロバイダーの Cisco Unified Communications ネットワーク間で、幅広いシグナリングおよ
びメディア機能を提供します。Cisco Unified Border Element は、次のものを対象として、ネットワー
ク間インターフェイス ポイントを提供します。
• アドレスおよびポート トランスレーション（プライバシーおよびトポロジ隠蔽）
• シグナリング インターワーキング（H.323 および SIP）
• メディア インターワーキング（DTMF、FAX、モデムおよびコーデック トランスコーディング）
• QoS および帯域幅管理（ToS/DSCP を使用した QoS マーキング、および RSVP やコーデック フィ
ルタリングによる帯域幅拡張）
• 課金および CDR 正規化
Cisco Unified Border Element は、Cisco 2800 および 3800 シリーズの Integrated Service Routers
（ISR）、Cisco AS5350XM および AS5400XM Media Gateways、Cisco 7200VXR および Cisco 7301 シ
リーズのルータおよびゲートウェイ プラットフォームで使用できる、認可を受けた Cisco IOS アプリ
ケーションです。
Cisco Unified Border Element は、任意の IP PSTN 配置に使用することをお勧めします。
Cisco Unified Communication SRND （Cisco Unified Communications Manager 7.x）
OL-16394-06-J
5-5
第5章
Cisco Unified CM トランク
H.323 および SIP トランクの比較
Cisco Unified SIP Proxy
Cisco Unified SIP Proxy は、Cisco 3800 シリーズの Integrated Services Router（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 SIP Proxy を使用します。容量の追加は、新し
い Unified Border Element を追加するのと同じくらい簡単です。
• 接続されている Unified Border Element がいずれも過負荷にならないように、Unified SIP Proxy
上でロード バランシングの方式を設定します。
• Unified CM または Unified Border Element の障害を検出して対処できるように、Unified SIP
Proxy にトランクのモニタリングをセットアップします。
図 5-1 に、Cisco Unified SIP Proxy と Cisco Unified Border Element を使用したコール フローを示し
ます。
Cisco Unified Communication SRND （Cisco Unified Communications Manager 7.x）
5-6
OL-16394-06-J
第5章
Cisco Unified CM トランク
H.323 トランク
図 5-1
Cisco Unified SIP Proxy と Cisco Unified Border Element のコール フロー
ǵȸȓǹ
ȗȭȐǤȀȸ
IP
ISR
Cisco Unified SIP Proxy
M
SIP-SIP
Cisco Unified Border Element-1
M
M
M
SIP-SIP
Cisco Unified Border Element-2
ࠪࠣ࠽࡝ࡦࠣ ࡄࠬ
ࡔ࠺ࠖࠕ ࡄࠬ
M
Cisco Unified CM
SIP-SIP
Cisco Unified Border Element-3
㔚⹤ᯏ
251633
ࡈࠔࠗࠕ࠙ࠜ࡯࡞
サービス プロバイダーへのコールを発信するために、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 SIP Proxy のインストールと設定の詳細については、次の Web サイトで入手可能な製品
マニュアルを参照してください。
http://www.cisco.com/en/US/products/ps10140/tsd_products_support_model_home.html
H.323 トランク
Unified CM では、次の主要なタイプの H.323 トランクを設定できます。
• 「クラスタ間トランク（非ゲートキーパー制御）」（P.5-7）
• 「クラスタ間トランク（ゲートキーパー制御）」（P.5-8）
• 「H.225 トランク（ゲートキーパー制御）」（P.5-8）
クラスタ間トランク（非ゲートキーパー制御）
このトランクは、最も単純で、単一のマルチクラスタ キャンパスまたは分散型コール処理配置で他の
Unified CM クラスタに接続するために使用されます。このトランクは、コール アドミッション制御に
ゲートキーパーを使用しません。ただし、帯域幅制御が必要な場合は、Unified CM で設定されたロ
ケーションを使用できます。
このタイプのトランクを定義する場合、同一の宛先クラスタに最大 3 つのリモート Unified CM サーバ
を定義できます。トランクは、定義されているすべてのリモート Unified CM サーバに自動的にロード
バランスされます。リモート クラスタでは、対応するクラスタ間トランク（非ゲートキーパー制御）
Cisco Unified Communication SRND （Cisco Unified Communications Manager 7.x）
OL-16394-06-J
5-7
第5章
Cisco Unified CM トランク
H.323 トランク
を設定することが重要です。このトランクには、最初のクラスタでリモート Unified CM サーバとして
定義されているサーバと同じサーバを含む Unified CM Group を割り当てます。クラスタ間トランクに
よって接続された各 Unified CM クラスタでも、同様の設定が必要です。
たとえば、クラスタ 1 にクラスタ 2 へのトランクがあり、クラスタ 2 にクラスタ 1 へのトランクがある
場合は、次の設定が必要になります。
• クラスタ 1
– サーバ B、C、および D を、クラスタ 2 へのトランクに関連付けられたデバイス プールで定義
されている Unified CM Group のメンバーとして設定します。
– 非ゲートキーパー制御トランクに、クラスタ 2 のリモート サーバ D、E、および F を設定しま
す。
• クラスタ 2
– サーバ D、E、および F を、クラスタ 1 へのトランクに関連付けられたデバイス プールで定義
されている Unified CM Group のメンバーとして設定します。
– 非ゲートキーパー制御トランクに、クラスタ 1 のリモート サーバ B、C、および D を設定しま
す。
クラスタ間トランク（ゲートキーパー制御）
クラスタ数が多くなる場合は、クラスタ間非ゲートキーパー制御トランクの代わりに、クラスタ間ゲー
トキーパー制御トランクを使用する必要があります。ゲートキーパー制御トランクを使用する主な利点
は、クラスタとフェールオーバー時間を全体的に管理できることです。非ゲートキーパー制御トランク
では、一般に、トランクのフル メッシュを設定する必要があります。ただし、この作業は、クラスタ
数が増加すると管理負担になる場合があります。また、クラスタ内のサブスクライバ サーバが到達不
能になった場合は、5 秒（デフォルト）でコールの試行がタイムアウトします。クラスタ全体が到達不
能になった場合、コール障害または公衆網を介した再ルーティングのいずれかが発生するまでの試行回
数は、トランク用に定義されたリモート サーバの数と、ルート リストまたはルート グループ内のトラ
ンクの数によって異なります。リモート サーバと非ゲートキーパー制御トランクの数が多いと、コー
ル遅延が過剰になることがあります。
ゲートキーパー制御トランクを使用する場合は、ゲートキーパーに登録されている他のすべてのクラス
タとゲートキーパーを介して通信できるトランクを 1 つだけ設定します。クラスタまたはサブスクライ
バが到達不能になった場合、ゲートキーパーは自動的に、コールをクラスタ内の別のサブスクライバに
送信するか、または他のサブスクライバが存在しなければコールを拒否します。その結果、ほとんど遅
延させることなく、公衆網を介して（必要な場合）コールを再ルーティングすることができます。単一
の Cisco ゲートキーパーを使用すると、100 のクラスタすべてが、それぞれ 1 つのトランクを、相互に
コールできるすべてのクラスタに登録できます。非ゲートキーパー制御トランクを使用する場合、この
同じトポロジでは、各クラスタに 99 のトランクを設定する必要があります。クラスタ間ゲートキー
パー制御トランクは、他の Unified CM と通信する場合だけ使用する必要があります。これは、このト
ランクを他の H.323 デバイスで使用すると、補足サービスに問題が発生することがあるためです。ま
た、Release 3.2 よりも前の Unified CM との下位互換性を確保する場合は、クラスタ間ゲートキー
パー制御トランクを使用する必要があります。
H.225 トランク（ゲートキーパー制御）
H.225 ゲートキーパー制御トランクは、本質的にはクラスタ間ゲートキーパー制御トランクと同じです
が、Unified CM クラスタ Release 3.2 以降のほか、ゲートウェイ、会議システム、およびクライアン
トなどの他の H.323 デバイスと連携動作する機能を持つ点が異なります。この機能は、コールごとに
Cisco Unified Communication SRND （Cisco Unified Communications Manager 7.x）
5-8
OL-16394-06-J
第5章
Cisco Unified CM トランク
H.323 トランク
検出メカニズムを通じて実現されます（この検出プロセスの詳細については、「Unified CM における
H.323 の動作」（P.5-15）を参照してください）。このタイプのトランクは、すべての Unified CM クラ
スタが Release 3.2 以降の場合に推奨される H.323 トランクです。
ゲートキーパー トランクの冗長性、復元性、およびロード バランシング
冗長性は、設計の要件に応じて、複数の方法で実現できます。最も簡単に実現するには、ゲートキー
パー制御トランクを設定し、そのトランクに割り当てられたデバイス プールに関連付けられている
Unified CM Group に、最大 3 つのサブスクライバを割り当てます。この設定により、すべてのサーバ
が、同じテクノロジー プレフィックスとともに、同じゾーン内の同じゲートキーパーに登録されます。
ただし、h323_id に使用される H.323 トランクの名前には、「_n」というサフィックスが付加されま
す。ここで、n はクラスタ内のノード番号です。この ID は自動的に生成され、変更できません。単一
のトランクを設定しても、ゲートキーパーは、複数のトランク、つまり Unified CM Group 内のサブス
クライバごとに 1 つのトランクを登録します。
追加の冗長性要件がある場合は、別のゲートキーパー制御トランクに、Unified CM Group にある別の
名前と別のサブスクライバを設定できますが、それ以外のパラメータはすべて最初のトランクと同じに
なります。この 2 つ目のトランクによって、追加のサブスクライバがゲートキーパーに登録されます。
標準のサブスクライバ ペアを構成する 2 つのサーバから Unified CM Group を構成し、このグループを
含むデバイス プールを割り当てることをお勧めします（サブスクライバの冗長性の詳細については、
「コール処理サブスクライバ」（P.8-8）を参照してください）。各クラスタ全体で完全な冗長性を実現す
るには、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 コール シグナリング アドレス
推奨されるクラスタ化ゲートキーパーが使用されている場合、ゲートキーパーは、代替ゲートキーパー
アドレスのリストを返します。このリストは、プライマリ ゲートキーパーで障害が発生した場合や使
用可能なリソースが不足した場合に使用されることがあります。
図 5-2 は、Gatekeeper Update Protocol（GUP）を使用して通信する、ゲートキーパーのクラスタを示
しています（ゲートキーパーの詳細については、「コール処理」（P.8-1）の章を参照してください）。
Cisco Unified Communication SRND （Cisco Unified Communications Manager 7.x）
OL-16394-06-J
5-9
第5章
Cisco Unified CM トランク
H.323 トランク
図 5-2
ゲートキーパー クラスタ
1
GK
2
3
GK
GK
GK
132273
GK
4
5
H.323 トランクの Unified CM Group にサブスクライバが 1 つだけ含まれている場合、Unified CM の
設定済みゲートキーパーとゲートキーパー クラスタの間の接続は 1 つだけになります（図 5-3 を参
照）。
図 5-3
単一の Unified CM サブスクライバを使用する H.323 トランク
1
GK
2
M
3
GK
GK
CallManager
GK
132274
GK
4
5
トランクに関連付けられた Unified CM Group に複数のサブスクライバが含まれている場合、
Unified CM クラスタとゲートキーパー クラスタ間には追加の接続が確立されます（図 5-4 を参照）。
図 5-4
複数の Unified CM サブスクライバを使用する H.323 トランク
1
M
M
M
3
GK
GK
M
GK
GK
4
5
132275
M
GK
2
このアプローチによってサブスクライバ障害やゲートキーパー障害に対する冗長性が確保されるのは、
登録完了後です。これは、トランクの登録時に代替ゲートキーパーの通信が行われるためです。ただ
し、このアプローチでは、設定済みのゲートキーパーが初期登録時やリセット後に使用不能である場合
Cisco Unified Communication SRND （Cisco Unified Communications Manager 7.x）
5-10
OL-16394-06-J
第5章
Cisco Unified CM トランク
H.323 トランク
には、冗長性が確保されません。これは、代替ゲートキーパーのリストがダイナミックであり、データ
ベースに格納されないためです。冗長性のレベルを上げたりロード バランシングを追加したりするに
は、ゲートキーパー クラスタにある追加のゲートキーパーを Unified CM で設定します。たとえば、元
のトランクがエレメント 2 に登録されている場合は、追加のゲートキーパーをエレメント 4 として設定
できます（図 5-5 を参照）。
図 5-5
ロード バランシングと追加の冗長性のために設定された追加のゲートキーパー
1
A
M
M
M
B
3
GK
GK
M
GK
GK
4
5
132276
M
GK
2
図 5-5 の例の場合、Unified CM の設定には次のコンポーネントが含まれます。
• エレメント 2 とエレメント 4 の 2 つのゲートキーパー
• サブスクライバ サーバ A および B を含む Unified CM Group に対して定義された 2 つの H.323 ト
ランク
このアプローチを使用すると、初期設定時にエレメント 2 またはエレメント 4 が到達不能であっても
（つまり、起動中またはトランクのリセット中でも）、引き続き Unified CM クラスタが登録できるよう
になります。
Unified CM クラスタに着信するコールのロード バランシングは、デフォルトで自動的に行われます。
これは、ゲートキーパーが、ゾーン内の登録済みサブスクライバのいずれかをランダムに選択するため
です。この動作が期待と異なる場合は、ゲートキーパーで gw-priority 設定コマンドを使用して、この
デフォルト動作を変更することができます（例 5-1 を参照）。
例 5-1
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
例 5-1 では、H.323 トランクは Unified CM で sjc-trunk として設定されています。また、クラスタ内の
サブスクライバのノード番号を示すために、「_2」と「_3」のサフィックスが Unified CM サブスクラ
イバによって自動的に付加されています。したがって、この例では、最初の選択肢としてノード 2 を
使用します。このノードは、このトランクの Unified CM Group において最もプライオリティの高い
Unified CM となる必要があります。このケースでは、ノード 3 は 2 番目の選択肢となります。
gw-default-priority 0 を使用するかどうかは任意です。この例で使用したのは、このゾーンで登録す
るよう不用意に設定される可能性のある他のトランクが一切使用されないようにするためです。
Cisco Unified Communication SRND （Cisco Unified Communications Manager 7.x）
OL-16394-06-J
5-11
第5章
Cisco Unified CM トランク
H.323 トランク
発信コールのロード バランシング
ほとんどの場合、標準方式で Unified CM Group をデバイスに割り当てれば、コール処理サブスクライ
バからの IP トランクを介した発信コールのコール分配に十分に対応できます。IP トランク コールは、
コール処理サブスクライバからランダムに発信されるように思えますが、このランダム コール発信で
は、コール処理が減り、クラスタ内での Intra-Cluster Communication Signaling（ICCS）トラフィッ
クも減るというトレードオフがあります。コール処理サーバにおける発信 IP トランク コールのロード
バランシングは、次に説明するように、逆効果となることがあります。これは、クラスタ内での予測可
能なコール発信によりもたらされるメリットよりも、発信 IP トランク コールを発信させるためにクラ
スタ内の別のサーバに通信を拡張する 1 つのサブスクライバの登録電話からのコールにより増加する
ICCS トラフィック量によるデメリットが上回るためです。
（注）
発信トランクの選択に役立つルート リストが使用される設定では、サブスクライバの選択は上記の説
明と異なる場合があります。Unified CM は、発信側エンドポイントが登録され、トランクもホストし
ているサブスクライバを選ぶのではなく、ルート リストとトランクの両方をホストするサブスクライ
バを選択する場合があります。このため、発信トランクの選択によって、サブスクライバ間の ICCS ト
ラフィックが最小化されることはなくなります。ルート リストを使用する場合の ICCS トラフィック
を最小化するために、ルート リストに関連付けられる Unified CM Group では、トランクに関連付けら
れる Unified CM Group のサブスクライバ セットとは異なるサブスクライバ セットを使用することを
お勧めします。
H.323 トランクを介した発信コールの開始において、選択されるサーバは、Unified CM クラスタ内で
の次の主な要因により決定されます。
• どの Unified CM サーバに、選択されたトランクのアクティブ H.323 デーモンがあるか
• 選択されたサーバのアクティブ H.323 デーモンがある Unified CM サーバに、コールを発信する電
話が登録されているか
IP トランクの場合、サーバ選択プロセスは、たとえば、PSTN へのコール発信に使用できるゲート
ウェイの選択や、複数のゲートウェイでのコール分配の提供にルート リストおよびルート グループを
使用できる、ゲートウェイとの H.323 接続の場合ほど直感的ではありません。ルート リストおよび
ルート グループ プロセスは、トランク選択およびコール分配でも使用できますが、H.323 コールを発
信するサーバの選択を行うセカンド プロセスが発生します。つまり、ルート リストおよびルート グ
ループ設定により、発信トランクが選択された後、その選択されたトランクに対する Unified CM
Group の 1 台のサーバを、H.323 コールを発信するサーバとして選択しなければなりません。
すべての IP トランクにおいて、この発信コールのサーバ選択プロセスは、次のようになります。
• 選択されたトランクのアクティブ H.323 デーモンが、コールを発信する電話またはデバイスが登
録される Unified CM サーバにある場合（つまり、このサーバがトランクの Unified CM Group に
リストされているサーバに含まれる場合）、H.323 コールを発信するサーバとして、この
Unified CM サーバを使用します。
• 選択されたトランクのアクティブ H.323 デーモンが、コールを発信する電話またはデバイスが登
録される Unified CM サーバにない場合、選択されたトランクの Unified CM Group から、ラウン
ドロビン方式でサーバを 1 台選択します。
（注）
トランクの Unified CM Group で定義されているすべてのサーバは、そのトランクのアクティブ H.323
デーモンを実行します。トランクの Unified CM Group 内で定義されている各サーバでは、各 H.323 ト
ランクに対して、一意な H.323 デーモンが作成されます。
IP トランクを介した発信コールに対して、予測可能および確定的なロード バランシングを提供するに
は、上記のトランク選択動作を考慮する必要があります。
Cisco Unified Communication SRND （Cisco Unified Communications Manager 7.x）
5-12
OL-16394-06-J
第5章
Cisco Unified CM トランク
H.323 トランク
サブスクライバに基づいた発信 IP トランク コールのロード バランシングは、次のように実現できま
す。
• 発信トランク コールをクラスタのコール処理サーバの 1 つのサブセットだけでロード バランシン
グするには、複数のトランクを定義して、各トランクの Unified CM Group にサブスクライバを 1
つだけ割り当てます。
• Unified CM Group 内でサブスクライバの冗長性を確保する場合、発信トランク コールの予測可能
なサブスクライバ ロード バランシングを提供する最も簡単な方法は、電話の登録に使用されるサ
ブスクライバと、トランク コールを開始するサブスクライバを別々にすることです。
たとえば、発信トランク コールをクラスタの 4 つのサブスクライバに分散するには、次のタスクを実
行します。
• 4 つの Unified CM Group に対して 4 つの H.323 トランクを設定し、これらすべてを、循環コール
分配を使用するルート グループに含めます。
• Unified CM Group は、次のように定義されます。
– グループ A: サブスクライバ A
– グループ B: サブスクライバ B
– グループ C: サブスクライバ C
– グループ D: サブスクライバ D
バックアップ サブスクライバが定義されていない場合、指定されたトランクのプライマリ サブスクラ
イバで障害が発生すると、Unified CM は、ルート グループの次のトランクに発信コールを再ルーティ
ングします。
上記の例の場合、サブスクライバ A、B、C、D を次のように使用することで、提供される各トランク
の各 Unified CM Group 内でバックアップ サブスクライバを定義できます。
• グループ A: サブスクライバ A; サブスクライバ B
• グループ B: サブスクライバ B; サブスクライバ C
• グループ C: サブスクライバ C; サブスクライバ D
• グループ D: サブスクライバ D; サブスクライバ A
ただし、電話登録や H.323 デーモン サブスクライバのコロケーションに基づいた発信トランク コール
のサブスクライバ選択を回避するため、クラスタ内のすべての電話は、他のコール処理サーバ（たとえ
ば、サブスクライバ、E、F、G、H）に登録し、必要に応じて、Unified CM Group を使用してサーバ
冗長性を確保する必要があります。
発信トランク コールをクラスタの 8 つのすべてのサブスクライバに分散するには、次のタスクを実行
します。
• 8 つの異なる Unified CM Group に対して 8 つの H.323 トランクを設定し、各グループにサブスク
ライバを 1 つだけ含め、すべてのトランクを循環ルート グループに含めます。
• Unified CM Group は、次のように定義されます。
– サブスクライバ A
– サブスクライバ B
– サブスクライバ C
– サブスクライバ D
– サブスクライバ E
– サブスクライバ F
Cisco Unified Communication SRND （Cisco Unified Communications Manager 7.x）
OL-16394-06-J
5-13
第5章
Cisco Unified CM トランク
メディア ターミネーション ポイントを使用する H.323 トランク
– サブスクライバ G
– サブスクライバ H
メディア ターミネーション ポイントを使用する H.323 トラ
ンク
メディア ターミネーション ポイント（MTP）は、一般に、H.323 トランクの通常動作には必要ありま
せん。ただし、通信相手となるデバイスが、H.323 Version 1 である場合、補足サービス用に Empty
Capabilities Set（ECS）をサポートしていない場合、または H323 FastStart を必要とする場合には必要
です。
MTP が必要かどうかをテストするには、次の簡単な手順を使用します。
1. 電話機から H.323 トランクを介して他のデバイスにコールを発信します。このコールは通常どお
りに発信する必要があります。
2. コールを保留にしてから、保留解除します。コールがドロップする場合は、Unified CM と他のデ
バイス間の相互運用性を保証するために MTP を使用することをお勧めします。
H323 発信 FastStart コール接続
大規模な WAN トポロジを介して IP Phone から発信されるコールに対して、着信側がオフフックで応
答する場合、音声クリッピングが発生します。H.323 トランクまたはゲートウェイが、Unified CM
サーバから分離されている場合、コールのセットアップ時に大量の H.245 メッセージが交換されるた
め、著しい遅延が発生します。
FastStart 機能を使用すると、2 つのパーティ間でメディア接続を確立するために必要な情報が、コール
セットアップの H.225 段階で交換されるため、H.245 メッセージが不要になります。この接続では、
コール セットアップ時に 1 回のラウンドトリップ WAN 遅延が発生しますが、着信側がコールに応答
するときに、発信側で音声クリッピングが発生することはありません。
Unified CM は、H.323 発信 FastStart コールを確立するために、メディア ターミネーション ポイント
（MTP）を使用します。Unified CM は、MTP を割り当て、受信チャネルを開くことで、発信 FastStart
コールを開始します。次に、H.323 Fast Connect プロシージャにより、FastStart 要素を含む SETUP
メッセージが着信側エンドポイントに送信されます。この FastStart 要素には、MTP の受信チャンネル
に関する情報が含まれています。
その他の MTP の使用
MTP は、H.323 トランク上でコールを発信する他のデバイスからのメディア ストリームを終端させる
場合や、同じ音声ペイロードでメディア ストリームを再発信する場合に非常に役立ちます。ただし、
そのような場合、IP アドレスは MTP のアドレスに変更されます。この事実に留意して、次のシナリオ
で MTP を使用します。
• 企業内の電話機、ゲートウェイ、および他のデバイスがすべて RFC 1918 プライベート アドレス
を使用する場合は、すべての音声およびビデオ デバイスにネットワーク アドレス変換（NAT）を
使用しなくても、引き続きパブリック ネットワーク上の他のシステムに接続できます。パブリッ
ク ネットワークと通信する Unified CM サブスクライバがパブリック IP アドレスを使用している
場合、シグナリングはルーティングされます。また、すべての MTP もパブリック アドレスを使用
している場合、RFC 1918 アドレスを持つデバイスからのメディアは MTP で終端され、再度発信
されます。ただし、今度は、パブリック ネットワーク上でルーティング可能なパブリック アドレ
Cisco Unified Communication SRND （Cisco Unified Communications Manager 7.x）
5-14
OL-16394-06-J
第5章
Cisco Unified CM トランク
Unified CM における H.323 の動作
スが割り当てられます。このアプローチを使用すると、RFC 1918 アドレスを持つ何万台ものデバ
イスが、パブリック ネットワークと通信できるようになります。この同じ方式を使用すると、企
業ネットワークにあるデバイスが他の企業またはサービス プロバイダーと通信するときに、その
デバイスの実際の IP アドレスを隠すことができます。
• 信頼性境界を設定すると、ファイアウォールを通過させることや、アクセス コントロール リスト
（ACL）を使用したアクセスを許可することができます。通常、メディアがファイアウォールを通
過できるようにするには、アプリケーション レイヤ ゲートウェイ（ALG）またはフィックスアッ
プを使用して、動的にメディア ストリームにアクセス許可を与えるか、または、ファイアウォー
ルを越えて通信する必要のある音声デバイスすべてで使用するための広範囲のアドレスおよびポー
トを割り当てます。H.323 トランクを使用し、ファイアウォールまたは ACL を通過するすべての
コールには、MTP から発信されるメディアが割り当てられます。このメディアでは、単一の IP ア
ドレスまたは狭い範囲の IP アドレスを使用できます。
これらの方法を両方使用する場合、MTP Required チェックボックスをオンにすると、デフォルトで、
H.323 トランク上のコールが許可されます。このことは、MTP リソースが使用不能の場合や、使い果
たされた場合でも同様です。このデフォルト動作により、コールの音声パスが使用不能になる場合があ
ります。この動作を変更するには、H.323 セクションにある Unified CM サービス パラメータ Fail
Call if MTP allocation fails を True に設定します。
Unified CM における H.323 の動作
この項では、H.323 プロトコルを Unified CM で使用および実装する方法、および特定の機能が所定ど
おりに動作する仕組みとその理由について説明します。
理解するうえで最も重要な点は、どのサブスクライバがコール シグナリング デーモンを実行するかと
いうことです。このデーモンは、H.323 コールを発信および受信する部分的なコードです。これは、通
常、H.225 デーモン（H.225D）と呼ばれます。H.225 は、H.323 プロトコルの一部で、主に呼制御を
担当します。H.245 は、H.323 のもう 1 つの主要コンポーネントで、コールのメディア制御を担当しま
す。
特定の H.323 デバイスに対する Unified CM Group のリストに含まれているサブスクライバによって、
デーモンを実行するサブスクライバと実行時期が決定されます。この点は非常に重要です。これは、不
適切なサブスクライバに送信されたコールは、拒否される場合があるためです。たとえば、この状況が
発生するのは、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 つの特殊機能を提供するためにゲートキーパー ゾーンで登録される特殊
なデバイスです。
Cisco Unified Communication SRND （Cisco Unified Communications Manager 7.x）
OL-16394-06-J
5-15
第5章
Cisco Unified CM トランク
Unified CM における H.323 の動作
– 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 クラスタ内のサブスクライバに H.323 コールが着信すると、コールを受け入れるかまたは
拒否するか、受け入れる場合はどの H.225D がコールを受信するかなど、さまざまな決定が下されま
す。図 5-6 は、このプロセスの仕組みを示しています。
Cisco Unified Communication SRND （Cisco Unified Communications Manager 7.x）
5-16
OL-16394-06-J
第5章
Cisco Unified CM トランク
Unified CM における H.323 の動作
Cisco Unified CM
䉰䊑䉴䉪䊤䉟䊋䈮
H.323 䉮䊷䊦䈏⌕ା
H.323 コールの受け入れまたは拒否を判別するプロセス
H.225 TCP ធ⛯䊏䉝
IP 䉝䊄䊧䉴䈫䇮䈖䈱䉰䊑
䉴䉪䊤䉟䊋䈮⸳ቯ䈘䉏䈢
H.323 䉭䊷䊃䉡䉢䉟
䉁䈢䈲㩷H.323 䉪䊤䉟
䉝䊮䊃䉕ᾖว
৻⥌
ਇ৻⥌
䉲䉫䊅䊥䊮䉫㩷䊘䊷䊃
⇟ภ䉕⏕⹺
䊘䊷䊃
1720
䊘䊷䊃㩷1720
䈪䈭䈇
䊘䊷䊃⇟ภ䈫䇮䈖䈱䉰䊑
䉴䉪䊤䉟䊋䈮⸳ቯ䈘䉏䈢
䉭䊷䊃䉨䊷䊌䊷೙ᓮ䊃䊤䊮䉪
䈪૶↪䈘䉏䉎䉻䉟䊅䊚䉾䉪㩷
䊘䊷䊃䉕ᾖว
৻⥌
䉭䊷䊃䉨䊷䊌䊷೙ᓮ䊃䊤䊮䉪
⌕ା䉮䊷䊦䈫䈚䈩
䉮䊷䊦䉕ಣℂ
⸳ቯᷣ䉂䉭䊷䊃䉡䉢䉟
䉁䈢䈲䉪䊤䉟䉝䊮䊃䈎䉌䈱
䉅䈱䈫䈚䈩䉮䊷䊦䉕ಣℂ
⸳ቯ
⸳ቯ
䉭䊷䊃䉨䊷䊌䊷೙ᓮ 䈘䉏䈩
䈘䉏䈩
Accept
Unknown
䊃䊤䊮䉪䈏㩷㪈㪎㪉㪇㩷䉕 䈇䈭䈇
TCP Connections 䉰䊷䊎䉴 䈇䈭䈇 H.225 TCP
૶↪䈜䉎䉋䈉䉰䊷䊎䉴㩷
䊌䊤䊜䊷䉺䈏 True 䈮
ធ⛯ࠍᜎุ
䊌䊤䊜䊷䉺䈪⸳ቯ䈘䉏䈩
⸳ቯ䈘䉏䈩䈇䉎䈎⏕⹺
䈇䉎䈎⏕⹺
⸳ቯ䈘䉏䈩䈇䉎
⸳ቯ䈘䉏䈩
䈇䉎
⌕ା H.225 TCP ធ⛯ࠍ
ฃߌ౉ࠇ
ਇ৻⥌
H.225 䉶䉾䊃䉝䉾䊒㩷
䊜䉾䉶䊷䉳䉕⏕⹺ᓟ䇮
ㅍାర䉲䉫䊅䊥䊮䉫㩷
䉝䊄䊧䉴䉕᛽಴
H.225 䉲䉫䊅䊥䊮䉫㩷䉝䊄䊧䉴 ৻⥌
䈫⸳ቯᷣ䉂㩷H.323
䉭䊷䊃䉡䉢䉟䉕ᾖว
ਇ৻⥌
ARQ 䉕䉭䊷䊃䉨䊷䊌䊷䈮
ㅍା䇮IP 䊏䉝㩷䉝䊄䊧䉴䉕
૶↪䈚䈩䉮䊷䊦䉕ಣℂ
H225ReleaseComplete
with cause IE - Call Rejected
䊥䉥䊷䉻䊷㩷䊃䊷䊮䈏⡞䈖䈋䉎
⸳ቯᷣ䉂
䉭䊷䊃䉡䉢䉟
䈎䉌䈱䉅䈱䈫
䈚䈩䉮䊷䊦䉕
ಣℂ
132369
図 5-6
Unified CM の H.323 プロトコルには、次の追加機能が含まれています。
• Protocol Auto Detect
この機能では、コールごとに、発信側デバイスが Cisco Unified CM Release 3.2 以降を使用してい
るかどうかを判別できます。コールを受信するたびに、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 クラスタ間
で正しく動作させる仕組みが異なります。
Cisco Unified Communication SRND （Cisco Unified Communications Manager 7.x）
OL-16394-06-J
5-17
第5章
Cisco Unified CM トランク
Unified CM における H.323 の動作
• Tunneled Q.SIG または H.323 Annex M1
Cisco Unified CM 4.1(3) のリリースから、この機能はすべての 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 トランクは、ゲートキーパーに Admission Request（ARQ; 許可要求）を送信すると、
Admission Confirmation message（ACF; アドミッション確認）で異なる E.164 番号を受信する場
合があります。このことは、元の着信番号をこの新しい番号で置き換える必要があることを示して
います。この機能では、Gatekeeper Transaction Message Protocol（GKTMP）を使用して Cisco
ゲートキーパーと通信するルート サーバが必要になります。
（注）
CanMapAlias は、着信番号に関してだけサポートされます。
• 帯域幅要求
H.323 トランクは、ゲートキーパーの帯域幅情報をアップデートし、特定のコールに割り当てられ
た帯域幅の要求量が変更されたことを示すことができます。この機能は、デフォルトでは無効に
なっています。この機能を制御するには、H.323 セクションにある Unified CM サービス パラメー
タ BRQ Enabled を True に設定します。この機能は、H.323 トランク上でビデオを使用するとき
に特に重要です。これは、元の帯域幅要求が許容最大限の量を要求するためです。この機能を有効
にすると、コール アドミッション制御が、コールのセットアップ中にネゴシエートされた実際の
帯域幅を使用することが保証されます。
Cisco Unified Communication SRND （Cisco Unified Communications Manager 7.x）
5-18
OL-16394-06-J
第5章
Cisco Unified CM トランク
SIP トランク
SIP トランク
H.323 トランクの場合と同様、SIP トランクを配置するときに設計に関して考慮すべき事項がいくつか
あります。この項では、これらの設計に関する考慮事項について説明します。
配置に関する一般的な考慮事項
SIP ベース PBX またはサービス プロバイダー IP PSTN 接続など、サードパーティ デバイスとの SIP
トランク接続では、Unified CM からの発信コールにディレイドオファーを使用し、Unified CM への
着信コールにディレイドオファーまたはアーリー オファーのいずれかを使用することをお勧めします。
発信コールにディレイドオファーを使用すると、MTP リソースを SIP トランクに割り当てる必要がな
くなります。ただし、発信側および着信側エンドポイントで DTMF トランスポート タイプが一致しな
い場合（つまり、Unified CM により MTP が動的に挿入される場合）は例外です。
前述のとおり、Cisco Unified Border Element は、Unified CM から音声サービス プロバイダーへの任
意の IP PSTN SIP トランク接続に配置することをお勧めします。
SIP ディレイドオファー、アーリー オファーおよび DTMF については、以降の項で詳しく説明してい
ます。
DTMF Transport
DTMF 情報を SIP エンドポイント間で転送する方法はいくつかあります。一般的に、これらの方法は、
アウトオブバンド（OOB）およびインバンド シグナリングに分類できます。インバンド DTMF 転送方
式では、RTP ストリーム内でそのままの、またはシグナリングされた DTMF トーンのいずれかが送信
されます。これらは、発信側または着信側、あるいはその両方のエンドポイントで処理および解釈され
る必要があります。アウトオブバンド（OOB）シグナリング方式では、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 の一部のモデルだけです。Unsolicited Notify は、非標準方式で、
Cisco IOS ゲートウェイ（Release 12.2 以降）だけで使用されます。INFO は、Unified CM ではサポー
トされていません。
インバンド DTMF 転送方式は、RTP メディア ストリームのそのままのトーン、または RFC 2833 を使
用した RTP ペイロードのシグナリングされたトーンのいずれかで DTMF トーンを送信します。
RFC 2833 は、SIP 製品ベンダーにおいて、主流の DTMF トーン送受信方式となっていて、シスコ音声
製品の大部分でサポートされています。
インバンド シグナリング方式では、RTP メディア ストリームの DTMF トーンが送信されるため、
セッションの SIP エンドポイントは、使用される転送方式（たとえば、RFC 2833）をサポートする
か、このインバンド シグナリングを解釈し変換する方式を提供しなければなりません。2 つのエンポイ
ントで、呼制御に Back-To-Back User Agent（B2BUA）サーバ（たとえば、Cisco Unified CM）が使
用されていて、これらのエンドポイントで、各デバイスと呼制御ボックス間で異なる DTMF 方式がネ
ゴシエートされる場合、DTMF の違いをどのように扱うか、つまり、MTP 挿入または OOB 方式のい
ずれを介するかが、この呼制御ボックスにより決定されます。Unified CM では、DTMF 転送方式の不
一致（たとえば、インバンドとアウトオブバンド DTMF ）は、メディア ターミネーション ポイント
（MTP）を挿入することで解決されます。MTP は、インバンド DTMF シグナリング（RFC 2833）で
RTP ストリームを終端させ、RTP ストリームから DTMF トーンを抽出して、これらのトーンをアウト
Cisco Unified Communication SRND （Cisco Unified Communications Manager 7.x）
OL-16394-06-J
5-19
第5章
Cisco Unified CM トランク
SIP トランク
オブバンドで 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 ディレイドオファーおよびアーリー オファー
Cisco Unified CM は、RFC 3264 で定義されているように、SIP セッションの確立に SIP オファー / ア
ンサー モデルを使用します。この場合、オファーは、SIP メッセージ本文で送信される Session
Description Protocol（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 トランクを介して Unified CM に接続する SIP スイッチで、発着信
コールに提供および選択されるコーデックを制御する場合に便利です（つまり、Unified CM からの
ディレイドオファー発信および Unified CM へのアーリー オファー着信を使用する場合、サービス プ
ロバイダーは、いかなる場合でもオファーを送信し、これにより、すべてのコールに提供されるコー
デックを決定できます）。
Cisco Unified Communication SRND （Cisco Unified Communications Manager 7.x）
5-20
OL-16394-06-J
第5章
Cisco Unified CM トランク
SIP トランク
アーリーメディア
場合によって、SIP セッションで、2 つの SIP エンドポイント間でのメディア機能交換を終了する前
に、メディア パスをセットアップする必要があります。そのため、SIP プロトコルでは、初期オファー
がエンドポイントで受信された後で、アーリーメディアを確立できます。アーリーメディアを使用する
理由は、次のようにいくつかあります。
• 着信側デバイスでは、一定時間を超えるシグナリング遅延が発生したコールに対するオーディオ
カットスルー遅延（クリッピング）の効果を軽減させるか、ネットワークベース音声メッセージを
発信側に提供する場合に、アーリーメディア RTP パスを確立します。
• 発信側デバイスでは DTMF または音声での IVR システムにアクセスする場合に、アーリーメディ
ア RTP パスを確立します。
Unified CM は、アーリー オファーおよびディレイドオファーの両方のコールに対してアーリーメディ
アをサポートしています。
（注） 「アーリー オファー」と「アーリーメディア」という用語は混乱しやすいですが、同じではないので注
意してください。
メディア ターミネーション ポイント
メディア ターミネーション ポイント（MTP）は、通常、Unified CM SIP トランクからのディレイド
オファー コールには必要ありません。そのため、ディレイドオファーは、Unified CM SIP トランクか
らの発信コールのコール セットアップ方式として推奨します。Unified CM からの発信アーリー オ
ファー コールでは、MTP リソースが必要で（SIP トランクの MTP required チェックボックスが選択
され、提供されるコーデックが選択されている）、これは、コールの期間中、メディア パスに存在しま
す。
Unified CM からのコール発着信では、エンドポイントは、RFC 2833 またはアウトオブバンド DTMF
方式（たとえば、KPML）エンドツーエンドのいずれを使用するかネゴシエートできます。エンドポイ
ント間で共通の DTMF 方式をネゴシエートできない場合、Cisco Unified CM 5.x 以降のリリースでは、
MTP が動的に挿入されます。Cisco Unified CM 5.x 以降リリースは、ディレイドオファー（SDP を使
用しない Invite）をデフォルトでサポートします。ディレイドオファーは、SIP RFC 3261 仕様の必須
部分ですが、SIP アプリケーションによってはサポートされていません。そのような場合は、SIP
Trunk 設定で MTP を事前に割り当てておくことにより、SIP トランクでアーリー オファーがサポート
されるように設定する必要があります。
MTP は、次の 3 種類の形式で利用できます。
• Cisco IOS ゲートウェイでのソフトウェアベースの MTP。任意の Cisco IOS T-train ソフトウェア
リリースで使用できます。Cisco 3845 サービス統合型ルータで最大 500 セッション（コール）ま
で拡張できます。
• Cisco IOS ゲートウェイでのハードウェアベースの MTP。任意の Cisco IOS T-train ソフトウェア
リリースで使用できます。ハードウェア MTP は、オンボード DSP リソースを使用し、シスコ
ルータ プラットフォームでサポートされる DSP 数に従ってコールを拡張します。
• Cisco Media Convergence Server（MCS）で Cisco IP Voice Media Streaming Application を使用
するソフトウェアベースの 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
Cisco Unified Communication SRND （Cisco Unified Communications Manager 7.x）
OL-16394-06-J
5-21
第5章
Cisco Unified CM トランク
SIP トランク
!
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
G.729 コーデックがアーリー オファーで選択される場合、Cisco IOS ゲートウェイでソフトウェアまた
はハードウェアのいずれかの MTP を使用しなければならないので注意してください。MTP の詳細に
ついては、「メディア リソース」（P.6-1）の章を参照してください。
SIP Trunk Transport Protocol
SIP トランクは、メッセージ トランスポート プロトコルとして TCP または UDP のいずれかを使用で
きます。接続状態を保持する、信頼できるコネクション型のプロトコルとしては、TCP の方が適して
います。これは、SIP トランクの遠端の宛先デバイスで障害が発生した場合、そのほぼ直後に、代替ト
ランクへのフェールオーバーが実行されるためです。UDP は、コネクション型プロトコルではないた
め、SIP トランクの終端の宛先デバイスが利用できないかどうかを判別するときに SIP プロトコル ス
タックに依存します。UDP ベース SIP トランクの場合、Unified CM は、SIP Invite Retry カウントお
よび SIP Trying タイマーの値を使用して、遠端のデバイス障害を検出して、これに対応します。デ
フォルトでは、フェールオーバーには、コールごとに約 64 秒かかりますが、これらのタイマーを調整
して、フェールオーバー時間を許容値まで短縮できます。
SIP トランク タイマーの調整の詳細については、次に示す設定例およびテクニカル ノートを参照して
ください。
http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_configuration_example09186a0
08082d76a.shtml
SIP クラスタ間トランク
クラスタ間トランキングに SIP トランクを使用する主な利点の 1 つは、コール存続可能性です。ただ
し、H.323 トランクと比較した場合、SIP トランクは Annex M1 を使用した QSIG Tunneling をサポー
トしません。DNS ではなく宛先 IP アドレスを使用する SIP トランクを介した発信コールでは、サブス
クライバのロード バランシングは、H.323 トランク コールの場合と同じ方法で実現できます（「発信
コールのロード バランシング」（P.5-12）の「H.323」の項を参照してください）。
Cisco Unified CM Release 3.3 以降の H.323 トランクとは異なり、SIP トランクは単一の IP アドレス
または DNS Server（SRV）レコードだけを指すことができます。DNS SRV 機能のないクラスタ間 SIP
トランクにフェールオーバーおよびロード バランシングを提供するためには、複数の SIP トランクを
設定します。さらに、その SIP トランクは、ルート グループおよびルート リストのメンバーになる必
要があります。また、重要な点として、Unified CM が受け入れるコールが、設定済み SIP トランクの
いずれかの宛先アドレスと IP アドレスが一致する SIP デバイスからのコールだけであることにも注意
してください。さらに、SIP メッセージの着信ポート番号は、その SIP トランク用に設定されたポート
番号と一致している必要があります。その結果、コールが着信する可能性のある、あらゆる遠端 SIP デ
バイスのすべての IP アドレスと一致するように、できるだけ多くの SIP トランクに宛先アドレスを設
Cisco Unified Communication SRND （Cisco Unified Communications Manager 7.x）
5-22
OL-16394-06-J
第5章
Cisco Unified CM トランク
SIP トランク
定するようにしてください。この方式は、複数の Unified CM クラスタがある場合には適さないため、
その場合は DNS SRV で SIP トランクを使用することをお勧めします。図 5-7 は、DNS SRV を使用し
たクラスタ間 SIP トランク コールのコール フローを示しています。
図 5-7
DNS SRV を使用したクラスタ間 SIP トランクのコール フロー
3
Cluster1
Cluster FQDN: cluster1.foo.com
CCM4
M
2
CCM3
M
CCM2
M
4
6
m
.co
foo
.
r1.
ste om .
clu o.c om
䊒䋺 r1.fo o.c
䉝䉾 ste 1.fo
䉾䉪 .clu ster
3 lu
䊦
M
V
.c
SR CC M4
C
S
60
DN 1 50 60 C
0
10 1 5
20
D
10 NS
20 1 SR
1 506 V 䊦
50 0
60 C 䉾䉪
C CM 䉝
C -A 䉾
M
䊒
-B .cl
:
.c us clu
lu te
st r2 ste
er .f r2
2. oo .fo
fo .c
o. om o.c
om
co
m
DNS 䉰䊷䊋
Cluster2
⊒ା SIP invit
e
ర䋺C
CM3 :875220
0
.clus
ter1. 1@clust
e
voo.c
om ተ r2.foo.co
m
వ䋺C
CM-A
.
Cluster FQDN: cluster2.foo.com
M
M
M
CCM-D
CCM-C
CCM-B
5
clust
CCM1
M
er2.f
oo.co
䊦䊷䊃㩷䊌䉺䊷䊮: 8752XXXX SIP 䊃䊤䊮䉪䈱ተవ䋺
DSN SRV cluster2.foo.com
m
M
CCM-A
IP
1
8-645-3001
141884
䊦䊷䊃㩷䊌䉺䊷䊮: 8752XXXX SIP 䊃䊤䊮䉪䈱ተవ䋺
DSN SRV cluster2.foo.com
IP
87522001 䈮䉮䊷䊦䈜䉎
8-752-2001
ᵈ䋺DNS A 䊦䉾䉪䉝䉾䊒䈲䇮䈖䈱䉮䊷䊦 䊐䊨䊷䈎䉌೥㒰䈘䉏䈩䈇䉁䈜䇯
図 5-7 は、このコール フローにおける次の手順を示しています。
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
ルックアップが行われます。
Cisco Unified Communication SRND （Cisco Unified Communications Manager 7.x）
OL-16394-06-J
5-23
第5章
Cisco Unified CM トランク
SIP トランク
4. CCM3 は、SIP Invite を [email protected] に送信します。宛先アドレスは CCM-A の
IP アドレスに設定されます。
5. Unified CM は、このコールをローカル コールとして解釈します。Uniform Resource Identifier
（URI; ユニフォーム リソース識別子）のホスト部分が Cluster FQDN エンタープライズ パラメー
タと一致しているためです。Cluster2 には、CCM3 の宛先が設定された SIP トランクがありませ
ん。したがって、DNS SRV を使用して SIP トランクに設定されたすべてのドメインに対して、
DNS SRV ルックアップを行います。その場合、例では cluster1.foo.com の DNS SRV の宛先を持
つ単一のトランクが示されています。
6. DNS サーバは 2 つのエントリを返し、そのうちの 1 つが Invite の発信元 IP アドレスと一致しま
す。クラスタはコールを受け入れ、内線 87522001 にコールをルーティングします。
SIP トランクでの SRTP
Secure RTP（SRTP）は、Cisco Unified CM 7.0 以降のリリースでの SIP トランク上でサポートされま
す。SRTP では、リモート側との暗号化された TLS 接続を使用してトランクを確立する必要がありま
す。SRTP パラメータは、このトランクを介して、SIP SDP メッセージで交換されます。
MTP は SRTP をサポートしていないため、SRTP の場合、トランク設定の MTP Required フラグはオ
フのままにする必要があります。このフラグをオフにすることで、Unified CM は、ディレイドオ
ファー コールだけで SRTP をサポートするようになります。ただし、Unified CM により、たとえば、
Trusted Relay Point または RSVP エージェントなど、アーリー オファー以外の目的で MTP が動的に挿
入される場合、SRTP は MTP を介してサポートされます。
MTP を使用する dtmf-relay は（MTP が、インバンドおよびアウトオブバンド DTMF 信号を変換する
必要がある場合）、メディア ストリームの DTMF パケットを復号化できないため、SRTP では機能しな
いので注意してください。
発番号の正規化および SIP トランク
Unified CM 7.0 では、ゲートウェイおよびトランクを介して着信するコールの発番号を正規化形式に
変換する機能が導入されました。通常、この形式は、E.164 仕様に従ってグローバルにルーティングで
きる国際的な番号表現にします。
正規化のプロセスは、着信コールの番号および関連する番号タイプに依存します。番号タイプ パラ
メータは、発番号のプレフィックスとして付加する適切な番号を選択するときに使用できます。番号タ
イプは、Unknown、Subscriber、National、または International のいずれかです。これらの番号タイプ
（P.10-1）の章を参
がどのように使用されるかについての詳細および例については、
「ダイヤル プラン」
照してください。
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
Cisco Unified Communication SRND （Cisco Unified Communications Manager 7.x）
5-24
OL-16394-06-J
第5章
Cisco Unified CM トランク
IP トランク上でのコーデック選択
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 に変更し、接続サービス プロバイダーにより要求された
場合は除去と番号タイプ変更の両方を実行しなければなりません。
IP トランク上でのコーデック選択
通信エンティティ間でメディアを確立するには、これらのエンティティが、使用する 1 つ以上のコー
デックに同意する必要があります。このコーデック（ビデオの場合は複数のコーデック）は、関連エン
ティティでサポートされる複数のコーデックの同意点、および Unified CM の設定済みポリシーから決
定します。Unified CM のポリシーは、リージョン設定で指定されます。オーディオのリージョン内
コーデック、およびビデオ（オーディオを含む）のリージョン内帯域幅設定により、それぞれのリー
ジョンに含まれるデバイス間で使用されるコーデックのセットが決まります。このコーデック設定は、
これらのリージョンで通信を行うデバイスに許可される最大帯域幅だけを指定するもので、すべての
コールで使用される正確なコーデックを指定するわけではないので注意してください。これらのエン
ティティで、複数のコーデックを共有し、リージョン間設定で、複数のコーデックの選択が許可されて
いる場合、Unified CM は、品質が最高のコーデックを選択します。
たとえば、トランクと IP Phone 間のリージョン間オーディオ コーデック設定が G.729（低帯域幅コー
デック）に設定されていて、両方のエンドポイントで G.729 をサポートしている場合、このコーデック
が選択されます。ただし、リージョン間コーデックが G.711（高帯域幅コーデック）に設定されてい
て、両方のエンドポイントで G.711、G.722、G.729 がサポートされている場合、G.722 が最高のオー
ディオ品質を提供するため、Unified CM はこのコーデックを選択します。また、例外として、iLBC
コーデックが選択されることがあります。両方のエンドポイントで iLBC コーデックをサポートしてい
る場合、このコーデックの使用が可能な場合、およびリージョン内設定でリージョン間の Link Loss
Type が lossy に指定されている場合、iLBC が使用されます。この選択は、最高品質のコーデックを使
用するという規則より優先されます。
（注）
MTP Required がトランクで選択されている場合、他の設定に関係なく、MTP に指定されるコーデッ
クが使用されます。この場合、リージョン間コーデック設定は、このコーデックを許可するように適切
に設定されていなければなりません。
Cisco Unified Communication SRND （Cisco Unified Communications Manager 7.x）
OL-16394-06-J
5-25
第5章
Cisco Unified CM トランク
Cisco Unified CM トランクおよび緊急サービス
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 へのローカル ゲートウェイを使用できなけれ
ばなりません。詳細については、「Emergency Services」（P.11-1）を参照してください。
IP トランクを配置するときの設計に関する推奨事項
Cisco Unified CM から IP トランクを配置する場合、次のガイドラインとベスト プラクティスを参考に
してください。
• トランク プロトコルを選択します。使用しているシステムの要件および必要な機能に基づいて、
H.323 または SIP のいずれのトランクを使用するかを選択します。たとえば、PBX との接続に
Q.SIG トンネリングが必要な場合は H.323 を使用します。また、トランクの選択は、配置した
Unified CM のバージョンにより異なる場合もあります。SIP トランク機能は、通常、
Unified CM 5.1(2) 以降のリリースで拡張されているため、これらのいずれかのバージョンを使用
する場合 SIP を選択してください。
• Unified CM 4.x での SIP トランクでは、常に、発信コールに MTP が必要です。また、これらのト
ランクは、音声通信の場合は G.711 コーデックに限定されます。予測される同時コール数に対応で
きるだけの十分な MTP リソースを確保するようにしてください。
• Unified CM 5.x 以降のリリースでの SIP トランクでは、各発信コールに MTP を割り当てるかどう
かを選択できます。デフォルトでは、MTP は使用されません。リモート エンドでアーリー オ
ファー（初期 INVITE の オファー SDP）が必要ない場合、ディレイドオファーを使用して、MTP
リソース使用を最適化してください。
• 監視されている場合、音声クリッピングは、トランクで PRACK を有効にすることで、最小化また
は削減できます。このパラメータは、Cisco CallManager サービスの Service Parameters で有効に
することができます（SIP Rel1XX Enabled）。
• セキュリティ設定や SIP トランクを介して受け入れられるメッセージのタイプなどの他の操作パラ
メータは、SIP Trunk Security Profile で有効にすることができます。ここでは、TLS およびダイ
ジェスト認証のパラメータだけでなく、トランクが Presence Subscription、Out-Of-Dialog
REFER メッセージ、Replaces ヘッダー、または Unsolicited Notification を受け入れるかどうかを
指定するパラメータも設定できます。
• サービス プロバイダー ネットワークに接続する場合、Cisco Unified Border Element を使用するこ
とをお勧めします。企業とサービス プロバイダーのネットワーク間への境界ポイント提供のほか、
Cisco Unified Border Element は、2 つのネットワーク間での SIP シグナリング相互運用性の拡張
にも使用できます。
• Unified CM 7.x では、G.711 のほかに、低帯域幅コーデック G.729 をアーリー オファーで使用で
きます。ただし、アーリー オファーでシグナリングできるのは、これらのコーデックのいずれか 1
つだけです。アーリー オファーでの複数のコーデックの使用、または Unified CM からディレイド
オファー コールへのアーリー オファー コールへの変換は、Cisco Unified Border Element の
Delayed Offer to Early Offer 機能により実行できます。
Cisco Unified Communication SRND （Cisco Unified Communications Manager 7.x）
5-26
OL-16394-06-J
第5章
Cisco Unified CM トランク
IP トランクを配置するときの設計に関する推奨事項
• SIP トランクを介して SRTP を使用する場合、Unified CM でサポートされる唯一のモードは、
ディレイドオファーです。
Cisco Unified Communication SRND （Cisco Unified Communications Manager 7.x）
OL-16394-06-J
5-27
第5章
Cisco Unified CM トランク
IP トランクを配置するときの設計に関する推奨事項
Cisco Unified Communication SRND （Cisco Unified Communications Manager 7.x）
5-28
OL-16394-06-J