RfインタフェースAPIを使用する方法について説明します。内容は次のとおりです。Rfインタフェースのサポートの概要オフライン・チャージングは、定期的に支払いを行うネットワーク・サービスに使用します。毎月支払いを行う必要がある音声コール・サブスクリプションをユーザーが利用する場合です。Rfプロトコルを使用することで、IMSチャージング・トリガー機能(CTF)からオフライン・イベントをチャージング・データ機能(CDF)へ発行することが可能になります。チャージング・イベントは、1回かぎりの(ワンタイム)イベントとすることも、セッション・ベースとすることもできます。ContainerはDiameterオフライン・チャージング・アプリケーションを提供します。デプロイ済のアプリケーションは、このアプリケーションを利用してRfプロトコルに基づくチャージング・イベントを生成します。Containerにデプロイ済のアプリケーションが、構成済のCDFのためにCTFとして機能することを可能にします。Protocol(http://www.ietf.org/rfc/rfc3588.txt)を参照してください。32.299(http://www.3gpp.org/ftp/Specs/html-info/32299.htm)を参照してください。3588で説明されているアカウンティング状態のマシンを実行します。ACCOUNTING」を実行します。CDFへのオフライン・チャージング・イベントのレポーティングは、Diameterアカウンティング・リクエスト(ACR)メッセージを通じて管理されます。Rfは、表11-1に記載されているACRイベント・タイプをサポートします。ACRイベント・タイプリクエスト説明STARTアカウンティング・セッションの開始INTERIMアカウンティング・セッションの更新STOPアカウンティング・セッションの終了EVENT1回かぎりの(ワンタイム)アカウンティング・イベントSTART、INTERIMおよびSTOPイベント・タイプは、セッション・ベース・アカウンティングに対し使用します。EVENTタイプは、イベント・ベース・アカウンティングに対し使用するか、セッションの確立が失敗したことを示すために使用します。EVENTメッセージを通じて報告されます。例11-1は、基本的なメッセージ・フローです。START、INTERIMおよびSTOPリクエストを使用して、CDFの使用を報告します。INTERIMリクエストを報告する可能性があります。例11-2は、基本的なメッセージ・フローです。Containerによるサービス・リクエストの受信時に送信されます。INTERIMは通常、AIIタイマーの時間切れ時点で送信されます。Containerによるサービス終了のリクエスト時に発行されます。APIは、プロファイル・データを管理するためのShアプリケーションと似たようなDiameterアプリケーションとしてパッケージされています。APIは、DOMAIN_ROOT/config/custom/diameter.xmlに格納されているDiameter構成ファイルを編集するか、Diameterコンソール拡張を使用して、構成および有効化できます。Rfアプリケーションへのcdf.realmおよびcdf.host初期化パラメータを使用して指定できます。例11-3は、CDFレルム「oracle.com」およびホスト「cdf.oracle.com:」でRfを有効化するdiameter.xmlから抜粋したサンプルです。</application>RfApplicationはDiameter基本アカウンティング・メッセージを使用するため、DiameterアプリケーションIDは「3」で、ベンダーIDはありません。Containerは、オフライン・チャージングAPIを提供します。このAPIにより、デプロイ済の任意のアプリケーションがCTFとして機能し、オフライン・チャージング・イベントを発行することが可能になります。このAPIは、イベント・ベースおよびセッション・ベースのどちらのチャージング・イベントもサポートします。Com.bea.wcp.diameter.accountingパッケージ内のクラスにより、Diameterアカウンティング・メッセージおよびセッションについての全般的なサポートが提供されます。表11-2に、クラスの概要を示します。Diameterアカウンティング・クラスクラス説明ACRアカウンティング・リクエスト・メッセージACAアカウンティング応答メッセージClientSessionクライアント・ベースのアカウンティング・セッションRecordTypeアカウンティング・レコード・タイプ定数さらに、com.bea.wcp.diameter.chargingパッケージ内のクラスにより、特にRfアプリケーションがサポートされます。表11-3に、クラスの概要を示します。Rfアプリケーション・サポート・クラスチャージング3GPPチャージング機能の共通定義RfApplicationオフライン・チャージング・アプリケーションRfSessionオフライン・チャージング・セッションRfApplicationクラスを使用して、イベント・ベース・チャージングのACRリクエストを直接送信できます。アプリケーションには、ACRリクエストの送信前にリクエストを直接修正するオプションがあります。これは、リクエストに任意のカスタムAVPを追加するために必要なオプションです。AVPを設定する必要があります。(WLSS)からCDF(チャージング・サーバー)へ送信するために使用されます。これはグループ化されたAVPで、その値はアプリケーションとそのチャージング機能に応じて異なります。オフライン・チャージングAPIにより、アプリケーションで、リクエストの送信前にこの情報をリクエストに設定することが可能になります。セッション・ベース・アカウンティングでは、RfApplicationクラスは、セッション・ベース・チャージング・イベント生成のための新しいアカウンティング・セッションを作成するためにも使用します。各アカウンティング・セッションは、RfSessionのインスタンスで表され、セッション用のアカウンティング状態のマシンをカプセル化します。Containerでデプロイされたアプリケーションは、Diameterノード(com.bea.wcp.diameter.Nodeクラス)からアプリケーションのインスタンスを取得できます。Nodeを取得してRfアプリケーションにアクセスするため使用するサンプル・サーブレット・コードを示しています。node.getApplication(Charging.RF_APPLICATION_ID);アプリケーションは、RfApplicationの単一インスタンスを安全に使用して、オフライン・チャージング・リクエストを複数のスレッド内で同時に発行できます。RfSessionの各インスタンスは、実際には、各呼出しに対し一意のセッションごとの状態を保持します。セッション・ベース・チャージングの実装セッション・ベース・チャージング・リクエストでは、アプリケーションは、最初にRfApplicationを使用してRfSessionのインスタンスを作成します。その後、セッション・オブジェクトを使用して1つまたは複数のチャージング・リクエストを作成できます。INTERIMリクエストが続きます。STOPリクエストで終了します。STOPメッセージを受信すると、RfApplicationが自動的にRfSessionを終了します。例11-5は、新しいセッション・ベース・アカウンティング・セッションを開始するサンプル・コードです。}例11-5では、呼出しの進捗にともなって追加のアカウンティング・リクエストの送信に使用できるように、RfSessionがSIPアプリケーション・セッション属性として格納されています。例11-6は、INTERIMリクエストをどのように送信するかを示します。INTERIMリクエストを送信しようとする場合があります。AVP値に基づきます。INTERIMを送信する必要があります。32.299を参照してください。(AII)タイマー値が使用されます。STARTがCDFに送られてアカウンティング・セッションが開始するときに指定されます。INTERIMメッセージを送信するタイマーをスタートさせます。このINTERIMメッセージによって、セッションがまだ使用中であることがCDFに伝えられます。この通知がない場合、CDFはセッションを自動的に終了します。INTERIMメッセージでCDFへ送信されるため、アプリケーションはこれらのメッセージを送信する責任があります。AII値に応じて期限切れになるServletTimerを作成することをお薦めします。INTERIMメッセージを送信する必要があります。通常、アプリケーションは同期sendAndWait()メソッドを使用します。待機時間が重要な場合は、非同期APIを使用できます。非同期APIでは、CDFから応答メッセージを受信する際、アプリケーション・サーブレットに対し非同期的に通知が行われます。非同期APIを使用するために、アプリケーションは、まずSessionListenerのインスタンスを登録して、セッションに配信されるメッセージを非同期的に受信するようにします(例11-7を参照)。session.setListener(this);属性は、SIPアプリケーション・セッション属性を格納するのと同じ方法で、RfSessionインスタンスに格納できます。上の例では、リスナー・コールバックに使用できるように、関連SIPアプリケーションはRfSessionとして格納されています。msg)メソッドを呼び出すことでアプリケーション・サーブレットに通知が送られます。例11-8に示されているように、関連SIPアプリケーション・セッションがセッション属性として格納されていれば、RfSessionから取得できます。ACAメッセージの受信時点でセッションは自動で終了します。timeout)メソッドは、EVENTリクエストを同時に送信し、CDFからレスポンスを受信するまでスレッドをブロックするために使用できます。例11-9では、RfSessionを使用してイベント・ベースのチャージング・リクエストを送信する場合の例を示します。}便宜上、例11-10のように、RfApplicationを直接使用してイベント・ベース・チャージング・リクエストを送信することもできます。acr.sendAndWait(1000);RfApplicationは、内部的にACRリクエストに関連するRfSessionのインスタンスを作成します。そのため、このメソッドはセッションの明示的な作成と同等です。AVPの更新を、自動で処理します。上の例では、アプリケーションはCDFからの応答の受信を1000ミリ秒待ちます。その間に応答の受信がない場合は、Diameter中核機能からアプリケーションにUNABLE_TO_COMPLYエラー・レスポンスが配信され、リクエストが取り消されます。sendAndWait()を使ってタイムアウトを指定しない場合は、デフォルトのリクエスト・タイムアウト値である30秒が適用されます。このデフォルト値は、Diameterコンソール拡張を使用して構成できます。アカウンティング・セッション状態の使用オフライン・チャージングのアカウンティング・セッション状態はシリアライズ可能なので、SIPアプリケーション・セッション属性として格納できます。クライアントAPIは同期的であるため、いったんサーブレットが呼出し処理を終了したら、アカウンティング・セッションの状態を保持する必要はまったくありません。イベント・ベースのチャージング・イベントでは、アカウンティング・セッション状態は内部的にのみ使用されるため、アプリケーションが保持する必要はありません。そのため、いったんACAレスポンスが受信された後は、アカウンティング・セッション状態は破棄されます。reserved.法律上の。