Cisco Unified CallManager システム ガイド Release 5.1(3)

RSVP の利点

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

• RSVP は複雑なトポロジを処理できます。ロケーション ベースの CAC がサポートするのは、ハブアンドスポーク型のネットワーク トポロジだけです。ロケーション ベースの 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 ポリシー レベルが用意されています。

–No reservation（ロケーション ベースの CAC の使用を続行）

–Mandatory

–Optional (video desired)

–Mandatory (video desired)

• RSVP には、再試行予約機能があります。この機能により、コールはリソース（帯域幅）が現在利用不能であっても、良好なサービス品質（QoS）を取得または再取得できます。

• RSVP Retry Timer では、再試行の頻度が制御されます。Mandatory RSVP Mid-call 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 CallManager のすべての補助サービスおよび補助機能と連携するので、そのサービスまたは機能が起動された後も帯域予約が正しいことが保証されます。サポートされる機能の例としては、Call Transfer、Conference、および Call Forwarding があります。

• RSVP は Music on Hold（MOH; 保留音）機能と Annunciator 機能をサポートします。

RSVP ベースの MLPP

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

• Cisco Unified CallManager は MLPP コールの優先順位を、SCCP サービス品質（QoS）メッセージによって RSVP Agent に渡します。

• エージェントは、RSVP 要求に優先順位情報を追加します。

• IOS ルータは、その優先順位情報を使用してコールを受け入れます。

• IOS ルータで優先処理が発生した場合、RSVP Agent は Cisco Unified CallManager に優先処理による予約の失敗を通知します。

• Cisco Unified CallManager は、優先処理の対象となった発信側と受信側に優先処理を通知します。Cisco Unified CallManager は、ロケーション ベースのコール アドミッション制御（CAC）MLPP 優先処理メカニズムによく似た、既存の MLPP 機能を使用します。

• 優先処理の対象となったコールは、失敗するか、低い QoS で続行されます。優先処理の対象となったコールは、コール中の予約の失敗と同じ扱いを受けます。

追加機能

Cisco Unified CallManager は、次の相互対話をサポートしています。

• RSVP Agent は、Differentiated Services Control Point（DSCP）マークの変更をサポートします。この機能は、たとえば Communicator や VTA など、デスクトップ アプリケーションでの信頼に関する問題を軽減します。

• RSVP は、オーディオ、ビデオ、およびデータのパススルーをサポートします。ビデオ データのパススルーでは、ビデオとデータのパケットが、RSVP Agent および Media Termination Point（MTP; メディア ターミネーション ポイント）デバイスを通過できます。また、ビデオ コールにオーディオ トランスコーディングを使用することもできます。オーディオ パススルーでは、暗号化されたコールが MTP を通過できます。

パススルーの条件

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

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

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

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

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

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

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

RSVP に関する注意点

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

• RSVP は、クラスタ間 RSVP Agent をサポートしません。つまり、RSVP は、異なるクラスタに置かれている 2 台の RSVP Agent 間での予約をサポートしません。

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

エンドポイント A -- agentA -- agentICT1 -- ICT1 -- ICT2 -- agentICT2 -- agentB -- エンドポイント B

ここで、A はクラスタ 1 内のエンドポイントを指定し、B はクラスタ 2 内のエンドポイントを指定し、ICT1 と ICT2 はクラスタ 1 内とクラスタ 2 内のクラスタ間トランクを指定し、RSVP Agent はそれぞれのデバイスに関連付けられています。

このシナリオで、Cisco Unified CallManager 1 は agentA と agentICT1 の間の予約を制御し、Cisco Unified CallManager 2 は agentB と agentICT2 の間の予約を制御します。

代替の方法として、IP-IP ゲートウェイを使用することもできます。詳細については、「ゲートキーパーとトランク」を参照してください。

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

• Cisco Unified CallManager は、デバイス モビリティをサポートしていません。デバイスのメディア リソース グループ リスト（MRGL）は静的に設定されるので、MRGL はデバイスが移動したときに自動更新されません。

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

RSVP Agent の割り当て

Cisco Unified CallManager は、メディア ターミネーション ポイントとトランスコーダ リソースを割り当てるのと同じ方法で RSVP Agent リソースを割り当てます。ユーザは、RSVP Agent を含んだメディア リソース グループ リスト（MRGL）を設定し、その MRGL をデバイスまたはデバイスへ関連付けられたデバイス プールに割り当てます。コール中の両方のエンドポイントに同じ RSVP Agent が割り当てられている場合、RSVP 予約は失敗します。

RSVP Agent とロケーション ベースの CAC との相互対話

ロケーション ベースのコール アドミッション制御（CAC）と RSVP の両方を同時にアクティブにしないことを推奨します。ただし、ロケーション ベースの CAC から RSVP への移行期間中は除きます。

ロケーション内でロケーション帯域幅が無制限（無限の帯域幅）に設定されていない場合、Cisco Unified CallManager は、RSVP を実行する前にロケーション ベースの CAC を実行します。ロケーション ベースの CAC が失敗した場合、コールは失敗し、Cisco Unified CallManager は RSVP を起動しません。

ロケーション内でロケーション帯域幅が無制限（無限の帯域幅）に設定されている場合、Cisco Unified CallManager は、発信側と着信側に関連付けられているロケーション ペアの RSVP ポリシーに基づいて、RSVP を起動します。

クラスタ全体のデフォルト RSVP ポリシー

クラスタ全体の RSVP ポリシーを設定するには、Cisco CallManager サービスに、次のようなクラスタ全体（System RSVP）のサービス パラメータを設定します。

1. Cisco Unified CallManager の管理ページで、 ［システム］ >［サービス パラメータ］ メニュー オプションを選択します。

2. ［サービス パラメータ設定（Service Parameter Configuration）］ウィンドウで、サーバを選択し、Cisco CallManager サービスを選択します。

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

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

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

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

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

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

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

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

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

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

1. Cisco Unified CallManager の管理ページで、 ［システム］ >［ロケーション］ メニュー オプションを選択します。

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

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

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

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

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

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

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

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

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

RSVP の再試行

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

• RSVP Retry Timer

• Mandatory RSVP Mid-call Retry Counter

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

1. Cisco Unified CallManager の管理ページで、 ［システム］ >［サービス パラメータ］ メニュー オプションを選択します。

2. ［サービス パラメータ設定（Service Parameter Configuration）］ウィンドウで、サーバを選択し、Cisco CallManager サービスを選択します。

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

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

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

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

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

コール中 RSVP エラー処理

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

• Mandatory RSVP mid call error handle option

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

1. Cisco Unified CallManager の管理ページで、 ［システム］ >［サービス パラメータ］ メニュー オプションを選択します。

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 exceeded］：コール中に RSVP に障害が起きた場合、コールは RSVP の N 回の再試行の後に失敗します。ただし、N は Mandatory RSVP Mid-call Retry Counter サービス パラメータで指定されます。

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

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

発信者の MLPP 優先順位から RSVP 優先レベルへのマッピングを設定するには、次に示すクラスタ全体（System - 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 CallManager の管理ページで、 ［システム］ >［サービス パラメータ］ メニュー オプションを選択します。

2. ［サービス パラメータ設定（Service Parameter Configuration）］ウィンドウで、サーバを選択し、Cisco CallManager サービスを選択します。

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

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

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

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

• RSVP Agent は RSVP 予約が失敗した理由を、優先処理の原因も含め、Cisco Unified CallManager に通知する必要があります。

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

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

TSpec

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

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

• averageBitRate（kbps）

• burstSize（バイト）

• peakRate（kbps）

オーディオ TSpec

オーディオ フローの場合、TSpec の計算で次の値が指定されます。

• burstSize（バイト）：パケット サイズに 1 バースト内のパケット数を乗算したサイズとして計算されます。オーディオ フローの場合、通常のバーストは 1 ～ 2 です。

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

コールに応答があったときに帯域予約が上方修正されることを避けるため、Cisco Unified CallManager は、コールの設定時に各リージョン コーデックの最大帯域幅を予約します。その後、Cisco Unified CallManager はコールに対する応答があったときに、接続先メディアの能力に基づいて帯域幅を修正または調整します。

オーディオ TSpec の計算例

コールの設定については、次に示すさまざまなリージョン コーデックの帯域幅計算例を参照してください。

G.711： 8 サンプル/フレーム、10 ms パケットの場合：80 + 40 （ヘッダー） = 120 * 100 （パケット/秒） = 12000 * 8 = 96 kbps ; (packet_size_in_ms*8+40)*8000/packet_size_in_ms

G.729： 10 ms/フレーム、8 kbps、デフォルトは 20 ms、0 と 10 が可能。10 ms パケットの場合：10 + 40 = 50 * 100 = 5000 * 8 = 40 kbps

kbps： (packet_size_in_ms+40)*8000/packet_size_in_ms

G.711 コーデックの TSpec では、次の計算が指定されます。

Tspec.mAverageBitRate = bwPlusHeader = 96 kbps

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 CallManager は、最初に、ビデオ コール全体の帯域幅を使用してビデオ ストリームの帯域幅を予約しようとします。つまり、「384 kb + オーバーヘッド」です。

例：384 + 27 = 410 kbps

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

例：(384 - 64) + 22 = 342 kbps

384 kb コーデックの Tspec では、次の計算が指定されます。

Tpsec.mAverageBitRate = bwPlusHeader = 410 kbps

Tspec.mPeakRate = Tspec.mAverageBitRate = 410

Tspec.mBurstSize = 1000 * 5 = 5000

DSCP

RSVP 予約が失敗した場合、Cisco Unified CallManager は RSVP Agent またはエンドポイント（RSVP Agent の割り当てに失敗した場合）に、メディアの Differentiated Services Control Point（DSCP）マークをベストエフォート型に変更するよう指示します。そうでないと、EF マークの付いた過度のメディア パケットにより、たとえ予約のあるフローの場合でもサービス品質（QoS）が劣化する可能性があります。

Cisco Unified CallManager は、コールの RSVP に障害が起きたとき、クラスタ全体（System QoS）の DSCP for Audio Calls When RSVP Fails サービス パラメータまたは DSCP for Video Calls When RSVP Fails サービス パラメータを使用して、この指示に対する DSCP 値を決定します。

アプリケーション ID

アプリケーション ID は、RSVP メッセージ内のポリシー要素に挿入できる RSVP オブジェクトを指定します。このオブジェクトは、RFC 2872 に記述されています。このポリシー オブジェクトはアプリケーションの識別に役立ち、アプリケーションを RSVP 予約要求に関連付けます。そのアプリケーション情報に基づいて、パス上にあるルータは適切な決定を下すことができます。

次のクラスタ全体（System - RSVP）のシステム パラメータにより、アプリケーション ID を設定できます。

• RSVP Audio Application ID

• RSVP Video Application ID

メディア デバイスの RSVP

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

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

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

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

2. デフォルトのロケーション間ポリシーを「No Reservation」以外の設定値に設定するか、または、［ロケーションの設定（Location Configuration）］ウィンドウを使用して 2 つのロケーションの RSVP 設定値を「No Reservation」以外に設定します。

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

RSVP での特別な設定

RSVP セッションでは、次の条件がすべてあてはまる場合、特別な設定が適用されます。

• 1 つのエンドポイント デバイス（Cisco IP Interactive Voice Response（IP IVR）など）が、G.711 コーデックだけをサポートするように設定されている。

• コールに RSVP が設定されている。

• 発信側 RSVP Agent と着信側 RSVP Agent の間のリージョン間コーデックが G.729 である。

コールが発信されるときに RSVP Agent のリソースと帯域幅の正常な割り当ておよび予約を行うために、管理者はメディア ターミネーション ポイント（MTP）/RSVP Agent にパススルー コーデックだけではなく G.729 コーデックを設定する必要があります。この設定により、メディア接続時に着信側の RSVP Agent と着信側デバイスの間にトランスコーダを挿入できます。コーデックが一致する場合は、コーデック パススルーが実行されます。コーデックが一致しない場合は、トランスコーダがないとコールを継続できません。

エージェントに G.729 コーデックが設定されていない場合は、RSVP コールに必要なトランスコーダを Cisco Unified CallManager が起動しないため、コールは失敗します。

このような状況が発生するのは、発信側エージェントと着信側エージェントの間、または G.729 を指定する 2 つのエンドポイントの間で、リージョン間コーデックが使用される場合です。このようなコールでルーティングを正常に行うには、次の 2 つの方法があります。

• IVR の RSVP Agent をトランスコーダとして使用します。この場合、トランスコーダ/RSVP Agent と IVR 間のリージョン間コーデックは G.711 コーデックである必要があります。

• ソフトウェア MTP を RSVP Agent として使用し、IVR と IVR の RSVP Agent の間にトランスコーダを挿入します。この場合、ソフトウェア MTP にパススルー コーデックだけではなく G.729 コーデックが設定されていることを確認します。

トランスコーディング機能を持つ RSVP Agent は、G.729 から G.729 へのトランスコーディングを実行できないことに注意してください。トランスコーダを RSVP Agent として使用する場合は、パススルー コーデックを使用するか、トランスコーダを設定して、トランスコーダの両側で使用されるコーデックのいずれかが G.711 であるようにする必要があります。

RSVP の設定チェックリスト

表9-1 に、RSVP を使用してコール アドミッション制御を設定する一般的な手順を示します。

RSVP と共有回線コール

図9-3 は、共有回線コールの呼び出し音フェーズにおける RSVP 相互対話を示しています。

図9-3 共有回線コール（呼び出し音フェーズ）での RSVP

この例は、共有回線コールの呼び出し音フェーズにおける次の設定を示しています。

• 電話機 B1（ロケーション 2 内）、B2（ロケーション 3 内）、および B3 と B4（どちらもロケーション 4 内）は、DN 2000 を共有します。

• ロケーション 1 の RSVP Agent には、単一のポートが割り当てられています。そのポートには、複数の宛先、つまり他のロケーション（2、3、および 4）にある各 RSVP Agent ごとに 1 つずつ、宛先があります。

• ロケーション 4 の RSVP Agent には、1 つのポートが割り当てられています。電話機 B3 と B4 は、そのポートを共有します。

DN 2000 を共有する電話機 B3 と B4 は、単一の RSVP Agent を使用します。

図9-4 は、共有回線コールに応答があった後の RSVP 相互対話を示しています。

図9-4 共有回線コール（コール応答後フェーズ）での RSVP

電話機 B2（ロケーション 3 内）が共有回線コールに応答した後、ロケーション 1 とロケーション 3 の間の RSVP 予約、およびロケーション 1 とロケーション 4 の間の予約は破棄されます。

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 Agent は電話機 A と電話機 B の接続に使用された予約を保存します。別の RSVP Agent は、電話機 A と MOH サーバの間に新しい予約を作成します。

RSVP とコール転送

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

図9-8 RSVP Agent 接続による電話機 A から電話機 B へのコール

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

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

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

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

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

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

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

RSVP と MLPP

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

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

初期コール RSVP ポリシー：Mandatory

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

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

1. Priority コールを開始します。

コールは成功します。

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

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

3. Flash コールを開始します。

コールは、Priority コールに優先処理が行われるので成功します。

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

初期コール RSVP ポリシー：Mandatory（Video Desired）

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

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

1. Priority オーディオ コールを開始します。

コールは成功します。

2. Flash ビデオ コールを開始します。

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

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

初期コール RSVP ポリシー：Optional

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

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

1. Priority コールを開始します。

コールは成功します。

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

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

3. Flash コールを開始します。

コールは成功します。Priority コールの QoS は低下します。

4. Flash コールを終了します（電話を切ります）。

Priority コールは RSVP 予約を復旧し、QoS が向上します。

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

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

• RSVP AudioReservationErrorCounts

• RSVP MandatoryConnectionsInProgress

• RSVP OptionalConnectionsInProgress

• RSVP TotalCallsFailed

• RSVP VideoCallsFailed

• RSVP VideoReservationErrorCounts

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

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

• OutOfResources

• ResourceActive

• ResourceAvailable

• ResourceTotal

パフォーマンス モニタリング カウンタの詳細については、『 Cisco Unified CallManager Serviceability システム ガイド 』を参照してください。パフォーマンス モニタリング カウンタの表示方法については、『 Cisco Unified CallManager Serviceability アドミニストレーション ガイド 』を参照してください。

コール詳細レコード

Cisco Unified CallManager Quality of Service (QoS) RSVP Agent 機能によって、次のコール詳細レコード（CDR）フィールドが追加されます。

• origRSVPAudioStat：発信側から終端側への RSVP オーディオ予約の状態

• destRSVPAudioStat：終端側から発信側への RSVP オーディオ予約の状態

• origRSVPVideoStat：発信側から終端側への RSVP ビデオ予約の状態

• destRSVPVideoStat：終端側から発信側への RSVP ビデオ予約の状態

これらのフィールドには、オーディオまたはビデオ ストリームの RSVP 帯域幅予約の状態が反映されます。

Cisco Unified CallManager RSVP CDR 状態フィールドには、次の値が適用されます。

• 0：RSVP NO RESERVATION 状態を示します。これがデフォルト値です。

• 1：コールの設定時または機能の起動時の RSVP RESERVATION FAILURE 状態を示します。

• 2：コールの設定時または機能の起動時の RSVP RESERVATION SUCCESS 状態を示します。

• 3：コールの設定時または機能の起動時の RSVP RESERVATION NO RESOURCE（RSVP Agent）状態を示します。

• 4：RSVP MID_CALL FAILURE_PREEMPTED 状態（コールの設定後に優先処理が行われた）を示します。

• 5：RSVP MID_CALL FAILURE_LOST_BANDWIDTH 状態（MLPP 優先処理以外のすべてのコール中機能を含む）を示します。

Cisco Unified CallManager RSVP CDR 状態フィールドの値は連結され、コールについて最新の 32 個の状態値が保存されます。

例

Optional RSVP ポリシーを使用してコールが確立され、初期 RSVP 予約が成功します。その後、コールは帯域幅予約を失い、再試行後に帯域幅予約を再取得します。このシーケンスが、コール中に何度も繰り返され、コールは RSVP 予約に成功して終了します。この場合、CDR は、その特定のストリームについて、次の文字列を Cisco Unified CallManager RSVP 予約状態として示します。

"2:5:2:5:2:5:2" (success:lost_bw:success:lost_bw:success:lost_bw:success)

詳細については、『 Cisco Unified CallManager Call Detail Record Definitions 』を参照してください。

アラーム

使用できる RSVP Agent リソースがないときは、RsvpNoMoreResourcesAvailable という Cisco Unified CallManager Serviceability アラームが生成されます。

このアラームは、Cisco Unified CallManager アラーム カタログ /vob/ccm/Common/XML/AlarmCatalog/CallManager.xml で定義されています。

詳細については、『 Cisco Unified CallManager Serviceability システム ガイド 』および『 Cisco Unified CallManager Serviceability アドミニストレーション ガイド 』を参照してください。

トレース情報

RSVP では、RSVP 予約に失敗したとき、Cisco CallManager サービスについて、いくつかの SDL トレースおよび SDI トレースが生成されます。Cisco Unified CallManager の SDL と SDI のどちらのトレース ファイルにも、RSVP エラー コードがあります。

RSVP Agent は、次の 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

詳細については、『 Cisco Unified CallManager Serviceability システム ガイド 』および『 Cisco Unified CallManager Serviceability アドミニストレーション ガイド 』を参照してください。