この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
目次
この章では、Session Initiation Protocol(SIP)、および SIP と Cisco Unified Communications Manager の対話について説明します。
SIP トランクのセットアップに、SIP トランクを Cisco Unified Communications Manager に設定するために必要な手順の概要を、関連する手順とトピックの参照先とともに示します。
電話機の設定に、SIP を実行する Cisco Unified IP Phone を設定するために必要な手順の概要を示します。
SIP を実行するサードパーティの電話機を設定する場合は、『Cisco Unified Communications Manager アドミニストレーション ガイド』を参照してください。
SIP プロキシ サーバ:このプロキシ サーバは、クライアントから SIP 要求を受信して、クライアントの代わりに要求を転送する中間デバイスとして機能します。 プロキシ サーバは、認証、許可、ネットワーク アクセス制御、ルーティング、信頼性の高い要求再送、セキュリティなどの機能を提供します。
リダイレクト サーバ:リダイレクト サーバは、メッセージが進むべきネクストホップに関する情報を 1 つ以上クライアントに提供します。その後、クライアントは、次のホップ サーバまたユーザ エージェント サーバと直接接続します。
登録サーバ:登録サーバは、現在のロケーションの登録を求めるユーザ エージェント クライアントからの要求を処理します。 リダイレクトまたはプロキシ サーバには、登録サーバが含まれる場合があります。
ユーザ エージェント(UA):UA は、コールを開始および受信するユーザ エージェント クライアント(UAC)とユーザ エージェント サーバ(UAS)の組み合わせで構成されます。 UAC が SIP 要求を開始します。 UAS は、SIP 要求を受信したときにユーザに連絡するサーバ アプリケーションです。 要求を受信すると、UAS がユーザの代わりに応答します。 Cisco Unified Communications Manager は、サーバとクライアントの両方(バックツーバック ユーザ エージェント)として動作できます。
SIP は、要求/応答方式を使用して、ネットワーク内の各種のコンポーネント間の通信を確立し、最終的に 2 つ以上のエンドポイント間のコールまたはセッションを確立します。 1 つのセッションには、複数のクライアントおよびサーバが使用されます。
SIP ネットワーク内のユーザの識別は、次の方法で行われます。
一意の電話番号または内線番号。
電子メール アドレスと同じように表示され、sip:<userID>@<domain> 形式を使用する一意の SIP アドレス。 ユーザ ID は、ユーザ名または E.164 アドレスのいずれかを使用できます。 Cisco Unified Communications Manager は、E.164 アドレスだけをサポートし、電子メール アドレスはサポートしていません。
Cisco Unified Communications Manager 上で SIP ルート パターンによってサポートされている電子メール アドレス形式 (employee@company.com)。
どのプロトコルを使用する場合も、コールを受信および発信するためには、シグナリング インターフェイス(トランク)またはゲートウェイのいずれかを作成する必要があります。 SIP に関しては、SIP トランクを設定する必要があります。
次の図に示すように、SIP トランクは、 Cisco Unified Communications Manager ネットワークを SIP プロキシ サーバが提供する SIP ネットワークに接続します。 他のプロトコルと同様に、SIP コンポーネントは、 Cisco Unified Communications Manager アーキテクチャのデバイス層に適合します。 H.323 プロトコルの場合、複数の論理 SIP トランクを Cisco Unified Communications Manager データベースに設定し、ルート グループ、ルート リスト、およびルート パターンに関連付けることができます。 1 つの論理 SIP インターフェイスに障害が発生した場合に冗長性を提供できるように、他の論理 SIP インターフェイスは同一のルート グループ リストにサービスを提供します。 複数の Cisco Unified Communications Manager ノードを SIP トランク デバイス プールに割り当てると、冗長性も実現できます。
SIP トランクはすべてのノードで同時に実行でき、 Cisco Unified Communications Manager は指定されたノードにアクセスできる使用可能な SIP トランクからランダムに選択できます。 システムは、長期間平均して、コア クラスタ内の 16 のノードすべてが均等に使用されるようにします。 これにより、システム リソースがアイドル状態のノードがある一方で、持続不可能なコール負荷を処理するノードがあるという状況が生じません。
![]() (注) |
SIP ICT での外部番号への折り返しはサポートされていません。 |
SIP トランクは、複数ポート ベースのルーティングをサポートしています。 Cisco Unified Communications Manager の複数の SIP トランクがポート 5060(デフォルト)を使用でき、このデフォルト値は、[SIP トランクセキュリティプロファイルの設定(SIP Trunk Security Profile Configuration)] ウィンドウで設定できます。 TCP/UDP では、SIP トランクはリモート ホストおよびローカル リスニング ポートを使用してルーティングを行います(リモート ホストは、IP、FQDN、または SRV で構成できます)。 TLS では、SIP トランクは、X.509 のサブジェクト名を使用してルーティングを行います。
SIP トランクおよび SIP ステーションからのサービス拒否(DoS)攻撃を防止するために、Cisco Unified Communications Manager は、プラットフォーム層に備えられている SIP UDP ポート スロットリング機能を使用します。 SIP UDP ポート スロットリングのしきい値は、10,000 パケットのバーストで秒あたり 35 パケットに設定されています。 スロットリングのしきい値は、システムのインストール中に設定され、変更できません。
SIP トランクの場合、 Cisco Unified Communications Manager は、設定された SIP トランクの宛先アドレスと IP アドレスが一致する SIP デバイスからのコールのみを受け入れます。 また、SIP メッセージが着信するポートは、SIP トランク上で設定されたポートと一致している必要があります。 コールが受け入れられると、 Cisco Unified Communications Manager は SIP プロファイル設定の [着信要求を新規トランクへと再ルーティングする基準(Reroute Incoming Request to new Trunk based on)] の設定値(コールが着信する SIP トランク上に設定されている)を使用して、コールを別の SIP トランクに再ルーティングするかどうかを決定します。 この設定値に応じて、 Cisco Unified Communications Manager は次のいずれかのタスクを実行します。
別の SIP トランクに再ルーティングしない。
contact ヘッダーにある IP アドレスまたはドメイン名とポート番号を解析し、その情報がいずれかの SIP トランクと一致するかどうかを確認する。SIP トランクが見つかった場合は、コールを再ルーティングします。 SIP トランクが見つからない場合は、コールが着信した SIP トランクがコールを処理します。
Call-Info ヘッダーの IP アドレスまたはドメイン名とポート番号を解析し、パラメータ purpose=x-cisco-origIP を探し、IP アドレスとポートがいずれかの SIP トランクに一致するかどうかを確認する。SIP トランクが見つかった場合は、コールを再ルーティングします。 SIP トランクが見つからない場合、またはこのパラメータが Call-Info ヘッダー内に存在しない場合は、コールが着信した SIP トランクがコールを処理します。
Cisco Unified Communications Manager SIP デバイス(回線およびトランク)が常に MTP を使用するように設定できます。 MTP を使用しないように設定パラメータが設定されている場合(デフォルトの場合)、 Cisco Unified Communications Manager は、コールの DTMF 方式に互換性がなければ、動的に MTP を割り当てようとします。 たとえば、SCCP を実行する電話機はアウトオブバンドの DTMF だけをサポートし、SIP を使用する Cisco Unified IP Phone(7905、7912、7940、7960)は RFC2833 だけをサポートします。 DTMF 方式が同一でないため、 Cisco Unified Communications Manager は MTP を動的に割り当てます。 ただし、RFC2833 とアウトオブバンドをサポートし、SCCP を実行する電話機( Cisco Unified IP Phone 7971 など)が SIP を使用する Cisco Unified IP Phone 7940 にコールした場合、 Cisco Unified Communications Manager は、両方の電話機が RFC2833 をサポートしているため、MTP を割り当てません。 それぞれの電話機で同じタイプの DTMF 方式がサポートされているため、MTP は不要です。
リージョンの関係を設定する場合は、コールに使用されるすべてのデバイスにとって十分な帯域幅のオーディオ コーデックを選択する必要があります。 これには、同じリージョンのデバイスおよび別のリージョンのデバイスに対するコーデックの設定が含まれます。 SIP を使用するようにトランクまたはサードパーティの電話機を設定し、[メディアターミネーションポイントが必須(Media Termination Point Required)] が有効である場合、 Cisco Unified Communications Manager の管理ページの [MTP優先発信コーデック(MTP Preferred Originating Codec)] フィールドでは G.711 コーデックしか選択できません。 [メディアターミネーションポイントが必須(Media Termination Point Required)] オプションが有効な SIP トランクまたは SIP を実行するサードパーティ電話機をそのリージョンのデバイス プールに割り当てる場合、SIP デバイスと MTP デバイスの間のリージョンの関係は、帯域幅が同等以上のコーデック(G.711 コーデックまたはワイドバンド/AAC-LD(mpeg4-generic)コーデック)を使用するように設定されていることを確認する必要があります。
SIP Interoperability Enabled サービス パラメータは、Cisco CallManager サービスをサポートしますが、このパラメータによって、SIP ステーションおよび SIP トランクの Session Initiation Protocol(SIP)を Cisco Unified Communications Manager がサポートするかどうかが決まります。 SIP を実行するデバイス(電話機やトランクなど)がある場合は、このパラメータを [True] に設定する必要があります。このパラメータを [False] に設定すると、 Cisco Unified Communications Manager は SIP メッセージを無視するため、SIP デバイスが機能しなくなります。つまり、SIP を実行する電話機が Cisco Unified Communications Manager に登録されず、SIP トランクが Cisco Unified Communications Manager と対話できなくなります。 デフォルト値は [True] です。 このパラメータの値を変更した場合は、Cisco CallManager サービスを再起動する必要があります。
SIP タイマーとカウンタは、設定可能なサービス パラメータとして機能します。 次の表では、各種の SIP タイマーとカウンタについて説明し、それぞれのデフォルト値と範囲値を示します。
![]() (注) |
SIP デバイスが TCP 転送を使用しているときにタイマーがタイムアウトすると、SIP デバイスは再転送を行いません。 デバイスの再試行は、TCP に依存します。 |
次の表は、サポートされている各種オーディオ メディア タイプの説明です。
タイプ |
エンコーディング名 |
ペイロード タイプ |
コメント |
---|---|---|---|
G.711 u-law |
PCMU |
0 |
|
GSM Full-rate |
GSM |
3 |
|
G.723.1 |
G723 |
4 |
|
G.711 A-law |
PCMA |
8 |
|
G.722 |
G722 |
9 |
|
G.722.1 |
G7221 |
動的に割り当て |
利用可能な範囲は 96 ~ 127 |
G.728 |
G728 |
15 |
|
G.729 |
G729 |
18 |
annex A と B のすべての組み合わせをサポート |
RFC2833 DTMF |
テレフォニー イベント |
動的に割り当て |
利用可能な範囲は 96 ~ 127 |
AAC-LD(mpeg4-generic) |
mpeg4-generic |
動的に割り当て |
利用可能な範囲は 96 ~ 127 |
AAC-LD(MP4A-LATM) |
MP4A-LATM |
動的に割り当て |
利用可能な範囲は 96 ~ 127 |
ILBC |
iLBC |
動的に割り当て |
利用可能な範囲は 96 ~ 127 |
AMR |
AMR |
動的に割り当て |
利用可能な範囲は 96 ~ 127 |
AMR-WB |
AMR-WB |
動的に割り当て |
利用可能な範囲は 96 ~ 127 |
次の表は、サポートされている各種ビデオ メディア タイプの説明です。
タイプ |
エンコーディング名 |
ペイロード タイプ |
---|---|---|
H.261 |
H261 |
31 |
H.263 |
H263 |
34 |
H.263+ |
H263-1998 |
利用可能な範囲は 96 ~ 127 |
H.263++ |
H263-2000 |
利用可能な範囲は 96 ~ 127 |
H.264 |
H264 |
利用可能な範囲は 96 ~ 127 |
次の表は、サポートされているアプリケーション メディア タイプの説明です。
タイプ |
エンコーディング名 |
ペイロード タイプ |
---|---|---|
H.224 FECC |
H224 |
利用可能な範囲は 96 ~ 127 |
次の表は、サポートされている各種アプリケーション メディア タイプの説明です。
タイプ |
エンコーディング名 |
ペイロード タイプ |
---|---|---|
T38fax |
該当なし |
N/A |
SIP トランクと SIP エンドポイントは、SIP プロファイルを使用します。 SIP トランクは、SIP プロファイルを使用して [デフォルトテレフォニーイベントペイロードタイプ(Default Telephony Event Payload Type)]、[180で早期メディアを無効化(Disable Early Media on 180)]、および [着信要求を新規トランクへと再ルーティングする基準(Reroute Incoming Request to new Trunk based on)] 設定値を定義します。 SIP プロファイルの詳細については、エンドポイントの SIP プロファイルを参照してください。
Cisco Unified Communications Manager の管理ページでは、SIP トランクのセキュリティ関連設定をグループ化し、単一のセキュリティ プロファイルとして複数の SIP トランクに割り当てることができます。 セキュリティに関連する設定には、デバイス セキュリティ モード、ダイジェスト認証、および着信/発信転送タイプの設定があります。 設定した値を SIP トランクに適用するには、[トランクの設定(Trunk Configuration)] ウィンドウでセキュリティ プロファイルを選択します。
Cisco Unified Communications Manager リリース 6.0 以降および Cisco Unified CallManager リリース 4.0 以降(5.x を含む)は、SIP トランクで使用される場合、転送タイプとして TCP および UDP をサポートしています。 ただし、リリース 4.x は SIP コールごとに TCP 接続を 1 つ使用します。リリース 5.x および 6.x 以降では、複数の SIP コールに同一の TCP 接続で対応できます(これは TCP 接続の再利用と呼ばれます)。
次のシスコ製品は TCP をサポートしています。ただし、すべてが TCP の再利用をサポートしているわけではありません。
Cisco Unified CallManager リリース 4.1:TCP 接続の再利用は不可
Cisco Unified CallManager リリース 4.2:TCP 接続の再利用は不可
Cisco Unified CallManager リリース 5.0(2):TCP 接続の再利用が可能
Cisco Unified CallManager リリース 5.1(x):TCP 接続の再利用が可能
Cisco Unified Communications Manager リリース 6.0(x)以降:TCP 接続の再利用が可能
Cisco IOS 12.3(8)T 以降:TCP の再利用が可能
Cisco IOS 12.3(8)T よりも前:TCP の再利用は不可
次の表に、Cisco Unified CallManager と Cisco Unified Communications Manager の各リリース間および IOS ゲートウェイでサポートされる SIP トランク接続を示します。
リリース 6.x 以降のシステムが複数のコールを TCP ベースの SIP トランク経由で 4.x システムに発信した場合、4.x システムはコールを 1 つだけ接続します。 残りのコールは接続されません。4.x システムと 6.x 以降のシステムの間で SIP トランクを使用する場合は、[発信トランスポートタイプ(Outgoing Transport Type)] として UDP を使用するように両方のシステムを設定して、リリース 4.x システムと 6.x 以降のシステムとの間のコールが適切に接続されるようにする必要があります。
UDP を設定するには、 Cisco Unified Communications Manager の管理ページを使用します。
SIP トランク上で Cisco Unified Communications Manager によって送信されるコール設定(INVITE)要求は、SIP プロキシで複製し、複数の宛先に転送することができます(この処理はフォークと呼ばれます)。 Cisco Unified Communications Manager はフォークをサポートしていますが、次の制限事項があります。
Cisco Unified CallManager リリース 4.x は、6 つ以上の宛先からの暫定応答(180 Ringing など)を受け付けません。 応答のあった最初の 5 つ以外の宛先から、成功応答(200 Ok)が返されても受け付けません。
Cisco Unified CallManager リリース 5.x および Cisco Unified Communications Manager リリース 6.x は、21 以上の宛先からの暫定応答(180 Ringing など)を受け付けません。 応答のあった最初の 20 個以外の宛先から、成功応答(200 Ok)が返されても受け付けません。
セッション(メディア)記述を含む暫定応答(183 Session Progress)を受け付けた Cisco Unified CallManager リリース 4.x、Cisco Unified CallManager リリース 5.x、および Cisco Unified Communications Manager リリース 6.x は、同じ宛先からの成功応答(200 Ok)のみ受け付けます。セッション記述が暫定応答から成功応答に変更されても受け付けません。
Cisco Unified CallManager リリース 4.x、Cisco Unified CallManager リリース 5.x、および Cisco Unified Communications Manager リリース 6.x が暫定応答に対して(SIP の PRACK メソッドを使用して)受信応答するように設定されている場合、 Cisco Unified Communications Manager は最初に応答のあった宛先以外からの暫定応答および成功応答を受け付けません。
他の設定オプションは、 Cisco Unified Communications Manager でのダウンストリーム SIP フォークのサポートには影響しません。
Cisco Unified Communications Manager は、PBX、ゲートウェイ、サービス プロバイダーなど、さまざまなエンドポイントに接続できます。 各エンドポイントがそれぞれ別個に SIP プロトコルを実装することにより、固有の相互運用性問題が発生する可能性があります。 SIP の透過および正規化によって、 Cisco Unified Communications Manager はさまざまな PBX およびサービス プロバイダーとシームレスに相互運用できるようになります。 正規化では、 Cisco Unified Communications Manager を経由するときにプロトコル レベルで着信および発信の SIP メッセージを修正できます。 透過を使用すると、 Cisco Unified Communications Manager で、1 つのコール レッグから別のコール レッグにヘッダー、パラメータ、およびコンテンツ本体を渡せるようになります。
メッセージを正規化するために、 Cisco Unified Communications Manager ではシステムにスクリプトを追加または更新し、これらのスクリプトを 1 つまたは複数の SIP トランクまたは SIP 回線に関連付けることができます。 作成する正規化スクリプトによって、既知または不明な SIP ヘッダーまたはコンテンツ本体の内容を保持、削除、または変更できます。 正規化スクリプトは、[トランクの設定(Trunk Configuration)] ウィンドウで SIP トランクに適用できます。また、[SIPプロファイルの設定(SIP Profile Configuration)] ウィンドウで SIP 回線に適用できます。
着信メッセージの場合、正規化は、ネットワークからメッセージを受信した直後に実行されます。 発信メッセージの場合、正規化は、ネットワークにメッセージを送信する直前に実行されます。 正規化は、相手側にあるトランクの接続先デバイスのタイプに関係なく、 Cisco Unified Communications Manager でトランクまたは SIP プロファイルにスクリプトが設定されているすべての SIP トランクまたは SIP 回線に適用されます。 正規化はコール レッグごとに実行されます。相手側のコール レッグが SIP である必要はありません。 コールには、SIP 回線から SIP トランク、SCCP から SIP トランク、MGCP から SIP トランク、H.323 から SIP トランクなどを指定できます。
スクリプト環境(さらにはコンテキスト)は、トランクまたはデバイスがリセットされるまで SIP トランクまたは SIP デバイスの有効期間を超えて保持されます。 スクリプト ライターは Lua モジュールを実装して、メッセージを操作するコールバック関数のセットを提供します(inbound_INVITE、outbound_180_INVITE など)。 この環境によって、SIP メッセージおよび SDP(ある場合)に一連の API 経由でアクセスできるようになります。
シスコのスクリプト環境ではメモリ消費が制御されます。 設定されているメモリ使用量のしきい値をスクリプトが超えた場合、エラーが発生します。
透過とは、1 つのコール レッグから別のコール レッグに情報を渡す機能のことです。 SIP の透過によって、専用ヘッダーなどの着信 SIP メッセージ情報が、 Cisco Unified Communications Manager の片側から相手側に通過できるようになり、これによって、情報が送信 SIP メッセージに含まれるようになります。
透過的なパススルーは、SIP トランクから SIP トランクへのコールにのみ適用されます。
このリリースでは、 Cisco Unified Communications Manager は次のメッセージ タイプの透過をサポートしています。
不明なヘッダー(パススルー)
不明なパラメータ(パススルー)
不明なコンテンツ本体(パススルー)
初期 INVITE、reINVITE、UPDATE、INFO、BYE、18x、200(INVITE、UPDATE)、4/5/6xx
可能な場合には 1 対 1 のトランザクション(つまり、reINVITE が相手側の 1 つの reINVITE を開始する)
透過の詳細については、『Developer Guide for SIP Transparency and Normalization』を参照してください。
また、 Cisco Unified Communications Manager が REFER 要求に応じるのではなく、別のエンドポイントに渡すように REFER の透過を設定することもできます。 REFER の透過は、REFER(ブラインド転送の開始)を送信するエージェントがコールの両側から離れた地域に存在する、コール センター アプリケーションにおいて重要です。 REFER の透過を使用する場合、ローカルの Cisco Unified Communications Manager は、ローカル エージェントが削除されるとコールからドロップします。 REFER の透過を使用しない場合、コール シグナリングは、転送を開始するエージェントの Cisco Unified Communications Manager を経由して接続されたままです。 コールに関連付けられ、MTP デバイスを連続使用するロードは(初期コール時に割り当てられた場合)、転送を開始するエージェントの Cisco Unified Communications Manager とともに残り、新しいコールの通話者間のシグナリング遅延につながります。
REFER の透過は、[トランクの設定(Trunk Configuration)] ウィンドウ( )で 1 つ以上の SIP トランクと、refer-passthrough スクリプトまたはカスタム REFER 透過スクリプトを関連付けることによって有効にします。 [正規化スクリプト(Normalization Script)] グループ ボックスのフィールドを設定する必要があります。
カスタマー スクリプトの作成の詳細については、『Developer Guide for SIP Transparency and Normalization』を参照してください。 Cisco Unified Communications Manager にカスタマー スクリプトをアップロードするには、[SIP正規化スクリプト設定(SIP Normalization Script Configuration)] ウィンドウ( )を使用します。
Cisco Unified Communications Manager では、SIP 正規化のトレースを使用して、次の機能を実行できます。
コールの失敗のデバッグを目的とした、正規化されなかったメッセージと正規化されたメッセージの両方のトレース
スクリプトのデバッグを目的とした、スクリプトによるトレースの作成
システムの保守を目的とした、予期せぬスクリプトの失敗時のトレースの作成
スクリプトおよびコールの失敗をデバッグするには、 Cisco Unified Serviceability の [トレース設定(Trace Configuration)] ウィンドウの [SDI SIPコール処理の有効化(SDI Enable SIP Call Processing)] チェックボックスをオンにすることによって、トレースを有効にします。 このオプションを使用すると、正規化の前後で着信 SIP メッセージおよび発信 SIP メッセージをトレースできます。
![]() (注) |
正規化スクリプトでトレースを有効にしている場合のみ、SIP 正規化によってトレースが作成されます。 |
デバッグを目的としてスクリプトからトレースを生成するには、SIP トランクの場合は [トランクの設定(Trunk Configuration)] ウィンドウ、SIP 回線の場合は [SIPプロファイルの設定(SIP Profile Configuration)] ウィンドウで、Cisco Unified Communications Manager の管理ページの [トレースを有効にする(Enable Trace)] チェックボックスをオンにします。 オンにすると、Lua スクリプト ライターに提供される trace.output API および trace.format API によって SDI トレースが作成されます。
![]() (注) |
スクリプトをデバッグする場合のみトレースを有効にすることをお勧めします。 トレースはパフォーマンスに影響を与えるため、通常の稼働状況では有効にしなでください。 |
SDI トレースを有効にすると、 Cisco Unified Communications Manager によって、さらに次のトレースを含む SDI エラーレベルのトレースが作成されます。
Cisco Unified Communications Manager によって、SIP 正規化スクリプトの使用とエラーが識別されます。つまり、スクリプトが開いたときと閉じたときのタイムスタンプ、およびエラーとリソース警告が発生したときのタイプスタンプが、システムによって保持されます。
SIPNormalizationScriptOpened
SIPNormalizationScriptClosed
SIPNormalizationResourceWarning
SIPNormalizationScriptError
SIPNormalizationAutoResetDisabled
これらのアラームを検索するには、 Cisco Unified Serviceability で CallManager アラーム カタログにアクセスします。
シスコの SIP 正規化パフォーマンス オブジェクトには、スクリプトのステータスやエラーなど、正規化スクリプトのさまざまな面をモニタできるカウンタが含まれています。 パフォーマンス カウンタの動作は、SIP 回線と SIP トランクでわずかに異なります。
SIP 回線では、パフォーマンス カウンタは各スクリプトに 1 セットのみ含まれます。 2 つのエンドポイントが同じスクリプトを共有する場合も、これが該当します。
SIP トランクでは、これらのカウンタのインスタンスは、スクリプトに関連付けられている各デバイスによって新規に作成されます。 デバイスとスクリプトの関連付けを解消するか、または Cisco Unified Communications Manager の管理ページからデバイスを削除すると、これらのカウンタのインスタンスが削除されます。
詳細については、『Cisco Unified Communications Manager Real-Time Monitoring Tool Administration Guide』を参照してください。
どのトランクが特定の正規化スクリプトを使用するかを検索するには、Cisco Unified Communications Manager の管理ページの [SIP正規化スクリプト設定(SIP Normalization Script Configuration)] ウィンドウにある [関連リンク(Related Links)] ドロップダウン リスト ボックスで [依存関係レコード(Dependency Records)] を選択します。 [依存関係レコード要約(Dependency Records Summary)] ウィンドウに、スクリプトを使用しているトランクに関する情報が表示されます。 特定のトランクに関する詳細を検索するには、[トランク(Trunk)] リンクをクリックしてから、[依存関係レコード詳細(Dependency Records Detail)] ウィンドウでトランクの名前をクリックします。 依存関係レコードがシステムで使用可能になっていない場合、[依存関係レコード要約(Dependency Records Summary)] ウィンドウにメッセージが表示されます。
Cisco Unified Communications Manager は、SIP コールに関して、この項で説明する機能をサポートします。
この項では、3 つの基本コールのシナリオについて説明します。 2 つのシナリオでは着信および発信コールについて説明し、もう 1 つのシナリオでは早期メディアの使用(コールの接続または応答の前のメディア接続)について説明します。
任意の Cisco Unified Communications Manager デバイスから SIP デバイスに発信コールを開始できます。 Cisco Unified Communications Manager デバイスには、Foreign Exchange Station(FXS)ゲートウェイに接続された SCCP または SIP IP Phone またはファクス デバイスが含まれます。 たとえば、SCCP IP Phone は、SIP エンドポイントにコールできます。 コールに応答する SIP デバイスが、メディアの確立に対するトリガーとなります。
FXS ゲートウェイに接続された SIP IP Phone またはファクス デバイスを含む SIP ネットワーク上の任意のデバイスが、着信コールを開始できます。 たとえば、SIP エンドポイントは、SCCP IP Phone へのコールを開始できます。 コールに応答する SCCP IP Phone が、メディアの確立に対するトリガーとなります。
PSTN は、早期メディアにインバンドの進行情報(呼び出しトーンまたはビジー信号など)のシグナリングを提供しますが、これは SIP では行われません。 発信側は、コーデック使用状況、IP アドレス、ポート番号などのセッション記述プロトコル(SDP)情報を、発信 INVITE メッセージに含めます。 この応答として、終端側は自身のコーデック、IP アドレスおよびポート番号を 183 Session Progress メッセージで送信し、早期メディアの候補であることを示します。
183 Session Progress 応答は、メッセージ本体にメディア セッションに関する情報が含まれることを示します。 180 Alerting および 183 Session Progress メッセージの両方に、コールへの応答が行われる前に早期メディア セッションの確立を許可する SDP を含めることができます。
早期メディアが、接続の前に SIP エンドポイントに配信される必要がある場合、 Cisco Unified Communications Manager は常に SDP を含む 183 Session Progress メッセージを送信します。 Cisco Unified Communications Manager は SDP を含む 180 Alerting メッセージを生成しませんが、SDP を含む 180 Alerting メッセージの受信はサポートしています。
[SIP プロファイルの設定(SIP Profile Configuration)] ウィンドウには、[180 で早期メディアを無効化(Disable Early Media on 180)] チェックボックスがあります。 ローカル呼び出し音を着信側電話機で再生し、200OK 応答の受信と同時にメディアを接続するには、このチェックボックスをオンにします。
各エンドポイントで使用されている DTMF 方式に基づいて、MTP が必要に応じて動的に割り当てられるようになりました。
次の図は、1 次群速度インターフェイス(PRI)ゲートウェイと通信を行うために、MTP ソフトウェア デバイスが SIP を実行している電話機からのインバンド DTMF ディジットを処理する仕組みを示しています。 RTP ストリームは、ダイナミック ペイロード タイプが示すように、RFC 2833 DTMF を伝送します。
この図では、メディア ストリーミングから開始し、MTP デバイスは DTMF がダイナミック ペイロード タイプであることを通知されています。
SIP エンドポイントと Cisco Unified Communications Manager 間の DTMF リレー コールの説明のように、SIP は、DTMF インバンド ディジットを送信し、 Cisco Unified Communications Manager はアウトバンド ディジットだけをサポートします。 ソフトウェア MTP デバイスは、アウトバンドの DTMF トーンを受信し、インバンドの DTMF トーンを SIP クライアントに生成します。
この図では、メディア ストリーミングから開始し、MTP デバイスには DTMF ダイナミック ペイロード タイプであることが通知されています。
システムは、SCCP エンドポイントが SIP コールで開始するすべての補足サービスをサポートしています。 SCCP エンドポイントは、接続された SIP デバイスに影響を与えることなく Cisco Unified Communications Manager 内部で管理されます。 当初の接続情報に加えられる変更は、Remote-Party-ID ヘッダーを使用する re-INVITE または UPDATE メッセージで更新されます。 Remote-Party-ID ヘッダーの詳細については、『SIP Extensions for Caller Identity and Privacy』を参照してください。
ブラインド転送時の呼び出し音では、ブラインド転送について説明します。ブラインド転送は、 Cisco Unified Communications Manager がメディア アナウンスを提供する必要があるため、補足サービスと同様に固有の動作になります。
SCCP が開始するブラインド転送では、コールが接続されてから Cisco Unified Communications Manager がトーンまたは呼び出し音を生成する必要があります。 つまり、 Cisco Unified Communications Manager は、ブラインド転送のメディア アナウンスを提供します。
ブラインド転送は、転送のターゲットがコールに応答する前に、転送側の電話機が発信者を宛先の回線に接続する際に行われます。 ブラインド転送は、転送側の 1 つが呼び出し音の鳴っている電話機(呼び出し音が受信されている)に発信者を接続するか、または発信者を第三者に接続する前に第三者と話をする、打診転送(在席転送)とは異なります。
SCCP IP Phone が開始するブラインド転送は、最初に接続された SIP デバイス ユーザへの呼び出し音を許可します。 Cisco Unified Communications Manager は、呼び出し音を実行するために、MTP デバイスとともに配置されることがあるアナンシエータ ソフトウェア デバイスを使用します。
アナンシエータを使用すると、 Cisco Unified Communications Manager は、SCCP IP Phone、ゲートウェイ、およびその他の IP テレフォニー デバイスに対して事前定義されたトーンおよびアナウンスを再生できます。 これらの事前定義されたトーンおよびアナウンスは、ユーザにコール ステータスに関する詳細情報を提供します。
Cisco Unified Communications Manager は、SIP が開始するコール転送をサポートし、REFER 要求または Replaces ヘッダーを含む INVITE メッセージを受信します。
Cisco Unified Communications Manager は、SIP デバイスまたは Cisco Unified Communications Manager デバイスが開始するコール保留と取得をサポートします。 たとえば、SCCP IP Phone のユーザが別のユーザが保留にしているコールを取得する場合、 Cisco Unified Communications Manager は re-INVITE メッセージを SIP プロキシに送信します。 re-INVITE メッセージには、現在の接続先を反映させるために、更新された Remote-Party-ID 情報が含まれています。 Cisco Unified Communications Manager が最初にコールを開始した場合、Remote-Party-ID ヘッダーの Party フィールドには発信側が設定されます。そうでない場合は着信側が設定されます。 Party フィールド パラメータの詳細については、拡張されたコール識別サービスを参照してください。
Cisco Unified Communications Manager は、SIP デバイスまたは Cisco Unified Communications Manager デバイスが開始する自動転送をサポートします。 SIP デバイスが自動転送のリダイレクションを要求すると、 Cisco Unified Communications Manager が要求を処理します。 Cisco Unified Communications Manager が開始する自動転送には、SIP のリダイレクション メッセージは使用されません。 Cisco Unified Communications Manager は、内部でリダイレクションを処理し、Remote-Party-ID ヘッダーを介して発信側の SIP エンドポイントに接続先の情報を伝送します。
ここでは、 Cisco Unified Communications Manager の次の SIP 識別サービスおよび Cisco Unified Communications Manager が SIP にこれらの識別サービスを伝送する方法について説明します。
Cisco Unified Communications Manager では、これらの識別サービスを提供するための柔軟な設定オプションにより、コールごとの設定や、SIP シグナリング インターフェイスごとの静的な事前設定を行うことができます。
Cisco Unified Communications Manager は、 Cisco Unified Communications Manager からの初期 INVITE メッセージの From ヘッダーおよび Remote-Party-ID ヘッダーに発呼者回線(または番号)および発呼者名の表示情報を含めます。 From ヘッダーのフィールドは、要求の発信側を示します。 Cisco Unified Communications Manager は、18x、200、および re-INVITE メッセージの Remote-Party-ID ヘッダーを使用して、接続先の名前および識別情報を伝送します。 Remote-Party-ID ヘッダーには、発信者 ID およびプライバシーの詳細も含まれます。 発信者 ID サービスの場合、 Cisco Unified Communications Manager は、Remote-Party-ID ヘッダーの Party フィールドに発信側を設定します。
![]() (注) |
Remote-Party-ID ヘッダーの詳細については、『Cisco IOS SIP Configuration Guide』を参照してください。 |
Bob Jones(外部電話番号=8005550100)が SIP シグナリング インターフェイスにダイヤルアウトします。From ヘッダーおよび Remote-Party-ID ヘッダーには、次の内容が含まれます。
From: "Bob Jones" <sip:8005550100@localhost> Remote-Party-ID: "Bob Jones"<8005550100@localhost; user=phone>; party=calling;screen=no;privacy=off
発呼者回線(または番号)の制限および発呼者名の制限設定は、SIP シグナリング インターフェイス レベルまたはコール単位で行われます。 SIP トランク レベルの設定は、コール単位の設定より優先されます。 コールごとに設定するには、『 Cisco Unified Communications Manager アドミニストレーション ガイド』の拡張されたコール識別サービスを参照してください。
また、発呼者回線および発呼者名の制限は、それぞれ個別に設定できます。 たとえば、番号だけを制限し、名前の表示を許可するように選択できます。
発呼者名を制限した場合、 Cisco Unified Communications Manager は、From ヘッダー内の発呼者名を設定可能な文字列に設定します。 Cisco Unified Communications Manager によって、Remote-Party-ID ヘッダーの表示フィールドには実際の名前が含まれるように設定されますが、Privacy フィールドは次のように name に設定されます。
From: "Anonymous" <sip:8005550100@localhost> Remote-Party-ID: "Bob Jones"<sip:9728135001@localhost; ;user=phone>; party=calling;screen=no;privacy=name
発信番号を制限した場合、 Cisco Unified Communications Manager は From ヘッダーの発呼者回線を省略します。ただし、 Cisco Unified Communications Manager は、Remote-Party-ID ヘッダーには発呼者回線を含め、Privacy フィールドを privacy=uri に設定します。
From: "Bob Jones" <sip:@localhost> Remote-Party-ID: "Bob Jones"<sip:8005550100@localhost; ;user=phone>; party=calling;screen=no;privacy=uri
発信者の名前および番号を制限した場合、 Cisco Unified Communications Manager は、Remote-Party-ID ヘッダーの Privacy フィールドを privacy=full に設定します。
From: "Anonymous" <sip:localhost> Remote-Party-ID: "Bob Jones"<sip:8005550100@localhost;user=phone>; party=calling;screen=no;privacy=full
Cisco Unified Communications Manager の SIP 機能では、発信 SIP コールに発呼側 ID を 2 セット利用でき、SIP ヘッダーに基づいて着信 SIP コールに CLI(発呼者回線 ID)を選択できます。
スイッチボード データを SIP トランク上で設定している場合、[元の発信者ID DNと発信者名をIDヘッダーに維持する(Maintain Original Caller ID DN and Caller Name in Identity Headers)] をオンにすると、発信 SIP メッセージの元の発信者 ID は SIP ヘッダー内のデータによって上書きされません。
[元の発信者ID DNと発信者名をIDヘッダーに維持する(Maintain Original Caller ID DN and Caller Name in Identity Headers)] を SIP トランク上で設定すると、すべての発信 SIP コールに影響します。 この機能は、SIP プロファイルを使用して SIP 回線デバイスのグループにも設定できます。 [SIPプロファイル(SIP Profile)] ページの電話機セクションに、SIP トランク上でスイッチボード データをミラーするために、[発信者ID DN(Caller ID DN)] および [発信者名(Caller Name)] という 2 つのテキストボックスが新たに追加されています。 [SIPプロファイル(SIP Profile)] ページのトランク セクションに、[設定済み回線デバイス発信者情報のパススルーを許可(Allow Passthrough of Configured Line Device Caller Information)] というチェックボックスが新たに追加されています。
Cisco Unified Communications Manager では、SIP インターフェイスでの ID の選択、表示、および制限を拡張できます。 対応する SIP 電話機を制御するために、SIP トランクと SIP プロファイルの表示に使用する設定フィールドを新たに追加することで、この新しい機能を提供しています。
発信 ID 機能の導入により、着信 SIP コールで発呼側 ID を 2 セット利用できるようになりました。 コール処理用の ID 選択に役立つよう、着信 CLI(発呼者回線 ID)が導入されています。 選択は、[発呼者回線IDの表示(Calling Line Identification Presentation)] の新しいリスト ボックスを使用して制御します。
一部のネットワークでは、保持された 2 セットの ID として、ネットワーク指定の ID(信頼済み)およびユーザ指定の ID(信頼済みでない)を利用できます。 SIP コールでは、P-Asserted-Identity(PAI)、P-Preferred-Identity(PPI)、および Remote-Party-ID(RPID)が含まれた ID ヘッダーがネットワーク指定の ID を伝送し、FROM ヘッダーがユーザ指定の ID を伝送します。 Cisco Unified Communications Manager の以前のリリースでは、発信コールに ID を 1 セットのみ利用できました。 ID ヘッダーと FROM ヘッダーの ID はまったく同じであり、ネットワーク指定の ID とユーザ指定の ID を区別できませんでした。 一般に、管理者は、電話番号(DN)と表示名によって各ユーザ デバイスを設定します。 この DN からの発信コールでは、ID ヘッダーと FROM ヘッダーの両方で電話番号と表示名が伝送されます。 管理者は、SIP トランク上に別の ID を設定することもできます。 この ID(スイッチボード ID とも呼ばれます)は、個々の発信者の ID を隠すために使用し、 発信コールの [SIPトランク(SIP Trunk)] の [発信者情報(Caller Information)]セクションで設定できます。 設定には、[発信者ID DN(Caller ID DN)] と [発信者名(Caller Name)] の 2 つのフィールドを使用します。 この設定が有効になっている場合、発信者の元の電話番号と表示名が上書きされます。
Cisco Unified Communications Manager で用意されている設定を使用すると、管理者は、スイッチボード ID と元の発信者 ID の両方を有効にできます。 スイッチボード ID は FROM ヘッダーで伝送され、元の発信者 ID は ID ヘッダーで伝送されます。 この設定を各 SIP トランクまたは SIP ユーザ デバイスで有効にできます。
ネットワーク内からの着信コールの場合、Cisco Unified Communications Manager では、ID ヘッダーで伝送されるネットワーク指定の ID または FROM ヘッダーで伝送されるユーザ指定の ID を受け入れるための設定を利用できます。 Cisco Unified Communications Manager には、コールごとに 1 セットの ID が保持されます。
![]() (注) |
PAI、PPI および RPID という 3 つの異なる ID ヘッダーがサポートされます。 [SIPトランク(SIP trunk)] ページの [コールルーティング情報(Call Routing Information)] の設定に応じて、発信要求または発信応答にこれらのヘッダーが 1 つまたは 2 つ表示されることがあります。 |
元の発信者 ID を持つ発信コールが、[コールルーティング情報(Call Routing Information)] にデフォルトで設定されます。 デフォルトでは、[リモートパーティID(Remote-Party-Id)] チェックボックスと [アサート済ID(Asserted-Identity)] チェックボックスがオンになり、[アサート済タイプ(Asserted-Type)] フィールドと [SIPプライバシ(SIP Privacy)] フィールドが [デフォルト(Default)] に設定されます。
スイッチボード ID を持つ発信コールを設定するには、[SIPトランク(SIP trunk)] 設定ページの [コール(Calls)] セクションにある [発信者ID DN(Caller ID DN)] と [発信者名(Caller Name)] を設定します。 これらのフィールドで、スイッチボード ID が提供されて発信者の ID が非表示になります。
Cisco Unified Communications Manager デバイスから発信されるコールの場合、ID ヘッダーはデバイスの回線 ID に設定され、From ヘッダーは ID ヘッダーと同じ値かスイッチボード情報のいずれかに設定されます。 これは、プロビジョニング可能であり、Cisco Unified Communications Manager を変更する必要はありません。 [SIPトランク(SIP trunk)] 設定ページの新しいチェックボックス [元の発信者ID DNと発信者名をIDヘッダーに維持する(Maintain Original Caller ID DN and Caller Name in Identity Headers)] を使用して、発信 SIP メッセージの表示名と番号を制御できます。 発信 SIP メッセージに対して有効になっている場合、[発信者ID DN(Caller ID DN)] の設定値によって電話番号は上書きされず、[発信者名(Caller Name)] の設定値によって発信 ID ヘッダーの発信者名は上書きされません。
Cisco Unified Communications Manager は、接続側回線および名前の識別を補足サービスとして使用し、発呼側に接続先の番号と名前を通知します。 From ヘッダーのフィールドは、要求の発信側を示します。 Cisco Unified Communications Manager は、18x、200、および re-INVITE メッセージの Remote-Party-ID ヘッダーを使用して、接続側の情報を伝送します。 Cisco Unified Communications Manager は、Remote-Party-ID ヘッダーの Party フィールドに着信側を設定します。
Cisco Unified Communications Manager は、宛先アドレスが 800555 の INVITE メッセージを受信します。 Cisco Unified Communications Manager は、次のように接続先の名前を 18x および 200 メッセージに含めます。
Remote-Party-ID: "Bob Jones"<98005550100@localhost; user=phone>;
party=called;screen=no;privacy=off
SIP トランク レベルまたはコール単位で接続側回線(または番号)および名前の制限を設定できます。 SIP トランク レベルの設定は、コール単位の設定より優先されます。
Cisco Unified Communications Manager は、Remote-Party-ID ヘッダーの表示フィールドには実際の名前が含まれるように設定しますが、Privacy フィールドを privacy=name に設定します。
Remote-Party-ID: "Bob Jones"<8005550100@localhost; user=phone>;
party=called;screen=no;privacy=name
接続側の番号を制限した場合、 Cisco Unified Communications Manager は、Remote-Party-ID ヘッダーには接続側の番号を含めますが、Privacy フィールドを privacy=uri に設定します。
Remote-Party-ID: "Bob Jones"<8005550100@localhost; user=phone>;
party=called;screen=no;privacy=uri
接続側の名前と番号を制限した場合、 Cisco Unified Communications Manager は、Remote-Party-ID ヘッダーの Privacy フィールドを privacy=full に設定します。
Remote-Party-ID: "Bob Jones"<8005550100@localhost; user=phone>;
party=called;screen=no;privacy=full
Cisco Unified Communications Manager は、初期 INVITE メッセージの SIP Diversion ヘッダーを使用して、利用可能な RDNIS 情報を伝送します。
次のシナリオは、[SIPプロファイルの設定(SIP Profile Configuration)] ウィンドウの [アプリケーションによるリダイレクト(Redirect by Application)] チェックボックスをオフにした場合の動作です。 この設定では、SIP ネットワークからのリダイレクションは SIP スタック レベルで処理され、システムはリダイレクション要求をすべて受け取り、リダイレクション応答の Contact ヘッダー内のアドレスへ転送します。 コールは、リダイレクション応答を受信したトランクに自動的に転送されます。 コールのリダイレクト方法を処理または制限する追加のルーティング ロジックは適用されていません。 たとえば、発信 INVITE への 3xx 応答内のリダイレクション接続先が Cisco Unified Communications Manager に登録済みの電話機で、スタックがリダイレクションを処理している場合、コールは Cisco Unified Communications Manager 電話機へ直接ルーティングされずに、同じトランクへリダイレクトして戻されていました。 制限された電話番号(国際電話番号など)へリダイレクトされると、スタック レベルでのリダイレクション処理により、コールがブロックされずにルーティングされます。
[アプリケーションによるリダイレクト(Redirect by Application)] チェックボックスがオンの場合、Cisco Unified Communications Manager は、ルーティング エンジン経由で Contact ヘッダーを渡し、ルーティング ロジックを使用してリダイレクション要求を Contact ヘッダー内のアドレスに転送します。 SIP 要求では、Contact ヘッダーのホスト部分がローカル Unified CM でない場合、SIP ルート パターンで Contact ヘッダーのホスト部分を発信トランクにマッピングする必要があります。そうしない場合、Unified CM はコールをルーティングできません。
管理者は、[アプリケーションによるリダイレクト(Redirect by Application)] チェックボックスで次の処理を実行できます。
特定のコーリング サーチ スペースを、3xx 応答内で受信したリダイレクト接続先に適用する。
コールが正しくルーティングされるよう、リダイレクト接続先に番号分析を適用する。
サービス パラメータで設定できるリダイレクション(再帰リダイレクション)の番号を制限することで、DOS 攻撃を防止する。
リダイレクションの実行中に、別の機能を起動できるようにする。
Unified CM による SIP 要求のルーティング方法の詳細については、『Cisco Unified Communications System SRND』の「Dial Plan」の章の「Routing of SIP Requests in Unified CM」を参照してください。
G. Clear(クリア チャネル)コーデックを使用すると、SIP トランクおよび Cisco Unified Communications Manager を使用する音声ネットワークを通じて、Digital Signal-0(DS-0)データ回線のタンデム スイッチングを実現できます。 G.Clear コーデックは、G.711 コーデックとほぼ同等の 64 kb/s の帯域幅(IP パケットのオーバーヘッドは含まず)を使用します。 Cisco Unified Communications Manager は、音声コールのコーデックを選択し、メディア テーブル内の G.711 mulaw および G.711 alaw コーデックよりも G. Clear コーデックを優先します。
G.Clear コーデックまたは G.729 コーデックが必要となるのは、リージョンの内部です。リモート リージョンへのコールには、他の低帯域幅コーデックを使用します。 G.729 コーデックは音声用に最適化されており、使用帯域幅が G. Clear コーデックよりも大幅に小さくなります。 G.Clear コーデックは、低帯域幅のリージョン内で実行することを明示的に許可することのみを目的としたオプションです。
G. Clear コーデックのコールでは、IP パケットのヘッダーに個別の Differentiated Services Code Point(DSCP)値が必要です。 これは従来の音声コーデックおよびビデオ コールと異なり、MLPP 優先順位によって一意にタグ付けされる必要があります。 これらの機能には、サービス パラメータが適用されます。
G. Clear コーデックのコールは、RTP ダイナミック ペイロード タイプ 125 を使用して、ゲートウェイを通じて一貫性が維持されます。 このダイナミック ペイロード タイプは、 Cisco Unified Communications Manager を使用して静的に割り当てられます。
SIP トランクで G. Clear コーデックがサポートされるため、クラスタ間の操作が可能になります。 このコーデックは、SIP Session Description Protocol(SDP)メッセージでサポートされるメディア タイプとしてネゴシエートされ、RTP ペイロード タイプ 125 に静的に符号化されます。
![]() (注) |
G. Clear コーデックは、メディア ターミネーション ポイントではサポートされません。 |
別の T1 PRI トランク上の VoIP ネットワークから発信される着信 ISDN データ コール(制限デジタル情報および無制限デジタル情報)に対する ISDN ベアラ機能は、サポートされています。
次の図に、G.Clear コーデックを有効にした SIP トランクの一般的な配置を示します。
2 つの SIP サービス パラメータ、SIP Route Class Naming Authority および SIP Clear Channel Data Route Class Label は、SIP トランクで G. Clear コーデックを有効化します。 SIP Route Class Naming Authority パラメータは、SIP シグナリングで使用される、ルート クラスを表すラベルの名前付け機関および名前付けコンテキストを表します。 この値には、名前付け機関が所有するドメインの名前を指定します。 デフォルトは cisco.com です。
特定のルート クラス値をシグナリングするため、 Cisco Unified Communications Manager は、ドメイン名と適切なルート クラス ラベル(SIP Clear Channel Data Route Class Label サービス パラメータで定義されたもの)を SIP シグナリングに組み込みます。
SIP Clear Channel Data Route Class Label は、SIP シグナリングにおけるクリア チャネル データのルート クラスを表します。 このパラメータと SIP Route Class Naming Authority パラメータによって、SIP クリア チャネル データのルート クラス値を表す完全なシグナリング構文が作成されます。 デフォルトは ccdata です。
ルート クラス シグナリングが有用となるのは、ルート クラスおよびクリア チャネル データ ルート クラスに基づいてルーティング決定を行う TDM ネットワークとインターワーキングする場合です。 このパラメータで指定されたデフォルト ドメイン名は、シスコ スイッチ間の相互対話に適用されます。 このパラメータは、ベンダー(または配置)固有の要件に応じて変更できます。 遠端のスイッチは、このパラメータで設定されたものと同一の値を受信します。
G. Clear コーデックを使用する H.323 ICT は、サポートされていません。
G. Clear コーデックを使用する Skinny Client Control Protocol(SCCP)は、サポートされていません。
G. Clear コーデックを使用する T1 および E1 CAS は、サポートされていません。
G. Clear コーデックを使用する RSVP は、サポートされていません。
E1 トランクでの MLPP はサポートされていません。
発信 G. Clear コーデック コールのエコー キャンセレーションおよびゼロ抑制は無効になります。
ITU H.244 で定義されている個々の DS-0 回線のボンディングは、端末装置が実行します。このため、VoIP ネットワークを通過し、個々の DS-0 回線を整列するためのフレームはサポートされていません。
Cisco Unified Communications Manager の [ファスト スタート(Fast Start)] および [メディア ターミネーション ポイントが必須(Media Termination Point Required)] オプションは、G. Clear が有効化されている状態では機能しません。
G.Clear コーデックを使用する DTMF シグナリングは、サポートされていません。
![]() (注) |
Cisco Unified Communications Manager は、G.Clear がコールのコーデックに選択されているかどうかに関係なく、G.Clear がコーデックのリストにアドバタイズされているすべてのコールで DTMF の設定値を無視します。 |
Cisco Unified Communications Manager は、G.Clear データ コール(クリア チャネル)に対する制限付き早期オファーをサポートしています。 G.Clear コールに対する早期オファー機能により、メディア ターミネーション ポイントを使用せずにデータ コールをネゴシエートする早期オファーを実行可能なサードパーティの SIP ユーザ エージェントをサポートできます。 MTP は、G.Clear コーデックをサポートしていません。
SIP デバイスに対して、[メディアターミネーションポイントが必須(Media Termination Point Required)] と [G.Clearコールに対する早期オファー(Early Offer for G.Clear Calls)] の両方を有効にすると、G.Clear コーデックがオファー内に存在する場合でも、MTP が割り当てられません。 MTP が割り当てられるのは、コールが G.Clear ではなく、MTP が必要な場合だけです。
G.Clear コールに対する早期オファー機能は、標準ベースの G.Clear(CLEARMODE)と、CCD、G.nX64、X-CCD などのシスコ独自の Session Description Protocol(SDP)の両方をサポートしています。
[G.Clearコールに対する早期オファー(Early Offer for G.Clear Calls)] を有効または無効にするには、 Cisco Unified Communications Manager の管理ページの [SIPプロファイルの設定(SIP Profile Configuration)] ウィンドウで次のいずれかのオプションを選択します。
Cisco Unified Communications Manager の管理は、SIP トランクで Multilevel Precedence and Preemption(MLPP)を使用する Voice over Secured IP(VoSIP)ネットワークをサポートしています。 Resource Priority ヘッダーおよび SIP の Reason ヘッダーがメッセージに追加されます。 SIP シグナリングに関係するリソースは、 Cisco Unified Communications Manager によって優先順位が設定されます。これは、緊急の場合または輻輳が発生した場合に、これらのリソースを解放してネットワークが機能できるようにするためです。 リソース プライオリティ ネームスペース ネットワーク ドメインおよびリソース プライオリティ ネームスペース リストを設定することで、必要に応じて優先順位設定を有効にできます。
SIP シグナリングのリソース プライオリティ ネームスペース ネットワーク ドメインは、レガシー TDM MLPP ネットワークで使用される ISDN プレシデンス情報要素(IE)および ISDN ユーザ パート(ISUP)プレシデンス パラメータと似ています。
リソース プライオリティ ネームスペース ネットワーク ドメインは発信コールに含まれており、コールを SIP トランクに転送するためのトランスレーション パターンまたはルート パターンに基づいています。 次のメッセージには、設定済みのリソース プライオリティ ネームスペース ネットワーク ドメインが含まれています。
着信コールの場合、このネットワーク ドメインが許容ネットワーク ドメインのリストと比較されます。 着信コールのネットワーク ドメインが検証されるのは、コールが Cisco Unified Communications Manager エンドポイントで終端する場合のみです。 他のコール タイプの場合、このネットワーク ドメインは、いずれもローカル設定と照合して検証されません。 許容されるネットワーク ドメインの設定は、SIP プロファイルに追加されている必要があります。
セキュア V.150.1 のサポートは、SIP トランクおよびクラスタ間 SIP トランクを介した IP Secure Terminal Equipment(STE)とレガシー(BRI またはアナログ)STE 間での Modem over IP(MoIP)通信に基づいていました。 SIP トランクは、発信コールの Session Description Protocol(SDP)情報を転送し、着信コールの MoIP SDP 情報が受信されたときは Cisco Unified Communications Manager に通知します。 デバイスは、SIP を使用して V.150.1 セキュア コールをネゴシエートすることで、クラスタ間でコールを発信できます。
![]() (注) |
SIP トランクでの MoIP については、設定は不要です。 |
G.729a および G.729b は、SIP トランクを通じて開始されるコールに使用可能な、低帯域幅のコーデックです。 この機能を必要とするのは、遅延メディア コールをサポートせず、G.711 などの高帯域幅コーデックを使用しないエンドポイントであることに注意してください。
早期提供コールの場合は、MTP が事前に割り当てられている必要があるため、この機能を使用するには、外部の MTP デバイスまたはトランスコーダ デバイスを設定する必要があります。 ソフトウェア MTP は、SIP トランクでの G.729 をサポートしていません。
この機能は、4 つの G.729 コーデック(G.729、G.729a、G.729b、および G.729ab)をすべてサポートしていますが、システムでは、G.729 と G.729a、および G.729b と G.729ab を区別できません。 したがって、これらのコーデックを SIP トランクに対して設定するためのオプションは、 Cisco Unified Communications Manager の管理ページでは 2 つのみ提供されます(G729/G729a と G729b/G729ab)。
SIP トランクに G.729 コーデックが適用されるのは発信コールのみで、着信コールには影響しません。 コール中に、システムがコーデックを G.729 から他のコーデックに切り替えることはできません。
T.38 標準は、IP ネットワークを使用した Group 3 ファクシミリ(ファクス)通信のリアルタイム転送のための ITU-T 勧告に基づいています。 Cisco Unified Communications Manager には、Microsoft Exchange との T.38 相互運用が実装されており、コールをオーディオから T.38 ファクスに切り替えることができます。
次に、Microsoft Exchange Server がファクス機へのコールを確立する手順を示します。
Cisco Unified Communications Manager の管理ページを使用して、T.38 ファクス通信をサポートする SIP プロファイルを設定できます。 このプロファイルは、SIP トランクにのみ適用され、SIP を実行する電話機およびエンドポイントには適用されません。
Cisco Unified Communications Manager では、IP ネットワーク上の SIP トランクを介して、別の Cisco Unified Communications Manager または QSIG-SIP ゲートウェイに向かう QSIG メッセージと SIP メッセージ間のインターワーキングをサポートし、QSIG コールと、メッセージ受信のインジケータ(MWI)、コール転送、自動転送、折り返し、Call Completion、パス変換、ID サービスなどの QSIG 機能をサポートします。 これらの機能を受け入れるために、 Cisco Unified Communications Manager では、トンネル化プロトコルとして QSIG を使用する SIP トランクを設定できます。 SIP トランクの設定の詳細については、 『Cisco Unified Communications Manager アドミニストレーション ガイド』のSIP トランクの G. Clear コーデックのサポートを参照してください。
![]() (注) |
SIP ゲートウェイから着信した Remote Party ID(RPID)ヘッダーによって QSIG コンテンツが干渉を受け、それにより折り返し機能で予期しない動作が発生する場合があります。 QSIG コンテンツへの干渉を防ぐには、SIP ゲートウェイで RPID ヘッダーを無効にします。 |
トランク サービス タイプとして Cisco Intercompany Media Engine(IME)を選択して SIP トランクを作成する場合、[トンネル化プロトコル(Tunneled Protocol)] フィールドのデフォルトは [QSIG] になります。 Cisco IME トランクで QSIG 機能を動作させるには、トンネル化プロトコルを QSIG にする必要があります。
![]() (注) |
Cisco Unified Communications Manager は、Cisco IME トランクでの折り返しについては、接続維持モードのみをサポートしています。 |
SIP PUBLISH は、IP Phone のプレゼンス情報を Cisco Unified Communications Manager リリース 6.0 以降から Cisco Unified Presence リリース 6.0 以降に SIP トランク経由で送信するための最適なメカニズムを提供します。このメカニズムによって、パフォーマンスが向上します。 また、サイレントやモビリティなどの回線ごとのプレゼンス情報も提供します。 サポートされるのは発信 PUBLISH だけです ( Cisco Unified Communications Manager リリース 6.0 以降は、プレゼンスに関して Cisco Unified Presence リリース 1.0 と通信するときに SUBSCRIBE/NOTIFY を使用します)。
PUBLISH は、イベント状態を発行するための SIP メソッドです。 イベント状態をユーザ エージェントから発行するためのフレームワークは、RFC 3903 で規定されています。発行先となるのは、このイベント状態を集約し、関係するパーティに SIP Events フレームワークを通じて配信するエンティティです。 RFC 3903 に記述されているメカニズムを拡張すると、適切なイベント パッケージで処理される任意のイベント状態を発行することができます。
また、RFC 3903 は、プレゼンス ユーザ エージェントによってプレゼンス集約側にプレゼンス状態を発行するための、このフレームワークの厳格な使用方法も定義しています。
SIP トランクは、 Cisco Unified Communications Manager に登録されている電話機のプレゼンス情報を Cisco Unified Presence と連携して提供します。 リリース 5.0 では、 Cisco Unified Presence は、プレゼンス情報を Cisco Unified CallManager から SIP 登録メカニズムを通じて取得していました。
Cisco Unified Communications Manager から Cisco Unified Presence への相互対話は、SIP 登録メカニズムが使用されている場合は正常に機能しますが、このメカニズムはパフォーマンス低下の原因になります。 Cisco Unified Communications Manager と Cisco Unified Presence の両方で、監視対象となる電話機ごとに、それぞれ個別の登録ダイアログが維持される必要があります。 さらに、1 台の電話機を 2 人のユーザが監視し、各ユーザの監視ルールが異なっている場合、 Cisco Unified Presence は、同じ番号に関する 2 つの SUBSCRIBE 要求を Cisco Unified Communications Manager SIP トランクに発行します。
Cisco Unified Communications Manager リリース 6.0 以降では、SIP トランクは、PUBLISH を Cisco Unified Presence とのプレゼンス相互対話のメカニズムとして使用できます。 Cisco Unified Communications Manager はイベント発行エージェント(EPA)として動作し、管理対象の電話機のプレゼンス情報を発行します。 Cisco Unified Presence はイベント状態集約システム(ESC)として動作し、発行されたプレゼンス情報を受信および集約して、監視者の電話機の表示を更新します。
次の図に、 Cisco Unified Communications Manager、 Cisco Unified Presence、および Cisco Unified IP Phone がどのように連携して動作するかを示します。
Cisco Unified Communications Manager がすべての IP Phone を管理し、 Cisco Unified Communications Manager が SIP または SCCP インターフェイスを使用して電話機を制御します。
IP Phone と Cisco Unified Presence の間には HTTP インターフェイスも存在します。 このインターフェイスは、電話機の画面を更新するために Cisco Unified Presence で使用されます。 また、ユーザのログイン/ログアウト アクティビティを検出するために、 Cisco Unified Presence でも使用されます。
SIP トランク インターフェイスは、プレゼンス データを Cisco Unified Communications Manager と Cisco Unified Presence の間で交換するために使用されます。
Cisco Unified Communications Manager の管理ページで SIP トランクを PUBLISH 用に設定するときは、次の設定のヒントを参考にしてください。
SIP の [トランクの設定(Trunk Configuration)] ウィンドウで、 Cisco Unified Presence(宛先アドレス)にアクセスするように SIP トランクを設定します。
![]() ヒント |
マルチノード クラスタでの分散処理のパフォーマンスを最大限まで高めるには、デフォルトのデバイス プールを使用するように SIP トランクを設定することをお勧めします。 |
Cisco CallManager サービスの [サービスパラメータ設定(Service Parameters Configuration)] ウィンドウにある [CUP PUBLISH Trunk] フィールドで、設定済みの SIP トランクを選択します。
Cisco Unified Presence エンド ユーザを設定し( )、ライセンス ユニットをユーザに割り当てます( )。
エンド ユーザをライン アピアランスに関連付けます( Cisco Unified Presence へのアクセスに使用する DN をクリックします。 [エンドユーザの関連付け(Associate End Users)] ボタンをクリックします。 [ユーザの検索/一覧表示(Find and List Users)] ウィンドウで、 Cisco Unified Presence にアクセスするエンド ユーザを選択します。
)。 [電話の設定(Phone Configuration)] ウィンドウで、ユーザが![]() (注) |
1 つのライン アピアランスを 5 人までのエンド ユーザに関連付けることができます。 |
SIP Trunk PUBLISH での DND サポート:DND は、リリース 6.0 以降ではデバイス単位で適用されます。このため、デバイスが DND 状態に移行した場合、このデバイスに関連付けられている Cisco Unified Presence 対応のすべてのライン アピアランスが発行される可能性があります。 デバイスが DND 状態に移行した場合は、DND に加えてビジー/アイドル ステータスも一緒に発行されるため、 Cisco Unified Presence で柔軟にデータを処理することができます。
共有回線:電話機 A と電話機 B が DN 1000 を共有している場合、ユーザが電話機 A の受話器を取って回線 1000 上でコールを発信すると、 Cisco Unified Communications Manager は回線 1000 がビジーであることを Cisco Unified Presence に通知します。 この情報によって、監視者は DN 1000 のすべての回線がビジーになっていると誤解します。 電話機 B の回線 1000 はアイドルのままであるため、これは正確な情報を表していません。 Cisco Unified Communications Manager は、電話機 A の回線 1000 がビジーであることを Cisco Unified Presence に通知します。 リリース 6.0 以降では、 Cisco Unified Communications Manager はライン アピアランス別に発行を行います。 システムは、ライン アピアランスを(DN とデバイスの)ペアと見なします。
複数パーティション: Cisco Unified Communications Manager は DN のプレゼンス ステータスを発行し、DN が関連付けられているパーティションも示します。
ユーザ名の関連付け:共有回線と複数パーティションがサポートされている場合、 Cisco Unified Presence は、電話機ごとに 1 つの DN という前提で動作できません。また、 Cisco Unified Communications Manager システム全体にわたって 1 つのパーティションという前提で動作することもできません。 リリース 6.0 以降では、ライン アピアランスをエンド ユーザに関連付けることができるため、ライン アピアランスに関連付けられているエンド ユーザに代わって SIP トランクがそのライン アピアランスのステータスを発行します。つまり、このステータスを使用して Cisco Unified Presence 対応の回線を識別できます。 ライン アピアランスがエンド ユーザに関連付けられている場合、システムは Cisco Unified Presence 対応であると見なされます。したがって、そのライン アピアランスのプレゼンス情報が発行されます。
PUBLISH の設定には、次の Cisco CallManager サービス パラメータが使用されます。
Cisco Unified Serviceability は、PUBLISH に関連する次のパフォーマンス カウンタを収集し、表示します。
Cisco Unified CallManager リリース 5.x には次のパフォーマンス カウンタがありますが、これらの値は PUBLISH 機能の影響を受けます。
RFC 3903 では、アクセス制御、サービス拒絶攻撃、リプレイ アタック、および中間者攻撃などの問題に対処するため、TLS とダイジェスト認証の使用が推奨されています。 Cisco Unified Communications Manager および Cisco Unified Presence は TLS とダイジェスト認証をサポートしているため、リリース 6.0 での変更点はありません。 管理者は、 Cisco Unified Communications Manager および Cisco Unified Presence で TLS とダイジェスト認証を設定し、有効にすることができます。 また、IPSec を TLS の代替手段として使用することもできます。
Cisco Unified Presence ユーザを Cisco Unified Communications Manager に移行する場合は、次の BAT ツールが役立ちます。
BAT では、 Cisco Unified Communications Manager を 5.x から 6.0 以降にアップグレードした後に、すべての Cisco Unified Presence ライセンス取得済みユーザ、それらのユーザのプライマリ内線番号、およびそれらのユーザに関連付けられるデバイス ライン アピアランスを検証するためのツールが提供されます。 このツールが必要になるのは、(すべてのバックエンド登録が削除され、 Cisco Unified Presence ユーザの新しいライン アピアランスベースのプレゼンスを使用できるようにする必要があるため) Cisco Unified Presence のアップグレードまたは移行中に Cisco Unified Communications Manager に接続するときです。 移行を実行するため、BAT はエクスポート機能と更新機能を使用します。 エクスポート csv の形式は、User ID、Device、Directory Number、および Partition です。 最後の 3 つのカラムがライン アピアランスを形成します。
[エクスポート(Export)] ウィンドウおよび [更新(Update)] ウィンドウにアクセスするには、
および を選択します。[エクスポート(Export)] ウィンドウおよび [更新(Update)] ウィンドウには、[CUPユーザのラインアピアランスのみエクスポート(Export line appearances for CUP users only)] チェックボックス(および [CUPユーザのラインアピアランスのみ更新(Update line appearance for CUP users only)] チェックボックス)があります。 このチェックボックスをオンにすると、 Cisco Unified Presence ユーザのエクスポート操作または更新操作が実行されます。 Cisco Unified Presence ユーザ以外のユーザは、エクスポートおよび更新されません。
Cisco Unified Communications Manager で SIP OPTIONS メソッドを使用すると、SIP トランクでリモート宛先のステータスを追跡できます。 発信の OPTIONS を送信して着信応答メッセージを確認することにより、リモート ピアで新しい要求を受信する準備が整っているかどうかを SIP トランクが認識します。 SIP トランクは、到達不能なリモート ピアに対して新しいコールの設定を試行しません。このアプローチによって、迅速なフェールオーバーが可能になります。
Cisco Unified Communications Manager では、SIP トランク上のキープアライブ メカニズムとして SIP OPTIONS を使用します。 Cisco Unified Communications Manager は、SIP トランク上の設定済み宛先アドレスに、定期的に OPTIONS 要求を送信します。 リモート SIP デバイスが応答に失敗するか、または SIP エラー応答を返信すると、 Cisco Unified Communications Manager は設定に応じて、他のトランクを使用するかまたは別のアドレスを使用することによって、コールの再ルーティングを試行します。
OPTIONS 要求はコールのコンテキスト外に配置されます。そのため、コールが SIP トランク上になくても、 Cisco Unified Communications Manager は要求によって障害を検出できます。 このアプローチを使用すると、後続のコールをより迅速に再ルーティングできます。 SIP OPTIONS メソッドにより、コールが再ルーティングされる前に、長時間タイムアウトしたり再試行が遅延したりすることがなくなります。
Cisco Unified Communications Manager の管理ページで OPTIONS を使用できるように SIP トランクを設定する場合は、次の設定のヒントを参考にしてください。
SIP OPTIONS を有効にするには、SIP プロファイルを設定します ( Cisco Unified Communications Manager の管理ページで メニュー オプションを使用します)。標準 SIP プロファイルをコピーして、そのコピーの名前を(OPTIONS プロファイルなどに)変更します。 [サービスタイプ "なし(デフォルト)" のトランクの接続先ステータスをモニタするためにOPTIONS Pingを有効にする(Enable OPTIONS Ping to monitor destination status for Trunks with Service Type "None (Default)")] チェックボックスをオンにします。 SIP OPTIONS は、デフォルトでは無効になっています。
作成した SIP プロファイルで、必要に応じて 2 つの要求タイマーを更新します。 1 つ目のタイマーは SIP トランクがサービス中または部分的にサービス中のときに使用され、2 つ目のタイマーは SIP トランクがサービス中ではないときに使用されます。 Cisco Unified Communications Manager は、設定済みのトランスポート プロトコル(UDP、TCP など)を使用して、SIP トランクの設定済み宛先アドレスに対して SIP OPTIONS 要求を開始します。
作成した SIP プロファイルで、SIP OPTIONS の再試行タイマーとカウンタを設定します。
SIP トランクを設定します(まだ設定していない場合)。 SIP トランクのトランク サービス タイプには、[なし(デフォルト)(None(default))] を指定する必要があります。 コール制御ディスカバリ、クラスタ間のエクステンション モビリティ、Intercompany Media Services などのダイナミック SIP トランクはサポートされません。
[トランクの設定(Trunk Configuration)] を使用して、宛先情報を設定します。 複数の宛先を設定できます。 宛先アドレスが(ドット付き IP アドレスではなく)ホスト名として設定されており、複数のアドレスが戻される場合、応答が受信されるまで、戻りアドレス宛に OPTIONS メッセージが送信されます。 すべての戻りアドレスが使用され尽くす前に応答が受信されなかった場合、SIP トランクには、ターゲットが「ダウン状態」であることを示すマークが付けられます。
SIP トランクの宛先に複数の IP アドレスが含まれるか、宛先が複数の IP アドレスに解決される場合、コール ルーティングはランダム選択アルゴリズムを使用して、SIP トランク上の次のコール用の宛先 IP アドレスを選択します。 SIP OPTIONS がトランクに対して有効になっている場合、選択した IP アドレスの状態情報によって、INVITE を送信するか、または次の宛先に進むかが決定されます。
SIP OPTIONS メソッドでは、SIP トランク セキュリティ プロファイルで [転送タイプ(Transport Type)] 設定が [TLS] に設定されているセキュア SIP トランクをサポートしています。 他の要求または応答(INVITE など)とは異なり、 Cisco Unified Communications Manager は、OPTIONS 要求または応答については [X.509のサブジェクト名(X.509 Subject Name)] の設定(SIP トランク セキュリティ プロファイルで設定)を確認しません。 そのため、OPTIONS 要求または応答に基づいてリモート宛先に使用可能のマークを付けることはできますが、コール設定要求(INVITE など)が理由コード 403 Forbidden で失敗することがあります。 OPTIONS 要求を送信する Cisco Unified Communications Manager か OPTIONS 要求を受信して応答する Cisco Unified Communications Manager のいずれかで [X.509のサブジェクト名(X.509 Subject Name)] を誤って設定すると、この障害が発生することがあります。
Unified CM 1 は SIP トランクを介して Unified CM 2 に OPTIONS 要求を送信し、200 OK 応答を受信します。 Unified CM 2 の SIP トランク セキュリティ プロファイルの [X.509のサブジェクト名(X.509 Subject Name)] が誤って設定されています。そのため、Unified CM 1 では Unified CM 2 に使用可能のマークが付きます。 INVITE が Unified CM 1 から Unified CM 2 に送信されると、Unified CM 2 は Unified CM 1 に 403 Forbidden メッセージを送信します。 次の図に、このシナリオを示します。
Unified CM 1 は SIP トランクを介して Unified CM 2 に OPTIONS 要求を送信し、200 OK 応答を受信します。 Unified CM 1 の SIP トランク セキュリティ プロファイルの [X.509のサブジェクト名(X.509 Subject Name)] が誤って設定されていても、Unified CM 1 は Unified CM 2 に使用可能のマークを付けます。 この場合、Unified CM 1 から Unified CM 2 への INVITE 要求は失敗します。 次の図に、このシナリオを示します。
SIP トランクに対してダイジェスト認証が有効になっている場合(対応する SIP トランク セキュリティ プロファイルで [ダイジェスト認証を有効化(Enable Digest Authentication)] チェックボックスがオンになっている)、OPTIONS 要求に対する 401(未許可)応答を受信した時点で、リモート宛先に使用可能のマークが付けられます。 401 応答を受信した後、OPTIONS はダイジェスト クレデンシャルとともに再送信されます。リモート側からのクレデンシャル確認時に、OPTIONS 要求に対する 200 OK 応答が受信されます。
SIP レルム(最初の 401 応答の受信時)またはダイジェスト クレデンシャルが不一致(リモート側)の場合の OPTIONS 要求では、リモート宛先に使用可能のマークが付けられていても、後続の INVITE 要求が失敗します。
SIP OPTIONS をサポートしているアラームは、次のとおりです。
サードパーティの SIP デバイスとの相互運用性を拡張するために、 Cisco Unified Communications Manager では、発信側エンドポイントのメディア機能およびメディア ポート情報が使用可能な場合に、MTP を必要とせずに発信ボイスおよびビデオ コールに対する早期オファーを有効にするように、SIP トランクを設定できます。
早期オファー トランクの発信コール セットアップのために、 Cisco Unified Communications Manager は、発信側デバイスのメディア ポート、コーデック、および発信側デバイスの IP アドレス(可能な場合)を含む SDP を取り込み、発信側のメディア情報を利用できない場合にかぎり、早期オファーの MTP を挿入し、複数のコーデックをサポートする MTP が挿入される場合は複数のコーデックをアドバタイズします。 以前のリリースでは、管理者が発信 SIP トランクで MTP の必須または E2E RSVP を有効にしている場合にのみ、 Cisco Unified Communications Manager は早期オファー SDP を提供していました。 早期オファー機能によって、より高い割合の発信の早期オファー SIP トランク コールが MTP を必要とせずに発信されるため、必要な MTP リソースの数が減り、サードパーティの PBX との相互互換性が向上します。
Cisco Unified Communications Manager では、次のいずれかのデバイスのコール開始時に、早期オファー(MTP を必要としない)をサポートします。
SIP 電話機
SCCP v20 でサポートされている SCCP 電話機。getPort 機能を使用してメディア ポート情報を提供
MGCP ゲートウェイ
着信の H323 FastStart コール
着信の早期オファー SIP トランクコール
![]() (注) |
メディア ポート情報を使用できないエンドポイント(H323 SlowStart コール、遅延オファー SIP コール、従来の SCCP 電話機など)の場合、 Cisco Unified Communications Manager はこれまでどおりに MTP を割り当て、初期 INVITE で SDP を提供します。 |
![]() (注) |
上記のリストにあるデバイスから開始されたコールについては、DTMF/コーデックの不一致、着信または発信トランクで TRP が必須、発信側で MTP が必須などの他の理由により MTP が必要になることがあります。 |
Cisco Unified Communications Manager は、基本的な保留/再開操作などの通話中の操作や、転送や会議などの補足サービスを実行しているときのサードパーティのデバイスとの相互運用性も拡張します。 以前のリリースの Cisco Unified Communications Manager では、非アクティブ SDP(a=inactive 属性)を含む INVITE を送信してメディア パスの中断を示し、遅延オファー INVITE を送信して保留音を挿入するかメディア ストリームを再開し、さらに 200 OK に送受信オファー SDP が含まれることを想定していました。 サードパーティのデバイスは、200 OK で送受信オファー SDP ではなく非アクティブ オファー SDP を提供することが多いため、メディア パスが非アクティブ状態のままになり、コールが破棄されます。
Cisco Unified Communications Manager では、 Cisco Unified Communications Manager によって通話中 INVITE での非アクティブ SDP または送信専用 SDP の送信が禁止されるように、早期オファー SIP トランクのパラメータを設定できます。 このパラメータが有効の場合、 Cisco Unified Communications Manager は、保留中または他機能の起動中に既存のメディア ストリームを中断せずに、SIP トランク デバイスを MOH またはアナンシエータ デバイスに直接接続します。 同様に、 Cisco Unified Communications Manager は、MOH またはアナンシエータ ストリームを中断せずに、コール再開時に SIP トランク デバイスを回線側デバイスに直接接続します。 遠端のメディア ストリームが非アクティブに設定されないようにすることによって、 Cisco Unified Communications Manager で常にメディア パスを再開できるようにする必要があります。
![]() (注) |
保留/再開時または補足サービスのメディア再開時に、サードパーティの SIP デバイスとの相互運用性で問題が発生している場合にのみ、非アクティブ SDP または送信専用 SDP の禁止を設定する必要があります。 この設定を有効にした場合、 Cisco Unity Connection などの特定のエンドポイントが動作しないことがあります。 |
Cisco Unified Communications Manager では、SIP トランクに接続されているデバイスで GetPort 機能がサポートされている場合に、SIP トランク上の初期コールまたは通話中コールの遅延オファー INVITE に応答する送受信 SDP も提供しています。 Cisco Unified Communications Manager は、SIP トランクが早期オファー用に設定されているかどうかに関係なく、この機能を提供します。 デバイスで GetPort 機能がサポートされていない場合、 Cisco Unified Communications Manager では送受信オファーを提供するための別の MTP は挿入しません。
コールが接続された後、 Cisco Unified Communications Manager が SCCP デバイスまたは MTP からのオーディオ/ビデオ/データ ポートの受信を待機する時間を変更するには、Port Received Timer After Call Connection サービス パラメータを設定します。 このパラメータで指定された時間が経過する前に、 Cisco Unified Communications Manager でビデオ ポートの受信に失敗すると、コールは最初に双方向オーディオでのみ確立されます。 双方向ビデオは、別のオファー/アンサー トランザクションが完了した後、確立されることがあります。 このタイマーで指定された時間が経過する前に、 Cisco Unified Communications Manager でオーディオ ポートの受信に失敗すると、 Cisco Unified Communications Manager は別のオファー/アンサー トランザクションを試行して、オーディオとビデオの両方の双方向メディア パスを確立します。
タイマーの時間を増やすと、Unified CM でポート情報を受信できる時間が長くなりますが、コールの開始時またはコール中にオーディオ/ビデオが遅延する場合があります。 発信側デバイスが CAST プロトコル バージョン 3 を使用している CTI または Unified Video Advantage アプリケーションの場合、アプリケーションで接続を開いてポート情報を取得するために必要な時間と適合するように、タイマーを調整することが必要になる場合があります。
早期オファー機能に適用される制限事項および相互作用は、次のとおりです。
早期オファー機能を使用するには、MTP で IOS バージョン 15.1(2)T 以降を使用している必要があります。
SRTP およびビデオ: Cisco Unified Communications Manager では、発信側デバイスの機能に応じて、初期 INVITE の SDP でセキュアなオーディオ機能やビデオ機能をアドバタイズできます。
エンドツーエンド(E2E)の RSVP:E2E RSVP では、初期 INVITE に SDP を含めることによって早期オファーを提供するため、早期オファー機能と E2E RSVP 機能を [SIPプロファイルの設定(SIP Profile Configuration)] ウィンドウで同時に指定することはできません。 [RSVP Over SIP] ドロップダウン リスト ボックスで [E2E] を選択すると、[音声コールとビデオコールに対する早期オファーのサポート(必要な場合はMTPを挿入)(Early Offer support for voice and video calls (insert MTP if needed))] チェックボックスは無効になります。
シングル ナンバー リーチ(SNR):設定時にメディア機能が使用可能になっている SIP 電話機、SCCP v20 電話機、または発信側デバイスから、トランクのシングル ナンバー リーチ(SNR)宛先へのコールが開始されると、INVITE SDP に発信側デバイスの IP アドレスとポートが含められます。 SNR トランク コールに早期オファーを提供するために MTP が必要な場合、別々の MTP ポートがそれぞれの SNR 宛先に割り当てられます。
IPv6: Cisco Unified Communications Manager は、SIP トランクに早期オファーが設定されていても、次の IPv6 シナリオの場合は遅延オファー INVITE を送信します。
遅延オファー SIP コールと早期オファーのインターワーキングの場合、 Cisco Unified Communications Manager は MTP を挿入して、発信コール レッグで SDP を提供します。 INVITE にはオーディオ回線のみが含まれます。 発信レッグで送信される INVITE には、オーディオ メディア回線のみが含まれます。 発信側ビデオ機能およびデバイスの暗号化キーは、タンデム クラスタでは使用できないため、オーディオまたはビデオ メディア回線には暗号化属性がありません。 結果として、発信 INVITE SDP には、MTP の IP とオーディオ ポートが含まれ、オーディオ メディア回線の SRTP キーや属性は含まれず、ビデオ メディア回線も含まれません。
SlowStart H323 コールと早期オファーのインターワーキングの場合、 Cisco Unified Communications Manager は MTP を挿入して、発信コール レッグで SDP を提供します。 INVITE にはオーディオ回線のみが含まれます。 発信レッグで送信される INVITE には、オーディオ メディア回線のみが含まれます。 発信側ビデオ機能およびデバイスの暗号化キーは、タンデム クラスタでは使用できないため、オーディオまたはビデオ メディア回線には暗号化属性がありません。 結果として、発信 INVITE SDP には、MTP の IP とオーディオ ポートが含まれ、オーディオ メディア回線の SRTP キーや属性は含まれず、ビデオ メディア回線も含まれません。 Cisco Unified Communications Manager では、メディア カットスルー後に H323 レッグからビデオ TCS を受信すると、コール アドミッション制御(CAC)でビデオが許可されており、割り当て済みの MTP でパススルーとマルチメディアがサポートされている場合には、ビデオも含まれるようになります。
Cisco Unified Communications Manager は、次のシナリオの場合に遅延オファー INVITE を送信します。
通話中のメディア再ネゴシエーション
コール保留:MOH サーバがネゴシエートされたオーディオ コールと同じコーデックをサポートしていないことがあるため、 Cisco Unified Communications Manager は MOH を挿入する場合、通話中に遅延オファー INVITE を送信します。 Cisco Unified Communications Manager では、メディアを再ネゴシエートするために、遠端の完全なコーデック リストを必要とします。
コール再開
次の状況のいずれかが発生した場合、 Cisco Unified Communications Manager で遅延オファー INVITE が送信されるか、または発信コールが失敗します。
割り当て済みの MTP、トランスコーダ、または TRP で getPort 機能がサポートされていない場合に、発信 SIP トランク レッグが早期オファーに対して有効になっていると、 Cisco Unified Communications Manager は早期オファーを提供するための別のメディア リソースを割り当てません。
SIP トランクで [信頼されたリレーポイントを使用(Use Trusted Relay Point)] の設定が有効になっており( Cisco Unified Communications Manager は別のメディア リソースを割り当てません。 この状況は、MTP または RSVP エージェントが TRP に設定されていない場合に発生します。
)、割り当て済みのメディア リソースで TRP 機能がサポートされていないか、またはメディア ポートの提供に失敗している場合、Fail Call If MTP Allocation Fails サービス パラメータまたは Fail Call If TRP Allocation Fails サービス パラメータの設定に応じて、 Cisco Unified Communications Manager で遅延オファーが送信されるか、またはコールが失敗します。
早期オファー SIP トランク上の打診コール レッグで帯域内呼び出し音またはアナウンスを提供するブラインド転送で呼び出し音を提供するように、SIP トランクに UPDATE および PRACK を設定してください。 トランクが PRACK に対して有効になっていない場合、または遠端のデバイスで UPDATE がサポートされていない場合、転送される側は呼び出し音を受信しません。
以前のリリースと同様に、オファー SDP 内のコーデックの順序は変更できません。 Cisco Unified Communications Manager は内部リストに基づいて、通常は高いものから低いものとなるようにコーデックを並べます。 この問題を回避するには、SIP 正規化スクリプトを作成して、オファー SDP 内のコーデックの順序を並べ替えます。
001685280 |2010/05/25 13:50:31.980 |100 |AppInfo
|||SIPCdpc(1,100,67,9)||1,100,67,9.1^*^*|//SIP/SIPCdpc(1,67,9)/ci=30801944/ccbId=14961/scb
Id=0/StartTransition: requireInactiveSDPForMidcallMediaChange=0,
isTrunkEnabledForVoiceEO=1
![]() (注) |
1 は、このコールに対して早期オファーが有効になっていることを示し、0 は早期オファーが無効になっていることを示します。 |
001685289 |2010/05/25 13:50:32.001 |100 |SdlSig |PolicyAndRSVPRegisterReq |wait |RSVPSessionMgr(1,100,91,1) |SIPCdpc(1,100,67,9) |1,100,49,1.100206^172.18.199.61^SEP001319ACCA00 |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] CI= 30801944 Branch= 0 reg=Default cap=0 loc=0 MRGLPkid=1db1ba42-9575-e3dc-ba78-fb11d56db546 PrecLev=5 VCall=F VCapa=F VCapCount=0 regiState=0 medReq=0 dataCapFl=2 IsEmccD=F EmccDName=to-ccm84 rcId= ipMode=0 eoType=2 getPort=F sRTP=F cryptocap=0 tm=16 DTMF(wantRecep=1 provOOB=1 suppMeth=1 Cfg=1 PT=0 reqMed=0) hInCodec=F distMed=F mediaEP=F rsvpQoSType=0 qosFallback=F status=0 sipOfferNeededInd=T hasSDP=F geolocInfo={geolocPkid=, filterPkid=, geolocVal=, devType=8}
![]() (注) |
eoType の値は、なし(0)、G.Clear に対する早期オファー(1)、音声およびビデオに対する早期オファー(2)、G.Clear 音声およびビデオに対する早期オファー(3)です。 |
001685353 |2010/05/25 13:50:32.087 |100 |SdlSig |PolicyAndRSVPRegisterRes |outCall_waitRSVPRes |SIPCdpc(1,100,67,9) |RSVPSession(1,100,93,5) |1,100,49,1.100207^172.18.199.61^SEP001319ACCA00 |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] CI= 30801944 Branch= 0 Status=1 rsvpPol=1 vCall=F e2eRSVPInserted=F eoStatus=1 hasSDPMsg=T RSVPAgent: confID =0 ci =0 capCt =0 reg= mtpType =2 agentCt =0 agentAllo =0 RemoAgent=F DevCap=0 ipAddrMode=0
![]() (注) |
eoStatus の有効な値は、なし(0)、音声およびビデオに対する早期オファー(1)、G.Clear に対する早期オファー(2)、遅延オファーの続行(3)、失敗したコール(4)です。 |
001685325 |2010/05/25 13:50:32.064 |100 |SdlSig |DeviceMediaInfoReq |restart0 |StationD(1,100,50,13) |RSVPSession(1,100,93,5) |1,100,49,1.100206^172.18.199.61^SEP001319ACCA00 |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] CI= 30801943 confID=30801943 callRefID=30801943 counter=1 mediaType=1 iptype=0 PPID=16777217 reqCode=1 001685327 |2010/05/25 13:50:32.064 |100 |SdlSig |StationPortReq |restart0 |StationD(1,100,50,13) |StationCdpc(1,100,51,1) |1,100,49,1.100206^172.18.199.61^SEP001319ACCA00 |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] confID=30801943 PPID=16777217 CI=30801943 transportType=1 addrType=0 mediaType=1 .
001685328 |2010/05/25 13:50:32.081 |100 |AppInfo |||StationInit(1,100,49,1)||1,100,49,1.100207^172.18.199.61^SEP001319ACCA00|StationInit: (0000013) PortRes IpAddr=0x399eb00, Port=31780, RTCPPort=0, confID=30801943, PPID=16777217 001685330 |2010/05/25 13:50:32.081 |100 |SdlSig |StationPortRes |outgoing_call_proceeding3 |StationCdpc(1,100,51,1) |StationD(1,100,50,13) |1,100,49,1.100207^172.18.199.61^SEP001319ACCA00 |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] CI= 30801943 confID=30801943 ptpID=16777217 ipaddr=0x{ac,12,c7,3d,0,0,0,0,0,0,0,0,0,0,0,0} port=31780 =.type=0. RTCPPort=0 mediaType=1 001685331 |2010/05/25 13:50:32.082 |100 |SdlSig |DeviceMediaInfoRes |wait |RSVPSessionMgr(1,100,91,1) |StationCdpc(1,100,51,1) |1,100,49,1.100207^172.18.199.61^SEP001319ACCA00 |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] CI= 30801943 confID=30801943 callRefID=30801943 mediaType=1 iptype=0 PPID=16777217 reqCode=1 port=31780 RTCPPort=0 ipAddrType=0 ipv4=172.18.199.61 status=0
001686458 |2010/05/25 13:50:48.535 |100 |SdlSig |AuEarlyOfferConnectReq |waitForAll |MediaCoordinator(1,100,125,1) |RSVPSession(1,100,93,6) |1,100,49,1.100222^172.18.201.82^SEP0014F2E982F1 |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] Party1: CI=30801945 capCount=7 region=Default xferMode=4 mrid=0 audioId=0 videoCap=F dataCap=2 activeCap=0 cryptoCapCount=0 flushIns=0 dtmCall=0 dtmPrimaryCI=0 IFPid=(0,0,0,0) dtMedia=F honorcodec=F EOType=0 MohType=0 Party2: CI=30801946 capCount=0 region=Default xferMode=16 mrid=0 audioId=0 videoCap=F dataCap=2 activeCap=0 cryptoCapCount=0 flushIns=0 dtmCall=0 dtmPrimaryCI=0 IFPid=(0,0,0,0) dtMedia=F honorcodec=F EOType=2 MohType=0 videoCall=F confID =0 ci =0 capCt =0 reg= mtpType =2 agentCt =0 agentAllo =0 RemoAgent=F DevCap=0 ipAddrMode=0 mtpInsReason=32 hasSDP=F
![]() (注) |
mtpInsReason の有効な値は、なし(0)、TRP 側 B(1)、TRP 側 A(2)、トランスコーダ側 A(4)、MTP 側 A(8)、DTMF 不一致(16)、早期オファー(32)です。 |
001686676 |2010/05/25 13:50:48.646 |100 |SdlSig |AuEarlyOfferConnectReply |wait |RSVPSession(1,100,93,6) |MediaCoordinator(1,100,125,1) |1,100,49,1.100223^172.18.197.154^MTP_sinise |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] ciParty1=30801945 ciParty2=30801946 devicePidParty1=(1,100,50,3) devicePidParty2=(1,100,67,10) err=0 videoFlag=F hasSDP=T.
![]() (注) |
メディア リソース割り当ての失敗に対する有効なエラーコードの有効な値は、エラーなし(0)、TRP 割り当て側 B(1)、TRP 側 A(2)、トランスコーダ側 A(3)、MTP 側 A(4)、DTMF 不一致の MTP(5)、早期オファーの MTP(6)です。 |
早期オファーの問題をトラブルシューティングする方法については、次の表を参照してください。
Cisco Unified IP Phone 7911、7941、7961、7970、および 7971 は、 Cisco Unified Communications Manager Back to Back User Agent(B2BUA)環境で SIP エンドポイントとして配置されます。 電話機と他のネットワーク コンポーネントとの基本的なインターフェイスは SIP が提供します。 SIP 以外に、たとえば、IP アドレス割り当て用の DHCP、ドメイン名からアドレスへの解決に使用する DNS、イメージおよび設定データをダウンロードするための TFTP など、各種の機能に対してさまざまなプロトコルが使用されます。
ここでは、例を図で示し、B2BUA 環境とピアツーピア環境について簡単に説明します。
上図は、メイン サイトと営業所の配置を示した Cisco Unified Communications Manager B2BUA ネットワークの単純な例を示しています。 各サイトには、SIP を実行する電話機と SCCP を実行する電話機が混在しています。 メイン サイトには、 Cisco Unified Communications Manager クラスタとボイスメール サーバがあります。 メイン サイトと営業所サイトにある電話機はそれぞれ、プライマリ、セカンダリ、および三次の Cisco Unified Communications Manager セットをホームにしています。 これによって、個々の Cisco Unified Communications Manager サーバに障害が起きた場合の、コール制御の冗長性が提供されます。
メイン サイトの SIP を実行している電話機は、すべてのセッション招待を Cisco Unified Communications Manager へ送信します。 ルーティング設定と宛先を基に、 Cisco Unified Communications Manager はコールを SIP または SCCP を実行している別の電話機へローカルに送り届けたり、メイン サイトの音声ゲートウェイを通じて IP WAN から営業所内のいずれかの電話機へ送り届けたり、メイン サイトの音声ゲートウェイを通じて PSTN へ送り届けたりします。 同様に、営業所内の電話機から発信されたコールも、営業所の音声ゲートウェイを通じて、コールを PSTN へルーティングする追加機能を使用してルーティングされます。
営業所には、メイン サイトの IP WAN および PSTN にアクセスするために、SRST ゲートウェイが配置されます。 営業所の SIP を実行している電話機は、すべてのセッション招待をメイン サイトの Cisco Unified Communications Manager へ送信します。 メイン サイトの電話機と同様に、 Cisco Unified Communications Manager は、コールをメイン サイトの電話機へ送り届けたり、メイン サイトの音声ゲートウェイを通じて IP WAN から営業所の電話機、または PSTN へ送り届けたりすることができます。 営業所内の電話機から発信された PSTN コールは、 Cisco Unified Communications Manager クラスタのルーティング設定に従って、メイン サイトのゲートウェイを通じて PSTN へルーティングしたり、営業所のゲートウェイを通じて PSTN へローカルにルーティングしたりすることができます。
IP WAN に障害が起きた場合、SRST ゲートウェイは、バックアップ コール制御サーバとしても機能します。 SIP を実行している電話機と SCCP を実行している電話機はどちらも、WAN の障害時に SRST ゲートウェイへフェールオーバーします。 そうすることにより、営業所内の電話機はコールを SRST ゲートウェイにルーティングできます。 このようなコールとしては、営業所内で発信および終端するコールと、PSTN 内で発信および終端するコールがあります。
SIP 回線側機能は、 Cisco Unified Communications Manager アーキテクチャ、TFTP サーバ、および Cisco Unified IP Phone に影響を与えます。 SIP を実行している電話機の機能は SCCP を実行している電話機の機能と同等で、動作も似ています。 Cisco Unified IP Phone 7941/61/71/70/11 は、すべての機能およびほとんどの CTI アプリケーションをサポートします。 Cisco Unified IP Phone 7905/12/40/60 は、縮小された機能セット(たとえば、制限付きの MOH 機能とフェールオーバー機能)をサポートします。 SIP トランク側アプリケーションは、SCCP を実行している電話機と SIP を実行している電話機の両方に対して機能します。
Cisco Unified Communications Manager では、この項で説明する SIP 規格がサポートされています。
この SIP 規格では、次の Cisco Unified Communications Manager 機能がサポートされます。
これらの SIP 規格では、次の Cisco Unified Communications Manager 機能がサポートされます。
この SIP 規格では、次の Cisco Unified Communications Manager 機能がサポートされます。
Calling Line ID(CLID)
Calling Party Name ID(CNID)
Dialed Number ID Service(DNIS)
Call-by-call Calling Line ID Restriction(call-by-call CLIR)
RPID は、識別サービスに使用される SIP ヘッダーです。 RPID は、発信側、着信側、および接続先リモート側の情報を相手に示します。その目的は、識別と折り返し、合法的な代行受信、緊急サービスに対するユーザ ID とユーザ ロケーションの指示、およびアカウンティング サービスと課金サービス用のユーザの識別です。
この SIP 規格では、次の Cisco Unified Communications Manager 機能がサポートされます。
この SIP 規格では、次の Cisco Unified Communications Manager 機能がサポートされます。
この SIP 規格では、次の Cisco Unified Communications Manager 機能がサポートされます。
Cisco Unified Communications Manager 8.6(1) では、ネットワーク配置で P-Charging-Vector(PCV)という SIP ヘッダーのパススルーをサポートします。 この PCV ヘッダーを使用して、グローバルに一意な IP Multimedia Subsystem(IMS)Charging Identifier(ICID)値など、モバイルまたは PSTN の課金関連情報をサービス プロバイダーに伝送します。
新しい SIP 正規化スクリプトである、HCS-PCV-PAI-passthrough は、この機能の一部として導入されています。 このスクリプトが Cisco Unified Communications Manager にプレインストールされていて、ネットワークを指すすべての SIP トランクに関連付けられる必要があります。
ネットワークから発信するすべてのコールに対して、Cisco Unified Communications Manager は、INVITE、UPDATE、および 200 OK でネットワークから受信した PCV ヘッダーを相手側へパススルーします。 さらに、Cisco Unified Communications Manager は、Cisco Unified Communications Manager で終了するコールに対する 200 OK SIP を介したネットワークからの PCV ヘッダーをパススルーします。 これらのコールは同じ SIP トランクを経由してシスコ ネットワークに戻るようにルーティングされるため、Cisco Unified Communications Manager が受信する 200 OK メッセージは、発信コールの PCV ヘッダーを使用してそのまま渡されます。
この SIP 規格では、次の Cisco Unified Communications Manager 機能がサポートされます。
これらの SIP 規格では、次の Cisco Unified Communications Manager 機能がサポートされます。
これらの SIP 規格では、次の Cisco Unified Communications Manager 機能がサポートされます。
これらの SIP 規格では、次の Cisco Unified Communications Manager 機能がサポートされます。
この SIP 規格では、次の Cisco Unified Communications Manager 機能がサポートされます。
この SIP 規格は、re-INVITE による SIP セッションの定期的なリフレッシュを許可し、リモートへのシグナリング接続がまだ有効であるかどうかを Cisco Unified Communications Manager が判別できるようにします。
この項で説明している次の Cisco Unified IP Phone 機能が Cisco Unified Communications Manager でサポートされます。
Cisco Unified Communications Manager では、回線キーを BLF コール ピックアップ キーとして割り当てることができます。 BLF コール ピックアップ キーの動作は、SIP を実行している電話機の BLF スピード ダイヤル キーと同等です。 回線キーには、設定されている DN の BLF ステータスが表示されます。この回線キーを押すと、設定されている DN への発信が実行されます。 BLF コール ピックアップでは、BLF コール ピックアップ DN として設定されている DN でコールのアラートが発生すると、アラート通知が追加されます。 アラート中のコールに応答するには、コールがアラート状態となっている間に、BLF コール ピックアップ DN を押します。
BLF コール ピックアップ機能でモニタされている DN については、サブスクリプション タイプ PRESENCE+ALTERTING を使用して、SIP デバイス レイヤがコールのプレゼンス ステータスとアラート ステータスをサブスクライブします。 PRESENCE+ALTERTING のサブスクリプションは、モニタされている DN 回線の回線制御によって処理されます。 サブスクライブされている DN でコールが受信されると、回線制御によって Subscription Manager に通知されます。
Cisco Unified Communications Manager では、ゲートウェイを介して受信したコールの発呼側番号をグローバル化できます。 発呼側番号を電話機に表示する前に変換して、E.164 形式にすることができます。 電話機には、このグローバル化された番号が提供されます。ユーザは、番号編集の機能を使用しなくても、受信した番号に折り返しのコールを発信できます。
グローバル化された番号のオプションの URI パラメータ(x-cisco-callback-number)が RPID ヘッダーに追加されます。 ローカライズされた番号は、SIP URI のユーザ部分として指定されます。 Cisco Unified Communications Manager によって電話機に送信される From ヘッダーでも、同じ SIP URI が指定されます。 折り返しダイヤル機能を起動すると、電話機は同じ SIP URI を要求 URI として Cisco Unified Communications Manager に INVITE でエコー バックします。 Cisco Unified Communications Manager の SIP デバイス レイヤは、グローバル化された番号が含まれている URI パラメータの要求 URI を解析し、ルーティングに使用します。 この URI が見つからない場合、SIP デバイス レイヤは、SIP URI のユーザ部分にある番号のローカライズ形式を使用します。
x-cisco-callback-number パラメータはオプションであり、会議コールの RPID ヘッダーには含まれず、コールが非通知としてマーキングされている場合には含まれていないことに注意してください。
回線側 SIP には CTI 機能が含まれます。この機能を使用すると、 Cisco Unified Communications Manager Assistant などの CTI アプリケーションで、SIP を実行している Cisco Unified IP Phone( Cisco Unified IP Phone 7961 など)をサポートできます。 SIP を実行している電話機の CTI 機能は、SCCP を実行している電話機のものと同等ですが、いくつかの例外があります。 SIP を実行している電話機でサポートされる CTI 機能には、テキストの表示、ランプの設定、トーンの再生、コール パーク、およびプライバシーのサポートが含まれます。 CTI および Cisco Unified Communications Manager の詳細については、コンピュータ テレフォニー統合を参照してください。
SCCP を実行している電話機とは異なり、SIP を実行している電話機は番号をローカルで収集してから、その番号を Cisco Unified Communications Manager へ送信します。 SIP を実行している電話機はローカル ダイヤル プランを使用して、十分な番号がいつ入力されたかを認識し、収集された番号を使用して INVITE をトリガーします。 SRST モードで SIP を実行している電話機は、 Cisco Unified Communications Manager から受信した設定済みダイヤル プランを使用し続けます。 詳細については、SIPダイヤル ルールを参照してください。
Cisco Unified Communications Manager は、SIP を実行している電話機上でダイレクト コール ピックアップ機能をサポートしています。 SIP を実行している電話機のダイレクト コール ピックアップ機能は、SCCP を実行している電話機のものと同等です。 ダイレクト コール ピックアップでは、[Gピック] ソフトキーを押して電話番号を入力することで、その DN のアラート中のコールを直接ピックアップできます。 SIP を実行している電話機は、 Cisco Unified Communications Manager に対して、ピックアップ対象となる電話機の DN が含まれた INVITE を送信します。
Cisco Unified Communications Manager は、SIP デバイスまたは Cisco Unified Communications Manager デバイスが開始するサイレント(DND)をサポートします。 DND ステータスの変化は、SIP デバイスから、SIP PUBLISH メソッドを使用して Cisco Unified Communications Manager にシグナリングされます。 DND ステータスの変化は、 Cisco Unified Communications Manager から、dndupdate Remote-cc REFER 要求を使用して SIP デバイスにシグナリングされます。 また、 Cisco Unified Communications Manager はデバイスの DND ステータスとともにデバイスのビジー/アイドル ステータスを発行することもできます。
DND 機能については、Cisco Unified Communications セルフケア ポータルで 2 つのオプションのいずれか 1 つに設定できます。 設定できるのは、[呼出音オフ(Ringer Off)] または [コール拒否(Call Reject)] です。 [コール拒否(Call Reject)] は、SCCP を実行している電話機と SIP を実行している電話機の両方でサポートされます。 DND がアクティブで [コール拒否(Call Reject)] が選択されている場合、着信コール、オーディオ通知、およびビジュアル通知が電話機に表示されません。
SIP を実行している Cisco Unified IP Phone は、デバイスにダウンロードされた設定ファイルから DSCP 情報を取得します。 DSCP 設定はデバイスに適用されますが、SCCP を実行している電話機はコール用に DSCP 設定を取得できます。 DSCP 値は、[エンタープライズ パラメータ設定(Enterprise Parameters Configuration)] ウィンドウと Cisco Unified Communications Manager の [サービス パラメータ設定(Service Parameter Configuration)] ウィンドウで設定されます。
Cisco Unified Communications Manager では、ゲートウェイを介して受信したコールの発呼側番号をグローバル化できます。 この処理には、E.164 形式の番号(+14085551234 など)にある「+」記号の追加を含みます。 SIP を実行している電話機が、通話履歴ログにある番号への折り返しダイヤル機能を起動した場合、 Cisco Unified Communications Manager にはグローバル化された番号がルーティング用として返されます。 E.164 のサポートによって、SIP デバイス レイヤは、グローバル化された番号文字列全体(+ を含む)を DA に渡すことができます。
iX メディア チャネル機能では、複数のアプリケーション レイヤ プロトコルを多重化するため、シンプルで信頼性に優れたセキュアなチャネルを利用できます。 SIP トランクで iX メディア チャネルのサポートを有効にするには、Cisco Unified Communications Manager の管理ページで [iXアプリケーションメディアを許可(Allow iX Application Media)] チェックボックスをオンにします。
を選択し、![]() (注) |
Unified Communications Manager は、ビデオ チャネルが確立されている場合のみ、iX メディア チャネルのネゴシエーションをサポートします。 |
![]() (注) |
サポートされている SIP デバイスの場合、iX メディア チャネルはデバイスのユーザ インターフェイスから有効化する必要があります。 詳細については、ご使用の電話機モデルに関連するドキュメントを参照してください。 |
参加機能の動作は、SIP を実行している電話機で、アドホック会議機能のインスタンスが 1 つ以上存在している場合と同様です。ただし、打診コールが開始されることはありません。 回線をまたいで参加機能を使用すると、複数の電話回線(電話番号が異なる回線または電話番号が同じでパーティションが異なる回線)上のコールを参加させ、会議を作成できます。
参加機能、または回線をまたいで参加機能をユーザが実行した場合、SIP を実行している電話機は、既存のソフトキーが SIP を実行している電話機から Cisco Unified Communications Manager に送信されるときと同じ方法で [参加] ソフトキー メッセージを使用し、選択されている回線で参加機能を実行します。
Cisco Unified Communications Manager は、SIP を実行している電話機上で MCID 機能をサポートしています。 SIP を実行している電話機の MCID 機能は、SCCP を実行している電話機のものと同等です。 MCID 機能は、いたずら電話や脅迫電話を追跡する便利な方法を提供します。 この類のコールを受信したユーザが [迷惑呼] ソフトキーを押すと、新しい Remote-cc REFER softkeyevent 要求が Cisco Unified Communications Manager に送信されます。 この結果、 Cisco Unified Communications Manager でコールが記録されます。 ユーザには確認音が再生され、MCID 通知が受信されたことを示すテキスト メッセージが送信されます。 この確認音は、電話機への Remote-cc playtonereq によって生成されます。テキスト メッセージは、「迷惑呼IDの処理完了」という内容の Remote-cc statuslineupdate です。
Cisco Unified Communications Manager の管理ページで電話用 Network Time Protocol(NTP)参照先を設定し、SIP を実行する Cisco Unified IP Phone が、日付と時刻を必ず NTP サーバから取得するようにできます。 すべての NTP サーバから応答がない場合、SIP を実行している電話機は、REGISTER メッセージに対する 200 OK 応答内の日付ヘッダーを使用して日付と時刻を取得します。
電話用 NTP を Cisco Unified Communications Manager の管理ページに追加した後、それを日時グループに追加する必要があります。 日時グループ内では、電話機が連絡する最初のサーバから順に、電話用 NTP に優先順位を付けます。
日時グループの設定はデバイス プール内で指定され、デバイス プールは電話機ウィンドウで指定されます。
NTP 参照先の設定方法については、SIPダイヤル ルールを参照してください。
Private Line Automatic Ringdown(PLAR)とは、従来のテレフォニー システムで使用される用語で、ユーザが電話機をオフフックすると、常に電話機が事前に設定された番号をすぐにダイヤルするような電話機の設定のことです。 ユーザは、その電話機(または回線)から別の番号をダイヤルできません。 これは、 Cisco Unified Communications Manager でパーティション、コーリング サーチ スペース(CSS)、およびトランスレーション パターンを使用して SCCP IP Phone に実装されます。電話機に PLAR がセットアップされていることは、デバイス設定にも回線設定にも表示されません。
管理者は SIP ダイヤル ルールを使用して、SIP を実行する電話機に PLAR を設定します。 PLAR に設定された電話機は、適切なターゲット パターンを指定する、1 回線ダイヤル プランが設定されます。 ユーザがオフフックすると、電話機は INVITE にターゲット文字列を含めて、すぐに要求を Cisco Unified Communications Manager へ送信します。 ユーザは、番号を入力しません。 詳細については、SIPダイヤル ルールを参照してください。
Cisco Unified IP Phone は、回線ボタン(ディスプレイの右側にあるボタン)をサポートしています。このボタンを使用すると、特定の回線上でコールを開始、応答、または切り替えることができます。 スピードダイヤル、エクステンション モビリティ、プライバシー、BLF スピードダイヤル、DND、サービス URL など、限られた数の機能をこれらのボタンに割り当てることができます。 これらの各機能は、SIP を実行している電話機でサポートされており、 Cisco Unified Communications Manager で設定できます。
PLK 機能の詳細については、プログラム可能な回線キーを参照してください。
Cisco Unified Communications Manager は、SIP デバイスから開始されるワンボタン割り込みと C 割り込みをサポートしています。 SIP を実行している電話機のワンボタン割り込み/C 割り込み機能は、SCCP を実行している電話機のものと同等です。 ワンボタン割り込み/C 割り込み機能を使用すると、ユーザは進行中のコールの共有回線ボタンを押すだけで、自分自身をそのコールに自動的に追加できます。
Cisco Unified Communications Manager は、SIP を実行している電話機上で、回線ロールオーバーによる単一コール UI をサポートしています。 回線ロールオーバーが発生するのは、max-calls-per-line および busy-trigger の値が 1/1 に設定されている場合です。 転送機能および会議機能では、プライマリ コールで max-calls-per-line の値に達した場合、電話機は、コールが発生していない直近の回線ボタンまたは別パーティションの同一 DN に対して打診コールをロールオーバーすることができます。 max-calls-per-line および busy-trigger の値が 2/1 に設定されている場合、発信の打診コールは同じボタンに転送されます。
SIP 属性はほとんど変更されないため、 Cisco Unified Communications Manager は SIP プロファイルを使用して、SIP トランクおよび Cisco Unified IP Phone に関連した SIP 属性を定義します。 これらの属性を、すべての SIP トランクと SIP を実行する電話機に個別に追加することなく、プロファイルの中に入れておくと、管理者は SIP デバイスの設定に費やす時間を減らすことができ、デバイス グループの値を変更できるようになります。 SIP プロファイルは、SIP のトランクと電話機を設定するときの必須フィールドなので、 Cisco Unified Communications Manager にはデフォルトの SIP プロファイルが用意されていますが、管理者はカスタマイズした SIP プロファイルを作成できます。 SIP プロファイルを SIP デバイスに割り当てるには、 Cisco Unified Communications Manager の管理ページを使用します。
SIP を実行している電話機のソフトウェアは、各電話機へ TFTP で送信された SIP 値の大部分を使用します。
SIP プロファイルの設定方法については、SIPダイヤル ルールを参照してください。
Cisco Unified Communications Manager では、2 つの異なるエンドポイントを同じデバイス名に登録することはできません。 これにより、ソフト クライアントでは問題が発生する可能性があります。ソフト クライアントは、複数のシステム(PC 用の Cisco Jabber クライアントや Macintosh 用の Cisco Jabber クライアントなど)にインストールでき、各システムの同じ登録を使用できるためです。
別のソフト クライアントが該当するデバイス名にすでに登録されている場合に、登録の試みを処理するため、ソフト クライアントでは、SIP 登録要求の Supported ヘッダーに次のタグを挿入できます。
x-cisco-duplicate-reg-:このタグがある場合、Cisco Unified Communications Manager は自動的に 2 つ目のソフト クライアントを登録して最初のソフト クライアントの登録を削除します。
x-cisco-graceful-reg:このタグにより、既存のセッションを自動的にキャンセルしなくても、登録済みのデバイス名に登録を試みているソフト クライアントが、既存の登録セッションを上書きできます。 このタグがある場合、Cisco Unified Communications Manager は新しい登録の試みを拒否して SIP 403 メッセージを返します。 ソフト クライアントは、x-cisco-duplicate-reg タグのみを使用して新しい登録の試みを送信することで、最初のソフト クライアントを再登録するか、または登録の試みを中止することで、最初のソフト クライアントの登録をそのまま残すことができます。
両方のタグがある場合、Cisco Unified Communications Manager は x-graceful-reg タグを優先します。
管理者は、 Cisco Unified Communications Manager の管理ページを使用して、電話機に表示されるソフトキー セットを変更できます。 キーの追加と削除、およびキー位置の変更ができます。 このデータはデータベースに書き込まれ、電話機の登録/初期化プロセスの一部として、Station メッセージで SCCP を実行する電話機へ送信されます。 ただし、SIP をサポートする Cisco Unified IP Phone では Station メッセージでキーが送信されず、 Cisco Unified Communications Manager TFTP サーバがソフトキー セットの含まれたファイルを作成します。 SIP を実行する電話機はそのファイルを TFTP サーバから取得し、電話機に内蔵されたソフトキー セットが、新しいソフトキー セットで上書きされます。 これにより、 Cisco Unified Communications Manager はデフォルトのソフトキーを変更できます。また、 Cisco Unified Communications Manager はソフトキー イベントを操作することで、一部の電話機レベルの機能を直接制御できます。
[ソフトキーテンプレートの設定(Softkey Template Configuration)] ウィンドウを使用して設定した機能が SIP を実行する電話機でサポートされていない場合、そのソフトキーは表示されますが、そのキーが有効でないというメッセージが電話機に表示されます。この動作は、SCCP を実行する電話機の動作と一貫性があります。
[ダイヤル] ソフトキーは、SIP を実行している電話機が SRST モードで動作しているときに、デフォルトのソフトキー セットの一部として表示されます。
![]() (注) |
SIP を実行している Cisco Unified IP Phone 7905、7912、7940、および 7960 は、ソフトキーをダウンロードしません。 これらの電話機では、ソフトキーが電話機のファームウェアに内蔵されています。 |
Cisco Unified Communications Manager は、UMCS と連動することで、 Cisco Unified Communications Manager の機能を Cisco Unified Mobile Communicator デバイスまで拡張できます。 UMCS は、1 つ以上の TCP 接続上で SIP を使用して、 Cisco Unified Communications Manager と通信します。 各 TCP 接続は、複数のユーザで共有できます。
目次
- Session Initiation Protocol
- SIP トランク設定
- SIP 電話の設定
- SIP ネットワーク
- SIP および Cisco Unified Communications Manager
- メディア ターミネーション ポイント(MTP)デバイス
- [メディアターミネーションポイントが必須(Media Termination Point Required)] オプションが有効な SIP デバイスのリージョンの設定
- SIP サービス パラメータ
- SIP の相互運用性
- SIP タイマーとカウンタ
- サポートされるオーディオ メディア タイプ
- サポートされるビデオ メディア タイプ
- サポートされるアプリケーション メディア タイプ
- サポートされる T38fax ペイロード タイプ
- トランクの SIP プロファイル
- SIP トランク セキュリティ プロファイル
- Cisco Unified CallManager と Cisco Unified Communications Manager の各リリース間の SIP トランク
- SIP トランクでの SIP フォーク
- SIP の透過および正規化
- SIP 正規化のトレース
- SIP 正規化のアラーム
- SIP 正規化のパフォーマンス カウンタ
- 依存関係レコード
- SIP の機能
- SIP エンドポイントと Cisco Unified Communications Manager 間の基本コール
- 基本の発信コール
- 基本の着信コール
- 早期メディアの使用
- SIP エンドポイントと Cisco Unified Communications Manager 間の DTMF リレー コール
- Dissimilar DTMF 方式の、SIP デバイスからゲートウェイまたは対話型音声応答(IVR)システムへの DTMF ディジットの転送
- Dissimilar DTMF 方式の DTMF ディジットの生成
- MTP が割り当てられた場合に開始される補足サービス
- ブラインド転送時の呼び出し音
- SIP エンドポイントが開始する補足サービス
- SIP が開始するコール転送
- コール保留
- 自動転送
- 拡張されたコール識別サービス
- 発呼者回線 ID の表示(CLIP)および発呼者名の表示(CNIP)
- 発呼者回線 ID の制限(CLIR)および発呼者名の制限(CNIR)
- SIP CLI 処理の変更
- 接続側回線 ID の表示(COLP)および接続先名の表示(CONP)
- 接続側回線 ID の制限(COLR)および接続先名の制限(CONR)
- Redirecting Dial Number Identification Service(RDNIS)
- リダイレクション
- SIP トランクの G. Clear コーデックのサポート
- G.Clear コールに対する早期オファー
- SIP トランクでの Multilevel Precedence and Preemption のサポート
- リソース プライオリティ ネームスペース ネットワーク ドメイン
- SIP トランクでのセキュア V.150.1 Modem over IP のサポート
- SIP トランクでの G.729a コーデックと G.729b コーデックのサポート
- Microsoft Exchange を使用する場合の SIP T.38 相互運用のサポート
- SIP を介した QSIG トンネリングのサポート
- SIP PUBLISH
- Cisco Unified Communications Manager および Cisco Unified Presence の高レベル アーキテクチャの概要
- SIP OPTIONS
- SIP 早期オファー
- 早期オファーの制限事項および相互作用
- トレース
- 早期オファーの問題のトラブルシューティング
- Cisco Unified Communications Manager SIP エンドポイントの概要
- SIP 回線側の概要
- SIP の規格
- RFC3261、RFC3262(PRACK)、RFC3264(Offer/Answer)、RFC3311(UPDATE)、3PCC
- RFC3515(REFER)Replaces および Referred-by ヘッダー
- Remote Party Id(RPID)ヘッダー
- Diversion ヘッダー
- Replaces ヘッダー
- Join ヘッダー
- P-Charging-Vector ヘッダー
- RFC3265 + ダイアログ パッケージ
- RFC3265 + プレゼンス パッケージ
- RFC3265 + KPML パッケージ
- RFC3265 + RFC3842 MWI パッケージ(要求なしの通知)
- Remotecc
- RFC4028 セッション タイマー
- SIP 電話機での Cisco Unified Communications Manager の機能
- BLF コール ピックアップ
- 発呼側の正規化
- CTI サポート
- ダイヤル プラン
- ダイレクト コール ピックアップ
- サイレント
- サイレント(DND)によるコール拒否
- DSCP の設定
- E.164
- iX メディア チャネル
- 参加および回線をまたいで参加
- 迷惑呼 ID(MCID)
- Network Time Protocol(NTP)
- PLAR
- プログラム可能な回線キー
- ワンボタン割り込み/C 割り込み
- 単一コール UI
- エンドポイントの SIP プロファイル
- ソフト クライアントの二重登録
- ソフトキー処理
- Unified Mobile Communications Server(UMCS)との連動
- SIP トランク設定
- SIP 電話の設定
- SIP ネットワーク
- SIP および Cisco Unified Communications Manager
- SIP の機能
- Cisco Unified Communications Manager SIP エンドポイントの概要
- SIP 回線側の概要
- SIP の規格
- SIP 電話機での Cisco Unified Communications Manager の機能
SIP トランク設定
SIP トランクのセットアップに、SIP トランクを Cisco Unified Communications Manager に設定するために必要な手順の概要を、関連する手順とトピックの参照先とともに示します。
SIP 電話の設定
電話機の設定に、SIP を実行する Cisco Unified IP Phone を設定するために必要な手順の概要を示します。
SIP を実行するサードパーティの電話機を設定する場合は、『Cisco Unified Communications Manager アドミニストレーション ガイド』を参照してください。
SIP ネットワーク
SIP プロキシ サーバ:このプロキシ サーバは、クライアントから SIP 要求を受信して、クライアントの代わりに要求を転送する中間デバイスとして機能します。 プロキシ サーバは、認証、許可、ネットワーク アクセス制御、ルーティング、信頼性の高い要求再送、セキュリティなどの機能を提供します。
リダイレクト サーバ:リダイレクト サーバは、メッセージが進むべきネクストホップに関する情報を 1 つ以上クライアントに提供します。その後、クライアントは、次のホップ サーバまたユーザ エージェント サーバと直接接続します。
登録サーバ:登録サーバは、現在のロケーションの登録を求めるユーザ エージェント クライアントからの要求を処理します。 リダイレクトまたはプロキシ サーバには、登録サーバが含まれる場合があります。
ユーザ エージェント(UA):UA は、コールを開始および受信するユーザ エージェント クライアント(UAC)とユーザ エージェント サーバ(UAS)の組み合わせで構成されます。 UAC が SIP 要求を開始します。 UAS は、SIP 要求を受信したときにユーザに連絡するサーバ アプリケーションです。 要求を受信すると、UAS がユーザの代わりに応答します。 Cisco Unified Communications Manager は、サーバとクライアントの両方(バックツーバック ユーザ エージェント)として動作できます。
SIP は、要求/応答方式を使用して、ネットワーク内の各種のコンポーネント間の通信を確立し、最終的に 2 つ以上のエンドポイント間のコールまたはセッションを確立します。 1 つのセッションには、複数のクライアントおよびサーバが使用されます。
SIP ネットワーク内のユーザの識別は、次の方法で行われます。
一意の電話番号または内線番号。
電子メール アドレスと同じように表示され、sip:<userID>@<domain> 形式を使用する一意の SIP アドレス。 ユーザ ID は、ユーザ名または E.164 アドレスのいずれかを使用できます。 Cisco Unified Communications Manager は、E.164 アドレスだけをサポートし、電子メール アドレスはサポートしていません。
Cisco Unified Communications Manager 上で SIP ルート パターンによってサポートされている電子メール アドレス形式 (employee@company.com)。
SIP および Cisco Unified Communications Manager
どのプロトコルを使用する場合も、コールを受信および発信するためには、シグナリング インターフェイス(トランク)またはゲートウェイのいずれかを作成する必要があります。 SIP に関しては、SIP トランクを設定する必要があります。
次の図に示すように、SIP トランクは、 Cisco Unified Communications Manager ネットワークを SIP プロキシ サーバが提供する SIP ネットワークに接続します。 他のプロトコルと同様に、SIP コンポーネントは、 Cisco Unified Communications Manager アーキテクチャのデバイス層に適合します。 H.323 プロトコルの場合、複数の論理 SIP トランクを Cisco Unified Communications Manager データベースに設定し、ルート グループ、ルート リスト、およびルート パターンに関連付けることができます。 1 つの論理 SIP インターフェイスに障害が発生した場合に冗長性を提供できるように、他の論理 SIP インターフェイスは同一のルート グループ リストにサービスを提供します。 複数の Cisco Unified Communications Manager ノードを SIP トランク デバイス プールに割り当てると、冗長性も実現できます。
SIP トランクはすべてのノードで同時に実行でき、 Cisco Unified Communications Manager は指定されたノードにアクセスできる使用可能な SIP トランクからランダムに選択できます。 システムは、長期間平均して、コア クラスタ内の 16 のノードすべてが均等に使用されるようにします。 これにより、システム リソースがアイドル状態のノードがある一方で、持続不可能なコール負荷を処理するノードがあるという状況が生じません。
(注)
SIP ICT での外部番号への折り返しはサポートされていません。
SIP トランクは、複数ポート ベースのルーティングをサポートしています。 Cisco Unified Communications Manager の複数の SIP トランクがポート 5060(デフォルト)を使用でき、このデフォルト値は、[SIP トランクセキュリティプロファイルの設定(SIP Trunk Security Profile Configuration)] ウィンドウで設定できます。 TCP/UDP では、SIP トランクはリモート ホストおよびローカル リスニング ポートを使用してルーティングを行います(リモート ホストは、IP、FQDN、または SRV で構成できます)。 TLS では、SIP トランクは、X.509 のサブジェクト名を使用してルーティングを行います。
SIP トランクおよび SIP ステーションからのサービス拒否(DoS)攻撃を防止するために、Cisco Unified Communications Manager は、プラットフォーム層に備えられている SIP UDP ポート スロットリング機能を使用します。 SIP UDP ポート スロットリングのしきい値は、10,000 パケットのバーストで秒あたり 35 パケットに設定されています。 スロットリングのしきい値は、システムのインストール中に設定され、変更できません。
SIP トランクの場合、 Cisco Unified Communications Manager は、設定された SIP トランクの宛先アドレスと IP アドレスが一致する SIP デバイスからのコールのみを受け入れます。 また、SIP メッセージが着信するポートは、SIP トランク上で設定されたポートと一致している必要があります。 コールが受け入れられると、 Cisco Unified Communications Manager は SIP プロファイル設定の [着信要求を新規トランクへと再ルーティングする基準(Reroute Incoming Request to new Trunk based on)] の設定値(コールが着信する SIP トランク上に設定されている)を使用して、コールを別の SIP トランクに再ルーティングするかどうかを決定します。 この設定値に応じて、 Cisco Unified Communications Manager は次のいずれかのタスクを実行します。
別の SIP トランクに再ルーティングしない。
contact ヘッダーにある IP アドレスまたはドメイン名とポート番号を解析し、その情報がいずれかの SIP トランクと一致するかどうかを確認する。SIP トランクが見つかった場合は、コールを再ルーティングします。 SIP トランクが見つからない場合は、コールが着信した SIP トランクがコールを処理します。
Call-Info ヘッダーの IP アドレスまたはドメイン名とポート番号を解析し、パラメータ purpose=x-cisco-origIP を探し、IP アドレスとポートがいずれかの SIP トランクに一致するかどうかを確認する。SIP トランクが見つかった場合は、コールを再ルーティングします。 SIP トランクが見つからない場合、またはこのパラメータが Call-Info ヘッダー内に存在しない場合は、コールが着信した SIP トランクがコールを処理します。
- メディア ターミネーション ポイント(MTP)デバイス
- [メディアターミネーションポイントが必須(Media Termination Point Required)] オプションが有効な SIP デバイスのリージョンの設定
- SIP サービス パラメータ
- トランクの SIP プロファイル
- SIP トランク セキュリティ プロファイル
- Cisco Unified CallManager と Cisco Unified Communications Manager の各リリース間の SIP トランク
- SIP トランクでの SIP フォーク
- SIP の透過および正規化
メディア ターミネーション ポイント(MTP)デバイス
Cisco Unified Communications Manager SIP デバイス(回線およびトランク)が常に MTP を使用するように設定できます。 MTP を使用しないように設定パラメータが設定されている場合(デフォルトの場合)、 Cisco Unified Communications Manager は、コールの DTMF 方式に互換性がなければ、動的に MTP を割り当てようとします。 たとえば、SCCP を実行する電話機はアウトオブバンドの DTMF だけをサポートし、SIP を使用する Cisco Unified IP Phone(7905、7912、7940、7960)は RFC2833 だけをサポートします。 DTMF 方式が同一でないため、 Cisco Unified Communications Manager は MTP を動的に割り当てます。 ただし、RFC2833 とアウトオブバンドをサポートし、SCCP を実行する電話機( Cisco Unified IP Phone 7971 など)が SIP を使用する Cisco Unified IP Phone 7940 にコールした場合、 Cisco Unified Communications Manager は、両方の電話機が RFC2833 をサポートしているため、MTP を割り当てません。 それぞれの電話機で同じタイプの DTMF 方式がサポートされているため、MTP は不要です。
[メディアターミネーションポイントが必須(Media Termination Point Required)] オプションが有効な SIP デバイスのリージョンの設定
リージョンの関係を設定する場合は、コールに使用されるすべてのデバイスにとって十分な帯域幅のオーディオ コーデックを選択する必要があります。 これには、同じリージョンのデバイスおよび別のリージョンのデバイスに対するコーデックの設定が含まれます。 SIP を使用するようにトランクまたはサードパーティの電話機を設定し、[メディアターミネーションポイントが必須(Media Termination Point Required)] が有効である場合、 Cisco Unified Communications Manager の管理ページの [MTP優先発信コーデック(MTP Preferred Originating Codec)] フィールドでは G.711 コーデックしか選択できません。 [メディアターミネーションポイントが必須(Media Termination Point Required)] オプションが有効な SIP トランクまたは SIP を実行するサードパーティ電話機をそのリージョンのデバイス プールに割り当てる場合、SIP デバイスと MTP デバイスの間のリージョンの関係は、帯域幅が同等以上のコーデック(G.711 コーデックまたはワイドバンド/AAC-LD(mpeg4-generic)コーデック)を使用するように設定されていることを確認する必要があります。
SIP サービス パラメータ
- SIP の相互運用性
- SIP タイマーとカウンタ
- サポートされるオーディオ メディア タイプ
- サポートされるビデオ メディア タイプ
- サポートされるアプリケーション メディア タイプ
- サポートされる T38fax ペイロード タイプ
SIP の相互運用性
SIP Interoperability Enabled サービス パラメータは、Cisco CallManager サービスをサポートしますが、このパラメータによって、SIP ステーションおよび SIP トランクの Session Initiation Protocol(SIP)を Cisco Unified Communications Manager がサポートするかどうかが決まります。 SIP を実行するデバイス(電話機やトランクなど)がある場合は、このパラメータを [True] に設定する必要があります。このパラメータを [False] に設定すると、 Cisco Unified Communications Manager は SIP メッセージを無視するため、SIP デバイスが機能しなくなります。つまり、SIP を実行する電話機が Cisco Unified Communications Manager に登録されず、SIP トランクが Cisco Unified Communications Manager と対話できなくなります。 デフォルト値は [True] です。 このパラメータの値を変更した場合は、Cisco CallManager サービスを再起動する必要があります。
SIP タイマーとカウンタ
SIP タイマーとカウンタは、設定可能なサービス パラメータとして機能します。 次の表では、各種の SIP タイマーとカウンタについて説明し、それぞれのデフォルト値と範囲値を示します。
(注)
SIP デバイスが TCP 転送を使用しているときにタイマーがタイムアウトすると、SIP デバイスは再転送を行いません。 デバイスの再試行は、TCP に依存します。
サポートされるオーディオ メディア タイプ
次の表は、サポートされている各種オーディオ メディア タイプの説明です。
表 3 サポートされるオーディオ メディア タイプ タイプ
エンコーディング名
ペイロード タイプ
コメント
G.711 u-law
PCMU
0
GSM Full-rate
GSM
3
G.723.1
G723
4
G.711 A-law
PCMA
8
G.722
G722
9
G.722.1
G7221
動的に割り当て
利用可能な範囲は 96 ~ 127
G.728
G728
15
G.729
G729
18
annex A と B のすべての組み合わせをサポート
RFC2833 DTMF
テレフォニー イベント
動的に割り当て
利用可能な範囲は 96 ~ 127
AAC-LD(mpeg4-generic)
mpeg4-generic
動的に割り当て
利用可能な範囲は 96 ~ 127
AAC-LD(MP4A-LATM)
MP4A-LATM
動的に割り当て
利用可能な範囲は 96 ~ 127
ILBC
iLBC
動的に割り当て
利用可能な範囲は 96 ~ 127
AMR
AMR
動的に割り当て
利用可能な範囲は 96 ~ 127
AMR-WB
AMR-WB
動的に割り当て
利用可能な範囲は 96 ~ 127
トランクの SIP プロファイル
SIP トランクと SIP エンドポイントは、SIP プロファイルを使用します。 SIP トランクは、SIP プロファイルを使用して [デフォルトテレフォニーイベントペイロードタイプ(Default Telephony Event Payload Type)]、[180で早期メディアを無効化(Disable Early Media on 180)]、および [着信要求を新規トランクへと再ルーティングする基準(Reroute Incoming Request to new Trunk based on)] 設定値を定義します。 SIP プロファイルの詳細については、エンドポイントの SIP プロファイルを参照してください。
Cisco Unified CallManager と Cisco Unified Communications Manager の各リリース間の SIP トランク
Cisco Unified Communications Manager リリース 6.0 以降および Cisco Unified CallManager リリース 4.0 以降(5.x を含む)は、SIP トランクで使用される場合、転送タイプとして TCP および UDP をサポートしています。 ただし、リリース 4.x は SIP コールごとに TCP 接続を 1 つ使用します。リリース 5.x および 6.x 以降では、複数の SIP コールに同一の TCP 接続で対応できます(これは TCP 接続の再利用と呼ばれます)。
次のシスコ製品は TCP をサポートしています。ただし、すべてが TCP の再利用をサポートしているわけではありません。
Cisco Unified CallManager リリース 4.1:TCP 接続の再利用は不可
Cisco Unified CallManager リリース 4.2:TCP 接続の再利用は不可
Cisco Unified CallManager リリース 5.0(2):TCP 接続の再利用が可能
Cisco Unified CallManager リリース 5.1(x):TCP 接続の再利用が可能
Cisco Unified Communications Manager リリース 6.0(x)以降:TCP 接続の再利用が可能
Cisco IOS 12.3(8)T 以降:TCP の再利用が可能
Cisco IOS 12.3(8)T よりも前:TCP の再利用は不可
次の表に、Cisco Unified CallManager と Cisco Unified Communications Manager の各リリース間および IOS ゲートウェイでサポートされる SIP トランク接続を示します。
リリース 6.x 以降のシステムが複数のコールを TCP ベースの SIP トランク経由で 4.x システムに発信した場合、4.x システムはコールを 1 つだけ接続します。 残りのコールは接続されません。4.x システムと 6.x 以降のシステムの間で SIP トランクを使用する場合は、[発信トランスポートタイプ(Outgoing Transport Type)] として UDP を使用するように両方のシステムを設定して、リリース 4.x システムと 6.x 以降のシステムとの間のコールが適切に接続されるようにする必要があります。
UDP を設定するには、 Cisco Unified Communications Manager の管理ページを使用します。
- Cisco Unified Communications Manager リリース 4.x システムに接続するリリース 6.0 以降のシステムでは、[SIPトランクセキュリティプロファイルの設定(SIP Trunk Security Profile Configuration)] ウィンドウで、[発信トランスポートタイプ(Outgoing Transport Type)] として UDP を選択します。
- リリース 6.x 以降のシステムに接続する Cisco Unified CallManager リリース 4.0 以降のシステムでは、[トランクの設定(Trunk Configuration)] ウィンドウで、[発信トランスポートタイプ(Outgoing Transport Type)] として UDP を選択します。
SIP トランクでの SIP フォーク
SIP トランク上で Cisco Unified Communications Manager によって送信されるコール設定(INVITE)要求は、SIP プロキシで複製し、複数の宛先に転送することができます(この処理はフォークと呼ばれます)。 Cisco Unified Communications Manager はフォークをサポートしていますが、次の制限事項があります。
Cisco Unified CallManager リリース 4.x は、6 つ以上の宛先からの暫定応答(180 Ringing など)を受け付けません。 応答のあった最初の 5 つ以外の宛先から、成功応答(200 Ok)が返されても受け付けません。
Cisco Unified CallManager リリース 5.x および Cisco Unified Communications Manager リリース 6.x は、21 以上の宛先からの暫定応答(180 Ringing など)を受け付けません。 応答のあった最初の 20 個以外の宛先から、成功応答(200 Ok)が返されても受け付けません。
セッション(メディア)記述を含む暫定応答(183 Session Progress)を受け付けた Cisco Unified CallManager リリース 4.x、Cisco Unified CallManager リリース 5.x、および Cisco Unified Communications Manager リリース 6.x は、同じ宛先からの成功応答(200 Ok)のみ受け付けます。セッション記述が暫定応答から成功応答に変更されても受け付けません。
Cisco Unified CallManager リリース 4.x、Cisco Unified CallManager リリース 5.x、および Cisco Unified Communications Manager リリース 6.x が暫定応答に対して(SIP の PRACK メソッドを使用して)受信応答するように設定されている場合、 Cisco Unified Communications Manager は最初に応答のあった宛先以外からの暫定応答および成功応答を受け付けません。
他の設定オプションは、 Cisco Unified Communications Manager でのダウンストリーム SIP フォークのサポートには影響しません。
SIP の透過および正規化
Cisco Unified Communications Manager は、PBX、ゲートウェイ、サービス プロバイダーなど、さまざまなエンドポイントに接続できます。 各エンドポイントがそれぞれ別個に SIP プロトコルを実装することにより、固有の相互運用性問題が発生する可能性があります。 SIP の透過および正規化によって、 Cisco Unified Communications Manager はさまざまな PBX およびサービス プロバイダーとシームレスに相互運用できるようになります。 正規化では、 Cisco Unified Communications Manager を経由するときにプロトコル レベルで着信および発信の SIP メッセージを修正できます。 透過を使用すると、 Cisco Unified Communications Manager で、1 つのコール レッグから別のコール レッグにヘッダー、パラメータ、およびコンテンツ本体を渡せるようになります。
正規化
メッセージを正規化するために、 Cisco Unified Communications Manager ではシステムにスクリプトを追加または更新し、これらのスクリプトを 1 つまたは複数の SIP トランクまたは SIP 回線に関連付けることができます。 作成する正規化スクリプトによって、既知または不明な SIP ヘッダーまたはコンテンツ本体の内容を保持、削除、または変更できます。 正規化スクリプトは、[トランクの設定(Trunk Configuration)] ウィンドウで SIP トランクに適用できます。また、[SIPプロファイルの設定(SIP Profile Configuration)] ウィンドウで SIP 回線に適用できます。
着信メッセージの場合、正規化は、ネットワークからメッセージを受信した直後に実行されます。 発信メッセージの場合、正規化は、ネットワークにメッセージを送信する直前に実行されます。 正規化は、相手側にあるトランクの接続先デバイスのタイプに関係なく、 Cisco Unified Communications Manager でトランクまたは SIP プロファイルにスクリプトが設定されているすべての SIP トランクまたは SIP 回線に適用されます。 正規化はコール レッグごとに実行されます。相手側のコール レッグが SIP である必要はありません。 コールには、SIP 回線から SIP トランク、SCCP から SIP トランク、MGCP から SIP トランク、H.323 から SIP トランクなどを指定できます。
スクリプト環境(さらにはコンテキスト)は、トランクまたはデバイスがリセットされるまで SIP トランクまたは SIP デバイスの有効期間を超えて保持されます。 スクリプト ライターは Lua モジュールを実装して、メッセージを操作するコールバック関数のセットを提供します(inbound_INVITE、outbound_180_INVITE など)。 この環境によって、SIP メッセージおよび SDP(ある場合)に一連の API 経由でアクセスできるようになります。
シスコのスクリプト環境ではメモリ消費が制御されます。 設定されているメモリ使用量のしきい値をスクリプトが超えた場合、エラーが発生します。
透過
透過とは、1 つのコール レッグから別のコール レッグに情報を渡す機能のことです。 SIP の透過によって、専用ヘッダーなどの着信 SIP メッセージ情報が、 Cisco Unified Communications Manager の片側から相手側に通過できるようになり、これによって、情報が送信 SIP メッセージに含まれるようになります。
透過的なパススルーは、SIP トランクから SIP トランクへのコールにのみ適用されます。
このリリースでは、 Cisco Unified Communications Manager は次のメッセージ タイプの透過をサポートしています。
不明なヘッダー(パススルー)
不明なパラメータ(パススルー)
不明なコンテンツ本体(パススルー)
初期 INVITE、reINVITE、UPDATE、INFO、BYE、18x、200(INVITE、UPDATE)、4/5/6xx
可能な場合には 1 対 1 のトランザクション(つまり、reINVITE が相手側の 1 つの reINVITE を開始する)
透過の詳細については、『Developer Guide for SIP Transparency and Normalization』を参照してください。
また、 Cisco Unified Communications Manager が REFER 要求に応じるのではなく、別のエンドポイントに渡すように REFER の透過を設定することもできます。 REFER の透過は、REFER(ブラインド転送の開始)を送信するエージェントがコールの両側から離れた地域に存在する、コール センター アプリケーションにおいて重要です。 REFER の透過を使用する場合、ローカルの Cisco Unified Communications Manager は、ローカル エージェントが削除されるとコールからドロップします。 REFER の透過を使用しない場合、コール シグナリングは、転送を開始するエージェントの Cisco Unified Communications Manager を経由して接続されたままです。 コールに関連付けられ、MTP デバイスを連続使用するロードは(初期コール時に割り当てられた場合)、転送を開始するエージェントの Cisco Unified Communications Manager とともに残り、新しいコールの通話者間のシグナリング遅延につながります。
REFER の透過は、[トランクの設定(Trunk Configuration)] ウィンドウ( )で 1 つ以上の SIP トランクと、refer-passthrough スクリプトまたはカスタム REFER 透過スクリプトを関連付けることによって有効にします。 [正規化スクリプト(Normalization Script)] グループ ボックスのフィールドを設定する必要があります。
カスタマー スクリプトの作成の詳細については、『Developer Guide for SIP Transparency and Normalization』を参照してください。 Cisco Unified Communications Manager にカスタマー スクリプトをアップロードするには、[SIP正規化スクリプト設定(SIP Normalization Script Configuration)] ウィンドウ( )を使用します。
SIP 正規化のトレース
Cisco Unified Communications Manager では、SIP 正規化のトレースを使用して、次の機能を実行できます。
コールの失敗のデバッグを目的とした、正規化されなかったメッセージと正規化されたメッセージの両方のトレース
スクリプトのデバッグを目的とした、スクリプトによるトレースの作成
システムの保守を目的とした、予期せぬスクリプトの失敗時のトレースの作成
スクリプトおよびコールの失敗をデバッグするには、 Cisco Unified Serviceability の [トレース設定(Trace Configuration)] ウィンドウの [SDI SIPコール処理の有効化(SDI Enable SIP Call Processing)] チェックボックスをオンにすることによって、トレースを有効にします。 このオプションを使用すると、正規化の前後で着信 SIP メッセージおよび発信 SIP メッセージをトレースできます。
(注)
正規化スクリプトでトレースを有効にしている場合のみ、SIP 正規化によってトレースが作成されます。
デバッグを目的としてスクリプトからトレースを生成するには、SIP トランクの場合は [トランクの設定(Trunk Configuration)] ウィンドウ、SIP 回線の場合は [SIPプロファイルの設定(SIP Profile Configuration)] ウィンドウで、Cisco Unified Communications Manager の管理ページの [トレースを有効にする(Enable Trace)] チェックボックスをオンにします。 オンにすると、Lua スクリプト ライターに提供される trace.output API および trace.format API によって SDI トレースが作成されます。
(注)
スクリプトをデバッグする場合のみトレースを有効にすることをお勧めします。 トレースはパフォーマンスに影響を与えるため、通常の稼働状況では有効にしなでください。
SDI トレースを有効にすると、 Cisco Unified Communications Manager によって、さらに次のトレースを含む SDI エラーレベルのトレースが作成されます。
SIP 正規化のアラーム
Cisco Unified Communications Manager によって、SIP 正規化スクリプトの使用とエラーが識別されます。つまり、スクリプトが開いたときと閉じたときのタイムスタンプ、およびエラーとリソース警告が発生したときのタイプスタンプが、システムによって保持されます。
SIPNormalizationScriptOpened
SIPNormalizationScriptClosed
SIPNormalizationResourceWarning
SIPNormalizationScriptError
SIPNormalizationAutoResetDisabled
これらのアラームを検索するには、 Cisco Unified Serviceability で CallManager アラーム カタログにアクセスします。
SIP 正規化のパフォーマンス カウンタ
シスコの SIP 正規化パフォーマンス オブジェクトには、スクリプトのステータスやエラーなど、正規化スクリプトのさまざまな面をモニタできるカウンタが含まれています。 パフォーマンス カウンタの動作は、SIP 回線と SIP トランクでわずかに異なります。
SIP 回線では、パフォーマンス カウンタは各スクリプトに 1 セットのみ含まれます。 2 つのエンドポイントが同じスクリプトを共有する場合も、これが該当します。
SIP トランクでは、これらのカウンタのインスタンスは、スクリプトに関連付けられている各デバイスによって新規に作成されます。 デバイスとスクリプトの関連付けを解消するか、または Cisco Unified Communications Manager の管理ページからデバイスを削除すると、これらのカウンタのインスタンスが削除されます。
詳細については、『Cisco Unified Communications Manager Real-Time Monitoring Tool Administration Guide』を参照してください。
依存関係レコード
どのトランクが特定の正規化スクリプトを使用するかを検索するには、Cisco Unified Communications Manager の管理ページの [SIP正規化スクリプト設定(SIP Normalization Script Configuration)] ウィンドウにある [関連リンク(Related Links)] ドロップダウン リスト ボックスで [依存関係レコード(Dependency Records)] を選択します。 [依存関係レコード要約(Dependency Records Summary)] ウィンドウに、スクリプトを使用しているトランクに関する情報が表示されます。 特定のトランクに関する詳細を検索するには、[トランク(Trunk)] リンクをクリックしてから、[依存関係レコード詳細(Dependency Records Detail)] ウィンドウでトランクの名前をクリックします。 依存関係レコードがシステムで使用可能になっていない場合、[依存関係レコード要約(Dependency Records Summary)] ウィンドウにメッセージが表示されます。
SIP の機能
- SIP エンドポイントと Cisco Unified Communications Manager 間の基本コール
- SIP エンドポイントと Cisco Unified Communications Manager 間の DTMF リレー コール
- MTP が割り当てられた場合に開始される補足サービス
- SIP エンドポイントが開始する補足サービス
- 拡張されたコール識別サービス
- Redirecting Dial Number Identification Service(RDNIS)
- リダイレクション
- SIP トランクの G. Clear コーデックのサポート
- SIP トランクでの Multilevel Precedence and Preemption のサポート
- SIP トランクでのセキュア V.150.1 Modem over IP のサポート
- SIP トランクでの G.729a コーデックと G.729b コーデックのサポート
- Microsoft Exchange を使用する場合の SIP T.38 相互運用のサポート
- SIP を介した QSIG トンネリングのサポート
- SIP PUBLISH
- SIP OPTIONS
- SIP 早期オファー
SIP エンドポイントと Cisco Unified Communications Manager 間の基本コール
早期メディアの使用
PSTN は、早期メディアにインバンドの進行情報(呼び出しトーンまたはビジー信号など)のシグナリングを提供しますが、これは SIP では行われません。 発信側は、コーデック使用状況、IP アドレス、ポート番号などのセッション記述プロトコル(SDP)情報を、発信 INVITE メッセージに含めます。 この応答として、終端側は自身のコーデック、IP アドレスおよびポート番号を 183 Session Progress メッセージで送信し、早期メディアの候補であることを示します。
183 Session Progress 応答は、メッセージ本体にメディア セッションに関する情報が含まれることを示します。 180 Alerting および 183 Session Progress メッセージの両方に、コールへの応答が行われる前に早期メディア セッションの確立を許可する SDP を含めることができます。
早期メディアが、接続の前に SIP エンドポイントに配信される必要がある場合、 Cisco Unified Communications Manager は常に SDP を含む 183 Session Progress メッセージを送信します。 Cisco Unified Communications Manager は SDP を含む 180 Alerting メッセージを生成しませんが、SDP を含む 180 Alerting メッセージの受信はサポートしています。
[SIP プロファイルの設定(SIP Profile Configuration)] ウィンドウには、[180 で早期メディアを無効化(Disable Early Media on 180)] チェックボックスがあります。 ローカル呼び出し音を着信側電話機で再生し、200OK 応答の受信と同時にメディアを接続するには、このチェックボックスをオンにします。
SIP エンドポイントと Cisco Unified Communications Manager 間の DTMF リレー コール
- Dissimilar DTMF 方式の、SIP デバイスからゲートウェイまたは対話型音声応答(IVR)システムへの DTMF ディジットの転送
- Dissimilar DTMF 方式の DTMF ディジットの生成
Dissimilar DTMF 方式の、SIP デバイスからゲートウェイまたは対話型音声応答(IVR)システムへの DTMF ディジットの転送
Dissimilar DTMF 方式の DTMF ディジットの生成
SIP エンドポイントと Cisco Unified Communications Manager 間の DTMF リレー コールの説明のように、SIP は、DTMF インバンド ディジットを送信し、 Cisco Unified Communications Manager はアウトバンド ディジットだけをサポートします。 ソフトウェア MTP デバイスは、アウトバンドの DTMF トーンを受信し、インバンドの DTMF トーンを SIP クライアントに生成します。
この図では、メディア ストリーミングから開始し、MTP デバイスには DTMF ダイナミック ペイロード タイプであることが通知されています。
MTP が割り当てられた場合に開始される補足サービス
システムは、SCCP エンドポイントが SIP コールで開始するすべての補足サービスをサポートしています。 SCCP エンドポイントは、接続された SIP デバイスに影響を与えることなく Cisco Unified Communications Manager 内部で管理されます。 当初の接続情報に加えられる変更は、Remote-Party-ID ヘッダーを使用する re-INVITE または UPDATE メッセージで更新されます。 Remote-Party-ID ヘッダーの詳細については、『SIP Extensions for Caller Identity and Privacy』を参照してください。
ブラインド転送時の呼び出し音では、ブラインド転送について説明します。ブラインド転送は、 Cisco Unified Communications Manager がメディア アナウンスを提供する必要があるため、補足サービスと同様に固有の動作になります。
ブラインド転送時の呼び出し音
SCCP が開始するブラインド転送では、コールが接続されてから Cisco Unified Communications Manager がトーンまたは呼び出し音を生成する必要があります。 つまり、 Cisco Unified Communications Manager は、ブラインド転送のメディア アナウンスを提供します。
ブラインド転送は、転送のターゲットがコールに応答する前に、転送側の電話機が発信者を宛先の回線に接続する際に行われます。 ブラインド転送は、転送側の 1 つが呼び出し音の鳴っている電話機(呼び出し音が受信されている)に発信者を接続するか、または発信者を第三者に接続する前に第三者と話をする、打診転送(在席転送)とは異なります。
SCCP IP Phone が開始するブラインド転送は、最初に接続された SIP デバイス ユーザへの呼び出し音を許可します。 Cisco Unified Communications Manager は、呼び出し音を実行するために、MTP デバイスとともに配置されることがあるアナンシエータ ソフトウェア デバイスを使用します。
アナンシエータを使用すると、 Cisco Unified Communications Manager は、SCCP IP Phone、ゲートウェイ、およびその他の IP テレフォニー デバイスに対して事前定義されたトーンおよびアナウンスを再生できます。 これらの事前定義されたトーンおよびアナウンスは、ユーザにコール ステータスに関する詳細情報を提供します。
SIP エンドポイントが開始する補足サービス
コール保留
Cisco Unified Communications Manager は、SIP デバイスまたは Cisco Unified Communications Manager デバイスが開始するコール保留と取得をサポートします。 たとえば、SCCP IP Phone のユーザが別のユーザが保留にしているコールを取得する場合、 Cisco Unified Communications Manager は re-INVITE メッセージを SIP プロキシに送信します。 re-INVITE メッセージには、現在の接続先を反映させるために、更新された Remote-Party-ID 情報が含まれています。 Cisco Unified Communications Manager が最初にコールを開始した場合、Remote-Party-ID ヘッダーの Party フィールドには発信側が設定されます。そうでない場合は着信側が設定されます。 Party フィールド パラメータの詳細については、拡張されたコール識別サービスを参照してください。
自動転送
Cisco Unified Communications Manager は、SIP デバイスまたは Cisco Unified Communications Manager デバイスが開始する自動転送をサポートします。 SIP デバイスが自動転送のリダイレクションを要求すると、 Cisco Unified Communications Manager が要求を処理します。 Cisco Unified Communications Manager が開始する自動転送には、SIP のリダイレクション メッセージは使用されません。 Cisco Unified Communications Manager は、内部でリダイレクションを処理し、Remote-Party-ID ヘッダーを介して発信側の SIP エンドポイントに接続先の情報を伝送します。
拡張されたコール識別サービス
ここでは、 Cisco Unified Communications Manager の次の SIP 識別サービスおよび Cisco Unified Communications Manager が SIP にこれらの識別サービスを伝送する方法について説明します。
Cisco Unified Communications Manager では、これらの識別サービスを提供するための柔軟な設定オプションにより、コールごとの設定や、SIP シグナリング インターフェイスごとの静的な事前設定を行うことができます。
- 発呼者回線 ID の表示(CLIP)および発呼者名の表示(CNIP)
- 発呼者回線 ID の制限(CLIR)および発呼者名の制限(CNIR)
- SIP CLI 処理の変更
- 接続側回線 ID の表示(COLP)および接続先名の表示(CONP)
- 接続側回線 ID の制限(COLR)および接続先名の制限(CONR)
発呼者回線 ID の表示(CLIP)および発呼者名の表示(CNIP)
Cisco Unified Communications Manager は、 Cisco Unified Communications Manager からの初期 INVITE メッセージの From ヘッダーおよび Remote-Party-ID ヘッダーに発呼者回線(または番号)および発呼者名の表示情報を含めます。 From ヘッダーのフィールドは、要求の発信側を示します。 Cisco Unified Communications Manager は、18x、200、および re-INVITE メッセージの Remote-Party-ID ヘッダーを使用して、接続先の名前および識別情報を伝送します。 Remote-Party-ID ヘッダーには、発信者 ID およびプライバシーの詳細も含まれます。 発信者 ID サービスの場合、 Cisco Unified Communications Manager は、Remote-Party-ID ヘッダーの Party フィールドに発信側を設定します。
(注)
Remote-Party-ID ヘッダーの詳細については、『Cisco IOS SIP Configuration Guide』を参照してください。
発呼者回線 ID の制限(CLIR)および発呼者名の制限(CNIR)
発呼者回線(または番号)の制限および発呼者名の制限設定は、SIP シグナリング インターフェイス レベルまたはコール単位で行われます。 SIP トランク レベルの設定は、コール単位の設定より優先されます。 コールごとに設定するには、『 Cisco Unified Communications Manager アドミニストレーション ガイド』の拡張されたコール識別サービスを参照してください。
また、発呼者回線および発呼者名の制限は、それぞれ個別に設定できます。 たとえば、番号だけを制限し、名前の表示を許可するように選択できます。
例 1
発呼者名を制限した場合、 Cisco Unified Communications Manager は、From ヘッダー内の発呼者名を設定可能な文字列に設定します。 Cisco Unified Communications Manager によって、Remote-Party-ID ヘッダーの表示フィールドには実際の名前が含まれるように設定されますが、Privacy フィールドは次のように name に設定されます。
From: "Anonymous" <sip:8005550100@localhost> Remote-Party-ID: "Bob Jones"<sip:9728135001@localhost; ;user=phone>; party=calling;screen=no;privacy=name例 2
発信番号を制限した場合、 Cisco Unified Communications Manager は From ヘッダーの発呼者回線を省略します。ただし、 Cisco Unified Communications Manager は、Remote-Party-ID ヘッダーには発呼者回線を含め、Privacy フィールドを privacy=uri に設定します。
From: "Bob Jones" <sip:@localhost> Remote-Party-ID: "Bob Jones"<sip:8005550100@localhost; ;user=phone>; party=calling;screen=no;privacy=uriSIP CLI 処理の変更
Cisco Unified Communications Manager の SIP 機能では、発信 SIP コールに発呼側 ID を 2 セット利用でき、SIP ヘッダーに基づいて着信 SIP コールに CLI(発呼者回線 ID)を選択できます。
ID が 2 セットの発信 SIP コール
スイッチボード データを SIP トランク上で設定している場合、[元の発信者ID DNと発信者名をIDヘッダーに維持する(Maintain Original Caller ID DN and Caller Name in Identity Headers)] をオンにすると、発信 SIP メッセージの元の発信者 ID は SIP ヘッダー内のデータによって上書きされません。
ID が 2 セットの発信 SIP コール(SIP 回線)
[元の発信者ID DNと発信者名をIDヘッダーに維持する(Maintain Original Caller ID DN and Caller Name in Identity Headers)] を SIP トランク上で設定すると、すべての発信 SIP コールに影響します。 この機能は、SIP プロファイルを使用して SIP 回線デバイスのグループにも設定できます。 [SIPプロファイル(SIP Profile)] ページの電話機セクションに、SIP トランク上でスイッチボード データをミラーするために、[発信者ID DN(Caller ID DN)] および [発信者名(Caller Name)] という 2 つのテキストボックスが新たに追加されています。 [SIPプロファイル(SIP Profile)] ページのトランク セクションに、[設定済み回線デバイス発信者情報のパススルーを許可(Allow Passthrough of Configured Line Device Caller Information)] というチェックボックスが新たに追加されています。
SIP コールの着信 CLI
Cisco Unified Communications Manager では、SIP インターフェイスでの ID の選択、表示、および制限を拡張できます。 対応する SIP 電話機を制御するために、SIP トランクと SIP プロファイルの表示に使用する設定フィールドを新たに追加することで、この新しい機能を提供しています。
発信 ID 機能の導入により、着信 SIP コールで発呼側 ID を 2 セット利用できるようになりました。 コール処理用の ID 選択に役立つよう、着信 CLI(発呼者回線 ID)が導入されています。 選択は、[発呼者回線IDの表示(Calling Line Identification Presentation)] の新しいリスト ボックスを使用して制御します。
一部のネットワークでは、保持された 2 セットの ID として、ネットワーク指定の ID(信頼済み)およびユーザ指定の ID(信頼済みでない)を利用できます。 SIP コールでは、P-Asserted-Identity(PAI)、P-Preferred-Identity(PPI)、および Remote-Party-ID(RPID)が含まれた ID ヘッダーがネットワーク指定の ID を伝送し、FROM ヘッダーがユーザ指定の ID を伝送します。 Cisco Unified Communications Manager の以前のリリースでは、発信コールに ID を 1 セットのみ利用できました。 ID ヘッダーと FROM ヘッダーの ID はまったく同じであり、ネットワーク指定の ID とユーザ指定の ID を区別できませんでした。 一般に、管理者は、電話番号(DN)と表示名によって各ユーザ デバイスを設定します。 この DN からの発信コールでは、ID ヘッダーと FROM ヘッダーの両方で電話番号と表示名が伝送されます。 管理者は、SIP トランク上に別の ID を設定することもできます。 この ID(スイッチボード ID とも呼ばれます)は、個々の発信者の ID を隠すために使用し、 発信コールの [SIPトランク(SIP Trunk)] の [発信者情報(Caller Information)]セクションで設定できます。 設定には、[発信者ID DN(Caller ID DN)] と [発信者名(Caller Name)] の 2 つのフィールドを使用します。 この設定が有効になっている場合、発信者の元の電話番号と表示名が上書きされます。
Cisco Unified Communications Manager で用意されている設定を使用すると、管理者は、スイッチボード ID と元の発信者 ID の両方を有効にできます。 スイッチボード ID は FROM ヘッダーで伝送され、元の発信者 ID は ID ヘッダーで伝送されます。 この設定を各 SIP トランクまたは SIP ユーザ デバイスで有効にできます。
ネットワーク内からの着信コールの場合、Cisco Unified Communications Manager では、ID ヘッダーで伝送されるネットワーク指定の ID または FROM ヘッダーで伝送されるユーザ指定の ID を受け入れるための設定を利用できます。 Cisco Unified Communications Manager には、コールごとに 1 セットの ID が保持されます。
(注)
PAI、PPI および RPID という 3 つの異なる ID ヘッダーがサポートされます。 [SIPトランク(SIP trunk)] ページの [コールルーティング情報(Call Routing Information)] の設定に応じて、発信要求または発信応答にこれらのヘッダーが 1 つまたは 2 つ表示されることがあります。
元の発信者 ID を持つ発信コールが、[コールルーティング情報(Call Routing Information)] にデフォルトで設定されます。 デフォルトでは、[リモートパーティID(Remote-Party-Id)] チェックボックスと [アサート済ID(Asserted-Identity)] チェックボックスがオンになり、[アサート済タイプ(Asserted-Type)] フィールドと [SIPプライバシ(SIP Privacy)] フィールドが [デフォルト(Default)] に設定されます。
スイッチボード ID を持つ発信コールを設定するには、[SIPトランク(SIP trunk)] 設定ページの [コール(Calls)] セクションにある [発信者ID DN(Caller ID DN)] と [発信者名(Caller Name)] を設定します。 これらのフィールドで、スイッチボード ID が提供されて発信者の ID が非表示になります。
Cisco Unified Communications Manager デバイスから発信されるコールの場合、ID ヘッダーはデバイスの回線 ID に設定され、From ヘッダーは ID ヘッダーと同じ値かスイッチボード情報のいずれかに設定されます。 これは、プロビジョニング可能であり、Cisco Unified Communications Manager を変更する必要はありません。 [SIPトランク(SIP trunk)] 設定ページの新しいチェックボックス [元の発信者ID DNと発信者名をIDヘッダーに維持する(Maintain Original Caller ID DN and Caller Name in Identity Headers)] を使用して、発信 SIP メッセージの表示名と番号を制御できます。 発信 SIP メッセージに対して有効になっている場合、[発信者ID DN(Caller ID DN)] の設定値によって電話番号は上書きされず、[発信者名(Caller Name)] の設定値によって発信 ID ヘッダーの発信者名は上書きされません。
接続側回線 ID の表示(COLP)および接続先名の表示(CONP)
Cisco Unified Communications Manager は、接続側回線および名前の識別を補足サービスとして使用し、発呼側に接続先の番号と名前を通知します。 From ヘッダーのフィールドは、要求の発信側を示します。 Cisco Unified Communications Manager は、18x、200、および re-INVITE メッセージの Remote-Party-ID ヘッダーを使用して、接続側の情報を伝送します。 Cisco Unified Communications Manager は、Remote-Party-ID ヘッダーの Party フィールドに着信側を設定します。
接続側回線 ID の制限(COLR)および接続先名の制限(CONR)
例 1
Cisco Unified Communications Manager は、Remote-Party-ID ヘッダーの表示フィールドには実際の名前が含まれるように設定しますが、Privacy フィールドを privacy=name に設定します。
Remote-Party-ID: "Bob Jones"<8005550100@localhost; user=phone>; party=called;screen=no;privacy=name
Redirecting Dial Number Identification Service(RDNIS)
Cisco Unified Communications Manager は、初期 INVITE メッセージの SIP Diversion ヘッダーを使用して、利用可能な RDNIS 情報を伝送します。
リダイレクション
次のシナリオは、[SIPプロファイルの設定(SIP Profile Configuration)] ウィンドウの [アプリケーションによるリダイレクト(Redirect by Application)] チェックボックスをオフにした場合の動作です。 この設定では、SIP ネットワークからのリダイレクションは SIP スタック レベルで処理され、システムはリダイレクション要求をすべて受け取り、リダイレクション応答の Contact ヘッダー内のアドレスへ転送します。 コールは、リダイレクション応答を受信したトランクに自動的に転送されます。 コールのリダイレクト方法を処理または制限する追加のルーティング ロジックは適用されていません。 たとえば、発信 INVITE への 3xx 応答内のリダイレクション接続先が Cisco Unified Communications Manager に登録済みの電話機で、スタックがリダイレクションを処理している場合、コールは Cisco Unified Communications Manager 電話機へ直接ルーティングされずに、同じトランクへリダイレクトして戻されていました。 制限された電話番号(国際電話番号など)へリダイレクトされると、スタック レベルでのリダイレクション処理により、コールがブロックされずにルーティングされます。
[アプリケーションによるリダイレクト(Redirect by Application)] チェックボックスがオンの場合、Cisco Unified Communications Manager は、ルーティング エンジン経由で Contact ヘッダーを渡し、ルーティング ロジックを使用してリダイレクション要求を Contact ヘッダー内のアドレスに転送します。 SIP 要求では、Contact ヘッダーのホスト部分がローカル Unified CM でない場合、SIP ルート パターンで Contact ヘッダーのホスト部分を発信トランクにマッピングする必要があります。そうしない場合、Unified CM はコールをルーティングできません。
管理者は、[アプリケーションによるリダイレクト(Redirect by Application)] チェックボックスで次の処理を実行できます。
特定のコーリング サーチ スペースを、3xx 応答内で受信したリダイレクト接続先に適用する。
コールが正しくルーティングされるよう、リダイレクト接続先に番号分析を適用する。
サービス パラメータで設定できるリダイレクション(再帰リダイレクション)の番号を制限することで、DOS 攻撃を防止する。
リダイレクションの実行中に、別の機能を起動できるようにする。
Unified CM による SIP 要求のルーティング方法の詳細については、『Cisco Unified Communications System SRND』の「Dial Plan」の章の「Routing of SIP Requests in Unified CM」を参照してください。
SIP トランクの G. Clear コーデックのサポート
G. Clear(クリア チャネル)コーデックを使用すると、SIP トランクおよび Cisco Unified Communications Manager を使用する音声ネットワークを通じて、Digital Signal-0(DS-0)データ回線のタンデム スイッチングを実現できます。 G.Clear コーデックは、G.711 コーデックとほぼ同等の 64 kb/s の帯域幅(IP パケットのオーバーヘッドは含まず)を使用します。 Cisco Unified Communications Manager は、音声コールのコーデックを選択し、メディア テーブル内の G.711 mulaw および G.711 alaw コーデックよりも G. Clear コーデックを優先します。
G.Clear コーデックまたは G.729 コーデックが必要となるのは、リージョンの内部です。リモート リージョンへのコールには、他の低帯域幅コーデックを使用します。 G.729 コーデックは音声用に最適化されており、使用帯域幅が G. Clear コーデックよりも大幅に小さくなります。 G.Clear コーデックは、低帯域幅のリージョン内で実行することを明示的に許可することのみを目的としたオプションです。
G. Clear コーデックのコールでは、IP パケットのヘッダーに個別の Differentiated Services Code Point(DSCP)値が必要です。 これは従来の音声コーデックおよびビデオ コールと異なり、MLPP 優先順位によって一意にタグ付けされる必要があります。 これらの機能には、サービス パラメータが適用されます。
G. Clear コーデックのコールは、RTP ダイナミック ペイロード タイプ 125 を使用して、ゲートウェイを通じて一貫性が維持されます。 このダイナミック ペイロード タイプは、 Cisco Unified Communications Manager を使用して静的に割り当てられます。
SIP トランクで G. Clear コーデックがサポートされるため、クラスタ間の操作が可能になります。 このコーデックは、SIP Session Description Protocol(SDP)メッセージでサポートされるメディア タイプとしてネゴシエートされ、RTP ペイロード タイプ 125 に静的に符号化されます。
(注)
G. Clear コーデックは、メディア ターミネーション ポイントではサポートされません。
別の T1 PRI トランク上の VoIP ネットワークから発信される着信 ISDN データ コール(制限デジタル情報および無制限デジタル情報)に対する ISDN ベアラ機能は、サポートされています。
次の図に、G.Clear コーデックを有効にした SIP トランクの一般的な配置を示します。
2 つの SIP サービス パラメータ、SIP Route Class Naming Authority および SIP Clear Channel Data Route Class Label は、SIP トランクで G. Clear コーデックを有効化します。 SIP Route Class Naming Authority パラメータは、SIP シグナリングで使用される、ルート クラスを表すラベルの名前付け機関および名前付けコンテキストを表します。 この値には、名前付け機関が所有するドメインの名前を指定します。 デフォルトは cisco.com です。
特定のルート クラス値をシグナリングするため、 Cisco Unified Communications Manager は、ドメイン名と適切なルート クラス ラベル(SIP Clear Channel Data Route Class Label サービス パラメータで定義されたもの)を SIP シグナリングに組み込みます。
SIP Clear Channel Data Route Class Label は、SIP シグナリングにおけるクリア チャネル データのルート クラスを表します。 このパラメータと SIP Route Class Naming Authority パラメータによって、SIP クリア チャネル データのルート クラス値を表す完全なシグナリング構文が作成されます。 デフォルトは ccdata です。
ルート クラス シグナリングが有用となるのは、ルート クラスおよびクリア チャネル データ ルート クラスに基づいてルーティング決定を行う TDM ネットワークとインターワーキングする場合です。 このパラメータで指定されたデフォルト ドメイン名は、シスコ スイッチ間の相互対話に適用されます。 このパラメータは、ベンダー(または配置)固有の要件に応じて変更できます。 遠端のスイッチは、このパラメータで設定されたものと同一の値を受信します。
G. Clear コーデックを使用する H.323 ICT は、サポートされていません。
G. Clear コーデックを使用する Skinny Client Control Protocol(SCCP)は、サポートされていません。
G. Clear コーデックを使用する T1 および E1 CAS は、サポートされていません。
G. Clear コーデックを使用する RSVP は、サポートされていません。
E1 トランクでの MLPP はサポートされていません。
発信 G. Clear コーデック コールのエコー キャンセレーションおよびゼロ抑制は無効になります。
ITU H.244 で定義されている個々の DS-0 回線のボンディングは、端末装置が実行します。このため、VoIP ネットワークを通過し、個々の DS-0 回線を整列するためのフレームはサポートされていません。
Cisco Unified Communications Manager の [ファスト スタート(Fast Start)] および [メディア ターミネーション ポイントが必須(Media Termination Point Required)] オプションは、G. Clear が有効化されている状態では機能しません。
G.Clear コーデックを使用する DTMF シグナリングは、サポートされていません。
(注)
Cisco Unified Communications Manager は、G.Clear がコールのコーデックに選択されているかどうかに関係なく、G.Clear がコーデックのリストにアドバタイズされているすべてのコールで DTMF の設定値を無視します。
G.Clear コールに対する早期オファー
Cisco Unified Communications Manager は、G.Clear データ コール(クリア チャネル)に対する制限付き早期オファーをサポートしています。 G.Clear コールに対する早期オファー機能により、メディア ターミネーション ポイントを使用せずにデータ コールをネゴシエートする早期オファーを実行可能なサードパーティの SIP ユーザ エージェントをサポートできます。 MTP は、G.Clear コーデックをサポートしていません。
SIP デバイスに対して、[メディアターミネーションポイントが必須(Media Termination Point Required)] と [G.Clearコールに対する早期オファー(Early Offer for G.Clear Calls)] の両方を有効にすると、G.Clear コーデックがオファー内に存在する場合でも、MTP が割り当てられません。 MTP が割り当てられるのは、コールが G.Clear ではなく、MTP が必要な場合だけです。
G.Clear コールに対する早期オファー機能は、標準ベースの G.Clear(CLEARMODE)と、CCD、G.nX64、X-CCD などのシスコ独自の Session Description Protocol(SDP)の両方をサポートしています。
[G.Clearコールに対する早期オファー(Early Offer for G.Clear Calls)] を有効または無効にするには、 Cisco Unified Communications Manager の管理ページの [SIPプロファイルの設定(SIP Profile Configuration)] ウィンドウで次のいずれかのオプションを選択します。
SIP トランクでの Multilevel Precedence and Preemption のサポート
Cisco Unified Communications Manager の管理は、SIP トランクで Multilevel Precedence and Preemption(MLPP)を使用する Voice over Secured IP(VoSIP)ネットワークをサポートしています。 Resource Priority ヘッダーおよび SIP の Reason ヘッダーがメッセージに追加されます。 SIP シグナリングに関係するリソースは、 Cisco Unified Communications Manager によって優先順位が設定されます。これは、緊急の場合または輻輳が発生した場合に、これらのリソースを解放してネットワークが機能できるようにするためです。 リソース プライオリティ ネームスペース ネットワーク ドメインおよびリソース プライオリティ ネームスペース リストを設定することで、必要に応じて優先順位設定を有効にできます。
リソース プライオリティ ネームスペース ネットワーク ドメイン
SIP シグナリングのリソース プライオリティ ネームスペース ネットワーク ドメインは、レガシー TDM MLPP ネットワークで使用される ISDN プレシデンス情報要素(IE)および ISDN ユーザ パート(ISUP)プレシデンス パラメータと似ています。
リソース プライオリティ ネームスペース ネットワーク ドメインは発信コールに含まれており、コールを SIP トランクに転送するためのトランスレーション パターンまたはルート パターンに基づいています。 次のメッセージには、設定済みのリソース プライオリティ ネームスペース ネットワーク ドメインが含まれています。
着信コールの場合、このネットワーク ドメインが許容ネットワーク ドメインのリストと比較されます。 着信コールのネットワーク ドメインが検証されるのは、コールが Cisco Unified Communications Manager エンドポイントで終端する場合のみです。 他のコール タイプの場合、このネットワーク ドメインは、いずれもローカル設定と照合して検証されません。 許容されるネットワーク ドメインの設定は、SIP プロファイルに追加されている必要があります。
SIP トランクでのセキュア V.150.1 Modem over IP のサポート
セキュア V.150.1 のサポートは、SIP トランクおよびクラスタ間 SIP トランクを介した IP Secure Terminal Equipment(STE)とレガシー(BRI またはアナログ)STE 間での Modem over IP(MoIP)通信に基づいていました。 SIP トランクは、発信コールの Session Description Protocol(SDP)情報を転送し、着信コールの MoIP SDP 情報が受信されたときは Cisco Unified Communications Manager に通知します。 デバイスは、SIP を使用して V.150.1 セキュア コールをネゴシエートすることで、クラスタ間でコールを発信できます。
(注)
SIP トランクでの MoIP については、設定は不要です。
SIP トランクでの G.729a コーデックと G.729b コーデックのサポート
G.729a および G.729b は、SIP トランクを通じて開始されるコールに使用可能な、低帯域幅のコーデックです。 この機能を必要とするのは、遅延メディア コールをサポートせず、G.711 などの高帯域幅コーデックを使用しないエンドポイントであることに注意してください。
早期提供コールの場合は、MTP が事前に割り当てられている必要があるため、この機能を使用するには、外部の MTP デバイスまたはトランスコーダ デバイスを設定する必要があります。 ソフトウェア MTP は、SIP トランクでの G.729 をサポートしていません。
この機能は、4 つの G.729 コーデック(G.729、G.729a、G.729b、および G.729ab)をすべてサポートしていますが、システムでは、G.729 と G.729a、および G.729b と G.729ab を区別できません。 したがって、これらのコーデックを SIP トランクに対して設定するためのオプションは、 Cisco Unified Communications Manager の管理ページでは 2 つのみ提供されます(G729/G729a と G729b/G729ab)。
SIP トランクに G.729 コーデックが適用されるのは発信コールのみで、着信コールには影響しません。 コール中に、システムがコーデックを G.729 から他のコーデックに切り替えることはできません。
Microsoft Exchange を使用する場合の SIP T.38 相互運用のサポート
T.38 標準は、IP ネットワークを使用した Group 3 ファクシミリ(ファクス)通信のリアルタイム転送のための ITU-T 勧告に基づいています。 Cisco Unified Communications Manager には、Microsoft Exchange との T.38 相互運用が実装されており、コールをオーディオから T.38 ファクスに切り替えることができます。
次に、Microsoft Exchange Server がファクス機へのコールを確立する手順を示します。
- Exchange サーバが、ファクス機とのオーディオ コールを確立します。
- ファクス機が、ファクス トーン(CNG)を Exchange サーバに送信します。
- Exchange サーバがファクス トーンを認識し、コールを T.38 ファクス(または T.38 ファクス リレー)コールとして再ネゴシエートしようとします。
Cisco Unified Communications Manager の管理ページを使用して、T.38 ファクス通信をサポートする SIP プロファイルを設定できます。 このプロファイルは、SIP トランクにのみ適用され、SIP を実行する電話機およびエンドポイントには適用されません。
SIP を介した QSIG トンネリングのサポート
Cisco Unified Communications Manager では、IP ネットワーク上の SIP トランクを介して、別の Cisco Unified Communications Manager または QSIG-SIP ゲートウェイに向かう QSIG メッセージと SIP メッセージ間のインターワーキングをサポートし、QSIG コールと、メッセージ受信のインジケータ(MWI)、コール転送、自動転送、折り返し、Call Completion、パス変換、ID サービスなどの QSIG 機能をサポートします。 これらの機能を受け入れるために、 Cisco Unified Communications Manager では、トンネル化プロトコルとして QSIG を使用する SIP トランクを設定できます。 SIP トランクの設定の詳細については、 『Cisco Unified Communications Manager アドミニストレーション ガイド』のSIP トランクの G. Clear コーデックのサポートを参照してください。
(注)
SIP ゲートウェイから着信した Remote Party ID(RPID)ヘッダーによって QSIG コンテンツが干渉を受け、それにより折り返し機能で予期しない動作が発生する場合があります。 QSIG コンテンツへの干渉を防ぐには、SIP ゲートウェイで RPID ヘッダーを無効にします。
トランク サービス タイプとして Cisco Intercompany Media Engine(IME)を選択して SIP トランクを作成する場合、[トンネル化プロトコル(Tunneled Protocol)] フィールドのデフォルトは [QSIG] になります。 Cisco IME トランクで QSIG 機能を動作させるには、トンネル化プロトコルを QSIG にする必要があります。
(注)
Cisco Unified Communications Manager は、Cisco IME トランクでの折り返しについては、接続維持モードのみをサポートしています。
SIP PUBLISH
SIP PUBLISH は、IP Phone のプレゼンス情報を Cisco Unified Communications Manager リリース 6.0 以降から Cisco Unified Presence リリース 6.0 以降に SIP トランク経由で送信するための最適なメカニズムを提供します。このメカニズムによって、パフォーマンスが向上します。 また、サイレントやモビリティなどの回線ごとのプレゼンス情報も提供します。 サポートされるのは発信 PUBLISH だけです ( Cisco Unified Communications Manager リリース 6.0 以降は、プレゼンスに関して Cisco Unified Presence リリース 1.0 と通信するときに SUBSCRIBE/NOTIFY を使用します)。
PUBLISH は、イベント状態を発行するための SIP メソッドです。 イベント状態をユーザ エージェントから発行するためのフレームワークは、RFC 3903 で規定されています。発行先となるのは、このイベント状態を集約し、関係するパーティに SIP Events フレームワークを通じて配信するエンティティです。 RFC 3903 に記述されているメカニズムを拡張すると、適切なイベント パッケージで処理される任意のイベント状態を発行することができます。
また、RFC 3903 は、プレゼンス ユーザ エージェントによってプレゼンス集約側にプレゼンス状態を発行するための、このフレームワークの厳格な使用方法も定義しています。
SIP トランクは、 Cisco Unified Communications Manager に登録されている電話機のプレゼンス情報を Cisco Unified Presence と連携して提供します。 リリース 5.0 では、 Cisco Unified Presence は、プレゼンス情報を Cisco Unified CallManager から SIP 登録メカニズムを通じて取得していました。
Cisco Unified Communications Manager から Cisco Unified Presence への相互対話は、SIP 登録メカニズムが使用されている場合は正常に機能しますが、このメカニズムはパフォーマンス低下の原因になります。 Cisco Unified Communications Manager と Cisco Unified Presence の両方で、監視対象となる電話機ごとに、それぞれ個別の登録ダイアログが維持される必要があります。 さらに、1 台の電話機を 2 人のユーザが監視し、各ユーザの監視ルールが異なっている場合、 Cisco Unified Presence は、同じ番号に関する 2 つの SUBSCRIBE 要求を Cisco Unified Communications Manager SIP トランクに発行します。
Cisco Unified Communications Manager リリース 6.0 以降では、SIP トランクは、PUBLISH を Cisco Unified Presence とのプレゼンス相互対話のメカニズムとして使用できます。 Cisco Unified Communications Manager はイベント発行エージェント(EPA)として動作し、管理対象の電話機のプレゼンス情報を発行します。 Cisco Unified Presence はイベント状態集約システム(ESC)として動作し、発行されたプレゼンス情報を受信および集約して、監視者の電話機の表示を更新します。
Cisco Unified Communications Manager および Cisco Unified Presence の高レベル アーキテクチャの概要
次の図に、 Cisco Unified Communications Manager、 Cisco Unified Presence、および Cisco Unified IP Phone がどのように連携して動作するかを示します。
Cisco Unified Communications Manager がすべての IP Phone を管理し、 Cisco Unified Communications Manager が SIP または SCCP インターフェイスを使用して電話機を制御します。
IP Phone と Cisco Unified Presence の間には HTTP インターフェイスも存在します。 このインターフェイスは、電話機の画面を更新するために Cisco Unified Presence で使用されます。 また、ユーザのログイン/ログアウト アクティビティを検出するために、 Cisco Unified Presence でも使用されます。
SIP トランク インターフェイスは、プレゼンス データを Cisco Unified Communications Manager と Cisco Unified Presence の間で交換するために使用されます。
Cisco Unified Communications Manager の管理ページにおける PUBLISH の設定のヒント
Cisco Unified Communications Manager の管理ページで SIP トランクを PUBLISH 用に設定するときは、次の設定のヒントを参考にしてください。
SIP の [トランクの設定(Trunk Configuration)] ウィンドウで、 Cisco Unified Presence(宛先アドレス)にアクセスするように SIP トランクを設定します。
ヒント
マルチノード クラスタでの分散処理のパフォーマンスを最大限まで高めるには、デフォルトのデバイス プールを使用するように SIP トランクを設定することをお勧めします。
Cisco CallManager サービスの [サービスパラメータ設定(Service Parameters Configuration)] ウィンドウにある [CUP PUBLISH Trunk] フィールドで、設定済みの SIP トランクを選択します。
Cisco Unified Presence エンド ユーザを設定し( )、ライセンス ユニットをユーザに割り当てます( )。
エンド ユーザをライン アピアランスに関連付けます( Cisco Unified Presence へのアクセスに使用する DN をクリックします。 [エンドユーザの関連付け(Associate End Users)] ボタンをクリックします。 [ユーザの検索/一覧表示(Find and List Users)] ウィンドウで、 Cisco Unified Presence にアクセスするエンド ユーザを選択します。
)。 [電話の設定(Phone Configuration)] ウィンドウで、ユーザが
(注)
1 つのライン アピアランスを 5 人までのエンド ユーザに関連付けることができます。
SIP Trunk PUBLISH での DND サポート:DND は、リリース 6.0 以降ではデバイス単位で適用されます。このため、デバイスが DND 状態に移行した場合、このデバイスに関連付けられている Cisco Unified Presence 対応のすべてのライン アピアランスが発行される可能性があります。 デバイスが DND 状態に移行した場合は、DND に加えてビジー/アイドル ステータスも一緒に発行されるため、 Cisco Unified Presence で柔軟にデータを処理することができます。
共有回線:電話機 A と電話機 B が DN 1000 を共有している場合、ユーザが電話機 A の受話器を取って回線 1000 上でコールを発信すると、 Cisco Unified Communications Manager は回線 1000 がビジーであることを Cisco Unified Presence に通知します。 この情報によって、監視者は DN 1000 のすべての回線がビジーになっていると誤解します。 電話機 B の回線 1000 はアイドルのままであるため、これは正確な情報を表していません。 Cisco Unified Communications Manager は、電話機 A の回線 1000 がビジーであることを Cisco Unified Presence に通知します。 リリース 6.0 以降では、 Cisco Unified Communications Manager はライン アピアランス別に発行を行います。 システムは、ライン アピアランスを(DN とデバイスの)ペアと見なします。
複数パーティション: Cisco Unified Communications Manager は DN のプレゼンス ステータスを発行し、DN が関連付けられているパーティションも示します。
ユーザ名の関連付け:共有回線と複数パーティションがサポートされている場合、 Cisco Unified Presence は、電話機ごとに 1 つの DN という前提で動作できません。また、 Cisco Unified Communications Manager システム全体にわたって 1 つのパーティションという前提で動作することもできません。 リリース 6.0 以降では、ライン アピアランスをエンド ユーザに関連付けることができるため、ライン アピアランスに関連付けられているエンド ユーザに代わって SIP トランクがそのライン アピアランスのステータスを発行します。つまり、このステータスを使用して Cisco Unified Presence 対応の回線を識別できます。 ライン アピアランスがエンド ユーザに関連付けられている場合、システムは Cisco Unified Presence 対応であると見なされます。したがって、そのライン アピアランスのプレゼンス情報が発行されます。
Serviceability のパフォーマンス カウンタ
Cisco Unified Serviceability は、PUBLISH に関連する次のパフォーマンス カウンタを収集し、表示します。
Cisco Unified CallManager リリース 5.x には次のパフォーマンス カウンタがありますが、これらの値は PUBLISH 機能の影響を受けます。
セキュリティ上の推奨事項
RFC 3903 では、アクセス制御、サービス拒絶攻撃、リプレイ アタック、および中間者攻撃などの問題に対処するため、TLS とダイジェスト認証の使用が推奨されています。 Cisco Unified Communications Manager および Cisco Unified Presence は TLS とダイジェスト認証をサポートしているため、リリース 6.0 での変更点はありません。 管理者は、 Cisco Unified Communications Manager および Cisco Unified Presence で TLS とダイジェスト認証を設定し、有効にすることができます。 また、IPSec を TLS の代替手段として使用することもできます。
BAT のサポート
Cisco Unified Presence ユーザを Cisco Unified Communications Manager に移行する場合は、次の BAT ツールが役立ちます。
BAT では、 Cisco Unified Communications Manager を 5.x から 6.0 以降にアップグレードした後に、すべての Cisco Unified Presence ライセンス取得済みユーザ、それらのユーザのプライマリ内線番号、およびそれらのユーザに関連付けられるデバイス ライン アピアランスを検証するためのツールが提供されます。 このツールが必要になるのは、(すべてのバックエンド登録が削除され、 Cisco Unified Presence ユーザの新しいライン アピアランスベースのプレゼンスを使用できるようにする必要があるため) Cisco Unified Presence のアップグレードまたは移行中に Cisco Unified Communications Manager に接続するときです。 移行を実行するため、BAT はエクスポート機能と更新機能を使用します。 エクスポート csv の形式は、User ID、Device、Directory Number、および Partition です。 最後の 3 つのカラムがライン アピアランスを形成します。
[エクスポート(Export)] ウィンドウおよび [更新(Update)] ウィンドウにアクセスするには、
および を選択します。[エクスポート(Export)] ウィンドウおよび [更新(Update)] ウィンドウには、[CUPユーザのラインアピアランスのみエクスポート(Export line appearances for CUP users only)] チェックボックス(および [CUPユーザのラインアピアランスのみ更新(Update line appearance for CUP users only)] チェックボックス)があります。 このチェックボックスをオンにすると、 Cisco Unified Presence ユーザのエクスポート操作または更新操作が実行されます。 Cisco Unified Presence ユーザ以外のユーザは、エクスポートおよび更新されません。
SIP OPTIONS
Cisco Unified Communications Manager で SIP OPTIONS メソッドを使用すると、SIP トランクでリモート宛先のステータスを追跡できます。 発信の OPTIONS を送信して着信応答メッセージを確認することにより、リモート ピアで新しい要求を受信する準備が整っているかどうかを SIP トランクが認識します。 SIP トランクは、到達不能なリモート ピアに対して新しいコールの設定を試行しません。このアプローチによって、迅速なフェールオーバーが可能になります。
Cisco Unified Communications Manager では、SIP トランク上のキープアライブ メカニズムとして SIP OPTIONS を使用します。 Cisco Unified Communications Manager は、SIP トランク上の設定済み宛先アドレスに、定期的に OPTIONS 要求を送信します。 リモート SIP デバイスが応答に失敗するか、または SIP エラー応答を返信すると、 Cisco Unified Communications Manager は設定に応じて、他のトランクを使用するかまたは別のアドレスを使用することによって、コールの再ルーティングを試行します。
OPTIONS 要求はコールのコンテキスト外に配置されます。そのため、コールが SIP トランク上になくても、 Cisco Unified Communications Manager は要求によって障害を検出できます。 このアプローチを使用すると、後続のコールをより迅速に再ルーティングできます。 SIP OPTIONS メソッドにより、コールが再ルーティングされる前に、長時間タイムアウトしたり再試行が遅延したりすることがなくなります。
Cisco Unified Communications Manager の設定のヒント
Cisco Unified Communications Manager の管理ページで OPTIONS を使用できるように SIP トランクを設定する場合は、次の設定のヒントを参考にしてください。
SIP OPTIONS を有効にするには、SIP プロファイルを設定します ( Cisco Unified Communications Manager の管理ページで メニュー オプションを使用します)。標準 SIP プロファイルをコピーして、そのコピーの名前を(OPTIONS プロファイルなどに)変更します。 [サービスタイプ "なし(デフォルト)" のトランクの接続先ステータスをモニタするためにOPTIONS Pingを有効にする(Enable OPTIONS Ping to monitor destination status for Trunks with Service Type "None (Default)")] チェックボックスをオンにします。 SIP OPTIONS は、デフォルトでは無効になっています。
作成した SIP プロファイルで、必要に応じて 2 つの要求タイマーを更新します。 1 つ目のタイマーは SIP トランクがサービス中または部分的にサービス中のときに使用され、2 つ目のタイマーは SIP トランクがサービス中ではないときに使用されます。 Cisco Unified Communications Manager は、設定済みのトランスポート プロトコル(UDP、TCP など)を使用して、SIP トランクの設定済み宛先アドレスに対して SIP OPTIONS 要求を開始します。
作成した SIP プロファイルで、SIP OPTIONS の再試行タイマーとカウンタを設定します。
SIP トランクを設定します(まだ設定していない場合)。 SIP トランクのトランク サービス タイプには、[なし(デフォルト)(None(default))] を指定する必要があります。 コール制御ディスカバリ、クラスタ間のエクステンション モビリティ、Intercompany Media Services などのダイナミック SIP トランクはサポートされません。
[トランクの設定(Trunk Configuration)] を使用して、宛先情報を設定します。 複数の宛先を設定できます。 宛先アドレスが(ドット付き IP アドレスではなく)ホスト名として設定されており、複数のアドレスが戻される場合、応答が受信されるまで、戻りアドレス宛に OPTIONS メッセージが送信されます。 すべての戻りアドレスが使用され尽くす前に応答が受信されなかった場合、SIP トランクには、ターゲットが「ダウン状態」であることを示すマークが付けられます。
SIP トランクの宛先に複数の IP アドレスが含まれるか、宛先が複数の IP アドレスに解決される場合、コール ルーティングはランダム選択アルゴリズムを使用して、SIP トランク上の次のコール用の宛先 IP アドレスを選択します。 SIP OPTIONS がトランクに対して有効になっている場合、選択した IP アドレスの状態情報によって、INVITE を送信するか、または次の宛先に進むかが決定されます。
SIP OPTIONS およびセキュア SIP トランク
SIP OPTIONS メソッドでは、SIP トランク セキュリティ プロファイルで [転送タイプ(Transport Type)] 設定が [TLS] に設定されているセキュア SIP トランクをサポートしています。 他の要求または応答(INVITE など)とは異なり、 Cisco Unified Communications Manager は、OPTIONS 要求または応答については [X.509のサブジェクト名(X.509 Subject Name)] の設定(SIP トランク セキュリティ プロファイルで設定)を確認しません。 そのため、OPTIONS 要求または応答に基づいてリモート宛先に使用可能のマークを付けることはできますが、コール設定要求(INVITE など)が理由コード 403 Forbidden で失敗することがあります。 OPTIONS 要求を送信する Cisco Unified Communications Manager か OPTIONS 要求を受信して応答する Cisco Unified Communications Manager のいずれかで [X.509のサブジェクト名(X.509 Subject Name)] を誤って設定すると、この障害が発生することがあります。
シナリオ 1
Unified CM 1 は SIP トランクを介して Unified CM 2 に OPTIONS 要求を送信し、200 OK 応答を受信します。 Unified CM 2 の SIP トランク セキュリティ プロファイルの [X.509のサブジェクト名(X.509 Subject Name)] が誤って設定されています。そのため、Unified CM 1 では Unified CM 2 に使用可能のマークが付きます。 INVITE が Unified CM 1 から Unified CM 2 に送信されると、Unified CM 2 は Unified CM 1 に 403 Forbidden メッセージを送信します。 次の図に、このシナリオを示します。
シナリオ 2
Unified CM 1 は SIP トランクを介して Unified CM 2 に OPTIONS 要求を送信し、200 OK 応答を受信します。 Unified CM 1 の SIP トランク セキュリティ プロファイルの [X.509のサブジェクト名(X.509 Subject Name)] が誤って設定されていても、Unified CM 1 は Unified CM 2 に使用可能のマークを付けます。 この場合、Unified CM 1 から Unified CM 2 への INVITE 要求は失敗します。 次の図に、このシナリオを示します。
SIP OPTIONS とダイジェスト認証
SIP トランクに対してダイジェスト認証が有効になっている場合(対応する SIP トランク セキュリティ プロファイルで [ダイジェスト認証を有効化(Enable Digest Authentication)] チェックボックスがオンになっている)、OPTIONS 要求に対する 401(未許可)応答を受信した時点で、リモート宛先に使用可能のマークが付けられます。 401 応答を受信した後、OPTIONS はダイジェスト クレデンシャルとともに再送信されます。リモート側からのクレデンシャル確認時に、OPTIONS 要求に対する 200 OK 応答が受信されます。
SIP レルム(最初の 401 応答の受信時)またはダイジェスト クレデンシャルが不一致(リモート側)の場合の OPTIONS 要求では、リモート宛先に使用可能のマークが付けられていても、後続の INVITE 要求が失敗します。
SIP 早期オファー
サードパーティの SIP デバイスとの相互運用性を拡張するために、 Cisco Unified Communications Manager では、発信側エンドポイントのメディア機能およびメディア ポート情報が使用可能な場合に、MTP を必要とせずに発信ボイスおよびビデオ コールに対する早期オファーを有効にするように、SIP トランクを設定できます。
発信側コール設定
早期オファー トランクの発信コール セットアップのために、 Cisco Unified Communications Manager は、発信側デバイスのメディア ポート、コーデック、および発信側デバイスの IP アドレス(可能な場合)を含む SDP を取り込み、発信側のメディア情報を利用できない場合にかぎり、早期オファーの MTP を挿入し、複数のコーデックをサポートする MTP が挿入される場合は複数のコーデックをアドバタイズします。 以前のリリースでは、管理者が発信 SIP トランクで MTP の必須または E2E RSVP を有効にしている場合にのみ、 Cisco Unified Communications Manager は早期オファー SDP を提供していました。 早期オファー機能によって、より高い割合の発信の早期オファー SIP トランク コールが MTP を必要とせずに発信されるため、必要な MTP リソースの数が減り、サードパーティの PBX との相互互換性が向上します。
Cisco Unified Communications Manager では、次のいずれかのデバイスのコール開始時に、早期オファー(MTP を必要としない)をサポートします。
SIP 電話機
SCCP v20 でサポートされている SCCP 電話機。getPort 機能を使用してメディア ポート情報を提供
MGCP ゲートウェイ
着信の H323 FastStart コール
着信の早期オファー SIP トランクコール
(注)
メディア ポート情報を使用できないエンドポイント(H323 SlowStart コール、遅延オファー SIP コール、従来の SCCP 電話機など)の場合、 Cisco Unified Communications Manager はこれまでどおりに MTP を割り当て、初期 INVITE で SDP を提供します。
(注)
上記のリストにあるデバイスから開始されたコールについては、DTMF/コーデックの不一致、着信または発信トランクで TRP が必須、発信側で MTP が必須などの他の理由により MTP が必要になることがあります。
通話中設定
Cisco Unified Communications Manager は、基本的な保留/再開操作などの通話中の操作や、転送や会議などの補足サービスを実行しているときのサードパーティのデバイスとの相互運用性も拡張します。 以前のリリースの Cisco Unified Communications Manager では、非アクティブ SDP(a=inactive 属性)を含む INVITE を送信してメディア パスの中断を示し、遅延オファー INVITE を送信して保留音を挿入するかメディア ストリームを再開し、さらに 200 OK に送受信オファー SDP が含まれることを想定していました。 サードパーティのデバイスは、200 OK で送受信オファー SDP ではなく非アクティブ オファー SDP を提供することが多いため、メディア パスが非アクティブ状態のままになり、コールが破棄されます。
Cisco Unified Communications Manager では、 Cisco Unified Communications Manager によって通話中 INVITE での非アクティブ SDP または送信専用 SDP の送信が禁止されるように、早期オファー SIP トランクのパラメータを設定できます。 このパラメータが有効の場合、 Cisco Unified Communications Manager は、保留中または他機能の起動中に既存のメディア ストリームを中断せずに、SIP トランク デバイスを MOH またはアナンシエータ デバイスに直接接続します。 同様に、 Cisco Unified Communications Manager は、MOH またはアナンシエータ ストリームを中断せずに、コール再開時に SIP トランク デバイスを回線側デバイスに直接接続します。 遠端のメディア ストリームが非アクティブに設定されないようにすることによって、 Cisco Unified Communications Manager で常にメディア パスを再開できるようにする必要があります。
(注)
保留/再開時または補足サービスのメディア再開時に、サードパーティの SIP デバイスとの相互運用性で問題が発生している場合にのみ、非アクティブ SDP または送信専用 SDP の禁止を設定する必要があります。 この設定を有効にした場合、 Cisco Unity Connection などの特定のエンドポイントが動作しないことがあります。
GetPort 機能のサポート
Cisco Unified Communications Manager では、SIP トランクに接続されているデバイスで GetPort 機能がサポートされている場合に、SIP トランク上の初期コールまたは通話中コールの遅延オファー INVITE に応答する送受信 SDP も提供しています。 Cisco Unified Communications Manager は、SIP トランクが早期オファー用に設定されているかどうかに関係なく、この機能を提供します。 デバイスで GetPort 機能がサポートされていない場合、 Cisco Unified Communications Manager では送受信オファーを提供するための別の MTP は挿入しません。
コールが接続された後、 Cisco Unified Communications Manager が SCCP デバイスまたは MTP からのオーディオ/ビデオ/データ ポートの受信を待機する時間を変更するには、Port Received Timer After Call Connection サービス パラメータを設定します。 このパラメータで指定された時間が経過する前に、 Cisco Unified Communications Manager でビデオ ポートの受信に失敗すると、コールは最初に双方向オーディオでのみ確立されます。 双方向ビデオは、別のオファー/アンサー トランザクションが完了した後、確立されることがあります。 このタイマーで指定された時間が経過する前に、 Cisco Unified Communications Manager でオーディオ ポートの受信に失敗すると、 Cisco Unified Communications Manager は別のオファー/アンサー トランザクションを試行して、オーディオとビデオの両方の双方向メディア パスを確立します。
タイマーの時間を増やすと、Unified CM でポート情報を受信できる時間が長くなりますが、コールの開始時またはコール中にオーディオ/ビデオが遅延する場合があります。 発信側デバイスが CAST プロトコル バージョン 3 を使用している CTI または Unified Video Advantage アプリケーションの場合、アプリケーションで接続を開いてポート情報を取得するために必要な時間と適合するように、タイマーを調整することが必要になる場合があります。
早期オファーの制限事項および相互作用
早期オファー機能に適用される制限事項および相互作用は、次のとおりです。
早期オファー機能を使用するには、MTP で IOS バージョン 15.1(2)T 以降を使用している必要があります。
SRTP およびビデオ: Cisco Unified Communications Manager では、発信側デバイスの機能に応じて、初期 INVITE の SDP でセキュアなオーディオ機能やビデオ機能をアドバタイズできます。
エンドツーエンド(E2E)の RSVP:E2E RSVP では、初期 INVITE に SDP を含めることによって早期オファーを提供するため、早期オファー機能と E2E RSVP 機能を [SIPプロファイルの設定(SIP Profile Configuration)] ウィンドウで同時に指定することはできません。 [RSVP Over SIP] ドロップダウン リスト ボックスで [E2E] を選択すると、[音声コールとビデオコールに対する早期オファーのサポート(必要な場合はMTPを挿入)(Early Offer support for voice and video calls (insert MTP if needed))] チェックボックスは無効になります。
シングル ナンバー リーチ(SNR):設定時にメディア機能が使用可能になっている SIP 電話機、SCCP v20 電話機、または発信側デバイスから、トランクのシングル ナンバー リーチ(SNR)宛先へのコールが開始されると、INVITE SDP に発信側デバイスの IP アドレスとポートが含められます。 SNR トランク コールに早期オファーを提供するために MTP が必要な場合、別々の MTP ポートがそれぞれの SNR 宛先に割り当てられます。
IPv6: Cisco Unified Communications Manager は、SIP トランクに早期オファーが設定されていても、次の IPv6 シナリオの場合は遅延オファー INVITE を送信します。
遅延オファー SIP コールと早期オファーのインターワーキングの場合、 Cisco Unified Communications Manager は MTP を挿入して、発信コール レッグで SDP を提供します。 INVITE にはオーディオ回線のみが含まれます。 発信レッグで送信される INVITE には、オーディオ メディア回線のみが含まれます。 発信側ビデオ機能およびデバイスの暗号化キーは、タンデム クラスタでは使用できないため、オーディオまたはビデオ メディア回線には暗号化属性がありません。 結果として、発信 INVITE SDP には、MTP の IP とオーディオ ポートが含まれ、オーディオ メディア回線の SRTP キーや属性は含まれず、ビデオ メディア回線も含まれません。
SlowStart H323 コールと早期オファーのインターワーキングの場合、 Cisco Unified Communications Manager は MTP を挿入して、発信コール レッグで SDP を提供します。 INVITE にはオーディオ回線のみが含まれます。 発信レッグで送信される INVITE には、オーディオ メディア回線のみが含まれます。 発信側ビデオ機能およびデバイスの暗号化キーは、タンデム クラスタでは使用できないため、オーディオまたはビデオ メディア回線には暗号化属性がありません。 結果として、発信 INVITE SDP には、MTP の IP とオーディオ ポートが含まれ、オーディオ メディア回線の SRTP キーや属性は含まれず、ビデオ メディア回線も含まれません。 Cisco Unified Communications Manager では、メディア カットスルー後に H323 レッグからビデオ TCS を受信すると、コール アドミッション制御(CAC)でビデオが許可されており、割り当て済みの MTP でパススルーとマルチメディアがサポートされている場合には、ビデオも含まれるようになります。
Cisco Unified Communications Manager は、次のシナリオの場合に遅延オファー INVITE を送信します。
通話中のメディア再ネゴシエーション
コール保留:MOH サーバがネゴシエートされたオーディオ コールと同じコーデックをサポートしていないことがあるため、 Cisco Unified Communications Manager は MOH を挿入する場合、通話中に遅延オファー INVITE を送信します。 Cisco Unified Communications Manager では、メディアを再ネゴシエートするために、遠端の完全なコーデック リストを必要とします。
コール再開
次の状況のいずれかが発生した場合、 Cisco Unified Communications Manager で遅延オファー INVITE が送信されるか、または発信コールが失敗します。
割り当て済みの MTP、トランスコーダ、または TRP で getPort 機能がサポートされていない場合に、発信 SIP トランク レッグが早期オファーに対して有効になっていると、 Cisco Unified Communications Manager は早期オファーを提供するための別のメディア リソースを割り当てません。
SIP トランクで [信頼されたリレーポイントを使用(Use Trusted Relay Point)] の設定が有効になっており( Cisco Unified Communications Manager は別のメディア リソースを割り当てません。 この状況は、MTP または RSVP エージェントが TRP に設定されていない場合に発生します。
)、割り当て済みのメディア リソースで TRP 機能がサポートされていないか、またはメディア ポートの提供に失敗している場合、Fail Call If MTP Allocation Fails サービス パラメータまたは Fail Call If TRP Allocation Fails サービス パラメータの設定に応じて、 Cisco Unified Communications Manager で遅延オファーが送信されるか、またはコールが失敗します。
早期オファー SIP トランク上の打診コール レッグで帯域内呼び出し音またはアナウンスを提供するブラインド転送で呼び出し音を提供するように、SIP トランクに UPDATE および PRACK を設定してください。 トランクが PRACK に対して有効になっていない場合、または遠端のデバイスで UPDATE がサポートされていない場合、転送される側は呼び出し音を受信しません。
以前のリリースと同様に、オファー SDP 内のコーデックの順序は変更できません。 Cisco Unified Communications Manager は内部リストに基づいて、通常は高いものから低いものとなるようにコーデックを並べます。 この問題を回避するには、SIP 正規化スクリプトを作成して、オファー SDP 内のコーデックの順序を並べ替えます。
トレース
SIP トランクのトレース
001685280 |2010/05/25 13:50:31.980 |100 |AppInfo |||SIPCdpc(1,100,67,9)||1,100,67,9.1^*^*|//SIP/SIPCdpc(1,67,9)/ci=30801944/ccbId=14961/scb Id=0/StartTransition: requireInactiveSDPForMidcallMediaChange=0, isTrunkEnabledForVoiceEO=1
(注)
1 は、このコールに対して早期オファーが有効になっていることを示し、0 は早期オファーが無効になっていることを示します。
001685289 |2010/05/25 13:50:32.001 |100 |SdlSig |PolicyAndRSVPRegisterReq |wait |RSVPSessionMgr(1,100,91,1) |SIPCdpc(1,100,67,9) |1,100,49,1.100206^172.18.199.61^SEP001319ACCA00 |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] CI= 30801944 Branch= 0 reg=Default cap=0 loc=0 MRGLPkid=1db1ba42-9575-e3dc-ba78-fb11d56db546 PrecLev=5 VCall=F VCapa=F VCapCount=0 regiState=0 medReq=0 dataCapFl=2 IsEmccD=F EmccDName=to-ccm84 rcId= ipMode=0 eoType=2 getPort=F sRTP=F cryptocap=0 tm=16 DTMF(wantRecep=1 provOOB=1 suppMeth=1 Cfg=1 PT=0 reqMed=0) hInCodec=F distMed=F mediaEP=F rsvpQoSType=0 qosFallback=F status=0 sipOfferNeededInd=T hasSDP=F geolocInfo={geolocPkid=, filterPkid=, geolocVal=, devType=8}
(注)
eoType の値は、なし(0)、G.Clear に対する早期オファー(1)、音声およびビデオに対する早期オファー(2)、G.Clear 音声およびビデオに対する早期オファー(3)です。
001685353 |2010/05/25 13:50:32.087 |100 |SdlSig |PolicyAndRSVPRegisterRes |outCall_waitRSVPRes |SIPCdpc(1,100,67,9) |RSVPSession(1,100,93,5) |1,100,49,1.100207^172.18.199.61^SEP001319ACCA00 |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] CI= 30801944 Branch= 0 Status=1 rsvpPol=1 vCall=F e2eRSVPInserted=F eoStatus=1 hasSDPMsg=T RSVPAgent: confID =0 ci =0 capCt =0 reg= mtpType =2 agentCt =0 agentAllo =0 RemoAgent=F DevCap=0 ipAddrMode=0
(注)
eoStatus の有効な値は、なし(0)、音声およびビデオに対する早期オファー(1)、G.Clear に対する早期オファー(2)、遅延オファーの続行(3)、失敗したコール(4)です。
早期オファー コールに関与している StationD(SCCP デバイス)のトレース
001685325 |2010/05/25 13:50:32.064 |100 |SdlSig |DeviceMediaInfoReq |restart0 |StationD(1,100,50,13) |RSVPSession(1,100,93,5) |1,100,49,1.100206^172.18.199.61^SEP001319ACCA00 |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] CI= 30801943 confID=30801943 callRefID=30801943 counter=1 mediaType=1 iptype=0 PPID=16777217 reqCode=1 001685327 |2010/05/25 13:50:32.064 |100 |SdlSig |StationPortReq |restart0 |StationD(1,100,50,13) |StationCdpc(1,100,51,1) |1,100,49,1.100206^172.18.199.61^SEP001319ACCA00 |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] confID=30801943 PPID=16777217 CI=30801943 transportType=1 addrType=0 mediaType=1 .001685328 |2010/05/25 13:50:32.081 |100 |AppInfo |||StationInit(1,100,49,1)||1,100,49,1.100207^172.18.199.61^SEP001319ACCA00|StationInit: (0000013) PortRes IpAddr=0x399eb00, Port=31780, RTCPPort=0, confID=30801943, PPID=16777217 001685330 |2010/05/25 13:50:32.081 |100 |SdlSig |StationPortRes |outgoing_call_proceeding3 |StationCdpc(1,100,51,1) |StationD(1,100,50,13) |1,100,49,1.100207^172.18.199.61^SEP001319ACCA00 |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] CI= 30801943 confID=30801943 ptpID=16777217 ipaddr=0x{ac,12,c7,3d,0,0,0,0,0,0,0,0,0,0,0,0} port=31780 =.type=0. RTCPPort=0 mediaType=1 001685331 |2010/05/25 13:50:32.082 |100 |SdlSig |DeviceMediaInfoRes |wait |RSVPSessionMgr(1,100,91,1) |StationCdpc(1,100,51,1) |1,100,49,1.100207^172.18.199.61^SEP001319ACCA00 |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] CI= 30801943 confID=30801943 callRefID=30801943 mediaType=1 iptype=0 PPID=16777217 reqCode=1 port=31780 RTCPPort=0 ipAddrType=0 ipv4=172.18.199.61 status=0MTP 割り当てが必要な場合の早期オファー コールのメディア レイヤ トレース
001686458 |2010/05/25 13:50:48.535 |100 |SdlSig |AuEarlyOfferConnectReq |waitForAll |MediaCoordinator(1,100,125,1) |RSVPSession(1,100,93,6) |1,100,49,1.100222^172.18.201.82^SEP0014F2E982F1 |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] Party1: CI=30801945 capCount=7 region=Default xferMode=4 mrid=0 audioId=0 videoCap=F dataCap=2 activeCap=0 cryptoCapCount=0 flushIns=0 dtmCall=0 dtmPrimaryCI=0 IFPid=(0,0,0,0) dtMedia=F honorcodec=F EOType=0 MohType=0 Party2: CI=30801946 capCount=0 region=Default xferMode=16 mrid=0 audioId=0 videoCap=F dataCap=2 activeCap=0 cryptoCapCount=0 flushIns=0 dtmCall=0 dtmPrimaryCI=0 IFPid=(0,0,0,0) dtMedia=F honorcodec=F EOType=2 MohType=0 videoCall=F confID =0 ci =0 capCt =0 reg= mtpType =2 agentCt =0 agentAllo =0 RemoAgent=F DevCap=0 ipAddrMode=0 mtpInsReason=32 hasSDP=F
(注)
mtpInsReason の有効な値は、なし(0)、TRP 側 B(1)、TRP 側 A(2)、トランスコーダ側 A(4)、MTP 側 A(8)、DTMF 不一致(16)、早期オファー(32)です。
001686676 |2010/05/25 13:50:48.646 |100 |SdlSig |AuEarlyOfferConnectReply |wait |RSVPSession(1,100,93,6) |MediaCoordinator(1,100,125,1) |1,100,49,1.100223^172.18.197.154^MTP_sinise |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] ciParty1=30801945 ciParty2=30801946 devicePidParty1=(1,100,50,3) devicePidParty2=(1,100,67,10) err=0 videoFlag=F hasSDP=T.
(注)
メディア リソース割り当ての失敗に対する有効なエラーコードの有効な値は、エラーなし(0)、TRP 割り当て側 B(1)、TRP 側 A(2)、トランスコーダ側 A(3)、MTP 側 A(4)、DTMF 不一致の MTP(5)、早期オファーの MTP(6)です。
早期オファーの問題のトラブルシューティング
早期オファーの問題をトラブルシューティングする方法については、次の表を参照してください。
Cisco Unified Communications Manager SIP エンドポイントの概要
Cisco Unified IP Phone 7911、7941、7961、7970、および 7971 は、 Cisco Unified Communications Manager Back to Back User Agent(B2BUA)環境で SIP エンドポイントとして配置されます。 電話機と他のネットワーク コンポーネントとの基本的なインターフェイスは SIP が提供します。 SIP 以外に、たとえば、IP アドレス割り当て用の DHCP、ドメイン名からアドレスへの解決に使用する DNS、イメージおよび設定データをダウンロードするための TFTP など、各種の機能に対してさまざまなプロトコルが使用されます。
ここでは、例を図で示し、B2BUA 環境とピアツーピア環境について簡単に説明します。
上図は、メイン サイトと営業所の配置を示した Cisco Unified Communications Manager B2BUA ネットワークの単純な例を示しています。 各サイトには、SIP を実行する電話機と SCCP を実行する電話機が混在しています。 メイン サイトには、 Cisco Unified Communications Manager クラスタとボイスメール サーバがあります。 メイン サイトと営業所サイトにある電話機はそれぞれ、プライマリ、セカンダリ、および三次の Cisco Unified Communications Manager セットをホームにしています。 これによって、個々の Cisco Unified Communications Manager サーバに障害が起きた場合の、コール制御の冗長性が提供されます。
メイン サイトの SIP を実行している電話機は、すべてのセッション招待を Cisco Unified Communications Manager へ送信します。 ルーティング設定と宛先を基に、 Cisco Unified Communications Manager はコールを SIP または SCCP を実行している別の電話機へローカルに送り届けたり、メイン サイトの音声ゲートウェイを通じて IP WAN から営業所内のいずれかの電話機へ送り届けたり、メイン サイトの音声ゲートウェイを通じて PSTN へ送り届けたりします。 同様に、営業所内の電話機から発信されたコールも、営業所の音声ゲートウェイを通じて、コールを PSTN へルーティングする追加機能を使用してルーティングされます。
営業所には、メイン サイトの IP WAN および PSTN にアクセスするために、SRST ゲートウェイが配置されます。 営業所の SIP を実行している電話機は、すべてのセッション招待をメイン サイトの Cisco Unified Communications Manager へ送信します。 メイン サイトの電話機と同様に、 Cisco Unified Communications Manager は、コールをメイン サイトの電話機へ送り届けたり、メイン サイトの音声ゲートウェイを通じて IP WAN から営業所の電話機、または PSTN へ送り届けたりすることができます。 営業所内の電話機から発信された PSTN コールは、 Cisco Unified Communications Manager クラスタのルーティング設定に従って、メイン サイトのゲートウェイを通じて PSTN へルーティングしたり、営業所のゲートウェイを通じて PSTN へローカルにルーティングしたりすることができます。
IP WAN に障害が起きた場合、SRST ゲートウェイは、バックアップ コール制御サーバとしても機能します。 SIP を実行している電話機と SCCP を実行している電話機はどちらも、WAN の障害時に SRST ゲートウェイへフェールオーバーします。 そうすることにより、営業所内の電話機はコールを SRST ゲートウェイにルーティングできます。 このようなコールとしては、営業所内で発信および終端するコールと、PSTN 内で発信および終端するコールがあります。
SIP 回線側の概要
SIP 回線側機能は、 Cisco Unified Communications Manager アーキテクチャ、TFTP サーバ、および Cisco Unified IP Phone に影響を与えます。 SIP を実行している電話機の機能は SCCP を実行している電話機の機能と同等で、動作も似ています。 Cisco Unified IP Phone 7941/61/71/70/11 は、すべての機能およびほとんどの CTI アプリケーションをサポートします。 Cisco Unified IP Phone 7905/12/40/60 は、縮小された機能セット(たとえば、制限付きの MOH 機能とフェールオーバー機能)をサポートします。 SIP トランク側アプリケーションは、SCCP を実行している電話機と SIP を実行している電話機の両方に対して機能します。
SIP の規格
- RFC3261、RFC3262(PRACK)、RFC3264(Offer/Answer)、RFC3311(UPDATE)、3PCC
- RFC3515(REFER)Replaces および Referred-by ヘッダー
- Remote Party Id(RPID)ヘッダー
- Diversion ヘッダー
- Replaces ヘッダー
- Join ヘッダー
- P-Charging-Vector ヘッダー
- RFC3265 + ダイアログ パッケージ
- RFC3265 + プレゼンス パッケージ
- RFC3265 + KPML パッケージ
- RFC3265 + RFC3842 MWI パッケージ(要求なしの通知)
- Remotecc
- RFC4028 セッション タイマー
Remote Party Id(RPID)ヘッダー
この SIP 規格では、次の Cisco Unified Communications Manager 機能がサポートされます。
Calling Line ID(CLID)
Calling Party Name ID(CNID)
Dialed Number ID Service(DNIS)
Call-by-call Calling Line ID Restriction(call-by-call CLIR)
RPID は、識別サービスに使用される SIP ヘッダーです。 RPID は、発信側、着信側、および接続先リモート側の情報を相手に示します。その目的は、識別と折り返し、合法的な代行受信、緊急サービスに対するユーザ ID とユーザ ロケーションの指示、およびアカウンティング サービスと課金サービス用のユーザの識別です。
P-Charging-Vector ヘッダー
Cisco Unified Communications Manager 8.6(1) では、ネットワーク配置で P-Charging-Vector(PCV)という SIP ヘッダーのパススルーをサポートします。 この PCV ヘッダーを使用して、グローバルに一意な IP Multimedia Subsystem(IMS)Charging Identifier(ICID)値など、モバイルまたは PSTN の課金関連情報をサービス プロバイダーに伝送します。
新しい SIP 正規化スクリプトである、HCS-PCV-PAI-passthrough は、この機能の一部として導入されています。 このスクリプトが Cisco Unified Communications Manager にプレインストールされていて、ネットワークを指すすべての SIP トランクに関連付けられる必要があります。
ネットワークから発信するすべてのコールに対して、Cisco Unified Communications Manager は、INVITE、UPDATE、および 200 OK でネットワークから受信した PCV ヘッダーを相手側へパススルーします。 さらに、Cisco Unified Communications Manager は、Cisco Unified Communications Manager で終了するコールに対する 200 OK SIP を介したネットワークからの PCV ヘッダーをパススルーします。 これらのコールは同じ SIP トランクを経由してシスコ ネットワークに戻るようにルーティングされるため、Cisco Unified Communications Manager が受信する 200 OK メッセージは、発信コールの PCV ヘッダーを使用してそのまま渡されます。
SIP 電話機での Cisco Unified Communications Manager の機能
- BLF コール ピックアップ
- 発呼側の正規化
- CTI サポート
- ダイヤル プラン
- ダイレクト コール ピックアップ
- サイレント
- サイレント(DND)によるコール拒否
- DSCP の設定
- E.164
- iX メディア チャネル
- 参加および回線をまたいで参加
- 迷惑呼 ID(MCID)
- Network Time Protocol(NTP)
- PLAR
- プログラム可能な回線キー
- ワンボタン割り込み/C 割り込み
- 単一コール UI
- エンドポイントの SIP プロファイル
- ソフト クライアントの二重登録
- ソフトキー処理
- Unified Mobile Communications Server(UMCS)との連動
BLF コール ピックアップ
Cisco Unified Communications Manager では、回線キーを BLF コール ピックアップ キーとして割り当てることができます。 BLF コール ピックアップ キーの動作は、SIP を実行している電話機の BLF スピード ダイヤル キーと同等です。 回線キーには、設定されている DN の BLF ステータスが表示されます。この回線キーを押すと、設定されている DN への発信が実行されます。 BLF コール ピックアップでは、BLF コール ピックアップ DN として設定されている DN でコールのアラートが発生すると、アラート通知が追加されます。 アラート中のコールに応答するには、コールがアラート状態となっている間に、BLF コール ピックアップ DN を押します。
BLF コール ピックアップ機能でモニタされている DN については、サブスクリプション タイプ PRESENCE+ALTERTING を使用して、SIP デバイス レイヤがコールのプレゼンス ステータスとアラート ステータスをサブスクライブします。 PRESENCE+ALTERTING のサブスクリプションは、モニタされている DN 回線の回線制御によって処理されます。 サブスクライブされている DN でコールが受信されると、回線制御によって Subscription Manager に通知されます。
発呼側の正規化
Cisco Unified Communications Manager では、ゲートウェイを介して受信したコールの発呼側番号をグローバル化できます。 発呼側番号を電話機に表示する前に変換して、E.164 形式にすることができます。 電話機には、このグローバル化された番号が提供されます。ユーザは、番号編集の機能を使用しなくても、受信した番号に折り返しのコールを発信できます。
グローバル化された番号のオプションの URI パラメータ(x-cisco-callback-number)が RPID ヘッダーに追加されます。 ローカライズされた番号は、SIP URI のユーザ部分として指定されます。 Cisco Unified Communications Manager によって電話機に送信される From ヘッダーでも、同じ SIP URI が指定されます。 折り返しダイヤル機能を起動すると、電話機は同じ SIP URI を要求 URI として Cisco Unified Communications Manager に INVITE でエコー バックします。 Cisco Unified Communications Manager の SIP デバイス レイヤは、グローバル化された番号が含まれている URI パラメータの要求 URI を解析し、ルーティングに使用します。 この URI が見つからない場合、SIP デバイス レイヤは、SIP URI のユーザ部分にある番号のローカライズ形式を使用します。
x-cisco-callback-number パラメータはオプションであり、会議コールの RPID ヘッダーには含まれず、コールが非通知としてマーキングされている場合には含まれていないことに注意してください。
CTI サポート
回線側 SIP には CTI 機能が含まれます。この機能を使用すると、 Cisco Unified Communications Manager Assistant などの CTI アプリケーションで、SIP を実行している Cisco Unified IP Phone( Cisco Unified IP Phone 7961 など)をサポートできます。 SIP を実行している電話機の CTI 機能は、SCCP を実行している電話機のものと同等ですが、いくつかの例外があります。 SIP を実行している電話機でサポートされる CTI 機能には、テキストの表示、ランプの設定、トーンの再生、コール パーク、およびプライバシーのサポートが含まれます。 CTI および Cisco Unified Communications Manager の詳細については、コンピュータ テレフォニー統合を参照してください。
ダイヤル プラン
SCCP を実行している電話機とは異なり、SIP を実行している電話機は番号をローカルで収集してから、その番号を Cisco Unified Communications Manager へ送信します。 SIP を実行している電話機はローカル ダイヤル プランを使用して、十分な番号がいつ入力されたかを認識し、収集された番号を使用して INVITE をトリガーします。 SRST モードで SIP を実行している電話機は、 Cisco Unified Communications Manager から受信した設定済みダイヤル プランを使用し続けます。 詳細については、SIPダイヤル ルールを参照してください。
ダイレクト コール ピックアップ
Cisco Unified Communications Manager は、SIP を実行している電話機上でダイレクト コール ピックアップ機能をサポートしています。 SIP を実行している電話機のダイレクト コール ピックアップ機能は、SCCP を実行している電話機のものと同等です。 ダイレクト コール ピックアップでは、[Gピック] ソフトキーを押して電話番号を入力することで、その DN のアラート中のコールを直接ピックアップできます。 SIP を実行している電話機は、 Cisco Unified Communications Manager に対して、ピックアップ対象となる電話機の DN が含まれた INVITE を送信します。
サイレント
Cisco Unified Communications Manager は、SIP デバイスまたは Cisco Unified Communications Manager デバイスが開始するサイレント(DND)をサポートします。 DND ステータスの変化は、SIP デバイスから、SIP PUBLISH メソッドを使用して Cisco Unified Communications Manager にシグナリングされます。 DND ステータスの変化は、 Cisco Unified Communications Manager から、dndupdate Remote-cc REFER 要求を使用して SIP デバイスにシグナリングされます。 また、 Cisco Unified Communications Manager はデバイスの DND ステータスとともにデバイスのビジー/アイドル ステータスを発行することもできます。
DSCP の設定
SIP を実行している Cisco Unified IP Phone は、デバイスにダウンロードされた設定ファイルから DSCP 情報を取得します。 DSCP 設定はデバイスに適用されますが、SCCP を実行している電話機はコール用に DSCP 設定を取得できます。 DSCP 値は、[エンタープライズ パラメータ設定(Enterprise Parameters Configuration)] ウィンドウと Cisco Unified Communications Manager の [サービス パラメータ設定(Service Parameter Configuration)] ウィンドウで設定されます。
E.164
Cisco Unified Communications Manager では、ゲートウェイを介して受信したコールの発呼側番号をグローバル化できます。 この処理には、E.164 形式の番号(+14085551234 など)にある「+」記号の追加を含みます。 SIP を実行している電話機が、通話履歴ログにある番号への折り返しダイヤル機能を起動した場合、 Cisco Unified Communications Manager にはグローバル化された番号がルーティング用として返されます。 E.164 のサポートによって、SIP デバイス レイヤは、グローバル化された番号文字列全体(+ を含む)を DA に渡すことができます。
iX メディア チャネル
iX メディア チャネル機能では、複数のアプリケーション レイヤ プロトコルを多重化するため、シンプルで信頼性に優れたセキュアなチャネルを利用できます。 SIP トランクで iX メディア チャネルのサポートを有効にするには、Cisco Unified Communications Manager の管理ページで [iXアプリケーションメディアを許可(Allow iX Application Media)] チェックボックスをオンにします。
を選択し、
(注)
Unified Communications Manager は、ビデオ チャネルが確立されている場合のみ、iX メディア チャネルのネゴシエーションをサポートします。
(注)
サポートされている SIP デバイスの場合、iX メディア チャネルはデバイスのユーザ インターフェイスから有効化する必要があります。 詳細については、ご使用の電話機モデルに関連するドキュメントを参照してください。
参加および回線をまたいで参加
参加機能の動作は、SIP を実行している電話機で、アドホック会議機能のインスタンスが 1 つ以上存在している場合と同様です。ただし、打診コールが開始されることはありません。 回線をまたいで参加機能を使用すると、複数の電話回線(電話番号が異なる回線または電話番号が同じでパーティションが異なる回線)上のコールを参加させ、会議を作成できます。
参加機能、または回線をまたいで参加機能をユーザが実行した場合、SIP を実行している電話機は、既存のソフトキーが SIP を実行している電話機から Cisco Unified Communications Manager に送信されるときと同じ方法で [参加] ソフトキー メッセージを使用し、選択されている回線で参加機能を実行します。
迷惑呼 ID(MCID)
Cisco Unified Communications Manager は、SIP を実行している電話機上で MCID 機能をサポートしています。 SIP を実行している電話機の MCID 機能は、SCCP を実行している電話機のものと同等です。 MCID 機能は、いたずら電話や脅迫電話を追跡する便利な方法を提供します。 この類のコールを受信したユーザが [迷惑呼] ソフトキーを押すと、新しい Remote-cc REFER softkeyevent 要求が Cisco Unified Communications Manager に送信されます。 この結果、 Cisco Unified Communications Manager でコールが記録されます。 ユーザには確認音が再生され、MCID 通知が受信されたことを示すテキスト メッセージが送信されます。 この確認音は、電話機への Remote-cc playtonereq によって生成されます。テキスト メッセージは、「迷惑呼IDの処理完了」という内容の Remote-cc statuslineupdate です。
Network Time Protocol(NTP)
Cisco Unified Communications Manager の管理ページで電話用 Network Time Protocol(NTP)参照先を設定し、SIP を実行する Cisco Unified IP Phone が、日付と時刻を必ず NTP サーバから取得するようにできます。 すべての NTP サーバから応答がない場合、SIP を実行している電話機は、REGISTER メッセージに対する 200 OK 応答内の日付ヘッダーを使用して日付と時刻を取得します。
電話用 NTP を Cisco Unified Communications Manager の管理ページに追加した後、それを日時グループに追加する必要があります。 日時グループ内では、電話機が連絡する最初のサーバから順に、電話用 NTP に優先順位を付けます。
日時グループの設定はデバイス プール内で指定され、デバイス プールは電話機ウィンドウで指定されます。
NTP 参照先の設定方法については、SIPダイヤル ルールを参照してください。
PLAR
Private Line Automatic Ringdown(PLAR)とは、従来のテレフォニー システムで使用される用語で、ユーザが電話機をオフフックすると、常に電話機が事前に設定された番号をすぐにダイヤルするような電話機の設定のことです。 ユーザは、その電話機(または回線)から別の番号をダイヤルできません。 これは、 Cisco Unified Communications Manager でパーティション、コーリング サーチ スペース(CSS)、およびトランスレーション パターンを使用して SCCP IP Phone に実装されます。電話機に PLAR がセットアップされていることは、デバイス設定にも回線設定にも表示されません。
管理者は SIP ダイヤル ルールを使用して、SIP を実行する電話機に PLAR を設定します。 PLAR に設定された電話機は、適切なターゲット パターンを指定する、1 回線ダイヤル プランが設定されます。 ユーザがオフフックすると、電話機は INVITE にターゲット文字列を含めて、すぐに要求を Cisco Unified Communications Manager へ送信します。 ユーザは、番号を入力しません。 詳細については、SIPダイヤル ルールを参照してください。
プログラム可能な回線キー
Cisco Unified IP Phone は、回線ボタン(ディスプレイの右側にあるボタン)をサポートしています。このボタンを使用すると、特定の回線上でコールを開始、応答、または切り替えることができます。 スピードダイヤル、エクステンション モビリティ、プライバシー、BLF スピードダイヤル、DND、サービス URL など、限られた数の機能をこれらのボタンに割り当てることができます。 これらの各機能は、SIP を実行している電話機でサポートされており、 Cisco Unified Communications Manager で設定できます。
PLK 機能の詳細については、プログラム可能な回線キーを参照してください。
単一コール UI
Cisco Unified Communications Manager は、SIP を実行している電話機上で、回線ロールオーバーによる単一コール UI をサポートしています。 回線ロールオーバーが発生するのは、max-calls-per-line および busy-trigger の値が 1/1 に設定されている場合です。 転送機能および会議機能では、プライマリ コールで max-calls-per-line の値に達した場合、電話機は、コールが発生していない直近の回線ボタンまたは別パーティションの同一 DN に対して打診コールをロールオーバーすることができます。 max-calls-per-line および busy-trigger の値が 2/1 に設定されている場合、発信の打診コールは同じボタンに転送されます。
エンドポイントの SIP プロファイル
SIP 属性はほとんど変更されないため、 Cisco Unified Communications Manager は SIP プロファイルを使用して、SIP トランクおよび Cisco Unified IP Phone に関連した SIP 属性を定義します。 これらの属性を、すべての SIP トランクと SIP を実行する電話機に個別に追加することなく、プロファイルの中に入れておくと、管理者は SIP デバイスの設定に費やす時間を減らすことができ、デバイス グループの値を変更できるようになります。 SIP プロファイルは、SIP のトランクと電話機を設定するときの必須フィールドなので、 Cisco Unified Communications Manager にはデフォルトの SIP プロファイルが用意されていますが、管理者はカスタマイズした SIP プロファイルを作成できます。 SIP プロファイルを SIP デバイスに割り当てるには、 Cisco Unified Communications Manager の管理ページを使用します。
SIP を実行している電話機のソフトウェアは、各電話機へ TFTP で送信された SIP 値の大部分を使用します。
SIP プロファイルの設定方法については、SIPダイヤル ルールを参照してください。
ソフト クライアントの二重登録
Cisco Unified Communications Manager では、2 つの異なるエンドポイントを同じデバイス名に登録することはできません。 これにより、ソフト クライアントでは問題が発生する可能性があります。ソフト クライアントは、複数のシステム(PC 用の Cisco Jabber クライアントや Macintosh 用の Cisco Jabber クライアントなど)にインストールでき、各システムの同じ登録を使用できるためです。
別のソフト クライアントが該当するデバイス名にすでに登録されている場合に、登録の試みを処理するため、ソフト クライアントでは、SIP 登録要求の Supported ヘッダーに次のタグを挿入できます。
x-cisco-duplicate-reg-:このタグがある場合、Cisco Unified Communications Manager は自動的に 2 つ目のソフト クライアントを登録して最初のソフト クライアントの登録を削除します。
x-cisco-graceful-reg:このタグにより、既存のセッションを自動的にキャンセルしなくても、登録済みのデバイス名に登録を試みているソフト クライアントが、既存の登録セッションを上書きできます。 このタグがある場合、Cisco Unified Communications Manager は新しい登録の試みを拒否して SIP 403 メッセージを返します。 ソフト クライアントは、x-cisco-duplicate-reg タグのみを使用して新しい登録の試みを送信することで、最初のソフト クライアントを再登録するか、または登録の試みを中止することで、最初のソフト クライアントの登録をそのまま残すことができます。
両方のタグがある場合、Cisco Unified Communications Manager は x-graceful-reg タグを優先します。
ソフトキー処理
管理者は、 Cisco Unified Communications Manager の管理ページを使用して、電話機に表示されるソフトキー セットを変更できます。 キーの追加と削除、およびキー位置の変更ができます。 このデータはデータベースに書き込まれ、電話機の登録/初期化プロセスの一部として、Station メッセージで SCCP を実行する電話機へ送信されます。 ただし、SIP をサポートする Cisco Unified IP Phone では Station メッセージでキーが送信されず、 Cisco Unified Communications Manager TFTP サーバがソフトキー セットの含まれたファイルを作成します。 SIP を実行する電話機はそのファイルを TFTP サーバから取得し、電話機に内蔵されたソフトキー セットが、新しいソフトキー セットで上書きされます。 これにより、 Cisco Unified Communications Manager はデフォルトのソフトキーを変更できます。また、 Cisco Unified Communications Manager はソフトキー イベントを操作することで、一部の電話機レベルの機能を直接制御できます。
[ソフトキーテンプレートの設定(Softkey Template Configuration)] ウィンドウを使用して設定した機能が SIP を実行する電話機でサポートされていない場合、そのソフトキーは表示されますが、そのキーが有効でないというメッセージが電話機に表示されます。この動作は、SCCP を実行する電話機の動作と一貫性があります。
[ダイヤル] ソフトキーは、SIP を実行している電話機が SRST モードで動作しているときに、デフォルトのソフトキー セットの一部として表示されます。
(注)
SIP を実行している Cisco Unified IP Phone 7905、7912、7940、および 7960 は、ソフトキーをダウンロードしません。 これらの電話機では、ソフトキーが電話機のファームウェアに内蔵されています。