Cisco Collaboration システム 10.x ソリューション リファレンス ネットワーク デザイン(SRND)
Cisco Unified CM トランク
Cisco Unified CM トランク
発行日;2014/04/25 | 英語版ドキュメント(2013/11/23 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 27MB) | フィードバック

目次

Cisco Unified CM トランク

この章の新規情報

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

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

SIP トランクの概要

Session Initiation Protocol(SIP)の操作

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

SIP ディレイド オファー

SIP アーリー オファー

Provisional Reliable Acknowledgement(PRACK)

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

Session Description Protocol(SDP)および音声コール

Session Description Protocol(SDP)およびビデオ コール

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

遠端カメラ制御(FECC)

UnifiedCM の SIP トランクの機能と操作

すべての UnifiedCM ノードで実行

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

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

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

DNS を使用する SIP トランク

SIP OPTIONS ping

UnifiedCM SIP トランク:ディレイド オファーおよびアーリー オファー

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

Unified CM SIP アーリー オファー

MTP-Less アーリー オファー

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

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

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

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

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

SIP トランク トランスポート プロトコル

安全な SIP トランク

メディア暗号化

シグナリング暗号化

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

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

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

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

SIP トランクを使用する際の設計と設定の推奨事項

UnifiedCM Session Management Edition

UnifiedCM Session Management Edition を導入すべき状況

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

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

UnifiedCM SIP トランクのマイナー機能

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

SIP トランクの正規化

SIP トランクの透過性

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

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

Cisco Unified Border Element

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

IP PSTN トランクと緊急サービス

Cisco Unified CM トランク

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

トランクは、Cisco Collaboration システムの導入における重要かつ不可欠な部分であるため、利用可能なトランクの種類、それらの機能に加え、障害復旧力、容量、ロード バランシングといった設計および導入時に考慮すべき事項について理解することが重要となります。

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

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

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

H.323 トランクは引き続きサポートされていますが、SIP トランクが Unified Communications の導入で推奨されるトランク タイプになります。これは、SIP トランクが H.323 トランクでは使用できない追加の機能を提供するためです。この章では、H.323 と SIP トランク機能の比較の概要を示しますが、重点は置くのは SIP トランクであり、その操作と、Unified Communications 導入向けの機能を説明します。H.323 トランクの機能と操作の詳細については、次の Web サイトで入手可能な『 Cisco Collaboration 9.x SRND 』の「 Cisco Unified CM Trunks 」の章を参照してください。

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/collab09/trunks.html

Unified CM トランクのアプリケーションの詳細については、このマニュアルの次の章の各項を参照してください。

「コラボレーションの配置モデル」

「メディア リソース」

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

「Cisco IM and Presence」

この章の新規情報


) この章は、現在のリリースに向けて大幅に改訂されました。Collaboration と Unified Communications システムにトランクを導入する前に、この章全体を読むことを推奨します。


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

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

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

MTP-Less SIP アーリー オファー

「MTP-Less アーリー オファー」

2013 年 11 月 19 日

この章から H.323 トランク情報が削除され、SIP トランクおよび操作や機能を重点的に取り扱うためにこの章が書き換えられています。

H.3213 トランクの詳細については、次の Web サイトで入手可能な『 Cisco Collaboration 9.x SRND 』の「 Cisco Unified CM Trunks 」の章を参照してください。

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

2013 年 11 月 19 日

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

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

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

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

 

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

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

Cisco Unified CM トランク接続は、SIP と H.323 の両方のトランクをサポートしています。SIP または H.323 のどちらを使用するかの決定は、それぞれのプロトコルで提供される固有な機能に大きく影響されます。Unified Communications ベンダーおよびお客様の両方の間で SIP の人気が拡大するにつれ、SIP トランクがサポートする機能も拡大して H.323 トランクよりも豊富な機能セットを提供できるようになり、Unified Communications の導入で推奨されるようになりました。現在多くのお客様が、H.323 トランクおよびゲートキーパーベースの Unified Communications の導入から、SIP トランクのみを使用し、トランクとダイヤル プランの集約プラットフォームとして Cisco Unified Communications Manager Session Manager Edition を使用する導入へ移行しています。

表 6-2 に示されるように、SIP および H.323 トランクがシスコ デバイス間のトランク接続で同じ機能を多数共有していますが、SIP トランクは H.323 トランクでサポートされていない複数の機能をサポートします。他のベンダー製品およびサービス プロバイダー ネットワークへのトランク接続では、SIP が今日最もよく使用されているプロトコルで、H.323 などのプロトコルを使用している Unified Communications の製品およびネットワークが SIP に移行するにともない、その使用が拡大しています。

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

 

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

機能
SIP
H.323

発呼回線(番号)ID 表示

Yes

Yes

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

Yes

Yes

発信者名 ID 表示

Yes

Yes

発信者名 ID 表示禁止

Yes

Yes

接続回線(番号)ID 表示

Yes

Yes

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

Yes

Yes

接続者名 ID 表示

Yes

Yes

接続者名 ID 表示禁止

Yes

Yes

呼び出し表示

Yes

No

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

Yes/Yes

Yes/Yes

すべてのコールの転送

Yes

Yes

自動転送(話中)

Yes

Yes

自動転送(無応答)

Yes

Yes

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

Yes

Yes

QSIG 呼完了(無応答)

Yes

Yes

QSIG パス置換

Yes

Yes

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

Yes

No

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

Yes

No

コール保留/復帰

Yes

Yes

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

Yes

Yes

DTMF リレー

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

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

SIP アーリー オファー

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

該当なし

SIP ディレイド オファー

Yes

該当なし

H.323 Fast Start

該当なし

Yes:発信 Fast Start のために常に MTP が必要:音声コールのみがサポート対象

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

Yes

No

SIP アーリー オファー/H323 Fast Start に対する MTP によるコーデック

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

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

G.711、G.723、G.729 のみ

ビデオ

Yes

Yes

ビデオ コーデック

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

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

ビデオ プレゼンテーション共有(BFCP)

Yes

No

Multi-Level Precedence and Preemption(MLPP)

Yes

Yes

T.38 ファクス

Yes

Yes

シグナリング認証

ダイジェスト、TLS

No

シグナリング暗号化

TLS

No

メディア暗号化(音声)

SRTP

SRTP

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

Yes

No

+ 文字のサポート

Yes

No

着信の着呼側変換

Yes

Yes

着信の発呼側変換

Yes

Yes

接続先変換

Yes

Yes

発信の発呼側変換

Yes

Yes

発信の着呼側変換

Yes

Yes

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

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

Unified CM、Unknown、National、International、Subscriber

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

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

Unified CM、ISDN、National Standard、Private、Unknown

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

OPTIONS ping

コール別の試行

IPv6、デュアル スタック、ANAT

Yes

No

相互運用性のためのプロトコル変更スクリプト

Yes

No

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

Yes

Yes

最大 16 の宛先アドレス

Yes

Yes

URI ベースのコール

Yes

No

地理的位置のサポート

Yes

Yes

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

SIP トランクの概要

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

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

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

SIP OPTIONS ping キープアライブ

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

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

相互運用性の SIP トランクの正規化および透過性スクリプト

SIP REFER 透過

デスクトップ プレゼンテーション(Binary Flow Control Protocol(BFCP))および遠端カメラ制御(FECC)を備えた H.264 ビデオ

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

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

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

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

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

Session Initiation Protocol(SIP)の操作

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

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

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

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

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

Unified CM SIP トランクは、SIP ディレイド オファーおよびアーリー オファーの両方をサポートします。デフォルトでは、SIP トランクはディレイド オファーとして設定されており、音声、ビデオ、および暗号化されたコールをサポートします。アーリー オファー コールの場合、発信側デバイスのメディア特性を判別できない場合、Unified CM はメディア ターミネーション ポイント(MTP)を挿入します(たとえば、アーリー オファー SIP トランクで転送される着信ディレイド オファー コール)。Unified CM アーリー オファー トランクの設定については、この章の後半で詳細に説明します。

SIP ディレイド オファー

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

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

 

SIP アーリー オファー

アーリー オファーでは、セッションの開始側(発信側デバイス)は、その機能(たとえば、サポート対象のコーデック、IP アドレス、および RTP の UDP ポート番号)を初回の Invite に含まれる SDP ボディで送信します(これにより、セッションで使用されるコーデックを着信側デバイスで選択できるようになります)。アーリー オファーは、サードパーティのユニファイド コミュニケーション ベンダーによって好んで使用されることが多く、サービス プロバイダーによってほぼ必ず使用されています。サービス プロバイダーは、初回の 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 が使用されている場合は、SDP メッセージになります。


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

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

Session Description Protocol(SDP)および音声コール

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

 

表 6-3 音声コール:SDP オファー

SDP メッセージのフィールド
説明

v=0

SDP バージョン(現在はバージョン 0)

o=CiscoCCM-SIP 2000 1 IN IP4 10.10.199.250

発信元(Unified CM IP アドレスを含む)

s=SIP Call

セッション名

c=IN IP4 10.10.199.130

接続データ(エンドポイントの IP アドレス)

t=0 0

タイミング(0 0 = 永続セッション)

m=audio 16444 RTP/AVP 0 8 18 101

メディア記述:UDP ポート、提供されたビデオ コーデックの RTP ペイロード タイプ(選好順序)、および DTMT

a=rtpmap:0 PCMU/8000

G.711 mu-law コーデック

a=ptime:20

パケット化(サンプリング)の時間間隔(ミリ秒)

a=rtpmap:8 PCMA/8000

G.711 a-law コーデック

a=ptime:20

パケット化(サンプリング)の時間間隔(ミリ秒)

a=rtpmap:18 G729/8000

G.729 コーデック

a=ptime:20

パケット化(サンプリング)の時間間隔(ミリ秒)

a=sendrecv

メディア方向

a=rtpmap:101 telephone-event/8000

RFC 2833 インバンド DTMF

a=fmtp:101 0-15

サポート対象の DTMF 文字

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

 

表 6-4 音声コール:SDP アンサー

SDP メッセージのフィールド
説明

v=0

SDP バージョン(現在はバージョン 0)

o=CiscoCCM-SIP 2000 1 IN IP4 10.10.199.251

発信元(Unified CM IP アドレスを含む)

s=SIP Call

セッション名

c=IN IP4 10.10.199.179

接続データ(エンドポイントの IP アドレス)

t=0 0

タイミング(0 0 = 永続セッション)

m=audio 28668 RTP/AVP 0 101

メディア記述:UDP ポート、選択したコーデックの RTP ペイロード タイプ、および DTMF

a=rtpmap: 0 PCMU/8000

G.711 mu-law コーデック

a=ptime:20

パケット化(サンプリング)の時間間隔(ミリ秒)

a=sendrecv

メディア方向

a=rtpmap:101 telephone-event/8000

RFC 2833 インバンド DTMF

a=fmtp:101 0-15

サポート対象の DTMF 文字

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

 

Session Description Protocol(SDP)およびビデオ コール

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

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

 

表 6-5 音声コールおよびビデオ コール:SDP オファー

SDP メッセージのフィールド
説明

v=0

SDP バージョン(現在はバージョン 0)

o=CiscoCCM-SIP 161095 1 IN IP4 10.10.199.250

発信元(Unified CM IP アドレスを含む)

s=SIP Call

セッション名

t=0 0

タイミング(0 0 = 永続セッション)

m=audio 16444 RTP/AVP 0 8 18 101

音声メディア:選好順序のペイロード タイプによって表示されているポート番号とオーディオ コーデック、および DTMF ペイロード タイプ

c=IN IP4 10.10.199.130

接続データ(エンドポイントの IP アドレス)

...

複数のオーディオ コーデックおよび DTMF の属性

m=video 16446 RTP/AVP 98 99

メディア記述:UDP ポート、および提供されたビデオ コーデックの RTP ペイロード タイプ(選好順序)

c=IN IP4 10.10.199.130

エンドポイントの IP アドレス

a=rtpmap:98 H264/90000

H.264 ビデオ コーデック

a=fmtp:98 profile-level-id=428016;packetization-mode=1;max-mbps=245000;max-fs=9000;max-cpb=200;max-br=5000;max-rcmd-nalu-size=3456000;max-smbps=245000;max-fps=6000

H.264 コーデック メディア属性

a=rtpmap:99 H263-1998/90000

H.263 ビデオ コーデック

a=fmtp:99 QCIF=1;CIF=1;CIF4=1;CUSTOM=352,240,1

H.263 コーデック メディア属性

a=rtcp-fb:* nack pli

パケット損失表示の RTCP

a=rtcp-fb:* ccm tmmbr

ビデオ レート適合の RTCP

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

 

表 6-6 音声コールおよびビデオ コール:SDP アンサー

SDP メッセージのフィールド
説明

v=0

SDP バージョン(現在はバージョン 0)

o=CiscoCCM-SIP 112480 1 IN IP4 10.10.199.251

発信元(Unified CM IP アドレスを含む)

s=SIP Call

セッション名

t=0 0

タイミング(0 0 = 永続セッション)

m=audio 28668 RTP/AVP 0 101

音声メディア:ポート番号、選択したオーディオ コーデック、および DTMF ペイロード タイプ

c=IN IP4 10.10.199.179

接続データ(エンドポイントの IP アドレス)

...

選択した G.711 オーディオ コーデックおよび DTMF の属性

m=video 28670 RTP/AVP 98

ビデオに選択した H.264 コーデック

c=IN IP4 10.10.199.179

エンドポイントの IP アドレス

a=rtpmap:98 H264/90000

H.264 コーデックの詳細

a=fmtp:98 profile-level-id=428016;packetization-mode=1;max-mbps=108000;max-fs=3600;max-cpb=200;max-br=5000;max-rcmd-nalu-size=1382400;max-smbps=108000;max-fps=6000

選択した H.264 コーデックのメディア属性。

プロファイル レベル ID とパケット化モードは、ネゴシエートされたコールで対称的である必要があります。その他の属性では、対称的である必要はなく、エンドポイントの受信機能を表します。

a=rtcp-fb:* nack pli

パケット損失表示の RTCP

a=rtcp-fb:* ccm tmmbr

ビデオ レート適合の RTCP

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

すべてのルート リストおよび SIP トランクで、[Run on all Active Unified CM Nodes] をオンにすることを強く推奨します。

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

SIP トランクは、最大 16 の宛先 IP アドレス、16 の完全修飾ドメイン名、または単一の DNS SRV エントリを使用して設定できます。追加の宛先 IP アドレスをサポートしているため、2 つの Unified Communications システム間のコール分配のために、ルート リストおよびルート グループに関連付けられた複数のトランクを作成する必要性が軽減されます。結果として、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 Communication システムに接続します。トランクのフェールオーバーが必要な場合、フェールオーバーの Unified Communication システムに追加のトランクを作成し、ルート リストとルート グループを使用して、トランクの選択を順序付けします。Unified CM は、設定された SIP トランク宛先アドレスで発信コールをランダムに分配します。

図 6-9 [Run on all Unified CM Nodes] および複数の宛先アドレスを使用した SIP トランク

 

図 6-10 [Run on all Unified CM Nodes] をオンにした SIP トランクおよびルート リスト

 

DNS を使用する SIP トランク

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

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

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

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

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


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


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

図 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 接続を確立できない場合、そのアドレスは「out of service」と見なされます。1 つ以上のノードが、1 つ以上の宛先アドレスから(408 または 503 以外の)応答を受信した場合、トランク全体の状態は「in service」と見なされます。SIP トランク ノードは、トランクの設定済み宛先 IP アドレス、またはトランクの DNS SRV エントリの解決済み IP アドレスに対して OPTIONS 要求を送信できます。SIP OPTIONS ping の有効化はすべての SIP トランクで推奨されます。有効にすることで、Unified CM は、ノード毎、コール毎、およびタイムアウト毎にトランク宛先の状態を判別するのではなく、ダイナミックにトランクの状態を追跡できるためです。

Unified CM SIP トランク:ディレイド オファーおよびアーリー オファー

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

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

Unified CM SIP トランクのデフォルト設定は、ディレイド オファー(SDP なしの SIP INVITE)を使用します。アーリー オファーとは異なり、ディレイド オファー トランクは、SDP オファーを作成するためにメディア ターミネーション ポイント(MTP)で使用する必要はありません。下記の特定の状況では、MTP は、コールでサポートされるメディア タイプを音声のみに制限できます。そのため、音声、ビデオ、および暗号化されたコールに対するサポートが必要な場合は、ディレイド オファーを使用する必要があります。

Unified CM SIP アーリー オファー

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

Media Termination Point Required

Early Offer support for voice and video calls (insert MTP if needed)

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

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

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

 

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

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

音声コールとビデオ コールに対するアーリー オファーのサポートとして設定されている SIP トランクを介した発信コール(必要に応じて、MTP を挿入)では、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 アーリー オファーによる音声コールおよびビデオ コールのサポート

 

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

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

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

MGCP トランク上

Unified CM に登録されている SIP ベースの IP フォンから

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

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

トランクの SIP プロファイルで [Early Offer support for voice and video calls (insert MTP if needed)] を設定している場合、古い SCCP ベースの電話、SIP ディレイド オファー トランク、および H.323 Slow Start トランクからのコールに対して Unified CM では MTP を割り当てます。MTP は、有効なメディア ポートおよび 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 では、[Early Offer for voice and video (insert MTP if needed)] 機能を有効にして SIP トランクを介したコールを発信するときに、MTP を使用する必要があります。クラスタにこれらの電話機タイプが多数配置されている場合、アーリー オファー トランクではなく、ディレイド オファー トランクを配置することを考慮してください。アーリー オファー トランクを使用する場合、[Early Offer for voice and video (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-Less アーリー オファー

MTP-Less アーリー オファーは、Unified CM Session Manager Edition(SME)SIP トランクの特殊なケースの設定です。SIP トランクのみを使用した SME 配置の場合、MTP-Less アーリー オファーを使用すると、メディアに透過的な SME クラスタを配置することができます(SME クラスタでメディア リソースは不要)。これは、すべてのメディア ネゴシエーションがリーフ Unified Communications システムで行われるためで、メディア リソース(MTP、トランスコーダなど)は必要に応じて挿入されます(図 6-14 を参照)。

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

図 6-14 MTP-Less アーリー オファー:SME メディアの透過性

 

メディアに透過的な SME クラスタを設定するには、次の内容を実行します。

SME クラスタで SIP トランクのみを使用する。

[Early Offer support for voice and video calls (insert MTP if needed)] を使用して、すべてのトランクを有効にする。

すべての SME ノードの IPVMS サービスを無効にする。これにより、Unified CM メディア ターミネーション ポイント、会議、保留音、およびアナンシエータ リソースが無効になります。

SME クラスタと Cisco IOS メディア リソースを関連付けしない。

SIP トランク DTMF 設定を [No Preference](デフォルト設定)に設定する。

すべての SME SIP トランクで [Accept Audio Codec Preference in Received Offer] をオンにする。

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

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

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

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

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

o Trusted Relay Point(TRP)として動作する場合

o 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 ソフトウェア リリースで使用できます。ハードウェア 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 の場合の例です。

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

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

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

アウトオブバンド(OOB)SIP DTMF シグナリング方式には、Unsolicited Notify(UN)、Information(INFO)および Key Press Markup Language(KPML)が含まれます。KPML(RFC 4730)は、シスコが推奨する OOB シグナリング方式ですが、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 コーデックを使用した場合だけ、その再生成が信頼できるため、低帯域幅コーデックでの使用には適していません。インバンド オーディオが唯一使用できる DTMF 転送メカニズムである場合、Cisco Unified Border Element を使用して、インバンド オーディオ DTMF シグナリングを RFC 2833 シグナリングに変換できます。

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

[DTMF Signalling Method: No Preference]

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

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

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

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

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

[DTMF Signalling Method: RFC 2833]

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

[DTMF Signalling 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 割り当てを最小に抑えることができます。

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

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

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

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

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

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

 

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

 

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

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

 


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



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


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

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

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

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

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

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

 

SIP トランク トランスポート プロトコル

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

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

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


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


安全な SIP トランク

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

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

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

メディア暗号化

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

シグナリング暗号化

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

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

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

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

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

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

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

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

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

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

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


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


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

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

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

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

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


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


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

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

メッセージ ヘッダー

From:

From: "Jim Bob" <sip:1000@10.10.199.250>

From: "Anonymous" <sip:localhost>

To:

To: "Nick Cave" <sip:2000@10.10.100.251>

P-Asserted-Identity:

P-Asserted-Identity: "Jim Bob" <sip:1000@10.10.199.250>

Remote-Party-ID:

Remote-Party-ID: "Jim Bob" <sip:1000@10.10.199.250>

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 ゲートウェイで定義できる変換ルールを示しています。

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

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

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

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

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

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 ノードで実行

この機能は、SIP トランクおよびルート リストでサポートされ、Unified CM および SME クラスタから、そして Unified CM および SME クラスタを介してコール ルーティングを大幅に簡素化します。すべての SIP トランクおよびルート リストで、[Run on all Active Unified CM Nodes] 機能をオンにすることを強く推奨します。コール ルーティングは、[Run on all Unified CM nodes] とルート ローカル機能の組み合わせで簡略化されます。ここでは、SIP トランクを介した電話は、電話機が登録されている Unified CM ノードから常に発信されます。トランク間のコールと同様に、発信 SIP トランク コールは、着信トランク コールが到達した Unified CM ノードから常に発信されます。すべての SIP トランクおよびルート リストに対して [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 Options] パラメータを介して PRACK を有効にします。

SIP トランクの DTMF Signalling Method:No Preference

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

Session Management Edition の SIP トランク:MTP-Less アーリー オファー

SIP トランクのみを使用した SME クラスタでは、MTP-less アーリー オファーでは、メディア トランスペアレントな SME クラスタを配置できます。メディア ネゴシエーションがリーフ UC システムで実行されるため(必要に応じてメディア リソース(MTP、トランスコーダなど)を挿入)、SME クラスタでメディア リソースは必要ありません。

メディアの透過的な SME クラスタを配置するには、次の内容を実行します。

SME クラスタで SIP トランクのみを使用する。

[Early Offer support for voice and video calls (insert MTP if needed)] を使用して、すべてのトランクを有効にする。

すべての SME ノードの IPVMS サービスを無効にする。これにより、Unified CM メディア ターミネーション ポイント、会議、保留音、およびアナンシエータ リソースが無効になります。

SME クラスタと Cisco IOS メディア リソースを関連付けしない。

SIP トランク DTMF 設定を [No Preference](デフォルト設定)に設定する。

すべての SME SIP トランクで [Accept Audio Codec Preference in Received Offer] をオンにする。

Unified CM SIP トランク:ディレイド オファーまたはアーリー オファー

Unified CM クラスタ内の SIP ディレイド オファーまたはアーリー オファーを使用する決断は、Unified CM クラスタに登録されている古い SCCP ベースの電話機の数に左右されます。

クラスタに登録されている電話機の大半が、新しい SCCP または SIP 電話機である場合、ディレイド オファーまたはアーリー オファーを使用できます。ただ、IP PSTN サービス プロバイダーと一部の Unified Communications アプリケーションでは、アーリー オファー SIP トランク コールのみに対応しているため、一般的にはアーリー オファーが推奨されます。

Cisco Unified IP Phone 7902、7905、7910、7912、7920、7935、7940、7960 など古い SCCP ベースの IP Phone では、[Early Offer support for voice and video (insert MTP if needed)] 機能を有効にして SIP トランクを介したコールを発信するときに、MTP を使用する必要があります。クラスタ内にこのような古い SCCP ベースの電話機が多数登録されている場合、アーリー オファーが使用されている場合は、かなりの数の MTP が必要です。この場合、SDP オファーが推奨されるので、SDP オファーまたはアンサーを生成するために MTP は必要ありません。

Unified Communications 配置では通常、アーリー オファーは IP PSTN サービス プロバイダーやその他の Unified Communications アプリケーションでも必ず必要です。Cisco Unified Border Element では、SIP ディレイド オファーからアーリー オファーへの変換機能を音声コールに対して提供します。着信ディレイド オファーの音声コールが発信アーリー オファーの音声コールに変換されるので、Unified CM および SME で、アーリー オファー SIP トランクと MTP ではなく、ディレイド オファー トランクを使用できるようになります。SIP アーリー オファーのみを受け入れる Unified Communications アプリケーションでは、ピーク時のコール量が低く、Unified CM からアプリケーションに専用の SIP トランクが使用される場合、Cisco Unified Border Element の代わりに、[Early Offer support for voice and video (insert MTP if needed)] 機能とともに MTP を使用することがより経済的であることがあります。

Unified CM Session Management Edition

Cisco Unified Communications Manager Session Management Edition(Unified CM SME)は、マルチサイト分散型呼処理配置で推奨されるトランクとダイヤル プランの集約プラットフォームです。SME は基本的に、トランク インターフェイスだけを使用し、IP エンドポイントを使用しない Unified CM クラスタです。このクラスタには、リーフ システムと呼ばれる、複数のユニファイド コミュニケーション システムを集約できます(図 6-20 を参照)。

SIP が H.323 および MGCP トランクで使用できない追加の機能を提供するため、SIP トランクは、SME およびリーフ Unified Communications システムで大いに推奨されます。この項の後半で述べられるように、SIP トランクのみを使用する SME 設計専用の特定のトランク機能があります。Unified Communications ネットワークが、ゲートウェイまたは他の Unified Communications アプリケーションへの H.323 または MGCP トランク接続をサポートする必要がある場合、SME クラスタで SIP 専用トランク機能を保持するために、SME ではなく、リーフ Unified Communications システムにこれらの H.323 および MGCP トランク(もしくはどちらか一方)を接続します。

Cisco Unified CM Session Management Edition(SME)は、次のコール タイプをサポートします。

ボイスコール

ビデオ コール

暗号化されたコール

FAX コール

また、Unified CM Session Management Edition を使用して、PSTN のほか、PBX、集中型のユニファイド コミュニケーション アプリケーションなどのサードパーティのユニファイド コミュニケーション システムに接続できます。

図 6-20 Unified CM Session Management Edition を使用したマルチサイト分散型呼処理配置

 

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 トランクは、[MTP-less Early Offer] トランクとして設定する必要があります。リーフ Unified CM クラスタは、[SIP Delayed Offer] または [SIP Early Offer for Voice and Video (Insert MTP if needed)] に設定できます。

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

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

WAN を介したクラスタリング:SME CoW+

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

WAN(CoW+)を介したクラスタリングの拡張ラウンドトリップ時間使用した SME の配置は、SIP トランクだけでサポートされます。すべての SIP トランクは、コールが SME クラスタ内のノード間でルーティングされないように、[MTP-less Early Offer] として設定され、[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-21 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 クラスタを介したコール ルーティングを改善し、簡略化する機能がこのバージョンに含まれているためです。

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

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

Unified CM リーフ クラスタの場合:

各地域データセンターの SME ノードのセットごとに 1 つの SIP トランクを設定する。たとえば、4 つの地域 SME データセンターがある場合、各リーフ クラスタに 4 つの SIP トランクを作成します(図 6-22 を参照)。これにより、すべての SME のノードからのコールがリーフ クラスタによって受信され、受け入れられるようになります。これらのすべてのトランクで [Run on all Unified CM nodes] をオンにします。

SME CoW+ クラスタへのパスの冗長性のために、ルート リストおよびルート グループにこのようなリーフ クラスタの SIP トランクを 2 つ以上置く。

SIP トランクは、SIP アーリー オファーまたは SIP ディレイド オファーのいずれかを使用できます。

すべてのリーフ クラスタ ノードで IPVMS サービスを有効にする。必要に応じて、会議、保留音、およびアナンシエータ リソースをアクティブにします(IPVMS ベースの MTP を非アクティブにすることが推奨されます)。

必要に応じて、リーフ クラスタに Cisco IOS メディア リソース(MTP、会議、およびトランスコーディング)を設定して、関連付ける。

SIP トランク DTMF 設定を [No Preference](デフォルト設定)に設定する。

SIP OPTIONS ping および PRACK を有効にする。

必要に応じて、コーデックのプリファレンス リストを設定し、適用する。

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

 

Session Management Edition クラスタの場合:

SME クラスタで SIP トランクのみを使用する。

SME クラスタから各リーフ クラスタに 1 つの SIP トランクを設定する(図 6-23 を参照)。これらのトランクで [Run on all Unified CM Nodes] をオンにし、リーフ クラスタ内のすべてのコール処理ノードにトランク宛先を設定する。

[Early Offer support for voice and video calls (insert MTP if needed)] を使用して、すべてのトランクを有効にする。

すべての 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-23 CoW+ SME クラスタ トランクに対する推奨トランク設定

 

リーフおよび SME クラスタを介したコール ルーティングの場合:

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

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

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

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

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

 

Unified CM SIP トランクのマイナー機能

ここでは、Unified CM SIP トランクで使用可能な複数のマイナー機能の機能と用途を説明します。

[Send sendrecv in Mid-Call INVITE]

この機能は、サードパーティ製品との相互運用性の問題を処理するために使用されます。Unified CM が SIP トランクを介してコールを保留に置く場合、SDP 本文の音声方向のメディア属性 a=inactive で通話中の INVITE を送信して、メディア接続を切断します。コールの再開では、SDP オファーでメディア特性を取得するために、Unified CM は保留デバイスにディレイド オファー INVITE(SDP なし)を送信します。RFC 3261(セクション 14.2)に応じて、保留デバイスは、新しいコールを発信したかのように(つまり、サポート対象のすべてのコーデックと a=sendrecv のリストで)オファーを構築する必要があります。一部のサードパーティ製品は、コールが常に非アクティブ状態で、メディアを再開できない結果に応じて、最後に使用されたコーデックとメディア方向属性のみで応答します。[Send "sendrecv" in mid call INVITE] が有効な場合、この機能では、発信側デバイス間のメディア パスに MTP を挿入することにより、a=sendrecv により MTP と保留デバイス間のメディアを確立し、維持しながら、Unified CM デバイスと MTP 間でメディア接続を切断することができるようになります。コールの再開中、MTP がメディア パスから削除されます。この機能は、音声方向の通話中のディレイド オファー INVITE 問題に対処しますが、サポートされているすべてのコーデックの詳細なリストではなく、最後に使用されたコーデックを使用して応答するデバイスの問題を解決できません。この問題は、G.729 コールを保留中にし、G711 が望まれる保留音ソースに接続するなどのメディアの再構築でコーデックの変更が必要な場合は、問題になる可能性があります。

通話中のメディア交換で SDP 非アクティブを必要とする

SIP では、メディア接続を中断することなく、通話中のコーデックの更新や、IP アドレス、UDP ポート番号などの接続情報の更新を処理できます。一部のサードパーティ製デバイスはこの方法を使用してメディア変更を受け入れることができないので、正常にメディア パスを閉じてから、再び開いてメディア変更を行う必要があります。この機能が有効な場合、通話中のコーデックまたは接続の更新中に、Cisco Unified CM が INVITE a=inactive SDP メッセージをエンドポイントに送信して、メディア交換を中断させます。


) アーリー オファー対応の SIP トランクの場合、このパラメータは [Send send-receive SDP in mid-call INVITE] パラメータによって上書きされます。


Disable Early Media on 180

デフォルトでは、SDP が 180 Ringing または 183 Session Progress Response で受信されなかった場合、Cisco Unified CM は、ローカル リングバックを再生するように、登録された発信側電話機に通知します。

180 または 183 Response に SDP が含まれる場合、リングバックをローカルで再生する代わりに、Cisco Unified CM ではメディアを接続し、発信側電話機がメディア ストリームで送信しているもの(リングバックまたはビジー信号)をすべて着信側電話機で再生します。

リングバックが受信されない場合、接続しているデバイスが 180 Response に SDP を含んでいる可能性がありますが、200 OK 応答の前にメディアを送信していません。この場合、このチェックボックスをオンにして、発信側の電話機でローカル リングバックを再生し、200 OK 応答の受信時にメディアを接続します。

Redirect by Application

オンにした場合、Redirect by Application 機能により、Unified CM は次の内容を実行できます。

リダイレクトされたコンタクトが 3xx 応答で受信された場合に、特定のコーリング サーチ スペースを適用する。

リダイレクトされたコンタクトに対して番号分析を適用し、コールが正しくルーティングされていることを確認する。

リダイレクション(再帰リダイレクション)要求の数を制限することによって、DOS 攻撃を防止する。

リダイレクションの実行中にその他の機能を起動できるようにする。

[Redirect by Application] チェックボックスがオフの場合、発信 SIP トランク コールを制限付きの電話番号(国際電話など)にリダイレクトできます。これは、リダイレクトが SIP スタック レベルで処理およびルーティングされ、Unified CM の番号解析とサービス クラスによる介入がないためです。

新しいトランクへの着信要求の再ルーティング

発信側デバイスの送信元 IP アドレスとポート番号が、設定された SIP トランクの宛先 IP アドレスとポート番号に一致する場合にだけ、Unified CM への着信 SIP トランク コールが受け入れられます。コールが受け入れられると、受信した SIP メッセージ ヘッダーに含まれる情報に基づいて、別の Unified CM SIP トランクに任意で再ルーティングできます。

デフォルトでは、IP アドレスとポート番号に基づいて SIP トランクが照合されると、コールは再ルーティングされることはありません。

任意で、次の内容の受信に基づいて新しいトランクに着信要求を再ルーティングできます。

Contact ヘッダー

コールは、Contact ヘッダーで受信された IP アドレスとポート番号に基づいて別の SIP トランクに再ルーティングされます。この機能は、通常、SIP プロキシから特定のエンド ユーザまたはシステムに割り当てられている Unified CM SIP トランクにコールを再ルーティングするために使用されます。

[Call-Info Header with purpose=x-cisco-origIP]

このオプションは、Cisco Unified Customer Voice Portal(CVP)からの着信コールを、Call-Info ヘッダーのパラメータ purpose=x-cisco-origIP に含まれる IP アドレスとポート番号に基づいた特定のトランクに照合するために使用されます。この機能は、コール アドミッション制御に対して Unified CVP からのコールを Unified CM トランクにマッピングするために通常使用されます。

発信トランク コールでの発信者 ID 番号および発信者名の上書き

この機能はたとえば、SIP トランクで送信されるコールの SIP メッセージの発信者の番号と名前ではなく、企業のスイッチボードの番号と企業名を送信する場合に、実用的です(図 6-25 を参照)。この機能は、デバイス レベル(集中型 SIP トランクを使用した支社の場合)またはトランク レベルに適用できます。

デバイス レベルでは、デバイスに関連付けられている SIP プロファイルの [Incoming Requests FROM URI Setting] セクションの [Caller ID DN] および [Caller Name] フィールドを使用します。

トランク レベルでは、トランク設定ページの [Outbound Calls - Caller Information] セクションの [Caller ID DN] および [Caller Name] フィールドを使用します。

デフォルトでは、From ヘッダー、Contact ヘッダー、および P-Asserted-Identity ヘッダー、および Remote-Party-ID ヘッダーで送信される [Caller ID DN] と [Caller Name] は、発信 SIP トランク コールで変更されます。P-Asserted-Identity および Remote-Party-ID ヘッダーの元の発信者 ID を保持したい場合は、トランク設定ページで [Maintain Original Caller ID DN and Caller Name in Identity Headers] チェックボックスをオンにします。このチェックボックスをオンにすると、コールの発信者を追跡することができます。

図 6-25 発信 SIP トランク コールでの発信者 ID の番号および発信者名の上書き

 

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

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

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 パラメータ

Content の本体

SDP

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

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

 

SIP トランクの透過性

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

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

SIP ヘッダー

SIP パラメータ

Content の本体

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

 

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

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

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

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

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

http://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 スクリプト:このスクリプトは、さまざまな Call Forward シナリオ用に Diversion カウンタを調整する機能を提供します。

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

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

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

SIP のサービスは今日の使用可能なサービスの中で優位を占め、旧 H.323 サービスは特定の地域で使用できましたが、段階的に使用されなくなっています。これは、主にユニファイド コミュニケーションのベンダーおよび企業内で、SIP がプロトコルとして人気が高まったことによるものです。

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

Cisco Unified Border Element

Cisco Unified Border Element は、次の機能とサービスを提供する Session Border Controller です。

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

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

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

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

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

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

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

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

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

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

ダイヤル ピアに照合するために URI ルーティングによる GDPR ルート文字列の使用

ドメインベースのルーティング

マルチキャスト保留音からユニキャスト保留音

音声およびビデオ メディア フォーキング

企業のフォン プロキシ:Unified CM から Cisco Unified Border Element への VPN-Less IP Phone の登録

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

Cisco Unified Border Element は、Cisco ルータおよびゲートウェイ プラットフォームの広い範囲で使用できる認可を受けた Cisco IOS アプリケーションです。選択したハードウェア プラットフォームに応じて、Cisco Unified Border Element は、ボックス内またはボックス間のフェールオーバー オプションで、4 ~ 16,000 の同時音声コールについてセッション スケーラビリティを提供できます。

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

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

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

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

中央集中型トランクは、Cisco Unified Border Element などのセッション ボーダー コントローラ(SBC)を使用し、1 つの論理接続を通して企業ネットワークをサービス プロバイダーに接続します(ただし、冗長性を確保するために複数の物理接続が存在する場合があります)(図 6-28 を参照)。IP PSTN へのすべてのコール、および IP PSTN からのすべてのコールでは、このトランクのセットが使用されます。集中型 IP PSTN 接続からのすべてのリモート サイトでは、PSTN コールのメディアおよびシグナリングは、企業 IP WAN を通過する必要があります。

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

 

分散型トランクは、複数の地理的に分散された論理接続経由でサービス プロバイダーに接続します(図 6-29 を参照)。会社の各支社は、サービス プロバイダーへの独自のローカル トランクを保有しています。各支社サイトで分散型トランクを使用する場合、メディアは企業 WAN を通過する必要はなくなりましたが、ローカル SBC 経由でサービス プロバイダーへと流れます。

図 6-29 分散型 SIP トランク モデル

 

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

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

 

IP PSTN トランクと緊急サービス

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

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