RSVP
- IETF RFC 2205
- End-to-End QoSを動的にサポート
- 帯域予約は方方向
- IPヘッダー46
- PathパケットはSession, Sender-TSpec,PHOPの情報をPathメッセージとしてNext Hopのルーターに渡す。
- Sessionは宛先IP,Port,UDP/TCP
- Sender-TSpecは特定のコーデックに必要な最大帯域数を指定
- PHOPは処理したIPアドレス
- Next HopルータがRSVP非対応の場合は透過
- ResvパケットはSession,NHOPを返信
RSVPへの移行
- CUCMは最初にRSVPがEnableになっているか確認してからLBMによってロケーションとリンクを確認するため容易に移行が可能。
- 1) Default inter-location RSVP Policyがenableになっている確認
- 2) デバイスのMRGLからRSVPエージェントを割り当て、RSVP予約リクエストを行う
- 3) RSVPエージェントから結果を受け取る
- 4) CUCMはCACがEnable(LBMがActive)か確認し、Enableの場合は有効なリンクから帯域確保を要求
- 5-1) 要求がOKだと、コールを開始する
- 5-2) 要求がNGだと、Call Treatment When No LBM Availableの設定を確認し、Callを許可する場合(allow call)はコールを開始
RSVPの設定(CUCM)
- Default inter-location RSVP PolicyをMandatory かMandatory(Video Desired)に変更
- 各拠点でRSVPエージェントを設定
- MRGおよびMRGLにRSVPエージェントを割り当て
- Call Treatment When No LBM AvailableをAllow Callに設定
- Default inter-location RSVP PolicyをMandatoryかMandatory(Video Desired)に変更
RSVPへの移行完了後の確認項目
- LBMをDisableにする
- 問題が発生したら、Default inter-location RSVP PolicyをNo Reservationへ変更
SCCP(アプリケーションID)
- RSVPでアプリケーションごとの帯域確保を行う(音声かビデオ)
- 12.4(6)T以降のIOSでサポート
- アプリケーションIDはRSVP Audio Application IDとRSVP Video Application IDのパラメータで設定
- CUCMはSCCPを使ってRSVPエージェントに送る
- RSVPエージェントはRSVPシグナルパケット(PATH/RCEV)にアプリケーションIDを付与して送付
- ビデオコール(音声とビデオ)の場合はVideo Application IDを使用する
SIPプレコンディション
- RFC3312とRFC4032に基づく
- RSVPメッセージはSIPトランクでは使われず、ポリシー情報をSIPパケットに乗せて送る
- SIPプレコンディションでは事前にSDPパケットを送る。下記の場合は、現在のQoSの設定をnoneからend-to-end Mandatory sednrecvに変更し、呼び出し音を鳴らす前にネゴする。
SDP Packet(INVITE) SDP Packet (UPDATE)
a=curr:qos e2e none a=curr:qos e2e send
a=des:qos mandatory e2e ==> a=des:qos mandatory e2e
sendrecv sendrecv
クラスタ対応
- クラスタ間をSIPでつなぐと、End-to-EndでRSVPが有効になる(Ciscoでは推奨していない。)
- SIPトランクプロファイルでFall back to local RSVPを設定するとEnd-to-EndからローカルのRSVPにきり戻す設定が可能
- 対向からSIP 420(Bad Extension)が帰ってきた場合のみ。
- 対向からSIP 580(Precondition Failed)の場合はフォールバックしない
最終更新:2014年01月05日 00:07