Cisco Collaboration システム 12.x ソリューション リファレンス ネットワーク デザイン（SRND）

SIP オファー/アンサー モデル

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

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

ディレイド オファーおよびアーリー オファーは、メディア機能の交換にすべての標準ベースの SIP スイッチで使用できる 2 つのオプションです。ほとんどのベンダーは、ディレイド オファーまたはアーリー オファーのいずれかを選択しています。また、それぞれに独自の利点や制限事項があります。

Unified CM SIP トランクは、SIP ディレイド オファーおよび SIP アーリー オファーの両方をサポートします。デフォルトでは、SIP トランクはディレイド オファーとして設定されており、音声、ビデオ、および暗号化されたコールをサポートします。アーリー オファー コールでは、次の 3 つのトランク設定オプションを使用できます。

• SIP トランクでオンになっている [MTP が必須（MTP Required] オプション：MTP がすべてのコールに挿入されます。
• [音声コールとビデオ コールに対する早期オファー サポートが必須（必要な場合は MTP を挿入）（Early Offer support for voice and video calls Mandatory (insert MTP if needed)）]：SIP プロファイルのオプション。発信側デバイスのメディア特性（たとえば、アーリー オファー SIP トランクを介して転送される着信ディレイド オファー コールなど）を判別できない場合、Unified CM はメディア ターミネーション ポイント（MTP）を挿入します。
• [音声コールとビデオ コールに対する早期オファーのサポートはベスト エフォート（MTP の挿入なし）（Early Offer support for voice and video calls Best Effort (No MTP inserted)）]：SIP プロファイルのオプション。発信側デバイスのメディア特性を判別できる場合にのみ、アーリー オファーが送信されます。メディア特性を判別できない場合は、ディレイド オファーが送信されます。

ディレイド オファー、アーリー オファー、およびベスト エフォートのアーリー オファーに関する Unified CM アーリー オファー トランク設定については、Unified CM SIP トランク：ディレイド オファー、アーリー オファー、およびベスト エフォートのアーリー オファーの項で説明します。

SIP ディレイド オファー

ディレイド オファーでは、セッションの開始側（発信側デバイス）は、その機能を初回の Invite で送信せず、着信側デバイスからその機能（たとえば、着信デバイスでサポートされるコーデックのリスト）が送られるまで待機します（これにより、発信デバイスは、セッションで使用されるコーデックを選択できます）。図 6-2 では、SIP ディレイド オファーの例を示します。

図 6-2 SIP ディレイド オファー

SIP アーリー オファー

アーリー オファーでは、セッションの開始側（発信側デバイス）は、その機能（たとえば、サポート対象のコーデック、IP アドレス、および RTP の UDP ポート番号）を初回の Invite に含まれる SDP ボディで送信します（これにより、セッションで使用されるコーデックを着信側デバイスで選択できるようになります）。アーリー オファーおよびディレイド オファーは、どちらも SIP 規格の必須となる部分ですが、アーリー オファーは、サードパーティのユニファイド コミュニケーション ベンダーが優先的に使用することが多く、IP PSTN サービス プロバイダーではほとんどの場合に使用されています。サービス プロバイダーは、初回の INVITE の SDP オファーが受信されると、発信側デバイスに一方向メディアが確立されるようになるアーリー オファー機能を使用します。この一方向メディア機能は、通話の課金が始まる前に、発信者に（たとえば、不明な番号）対するアナウンスを再生するために使用されます（通話の課金が開始されるのは通常、双方向メディアが確立され、トランザクションの最終確認応答（ACK）が受信された後です）。

（注） SIP ベースの Cisco Unified IP Phone は、アーリー オファーを送信します。（図 6-3 を参照）。

図 6-3 SIP アーリー オファー

Provisional Reliable Acknowledgement（PRACK）

SIP は、最終応答と暫定応答の 2 つのタイプの応答を SIP 要求で定義します。

最終応答（たとえば、2XX、3XX、および 4XX 応答）は、処理された要求（INVITE など）の結果を伝達し、確実に送信されます（確認応答されたことを意味します）。

暫定応答（すべての 1XX 応答）は、要求の経過に関する情報を提供しますが、確実には送信されません。そのため、暫定応答の送信者は、受信されたことを認識しません。この理由から、信頼できない 1XX 応答で SDP 情報は送信されません。

Provisional Reliable Acknowledgements（PRACK）は、確実に 1XX 応答を送信できる SIP プロトコルの拡張機能です。PRACK は、PSTN との相互運用シナリオに 1XX 応答の信頼性を提供するため実用的です。また、双方向メディアを設定する前に交換する必要がある SIP メッセージ数を減らすために使用することもできます（図 6-4 および図 6-5 を参照）。

PRACK は、アーリー オファーまたはディレイド オファーを使用する SIP トランク上で使用できます。 アーリー メディア とも呼ばれます。PRACK は Cisco Collaboration 製品の大半でサポートされており、一般に推奨される機能です。

図 6-4 アーリー メディア（PRACK）を使用した SIP アーリー オファー

図 6-5 アーリー メディア（PRACK）を使用した SIP ディレイド オファー

（注） 100 Trying 応答は、Unified CM が INVITE を受信したことを示します。180 Ringing および 183 Session in Progress 応答は、ユーザが呼び出しを受けていることを示し、SIP ヘッダー メッセージ（PRACK が使用されている場合は、SIP メッセージ本文内の SDP コンテンツ）で着信側ユーザに関する情報を送信するのに使用されます。

Session Description Protocol（SDP）およびメディア ネゴシエーション

SDP は、SIP のコンパニオン プロトコルです。RFC 4566 に規定されているように、SDP はメディア特性について記載し、エンドポイント間のマルチメディア セッションのメディア タイプ、形式、および関連付けられたパラメータをネゴシエートするために使用されます。これらのメディア特性は、SDP メッセージで一連の 1 行フィールドに記載されます。

Session Description Protocol（SDP）および音声コール

表 6-2 、 表 6-3 、および図 6-6 の例では、音声コールの SDP オファーとアンサーを示します。

対応する SDP アンサーは、オファーを受信するエンドポイントのメディア特性および双方向音声メディアのエンドポイントによって選択される音声コーデックについて記載します（ 表 6-3 を参照）。

図 6-6 ネゴシエートされた音声コール

Session Description Protocol（SDP）およびビデオ コール

音声コールの場合、共通の音声コーデックの対称のメディア フローがエンドポイントによってネゴシエートされます。ビデオ メディア フローの場合、通常、送受信メディア機能が非対称であることが望まれます。非対称の要件は、アップロードとダウンロード速度が異なるブロードバンド サービスなどのいくつかの使用例に由来します（大きさ順が用いられることが多い）。さらに、ビデオの符号化は復号化より CPU を使用でき、ビデオ エンドポイントは、一般に符号化することが可能な解像度より高い解像度で復号化できます。このような要件から、SDP オファーおよびアンサーで送信されるビデオ コーデック機能は、それぞれのエンドポイントの受信機能と見なされ、一般に非対称である必要があります。

表 6-4 は、音声コールおよびビデオ コールの SDP オファーを示します。

この SDP メッセージで提供される H.263 および H.264 コーデックには、エンドポイントの受信機能について記載する追加のパラメータの範囲が含まれます。SDP アンサーのネゴシエートされた H.264 コーデックに対して 表 6-5 に示されるように、これらのパラメータは対称的である必要はありません。

プロファイル レベル ID およびパケット化モードは、ネゴシエートされたビデオ コールで対称的である必要があります。プロファイル レベル ID は、エンドポイントでサポートされる H.264 機能、解像度、フレーム レート、およびビット レットの最小サブセットについて記載します。パケット化モードは、ビデオ サンプルをどのようにカプセル化し、RTP パケットで送信できるかについて記載します。プロファイル レベル ID とパケット化モードの後のメディア属性は、対称的である必要はなく、 表 6-5 および 図 6-7 に示されるように、実際にネゴシエートされたビデオ コールですべてが対称的でありません。

図 6-7 ネゴシエートされた音声コールおよびビデオ コール

ビデオ デスクトップ共有および Binary Floor Control Protocol（BFCP）

ビデオ デスクトップおよびプレゼンテーション共有では、エンドポイントは追加の RTP ビデオ チャネルをネゴシエートして、共有されるコンテンツ（たとえば、プレゼンテーションのスライド）と、ビデオまたは会議コール内のリソースへの共有アクセスを管理する BFCP の UDP チャネルを送信します。（図 6-8 を参照）。BFCP は、RFC 4582 および RFC 4583 に記載されています。

遠端カメラ制御（FECC）

遠端カメラ制御を使用すると、ユーザはビデオ ソースを選択して、パン、チルト、ズームおよびフォーカスなどのカメラのアクションを制御できます。FECC を使用したエンドポイントは、カメラ制御に対して追加の RTP チャネルをネゴシエートします。（図 6-8 を参照）。FECC は、H.281、H.224、および RFC 4573 に記載されています。

図 6-8 プレゼンテーション共有および遠端カメラ制御を使用した音声コールおよびビデオ コール

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

Cisco Unified CM は、クラスタ内のコール処理サブスクライバ ノードで SIP トランク コールが発信または受信されるようにする設定オプションを提供しています。

SIP トランク：すべてのノードおよびルート ローカル ルールで実行

SIP トランクで [すべてのアクティブな Unified CM ノードで実行（Run on all Active Unified CM Nodes）] オプションをオンにすると、Unified CM は、クラスタ内のコール処理サブスクライバごとに SIP トランク デーモンのインスタンスを作成します。そのため、どのコール処理サブスクライバでも SIP トランク コールを発信または着信できます。（この機能の前は、Unified CM グループを使用して最大 3 つのノードがトランクごとに選択可能でした）。[すべてのアクティブな Unified CM ノードで実行（Run on all Active Unified CM Nodes）] をオンにすると、発信 SIP トランク コールは、（たとえば電話またはトランクから）着信コールを受信したのと同じノードから発信します（ルート ローカル ルールに基づいて）。[すべてのアクティブな Unified CM ノードで実行（Run on all Active Unified CM Nodes）] 機能は、トランクの Unified CM グループ設定を無効にします。

SIP トランクでは、ルート ローカル ルールは次のように動作します。

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

SIP トランクで [すべてのアクティブな Unified CM ノードで実行（Run on all Active Unified CM Nodes）] をオンにすることが推奨されます。この機能を使用すると、発信コールがクラスタ内のコール処理ノードで発信されたり、受信されたりできるからです。[すべてのアクティブな Unified CM ノードで実行（Run on all Active Unified CM Nodes）] は、発信 SIP トランク上で確立される前に、コールが同じクラスタ内のコール処理ノード間でセットアップされないようにすることもできます。

すべての Unified CM SIP トランクと同様に、トランクに関連付けられている SIP デーモンは、トランクの宛先アドレス フィールドに定義された IP アドレスを持つエンド システムからの着信コールのみを受け入れます。同じ宛先への複数の SIP トランクが同じコール処理ノードを使用している場合、各トランクが一意に識別されるように、トランクごとに一意の着信および発信のポート番号を定義する必要があります。

ルール リスト：すべてのノードおよびルート ローカル ルールで実行

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

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

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

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

ルート リストで [すべてのアクティブな Unified CM ノードで実行（Run on all Active Unified CM Nodes）] をオンにしていない場合、ルート リストのインスタンスはクラスタ内の 1 つのノード（ルート リストの Unified CM グループのプライマリ ノード）でアクティブになります。選択した発信トランクが、ルート リストの Unified CM グループのプライマリ ノードでもアクティブな場合、ルート ローカル ルールが適用され、結果として発信コールの分配が最適ではなくなります。これは、すべての発信トランク コールがこのノードから発信されるためです。

すべてのルート リストおよび SIP トランクで、[すべてのアクティブな Unified CM ノードで実行（Run on all Active Unified CM Nodes）] をオンにすることを強く推奨します。

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

SIP トランクは、最大 16 の宛先 IP アドレス、16 の完全修飾ドメイン名、または単一の DNS SRV エントリを使用して設定できます。追加の宛先 IP アドレスをサポートしているため、2 つの Unified Communications システム間のコール分配のために、ルート リストおよびルート グループに関連付けられた複数のトランクを作成する必要性が軽減されます。結果として、Unified CM トランク設計が単純になりますこの機能は、[すべてのアクティブな Unified CM ノードで実行（Run on all Active Unified CM Nodes）] 機能と併用できます。（図 6-9 および図 6-10 を参照）。ただし、Unified CM SIP トランクと関連付けられた SIP デーモンは、トランクの宛先アドレス フィールドに定義された IP アドレスを持つエンド システムからの着信のみを受け入れる点に注意してください。1 つ以上の宛先アドレスで 1 つの SIP トランクを使用して、Unified CM クラスタをもう 1 つのユニファイド コミュニケーション システムに接続します。トランクのフェールオーバーが必要な場合は、フェールオーバーのユニファイド コミュニケーション システムに追加のトランクを作成し、ルート リストとルート グループを使用して、トランクの選択を順序付けします。Unified CM は、設定された SIP トランク宛先アドレスで発信コールをランダムに分配します。

図 6-9 [すべての Unified CM ノードで実行（Run on All Unified CM Nodes）] および複数の宛先アドレスを使用した SIP トランク

図 6-10 [すべての Unified CM ノードで実行（Run on All Unified CM Nodes）] をオンにした SIP トランクおよびルート リスト

DNS を使用する SIP トランク

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

• SRV ホストの優先順位付けが必要な場合
• SRV ホストの重み付けが必要な場合
• 必要な宛先 IP アドレス数が 16 を超える場合
• DNS SRV の解決が、宛先 Unified Communications システムの要件の場合

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

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

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

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

1. クラスタ 1 内の IP Phone が 87522001 にコールします。

2. コールはルート パターン 8752XXXX と一致し、このパターンは cluster2.foo.com の DNS SRV を使用した SIP トランクを指しています。電話機と SIP トランクの両方が登録されているため、クラスタ 1 の CUCM-4 はこのコールに対処するノードです。CUCM-4 は、cluster2.foo.com の DNS SRV ルックアップを送信します。

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

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

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

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

（注） DNS A ルックアップは、このコール フローでは表示されません。

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 トランクで SIP OPTIONS Ping を有効にすることを推奨します。有効にすることで、Unified CM は、ノードごと、コールごと、およびタイムアウトごとにトランク宛先の状態を判別するのではなく、ダイナミックにトランクの状態を追跡できるためです。

Unified CM SIP トランク：ディレイド オファー、アーリー オファー、およびベスト エフォートのアーリー オファー

ここでは、Unified CM SIP トランクでのディレイド オファー、アーリー オファー、およびベスト エフォートのアーリー オファーの使用に関するガイドラインを示します。

Unified CM SIP ディレイド オファー

Unified CM SIP トランクのデフォルト設定では、ディレイド オファー（SDP コンテンツなしで送信される SIP INVITE）を使用します。このデフォルト設定を使用して、SIP トランクを経由するすべての発信コールは SIP ディレイド オファーを送信します。メディア ターミネーション ポイント（MTP）は、送信 INVITE で使用されません。つまり、受信オファーに応答して送信されるアンサー内の SDP コンテンツを生成するのに使用されません。ただし、DTMF 転送の不一致に対応するために MTP を使用できます。SIP トランクを介して送信されるすべてのコールがディレイド オファーを送信するようにするには、このデフォルト設定を使用します。音声コール、ビデオ コール、および暗号化されたコールがサポートされます。

Unified CM SIP アーリー オファー

Unified CM SIP トランクを経由するすべての発信コールにアーリー オファーを有効にするには、2 つの設定可能なオプションがあります。

• メディア ターミネーション ポイントが必須（Media Termination Point Required）
• 音声コールとビデオ コールに対する早期オファーのサポートが必須（必要に応じて MTP を挿入）

[メディア ターミネーション ポイントが必須（Media Termination Point Required）] を使用したアーリー オファー

SIP トランクで [メディア ターミネーション ポイントが必須（Media Termination Point Required）] オプションをオンにすると、トランクのメディア リソース グループ（MRG）からの MTP が各着信コールおよび発信コールに割り当てられます。（図 6-12 を参照）。この処理でスタティックに割り当てられた MTP は G.711 または G.729 コーデックのみをサポートするため、選択したコーデック タイプを使用して、メディアは音声コールにのみ限定されます。[メディア ターミネーション ポイントが必須（Media Termination Point Required）] を使用したアーリー オファーの有効化は、[音声コールとビデオ コールに対する早期オファー サポートが必須（必要な場合は MTP を挿入）（Early Offer support for voice and video calls Mandatory (insert MTP if needed)）] および [音声コールとビデオ コールに対する早期オファーのサポートはベスト エフォート（MTP の挿入なし）（Early Offer support for voice and video calls Best Effort (No MTP inserted)）] に変更されています。[メディア ターミネーション ポイントが必須（Media Termination Point Required）] を使用したアーリー オファーは、着信コールと発信コールの音声メディアが MTP の 1 つの IP アドレスにアンカーされる必要がある場合に有効です。

図 6-12 [メディア ターミネーション ポイントが必須（Media Termination Point Required）] を使用した SIP アーリー オファー

[音声コールとビデオ コールに対する早期オファー サポートが必須（必要な場合は MTP を挿入）（Early Offer support for voice and video calls Mandatory (insert MTP if needed)）] を使用したアーリー オファー

SIP トランクに関連付けられた SIP プロファイルで [音声コールとビデオ コールに対する早期オファー サポートが必須（必要な場合は MTP を挿入）（Early Offer support for voice and video calls Mandatory (insert MTP if needed)）] を有効にして MTP が挿入されるのは、発信デバイスがアーリー オファーの作成に必要なメディア特性を Unified CM に提示できない場合のみです。一般的に、[メディア ターミネーション ポイントが必須（Media Termination Point Required）] よりも [音声コールとビデオ コールに対する早期オファー サポートが必須（必要な場合は MTP を挿入）（Early Offer support for voice and video calls Mandatory (insert MTP if needed)）] が推奨されるのは、この設定オプションによって MTP の使用量が減り、音声コール、ビデオ コール、および暗号化されたコールをサポートできるためです。（図 6-13 を参照）。

[音声コールとビデオ コールに対する早期オファー サポートが必須（必要な場合は MTP を挿入）（Early Offer support for voice and video calls Mandatory (insert MTP if needed)）] に設定されている SIP トランクを介した発信コールの場合、Unified CM は、次の場合にのみ MTP を挿入して、SDP オファーを作成します。

• Unified CM への着信コールがディレイド オファー SIP トランクを介して受信される場合
• Unified CM への着信コールが H.323 Slow Start トランクを介して受信される場合
• 着信コールが Unified CM に登録されている古い SCCP ベースの IP Phone から受信される場合

一般に、MTP を使用するこのタイプのアーリー オファー コールは音声のみをサポートしますが、単一の音声コーデックに制限されていません（必要に応じて MTP を使用したアーリー オファーである場合）。これらのコールは、最初のコール セットアップでのみ音声をサポートしますが、コール メディアが再ネゴシエートされる場合（保留/再開後など）、ビデオおよび SRTP をサポートするためにコール中にエスカレーションできます。

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

図 6-13 音声コールとビデオ コールに対する早期オファー サポート：必須（必要な場合は MTP を挿入)

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

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

（注） Cisco Unified IP Phone 7902、7905、7910、7912、7920、7935、7940、7960 など古い SCCP ベースの IP Phone では、[音声とビデオに対する早期オファーが必須（必要に応じて MTP を挿入）（Early Offer for voice and video Mandatory (insert MTP if needed)）] 機能を有効にして SIP トランクを介したコールを発信するときに、MTP を使用する必要があります。クラスタにこれらの電話機タイプが多数配置されている場合は、[音声とビデオに対する早期オファーが必須（必要に応じて MTP を挿入）（Early Offer for voice and video Mandatory (insert MTP if needed)）] ではなく、ディレイド オファー トランクを配置することを検討してください。[音声とビデオに対する早期オファーが必須（必要に応じて MTP を挿入）（Early Offer for voice and video Mandatory (insert MTP if needed)）] トランクを使用する場合は、このアーリー オファー機能を使用する SIP トランクを介した最繁時のコール数と同等の MTP リソースをクラスタ内にプロビジョニングします。

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

ベスト エフォートのアーリー オファー [音声コールとビデオ コールに対する早期オファーのサポートはベスト エフォート（MTP の挿入なし）（Early Offer support for voice and video calls Best Effort (No MTP inserted)）]

[ベスト エフォートのアーリー オファー（Best Effort Early Offer）] は、SIP トランクに関連付けられた SIP プロファイルで有効にでき、すべての Unified CM および Unified CM Session Management Edition（SME）トランクに対して推奨される設定です。[ベスト エフォートのアーリー オファー（Best Effort Early Offer）] のトランクでは、アーリー オファーを作成するために MTP を使用しません。発信側デバイスに応じて、アーリー オファーかディレイド オファーのいずれかを使用して発信 SIP トランク コールを開始できます。[ベスト エフォートのアーリー オファー（Best Effort Early Offer）] の SIP トランクは、音声コール、ビデオ コール、および暗号化されたコールをサポートしています。

[ベスト エフォートのアーリー オファー（Best Effort Early Offer）] の SIP トランクは、次の状況において、アーリー オファー（SDP コンテンツを含む INVITE）を使用して発信コールを送信します。

• Unified CM または SME への着信コールがアーリー オファーを使用した SIP トランクを介して受信される場合。
• Unified CM または SME への着信コールが Fast Start を使用した H.323 トランクを介して受信される場合。
• Unified CM または SME への着信コールが MGCP トランクを介して受信される場合。
• コールが Unified CM に登録されている SIP ベースの IP 電話から開始される場合。
• コールが Unified CM に登録されている新しいモデルの SCCP ベースの Cisco Unified IP Phone から開始される場合。

[ベスト エフォートのアーリー オファー（Best Effort Early Offer）] のトランクは、次の状況において、ディレイド オファー（SDP コンテンツを含まない INVITE）を使用して発信コールを送信します。

• Unified CM または SME への着信コールがディレイド オファー SIP トランクを介して受信される場合。
• Unified CM または SME への着信コールが H.323 Slow Start トランクを介して受信される場合。
• コールが Unified CM に登録されている古いモデルの SCCP ベースの IP 電話から開始される場合。

図 6-14 ベスト エフォートのアーリー オファー

DTMF 変換用の MTP などのメディア リソース、Trusted Relay Point（TRP; トラステッド リレー ポイント）、およびコーデックの不一致用のトランスコーダは、引き続き [ベスト エフォートのアーリー オファー（Best Effort Early Offer）] のトランクに関連付けてそのトランクで使用できます。[ベスト エフォートのアーリー オファー（Best Effort Early Offer）] を使用すると、アーリー オファーの作成または、受信したオファーに応答したアンサーの作成に MTP が使用されなくなることに注意してください。

企業内のすべての SIP トランクで [ベスト エフォートのアーリー オファー（Best Effort Early Offer）] を使用することで、Cisco Collaboration システムのネットワーク設計と展開が簡略化され、オファーの作成に MTP を使用する必要がなくなります。ただし、Cisco Collaboration のコール制御システム、アプリケーション、およびゲートウェイは、[ベスト エフォートのアーリー オファー（Best Effort Early Offer）] のトランクを介してアーリー オファー コールまたはディレイド オファー コールを受信することができ、また、そのどちらかを受信できる必要があることに注意してください。すべての Cisco Collaboration システム アプリケーションは、アーリー オファー コールまたはディレイド オファー コールの受信をサポートしています。

特定のケース（たとえば、Cisco Unified Border Element Session Border Controller（SBC）を介したサービス プロバイダーの IP PSTN へのコールなど）では、アーリー オファーが常に IP PSTN に送信される必要があります。このような状況では、Cisco Unified Border Element のディレイド オファーからアーリー オファーへの変換機能を使用して、受信したディレイド オファーをアーリー オファーに変換します。

Cisco Collaboration システム アプリケーションがアーリー オファーまたはディレイド オファーのみを受信する必要がある場合は、それぞれアーリー オファー（[音声コールとビデオ コールに対する早期オファー サポートが必須（必要な場合は MTP を挿入）（Early Offer support for voice and video calls Mandatory (insert MTP if needed)）] または [MTP が必須（MTP Required）] を使用）またはディレイド オファーに設定された Unified CM SIP トランクを使用して、このアプリケーションに接続できます。単一の Unified CM クラスタの展開では、これらのトランクの選択は簡単です。Unified CM Session Management Edition 経由で相互接続されているマルチクラスタ展開で、多数のエンド Cisco Collaboration システムへの到達に単一の SIP トランクを共有できる場合は、すべての SME トランクに対して [ベスト エフォートのアーリー オファー（Best Effort Early Offer）] が推奨されます。[ベスト エフォートのアーリー オファー（Best Effort Early Offer）] の設計上の考慮事項については、マルチクラスタ SME 配置の SIP トランクの推奨事項の概要を参照してください。

MTP なしのアーリー オファー、ベスト エフォートのアーリー オファー、および SME メディアの透過性

[MTP なしのアーリー オファー（MTP-Less Early Offer）] は、[ベスト エフォートのアーリー オファー（Best Effort Early Offer）] 機能をサポートしない Unified CM Session Manager Edition（SME）クラスタ バージョンの特別な SIP トランク設定です。[ベスト エフォートのアーリー オファー（Best Effort Early Offer）] では、[MTP なしのアーリー オファー（MTP-Less Early Offer）] と同じ機能が提供されるのに対し、[MTP なしのアーリー オファー（MTP-Less Early Offer）] の展開では、メディア リソースが SME クラスタで設定されていないことが必要です。[ベスト エフォートのアーリー オファー（Best Effort Early Offer）] を使用する場合は、メディア リソースを必要に応じて設定できます。[ベスト エフォートのアーリー オファー（Best Effort Early Offer）] または [MTP なしのアーリー オファー（MTP-Less Early Offer）] の SIP トランクのみを使用した SME 展開の場合、メディアに透過的な SME クラスタを配置することができます（SME クラスタでメディア リソースは不要）。これは、すべてのメディア ネゴシエーションがリーフ Unified Communications システムで行われるためで、メディア リソース（MTP、トランスコーダなど）は必要に応じて挿入されます。（図 6-15 を参照）。

[MTP なしのアーリー オファー（MTP-Less Early Offer）] は、Unified CM SIP サービス パラメータ [MTP 割り当てが失敗した場合 SIP トランク経由のコールが失敗する（Fail Call Over SIP Trunk if MTP Allocation Fails）] を利用します。このサービス パラメータのデフォルト設定は [いいえ（False）] であるので、MTP リソースを使用できない場合は、着信ディレイド オファー コールがディレイド オファー コールとして（アーリー オファーで設定された）発信 SIP トランクを経由することができます。

図 6-15 SME メディアの透過性に対する MTP なしのアーリー オファーの使用

MTP なしのアーリー オファーを使用してメディアに透過的な SME クラスタを設定するには、次の内容を実行します。

• SME クラスタで SIP トランクのみを使用する。
• [音声コールとビデオ コールに対する早期オファー サポートが必須（必要な場合は MTP を挿入）（Early Offer support for voice and video calls Mandatory (insert MTP if needed)）] を使用して、すべてのトランクを有効にする。
• すべての SME ノードの IPVMS サービスを無効にする。これにより、Unified CM メディア ターミネーション ポイント、会議、保留音、およびアナンシエータ リソースが無効になります。
• SME クラスタと Cisco IOS メディア リソースを関連付けしない。
• SIP トランク DTMF 設定を [初期設定なし（No Preference）]（デフォルト設定）に設定する。
• すべての SME SIP トランクで [受信オファーのオーディオ コーデック初期設定を承認（Accept Audio Codec Preference in Received Offer）] をオンにする。

図 6-16 SME メディアの透過性に対するベスト エフォートのアーリー オファーの使用

[ベスト エフォートのアーリー オファー（Best Effort Early Offer）] を使用してメディアに透過的な SME クラスタを設定するには、次の内容を実行します。

• SME クラスタで SIP トランクのみを使用する。
• すべてのトランクで [ベスト エフォートのアーリー オファー（Best Effort Early Offer）] を有効にする。
• SIP トランク DTMF 設定を [初期設定なし（No Preference）]（デフォルト設定）に設定する。
• すべての SME SIP トランクで [受信オファーのオーディオ コーデック初期設定を承認（Accept Audio Codec Preference in Received Offer）] をオンにする。

（注） メディア リソースは、[ベスト エフォートのアーリー オファー（Best Effort Early Offer）] の SIP トランクが設定されている SME クラスタに展開できますが、これらのリソースが使用されるのは、1 つ以上の SIP トランクがディレイド オファーまたはアーリー オファーとして設定されている場合のみです。このような場合、アーリー オファー トランクまたはディレイド オファー トランクに発着するコールは、メディアに透過的ではなく、DTMF またはコーデックの不一致が見つかった場合はメディア リソースを呼び出すことができます。

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

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

• SIP トランク上で SIP アーリー オファーを配信する場合
• DTMF 転送の不一致に対処する場合
• RSVP エージェントとして動作する場合
• 信頼されたリレー ポイント（TRP）として動作する場合
• RTP ストリームに対して IPv4 と IPv6 の変換を提供する場合

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

• Cisco IOS ゲートウェイのソフトウェア MTP：任意の Cisco IOS T-train ソフトウェア リリースで使用できます。また、Route Processor RP2 を搭載した Cisco Aggregation Services Router（ASR）1000 シリーズでは、5,000 セッション（コール）まで拡張できます。
• Cisco IOS ゲートウェイでのハードウェア MTP：任意の Cisco IOS T-train ソフトウェア リリースで使用できます。ハードウェア MTP は、オンボード DSP リソースを使用し、Cisco ルータ プラットフォームでサポートされる DSP の数に従ってコールを拡張します。
• Unified CM サブスクライバ ノードで Cisco IP Voice Media Streaming Application を使用する Cisco Unified CM ソフトウェア MTP。

Cisco IOS MTP は Unified CM MTP で推奨されます。Cisco IOS MTP が追加のコーデック タイプ、複数のメディア ストリーム、およびパススルー コーデックのサポートなど、追加拡張性と優れた機能を提供するためです。（詳細については、メディア ターミネーション ポイント（MTP）の項を参照してください）。

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

SIP トランク上の DTMF トランスポート

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

アウトオブバンド（OOB）SIP DTMF シグナリング方式には、Unsolicited Notify（UN）、Information（INFO）および Key Press Mark-up Language（KPML）が含まれます。KPML（RFC 4730）は、シスコが推奨する OOB シグナリング方式ですが、Cisco Unified CM、Cisco IOS プラットフォーム（リリース 12.4 以降）、および大半の Cisco Unified 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 は 2 つのエンドポイント間で常にメディア パスに存在します。RTP メディア パケットは MTP を透過的に通過しますが、インバンド DTMF パケットは RTP ペイロード タイプによって識別され、Unified CM に抽出され、アウトオブバンド DTMF に変換されます。

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

Unified CM SIP トランクでは、3 つの DTMF オプションを使用できます。

• DTMF Signaling Method：No Preference

このモードでは、Unified CM は、コールに対して最も適切な DTMF シグナリング方式を選択することで、MTP リソースの使用を最小限に抑えようとします。

両方のエンドポイントが RFC 2833 インバンド DTMF をサポートしている場合は、MTP は必要ありません。

両方のデバイスがアウトオブバンド DTMF メカニズムをサポートしている場合、Unified CM は SIP トランク上で KPML を使用します。

両方のデバイスが RFC 2833 インバンド DTMF とアウトオブバンド DTMF の両方をサポートしている場合は、RFC 2833 が優先されます。

MTP が必要となる唯一のケースは、エンドポイントの 1 つがアウトオブバンド DTMF のみをサポートし、もう一方が RFC 2833 インバンド DTMF のみをサポートする場合です。

Cisco Collaboration システムのエンドポイントの大半は、インバンドおよびアウトオブバンドの両方の DTMF をサポートします。

• DTMF Signaling Method：RFC 2833

トランク全体の DTMF シグナリング方式を制限することにより、一方または両方のエンドポイントが RFC 2833 インバンド DTMF をサポートしていない場合に Unified CM は MTP を強制的に割り当てます。この設定では、MTP が割り当てられないのは、両方のエンドポイントが RFC 2833 インバンド DTMF をサポートしている場合だけです。

• DTMF Signaling Method：OOB and RFC 2833

このモードでは、SIP トランクを通じてアウトオブバンド（OOB）DTMF（KPML または Unsolicited NOTIFY）と RFC 2833 インバンド DTMF の両方が送信され使用されます。これは MTP の使用される可能性が最も高いモードです。MTP リソースが必要ないのは、両方のエンドポイントが RFC 2833 インバンド DTMF およびアウトオブバンド DTMF をサポートしている場合だけです。

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

Cisco Unified Border Element は、VoIP ダイヤル ピア上で SIP ベースの DTMF リレー転送方式（RFC 2833（rtp-nte）、Unsolicited Notify（sip-notify）、および KPML（sip-kpml））のいずれかまたはすべてをサポートします。

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

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

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

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

図 6-17 および図 6-18 は、コール セットアップ中にコーデックがコーデック ネゴシエーションにどのように選択されるかを示す例です。

図 6-17 最大オーディオ コーデック ビット レートが 64 kbps のコーデック選択

図 6-18 最大オーディオ コーデック ビット レートが 48 kbps のコーデック選択

SIP クラスタ間トランクでの 2 つの Unified CM クラスタ間のコールでは、オーディオ コーデック プリファレンス リストを使用することで、発信側と着信側デバイスのコーデック プリファレンスに基づいてコールのコーデックを選択することができます。各クラスタ内のデバイスをコーデック プリファレンスに基づいてリージョンにグループ化することで、単一のクラスタ間トランクを、優先コーデックを使用する各コール タイプで複数のコールをサポートするために使用できます。（図 6-19 を参照）。

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

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

（注） コーデック プリファレンスが必要な場合、[MTP が必須（MTP Required）] をオンにしたアーリー オファーに設定された SIP トランクを使用しないでください。このトランク設定は、1 つのオーディオ コーデックだけに限定されている着信コールと発信コールに MTP を挿入するので、コーデック プリファレンスと選択を無効にします。

受信オファーのオーディオ コーデック初期設定を承認

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

図 6-20 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 トランクのみを使用して配置されている場合に使用する必要があります。

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

Unified CM オーディオ コーデック プリファレンス リストは、Cisco Unified Border Element を使用した Unified Communications の導入で使用して、Unified CM と Unified Border Element 間の SIP トランクの設定を簡素化できます。たとえば、音声および FAX コール用に Unified Border Element への専用 SIP トランクを使用する代わりに、単一の Unified CM SIP トランクを使用して、コールが Unified Border Element を通過するときに、デバイス タイプごとのコーデック プリファレンスを考慮できるようになります。

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

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

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

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

SIP Trunk Transport Protocol

SIP トランクは、メッセージ トランスポート プロトコルとして TCP、TLS（TCP を介して実行）、または UDP のいずれかを使用できます。Unified CM は、異なる転送プロトコルを使用して SIP トランクのネイティブ インターワーキング機能を提供します。TCP は、大きな SIP メッセージを分割し、再構成する機能を備えた信頼性の高い接続指向のプロトコルであるため、Cisco Collaboration システム ネットワーク内で使用することを推奨します。UDP は接続指向ではなく、信頼性も高くありません（メッセージの伝送が保証されない）。遠端デバイスの障害の検出と応答は SIP INVITE の再試行回数と SIP Trying タイマーに依存しています。SIP OPTIONS ping を使用して、ダイナミックに各 SIP トランク上の各宛先 IP アドレスの状態、およびトランク全体の総合的な状態を追跡することを推奨します。

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

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

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

安全な SIP トランク

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

• メディアを暗号化するようにトランクを設定する（メディア暗号化を参照）
• シグナリングを暗号化するようにトランクを設定する（シグナリング暗号化を参照）

メディア暗号化

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

シグナリング暗号化

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

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

• 各 Unified CM ノードの SIP トランク デーモンに対して TLS 接続を確立したい各デバイスから、そのノードに対してインポートします。
• 認証局（CA）から署名されます。この場合、リモート デバイスの証明書をインポートする必要はありません。インポートする必要があるのは CA 証明書のみです。

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

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

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

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

https://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 が必須（MTP Required）] チェックボックスを使用して、スタティックに SIP トランクに割り当てられている MTP は、パススルー コーデックをサポートしないため、SRTP をサポートしません。

すべてのコールで SRTP をサポートするには、ディレイド オファーまたは [ベスト エフォートのアーリー オファー（Best Effort Early Offer）] について SIP トランクを設定します。

[音声コールとビデオ コールに対する早期オファーのサポートが必須（必要に応じて MTP を挿入）（Early Offer support for voice and video calls Mandatory (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 を挿入する場合、パススルー コーデック（Cisco IOS MTP）をサポートする MTP で SRTP がサポートされます。

（注） MTP を使用したインバンドからアウトオブバンド DTMF への変換は、SRTP 暗号化メディア ストリームに機能しません。MTP が DTMF パケットを復号化できないからです。

ユーザ ID および SIP トランク

発信側ユーザの名前と番号は、次の SIP メッセージ ヘッダーで Unified CM SIP トランクを介して送信できます。

SIP 要求と応答で送信される From メッセージと From メッセージのヘッダーは、コールの方向を示します。（From ヘッダーが発信側ユーザを表し、To ヘッダーが着信側ユーザを表します）。From ヘッダーおよび To ヘッダーは、コールのすべての SIP 要求と応答で同じ状態のままです。

SIP では、From ヘッダーが匿名で行われることを可能にするので、発信側のユーザ情報が着信側のユーザに表示されません。

P-Asserted-Identity および Remote-Party-ID ヘッダー（ある場合）には、常にユーザの ID が含まれます。これらの ID ヘッダーを持つ SIP メッセージに含まれるユーザ情報は方向性を持つので、ヘッダーは発信側のユーザの ID を初期 INVITE に含み、着信側のユーザの ID を応答に含みます。P-Asserted-Identity および Remote-Party-ID ヘッダーは、匿名コールの ID を追跡するために使用できます。

デフォルトでは、P-Asserted-Identity および Remote-Party-ID ヘッダーの両方は、Unified CM SIP トランクを介して送信されますが、無効にできます。P-Asserted-Identity および Remote-Party-ID ヘッダーの使用は、Unified CM SIP トランクが接続されているデバイスによって異なります。P-Asserted-Identity は、最新の標準で、Remote-Party-ID より広く使用されています。P-Asserted-Identity 標準（RFC 3325）は、信頼できない SIP レルム間の認証をサポートするため、Remote-Party-ID より安全であると見なされます。信頼できないネットワークへの SIP トランク接続の場合、P-Asserted-Identity ヘッダーではなく、P-Preferred-Identity ヘッダーを送信するように Unified CM を設定します。Unified CM は、送信された P-Preferred-Identity ヘッダーのダイジェスト認証チャレンジに応答します。

発信者 ID の表示と表示禁止

上記のように、発信側のユーザ名および番号は、SIP トランクで送信される SIP メッセージの From ヘッダーで匿名にできます。発信者名および番号の表示と表示禁止は、3 つの方法で有効にできます。

• 発信デバイスに関連付けられたトランスレーション パターンの発信者名と番号の表示または表示禁止の設定
• Unified CM トランクへの発信者名と番号の表示または表示禁止の設定
• Unified CM SIP トランクへの P-Asserted-Identity 関連の SIP プライバシー値の設定

これらの発信者 ID の表示と表示禁止の設定オプションは、次の優先順位（プライオリティが高いものを最優先）で実行します。

1. SIP プライバシー値

2. トランクの設定

3. デバイス設定

発呼側番号と着呼側番号の正規化および SIP トランク

パブリック PTSN または IP PTSN と、企業のプライベート ネットワークの間のエッジをコールが通過する際、コール セットアップ メッセージで送信される着信側番号と発信側番号は、+E.164 などのグローバルにルーティング可能な国際フォーマットに可能な限り正規化されている必要があります。これらの番号をどのようにして、どこで正規化するかは、企業が接続されている PSTN ネットワークのタイプに左右されます。

ISDN および Q.931 PSTN ネットワーク

ISDN Q.931 および PSTN ネットワーク内のコールは、着信番号と発信番号を分類するために、コール セットアップ メッセージの番号タイプ フィールドに追加の情報を提供します。番号タイプは、Unknown、Subscriber、National、または International のいずれかです。PSTN から企業ネットワークへのコールの場合、適切な数字を前に付けて、+E.164 値に発信側番号をグローバル化するために、番号タイプのパラメータを企業で使用できます。企業内のグローバル化された PSTN 発信側番号を使用すると、追加の番号操作をほとんど（もしくはまったく）することなく、PSTN の発信者にコールを返すことができます。サービス プロバイダーによって送信される番号形式によっては、企業の着信側番号を企業のダイヤル プランの番号と一致するように変更しなければならない場合もあります。企業内に +E.164 ダイヤル プランを配置することを推奨します。

これらの番号タイプがどのように使用されるかについての詳細および例、そしてダイヤル プランの推奨事項については、ダイヤル プランの章を参照してください。

SIP ベースの IP PSTN ネットワーク

SIP ベースの IP PSTN ネットワークからのコールには、SIP メッセージに番号タイプ情報は含まれません。この場合、IP PSTN サービス プロバイダーは、グローバルにルーティング可能な国際表現（たとえば、+E.164 番号）を使用して PSTN 発信側番号を示す必要があります。サービス プロバイダーによって送信される番号形式に応じて、企業の着信側番号が企業のダイヤル プランの番号と一致するように変更しなければならない場合があります。企業内に +E.164 ダイヤル プランを配置することを推奨します。

サービス プロバイダーが PSTN 発信側番号を +E.164 形式で送信し、着信側番号を、企業のダイヤル プラン（+E.164 を推奨）で使用される番号に一致する形式で送信する場合、企業内でこれらの番号に変更を加える必要はほとんどありません（もしくはまったくありません）。

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

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

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

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

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

Cisco Collaboration システムの配置で SIP トランクのみを使用する理由

1 つ以上の Unified CM クラスタで構成される Cisco Collaboration Systems ネットワークの場合、Unified Communications アプリケーション、セッション ボーダー コントローラ、およびゲートウェイは、SIP を唯一の相互接続トランク プロトコルとして使用して、一般的な機能を十分に備えたシンプルな Collaboration Systems ネットワークを構築できます。

他のトランク プロトコルと比べて、今日の SIP トランクは、次のような多数の独自の機能をサポートします。

• トランクの全体的な動作ステータスおよび各トランクの宛先ノードの状態を追跡する SIP OPTIONS ping。
• コーデック プリファレンス リストおよび SDP オファーで受信されるコーデック プリファレンスを受け入れる機能。
• BFCP ベースのプレゼンテーション共有および遠端カメラ制御を使用した H.264 ビデオのサポート。
• SIP メッセージの正規化および透過性。Unified CM を通過するときに SIP メッセージおよびメッセージ ボディ（SDP）の内容を透過的に転送または変更できる SIP トランクに強力なスクリプトベースの機能を提供します。正規化および透過性のスクリプトは、SIP の相互運用性の問題に対処するように設計されているため、Unified CM は SIP ベースのサードパーティ PBX、アプリケーション、および IP PSTN サービスと相互運用できます。
• IPv4 のみ、IPv6 のみ、またはデュアル スタック（IPv4 および IPv6）ANAT 対応 SIP トランクに対するサポート。

SIP トランクの設計と設定の推奨事項

SIP ベースの Cisco Collaboration システム ネットワークを設計および導入する場合、次の SIP トランク機能を使用することを推奨します。

Unified CM リーフ クラスタおよび SME クラスタに対するベスト エフォートのアーリー オファー

[ベスト エフォートのアーリー オファー（Best Effort Early Offer）] に設定された SIP トランクのみを使用すると、リーフ クラスタでのアーリー オファーの作成に MTP を使用する必要がなくなり、SME クラスタがメディア ネゴシエーションに対して透過的になります。[ベスト エフォートのアーリー オファー（Best Effort Early Offer）] を使用すると、発信側デバイスのオファーを作成するためのメディア機能に関する十分な情報を持っている場合にのみ、SIP トランクはアーリー オファーを送信します。この情報を持っていない場合は、代わりにディレイド オファーを送信します。

[ベスト エフォートのアーリー オファー（Best Effort Early Offer）] の前に、リーフ クラスタ トランクでディレイド オファーまたはアーリー オファーのどちらを使用するかの判断は通常、クラスタに登録されている古い SCCP エンドポイントの数に基づきます。古い SCCP エンドポイントでは、多数の SCCP エンドポイントがクラスタ内に存在する、アーリー オファー SIP トランクを介するコールに対しオファーを作成するには MTP の挿入が必要なため、MTP の使用を避けるためにディレイド オファーが推奨されていました。[ベスト エフォートのアーリー オファー（Best Effort Early Offer）] を使用すると、クラスタに登録されているエンドポイントのタイプに基づいてアーリー オファーまたはディレイド オファーの SIP トランク設定を決定する必要がなくなります。

Cisco Collaboration システムの展開では、Cisco Unified Communications 以外のアプリケーションとサービスで、アーリー オファーのみの受信が必要な場合があります。アーリー オファーを常に受信する要件に対処するオプションが 2 つあります。

• Cisco Unified Border Element では、SIP ディレイド オファーからアーリー オファーへの変換機能を音声コールに対して提供します。着信ディレイド オファーのコールが発信アーリー オファーのコールに変換されるので、Unified CM および SME で、[ベスト エフォートのアーリー オファー（Best Effort Early Offer）] のトランクを使用できるようになります。この使用例で代表的と言えるのは、通常は SIP アーリー オファーを常に受信する必要があるサービス プロバイダーの IP PSTN 接続です。
• SIP アーリー オファーのみを受け入れる企業の Unified Communications アプリケーションの場合、専用のアーリー オファー SIP トランクを Unified CM リーフ クラスタから Unified Communications アプリケーションに使用できます。多数の MTP がアーリー オファー SIP トランクで必要な場合は、Cisco Unified Border Element のディレイド オファーからアーリー オファーへの変換機能を使用することを検討してください。

SME クラスタでは、[ベスト エフォートのアーリー オファー（Best Effort Early Offer）] は SME クラスタをメディア ネゴシエーションに透過的にすることで [MTP なしのアーリー オファー（MTP-Less Early Offer）] と同じ役割を果たします。次にメディアの決定を末端の Unified Communications システムで行われるように強制します。このシステムでは、必要に応じて、DTMF またはコーデックの不一致問題に対処するためにメディア リソースを挿入できます。メディア リソースは、MTP なしのアーリー オファー SME トランクに関連付けないでください。必要に応じて、メディア リソースを [ベスト エフォートのアーリー オファー（Best Effort Early Offer）] のトランクに関連付けることができます。

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

この機能は、SIP トランクおよびルート リストでサポートされ、Unified CM および SME クラスタから、そして Unified CM および SME クラスタを介してコール ルーティングを大幅に簡素化します。すべての SIP トランクおよびルート リストで、[すべての Unified CM ノードで実行（Run on all Active Unified CM Nodes）] 機能をオンにすることを強く推奨します。コール ルーティングは、[すべての Unified CM ノードで実行（Run on all Unified CM nodes）] とルート ローカル機能の組み合わせで簡略化されます。ここでは、SIP トランクを介した電話は、電話機が登録されている Unified CM ノードから常に発信されます。トランク間のコールと同様に、発信 SIP トランク コールは、着信トランク コールが到達した Unified CM ノードから常に発信されます。すべての SIP トランクおよびルート リストに対して [すべての Unified CM ノードで実行（Run on all Unified CM nodes）] をオンにすると、クラスタ内のコール処理ノード間でコールをセットアップする必要がなくなります。これは、WAN を介したクラスタリングが Unified CM または SME クラスタで配置されるときに実用的です。

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

SIP トランクは、最大 16 の宛先 IP アドレス、16 の完全修飾ドメイン名、または単一の DNS SRV エントリを使用して設定できます。追加の宛先 IP アドレスをサポートしているため、2 つの Unified Communications システム間のコール分配のために、ルート リストおよびルート グループに関連付けられた複数のトランクを作成する必要性が軽減されます。結果として、Unified CM トランク設計が単純になりますIP アドレスが SIP トランクで宛先として使用される場合、Unified CM は定義されたすべての宛先 IP アドレス間でコールをランダムに配信します。

SIP OPTIONS ping

SIP トランクに関連付けられた SIP プロファイルで SIP OPTIONS ping 機能を有効にして、トランクの宛先の状態およびトランクの全体の状態をダイナミックに追跡できます。

PRACK

PRACK は、PSTN との相互運用シナリオに 1XX 応答の信頼性を提供します。また、双方向メディアを設定する前に交換する必要がある SIP メッセージ数を減らすのに使用することもできます。トランクに関連付けられた SIP プロファイルで [SIP Rel1XX オプション（SIP Rel1XX Options）] パラメータを介して PRACK を有効にします。

SIP トランクの DTMF シグナリング方式：初期設定なし

[DTMF シグナリング方式：初期設定なし（DTMF Signaling Method: No Preference）] の使用は、SIP トランクでは推奨されません。このモードでは、Unified CM は、コールに対して最も適切な DTMF シグナリング方式（インバンドまたはアウトオブバンド）を選択することで、MTP リソースの使用を最小限に抑えようとします。

Unified CM Session Management Edition を配置する状況

次のいずれかの操作を行う場合は、Unified CM Session Management Edition を配置することを推奨します。

• 集中型ダイヤル プランの作成および管理

他のすべてのユニファイド コミュニケーション システムに接続するために各ユニファイド コミュニケーション システムに別個のダイヤル プランおよびトランクを設定するのではなく、Unified CM Session Management Edition を使用すると、SME クラスタを指す簡潔なダイヤル プランおよびトランクをリーフのユニファイド コミュニケーション システムに設定できます。Unified CM Session Management Edition には、集中型ダイヤル プランと、他のすべてのユニファイド コミュニケーション システムに到達するためのこのプランに対応する情報が含まれています。

（注） SME および Unified CM リーフ クラスタで ILS GDPR を実行すると、ダイヤル プランの管理をさらに簡略化できます。これは、個々のディレクトリ番号、DN に対応する E.164 番号、ルート パターン（たとえば、内線番号範囲および外線番号範囲）、および URI は、ILS サービスを使用して配信できるためです。このアプローチでは、必要なルート パターンの数を減らし、それぞれ一意の番号範囲のルート パターンではなく、呼制御システム（Unified CM クラスタなど）ごとに 1 つの SIP ルート パターンにすることで、ダイヤル プランの管理を簡略化します。ILS および GDPR の詳細については、クラスタ間検索サービス（ILS）および Global Dial Plan Replication（GDPR）を参照してください。

• 集中型 PSTN アクセスの提供

Unified CM Session Management Edition を使用すると、1 つ（または複数）の集中型 PSTN トランクに PSTN アクセスを集約できます。集中型 PSTN アクセスには一般に、ブランチベースの PSTN 回線の削減または排除を伴います。

• アプリケーションの集中化

Unified CM Session Management Edition の導入によって、会議やボイス メールなどの一般に使用されるアプリケーションを直接 SME クラスタに接続できるため、複数のトランクの管理によるリーフ システムへのオーバーヘッドが軽減されます。

• Unified Communications システムに移行するために PBX を集約

Unified CM Session Management Edition は、レガシー PBX から Cisco Unified Communications システムへの移行の一環として、複数の PBX の集約ポイントを提供できます。ILS GDPR を導入する場合、各サードパーティ製システムでサポートされている番号範囲や URI を ILS GDPR にインポートし、SIP ルート パターンおよび対応する SIP トランクを介して到達できるようにすることもできます。

Unified CM Session Management Edition と標準の Unified CM クラスタの相違

Unified CM Session Management Edition ソフトウェアは、Unified CM と同じです。ただし、Unified CM ソフトウェアは、この新しい導入モデルの要件を満たすために強化されています。Unified CM Session Management Edition は、多数のトランクツートランク接続をサポートするように設計されているため、次に示す設計上の考慮事項に従う必要があります。

容量とサイジング

Unified CM Session Management クラスタは、リーフ Unified Communications システム間（たとえば、Unified CM クラスタと PBX 間）、集中型 PSTN 接続間、および集中型アプリケーションへの予想される BHCA トラフィック ロードに基づいて正確にサイジングすることが重要です。使用している Unified Communications システムでのユーザの平均的な BHCA およびコール保留時間を判断し、その情報をシスコ アカウント システム エンジニア（SE）またはシスコ代理店と共有して、Unified CM Session Management Edition クラスタの規模を適切に決定してください。SME サイジングの詳細については、コラボレーション ソリューション サイジング ガイダンスの章を参照してください。

SME トランク

SME は SIP、H.323、および MGCP トランクをサポートしますが、Cisco Unified Communications System Release 8.5 およびそれ以降のバージョンを実行する SME および Unified CM リーフ クラスタのトランク プロトコルとして SIP を使用することを推奨します。

SME クラスタで SIP トランクのみを使用すると、「メディア トランスペアレント」クラスタを展開できます。ここでは必要に応じて、メディア リソースが SME ではなく、エンドまたはリーフ Unified Communications システムによって挿入されます。WAN を介してクラスタリングする場合、SIP トランクのみを使用すると、SME ノード間で拡張ラウンド トリップ時間（RTT）を使用できるようにもなります。

SME SIP トランクは、[ベスト エフォートのアーリー オファー（Best Effort Early Offer）] トランクとして設定する必要があります。リーフ Unified CM クラスタ SIP トランクもまた、[ベスト エフォートのアーリー オファー（Best Effort Early Offer）] として設定する必要があります。

メディア ネゴシエーション用の SME の透過性

MTP またはトランスコーダなどのメディア リソースは、コールが正常に続行するために必要で、これらのリソースがエッジまたはリーフ Unified Communications システムで割り当てられる必要があります。SME トランク メディア リソースが SME クラスタを通過するコールに使用される場合、メディア パス コールが SME メディア リソースを介してヘアピンします。SIP トランクのみ、そして [ベスト エフォートのアーリー オファー（Best Effort Early Offer）]（または [MTP なしのアーリー オファー（MTP-Less Early Offer）]）を使用して、メディア リソースを使用せずに、SME クラスタを配置できます。メディア リソースが必要な場合は、リーフ Unified Communications システムで提供することができます。

SME CoW+ による WAN を介したクラスタリング

Cisco Unified CM 9.1 およびそれ以降のリリースでは、SME の配置では、SME クラスタ ノード間で最大 500 ミリ秒のラウンドトリップ時間（RTT）をサポートします。（図 6-23 を参照）。この拡張 RTT は SME クラスタのみに適用され（標準の Unified CM クラスタ設計の最長 RTT は 80 ミリ秒です）に適用され、次の設計上の制限があります。

• WAN（CoW+）を介したクラスタリングの拡張ラウンドトリップ時間使用した SME の配置は、SIP トランクだけでサポートされます。すべての SIP トランクは、コールが SME クラスタ内のノード間でルーティングされないように、すべて [ベスト エフォートのアーリー オファー（Best Effort Early Offer）]（推奨）またはすべて [MTP なしのアーリー オファー（MTP-Less Early Offer）] として設定され、[すべての Unified CM ノードで実行（Run on all Unified CM Nodes）] 機能を使用する必要があります。H.323、MGCP、および SCCP プロトコルは、WAN のラウンドトリップ時間を介した拡張クラスタリングの SME 配置ではサポートされていません。
• エンドポイントまたは CTI デバイスは SME クラスタに設定、または登録されません。
• MTP、信頼されたリレー ポイント（TRP）、RSVP エージェント、トランスコーダなどのメディア リソースは、SME クラスタに設定または登録されません。（Unified CM ノードでホストされているメディア リソースを無効にするには、クラスタ内の各ノードの IPVMS サービスを非アクティブにします）。
• サイト間の Intra-Cluster Communication Signaling（ICCS）トラフィックに最低 1.544 Mbps（T1）の帯域幅が必要です。
• Intra-Cluster Communication Signaling（ICCS）トラフィックに必要な帯域幅に加え、パブリッシャ ノードとあらゆるリモート サブスクライバ ノード間のデータベースおよびその他のサーバ間トラフィック用に、最低でも 1.544 Mbps（T1）の帯域幅が必要になります。

（注） すべての SME 設計を使用して、SME 設計は、配置前にシスコの SME チームによる確認と承認が必要になります。

SME クラスタのアップグレード プロセスは、2 つの主要な部分で構成されています。

• バージョンのスイッチングオーバー：コール処理ノードが新しいソフトウェア バージョンで再起動され、初期化されます（サーバあたり約 45 分かかります）。
• データベース複製：サブスクライバのデータベースは、パブリッシャ ノードのデータベースと同期化されます。

このデータベース複製フェーズを完了するのにかかる時間は、クラスタ内のサブスクライバ ノードの数とパブリッシャおよびサブスクライバ ノード間の RTT によって異なります。データベース複製プロセスにはサブスクライバの呼処理機能への影響はほとんどなく、通常の SME クラスタ処理中にバックグラウンド処理として実行できます。データベース複製フェーズ中に SME クラスタ設定に変更を加えないようにしてください。これにより、複製が完了するまでの時間が遅くなります。

拡張 RTT を使用して SME クラスタを配置する場合、クラスタをアップグレードする前に、パブリッシャ ノードで次の管理者レベル CLI コマンドを実行します。

utils dbreplication setprocess 40

このコマンドは、複製設定のパフォーマンスを向上させ、データベース複製に要する時間が短縮されます。

図 6-23 Unified CM Session Management Edition：拡張ラウンド トリップ時間を使用した WAN を介したクラスタリング

Unified CM バージョン

最新の Cisco Collaboration システムのリリースと SIP トランクを、すべての Unified CM リーフ クラスタと SME クラスタで使用すると、コーデックのプリファレンス リスト、ILS、GDPR、および Enhanced Locations Call Admission Control（CAC）といった一般的なクラスタ間機能のメリットを導入環境で享受できるようになります。最新の Unified CM バージョンへのアップグレードをすべてのクラスタ上で行いたくない場合、最小推奨バージョンは SIP トランクを使用する Cisco Unified CM 8.5 となります。これは、Unified CM および Session Management Edition クラスタを介したコール ルーティングを改善し、簡略化する機能がこのバージョンに含まれているためです。

Session Management Edition での Unified Communications アプリケーションの一元化に関するガイダンス

Session Management Edition クラスタへの Unified Communications（UC）アプリケーションの同時配置と接続では、各リーフ UC システムに関連付けられた複数のインスタンスではなく、1 つの集中型アプリケーション インスタンスを使用することで、規模を節約して、管理上のオーバーヘッドを縮小できます。ここでは、Session Management Edition クラスタと同時配置できる UC アプリケーションの設計ガイドラインの一部について説明します。

一般的なルールとして、コールを確立するために番号に基づいたコール ルーティングのみに依存するアプリケーションは、Unified CM Session Management Edition に接続できます。デバイス状態を追跡するために追加のインターフェイス（CTI など）を必要とするアプリケーション（たとえば、ユニファイド コンタクト センターやリーフ クラスタ）は、リーフ クラスタに接続する必要があります。（図 6-24 を参照）。

図 6-24 集中型 UC アプリケーションと Session Management Edition

集中型ボイス メール：Unity Connection

Cisco Unity Connection などのボイスメール アプリケーションは、SME クラスタに接続し、すべてのリーフ UC システム上のユーザにボイスメール サービスを提供できます。

リーフ クラスタと SME 間のクラスタ間トランク、およびボイスメール アプリケーションとのトランク接続では、ボイスメールにルーティングされるコールとともに、元の着信側/リダイレクト番号が送信されることを確認してください。

QSIG 非対応トランクの場合、元の着信側またはリダイレクト番号の転送は以下の方法で有効にできます。

• MGCP ゲートウェイ、H.323 ゲートウェイ、および H.323 トランクで着信および発信の [番号 IE 配信のリダイレクト（Redirecting Number IE Delivery）] を有効にします
• SIP トランクで着信および発信の [Diversion ヘッダー配信のリダイレクト（Redirecting Diversion Header Delivery）] を有効にします。

QSIG 対応 SIP、MGCP および H323 トランクの場合、元の着信側番号は、QSIG 転送元レッグ情報 APDU で送信されます。QSIG 対応トランクを介して QSIG APDU で送信される転送情報は、発信側の変更をピックアップせず、ボイス メール ボックスのマスク設定にも対応しません。Unified CM により送信された QSIG 転送情報は、変換の適用なしでリダイレクト元の DN に常に送信されます。

リダイレクト元 DN が +E.164 として設定されている場合は、先頭の「+」が削除され、QSIG 転送情報は「+」文字を含まない E.164 番号のみを保持します。

すべての QSIG トランク タイプの考慮事項

UC ネットワークでの QSIG の使用は、得られる機能のメリットが少ないため、通常は推奨されていません。QSIG を使用する主な理由は、コールバック機能を提供することです。（代替として、Collaboration ユーザは、Cisco IM and Presence サービスによって提供されるプレゼンス情報を使用して、他のユーザの状態を追跡できます）。リーフ UC システムから SME へのトランクで QSIG を有効にする場合は、すべてのクラスタ間トランクでも QSIG を有効にする必要があります。これによって、電話ユーザがコール バックが一部の（QSIG 対応の）着信側ユーザには機能しているがその他のユーザには機能していないことに気づくといった、低品質のエンド ユーザ エクスペリエンスが回避されます。

QSIG トンネリングが有効になっている H.323、MGCP、および SIP トランクでは、発信側、着信側、およびリダイレクト元の番号情報を含むすべての番号情報が、外部の H.323 メッセージや SIP ヘッダーからではなく、常にカプセル化された QSIG メッセージから取得されます。この QSIG トランクの動作には、SME に集中化され、複数のリーフ システムにサービス提供するボイスメール システムに特別な設計上の考慮が必要となる場合があります。

一般的な推奨事項として、円滑なエンドツーエンドの QSIG 実装を可能にするためには、すべての UC システムにわたって統一された、グローバルに一意なダイヤル プランが実装される必要があります。

QSIG トランクが使用されている場合、集中型ボイスメール システムに送信される前にリダイレクト番号を正規化することはできません。この制限により、各リーフ UC システムのユーザ用の集中型ボイスメール システム メールボックス番号は、各リーフ システムで使用される電話番号の番号形式に対応している必要があります。次に例を示します。

• E.164 形式の電話番号を持つユーザには、同じ E.164 形式を使用した、対応するボイスメール システム メールボックス番号を設定する必要があります。
• +E164 形式の電話番号を持つユーザには、同じ E.164 形式を使用した、対応するボイスメール システム メールボックス番号と、+E.164 形式を使用した代替のボイス メールボックス番号を設定する必要があります。

TelePresence Server および TelePresence Conductor

会議システムは、Session Management Edition クラスタに接続できます。Cisco TelePresence Conductor および TelePresence Server を使用した導入では、SIP トランクのシグナリング接続を超える追加のシグナリング接続がインスタント会議に必要なことに留意してください。会議リソースに到達するためにルート パターンと SIP トランクを使用する相手先固定会議とは異なり、Unified CM は、インスタンス会議をメディア リソースとして定義し、HTTP/HTTPS 経由の XML RPC を使用して、電話ユーザが「会議」ボタンを押したときにインスタント会議を作成するように TelePresence Conductor または TelePresence Server に指示します。インスタント会議では、HTTP/HTTPS XML RPC メッセージおよび SIP INVITE メッセージは、同じ送信元 IP アドレスから発信される必要があるので、インスタント会議接続（HTTP XML RPC および SIP トランク）は、SME クラスタではなくリーフ Unified CM クラスタで設定する必要があります。TelePresence Conductor および TelePresence Server は、SME と引き続き同じ場所に配置できますが、相手先固定会議のみが SME クラスタから直接接続された SIP トランク接続を使用でき、インスタント会議 SIP トランクおよび HTTP XML RPC 接続は、リーフ Unified CM クラスタから直接接続される必要があります。（図 6-25 を参照）。

詳細については、次の URL から入手できる最新バージョンの『 Cisco TelePresence Conductor with Unified CM Deployment Guide 』を参照してください。

https://www.cisco.com/c/en/us/support/conferencing/telepresence-conductor/products-installation-and-configuration-guides-list.html

図 6-25 集中型 TelePresence Server および TelePresence Conductor

Expressway-C および Expressway-E

Cisco Expressway プラットフォームは、Session Management Edition クラスタに接続できます（図 6-26 を参照）。導入タイプによって、Expressway-C は SME への接続に SIP トランクを使用できる場合とできない場合があります。

• モバイル & リモート アクセス

企業の UC ネットワークへの接続にモバイルおよびリモート アクセス機能を使用しているデバイスは、SME クラスタへの SIP 接続を確立しません。そのデバイスは、UDS を使用して、ホーム クラスタを検出して直接登録します。UDS ホーム クラスタ ルックアップ要求の受信に SME が使用されている場合は、ホーム クラスタの検出のために他の Unified CM クラスタと通信するために ILS サービスを使用する必要もあります。詳細については、次の URL から入手できる最新バージョンの『 Mobile and Remote Access via Cisco Expressway Deployment Guide 』を参照してください。

https://www.cisco.com/c/en/us/support/unified-communications/expressway-series/products-installation-and-configuration-guides-list.html

• トランキングされた Expressway アプリケーション

Business-to-Business（B2B）Collaboration などの Expressway アプリケーションの場合、Expressway は SME クラスタへの直接 SIP トランク接続を使用します。

図 6-26 集中型 Expressway-C と Expressway-E

マルチクラスタ SME 配置の SIP トランクの推奨事項の概要

ここでは、SIP トランクの推奨事項、および Unified CM Session Management Edition を使用したマルチ クラスタ配置の動作に関する概要を示します。

Unified CM リーフ クラスタの推奨事項：

• 各地域データセンターの SME ノードのセットごとに 1 つの SIP トランクを設定する。たとえば、4 つの地域 SME データセンターがある場合、各リーフ クラスタに 4 つの SIP トランクを作成します（図 6-27 を参照）。これにより、すべての SME ノードからのコールがリーフ クラスタによって受信され、受け入れられるようになります。これらのすべてのトランクで [すべての Unified CM ノードで実行（Run on all Unified CM nodes）] をオンにします。
• SME CoW+ クラスタへのパスの冗長性のために、ルート リストおよびルート グループにこのようなリーフ クラスタの SIP トランクを 2 つ以上置く。
• [ベスト エフォートのアーリー オファー（Best Effort Early Offer）] がすべてのリーフ クラスタ SIP トランクに推奨されます。

Unified Communications の展開では、Cisco Unified Communications 以外のアプリケーションとサービスで、アーリー オファーのみの受信が必要な場合があります。リーフ クラスタの場合は、アーリー オファーが常に受信される要件に対応するオプションが 2 つあります。

– Cisco Unified Border Element では、SIP ディレイド オファーからアーリー オファーへの変換機能を音声コールに対して提供します。着信ディレイド オファーのコールが発信アーリー オファーのコールに変換されるので、Unified CM および SME で、[ベスト エフォートのアーリー オファー（Best Effort Early Offer）] のトランクを使用できるようになります。この使用例で代表的と言えるのは、通常は SIP アーリー オファーを常に受信する必要がある、Cisco Unified Border Element 経由のサービス プロバイダーの IP PSTN 接続の場合です。

– SIP アーリー オファーのみを受け入れる企業の Unified Communications アプリケーションの場合、専用のアーリー オファー SIP トランクを Unified CM リーフ クラスタから Unified Communications アプリケーションに使用できます。多数の MTP がアーリー オファー SIP トランクで必要な場合は、Cisco Unified Border Element のディレイド オファーからアーリー オファーへの変換機能を代わりに使用することを検討してください。

• すべてのリーフ クラスタ ノードで IPVMS サービスを有効にする。必要に応じて、会議、保留音、およびアナンシエータ リソースをアクティブにします。（IPVMS ベースの MTP を非アクティブにすることが推奨されます）。
• 必要に応じて、リーフ クラスタに Cisco IOS メディア リソース（MTP、会議、およびトランスコーディング）を設定して、関連付ける。
• SIP トランク DTMF 設定を [初期設定なし（No Preference）]（デフォルト設定）に設定する。
• SIP OPTIONS ping および PRACK を有効にする。
• 必要に応じて、コーデックのプリファレンス リストを設定し、適用する。

図 6-27 CoW リーフ クラスタ トランクに対する推奨トランク設定

Session Management Edition クラスタの推奨事項：

• SME クラスタで SIP トランクのみを使用する。
• SME クラスタから各リーフ クラスタに 1 つの SIP トランクを設定する（図 6-28 を参照）。これらのトランクで [すべての Unified CM ノードで実行（Run on all Unified CM Nodes）] をオンにし、リーフ クラスタ内のすべてのコール処理ノードにトランク宛先を設定する。
• [ベスト エフォートのアーリー オファー（Best Effort Early Offer）] がすべての SME クラスタ SIP トランクに推奨されます。

アーリー オファーのみの受信が SME クラスタに接続されている Cisco Unified Communications 以外のアプリケーションとサービスで必要な場合、この要件に対応するオプションが 2 つあります。

– Cisco Unified Border Element では、SIP ディレイド オファーからアーリー オファーへの変換機能を音声コールに対して提供します。着信ディレイド オファーのコールが発信アーリー オファーのコールに変換されるので、Unified CM および SME で、[ベスト エフォートのアーリー オファー（Best Effort Early Offer）] のトランクのみを使用できるようになります。この使用例で代表的と言えるのは、通常は SIP アーリー オファーを常に受信する必要がある、Cisco Unified Border Element 経由のサービス プロバイダーの IP PSTN 接続の場合です。

– SIP アーリー オファーのみを受け入れる企業の Unified Communications アプリケーションで、専用のアーリー オファー SIP トランクが SME クラスタから Unified Communications アプリケーションに使用されている場合、メディア リソースは SME トランクに関連付けられる必要があり、それが使用されると、不要なメディアのヘアピニングの原因となります。通常このケースで使用されるメディア リソースは、アーリー オファーの作成または DTMF 不一致に対応するための MTP、またはコーデックの不一致に対応するためのトランスコーダです。SME クラスタでメディア リソースを使用することは一般に推奨されません。代わりに、SME と Unified Communications アプリケーション間で Cisco Unified Border Element のディレイド オファーからアーリー オファーへの機能を使用することを検討するか、またはリーフ クラスタからアプリケーションへの直接トランクを使用します。

• すべての SME ノードの IPVMS サービスを無効にする。これにより、Unified CM メディア ターミネーション ポイント、会議、保留音、およびアナンシエータ リソースが無効になります。
• SME クラスタと Cisco IOS メディア リソースを関連付けしない。
• SIP トランク DTMF 設定を [初期設定なし（No Preference）]（デフォルト設定）に設定する。
• すべての SME SIP トランクで [受信オファーのオーディオ コーデック初期設定を承認（Accept Audio Codec Preference in Received Offer）] をオンにする。
• SIP OPTIONS ping および PRACK を有効にする。

図 6-28 CoW+ SME クラスタ トランクに対する推奨トランク設定

リーフおよび SME クラスタを介したコール ルーティングの推奨事項：

発信リーフ クラスタは、発信デバイスが登録されている同じノードから SIP トランク コールを発信します（ルート ローカル ルールを使用）。リーフ クラスタは、SIP トランクのルート リストから宛先アドレスをランダムに選択します。（図 6-29 の例では、第一希望のトランクが選択されます）。

SME クラスタからの発信コールは、着信コールが到達した同じノードから発信されます（ルート ローカル ルールを使用）。すべての SME トランク上で [すべての Unified CM ノードで実行（Run on all Unified CM nodes）] がオンにされている場合、SME クラスタ内のコール処理ノード間でコールがセットアップされることはありません。SME クラスタは、宛先リーフ クラスタを指す SIP トランクの宛先アドレスをランダムに選択します。

宛先リーフ クラスタへの着信 SIP トランク コールの場合、着信コールが到達したコール処理ノードから、着信側デバイスが登録されているノードに、コールが拡張される場合があります。

必要に応じて、メディア リソースは、リーフ クラスタ（またはエンド Unified Communications システム）によって挿入されます。発信側リーフ クラスタの SIP トランクのデバイスがディレイド オファーを使用する場合、メディアの決定は、このクラスタによって行われます。必要に応じて、メディア リソース（MTP およびトランスコーダ、またはどちらか一方）を挿入します。発信側リーフ クラスタの SIP トランクのデバイスがアーリー オファーを送信する場合、メディアの決定は、宛先リーフ クラスタによって行われます。必要に応じて、メディア リソース（MTP およびトランスコーダ、またはどちらか一方）を挿入します。

図 6-29 リーフおよび SME クラスタを介したコール ルーティングで推奨されるトランクの設定

SIP トランクの正規化

正規化によって、Unified CM を通過するときに着信および発信 SIP メッセージを変更できます。たとえば、Unified CM では、リダイレクト番号情報を伝達するための Diversion ヘッダーがサポートされます。Unified CM に接続される一部の SIP デバイスでは、この目的で History-Info ヘッダーが使用されます。着信の正規化スクリプトは、Cisco Unified CM でリダイレクト情報が認識されるように、History-Info ヘッダーを Diversion ヘッダーに変換するために使用できます。同様に、発信の正規化スクリプトは、外部 SIP デバイスでリダイレクト情報が認識されるように、Diversion ヘッダーを History-Info ヘッダーに変換するために使用できます。

正規化スクリプトは、SIP トランクまたは SIP 回線に関連付けられています。スクリプトは、発着信 SIP メッセージで動作するメッセージ ハンドラのセットとして示されます。正規化では、スクリプトによって、次のものを含む SIP メッセージのほとんどの状態が操作されます。

• 要求 URI
• 応答コードとフレーズ
• SIP ヘッダー
• SIP パラメータ
• コンテンツ本文
• SDP

正規化は、コールに関係する他のエンドポイントで使用されるプロトコルに関係なく、スクリプトが関連付けられた SIP トランクを通過するすべてのコールに適用されます。たとえば、SIP トランクの正規化スクリプトは、SIP ライン デバイスから SIP トランクに対するコール、SCCP デバイスから SIP トランクに対するコール、MGCP トランクから SIP トランクに対するコール、H.323 トランクから SIP トランクに対するコールなどで実行できます（図 6-31 を参照）。

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

SIP トランクの透過性

通過するメッセージの部分を Unified CM が理解またはサポートしていない場合でも、透過性 Lua スクリプトによって、Unified CM は SIP ヘッダー、パラメータ、メッセージ ボディの内容を SIP トランク コール レッグから別の宛先に渡すことができます。透過性（または透過的なパススルー）は、Unified CM を介した SIP 間のコールでのみ適用されます。（図 6-32 を参照）。

透過性スクリプトは、SIP トランクまたは SIP 回線に関連付けられています。スクリプトは、発着信 SIP メッセージで動作するメッセージ ハンドラのセットとして示されます。透過性では、スクリプトによって、次のものを含む SIP メッセージのほとんどの情報が渡されます。

• SIP ヘッダー
• SIP パラメータ
• コンテンツ本文

SIP プロファイルは、SDP 透過性プロファイルもサポートしています。そのプロファイルは、すべての不明な SDP パラメータ（デフォルト）または Unified CM によってネイティブでサポートされていない選択された SDP パラメータを 1 つの SIP トランク（または SIP エンドポイント）から別のトランクに Lua 透過性スクリプトを使用せずに渡すために使用できます。

図 6-32 SIP トランクの透過性

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

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

https://www.cisco.com/en/US/products/sw/voicesw/ps556/products_programming_reference_guides_list.html

この開発者ガイドでは、SIP メッセージ情報を操作し、渡すために使用される、スクリプト環境および API について説明します。

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

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

プリロードされた Unified CM 正規化および透過性スクリプト

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

• Refer-passthrough スクリプト：このスクリプトを使用して、ブラインド転送（ダイアログ内参照使用）が 2 つの SIP トランク間で呼び出されたときに、Unified CM をコール シグナリング パスから削除できます。
• ContactHeader スクリプト：このスクリプトは、着信ディレイド オファーの通話中再参加内の Contact ヘッダーから音声とビデオの属性を削除します。
• HCS PCV PAI パススルー スクリプト：このスクリプトは、IP Multimedia Subsystem（IMS）ネットワークとの統合で使用され、INVITE、UPDATE、および 200 OK メッセージの P-Charging-Vector ヘッダーをパススルーまたは追加します。
• Diversion-Counter スクリプト：このスクリプトは、さまざまなコール転送シナリオ用に転送カウンタを調整する機能を提供します。
• VCS-interop スクリプト：このスクリプトは、Cisco TelePresence Video Communication Server（VCS）に登録されたエンドポイントの相互運用性を提供します。