この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
目次
Resource Reservation Protocol(RSVP)は、IP ネットワーク内のリソースを予約するための、トランスポート レベルのリソース予約プロトコルです。 RSVP は、ロケーション ベースのコール アドミッション制御(CAC)と並んで、CAC を達成するもう 1 つの方法を提供します。 ロケーション ベースの CAC は、ポイントツーポイントの CAC メカニズムで構成され、トポロジの変更や複層トポロジは考慮されません。これに対して、RSVP ではこれらの要素が考慮されます。
Cisco Unified Communications Manager で代替のコール アドミッション制御(CAC)メカニズムとして RSVP サポートが必要となる要因としては、次のものがあります。
多くのお客様が、ビデオ会議およびビデオ テレフォニー環境を既存のトポロジに適合させるための、フルメッシュ ネットワーク トポロジを求めています。 Cisco Unified Communications Manager で RSVP ベースの CAC メカニズムがサポートされていない場合でも、ロケーション ベースの CAC メカニズムを有効なソリューションとして利用できます。
Quality of Service(QoS)の基本として、すべての VoIP およびビデオ会議デバイスで RSVP を使用してアドミッション制御を提供することをお勧めします。
コール アドミッション制御(CAC)の詳細については、コール アドミッション制御を参照してください。
この章では、RSVP の概要を示し、 Cisco Unified Communications Manager 内での RSVP 設定について説明します。また、RSVP への移行について説明し、RSVP の相互対話の例やトラブルシューティング情報を示します。
Resource Reservation Protocol(RSVP)は、IP ネットワーク内のリソースを予約するための、トランスポート レベルのリソース予約プロトコルです。 RSVP は、ロケーション ベースのコール アドミッション制御(CAC)と並んで、CAC を達成するもう 1 つの方法を提供します。 ロケーション ベースの CAC は、ポイントツーポイントの CAC メカニズムで構成され、トポロジの変更や複層トポロジは考慮されません。これに対して、RSVP ではこれらの要素が考慮されます。
RSVP 予約は、特定のセッション用に作成されます。 セッションは、特定の宛先アドレス、宛先ポート、およびプロトコル識別子(TCP または UDP)を持つフローから構成されます。 RSVP 予約では、それぞれのセッションが 1 つの独立した単位として扱われます。
RSVP メッセージは、メディア フロー パスと同じパスを通過します。
RSVP は単方向プロトコルなので、フローは 1 方向だけに予約されます。
RSVP は受信者指向プロトコルなので、ストリームの受信者が予約を要求します。
RSVP はユニキャストとマルチキャストの両方の環境をサポートします。
RSVP メッセージは、RSVP 以外のルータとスイッチを透過的に通過します。
RSVP がロケーション ベースのコール アドミッション制御(CAC)よりも Quality of Service(QoS)を提供するために望ましいソリューションなのは、次の要因からです。
RSVP は複雑なトポロジを処理できます。 ロケーション ベースの CAC でサポートされるのは、マルチプロトコル ラベル スイッチング(MPLS)の単純なエニーツーエニー トポロジなど、ハブアンドスポークまたはポイントツーポイントのトポロジだけです。 ロケーションでは、複層のトポロジを正確に表現できません。 ロケーション ベースの CAC は、次のような複雑なトポロジを処理しません。
RSVP がネットワーク認識を公開するのに対し、ロケーション ベースの CAC は帯域幅の動的変更を処理できません。
IP ビデオ会議は、かなりの帯域幅を必要とするだけでなく、遅延とパケット損失に関してネットワークからの特殊なサービスも必要とします。 RSVP を使用したネットワークでは、ネットワーク内で実行される別のアプリケーションのパフォーマンスを過度に劣化させることなく、そのようなトラフィックに対処できます。
RSVP は本来、Multilevel Precedence and Preemption(MLPP)をサポートしています。
RSVP は、SIP、SCCP、MGCP、H.323 など、すべてのシグナリング プロトコルをサポートしています。
RSVP は、ロケーション ペア ベースの RSVP ポリシーを適用することによって機能します。 ユーザは、ロケーション ペアに基づいて RSVP を使用可能にしたり使用不可にしたりできます。 このため、移行も容易です。
システム全体のサービス パラメータの設定によって、システムの RSVP ポリシーが決まります。 したがって、システム全体で RSVP を使用可能にしたり使用不可にしたりできます。 ただし、ロケーション ペア ベースのポリシーは、システム全体のポリシーよりも優先されます。
RSVP には、次の RSVP ポリシー レベルが用意されています。
RSVP には、再試行予約機能があります。 この機能により、コールはリソース(帯域幅)が現在利用不能であっても、良好な Quality of Service(QoS)を取得または再取得できます。
RSVP Retry Timer では、再試行の頻度が制御されます。 Mandatory RSVP Midcall Retry Counter および Mandatory RSVP mid call error handle option サービス パラメータは、初期 RSVP ポリシーで [必須(Mandatory)] が指定されている場合に、必要なリソースを予約することにより、良好なサービス復元の試行回数を制御します。
RSVP は Differentiated Services(DiffServ)QoS と統合されます。 RSVP 予約の結果によって、Differentiated Services Code Point(DSCP)値が更新されます。
RSVP には、コール中障害ポリシーがあります。この機能を使用すると、コール中にコールの帯域予約が失われた場合に、コールに何が起きたのかを判別できます。 次のオプションがあります。
RSVP は、オーディオとビデオの両方のストリームに対して帯域予約をサポートします。
RSVP はアプリケーション ID サポートを提供します。
RSVP は Multilevel Precedence and Preemption(MLPP)をサポートします。
RSVP は、一方が保留されたときに予約を保持します。 予約されたリソースは、コールが再開されたときに再利用できます。
同じロケーション/リージョンに置かれた共有回線は、着信コールに対して同じ予約を共有します。
RSVP は、 Cisco Unified Communications Manager のすべての補足サービスおよび補足機能と連携するので、そのサービスまたは機能が起動された後も帯域予約が正しいことが保証されます。 サポートされる機能の例としては、コール転送、会議、および自動転送があります。
RSVP は保留音(MOH)機能とアナンシエータ機能をサポートします。
RSVP が設定されている場合、MLPP は次のように機能します。
Cisco Unified Communications Manager は MLPP コールの優先順位を、SCCP Quality of Service(QoS)メッセージによって RSVP エージェントに渡します。
エージェントは、RSVP 要求に優先順位情報を追加します。
IOS ルータは、その優先順位情報を使用してコールを受け入れます。
IOS ルータで優先処理が発生した場合、RSVP エージェントは Cisco Unified Communications Manager に優先処理による予約の失敗を通知します。
Cisco Unified Communications Manager は、優先処理の対象となった発呼側と着信側に優先処理を通知します。 Cisco Unified Communications Manager は、ロケーション ベースのコール アドミッション制御(CAC)MLPP 優先処理メカニズムによく似た、既存の MLPP 機能を使用します。
優先処理の対象となったコールは、失敗するか、低い QoS で続行されます。 優先処理の対象となったコールは、コール中の予約の失敗と同じ扱いを受けます。
Cisco Unified Communications Manager は次のインタラクションをサポートします。
RSVP エージェントは、Differentiated Services Control Point(DSCP)マークの変更をサポートします。 この機能は、たとえば Communicator や VTA など、デスクトップ アプリケーションでの信頼に関する問題を軽減します。
RSVP は、オーディオ、ビデオ、およびデータのパススルーをサポートします。 ビデオ データのパススルーでは、ビデオとデータのパケットが、RSVP エージェントおよびメディア ターミネーション ポイント(MTP)デバイスを通過できます。 また、ビデオ コールにオーディオ トランスコーディングを使用することもできます。 オーディオ パススルーでは、暗号化されたコールが MTP を通過できます。
Cisco Unified Communications Manager は、RSVP をネイティブでサポートするエンドポイントとの RSVP 相互対話をサポートしていません。
RSVP は G. Clear コーデックをサポートしていません。
(注) |
RSVP は自動代替ルーティング(AAR)と競合しません。AAR が設定されている場合、AAR は引き続き機能します。 詳細については、自動代替ルーティングを参照してください。 |
Cisco Unified Communications Manager は RSVP エージェントを使用します。RSVP エージェントは IOS ベースの RSVP プロキシで、RSVP をサポートするための SCCP インターフェイスを備えています。 Cisco Unified Communications Manager は、一連の SCCP メッセージを通じて RSVP エージェントと通信します。 RSVP エージェントは、メディア ターミネーション ポイントまたはトランスコーダ デバイスとして Cisco Unified Communications Manager に登録されます。
エンドポイントごとに 1 つずつ RSVP エージェントが必要です。 エージェント ペア(エンドポイント A 用に 1 つのエージェント、エンドポイント B 用に別の 1 つのエージェント)は、 Cisco Unified Communications Manager が制御するエンドポイントに代わって、RSVP に信号を発します。
Cisco Unified Communications Manager は、メディア ターミネーション ポイントとトランスコーダ リソースを割り当てるのと同じ方法で RSVP エージェント リソースを割り当てます。 ユーザは、RSVP エージェントを含んだメディア リソース グループ リスト(MRGL)を設定し、その MRGL をデバイスまたはデバイスへ関連付けられたデバイス プールに割り当てます。 コール中の両方のエンドポイントに同じ RSVP エージェントが割り当てられている場合、RSVP 予約は失敗します。
ロケーション ベースのコール アドミッション制御(CAC)と RSVP の両方を同時にアクティブにしないことを推奨します。ただし、ロケーション ベースの CAC から RSVP への移行期間中は除きます。
ロケーション内でロケーション帯域幅が無制限(無限の帯域幅)に設定されていない場合、 Cisco Unified Communications Manager は、RSVP を実行する前にロケーション ベースの CAC を実行します。 ロケーション ベースの CAC が失敗した場合、コールは失敗し、 Cisco Unified Communications Manager は RSVP を起動しません。
ロケーション内でロケーション帯域幅が無制限(無限の帯域幅)に設定されている場合、 Cisco Unified Communications Manager は、発信側と着信側に関連付けられているロケーション ペアの RSVP ポリシーに基づいて、RSVP を起動します。
RSVP の設定は、さまざまなサービス パラメータとその他のコンポーネントの設定で構成されています。 RSVP を設定するために必要な各種サービス パラメータとその他の設定について、次に説明します。
ヒント |
RSVP を設定する前に、RSVP の設定を参照してください。 |
クラスタ全体の RSVP ポリシーを設定するには、Cisco CallManager サービスに、次のようなクラスタ全体(システム - RSVP)のサービス パラメータを設定します。
ロケーション ペアの RSVP ポリシーを設定するには、[ロケーションの設定(Location Configuration)] ウィンドウを使用します。 ロケーション ペアに対して設定された RSVP ポリシーは、[サービスパラメータ設定(Service Parameter Configuration)] ウィンドウで設定されるデフォルトのロケーション間 RSVP ポリシーよりも優先されます。
ロケーション ペアに RSVP ポリシーを設定するには、次のようにして、そのロケーション ペアの [RSVP設定(RSVP Setting)] フィールドを設定します。
ステップ 1 | Cisco Unified Communications Manager の管理ページで、 メニュー オプションを選択します。 |
ステップ 2 | ロケーション ペアの 1 つのロケーションを見つけ、そのロケーションを選択します。 |
ステップ 3 | 選択したロケーションともう 1 つのロケーションの間の RSVP ポリシーを変更するには、ロケーション ペアのもう一方のロケーションを選択します。 |
ステップ 4 |
[RSVP設定(RSVP Setting)] ドロップダウン リスト ボックスで、このロケーション ペアの RSVP ポリシーを選択します。
|
RSVP の再試行の頻度と回数を設定するには、次に示すクラスタ全体(システム - RSVP)のサービス パラメータを使用します。
コール中 RSVP エラー処理を設定するには、次のクラスタ全体(システム - RSVP)のサービス パラメータを使用します。
発信者の MLPP 優先順位から RSVP 優先レベルへのマッピングを設定するには、次に示すクラスタ全体(システム - RSVP)のサービス パラメータを使用します。
TSpec オブジェクトは、送信者が生成するトラフィックを記述したものです。 TSpec は、ネットワークを通じてすべての中間ルータと宛先のエンドポイントへ転送されます。 中間ルータは、このオブジェクトを変更せず、オブジェクトは最終的な受信者(単数または複数)へ無変更のまま配信されます。
オーディオ フローの場合、TSpec の計算で次の値が指定されます。
burstSize(バイト):パケット サイズに 1 バースト内のパケット数を乗算したサイズとして計算されます。 オーディオ フローの場合、通常のバーストは 1 ~ 2 です。
peakRate(バイト):ピーク レート(バイト単位)は、エンドポイントが 1 回に伝送する 1 秒当たりの最大バイト数をバイト単位で表します。 バーストがオーディオ ストリームのように小さい場合、peakRate は tokenRate の 1.1(または 1.2)倍として計算できます。
コールが応答されたときに、帯域幅予約を上方に調整するのを回避するために、 Cisco Unified Communications Manager は、各リージョン コーデックに対する最大帯域幅をコール セットアップ時間で予約します。 次に、 Cisco Unified Communications Manager は、コールが応答されたときに、接続された当事者のメディア能力に基づく帯域幅を変更または調整します。
コールの設定については、次に示すさまざまなリージョン コーデックの帯域幅計算例を参照してください。
G.711:8 サンプル/フレーム、10 ms パケットの場合:80 + 40(ヘッダー) = 120 * 100(パケット/秒) = 12000 * 8 = 96 kb/s; (packet_size_in_ms*8+40)*8000/packet_size_in_ms
G.729: 10 ms/frame、8 kb/s、デフォルトは 20 ms、0 と 10 が可能。 10 ms パケットの場合:10 + 40 = 50 * 100 = 5000 * 8 = 40 kb/s
kb/s:(packet_size_in_ms+40)*8000/packet_size_in_ms
G.711 コーデックの TSpec では、次の計算が指定されます。
Tspec.mAverageBitRate = bwPlusHeader = 96 kb/s
Tspec.mPeakRate = Tspec.mAverageBitRate * (1.2) = 115
Tspec.mBurstSize = PacketSize * 2 = 120 * 2 = 240
ビデオ ストリームの場合、パケット長はコーデックに依存しません。 個々の実装がパケット長の基礎となります。 また、パケット サイズは、すべてのパケットで均一のままでもありません。 したがって、1 秒当たりのパケット数を見積もるのは難しくなります。
ここでは、ビデオ ストリームの最大パケット サイズが 1000 バイトであると想定します。
Cisco CallManager サービスのサービス パラメータの [Clusterwide Parameters (System - RSVP)] セクションにある RSVP Video Tspec Burst Size Factor サービス パラメータを使用すると、ビデオ ストリームのバースト サイズを設定できます。 このサービス パラメータのデフォルト値は 5 です。
burstSize(バイト):バースト サイズ係数(5)×最大パケット サイズ(1000)
peakRate(バイト):この要素は、エンドポイントが 1 回に伝送する 1 秒当たりの最大バイト数を表します。 バーストがオーディオ ストリームのように小さい場合、peakRate は tokenRate の 1.1(または 1.2)倍として計算できます。
Cisco Unified Communications Manager は、最初に、ビデオ コール全体の帯域幅を使用してビデオ ストリームの帯域幅を予約しようとします。つまり、「384 kb + オーバーヘッド」です。
ビデオ コール全体でも不十分な帯域幅が存在する場合、 Cisco Unified Communications Manager は、次に、「(ビデオ コール帯域幅 - オーディオ ストリーム コーデック) + オーバーヘッド」を帯域幅の量として予約しようとします。
384 kb コーデックの Tspec では、次の計算が指定されます。
Tspec.mAverageBitRate = bwPlusHeader = 410 kb/s
Tspec.mPeakRate = Tspec.mAverageBitRate = 410、Tspec.mBurstSize = 1000 * 5 = 5000
RSVP 予約が失敗した場合、 Cisco Unified Communications Manager は RSVP エージェントまたはエンドポイント(RSVP エージェントの割り当てに失敗した場合)に、メディアの DiffServ コード ポイント(DSCP)マークをベストエフォート型に変更するよう指示します。 そうでないと、EF マークの付いた過度のメディア パケットにより、たとえ予約のあるフローの場合でも Quality of Service(QoS)が劣化する可能性があります。
Cisco Unified Communications Manager は、コールの RSVP に障害が起きたとき、クラスタ全体(システム - QoS)の DSCP for Audio Calls When RSVP Fails サービス パラメータまたは DSCP for Video Calls When RSVP Fails サービス パラメータを使用して、この指示に対する DSCP 値を決定します。
アプリケーション ID は、RSVP メッセージ内のポリシー要素に挿入できる RSVP オブジェクトを指定します。 このオブジェクトは、RFC 2872 に記述されています。 このポリシー オブジェクトはアプリケーションの識別に役立ち、アプリケーションを RSVP 予約要求に関連付けます。そのアプリケーション情報に基づいて、パス上にあるルータは適切な決定を下すことができます。
次のクラスタ全体(システム - RSVP)のシステム パラメータにより、アプリケーション ID を設定できます。
RSVP ポリシーを設定したロケーション間で音声コールが確立された場合、そのオーディオ ストリームの予約には、RSVP Audio Application ID を使用してタグが付加されます。 RSVP ポリシーを設定したロケーション間でビデオ コールが確立された場合、そのオーディオ ストリームおよびビデオ ストリームの予約には、RSVP Video Application ID を使用してタグが付加されます。
オーディオ コールからビデオ コールに変更された場合は、次の処理が実行されます。
既存のオーディオ予約がオーディオ プールから解放されます。
ビデオ プールでオーディオ帯域幅予約が再試行されます。このとき、[オプション(ビデオが必要)(Optional(Video Desired))] ポリシーが使用されます。
オーディオ ストリームのアプリケーション ID が RSVP Video に変更され、新しいビデオ ストリームに RSVP Video Application ID を使用してタグが付加されます。
ビデオ コールがオーディオ コールに変更された場合は、次の処理が実行されます。
既存のオーディオ予約およびビデオ予約の両方がビデオ プールから解放されます。
オーディオ プールでオーディオ帯域幅予約が再試行されます。このとき、[オプション(ビデオが必要)(Optional(Video Desired))] ポリシーが使用されます。
オーディオ ストリームのアプリケーション ID が RSVP Audio に変更されます。
(注) |
エンドツーエンドの RSVP 環境では、オーディオ プールまたはビデオ プールでオーディオ帯域幅予約が再試行されると、両方のクラスタにおいて既存のプールからのオーディオ帯域幅の解放が試行され、新しいプールでのオーディオ予約が再試行されます。 これにより、新しいプールでオーディオ帯域幅予約が行われるまでの間、再試行サイクル中に競合状態が発生する場合があります。 |
このコール アドミッション制御のモデルを使用することによって、一定の帯域幅を音声コール用に予約して、プライオリティ キューの使用可能な帯域幅全体を使用できます。つまり、ビデオ コールが進行中でない場合、使用可能な帯域幅をすべて音声コールに使用できます。 使用可能な帯域幅がプライオリティ キューに十分にある場合は、コールでビデオを有効にすることもできます。 ビデオ対応のコールで消費できる帯域幅については、制限値を設定できます。ただし、使用可能な帯域幅がボイス コールによってすべて消費されている場合は、ビデオ コールを一切発信できないことがあります。
会議ブリッジ、保留音サーバ、およびアナンシエータは、メディア リソース グループ リスト(MRGL)の設定を指定しないので、そのデバイスを関連する RSVP エージェントを持つデバイス プールへ関連付けると、そのデバイスで RSVP リソースを使用できるようになります。 デバイス プールへ関連付けられた MRGL は、それらのタイプのメディア デバイス用に RSVP リソースを割り当てるために使用されます。
RSVP では、ローカルとエンドツーエンドの 2 つの異なる設定を使用することによって、異なるクラスタ内のエンドポイント間の予約がサポートされています。
ローカル RSVP では、異なるクラスタに配置されている 2 つの RSVP エージェント間の予約はサポートされていません。 ローカル RSVP ではクラスタごとに 2 つの RSVP エージェントを使用し、クラスタ間を接続するトランクを経由して RSVP を使用することはありません。 これが、デフォルトの設定です。
endpoint A - agentA - agentICT1 - ICT1 - ICT2 - agentICT2 - agentB - endpoint B
ここで、A はクラスタ 1 内のエンドポイントを、B はクラスタ 2 内のエンドポイントを、ICT1 と ICT2 はクラスタ 1 内とクラスタ 2 内のクラスタ間トランクを示しています。また、RSVP エージェントがそれぞれのデバイスに関連付けられています。
このシナリオで、 Cisco Unified Communications Manager 1 は agentA と agentICT1 の間の予約を制御し、 Cisco Unified Communications Manager 2 は agentB と agentICT2 の間の予約を制御します。
代替の手段として、Cisco Unified Border Element(以前の Cisco Multiservice IP-to-IP)ゲートウェイを使用できます。 詳細については、ゲートキーパーおよびトランクの設定を参照してください。
エンドツーエンドの RSVP 設定は、クラスタが SIP トランクによって接続されている場合に使用できます。 エンドツーエンドの RSVP では、エンドポイント間の接続全体で RSVP が使用され、RSVP エージェントがクラスタごとに 1 つだけ使用されます。
endpoint A - agentA - ICT1 - ICT2 - agentB - endpoint B
ここで、A はクラスタ 1 内のエンドポイントを、B はクラスタ 2 内のエンドポイントを、ICT1 と ICT2 はクラスタ 1 内とクラスタ 2 内のクラスタ間トランクを示しています。また、RSVP エージェントがそれぞれのエンドポイントに関連付けられています。
このシナリオでは、 Cisco Unified Communications Manager によって agentA と agentB との間にエンドツーエンドの RSVP 接続が確立されます。
SIP トランク経由でのエンドツーエンドの RSVP の設定
SIP トランクにおける RSVP の設定は、トランクに適用された SIP プロファイルによって決定されます。 SIP トランクでエンドツーエンドの RSVP を使用可能にするには、次のようにトランクの SIP プロファイルを設定します。
RSVP セッションでは、次の条件がすべてあてはまる場合、特別な設定が適用されます。
1 つのエンドポイント デバイス(Cisco IP Interactive Voice Response(IP IVR)など)が、G.711 コーデックだけをサポートするように設定されている。
コールに RSVP が設定されている。
発信側 RSVP エージェントと着信側 RSVP エージェントの間のリージョン間コーデックが G.729 である。
コールが発信されるときに RSVP エージェントのリソースと帯域幅の正常な割り当ておよび予約を行うために、管理者はメディア ターミネーション ポイント(MTP)/RSVP エージェントにパススルー コーデックだけではなく G.729 コーデックを設定する必要があります。 この設定により、メディア接続時に着信側の RSVP エージェントと着信側デバイスの間にトランスコーダを挿入できます。 コーデックが一致する場合は、コーデック パススルーが実行されます。コーデックが一致しない場合は、トランスコーダがないとコールを継続できません。
エージェントに G.729 コーデックが設定されていない場合は、RSVP コールに必要なトランスコーダを Cisco Unified Communications Manager が起動しないため、コールは失敗します。
このような状況が発生するのは、発信側エージェントと着信側エージェントの間、または G.729 を指定する 2 つのエンドポイントの間で、リージョン間コーデックが使用される場合です。 このようなコールでルーティングを正常に行うには、次の 2 つの方法があります。
IVR の RSVP エージェントをトランスコーダとして使用する。 この場合、トランスコーダ/RSVP エージェントと IVR 間のリージョン間コーデックは G.711 コーデックである必要があります。
ソフトウェア MTP を RSVP エージェントとして使用し、IVR と IVR の RSVP エージェントの間にトランスコーダを挿入する。 この場合、ソフトウェア MTP にパススルー コーデックだけではなく G.729 コーデックが設定されていることを確認します。
トランスコーディング機能を持つ RSVP エージェントは、G.729 から G.729 へのトランスコーディングを実行できないことに注意してください。 トランスコーダを RSVP エージェントとして使用する場合は、パススルー コーデックを使用するか、トランスコーダを設定して、トランスコーダの両側で使用されるコーデックのいずれかが G.711 であるようにする必要があります。
ロケーション ベースのコール アドミッション制御(CAC)から RSVP へ移行するには、いくつかの特殊な環境を考慮する必要があります。 RSVP の展開中は、一部のロケーションのデバイスには RSVP エージェントが設定され、他のロケーションでは RSVP エージェントが設定されていない状態になります。
RSVP エージェントを持つロケーションから RSVP エージェントを持たないロケーションへコールが行われた場合、 Cisco Unified Communications Manager は、ロケーション ベースの CAC と RSVP の両方を使用してコールの QoS を管理します。 コールの最初の部分(RSVP エージェントを持つロケーションから RSVP を持つハブ/中央サイトへ)では、RSVP メカニズムが使用されます。 コールの 2 番目の部分(ハブ/中央サイトから RSVP を持たないロケーションへ)は、ロケーション ベースの CAC によって管理されます。 どちらかのメカニズムで帯域幅の割り当てに失敗すると、コールは失敗します。
ロケーション | 帯域幅 |
---|---|
0 | 無制限 |
1 | 無制限 |
2 | 1500 |
3 | 3000 |
4 | 3000 |
ロケーション ペア |
RSVP ポリシー |
|
---|---|---|
1 |
1 |
[なし(None)] |
1 |
1 以外 |
[必須(Mandatory)] |
1 以外 |
1 以外 |
[なし(None)] |
次の項では、RSVP とさまざまな Cisco Unified Communications Manager 機能およびサービスとの相互対話の例を示します。
RSVP は IPv6 をサポートしていません。 RSVP コールは IPv4 をサポートします。 RSVP がコールに必要であり、コール内のデバイスが IPv6 アドレス用に設定されているか IPv6 アドレスを使用する場合、 Cisco Unified Communications Manager はコールを拒否し、発信側はビジー音を受信します。 IPv6 の詳細については、RSVP と MLPPを参照してください。
この例は、共有回線コールの呼び出し音フェーズにおける次の設定を示しています。
電話機 B1(ロケーション 2 内)、B2(ロケーション 3 内)、および B3 と B4(どちらもロケーション 4 内)は、DN 2000 を共有します。
ロケーション 1 の RSVP エージェントには、単一の予約が割り当てられています。 その予約には、複数の宛先、つまり他のロケーション(2、3、および 4)にある RSVP エージェントごとに 1 つずつ、宛先があります。
ロケーション 4 の RSVP エージェントには、1 つの予約が割り当てられています。 電話機 B3 と B4 は、その予約を共有します。
DN 2000 を共有する電話機 B3 と B4 は、単一の RSVP エージェントを使用します。
電話機 B2(ロケーション 3 内)が共有回線コールに応答した後、ロケーション 1 とロケーション 2 の間の RSVP 予約、およびロケーション 1 とロケーション 4 の間の予約は破棄されます。 ロケーション 1 とロケーション 3 の間の RSVP 予約だけが確立された状態になります。
RSVP は、電話機 A が保留状態になり保留音を受信している間、電話機 A と電話機 B の間の予約を保存します。 電話機 A と電話機 B の間のコールが再開されると、予約されていたリソースが再使用されます。 電話機 A と、その保留音を提供する MOH サーバは同じロケーションにあるので、電話機 A と MOH サーバの間に RSVP 予約は必要ありません。
この例は、電話機 A と電話機 B の間の通話で、保留音サーバが電話機 B と同じロケーションにある場合を示しています。 電話機 B が電話機 A を保留状態にし、電話機 A が保留音を受信する場合、電話機 A と電話機 B の接続に使用された予約は、保留音セッションに再使用されます。 追加の予約は作成されません。
電話機 B が電話機 A を保留状態にし、電話機 A が保留音を受信する場合、RSVP エージェントは電話機 A と電話機 B の接続に使用された予約を保存します。 別の RSVP エージェントは、電話機 A と MOH サーバの間に新しい予約を作成します。
この例では、電話機 A、DN 1000、ロケーション 1 が電話機 B、DN 2000、ロケーション 2 にコールします。 RSVP エージェントは、そのコール用の予約を確立します。 電話機 B は転送ボタンを押し、DN 3000 にダイヤルします。 電話機 C、DN 3000、ロケーション 4 が、そのコールに応答します。
この設定で、電話機 B が電話機 A から電話機 C へのコールの転送を開始した場合、RSVP エージェントは電話機 A と電話機 B の間の予約を保存します。 別の RSVP エージェントは、電話機 A と MOH サーバの間に新しい RSVP 予約を作成します。 電話機 B と電話機 C の間にも、RSVP エージェントによって新しい予約が作成されます。
電話機 B が転送を完了すると、新しい RSVP 予約が電話機 A と電話機 C の間に作成されます。 電話機 A と MOH サーバの間、電話機 A と電話機 B の間、および電話機 B と電話機 C の間の RSVP 予約は、すべて破棄されます。
ここでは、RSVP ベースのさまざまな MLPP シナリオについて説明します。
(注) |
RSVP ベースの MLPP は、プリエンプション非対応の番号をサポートしていません。 |
その他の設定の詳細:RSVP 帯域幅は 100 kb/s です。 それぞれのコールが 80 kb/s を取得します。したがって、予約の取得に成功するコールは 1 つだけです。
その他の設定の詳細:RSVP 帯域幅は 100 kb/s です。 それぞれのオーディオ コールが 80 kb/s を取得します。したがって、予約の取得に成功するコールは 1 つだけです。
その他の設定の詳細:RSVP 帯域幅は 100 kb/s です。 それぞれのオーディオ コールが 80 kb/s を取得します。したがって、予約の取得に成功するコールは 1 つだけです。
エンドツーエンドの RSVP のトラブルシューティングの詳細については、エンドツーエンドの RSVP のトラブルシューティングを参照してください。
RSVP は、RSVP のトラブルシューティングを支援するため、パフォーマンス モニタリング(PerfMon)カウンタ、コール詳細レコード(CDR)、アラーム、およびトレース情報を提供します。
次の Cisco Unified Communications Manager RSVP アドミッション制御パフォーマンス モニタリング カウンタが存在します。
RSVP AudioReservationErrorCounts
RSVP MandatoryConnectionsInProgress
RSVP OptionalConnectionsInProgress
RSVP TotalCallsFailed
RSVP VideoCallsFailed
RSVP VideoReservationErrorCounts
これらのロケーション ベースおよびノード ベースのパフォーマンス モニタリング カウンタは、ノードを越えて同期化されることはありません。
RSVP エージェント リソースのトラブルシューティングを行うために、次の RSVP パフォーマンス モニタリング カウンタが存在します。
パフォーマンス モニタリング カウンタの詳細および表示方法については、『 Cisco Unified Real Time Monitoring Tool Administration Guide』を参照してください。
Cisco Unified Communications Manager Quality of Service (QoS) RSVP エージェント機能によって、次のコール詳細レコード(CDR)フィールドが追加されます。
[origRSVPAudioStat]:発信側から終端側への RSVP オーディオ予約の状態
[destRSVPAudioStat]:終端側から発信側への RSVP オーディオ予約の状態
[origRSVPVideoStat]:発信側から終端側への RSVP ビデオ予約の状態
[destRSVPVideoStat]:終端側から発信側への RSVP ビデオ予約の状態
これらのフィールドには、オーディオまたはビデオ ストリームの RSVP 帯域幅予約の状態が反映されます。
Cisco Unified Communications Manager RSVP CDR 状態フィールドには、次の値が適用されます。
0:RSVP NO RESERVATION 状態を示します。これがデフォルト値です。
1:コールの設定時または機能の起動時の RSVP RESERVATION FAILURE 状態を示します。
2:コールの設定時または機能の起動時の RSVP RESERVATION SUCCESS 状態を示します。
3:コールの設定時または機能の起動時の RSVP RESERVATION NO RESOURCE(RSVP エージェント)状態を示します。
4:RSVP MID_CALL FAILURE_PREEMPTED 状態(コールの設定後に優先処理が行われた)を示します。
5:RSVP MID_CALL FAILURE_LOST_BANDWIDTH 状態(MLPP 優先処理以外のすべてのコール中機能を含む)を示します。
Cisco Unified Communications Manager RSVP CDR 状態フィールドの値は連結され、コールについて最新の 32 個の状態値が保存されます。
Optional RSVP ポリシーを使用してコールが確立され、初期 RSVP 予約が成功します。 その後、コールは帯域幅予約を失い、再試行後に帯域幅予約を再取得します。 このシーケンスが、コール中に何度も繰り返され、コールは RSVP 予約に成功して終了します。 この場合、CDR は、その特定のストリームについて、次の文字列を Cisco Unified Communications Manager RSVP 予約状態として示します。
"2:5:2:5:2:5:2" (success:lost_bw:success:lost_bw:success:lost_bw:success)
詳細については、『 Cisco Unified Communications Manager CDR Analysis and Reporting Administration Guide』を参照してください。
使用できる RSVP エージェント リソースがないときは、RsvpNoMoreResourcesAvailable というアラームが生成されます。
このアラームは、 Cisco Unified Communications Manager アラーム カタログ /vob/ccm/Common/XML/AlarmCatalog/Communications Manager.xml で定義されています。
RSVP では、RSVP 予約に失敗したとき、Cisco CallManager サービスについて、いくつかの SDL トレースおよび SDI トレースが生成されます。 Cisco Unified Communications Manager の SDL と SDI のどちらのトレース ファイルにも、RSVP エラー コードがあります。
RSVP エージェントは、次の RSVP 予約エラー コードを送信する場合があります。
QOS_CAUSE_RESERVATION_TIMEOUT=0
QOS_CAUSE_PATH_FAIL
QOS_CAUSE_RESV_FAIL
QOS_CAUSE_LISTEN_FAIL
QOS_CAUSE_RESOURCE_UNAVAILABLE
QOS_CAUSE_LISTEN_TIMEOUT
QOS_CAUSE_RESV_RETRIES_FAIL
QOS_CAUSE_PATH_RETRIES_FAIL
QOS_CAUSE_RESV_PREEMPTION
QOS_CAUSE_PATH_PREEMPTION
QOS_CAUSE_RESV_MODIFY_FAIL
QOS_CAUSE_PATH_MODIFY_FAIL
この項では、エンドツーエンドの RSVP のトラブルシューティング情報を示します。 エンドツーエンドの RSVP の詳細については、クラスタ間での RSVP の使用を参照してください。
問題 |
推奨処置 |
---|---|
タンデム転送またはリモート転送を実行した後、最後のコールがエンドツーエンドの RSVP コールでなくなる。 |
転送元ノードにおいて、着信および発信 SIP トランクが割り当てられているロケーション間で RSVP ポリシーがアクティブであることを確認します。 |
コールが保留されたとき、MOH サーバと保留にされた側との間で、エンドツーエンドの RSVP が使用されない。 |
保留しているクラスタで、MOH のデバイス プールに、RSVP エージェントが割り当てられた MRGL があることを確認します。 また、MOH サーバおよび SIP トランクが割り当てられたロケーション間で RSVP ポリシーがアクティブであることも確認します。 |
キャンパス(Hub_none ロケーション)のデバイスがコールを発信または受信する場合に、エンドツーエンドの RSVP が使用されない。 |
Hub_none ロケーションと SIP トランクが割り当てられたロケーションとの間で RSVP ポリシーがアクティブであることを確認します。 |
会議コールが起動されたとき、会議ブリッジとリモートの会議参加者との間で、エンドツーエンドの RSVP が使用されない。 |
会議コールを起動したクラスタで、会議ブリッジのデバイス プールに、RSVP エージェントが割り当てられた MRGL があることを確認します。 また、会議ブリッジおよび SIP トランクが割り当てられたロケーション間で RSVP ポリシーがアクティブであることも確認します。 |
コールがリモート システムにブラインド転送された場合に、アナンシエータと発信側の電話機との間でエンドツーエンドの RSVP が使用されない。 |
転送中のクラスタで、アナンシエータのデバイス プールに、RSVP エージェントが割り当てられた MRGL があることを確認します。 また、アナンシエータおよび SIP トランクが割り当てられたロケーション間で RSVP ポリシーがアクティブであることを確認します。 |
基本的なエンドツーエンドの RSVP コールに失敗する。 |
両方のクラスタのエンドポイントとトランクとの間で RSVP ポリシーがアクティブであること、および両方のクラスタの着信 SIP トランクと発信 SIP トランクの SIP プロファイルでエンドツーエンドの RSVP のサポートが設定されていることを確認します。 |
エンドツーエンドの RSVP 予約に失敗する。 |
考えられる原因は、発信側および着信側の RSVP エージェントとして同じルータを使用しようとしており、かつ、そのルータで、RSVP 予約のループバックがサポートされている最新バージョンの IOS が実行されていないことです。 ルータで最新バージョンの IOS が実行されていることを確認してください。 |
目次
- Resource Reservation Protocol
- RSVP の設定
- RSVP の概要
- RSVP の利点
- RSVP の機能
- RSVP ベースの MLPP
- 追加機能
- RSVP に関する注意点
- RSVP エージェントと QoS
- RSVP エージェントの割り当て
- RSVP エージェントとロケーション ベースの CAC との相互対話
- RSVP の設定
- クラスタ全体のデフォルト RSVP ポリシーの設定
- ロケーション ペア RSVP ポリシーの設定
- RSVP の再試行の設定
- コール中 RSVP エラー処理の設定
- MLPP から RSVP への優先レベル マッピングの設定
- TSpec
- オーディオ TSpec
- ビデオ TSpec
- DSCP
- アプリケーション ID
- メディア デバイスの RSVP
- クラスタ間での RSVP の使用
- コール用 RSVP の有効化
- RSVP での特別な設定
- RSVP への移行
- RSVP の相互対話
- RSVP と IPv6
- RSVP と共有回線コール
- RSVP と保留音
- RSVP とコール転送
- RSVP と MLPP
- RSVP のトラブルシューティング
- パフォーマンス モニタリング カウンタ
- コール詳細レコード
- アラーム
- トレース情報
- エンドツーエンドの RSVP のトラブルシューティング
Resource Reservation Protocol(RSVP)は、IP ネットワーク内のリソースを予約するための、トランスポート レベルのリソース予約プロトコルです。 RSVP は、ロケーション ベースのコール アドミッション制御(CAC)と並んで、CAC を達成するもう 1 つの方法を提供します。 ロケーション ベースの CAC は、ポイントツーポイントの CAC メカニズムで構成され、トポロジの変更や複層トポロジは考慮されません。これに対して、RSVP ではこれらの要素が考慮されます。
Cisco Unified Communications Manager で代替のコール アドミッション制御(CAC)メカニズムとして RSVP サポートが必要となる要因としては、次のものがあります。
多くのお客様が、ビデオ会議およびビデオ テレフォニー環境を既存のトポロジに適合させるための、フルメッシュ ネットワーク トポロジを求めています。 Cisco Unified Communications Manager で RSVP ベースの CAC メカニズムがサポートされていない場合でも、ロケーション ベースの CAC メカニズムを有効なソリューションとして利用できます。
Quality of Service(QoS)の基本として、すべての VoIP およびビデオ会議デバイスで RSVP を使用してアドミッション制御を提供することをお勧めします。
コール アドミッション制御(CAC)の詳細については、コール アドミッション制御を参照してください。
この章では、RSVP の概要を示し、 Cisco Unified Communications Manager 内での RSVP 設定について説明します。また、RSVP への移行について説明し、RSVP の相互対話の例やトラブルシューティング情報を示します。
RSVP の設定
手順Resource Reservation Protocol(RSVP)は、IP ネットワーク内のリソースを予約するための、トランスポート レベルのリソース予約プロトコルです。 RSVP は、ロケーション ベースのコール アドミッション制御(CAC)と並んで、CAC を達成するもう 1 つの方法を提供します。 ロケーション ベースの CAC は、ポイントツーポイントの CAC メカニズムで構成され、トポロジの変更や複層トポロジは考慮されません。これに対して、RSVP ではこれらの要素が考慮されます。
関連資料
関連情報
RSVP の概要
RSVP 予約は、特定のセッション用に作成されます。 セッションは、特定の宛先アドレス、宛先ポート、およびプロトコル識別子(TCP または UDP)を持つフローから構成されます。 RSVP 予約では、それぞれのセッションが 1 つの独立した単位として扱われます。
RSVP メッセージは、メディア フロー パスと同じパスを通過します。
RSVP は単方向プロトコルなので、フローは 1 方向だけに予約されます。
RSVP は受信者指向プロトコルなので、ストリームの受信者が予約を要求します。
RSVP はユニキャストとマルチキャストの両方の環境をサポートします。
RSVP メッセージは、RSVP 以外のルータとスイッチを透過的に通過します。
RSVP の利点
RSVP がロケーション ベースのコール アドミッション制御(CAC)よりも Quality of Service(QoS)を提供するために望ましいソリューションなのは、次の要因からです。
RSVP は複雑なトポロジを処理できます。 ロケーション ベースの CAC でサポートされるのは、マルチプロトコル ラベル スイッチング(MPLS)の単純なエニーツーエニー トポロジなど、ハブアンドスポークまたはポイントツーポイントのトポロジだけです。 ロケーションでは、複層のトポロジを正確に表現できません。 ロケーション ベースの CAC は、次のような複雑なトポロジを処理しません。
RSVP がネットワーク認識を公開するのに対し、ロケーション ベースの CAC は帯域幅の動的変更を処理できません。
IP ビデオ会議は、かなりの帯域幅を必要とするだけでなく、遅延とパケット損失に関してネットワークからの特殊なサービスも必要とします。 RSVP を使用したネットワークでは、ネットワーク内で実行される別のアプリケーションのパフォーマンスを過度に劣化させることなく、そのようなトラフィックに対処できます。
RSVP は本来、Multilevel Precedence and Preemption(MLPP)をサポートしています。
RSVP の機能
RSVP は、SIP、SCCP、MGCP、H.323 など、すべてのシグナリング プロトコルをサポートしています。
RSVP は、ロケーション ペア ベースの RSVP ポリシーを適用することによって機能します。 ユーザは、ロケーション ペアに基づいて RSVP を使用可能にしたり使用不可にしたりできます。 このため、移行も容易です。
システム全体のサービス パラメータの設定によって、システムの RSVP ポリシーが決まります。 したがって、システム全体で RSVP を使用可能にしたり使用不可にしたりできます。 ただし、ロケーション ペア ベースのポリシーは、システム全体のポリシーよりも優先されます。
RSVP には、次の RSVP ポリシー レベルが用意されています。
RSVP には、再試行予約機能があります。 この機能により、コールはリソース(帯域幅)が現在利用不能であっても、良好な Quality of Service(QoS)を取得または再取得できます。
RSVP Retry Timer では、再試行の頻度が制御されます。 Mandatory RSVP Midcall Retry Counter および Mandatory RSVP mid call error handle option サービス パラメータは、初期 RSVP ポリシーで [必須(Mandatory)] が指定されている場合に、必要なリソースを予約することにより、良好なサービス復元の試行回数を制御します。
RSVP は Differentiated Services(DiffServ)QoS と統合されます。 RSVP 予約の結果によって、Differentiated Services Code Point(DSCP)値が更新されます。
RSVP には、コール中障害ポリシーがあります。この機能を使用すると、コール中にコールの帯域予約が失われた場合に、コールに何が起きたのかを判別できます。 次のオプションがあります。
RSVP は、オーディオとビデオの両方のストリームに対して帯域予約をサポートします。
RSVP はアプリケーション ID サポートを提供します。
RSVP は Multilevel Precedence and Preemption(MLPP)をサポートします。
RSVP は、一方が保留されたときに予約を保持します。 予約されたリソースは、コールが再開されたときに再利用できます。
同じロケーション/リージョンに置かれた共有回線は、着信コールに対して同じ予約を共有します。
RSVP は、 Cisco Unified Communications Manager のすべての補足サービスおよび補足機能と連携するので、そのサービスまたは機能が起動された後も帯域予約が正しいことが保証されます。 サポートされる機能の例としては、コール転送、会議、および自動転送があります。
RSVP は保留音(MOH)機能とアナンシエータ機能をサポートします。
RSVP ベースの MLPP
RSVP が設定されている場合、MLPP は次のように機能します。
Cisco Unified Communications Manager は MLPP コールの優先順位を、SCCP Quality of Service(QoS)メッセージによって RSVP エージェントに渡します。
エージェントは、RSVP 要求に優先順位情報を追加します。
IOS ルータは、その優先順位情報を使用してコールを受け入れます。
IOS ルータで優先処理が発生した場合、RSVP エージェントは Cisco Unified Communications Manager に優先処理による予約の失敗を通知します。
Cisco Unified Communications Manager は、優先処理の対象となった発呼側と着信側に優先処理を通知します。 Cisco Unified Communications Manager は、ロケーション ベースのコール アドミッション制御(CAC)MLPP 優先処理メカニズムによく似た、既存の MLPP 機能を使用します。
優先処理の対象となったコールは、失敗するか、低い QoS で続行されます。 優先処理の対象となったコールは、コール中の予約の失敗と同じ扱いを受けます。
追加機能
Cisco Unified Communications Manager は次のインタラクションをサポートします。
RSVP エージェントは、Differentiated Services Control Point(DSCP)マークの変更をサポートします。 この機能は、たとえば Communicator や VTA など、デスクトップ アプリケーションでの信頼に関する問題を軽減します。
RSVP は、オーディオ、ビデオ、およびデータのパススルーをサポートします。 ビデオ データのパススルーでは、ビデオとデータのパケットが、RSVP エージェントおよびメディア ターミネーション ポイント(MTP)デバイスを通過できます。 また、ビデオ コールにオーディオ トランスコーディングを使用することもできます。 オーディオ パススルーでは、暗号化されたコールが MTP を通過できます。
RSVP に関する注意点
Cisco Unified Communications Manager は、RSVP をネイティブでサポートするエンドポイントとの RSVP 相互対話をサポートしていません。
RSVP は G. Clear コーデックをサポートしていません。
(注)
RSVP は自動代替ルーティング(AAR)と競合しません。AAR が設定されている場合、AAR は引き続き機能します。 詳細については、自動代替ルーティングを参照してください。
RSVP エージェントと QoS
Cisco Unified Communications Manager は RSVP エージェントを使用します。RSVP エージェントは IOS ベースの RSVP プロキシで、RSVP をサポートするための SCCP インターフェイスを備えています。 Cisco Unified Communications Manager は、一連の SCCP メッセージを通じて RSVP エージェントと通信します。 RSVP エージェントは、メディア ターミネーション ポイントまたはトランスコーダ デバイスとして Cisco Unified Communications Manager に登録されます。
エンドポイントごとに 1 つずつ RSVP エージェントが必要です。 エージェント ペア(エンドポイント A 用に 1 つのエージェント、エンドポイント B 用に別の 1 つのエージェント)は、 Cisco Unified Communications Manager が制御するエンドポイントに代わって、RSVP に信号を発します。
RSVP エージェントとロケーション ベースの CAC との相互対話
ロケーション ベースのコール アドミッション制御(CAC)と RSVP の両方を同時にアクティブにしないことを推奨します。ただし、ロケーション ベースの CAC から RSVP への移行期間中は除きます。
ロケーション内でロケーション帯域幅が無制限(無限の帯域幅)に設定されていない場合、 Cisco Unified Communications Manager は、RSVP を実行する前にロケーション ベースの CAC を実行します。 ロケーション ベースの CAC が失敗した場合、コールは失敗し、 Cisco Unified Communications Manager は RSVP を起動しません。
ロケーション内でロケーション帯域幅が無制限(無限の帯域幅)に設定されている場合、 Cisco Unified Communications Manager は、発信側と着信側に関連付けられているロケーション ペアの RSVP ポリシーに基づいて、RSVP を起動します。
RSVP の設定
RSVP の設定は、さまざまなサービス パラメータとその他のコンポーネントの設定で構成されています。 RSVP を設定するために必要な各種サービス パラメータとその他の設定について、次に説明します。
ヒント
RSVP を設定する前に、RSVP の設定を参照してください。
- クラスタ全体のデフォルト RSVP ポリシーの設定
- ロケーション ペア RSVP ポリシーの設定
- RSVP の再試行の設定
- コール中 RSVP エラー処理の設定
- MLPP から RSVP への優先レベル マッピングの設定
- TSpec
- DSCP
- アプリケーション ID
- メディア デバイスの RSVP
- クラスタ間での RSVP の使用
- コール用 RSVP の有効化
- RSVP での特別な設定
クラスタ全体のデフォルト RSVP ポリシーの設定
手順
ロケーション ペア RSVP ポリシーの設定
手順ロケーション ペアの RSVP ポリシーを設定するには、[ロケーションの設定(Location Configuration)] ウィンドウを使用します。 ロケーション ペアに対して設定された RSVP ポリシーは、[サービスパラメータ設定(Service Parameter Configuration)] ウィンドウで設定されるデフォルトのロケーション間 RSVP ポリシーよりも優先されます。
ロケーション ペアに RSVP ポリシーを設定するには、次のようにして、そのロケーション ペアの [RSVP設定(RSVP Setting)] フィールドを設定します。
ステップ 1 Cisco Unified Communications Manager の管理ページで、 メニュー オプションを選択します。 ステップ 2 ロケーション ペアの 1 つのロケーションを見つけ、そのロケーションを選択します。 ステップ 3 選択したロケーションともう 1 つのロケーションの間の RSVP ポリシーを変更するには、ロケーション ペアのもう一方のロケーションを選択します。 ステップ 4 [RSVP設定(RSVP Setting)] ドロップダウン リスト ボックスで、このロケーション ペアの RSVP ポリシーを選択します。
[Use System Default]:このロケーション ペアの RSVP ポリシーを、クラスタ全体の RSVP ポリシーと同じものにします。 詳細については、クラスタ全体のデフォルト RSVP ポリシーの設定を参照してください。
[No Reservation]:どのような 2 つのロケーション間にも RSVP 予約が作成されません。
[Video Desired (Optional)]:オーディオとビデオの両方のストリームに関して予約を取得できなかった場合、ベストエフォート型のオーディオのみのコールとしてコールを継続できます。 RSVP エージェントはオーディオに関する RSVP 予約を引き続き試み、予約が成功した場合は、 Cisco Unified Communications Manager に通知します。
Cisco Unified Communications Manager は、オーディオ ストリームのための RSVP 予約が成功するまでは、終端のデバイスの呼び出し音を鳴らしません。コールがビデオ コールである場合は、ビデオ ストリームについても同様です。
[Video Desired]:ビデオ コールは、オーディオ ストリームの予約が成功してビデオ ストリームの予約が成功しなかった場合、オーディオ専用として継続できます。
RSVP の再試行の設定
手順
コール中 RSVP エラー処理の設定
手順
MLPP から RSVP への優先レベル マッピングの設定
手順発信者の MLPP 優先順位から RSVP 優先レベルへのマッピングを設定するには、次に示すクラスタ全体(システム - RSVP)のサービス パラメータを使用します。
TSpec
TSpec オブジェクトは、送信者が生成するトラフィックを記述したものです。 TSpec は、ネットワークを通じてすべての中間ルータと宛先のエンドポイントへ転送されます。 中間ルータは、このオブジェクトを変更せず、オブジェクトは最終的な受信者(単数または複数)へ無変更のまま配信されます。
オーディオ TSpec
オーディオ フローの場合、TSpec の計算で次の値が指定されます。
burstSize(バイト):パケット サイズに 1 バースト内のパケット数を乗算したサイズとして計算されます。 オーディオ フローの場合、通常のバーストは 1 ~ 2 です。
peakRate(バイト):ピーク レート(バイト単位)は、エンドポイントが 1 回に伝送する 1 秒当たりの最大バイト数をバイト単位で表します。 バーストがオーディオ ストリームのように小さい場合、peakRate は tokenRate の 1.1(または 1.2)倍として計算できます。
コールが応答されたときに、帯域幅予約を上方に調整するのを回避するために、 Cisco Unified Communications Manager は、各リージョン コーデックに対する最大帯域幅をコール セットアップ時間で予約します。 次に、 Cisco Unified Communications Manager は、コールが応答されたときに、接続された当事者のメディア能力に基づく帯域幅を変更または調整します。
オーディオ TSpec の計算例
コールの設定については、次に示すさまざまなリージョン コーデックの帯域幅計算例を参照してください。
G.711:8 サンプル/フレーム、10 ms パケットの場合:80 + 40(ヘッダー) = 120 * 100(パケット/秒) = 12000 * 8 = 96 kb/s; (packet_size_in_ms*8+40)*8000/packet_size_in_ms
G.729: 10 ms/frame、8 kb/s、デフォルトは 20 ms、0 と 10 が可能。 10 ms パケットの場合:10 + 40 = 50 * 100 = 5000 * 8 = 40 kb/s
kb/s:(packet_size_in_ms+40)*8000/packet_size_in_ms
G.711 コーデックの TSpec では、次の計算が指定されます。
Tspec.mAverageBitRate = bwPlusHeader = 96 kb/s
Tspec.mPeakRate = Tspec.mAverageBitRate * (1.2) = 115
Tspec.mBurstSize = PacketSize * 2 = 120 * 2 = 240
ビデオ TSpec
ビデオ ストリームの場合、パケット長はコーデックに依存しません。 個々の実装がパケット長の基礎となります。 また、パケット サイズは、すべてのパケットで均一のままでもありません。 したがって、1 秒当たりのパケット数を見積もるのは難しくなります。
ここでは、ビデオ ストリームの最大パケット サイズが 1000 バイトであると想定します。
Cisco CallManager サービスのサービス パラメータの [Clusterwide Parameters (System - RSVP)] セクションにある RSVP Video Tspec Burst Size Factor サービス パラメータを使用すると、ビデオ ストリームのバースト サイズを設定できます。 このサービス パラメータのデフォルト値は 5 です。
burstSize(バイト):バースト サイズ係数(5)×最大パケット サイズ(1000)
peakRate(バイト):この要素は、エンドポイントが 1 回に伝送する 1 秒当たりの最大バイト数を表します。 バーストがオーディオ ストリームのように小さい場合、peakRate は tokenRate の 1.1(または 1.2)倍として計算できます。
Cisco Unified Communications Manager は、最初に、ビデオ コール全体の帯域幅を使用してビデオ ストリームの帯域幅を予約しようとします。つまり、「384 kb + オーバーヘッド」です。
ビデオ コール全体でも不十分な帯域幅が存在する場合、 Cisco Unified Communications Manager は、次に、「(ビデオ コール帯域幅 - オーディオ ストリーム コーデック) + オーバーヘッド」を帯域幅の量として予約しようとします。
384 kb コーデックの Tspec では、次の計算が指定されます。
Tspec.mAverageBitRate = bwPlusHeader = 410 kb/s
Tspec.mPeakRate = Tspec.mAverageBitRate = 410、Tspec.mBurstSize = 1000 * 5 = 5000
DSCP
RSVP 予約が失敗した場合、 Cisco Unified Communications Manager は RSVP エージェントまたはエンドポイント(RSVP エージェントの割り当てに失敗した場合)に、メディアの DiffServ コード ポイント(DSCP)マークをベストエフォート型に変更するよう指示します。 そうでないと、EF マークの付いた過度のメディア パケットにより、たとえ予約のあるフローの場合でも Quality of Service(QoS)が劣化する可能性があります。
Cisco Unified Communications Manager は、コールの RSVP に障害が起きたとき、クラスタ全体(システム - QoS)の DSCP for Audio Calls When RSVP Fails サービス パラメータまたは DSCP for Video Calls When RSVP Fails サービス パラメータを使用して、この指示に対する DSCP 値を決定します。
アプリケーション ID
アプリケーション ID は、RSVP メッセージ内のポリシー要素に挿入できる RSVP オブジェクトを指定します。 このオブジェクトは、RFC 2872 に記述されています。 このポリシー オブジェクトはアプリケーションの識別に役立ち、アプリケーションを RSVP 予約要求に関連付けます。そのアプリケーション情報に基づいて、パス上にあるルータは適切な決定を下すことができます。
次のクラスタ全体(システム - RSVP)のシステム パラメータにより、アプリケーション ID を設定できます。
RSVP ポリシーを設定したロケーション間で音声コールが確立された場合、そのオーディオ ストリームの予約には、RSVP Audio Application ID を使用してタグが付加されます。 RSVP ポリシーを設定したロケーション間でビデオ コールが確立された場合、そのオーディオ ストリームおよびビデオ ストリームの予約には、RSVP Video Application ID を使用してタグが付加されます。
オーディオ コールからビデオ コールに変更された場合は、次の処理が実行されます。
既存のオーディオ予約がオーディオ プールから解放されます。
ビデオ プールでオーディオ帯域幅予約が再試行されます。このとき、[オプション(ビデオが必要)(Optional(Video Desired))] ポリシーが使用されます。
オーディオ ストリームのアプリケーション ID が RSVP Video に変更され、新しいビデオ ストリームに RSVP Video Application ID を使用してタグが付加されます。
ビデオ コールがオーディオ コールに変更された場合は、次の処理が実行されます。
既存のオーディオ予約およびビデオ予約の両方がビデオ プールから解放されます。
オーディオ プールでオーディオ帯域幅予約が再試行されます。このとき、[オプション(ビデオが必要)(Optional(Video Desired))] ポリシーが使用されます。
オーディオ ストリームのアプリケーション ID が RSVP Audio に変更されます。
(注)
エンドツーエンドの RSVP 環境では、オーディオ プールまたはビデオ プールでオーディオ帯域幅予約が再試行されると、両方のクラスタにおいて既存のプールからのオーディオ帯域幅の解放が試行され、新しいプールでのオーディオ予約が再試行されます。 これにより、新しいプールでオーディオ帯域幅予約が行われるまでの間、再試行サイクル中に競合状態が発生する場合があります。
このコール アドミッション制御のモデルを使用することによって、一定の帯域幅を音声コール用に予約して、プライオリティ キューの使用可能な帯域幅全体を使用できます。つまり、ビデオ コールが進行中でない場合、使用可能な帯域幅をすべて音声コールに使用できます。 使用可能な帯域幅がプライオリティ キューに十分にある場合は、コールでビデオを有効にすることもできます。 ビデオ対応のコールで消費できる帯域幅については、制限値を設定できます。ただし、使用可能な帯域幅がボイス コールによってすべて消費されている場合は、ビデオ コールを一切発信できないことがあります。
クラスタ間での RSVP の使用
RSVP では、ローカルとエンドツーエンドの 2 つの異なる設定を使用することによって、異なるクラスタ内のエンドポイント間の予約がサポートされています。
ローカル RSVP では、異なるクラスタに配置されている 2 つの RSVP エージェント間の予約はサポートされていません。 ローカル RSVP ではクラスタごとに 2 つの RSVP エージェントを使用し、クラスタ間を接続するトランクを経由して RSVP を使用することはありません。 これが、デフォルトの設定です。
endpoint A - agentA - agentICT1 - ICT1 - ICT2 - agentICT2 - agentB - endpoint B
ここで、A はクラスタ 1 内のエンドポイントを、B はクラスタ 2 内のエンドポイントを、ICT1 と ICT2 はクラスタ 1 内とクラスタ 2 内のクラスタ間トランクを示しています。また、RSVP エージェントがそれぞれのデバイスに関連付けられています。
このシナリオで、 Cisco Unified Communications Manager 1 は agentA と agentICT1 の間の予約を制御し、 Cisco Unified Communications Manager 2 は agentB と agentICT2 の間の予約を制御します。
代替の手段として、Cisco Unified Border Element(以前の Cisco Multiservice IP-to-IP)ゲートウェイを使用できます。 詳細については、ゲートキーパーおよびトランクの設定を参照してください。
エンドツーエンドの RSVP 設定は、クラスタが SIP トランクによって接続されている場合に使用できます。 エンドツーエンドの RSVP では、エンドポイント間の接続全体で RSVP が使用され、RSVP エージェントがクラスタごとに 1 つだけ使用されます。
endpoint A - agentA - ICT1 - ICT2 - agentB - endpoint B
ここで、A はクラスタ 1 内のエンドポイントを、B はクラスタ 2 内のエンドポイントを、ICT1 と ICT2 はクラスタ 1 内とクラスタ 2 内のクラスタ間トランクを示しています。また、RSVP エージェントがそれぞれのエンドポイントに関連付けられています。
このシナリオでは、 Cisco Unified Communications Manager によって agentA と agentB との間にエンドツーエンドの RSVP 接続が確立されます。
SIP トランク経由でのエンドツーエンドの RSVP の設定
SIP トランクにおける RSVP の設定は、トランクに適用された SIP プロファイルによって決定されます。 SIP トランクでエンドツーエンドの RSVP を使用可能にするには、次のようにトランクの SIP プロファイルを設定します。
コール用 RSVP の有効化
手順
RSVP での特別な設定
RSVP セッションでは、次の条件がすべてあてはまる場合、特別な設定が適用されます。
1 つのエンドポイント デバイス(Cisco IP Interactive Voice Response(IP IVR)など)が、G.711 コーデックだけをサポートするように設定されている。
コールに RSVP が設定されている。
発信側 RSVP エージェントと着信側 RSVP エージェントの間のリージョン間コーデックが G.729 である。
コールが発信されるときに RSVP エージェントのリソースと帯域幅の正常な割り当ておよび予約を行うために、管理者はメディア ターミネーション ポイント(MTP)/RSVP エージェントにパススルー コーデックだけではなく G.729 コーデックを設定する必要があります。 この設定により、メディア接続時に着信側の RSVP エージェントと着信側デバイスの間にトランスコーダを挿入できます。 コーデックが一致する場合は、コーデック パススルーが実行されます。コーデックが一致しない場合は、トランスコーダがないとコールを継続できません。
エージェントに G.729 コーデックが設定されていない場合は、RSVP コールに必要なトランスコーダを Cisco Unified Communications Manager が起動しないため、コールは失敗します。
このような状況が発生するのは、発信側エージェントと着信側エージェントの間、または G.729 を指定する 2 つのエンドポイントの間で、リージョン間コーデックが使用される場合です。 このようなコールでルーティングを正常に行うには、次の 2 つの方法があります。
IVR の RSVP エージェントをトランスコーダとして使用する。 この場合、トランスコーダ/RSVP エージェントと IVR 間のリージョン間コーデックは G.711 コーデックである必要があります。
ソフトウェア MTP を RSVP エージェントとして使用し、IVR と IVR の RSVP エージェントの間にトランスコーダを挿入する。 この場合、ソフトウェア MTP にパススルー コーデックだけではなく G.729 コーデックが設定されていることを確認します。
トランスコーディング機能を持つ RSVP エージェントは、G.729 から G.729 へのトランスコーディングを実行できないことに注意してください。 トランスコーダを RSVP エージェントとして使用する場合は、パススルー コーデックを使用するか、トランスコーダを設定して、トランスコーダの両側で使用されるコーデックのいずれかが G.711 であるようにする必要があります。
RSVP への移行
手順ロケーション ベースのコール アドミッション制御(CAC)から RSVP へ移行するには、いくつかの特殊な環境を考慮する必要があります。 RSVP の展開中は、一部のロケーションのデバイスには RSVP エージェントが設定され、他のロケーションでは RSVP エージェントが設定されていない状態になります。
RSVP エージェントを持つロケーションから RSVP エージェントを持たないロケーションへコールが行われた場合、 Cisco Unified Communications Manager は、ロケーション ベースの CAC と RSVP の両方を使用してコールの QoS を管理します。 コールの最初の部分(RSVP エージェントを持つロケーションから RSVP を持つハブ/中央サイトへ)では、RSVP メカニズムが使用されます。 コールの 2 番目の部分(ハブ/中央サイトから RSVP を持たないロケーションへ)は、ロケーション ベースの CAC によって管理されます。 どちらかのメカニズムで帯域幅の割り当てに失敗すると、コールは失敗します。
RSVP の相互対話
RSVP と IPv6
RSVP は IPv6 をサポートしていません。 RSVP コールは IPv4 をサポートします。 RSVP がコールに必要であり、コール内のデバイスが IPv6 アドレス用に設定されているか IPv6 アドレスを使用する場合、 Cisco Unified Communications Manager はコールを拒否し、発信側はビジー音を受信します。 IPv6 の詳細については、RSVP と MLPPを参照してください。
RSVP と共有回線コール
この例は、共有回線コールの呼び出し音フェーズにおける次の設定を示しています。
電話機 B1(ロケーション 2 内)、B2(ロケーション 3 内)、および B3 と B4(どちらもロケーション 4 内)は、DN 2000 を共有します。
ロケーション 1 の RSVP エージェントには、単一の予約が割り当てられています。 その予約には、複数の宛先、つまり他のロケーション(2、3、および 4)にある RSVP エージェントごとに 1 つずつ、宛先があります。
ロケーション 4 の RSVP エージェントには、1 つの予約が割り当てられています。 電話機 B3 と B4 は、その予約を共有します。
DN 2000 を共有する電話機 B3 と B4 は、単一の RSVP エージェントを使用します。
電話機 B2(ロケーション 3 内)が共有回線コールに応答した後、ロケーション 1 とロケーション 2 の間の RSVP 予約、およびロケーション 1 とロケーション 4 の間の予約は破棄されます。 ロケーション 1 とロケーション 3 の間の RSVP 予約だけが確立された状態になります。
RSVP と保留音
図 5. 電話機 B が電話機 A を保留状態にし、MOH サーバが電話機 A と同じロケーションに存在する場合. この図は、保留音を起動するコールを示しています。 電話機 A と B の通話中に、電話機 B が電話機 A を保留状態にします。 この例では、MOH サーバは電話機 A と同じロケーションにあります。
RSVP は、電話機 A が保留状態になり保留音を受信している間、電話機 A と電話機 B の間の予約を保存します。 電話機 A と電話機 B の間のコールが再開されると、予約されていたリソースが再使用されます。 電話機 A と、その保留音を提供する MOH サーバは同じロケーションにあるので、電話機 A と MOH サーバの間に RSVP 予約は必要ありません。
図 6. 電話機 B が電話機 A を保留状態にし、MOH サーバが電話機 B と同じロケーションに存在する場合. この図は、保留音を起動するコールを示しています。 電話機 A と B の通話中に、電話機 B が電話機 A を保留状態にします。 この例では、MOH サーバは電話機 B と同じロケーションにあります。
この例は、電話機 A と電話機 B の間の通話で、保留音サーバが電話機 B と同じロケーションにある場合を示しています。 電話機 B が電話機 A を保留状態にし、電話機 A が保留音を受信する場合、電話機 A と電話機 B の接続に使用された予約は、保留音セッションに再使用されます。 追加の予約は作成されません。
図 7. 電話機 B が電話機 A を保留状態にし、MOH サーバが第 3 のロケーションに存在する場合. この図は、保留音を起動するコールを示しています。 電話機 A と B の通話中に、電話機 B が電話機 A を保留状態にします。 この例では、MOH サーバは電話機 A と電話機 B のどちらとも異なるロケーションにあります。 つまり、電話機 A、電話機 B、および保留音サーバが、それぞれ異なるロケーションに存在します。
電話機 B が電話機 A を保留状態にし、電話機 A が保留音を受信する場合、RSVP エージェントは電話機 A と電話機 B の接続に使用された予約を保存します。 別の RSVP エージェントは、電話機 A と MOH サーバの間に新しい予約を作成します。
RSVP とコール転送
この例では、電話機 A、DN 1000、ロケーション 1 が電話機 B、DN 2000、ロケーション 2 にコールします。 RSVP エージェントは、そのコール用の予約を確立します。 電話機 B は転送ボタンを押し、DN 3000 にダイヤルします。 電話機 C、DN 3000、ロケーション 4 が、そのコールに応答します。
この設定で、電話機 B が電話機 A から電話機 C へのコールの転送を開始した場合、RSVP エージェントは電話機 A と電話機 B の間の予約を保存します。 別の RSVP エージェントは、電話機 A と MOH サーバの間に新しい RSVP 予約を作成します。 電話機 B と電話機 C の間にも、RSVP エージェントによって新しい予約が作成されます。
電話機 B が転送を完了すると、新しい RSVP 予約が電話機 A と電話機 C の間に作成されます。 電話機 A と MOH サーバの間、電話機 A と電話機 B の間、および電話機 B と電話機 C の間の RSVP 予約は、すべて破棄されます。
RSVP と MLPP
シナリオ 1:輻輳時に優先順位の低いコールの優先処理が行われる
その他の設定の詳細:RSVP 帯域幅は 100 kb/s です。 それぞれのコールが 80 kb/s を取得します。したがって、予約の取得に成功するコールは 1 つだけです。
シナリオ 2:ビデオ コールは、十分な帯域幅が存在しない場合、オーディオ専用コールとして継続される
その他の設定の詳細:RSVP 帯域幅は 100 kb/s です。 それぞれのオーディオ コールが 80 kb/s を取得します。したがって、予約の取得に成功するコールは 1 つだけです。
RSVP のトラブルシューティング
エンドツーエンドの RSVP のトラブルシューティングの詳細については、エンドツーエンドの RSVP のトラブルシューティングを参照してください。
RSVP は、RSVP のトラブルシューティングを支援するため、パフォーマンス モニタリング(PerfMon)カウンタ、コール詳細レコード(CDR)、アラーム、およびトレース情報を提供します。
パフォーマンス モニタリング カウンタ
次の Cisco Unified Communications Manager RSVP アドミッション制御パフォーマンス モニタリング カウンタが存在します。
RSVP AudioReservationErrorCounts
RSVP MandatoryConnectionsInProgress
RSVP OptionalConnectionsInProgress
RSVP TotalCallsFailed
RSVP VideoCallsFailed
RSVP VideoReservationErrorCounts
これらのロケーション ベースおよびノード ベースのパフォーマンス モニタリング カウンタは、ノードを越えて同期化されることはありません。
RSVP エージェント リソースのトラブルシューティングを行うために、次の RSVP パフォーマンス モニタリング カウンタが存在します。
パフォーマンス モニタリング カウンタの詳細および表示方法については、『 Cisco Unified Real Time Monitoring Tool Administration Guide』を参照してください。
コール詳細レコード
Cisco Unified Communications Manager Quality of Service (QoS) RSVP エージェント機能によって、次のコール詳細レコード(CDR)フィールドが追加されます。
[origRSVPAudioStat]:発信側から終端側への RSVP オーディオ予約の状態
[destRSVPAudioStat]:終端側から発信側への RSVP オーディオ予約の状態
[origRSVPVideoStat]:発信側から終端側への RSVP ビデオ予約の状態
[destRSVPVideoStat]:終端側から発信側への RSVP ビデオ予約の状態
これらのフィールドには、オーディオまたはビデオ ストリームの RSVP 帯域幅予約の状態が反映されます。
Cisco Unified Communications Manager RSVP CDR 状態フィールドには、次の値が適用されます。
0:RSVP NO RESERVATION 状態を示します。これがデフォルト値です。
1:コールの設定時または機能の起動時の RSVP RESERVATION FAILURE 状態を示します。
2:コールの設定時または機能の起動時の RSVP RESERVATION SUCCESS 状態を示します。
3:コールの設定時または機能の起動時の RSVP RESERVATION NO RESOURCE(RSVP エージェント)状態を示します。
4:RSVP MID_CALL FAILURE_PREEMPTED 状態(コールの設定後に優先処理が行われた)を示します。
5:RSVP MID_CALL FAILURE_LOST_BANDWIDTH 状態(MLPP 優先処理以外のすべてのコール中機能を含む)を示します。
Cisco Unified Communications Manager RSVP CDR 状態フィールドの値は連結され、コールについて最新の 32 個の状態値が保存されます。
例
Optional RSVP ポリシーを使用してコールが確立され、初期 RSVP 予約が成功します。 その後、コールは帯域幅予約を失い、再試行後に帯域幅予約を再取得します。 このシーケンスが、コール中に何度も繰り返され、コールは RSVP 予約に成功して終了します。 この場合、CDR は、その特定のストリームについて、次の文字列を Cisco Unified Communications Manager RSVP 予約状態として示します。
"2:5:2:5:2:5:2" (success:lost_bw:success:lost_bw:success:lost_bw:success)
詳細については、『 Cisco Unified Communications Manager CDR Analysis and Reporting Administration Guide』を参照してください。
トレース情報
RSVP では、RSVP 予約に失敗したとき、Cisco CallManager サービスについて、いくつかの SDL トレースおよび SDI トレースが生成されます。 Cisco Unified Communications Manager の SDL と SDI のどちらのトレース ファイルにも、RSVP エラー コードがあります。
RSVP エージェントは、次の RSVP 予約エラー コードを送信する場合があります。
QOS_CAUSE_RESERVATION_TIMEOUT=0
QOS_CAUSE_PATH_FAIL
QOS_CAUSE_RESV_FAIL
QOS_CAUSE_LISTEN_FAIL
QOS_CAUSE_RESOURCE_UNAVAILABLE
QOS_CAUSE_LISTEN_TIMEOUT
QOS_CAUSE_RESV_RETRIES_FAIL
QOS_CAUSE_PATH_RETRIES_FAIL
QOS_CAUSE_RESV_PREEMPTION
QOS_CAUSE_PATH_PREEMPTION
QOS_CAUSE_RESV_MODIFY_FAIL
QOS_CAUSE_PATH_MODIFY_FAIL
エンドツーエンドの RSVP のトラブルシューティング
この項では、エンドツーエンドの RSVP のトラブルシューティング情報を示します。 エンドツーエンドの RSVP の詳細については、クラスタ間での RSVP の使用を参照してください。
表 3 エンドツーエンドの RSVP のトラブルシューティング 問題
推奨処置
タンデム転送またはリモート転送を実行した後、最後のコールがエンドツーエンドの RSVP コールでなくなる。
転送元ノードにおいて、着信および発信 SIP トランクが割り当てられているロケーション間で RSVP ポリシーがアクティブであることを確認します。
コールが保留されたとき、MOH サーバと保留にされた側との間で、エンドツーエンドの RSVP が使用されない。
保留しているクラスタで、MOH のデバイス プールに、RSVP エージェントが割り当てられた MRGL があることを確認します。 また、MOH サーバおよび SIP トランクが割り当てられたロケーション間で RSVP ポリシーがアクティブであることも確認します。
キャンパス(Hub_none ロケーション)のデバイスがコールを発信または受信する場合に、エンドツーエンドの RSVP が使用されない。
Hub_none ロケーションと SIP トランクが割り当てられたロケーションとの間で RSVP ポリシーがアクティブであることを確認します。
会議コールが起動されたとき、会議ブリッジとリモートの会議参加者との間で、エンドツーエンドの RSVP が使用されない。
会議コールを起動したクラスタで、会議ブリッジのデバイス プールに、RSVP エージェントが割り当てられた MRGL があることを確認します。 また、会議ブリッジおよび SIP トランクが割り当てられたロケーション間で RSVP ポリシーがアクティブであることも確認します。
コールがリモート システムにブラインド転送された場合に、アナンシエータと発信側の電話機との間でエンドツーエンドの RSVP が使用されない。
転送中のクラスタで、アナンシエータのデバイス プールに、RSVP エージェントが割り当てられた MRGL があることを確認します。 また、アナンシエータおよび SIP トランクが割り当てられたロケーション間で RSVP ポリシーがアクティブであることを確認します。
基本的なエンドツーエンドの RSVP コールに失敗する。
両方のクラスタのエンドポイントとトランクとの間で RSVP ポリシーがアクティブであること、および両方のクラスタの着信 SIP トランクと発信 SIP トランクの SIP プロファイルでエンドツーエンドの RSVP のサポートが設定されていることを確認します。
エンドツーエンドの RSVP 予約に失敗する。
考えられる原因は、発信側および着信側の RSVP エージェントとして同じルータを使用しようとしており、かつ、そのルータで、RSVP 予約のループバックがサポートされている最新バージョンの IOS が実行されていないことです。 ルータで最新バージョンの IOS が実行されていることを確認してください。