Cisco Unified Communications Manager システム ガイド リリース 8.5(1)

RSVP の利点

RSVP がロケーション ベースのコール アドミッション制御（CAC）よりもサービス品質（QoS）を提供するために望ましいソリューションなのは、次の要因からです。

• RSVP は複雑なトポロジを処理できます。ロケーション ベースの CAC でサポートされるのは、マルチプロトコル ラベル スイッチング（MPLS）の単純なエニーツーエニー トポロジなど、ハブアンドスポークまたはポイントツーポイントのトポロジだけです。ロケーションでは、複層のトポロジを正確に表現できません。ロケーション ベースの CAC は、次のような複雑なトポロジを処理しません。

– 冗長性のあるリンク（A = B）

– 連続する 4 つ以上のサイト（A － B － C － D）

– マルチレベルの階層構造（ハブ、リージョン、およびサブリージョン）

– メッシュ

• RSVP がネットワーク認識を公開するのに対し、ロケーション ベースの CAC は帯域幅の動的変更を処理できません。

• IP ビデオ会議は、かなりの帯域幅を必要とするだけでなく、遅延とパケット損失に関してネットワークからの特殊なサービスも必要とします。RSVP を使用したネットワークでは、ネットワーク内で実行される別のアプリケーションのパフォーマンスを過度に劣化させることなく、そのようなトラフィックに対処できます。

• RSVP は本来、Multilevel Precedence and Preemption（MLPP）をサポートしています。

RSVP の機能

RSVP 上には次の機能が構築されます。

• RSVP は、SIP、SCCP、MGCP、H.323 など、すべてのシグナリング プロトコルをサポートしています。

• RSVP は、ロケーション ペア ベースの RSVP ポリシーを適用することによって機能します。ユーザは、ロケーション ペアに基づいて RSVP を使用可能にしたり使用不可にしたりできます。このため、移行も容易です。

• システム全体のサービス パラメータの設定によって、システムの RSVP ポリシーが決まります。したがって、システム全体で RSVP を使用可能にしたり使用不可にしたりできます。ただし、ロケーション ペア ベースのポリシーは、システム全体のポリシーよりも優先されます。

• RSVP には、次の RSVP ポリシー レベルが用意されています。

– 予約なし（ロケーション ベースの CAC の使用を続行）

– 必須

– オプション（ビデオが必要）

– 必須（ビデオが必要）

• RSVP には、再試行予約機能があります。この機能により、コールはリソース（帯域幅）が現在利用不能であっても、良好なサービス品質（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 には、コール中障害ポリシーがあります。この機能を使用すると、コール中にコールの帯域予約が失われた場合に、コールに何が起きたのかを判別できます。次のオプションがあります。

– コールは予約を N 回試行した後に失敗する。

– コールはベストエフォート型コールになる。

• RSVP はオーディオとビデオの両方のストリームに対して帯域予約をサポートします。

• RSVP はアプリケーション ID サポートを提供します。

• RSVP は Multilevel Precedence and Preemption（MLPP）をサポートします。

• RSVP は、一方が保留されたときに予約を保持します。予約されたリソースは、コールが再開されたときに再利用できます。

• 同じロケーション/リージョンに置かれたシェアドライン デバイスは、着信コールに対して同じ予約を共有します。

• RSVP は、Cisco Unified Communications Manager のすべての補助サービスおよび補助機能と連携するので、そのサービスまたは機能が起動された後も帯域予約が正しいことが保証されます。サポートされる機能の例としては、Call Transfer、Conference、および Call Forwarding があります。

• RSVP は Music on Hold（MOH; 保留音）機能とアナンシエータ機能をサポートします。

RSVP ベースの MLPP

RSVP が設定されている場合、MLPP は次のように機能します。

• Cisco Unified Communications Manager は MLPP コールの優先順位を、SCCP サービス品質（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 エージェントおよび Media Termination Point（MTP; メディア ターミネーション ポイント）デバイスを通過できます。また、ビデオ コールにオーディオ トランスコーディングを使用することもできます。オーディオ パススルーでは、暗号化されたコールが MTP を通過できます。

パススルーの条件

次の条件がオーディオとビデオ/データの両方のパススルーに適用されます。

• 中間にあるすべての MTP デバイスがパススルーをサポートしている。

• [メディア ターミネーション ポイントが必須(Media Termination Point Required)] チェックボックスがオンにされているエンドポイントがない。

オーディオ パススルーには、次の追加条件が適用されます。

• リージョン フィルタリングの後、2 つのエンドポイント間に存在するオーディオ キャップが適合する。

ビデオ パススルーには、次の追加条件が適用されます。

• 中間にあるすべての MTP デバイスがマルチメディアをサポートしている。つまり、MTP デバイスが 1 コールにつき複数のチャネルをサポートしている。

RSVP に関する注意点

RSVP には、次のようなサポートの制限があります。

• Cisco Unified Communications Manager は、RSVP をネイティブでサポートするエンドポイントとの RSVP 相互対話をサポートしていません。

• RSVP は G.Clear コーデックをサポートしていません。

• RSVP は IPv6 をサポートしていません。RSVP コールは IPv4 をサポートしています。コールに RSVP が必要で、そのコールのデバイスが IPv6 のアドレス用に設定されているか、そのようなアドレスを使用している場合、Cisco Unified Communications Manager はコールを拒否し、発信側にはビジー トーンが聞こえます。IPv6 の詳細については、『 Cisco Unified Communications Manager 機能およびサービス ガイド 』のを参照してください。

（注） RSVP は Automated Alternate Routing（AAR; 自動代替ルーティング）と競合しません。AAR が設定されている場合、AAR は引き続き機能します。詳細については、「自動代替ルーティング」を参照してください。

RSVP エージェントの割り当て

Cisco Unified Communications Manager は、メディア ターミネーション ポイントとトランスコーダ リソースを割り当てるのと同じ方法で RSVP エージェント リソースを割り当てます。ユーザは、RSVP エージェントを含んだメディア リソース グループ リスト（MRGL）を設定し、その MRGL をデバイスまたはデバイスへ関連付けられたデバイス プールに割り当てます。コール中の両方のエンドポイントに同じ RSVP エージェントが割り当てられている場合、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 ポリシーを設定するには、Cisco CallManager サービスに、次のようなクラスタ全体（システム - RSVP）のサービス パラメータを設定します。

1. Cisco Unified Communications Manager の管理ページで、[システム(System)] > [サービスパラメータ(Service Parameters)] メニュー オプションを選択します。

2. [サービスパラメータ設定(Service Parameter Configuration)] ウィンドウで、サーバを選択し、Cisco CallManager サービスを選択します。

3. [Clusterwide Parameters (System - RSVP)] セクションで、Default interlocation RSVP Policy サービス パラメータを設定します。

このサービス パラメータは次の値に設定することができます。

• [No Reservation]：どのような 2 つのロケーション間にも RSVP 予約が作成されません。

• [Optional (Video Desired)]：オーディオとビデオの両方のストリームに関して予約を取得できなかった場合、ベストエフォート型のオーディオのみのコールとしてコールを継続できます。RSVP エージェントはオーディオに関する RSVP 予約を引き続き試み、予約が成功した場合は、Cisco Unified Communications Manager に通知します。

• [Mandatory]：Cisco Unified Communications Manager は、オーディオ ストリームに対して、またコールがビデオ コールの場合はビデオ ストリームに対して、RSVP 予約が成功するまで終端側デバイスの呼び出し音を鳴らしません。

• [Mandatory (Video Desired)]：ビデオ コールは、オーディオ ストリームの予約が成功してビデオ ストリームの予約が成功しなかった場合、オーディオ専用として継続できます。

サービス パラメータの詳細については、『 Cisco Unified Communications Manager アドミニストレーション ガイド 』の 「サービス パラメータの設定」 の章を参照してください。

ロケーション ペア RSVP ポリシー

ロケーション ペアの RSVP ポリシーを設定するには、[ロケーションの設定(Location Configuration)] ウィンドウを使用します。ロケーション ペアに対して設定された RSVP ポリシーは、[サービスパラメータ設定(Service Parameter Configuration)] ウィンドウで設定されるデフォルトのロケーション間 RSVP ポリシーよりも優先されます。

ロケーション ペアに RSVP ポリシーを設定するには、次のようにして、そのロケーション ペアの [RSVP設定(RSVP Setting)] フィールドを設定します。

1. Cisco Unified Communications Manager の管理ページで、[システム(System)] > [ロケーション(Location)] メニュー オプションを選択します。

2. ロケーション ペアの 1 つのロケーションを見つけ、そのロケーションを選択します。

3. 選択したロケーションともう 1 つのロケーションの間の RSVP ポリシーを変更するには、ロケーション ペアのもう一方のロケーションを選択します。

4. [RSVP設定(RSVP Setting)] ドロップダウン リスト ボックスで、このロケーション ペアの RSVP ポリシーを選択します。

このフィールドは次の値に設定することができます。

• [Use System Default]：ロケーション ペアの RSVP ポリシーは、クラスタ全体の RSVP ポリシーと一致します。詳細については、「クラスタ全体のデフォルト RSVP ポリシー」を参照してください。

• [No Reservation]：どのような 2 つのロケーション間にも RSVP 予約が作成されません。

• [Optional (Video Desired)]：オーディオとビデオの両方のストリームに関して予約を取得できなかった場合、ベストエフォート型のオーディオのみのコールとしてコールを継続できます。RSVP エージェントはオーディオに関する RSVP 予約を引き続き試み、予約が成功した場合は、Cisco Unified Communications Manager に通知します。

• [Mandatory]：Cisco Unified Communications Manager は、オーディオ ストリームに対して、またコールがビデオ コールの場合はビデオ ストリームに対して、RSVP 予約が成功するまで終端側デバイスの呼び出し音を鳴らしません。

• [Mandatory (Video Desired)]：ビデオ コールは、オーディオ ストリームの予約が成功してビデオ ストリームの予約が成功しなかった場合、オーディオ専用として継続できます。

RSVP の再試行

RSVP の再試行の頻度と回数を設定するには、次に示すクラスタ全体（システム - RSVP）のサービス パラメータを使用します。

• RSVP Retry Timer

• Mandatory RSVP Midcall Retry Counter

これらのサービス パラメータを見つけて設定するには、次の手順を実行します。

1. Cisco Unified Communications Manager の管理ページで、[システム(System)] > [サービスパラメータ(Service Parameters)] メニュー オプションを選択します。

2. [サービスパラメータ設定(Service Parameter Configuration)] ウィンドウで、サーバを選択し、Cisco CallManager サービスを選択します。

3. [Clusterwide Parameters (System - RSVP)] セクションで、指定されたサービス パラメータを設定します。

このサービス パラメータは次の値に設定することができます。

• [RSVP Retry Timer]：RSVP 再試行タイマー値を秒単位で指定します。このパラメータを 0 に設定すると、そのシステムの RSVP 再試行が使用不可になります。

• [Mandatory RSVP Midcall Retry Counter]：RSVP ポリシーで [Mandatory] が指定され、コール中エラー処理オプションが [call fails following retry counter exceeds] に設定されているときに、コール中 RSVP 再試行カウンタを指定します。デフォルト値では 1 回が指定されています。このサービス パラメータを -1 に設定した場合、予約が成功するかコールが破棄されるまで、再試行が無限に続行されます。

サービス パラメータの詳細については、『 Cisco Unified Communications Manager アドミニストレーション ガイド 』の 「サービス パラメータの設定」 の章を参照してください。

コール中 RSVP エラー処理

コール中 RSVP エラー処理を設定するには、次のクラスタ全体（システム - RSVP）のサービス パラメータを使用します。

• Mandatory RSVP mid call error handle option

このサービス パラメータを見つけて設定するには、次の手順を実行します。

1. Cisco Unified Communications Manager の管理ページで、[システム(System)] > [サービスパラメータ(Service Parameters)] メニュー オプションを選択します。

2. [サービスパラメータ設定(Service Parameter Configuration)] ウィンドウで、サーバを選択し、Cisco CallManager サービスを選択します。

3. [Clusterwide Parameters (System - RSVP)] セクションで、指定されたサービス パラメータを設定します。

Mandatory RSVP mid call error handle option サービス パラメータは、次の値に設定できます。

• [Call becomes best effort]：コール中に RSVP に障害が起きた場合、コールはベストエフォート型コールになります。再試行が使用可能になっている場合、RSVP 再試行の試みが同時に開始されます。

• [Call fails following retry counter exceeds]：コール中に RSVP に障害が起きた場合、コールは RSVP の N 回の再試行の後に失敗します。N は Mandatory RSVP Mid-call Retry Counter サービス パラメータで指定されます。

サービス パラメータの詳細については、『 Cisco Unified Communications Manager アドミニストレーション ガイド 』の 「サービス パラメータの設定」 の章を参照してください。

MLPP から RSVP への優先レベル マッピング

発信者の MLPP 優先順位から RSVP 優先レベルへのマッピングを設定するには、次に示すクラスタ全体（システム - RSVP）のサービス パラメータを使用します。

• MLPP EXECUTIVE OVERRIDE To RSVP Priority Mapping

• MLPP FLASH OVERRIDE To RSVP Priority Mapping

• MLPP FLASH To RSVP Priority Mapping

• MLPP IMMEDIATE To RSVP Priority Mapping

• MLPP PL PRIORITY To RSVP Priority Mapping

• MLPP PL ROUTINE To RSVP Priority Mapping

これらのサービス パラメータを見つけて設定するには、次の手順を実行します。

1. Cisco Unified Communications Manager の管理ページで、[システム(System)] > [サービスパラメータ(Service Parameters)] メニュー オプションを選択します。

2. [サービスパラメータ設定(Service Parameter Configuration)] ウィンドウで、サーバを選択し、Cisco CallManager サービスを選択します。

3. [Clusterwide Parameters (System - RSVP)] セクションで、指定されたサービス パラメータを設定します。

このサービス パラメータは次のように機能します。

• Cisco Unified Communications Manager は RSVP 予約の初期化時に、発信者の優先順位を RSVP 優先レベルへマッピングし、サービス パラメータ値が高いほど優先レベルが高くなるよう設定します。

• IOS ルータは、RSVP 優先レベルに基づいてコールの優先処理を行います。

• RSVP エージェントは RSVP 予約が失敗した理由を、優先処理の原因も含め、Cisco Unified Communications Manager に通知する必要があります。

• Cisco Unified Communications Manager は、既存の MLPP メカニズムを使用して、優先処理の対象となった発信側と着信側に優先処理に関する通知を行います。

サービス パラメータの詳細については、『 Cisco Unified Communications Manager アドミニストレーション ガイド 』の 「サービス パラメータの設定」 の章を参照してください。

TSpec

TSpec オブジェクトは、送信者が生成するトラフィックを記述したものです。TSpec は、ネットワークを通じてすべての中間ルータと宛先のエンドポイントへ転送されます。中間ルータは、このオブジェクトを変更せず、オブジェクトは最終的な受信者（単数または複数）へ無変更のまま配信されます。

TSpec オブジェクトは、次の要素から構成されます。

• averageBitRate（kb/s）

• burstSize（バイト）

• peakRate（kb/s）

オーディオ 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 です。

ビデオ Tspec は、次の要素から構成されます。

• burstSize（バイト）：バースト サイズ係数（5）×最大パケット サイズ（1000）

• peakRate（バイト）：この要素は、エンドポイントが 1 回に伝送する 1 秒当たりの最大バイト数を表します。バーストがオーディオ ストリームのように小さい場合、peakRate は tokenRate の 1.1（または 1.2）倍として計算できます。

Cisco Unified Communications Manager は、最初に、ビデオ コール全体の帯域幅を使用してビデオ ストリームの帯域幅を予約しようとします。つまり、「384 kb + オーバーヘッド」です。

例：384 + 27 = 410 kb/s

ビデオ コール全体でも不十分な帯域幅が存在する場合、Cisco Unified Communications Manager は、次に、「（ビデオ コール帯域幅 - オーディオ ストリーム コーデック）+ オーバーヘッド」を帯域幅の量として予約しようとします。

例：(384 - 64) + 22 = 342 kb/s

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 エージェントの割り当てに失敗した場合）に、メディアの Differentiated Services Control Point（DSCP）マークをベストエフォート型に変更するよう指示します。そうでないと、EF マークの付いた過度のメディア パケットにより、たとえ予約のあるフローの場合でもサービス品質（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 Audio Application ID

• RSVP Video Application 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

会議ブリッジ、保留音サーバ、およびアナンシエータは、メディア リソース グループ リスト（MRGL）の設定を指定しないので、そのデバイスを関連する RSVP エージェントを持つデバイス プールへ関連付けると、そのデバイスに RSVP リソースを使用できるようになります。デバイス プールへ関連付けられた MRGL は、それらのタイプのメディア デバイス用に RSVP リソースを割り当てるために使用されます。

クラスタ間での RSVP の使用

RSVP では、ローカルとエンドツーエンドの 2 つの異なる設定を使用することによって、異なるクラスタ内のエンドポイント間の予約がサポートされています。

ローカル RSVP

ローカル RSVP では、異なるクラスタに配置されている 2 つの RSVP エージェント間の予約はサポートされていません。ローカル RSVP ではクラスタごとに 2 つの RSVP エージェントを使用し、クラスタ間を接続するトランクを経由して RSVP を使用することはありません。これが、デフォルトの設定です。

次のようなシナリオを考えてみます。

エンドポイント A － agentA － agentICT1 － ICT1 － ICT2 － agentICT2 － agentB － エンドポイント 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

エンドツーエンドの RSVP 設定は、クラスタが SIP トランクによって接続されている場合に使用できます。エンドツーエンドの RSVP では、エンドポイント間の接続全体で RSVP が使用され、RSVP エージェントがクラスタごとに 1 つだけ使用されます。

次のようなシナリオを考えてみます。

エンドポイント A － agentA － ICT1 － ICT2 － agentB － エンドポイント 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 Over SIP(RSVP Over SIP)] ドロップダウン リストから、[E2E(E2E)] を選択します。

• 必要に応じて [ローカルRSVPにフォールバック(Fall back to local RSVP)] フィールドを設定します。

• [SIP Rel1XXオプション(SIP Rel1XX Options)] ドロップダウン リストから、[無効(Disabled)] 以外のオプションを選択します。

SIP トランク設定の詳細については、『 Cisco Unified Communications Manager アドミニストレーション ガイド 』の 「SIP プロファイルの設定」 を参照してください。

コール用に RSVP を使用可能にする方法

コール用に RSVP を使用可能にするには、次の手順を実行します。

1. 発信側デバイスと着信側デバイスを別々のロケーションに割り当てます。

2. デフォルトのロケーション間ポリシーを [予約なし] 以外の設定値に設定するか、または、[ロケーションの設定(Location Configuration)] ウィンドウを使用して 2 つのロケーションの RSVP 設定値を [No Reservation] 以外に設定します。

3. RSVP エージェント リソースを含んだメディア リソース グループ リスト（MRGL）を、両方のエンドポイント デバイスに割り当てます。デバイスの設定ウィンドウ、または [デバイスプールの設定(Device Pool Settings)] ウィンドウを使用します。

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 と IPv6

RSVP は IPv6 をサポートしていません。RSVP コールは IPv4 をサポートしています。コールに RSVP が必要で、そのコールのデバイスが IPv6 のアドレス用に設定されているか、そのようなアドレスを使用している場合、Cisco Unified Communications Manager はコールを拒否し、発信側にはビジー トーンが聞こえます。IPv6 の詳細については、『 Cisco Unified Communications Manager 機能およびサービス ガイド 』のを参照してください。

RSVP とシェアドライン コール

図 9-3 は、シェアドライン コールの呼び出し音フェーズにおける RSVP 相互対話を示しています。

図 9-3 シェアドライン コール（呼び出し音フェーズ）での 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 エージェントを使用します。

図 9-4 は、シェアドライン コールに応答があった後の RSVP 相互対話を示しています。

図 9-4 シェアドライン コール（コール応答後フェーズ）での RSVP

電話機 B2（ロケーション 3 内）がシェアドライン コールに応答した後、ロケーション 1 とロケーション 2 の間の RSVP 予約、およびロケーション 1 とロケーション 4 の間の予約は破棄されます。ロケーション 1 とロケーション 3 の間の RSVP 予約だけが確立された状態になります。

RSVP と保留音

図 9-5 は、保留音を起動するコールを示しています。電話機 A と B の通話中に、電話機 B が電話機 A を保留状態にします。図 9-5 で、MOH サーバは電話機 A と同じロケーションにあります。

図 9-5 電話機 B が電話機 A を保留状態にし、MOH サーバが電話機 A と同じロケーションに存在する場合

RSVP は、電話機 A が保留状態になり保留音を受信している間、電話機 A と電話機 B の間の予約を保存します。電話機 A と電話機 B の間のコールが再開されると、予約されていたリソースが再使用されます。電話機 A と、その保留音を提供する MOH サーバは同じロケーションにあるので、電話機 A と MOH サーバの間に RSVP 予約は必要ありません。

図 9-6 は、保留音を起動するコールを示しています。電話機 A と B の通話中に、電話機 B が電話機 A を保留状態にします。この例では、MOH サーバは電話機 B と同じロケーションにあります。

図 9-6 電話機 B が電話機 A を保留状態にし、MOH サーバが電話機 B と同じロケーションに存在する場合

この例は、電話機 A と電話機 B の間の通話で、保留音サーバが電話機 B と同じロケーションにある場合を示しています。電話機 B が電話機 A を保留状態にし、電話機 A が保留音を受信する場合、電話機 A と電話機 B の接続に使用された予約は、保留音セッションに再使用されます。追加の予約は作成されません。

図 9-7 は、保留音を起動するコールを示しています。電話機 A と B の通話中に、電話機 B が電話機 A を保留状態にします。この例では、MOH サーバは電話機 A と電話機 B のどちらとも異なるロケーションを占めています。つまり、電話機 A、電話機 B、および保留音サーバが、それぞれ異なるロケーションに存在します。

図 9-7 電話機 B が電話機 A を保留状態にし、MOH サーバが第 3 のロケーションに存在する場合

電話機 B が電話機 A を保留状態にし、電話機 A が保留音を受信する場合、RSVP エージェントは電話機 A と電話機 B の接続に使用された予約を保存します。別の RSVP エージェントは、電話機 A と MOH サーバの間に新しい予約を作成します。

RSVP とコール転送

次の図は、コール転送シナリオでの RSVP 相互対話を示しています。図 9-8 は初期シナリオで、電話 A が電話 B と通話中です。

図 9-8 RSVP エージェント接続による電話機 A から電話機 B へのコール

この例では、電話機 A、DN 1000、ロケーション 1 が電話機 B、DN 2000、ロケーション 2 にコールします。RSVP エージェントは、そのコール用の予約を確立します。電話機 B は転送ボタンを押し、DN 3000 にダイヤルします。電話機 C、DN 3000、ロケーション 4 が、そのコールに応答します。

図 9-9 は、電話機 B が電話機 C へコールを転送するときの RSVP 接続を示しています。

図 9-9 電話機 B が電話機 A から電話機 C へのコールの転送を開始した場合

この設定で、電話機 B が電話機 A から電話機 C へのコールの転送を開始した場合、RSVP エージェントは電話機 A と電話機 B の間の予約を保存します。別の RSVP エージェントは、電話機 A と MOH サーバの間に新しい予約を作成します。電話機 B と電話機 C の間にも、RSVP エージェントによって新しい予約が作成されます。

図 9-10 は、転送が完了した後のシナリオを示しています。

図 9-10 コール転送が完了し、電話機 A と電話機 C が接続された場合

電話機 B が転送を完了すると、新しい RSVP 予約が電話機 A と電話機 C の間に作成されます。電話機 A と MOH サーバの間、電話機 A と電話機 B の間、および電話機 B と電話機 C の間の RSVP 予約は、すべて破棄されます。

RSVP と MLPP

ここでは、RSVP ベースのさまざまな MLPP シナリオについて説明します。

シナリオ 1：輻輳時に優先順位の低いコールの優先処理が行われます。

初期コール RSVP ポリシー：必須

コール中 RSVP ポリシー：コール失敗。再試行なし

その他の設定の詳細：RSVP 帯域幅は 100 kb/s です。それぞれのコールが 80 kb/s を取得します。したがって、予約の取得に成功するコールは 1 つだけです。

1. プライオリティ コールを開始します。

コールは成功します。

2. 標準コールを開始します。

[Mandatory] 設定のため、コールは初期化に失敗します。

3. フラッシュ コールを開始します。

コールは、プライオリティ コールに優先処理が行われるので成功します。

シナリオ 2：ビデオ コールは、十分な帯域幅が存在しない場合、オーディオ専用コールとして継続されます。

初期コール RSVP ポリシー：必須（ビデオが必要）

コール中 RSVP ポリシー：ベストエフォート

その他の設定の詳細：RSVP 帯域幅は 100 kb/s です。それぞれのオーディオ コールが 80 kb/s を取得します。したがって、予約の取得に成功するコールは 1 つだけです。

1. プライオリティ オーディオ コールを開始します。

コールは成功します。

2. フラッシュ ビデオ コールを開始します。

コールは、ビデオ コール用の十分な帯域幅が存在しないため、オーディオ専用として開始されます。プライオリティ コールの品質は低下します。

シナリオ 3：輻輳時に、より低いプライオリティのコールが良好な QoS なしで続行されます。

初期コール RSVP ポリシー：オプション

コール中 RSVP ポリシー：ベストエフォート

その他の設定の詳細：RSVP 帯域幅は 100 kb/s です。それぞれのオーディオ コールが 80 kb/s を取得します。したがって、予約の取得に成功するコールは 1 つだけです。

1. プライオリティ コールを開始します。

コールは成功します。

2. 標準コールを開始します。

コールは成功しますが、良好な QoS は得られません（コールは、別の DSCP を使用します）。

3. フラッシュ コールを開始します。

コールは成功します。プライオリティ コールの QoS は低下します。

4. フラッシュ コールを終了します（電話を切ります）。

プライオリティ コールは RSVP 予約を復旧し、QoS が向上します。

パフォーマンス モニタリング カウンタ

次の Cisco Unified Communications Manager RSVP アドミッション制御パフォーマンス モニタリング カウンタが存在します。

• RSVP AudioReservationErrorCounts

• RSVP MandatoryConnectionsInProgress

• RSVP OptionalConnectionsInProgress

• RSVP TotalCallsFailed

• RSVP VideoCallsFailed

• RSVP VideoReservationErrorCounts

これらのロケーション ベースおよびノード ベースのパフォーマンス モニタリング カウンタは、ノードを越えて同期化されることはありません。

RSVP エージェント リソースのトラブルシューティングを行うために、次の RSVP パフォーマンス モニタリング カウンタが存在します。

• OutOfResources

• ResourceActive

• ResourceAvailable

• ResourceTotal

パフォーマンス モニタリング カウンタの詳細および表示方法については『 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 の使用」を参照してください。