Cisco Unified Communications Manager Business Edition システム ガイド for Cisco Unified Communications Manager Business Edition リリース 8.0(1)
Resource Reservation Protocol
Resource Reservation Protocol
発行日;2012/05/09 | 英語版ドキュメント(2010/03/31 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 4MB) | フィードバック

目次

Resource Reservation Protocol

RSVP の設定チェックリスト

RSVP の概要

RSVP の利点

RSVP の機能

RSVP ベースの MLPP

追加機能

RSVP に関する注意点

RSVP エージェントとサービス品質

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

RSVP エージェントとロケーション ベースの CAC との相互対話

RSVP の設定

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

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

RSVP の再試行

コール中 RSVP エラー処理

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

TSpec

オーディオ TSpec

ビデオ TSpec

DSCP

アプリケーション ID

メディア デバイスの RSVP

クラスタ間での RSVP の使用

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

RSVP での特別な設定

RSVP への移行

RSVP の相互対話の例

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

RSVP と保留音

RSVP とコール転送

RSVP と MLPP

RSVP のトラブルシューティング

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

コール詳細レコード

アラーム

トレース情報

エンドツーエンドの RSVP のトラブルシューティング

参考情報

Resource Reservation Protocol

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 メカニズムを有効なソリューションとして利用できます。

サービス品質(QoS)の基本として、すべての VoIP およびビデオ会議デバイスで RSVP を使用してアドミッション制御を提供することをお勧めします。

コール アドミッション制御(CAC)の詳細については、「コール アドミッション制御」を参照してください。

この章では、RSVP の概要を示し、Cisco Unified Communications Manager 内での RSVP 設定について説明します。また、RSVP への移行について説明し、RSVP の相互対話の例を示し、トラブルシューティング情報を示します。次のトピックがあります。

「RSVP の設定チェックリスト」

「RSVP の概要」

「RSVP エージェントとサービス品質」

「RSVP の設定」

「RSVP への移行」

「RSVP の相互対話の例」

「RSVP のトラブルシューティング」

「参考情報」

RSVP の設定チェックリスト

Resource Reservation Protocol(RSVP)は、IP ネットワーク内のリソースを予約するための、トランスポート レベルのリソース予約プロトコルです。RSVP は、ロケーション ベースのコール アドミッション制御(CAC)と並んで、CAC を達成するもう 1 つの方法を提供します。ロケーション ベースの CAC は、ポイントツーポイントの CAC メカニズムで構成され、トポロジの変更や複層トポロジは考慮されません。これに対して、RSVP ではこれらの要素が考慮されます。

表 7-1 に、RSVP を使用してコール アドミッション制御を設定する一般的な手順を示します。RSVP 機能の詳細については、「参考情報」を参照してください。

 

表 7-1 RSVP の設定チェックリスト

設定ステップ
手順および関連項目

ステップ 1

クラスタ全体のデフォルト RSVP ポリシーを設定します。

「RSVP の設定」

Cisco Unified Communications Manager アドミニストレーション ガイド 』の 「サービス パラメータの設定」

ステップ 2

クラスタ全体のデフォルト RSVP ポリシーとは異なる RSVP ポリシーを必要とするロケーション ペアがあれば、そのペア用の RSVP ポリシーを設定します。

Cisco Unified Communications Manager アドミニストレーション ガイド 』の 「ロケーションの設定」

ステップ 3

次に示すような、その他の RSVP 関連サービス パラメータを設定します。

RSVP の再試行

コール中 RSVP エラー処理

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

TSpec

DSCPdscp

アプリケーション ID

「RSVP の設定」

Cisco Unified Communications Manager アドミニストレーション ガイド 』の 「サービス パラメータの設定」

ステップ 4

メディア デバイス用の RSVP エージェントを設定します。

「メディア デバイスの RSVP」

Cisco Unified Communications Manager アドミニストレーション ガイド 』の 「デバイス プールの設定」

Cisco Unified Communications Manager アドミニストレーション ガイド 』の 「メディア リソース グループ リストの設定」

ステップ 5

SIP トランク経由でのエンドツーエンドの RSVP を設定します。

「クラスタ間での RSVP の使用」

Cisco Unified Communications Manager アドミニストレーション ガイド 』の 「SIP プロファイルの設定」

ステップ 6

コール用に RSVP を使用可能にします。

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

Cisco Unified Communications Manager アドミニストレーション ガイド 』の 「Cisco Unified IP Phone の設定」

Cisco Unified Communications Manager アドミニストレーション ガイド 』の 「メディア リソース グループ リストの設定」

RSVP の概要

RSVP には、次の機能があります。

RSVP 予約は、特定のセッション用に作成されます。セッションは、特定の宛先アドレス、宛先ポート、およびプロトコル識別子(TCP または UDP)を持つフローから構成されます。RSVP 予約では、それぞれのセッションが 1 つの独立した単位として扱われます。

RSVP メッセージは、メディア フロー パスと同じパスを通過します。

RSVP は単方向プロトコルなので、フローは 1 方向だけに予約されます。

RSVP は受信者指向プロトコルなので、ストリームの受信者が予約を要求します。

RSVP はユニキャストとマルチキャストの両方の環境をサポートします。

RSVP メッセージは、RSVP 以外のルータとスイッチを透過的に通過します。

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 は Automated Alternate Routing(AAR; 自動代替ルーティング)と競合しません。AAR が設定されている場合、AAR は引き続き機能します。詳細については、「自動代替ルーティング」を参照してください。


RSVP エージェントとサービス品質

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 への移行を容易にします。

図 7-1 は、RSVP エージェントで RSVP が設定されているCisco Unified Communications Manager ネットワークの例を示しています。

図 7-1 RSVP エージェントを使用して設定された Cisco Unified Communications Manager ネットワーク

 

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 の設定は、さまざまなサービス パラメータとその他のコンポーネントの設定で構成されています。RSVP を設定するために必要な各種サービス パラメータとその他の設定について、次に説明します。次のトピックがあります。

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

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

「RSVP の再試行」

「コール中 RSVP エラー処理」

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

「TSpec」

「DSCP」

「アプリケーション ID」

「メディア デバイスの RSVP」

「クラスタ間での RSVP の使用」

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

「RSVP での特別な設定」


ヒント 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 エージェンgと 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 に移行する方法を示しています。

1. RSVP エージェント A をロケーション 1 にインストールします。

2. RSVP エージェント B をロケーション 0(ハブ)にインストールします。

3. エージェント A を、ロケーション 1 にあるすべてのエンドポイントのメディア リソース グループ リストに追加します。

4. ハブにあるデバイスとその他のすべてのロケーションにあるデバイスも含め、ロケーション 1 にないすべてのエンドポイントのメディア リソース グループ リストにエージェント B を追加します。

5. ロケーション 1 から他のすべてのロケーションへの RSVP ポリシーを [Mandatory](または、必要であれば何か別のポリシー)に設定します。

6. ロケーション 1 のロケーション CAC 帯域幅制限を変更し、無制限とします。

図 7-2 は、この移行プロセスが適用されるロケーション設定を示しています。

図 7-2 ロケーション設定の最初のスポークの移行

 

上記の設定手順を実行すると、次の帯域幅がロケーションに適用されます。

 

ロケーション
帯域幅

0

無制限

1

無制限

2

1500

3

3000

4

3000

上記の設定手順を実行すると、次の RSVP ポリシーが適用されます。

 

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

1

1

なし

1

1 以外

必須

1 以外

1 以外

なし

上記の設定手順を実行すると、次のコール アドミッション制御(CAC)が行われます。

ロケーション 0、2、3、および 4 内のコールは、以前と同じ CAC を使用します。

ロケーション 1 内のコールは CAC の対象になりません。

ロケーション 0 とロケーション 1 との間のコールでは、RSVP CAC が使用されます。

ロケーション 1 とロケーション 2、3、または 4 との間のコールは、0 から 1 へのリンクに RSVP が使用され、0 から 2、0 から 3、または 0 から 4 へのリンクにロケーション ベースの CAC が使用されます。どちらかのメカニズムに障害が起きると、コールは失敗します。

RSVP の相互対話の例

ここでは、Cisco Unified Communications Manager のさまざまな機能およびサービスと RSVP の相互対話の例を示します。次のトピックがあります。

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

「RSVP と保留音」

「RSVP とコール転送」

「RSVP と MLPP」

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

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

図 7-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 エージェントを使用します。

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

図 7-4 シェアドライン コール(コール応答後フェーズ)での RSVP

 

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

RSVP と保留音

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

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

 

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

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

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

 

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

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

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

 

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

RSVP とコール転送

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

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

 

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

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

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

 

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

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

図 7-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 が向上します。

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 パフォーマンス モニタリング カウンタが存在します。

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 の使用」を参照してください。

 

表 7-2 エンドツーエンドの 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 が実行されていることを確認してください。

参考情報

関連項目

「RSVP の設定チェックリスト」

「RSVP の概要」

「RSVP エージェントとサービス品質」

「RSVP の設定」

「RSVP への移行」

「RSVP の相互対話の例」

「RSVP のトラブルシューティング」

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

Cisco Unified Communications Manager アドミニストレーション ガイド 』の 「ロケーションの設定」

「ルート パターン」

Cisco Unified Communications Manager アドミニストレーション ガイド 』の 「メディア リソース グループ リストの設定」

Cisco Unified Communications Manager アドミニストレーション ガイド 』の 「デバイス プールの設定」

Cisco Unified Communications Manager アドミニストレーション ガイド 』の 「リージョンの設定」

Cisco Unified Communications Manager アドミニストレーション ガイド 』の 「ルート パターンの設定」

Cisco Unified Communications Manager アドミニストレーション ガイド 』の 「ゲートキーパーの設定」

Cisco Unified Communications Manager アドミニストレーション ガイド 』の 「ゲートウェイの設定」

「Cisco Unified IP Phone」

Cisco Unified Communications Manager アドミニストレーション ガイド 』の 「Cisco Unified IP Phone の設定」

「ビデオ テレフォニーの概要」

Cisco Unified Communications Manager アドミニストレーション ガイド 』の 「トランクの設定」

Cisco Unified Communications Manager 機能およびサービス ガイド 』の 「Multilevel Precedence and Preemption」

参考資料

『Cisco Unified Communications Solution Reference Network Design (SRND)

『Cisco Unified Serviceability Administration Guide

『Cisco Unified Communications Manager CDR Analysis and Reporting Administration Guide

Cisco Multimedia Conference Manager (Command Reference) IOS のマニュアル