Cisco IOS XR セッション ボーダー コントローラ コンフィギュレーション ガイド Cisco IOS XR Software Release 3.5
課金のサポートに関する追加情報
課金のサポートに関する追加情報
発行日;2013/09/18 | 英語版ドキュメント(2013/05/14 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 6MB) | フィードバック

目次

課金のサポートに関する追加情報

スタンドアロン課金システム

統合課金システム

イベント メッセージの転送

複数サーバのサポート

イベント メッセージのバッチ処理

イベント メッセージの再送信

イベント メッセージ セットの概要

呼詳細レコード

CDR 形式

LDR 形式

部分コール形式

監査ログ形式

XML DTD

ファイル アクセス

CDR メディアの要件

領域要件

パフォーマンス要件

管理および設定

スタンドアロン モードの設定

統合モードの設定

SBC 課金の管理

ロギングおよびアラーム

耐障害性

ウォーム フェールオーバー

コールド フェールオーバー

セキュリティ

課金のサポートに関する追加情報

ここでは、課金に関する各種の内容について説明します。SBC の課金設定を行う前に、SBC 課金の特徴と機能をすべて理解しておくことが重要です。

スタンドアロン課金システム

統合課金システム

イベント メッセージの転送

呼詳細レコード

管理および設定

ロギングおよびアラーム

耐障害性

セキュリティ

スタンドアロン課金システム

スタンドアロンの課金および課金キャッシングは、統合モデル SBC またはスタンドアロン SBE の両方でサポートされます。スタンドアロン課金システムは、次の運用モードおよびイベントで構成されます。

コールが開始されると、SBC はそのコールの課金可能イベントの記録を開始します。

コールが終了すると、SBC は記録を停止し、イベントを単一の呼詳細レコード(CDR)にまとめます。

CDR がディスク上に保管されます。保管できる CDR 数は、使用可能なディスク領域によって制限されます。たとえば、24 時間分のレコードを保管するには、約 10 GB のディスク領域が必要です。

使用可能なディスク領域がなくなると、簡易ネットワーク管理プロトコル(SNMP)トラップの形式でアラーム ログが生成され、管理者に対して CDR を削除してディスク領域を解放するように要求が出されます。使用可能なディスク領域ができるまでは CDR はログに記録されませんが、システムはコールの受け入れを継続します。

SBC には一連のしきい値が設定されています。これらのしきい値にはファイル サイズの増加によってトリガーされる段階的なアラームが定義されており、これにより管理者はディスク領域がなくなる前にディスク領域を解放できます。

CDR の形式は、Extensible Markup Language(XML)形式であり、ターゲットの課金プラットフォームに必要な形式として解析できます。

ソフトスイッチ ベンダーが CDR の生成に最もよく使用している CDR 形式は、 Billing Automatic Message Accounting Format(BAF)Generic Requirements (BAF-GR-1100-CORE)に規定されている Bellcore AMA 形式です。SBC などの次世代 Voice over IP(VoIP)アプリケーションにとっては好ましいことではありませんが、BAF 形式はテレフォニーに特化しているので、IP 中心のロギング情報には十分に対応していません。(たとえば、セッション記述プロトコル(SDP)または RTCP 統計情報はロギングされません)。また、この形式は拡張できないので、これらのフィールドを含む拡張を定義することはできません。

代替として最適なのは、XML 形式です。XML はフレキシブルな標準化方式で、異種プラットフォーム間(SBC と課金サーバ間など)でデータを変換する必要がある場合、最も一般的に使用されています。詳細については、「Cisco XR 12000 シリーズ ルータでのエンドツーエンド SBC の設定例」モジュールを参照してください。

統合課金システム

統合課金は PacketCable Event Messages アーキテクチャで実現されています(『PacketCable 1.5 Event Messages Specification』PKT-SP-EM1.5-I01-050128 を参照)。SBC がこのアーキテクチャに統合されている例を図 B-1 に示します。例に示すように、課金サーバとソフトスイッチの両方で PacketCable イベント メッセージをサポートします。

ISP-A では統合モデルの SBC が動作し、課金システムは 3 台の課金サーバで構成される分散課金システムとして展開されています。これら 3 台のサーバすべてに同時に送信したり、1 台をプライマリにして 2 台をバックアップで使用したりするなど、さまざまな方法でサーバに送信するよう SBC を設定できます。

統合モデルでは、システムが次のように動作します。

SBC は Event Message(EM; イベント メッセージ)を生成します。これらのイベント メッセージは、課金可能なイベントや、コール開始、コール終了、メディア タイプの変更などの関連イベントです。

SBC(およびシステムの他のエレメント)は EM を生成すると、RADIUS プロトコルを使用してリアルタイムに(またはネットワークの効率のためバッチで)EM を課金サーバに送信します。

課金サーバは、EM を呼詳細レコードにまとめます。

課金サーバが使用できない場合、EM が未送信としてマーキングされ、最大 24 時間保管されます。(EM は、使用可能な空き領域に応じて、Cisco XR 12000 シリーズ ルータのハードディスクに保管されます)。

アラーム ログが生成され、RADIUS サーバがオンラインに戻った場合に手動で CLI コマンドを入力すると、EM が RADIUS サーバに再送信されます。

ISP-B は、分散モデルで SBC が動作し、課金システムが 1 台の課金サーバと 1 つのソフトスイッチを使用して展開されていることを示しています。

分散モデルでは、システムは次のように動作します。

SBE だけが課金サーバと通信します。つまり、DBE によって生成されるイベント メッセージはありません。すべてのメディア固有情報(ゲート要求情報、メディア統計情報など)は DBE によって SBE に送信され、SBE では必要に応じてイベント メッセージが生成されて課金サーバに送信されます。

課金サーバは SBE とソフトスイッチの両方から課金情報を収集して、ISP に単一の課金ポイントを提供します。課金サービスとソフトスイッチ間の専用インターフェイスは、サービス プロバイダーが課金情報の取得に使用できる手段の 1 つです。これは SBC 課金の説明の範囲外になります。

課金サーバが使用できない場合、EM が未送信としてマーキングされ、最大 24 時間保管されます。アラーム ログが生成され、RADIUS サーバがオンラインに戻ると、課金コンポーネントにより EM が再送信されます。


) スタンドアロンの課金および課金キャッシングは、統合モデル SBC またはスタンドアロン SBE の両方でサポートされます。



) 『PacketCable 1.5 Event Messages Specification』では、発信側 INVITE と応答側 SDP の識別情報(BCID および FEID)を送信して 2 組の課金データ間で相互に関連付ける方法が説明されています。SBC は、ドメイン内伝送用としてもドメイン間伝送用としてもこのメカニズムをサポートしていません。課金サーバは代替方式を使用して相互に関連付けを行う必要があります(たとえば、着信電話番号とコール時刻)。


図 B-1 統合課金の導入

 

イベント メッセージの転送

生成されたイベント メッセージは、RADIUS プロトコルを使用して、設定済みの課金サーバ セットに送信されます(「イベント メッセージ セットの概要」を参照)。イベント メッセージの具体的な内容を知る前に、次のセクションで説明するイベント メッセージ転送の考慮事項について理解しておく必要があります。

複数サーバのサポート

イベント メッセージのバッチ処理

イベント メッセージの再送信

複数サーバのサポート

課金サーバは、起動時にセットとして設定されます。

各セットには、単一のプライマリ サーバとゼロ台以上の順序付けられたバックアップ サーバで構成された、1 台以上の課金サーバのリストが含まれます。

SBE には、1 つ以上の課金サーバ セットを設定できます。

各イベント メッセージはすべてのセットに送信されますが、各セット内の 1 台のサーバに対してだけ送信されます。

各セットについて、SBE はセット内のプライマリ サーバにイベント メッセージを送信します。

プライマリ サーバが使用不可の場合、メッセージは最初のバックアップ サーバ(設定されている場合)に送信されます。最初のバックアップ サーバも使用不可の場合、メッセージは 2 番めのバックアップ サーバに送信されます。同様に、いずれかのサーバによってメッセージが受信されるか、またはセット内のすべてのサーバに送信を試みるまで、メッセージの送信が試行されます。

セット内のどのサーバもメッセージを受け付けなかった場合、セット全体が使用不可としてマーキングされ、メッセージは(後で再送信されるように)そのセット用としてキャッシュされます。

図 B-2 に、複数サーバのサポートの例を示します。

図 B-2 複数サーバのサポート

 

イベント メッセージのバッチ処理

RADIUS プロトコルは非効率的であるため、SBE はイベント メッセージをバッチ処理し、単一の RADIUS メッセージを使用して送信することにより、転送メカニズムの負荷を軽減しています。

バッチ処理は、セット単位だけで実行できます。バッチのサイズは設定できませんが、課金コンポーネント上の負荷によって判別されます。

バッチ処理はディセーブルにできません。

イベント メッセージの再送信

課金サーバのセットから応答がなかった場合、次の手順によって、未送信のイベントをサーバに再送信できます。

セット内のどの課金サーバもイベント メッセージを受信しない場合。

SBE により、そのセットが使用不可としてマーキングされ、障害のあるセットのイベント メッセージの保管が開始されます(直前に送信できなかったイベント メッセージから開始されます)。メッセージは最大 24 時間保管されます。

SBE により、アラーム ログが生成されます。このアラームには、応答していないサーバ セットを示す情報が含まれています(「ロギングおよびアラーム」の項を参照)。

管理者が問題を解決し、コマンドライン インターフェイス(CLI)または SNMP クライアントを使用して、再送信を試行します。(問題を解決できない場合には、このメカニズムを使用してキャッシュをクリアすることもできます)。キャッシュから(修復された)課金サーバのセットにイベント メッセージが再送信され、正常に再送信された場合はキャッシュから削除されます。


) メッセージはすぐに再送信されるわけではなく、プライオリティの高い処理(正常なセットへのリアルタイム課金など)によって SBE のリソースが要求されておらず、利用可能な場合にのみ試行されます。たとえば、管理者が現地時間の午後 6 時(通常はビジー タイム)に再送信をトリガーしたとしても、送信に失敗したメッセージは、午後 1 時など、ネットワーク トラフィックが少なくなる時間まで再送信されないことがあります。


イベント メッセージ セットの概要

ここでは、SBC によってサポートされているイベント メッセージのセットについて説明します。

コール固有のメッセージ

アウトオブバンド メッセージ

サポートされないメッセージ

コール固有のメッセージ

表 B-1 に、サポートされるコール イベント メッセージを示します。

 

表 B-1 サポートされるイベント メッセージ セット

イベント メッセージ
注意事項

Signaling_Start

シグナリングが開始された時点(インバウンド)および開始される時点(アウトバウンド)で送信されます。たとえば、SIP エンドポイントで、着信の INVITE を受信した時点、または発信の INVITE を送信する時点です。

QoS_Reserve

DBE に予約済み QoS がある場合に送信されます。インバウンド QoS が予約されている場合にはインバウンド レッグ、アウトバウンド QoS が予約されている場合にはアウトバウンド レッグに対して送信されます。

Call_Answer

終端側からアンサーがあり、メディアが開始されたことを示します。このメッセージは、同時に両方のレッグに対して送信されます。

QoS_Commit

DBE により QoS がコミットされた時点で送信されます。このメッセージは、同時に両方のレッグに対して送信されます。

Call_Disconnect

コールが終了し、メディア フローが停止したことを示します。同時に両方のレッグに対して送信されます。

QoS_Release

DBE により QoS が解放されたことを示します。同時に両方のレッグに対して送信されます。

Signaling_Stop

コールの各側ですべてのシグナリングが完了したことを示します (このイベントは、最後のシグナリング メッセージが送信されると、各側で 1 回生成されます)。

Media_Statistics

DBE により、コールのメディア統計情報が報告されたことを示します。メディアが解放されると、各レッグに対して送信されます。

Media_Alive

長時間のコールがまだアクティブであることを示します。24 時間ごとに、事前に設定された時刻になると、コールの各レッグに対して送信されます。

アウトオブバンド メッセージ

表 B-2 に、コールに関連していない、アウトオブバンド イベント メッセージを示します。

 

表 B-2 アウトオブバンド イベント メッセージ セット

イベント メッセージ
注意事項

Time_Change

時刻が 200 ms を超えて変更された場合に送信されます。サマータイムの変更時などにも送信されます。

サポートされないメッセージ

表 B-3 に、サポートされないイベント メッセージを示します。

 

表 B-3 サポートされないイベント メッセージ

イベント メッセージ
注意事項
サポートされない理由

Database_Query

フリーダイヤル キャリア、LNP ルーティングなどについて、外部データベースへのクエリーを実行するときに送信されます。

SBC はデータベース クエリーをサポートしていません。

Service_Instance

サービスのインスタンスを示します。

SBC はサービスをサポートしていません (ソフトスイッチおよびアプリケーション サーバの方がサービスに適しています)。

Service_Activation

サービスのアクティベーションを示します。

Service_Deactivation

サービスの非アクティベーションを示します。

Interconnect_Start

Public Switch Telephony Network(PSTN; 公衆電話回線網)への相互接続時に送信されます。

SBC には Public Switched Telephone Network(PSTN; 公衆電話交換網)への直接のインターフェイスはありません。

Interconnect_Stop

PSTN への接続の終了時に送信されます。

Conference_Party_Change

マルチパーティ コールにおけるパーティ ステート変更を示します。

SBC は、マルチパーティ コールをサポートしていません。

呼詳細レコード

呼詳細レコード(CDR)の運用モードでは、ネットワーク プロトコルを使用したリアルタイムでの個々のメッセージの生成は実行されません(統合モードとは異なります)。代わりに、SBC は、各コールの最後に、独自の XML 形式による呼詳細レコードを生成します。

この CDR は、ディスク上のファイルに付加され、FTP(または SCP、NTP など、基盤のオペレーティング システムでサポートされる他のファイル アクセス モード)で取得できるように、定期的にフリップされます。

この運用モードは、従来のクラス 5 スイッチのモードと似ています。次の 3 種類の CDR がログに記録されます。

Basic CDR :最も一般的なレコード タイプで、完全なコールが記録されます。

Partial CDR :システムが致命的な障害からの回復を試みたときにのみ生成されるレコードで、終了コールに関する可能な限りの情報が記録されます。

Long duration record (LDR) :24 時間を超えて継続している各コールについて、24 時間ごとに生成されるレコードです。LDR を生成する時刻は設定可能です。

これらの 3 つに加え、最新の 1 時間の課金アクティビティの要約を示す監査ログが 1 時間ごとに生成されます。次の項では、各レコード タイプの形式、詳細な XML DTD 定義、およびファイル アクセスとメディアの要件について説明します。

CDR 形式

LDR 形式

部分コール形式

監査ログ形式

XML DTD

ファイル アクセス

CDR メディアの要件

CDR 形式

次の項では、レコードの形式について説明します。

XML レコードの分析

XML 要素


) 独自の形式を採用しているのは、現時点では、CDR 用のオープン規格 VoIP 形式が存在しないためです。


XML レコードの分析

次に、90 秒間の短いコールの XML レコードを示します。


) 明確に示すために、この例には余白が追加されています。実稼働環境では、レコード サイズを縮小するために、追加の余白はすべて除去されます。


<?xml version="1.0" ?>
 
<recordfile sbe="192.49.2.2">
<!-- BEGIN CALL RECORD -->
<call starttime="1110916754000"
endtime="1110916844000"
duration="90000" bcid="01234567890">
 
<party type="orig" phone="02083661177"/>
<party type="term" phone="02083677012"/>
 
<adjacency type="orig" name="csi_enfield" account="csi" vpn="csivpn"/>
<adjacency type="term" name="softswitch1" account="internal"/>
 
<connect time="1110916754150"/>
<disconnect time="1110916843790" reason="1"/>
 
<QoS reservetime="1110916754100"
committime="1110916754120"
releasetime="1110916843800">
<gate>
<flowinfo>
<local address="67.12.43.123" port="46512"/>
<remote address="67.84.141.2" port="44684"/>
<sd>
m=audio 0 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=ptime:20
</sd>
<RTCPstats>
PS=1245, OS=62345, PR=1362, OR=68095, PD=0, OD=0, PL=0, JI=0, LA=48, PC/RPS=1362, PC/ROS=68095, PC/RPR=1245, PC/RPL=0, PC/RJI=0, PC/RLA=33
</RTCPstats>
</flowinfo>
<flowinfo>
<local address="172.19.8.45" port="48152"/>
<remote address="172.23.65.41" port="47132"/>
<sd>
m=audio 0 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=ptime:20
</sd>
<RTCPstats>
PS=1362, OS=68095, PR=1245, OR=62345, PD=0, OD=0, PL=0, JI=0, LA=44,
 
PC/RPS=1245, PC/ROS=62345, PC/RPR=1362, PC/RPL=0, PC/RJI=0, PC/RLA=31
</RTCPstats>
</flowinfo>
</gate>
</QoS>
</call>
<!-- END CALL RECORD -->
</recordfile>
 

XML ファイルの階層は、次のとおりです。

ルート ドキュメント エレメントの recordfile。このエレメントには、CDR を記録する SBE が記述され、レコードのリストが含まれます。

ルート ドキュメント エレメントには、それぞれ 1 つの CDR を示す 0 以上のコール エレメントが含まれています。さらに、コール エレメントには次の情報が含まれています。

発信および終端のエンドポイントを示す 2 つのパーティ エレメント。2 つのみ(各タイプに 1 つずつ)存在する必要があります。

コールを受信した着信側の隣接と、コールがルーティングされた発信側の隣接を示す 2 つの隣接エレメント。アカウント名および(適用される場合には)VPN ID も記述されます。2 つのみ(各タイプに 1 つずつ)存在する必要があります。

コールが接続されたことを示す、オプションの接続エレメント。

コールが切断された時刻および理由を示す、オプションの切断エレメント。このエレメントは、接続エレメントも存在する場合にのみ記述されます。

メディア プレーンで QoS が予約、コミット、および解放されたことを示す 1 つ以上の QoS エレメント。複数の QoS エレメントがある場合、コール中に QoS が変更されたことを示しています。

各 QoS エレメントには、複数のゲート エレメントが含まれています(コールに必要な各ゲートに 1 つずつです。ゲートとは、メディア ゲートウェイを通過する単一メディア ストリームのインスタンスとして定義されます)。各ゲート エレメントには、ゲートの各側で終端するフローを示す flowinfo エレメントが、2 つだけ含まれています。各 flowinfo エレメントには、次の情報が含まれています。

ゲートのこちら側でパケットを送受信するローカル アドレスおよびポート。

ゲートの反対側でパケットを送受信するリモート アドレスおよびポート。

ゲートのこちら側のフローのコーデック パラメータを示すセッション記述子。これには、フローの SDP からの関連する「m =」行(ポート番号を除く)、および関連するすべての「a =」行が含まれます。ゲートによりフローがトランスコードされることがあるので、セッション記述子はゲートの各側で個別に記述されます。

Real-Time Control Protocol(RTCP)統計情報エレメント。 表 B-4 に、報告される統計情報を示します。


) PC/* 値はすべて、リモート エンドポイントから受信した検査 RTCP パケット数による推定値です。RTCP パケットを受信していない場合(リモート エンドポイントから送信されなかった、または中間デバイスによりドロップされた場合)でも、これらの値はすべて CDR に記述されますが、ゼロに設定されます。その他の値はすべてメディア ゲートウェイによって測定されるので、RTCP には依存しません。


 

表 B-4 RTCP 統計情報エレメントの略語

省略形
定義

PS

このフローで、リモート エンドポイントに送信された RTP パケット数。

OS

このフローで、リモート エンドポイントに送信された RTP パケットのオクテット数。IP/UDP/RTP ヘッダーは含まれますが、レイヤ 2 ヘッダーは含まれません。

PR

このフローで、リモート エンドポイントから受信した RTP パケット数。

OR

このフローで、リモート エンドポイントから受信した RTP パケットのオクテット数。IP/UDP/RTP ヘッダーは含まれますが、レイヤ 2 ヘッダーは含まれません。

PD

リモート エンドポイントから受信し、ローカルで廃棄された RTP パケット数。

OD

リモート エンドポイントから受信し、ローカルで廃棄された RTP パケットのオクテット数。IP/UDP/RTP ヘッダーは含まれますが、レイヤ 2 ヘッダーは含まれません。

PL

シーケンス番号の欠落から推定された、接続中に受信しなかったパケット数。

JI

このフローで、リモート エンドポイントから受信したパケットの平均ジッター。単位はミリ秒です。

LA

MG により測定された平均遅延。ミリ秒単位の整数値です。

PC/RPS

このフローで、リモート エンドポイントからこの MG に送信された RTP パケット数。

これを、リモート エンドポイントから受信したローカル RTP パケット数と比較することにより、このコール レッグでドロップされた着信パケット数を算出できます。

PC/ROS

このフローで、リモート エンドポイントからこの MG に送信された RTP パケットのオクテット数。

このオクテット カウントには、RTP ペイロード バイトが含まれますが、IP/UDP/RTP ヘッダーは含まれません。

PC/RPR

このフローで、この MG からリモート エンドポイントが受信した RTP パケット数。

これを、リモート エンドポイントに送信されたローカル RTP パケット数と比較することにより、このコール レッグでドロップされた発信パケット数を算出できます。

PC/RPL

このフローで、リモート エンドポイントにより損失として報告された RTP パケット数。

PC/RJI

リモート エンドポイントにより報告された、このフローで受信されたパケットの平均ジッター。単位はミリ秒です。

PC/RLA

このフローでの、この MG とリモート エンドポイント間の往復遅延の半分。単位はミリ秒です。

この往復遅延とは、この MG からパケットが送信されてから、パケットがリモート エンドポイントに到達し、この MG に戻されるまでにかかった時間です。

このフローの ep_round_trip_delay フィールドの値と、相手側の同フィールドの値を加算すると、このフロー ペアにおけるエンドツーエンドの往復遅延を算出できます。

XML 要素

表 B-5 に、XML 要素およびその属性を示します。

 

表 B-5 SBC 課金 CDR の XML 形式の要素

要素
属性
オプション
説明

recordfile

sbe

N

レコードを記録している SBE の IP アドレス。

call

starttime

N

コールが開始された時刻(シグナリングの開始時刻)。

endtime

N

コールが終了した時刻(シグナリングが終了し、リソースが解放された時刻)。

duration

N

コールの長さ(ms 単位)。

bcid

N

このコール レコードの(この SBE インスタンスに対しての)固有識別情報。

party

type

N

次のいずれかになります。

orig(このパーティがコールの発信側エンドポイントであることを示す)。

term(このパーティがコールの着信側エンドポイントであることを示す)。

phone

N

パーティの電話番号。

adjacency

type

N

次のいずれかになります。

orig(この隣接がコールの発信側の隣接であることを示す)。

term(この隣接が、コールがルーティングされた発信側の隣接であることを示す)。

name

N

管理者によって SBC に設定された隣接の名前。

account

N

管理者によって SBC に設定された、コールの発信側または終端側のブランチが属すアカウントの名前。

vpn

Y

隣接に関連付けられた VRF 名(存在する場合)。

connect

Time

N

コールが接続された時刻(メディア ゲートがオープンされた時刻)。

disconnect

time

N

コールが接続解除された時刻(メディア ゲートがクローズされた時刻)。

reason

N

切断の理由。

QoS

reservetime

Y

QoS が予約された時刻。

committime

Y

QoS がコミットされた時刻。QoS がコミットされた場合、必ず記述されます。

releasetime

N

QoS が解放された時刻。

gate

属性はありません。

flowinfo

属性はありません。

local

Address

N

パケットを送受信している IP アドレス。

Port

N

パケットが送受信されるポート番号。

remote

Address

N

パケットを送受信している IP アドレス。

Port

N

パケットが送受信されるポート番号。

sd

属性はありません。

RTCPStats

属性はありません。

LDR 形式

24 時間ごとの設定可能な時刻(通常は午前 0 時)に、SBE は現在のアクティブ コールの一覧をチェックして、次の構造の Long-Duration Call Record(LDR)を生成します。

<longcall bcid=”0123456789” starttime=”1110916754000”
duration=”90000000”>
<party type=”orig” phone=”02083661177”/>
<party type=”term” phone=”02083677012”/>
<adjacency type="orig" name="csi_enfield" account="csi" vpn="0A32F18"/>
<adjacency type="term" name="softswitch1" account="internal"/>
</longcall>
 

) このレコードの生成は、コールド フェールオーバーの制限に影響されます(「コールド フェールオーバー」を参照)。


部分コール形式

Partial CDR は、プライマリおよびバックアップの両システムの致命的な障害により、SBE に以前のコール情報がまったく存在しない、コールド フェールオーバーの場合に生成されます。

コールが解放された時点で、できる限り多くのデータが回復され、次の XML レコードが生成されます。

<partialcall bcid=”01234567890”>
<QoS releasetime = “1110916754000”>
<gate>
<flowinfo>
<local address="67.12.43.123" port="46512"/>
<remote address="67.84.141.2" port="44684"/>
<sd>
m=audio 0 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=ptime:20
</sd>
<RTCPstats>
PS=1245, OS=62345, PR=1362, OR=68095, PD=0, OD=0, PL=0, JI=0, LA=48,
PC/RPS=1362, PC/ROS=68095, PC/RPR=1245, PC/RPL=0, PC/RJI=0, PC/RLA=33
</RTCPstats>
</flowinfo>
<flowinfo>
<local address="172.19.8.45" port="48152"/>
<remote address="172.23.65.41" port="47132"/>
<sd>
m=audio 0 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=ptime:20
</sd>
<RTCPstats>
PS=1362, OS=68095, PR=1245, OR=62345, PD=0, OD=0, PL=0, JI=0, LA=44,
PC/RPS=1245, PC/ROS=62345, PC/RPR=1362, PC/RPL=0, PC/RJI=0, PC/RLA=31
</RTCPstats>
</flowinfo>
</gate>
</QoS>
</partialcall>

監査ログ形式

監査ログは、1 時間ごとに生成され、最新の 1 時間の課金アクティビティの要約が記録されます。XML フラグメントを次に示します。

<audit time=”1110916754000”>
<log>
<name>billable calls received</name>
<value>120</value>
</log>
<log>
<name>call records</name>
<value>100</value>
</log>
<log>
<name>long records</name>
<value>10</value>
</log>
<log>
<name>partial records</name>
<value>5</value>
</log>
<log>
<name>lost due to resources</name>
<value>2</value>
</log>
<log>
<name>lost due to error</name>
<value>1</value>
</log>
</audit>
 

各監査ログの構造は、次のとおりです。

<audit> </audit> タグ ペア:1970 年 1 月 1 日、午前 0 時(UTC)からの属性(ミリ秒単位)として、ログの時刻が記録されます。

次の情報から構成される、多数のログ可能なパラメータ

ログに記録できる項目のテキスト ラベルを示す name タグ

ログの値を示す value タグ

表 B-6 に、ログ項目の名前と値を示します。

 

表 B-6 ログ項目の名前および値

名前
値の範囲

billable calls received(課金可能な受信コール)

0 以上の整数。

call records(コール レコード)

0 以上の整数。

long records(長いレコード)

0 以上の整数。

partial records(部分レコード)

0 以上の整数。

lost due to resources(リソースによる損失)

0 以上の整数。

lost due to error(エラーによる損失)

0 以上の整数。

XML DTD

XML の doctype は、次のとおりです。

<!DOCTYPE recordfile [
<!ELEMENT recordfile (call | longcall | partialcall | audit)*>
<!ATTLIST recordfile sbe CDATA #REQUIRED>
<!ELEMENT call (party, party, adjacency, adjacency, connect?, disconnect?, QoS*)>
<!ATTLIST call starttime CDATA #REQUIRED
endtime CDATA #REQUIRED
duration CDATA #REQUIRED
bcid CDATA #REQUIRED>
<!ELEMENT party EMPTY>
<!ATTLIST party type CDATA #REQUIRED
phone CDATA #REQUIRED>
<!ELEMENT adjacency EMPTY>
<!ATTLIST adjacency type CDATA #REQUIRED
name CDATA #REQUIRED
account CDATA #REQUIRED
vpn CDATA #IMPLIED>
<!ELEMENT connect EMPTY>
<!ATTLIST connect time CDATA #REQUIRED>
<!ELEMENT disconnect EMPTY>
<!ATTLIST disconnect time CDATA #REQUIRED
reason CDATA #REQUIRED>
<!ELEMENT QoS (gate, gate*)>
<!ATTLIST QoS
reservetime CDATA #IMPLIED
committime CDATA #IMPLIED
releasetime CDATA #IMPLIED>
<!ELEMENT gate (flowinfo, flowinfo)>
<!ELEMENT flowinfo (local, remote, sd, RTCPStats)>
<!ELEMENT local EMPTY>
<!ATTLIST local address CDATA #REQUIRED
port CDATA #REQUIRED>
<!ELEMENT remote EMPTY>
<!ATTLIST remote address CDATA #REQUIRED
port CDATA #REQUIRED>
<!ELEMENT sd (#PCDATA)>
<!ELEMENT RTCPblock (#PCDATA)>
<!ELEMENT longcall (party, party)>
<!ATTLIST longcall starttime CDATA #REQUIRED
duration CDATA #REQUIRED
bcid CDATA #REQUIRED>
<!ELEMENT partialcall (QoS)>
<!ATTLIST partialcall bcid CDATA #REQUIRED>
<!ELEMENT audit (log*)>
<!ELEMENT log (name, value)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT value (#PCDATA)>
]>

ファイル アクセス

レコードは単一ファイルに付加され、FTP によって検索できるように、定期的にフリップされ、アクセス可能な場所にコピーされます。

書き込みに失敗すると、アラームが生成されます。

ファイル サイズが設定済みの値を超えると、管理者に警告するアラームが生成されます。アラームの重大度には、ファイル サイズしきい値までの進行状況により、マイナー、メジャー、クリティカルのレベルがあります。これらのアラームの設定および管理は、「ロギングおよびアラーム」の項で指定されています。

CDR メディアの要件

ここでは、不揮発性メディア(ディスク、テープ、NVRAM など)で SBC CDR をサポートするための要件について説明します。

領域要件

パフォーマンス要件

領域要件

各レコードのサイズは、約 1300 バイトです。推定レコード数は、次の条件に基づいています。

ピーク時に平均 90 秒間の 25,000 の同時コール

総合的な平均使用率は、ピーク時の 20%

24 時間のコール数、つまりレコード数(4,800,000 コール)

したがって、24 時間分のレコードを保管するために必要なメディア領域は、6,240,000,000 バイト、つまり 5.8 GB になります。メディア領域の使用サイズがこの値に近くなると、フリップされた完全なファイルをタイムリーに取得することが必要不可欠で、そうでないと SBC の領域が不足することになります。

パフォーマンス要件

パフォーマンス要件は、書き込みレートが、ピーク時の新規コール要求間の平均時間と等しいことです。

これは、90 ÷ 25,000 = 0.0036 秒になります。

したがって、必要な書き込み速度は、1,300 ÷ 0.0036 = 361,000 バイト/秒、または 353 KB/秒です。

管理および設定

課金には、次の一般的な設定が必要です。

スタンドアロン モードまたは統合モードのどちらの課金を使用するか(両方はサポートされません)。

その他の設定は、選択した運用モードによって異なります。

スタンドアロン モードの設定

スタンドアロンを指定する場合、次の設定情報が必要です。

マイナー、メジャー、クリティカルの各アラームを生成するための、CDR ファイルのマイナー、メジャー、クリティカル アラームのしきい値。

LDR を生成する時刻。

統合モードの設定

統合モードを指定する場合、次の設定情報が必要です。

割り当て済みのエレメント ID。インターネット サービス プロバイダー(ISP)によって割り当てられた ID です。この ID は、特定の課金サーバ セットにイベント メッセージを送信する SBE のセット全体で、一意でなければなりません。

イベント メッセージ キャッシュ ファイルのマイナー、メジャー、およびクリティカルのしきい値サイズ

ディスク上のイベント メッセージ キャッシュ ファイルの場所

Media_Alive メッセージを生成する時刻

RADIUS クライアント設定情報

統合モードでは、SBC の RADIUS クライアント コンポーネントが必要です。これには、設定が必要です(課金サーバのセットなど)。これらの各セットのステートは、そのセットのイベント メッセージ キャッシュ ファイルが存在するかどうかに応じて設定されます。管理者は、このステートを変更できます。ステートは、disabled(ディセーブル)、active(アクティブ)、failed(障害)、または resending(再送信)です。

SBC 課金の管理

課金コンポーネントは、SBC コマンドライン インターフェイスを使用して管理されます。『 Cisco IOS XR Session Border Controller Command Reference 』で、使用可能な課金コマンドを参照してください。

設定情報は、管理の変更を反映するために、リアルタイムで変更されます。具体的には、管理者は各セットの設定を、次の方法で変更できます。

ステートがディセーブルの場合、セットはディセーブルなので、そのセットまたはローカル キャッシュにイベント メッセージは送信されません。イネーブルにするには、管理者はステートをアクティブに設定する必要があります。

セットのステートがアクティブで、障害イベントが存在しない場合、管理者はステートをディセーブルに変更する必要がなければ、何も実行することはありません。

ステートが障害の場合、セットに障害があり、課金により障害メッセージがキャッシュされています。管理者は、ステートを次のどちらかに変更できます。

再送信(課金により、キャッシュされたメッセージの再送信が試行されます)

ディセーブル(キャッシュされているイベント メッセージが削除され、メッセージは送信されません)

このように、管理者は障害ステートのサーバをディセーブル ステートに変更し、さらにアクティブ ステートに変更することによって、キャッシュをすべてクリアして、セットを再起動することができます。

障害ステートからアクティブ ステートにステートを直接変更することはできません。

ステートが再送信の場合、課金により、キャッシュされているメッセージの再送信が試行されています。この処理が完了すると、ステートはアクティブ ステートに戻ります。処理に失敗すると、障害ステートになります。管理者は、ステートを次に変更できます。

障害(再送信を中断します)

ディセーブル(再送信を停止し、キャッシュをクリアします)

管理者は、ステートをディセーブルに変更し、さらにアクティブに変更することによって、キャッシュをクリアして、キャッシュを再送信することなく、送信を再開できます。

再送信ステートからアクティブ ステートにステートを直接変更することはできません。

図 B-3 に、この処理の概要を示します。

図 B-3 課金サーバ セットの管理ステート

 

ロギングおよびアラーム

アラームの生成は、課金がどのように統合されているかによって異なります。 表 B-7 を参照してください。

 

表 B-7 課金システムのロギング条件

課金システムのタイプ
ロギング条件

スタンドアロン課金のアラーム

アラームは、次の条件に基づいて生成されます。

CDR ファイルが設定済みのマイナーしきい値を超えると、マイナー アラームが生成されます。

CDR ファイルがメジャーしきい値を超えると、メジャー アラームが生成されます。

CDR ファイルがクリティカルしきい値を超えると、クリティカル アラームが生成されます。

統合課金のアラーム

アラームは、次の条件に基づいて生成されます。

キャッシュ ファイルのサイズが設定済みのしきい値を超えると、マイナー、メジャー、およびクリティカルのアラームが送信されます。

課金サーバが使用不可になると、次のように、アラームが生成されます。

設定されている課金サーバ セットの 1 つが使用不可になると、マイナー アラームが生成されます。

2 つ以上の課金サーバ セットが使用不可になると、メジャー アラームが生成されます。

すべての課金サーバが使用不可になると、クリティカル アラームが生成されます。

(注) この状況では、2 つ以上のアラーム条件が満たされていることになります(たとえば、1 つのサーバ セットだけが設定され、そのセットが使用不可になった場合)。最も重大度の高いアラームが優先されます。

耐障害性

SBC 課金システムは、次の 2 つのレベルの耐障害性を備えています。

ウォーム フェールオーバー:ライブ バックアップへのフェールオーバー(同じマシン上の 2 番めのカードなど)

コールド フェールオーバー:障害マシンと新規マシンとの間にソフトウェア接続が存在しない、新規マシンへのフェールオーバー

ウォーム フェールオーバー

バックアップ システムへのフェールオーバーの場合、ウォーム フェールオーバー メカニズムがサポートされます。ウォーム フェールオーバーの場合、次のようになります。

SBE 上のデータはまったく失われません。

DBE 上のコールのメディア統計情報の値がリセットされます(この情報は失われます)。

コールド フェールオーバー

バックアップ専用ではないマシンへのコールド フェールオーバーの場合には、障害のあるシステムから新規サーバへの移行中に、一部の課金データが失われます。移行中に完全に失われる課金レコード数は、1 回のフェールオーバーにつき、10,000 未満です。ただし、このような状況では、次の可能性があることに注意してください。

存続している課金レコードが破壊され、課金レコードを部分的にしか回復できないことがあります。特に、ローカル CDR 生成の場合には、コール終了までハード形式のログが生成されないため、この状況が発生しやすくなります。

イベント メッセージ キャッシュが障害マシン上に存在する場合には、火災、ハードウェア異常、またはその他の障害の原因によってディスク レコードを回復できず、より多くの課金イベントが失われることがあります。ただし、コールド フェールオーバーの所要時間よりも長く、課金サーバが使用不可かつ回復不能であることが前提であるため、実際には、この状況はほとんど発生しません。

CDR が書き込まれていたメディアが失われると、(FTP を使用してレコードを抽出することで)バックアップされていない CDR は、すべて失われます。

コールド フェールオーバー後は、長時間のコールを検出できません。データをシステムから回復できるのは、ネットワーク上でメディア終了などのイベントが発生した場合だけです。

セキュリティ

PacketCable 1.5 Event Messages Specification 』には、セキュリティ上、RADIUS プロトコルおよび IPSec を使用して課金メッセージを送信することが規定されています。


) リリース 3.4.0 では、独自の Request Authenticator に基づく RADIUS セキュリティ メカニズムだけがサポートされています。