| Oracle® WebLogic Communication Services 開発者ガイド 11g リリース 1 (11.1.1) B55506-01 |
|
 戻る |
 次へ |
この章では、アプリケーション開発時にOWLCS の Diameter プロトコル実装に基づいて Diameter Rf インタフェース API を使用する方法について説明します。以下の節で構成されています。
オフライン チャージングは、定期的に支払いを行うネットワーク サービスに使用します。たとえば、ユーザが、毎月支払いを行う必要がある音声コール サブスクリプションを利用するといった場合などです。Rf プロトコルを使用することで、IMS チャージング トリガ機能 (CTF) からオフライン イベントをチャージング データ機能 (CDF) へ発行することが可能になります。チャージング イベントは、1 回限りの (ワンタイム) イベントとすることも、セッション ベースとすることもできます。
OWLCS は Diameter オフライン チャージング アプリケーションを提供します。デプロイ済みのアプリケーションは、このアプリケーションを利用して Rf プロトコルに基づくチャージング イベントを生成します。オフライン チャージング アプリケーションは Diameter 基本プロトコル実装を使用し、OWLCS にデプロイ済みのアプリケーションがコンフィグレート済みの CDF に対し CTF として機能することを可能にします。
オフライン チャージングについての基本的な情報は、RFC 3588 : Diameter 基本プロトコル (http://www.ietf.org/rfc/rfc3588.txt) を参照してください。Rf プロトコルの詳細については、3GPP TS 32.299 (http://www.3gpp.org/ftp/Specs/html-info/32299.htm) を参照してください。
イベントとセッションに基づく両方のチャージングに関しては、CTF は RFC 3588 で説明されるアカウンティング状態のマシンを実行します。サーバ (CDF) は RFC 3588 で指定されたようにアカウンティング状態のマシン「SERVER、STATELESS ACCOUNTING」を実行します。
CDF へのオフライン チャージング イベントのレポーティングは、Diameter アカウンティング リクエスト (ACR) メッセージを通じて管理されます。Rf は、表 14-1 に記載されている ACR イベント タイプをサポートします。
表 14-1 Rf ACR イベント タイプ
| リクエスト | 説明 |
|---|---|
|
START |
アカウンティング セッションの開始 |
|
INTERIM |
アカウンティング セッションの更新 |
|
STOP |
アカウンティング セッションの終了 |
|
EVENT |
一回限りの (ワンタイム) アカウンティング イベント |
START、INTERIM および STOP イベント タイプは、セッション ベース アカウンティングに対し使用します。EVENT タイプは、イベント ベース アカウンティングに対し使用するか、またはセッションの確立が失敗したことを示すために使用します。
セッション ベース チャージングは、ACR START、INTERIM および STOP リクエストを使用して、CDF の使用を報告します。セッション中、セッション ライフサイクルによっては CTF が複数の ACR INTERIM リクエストを報告する可能性があります。例 14-2 は、基本的なメッセージ フローです。
例 14-2 セッション ベース チャージングのメッセージ フロー
CTF (WLSS) CDF (Server) | | | --- ACR (START) ----> | | | | (Open CDR) | | | <-- ACA (START) ----- | | | ... ... | --- ACR (INTERIM) --> | | | | (Update CDR) | | | <-- ACA (INTERIM) --- | ... ... | --- ACR (STOP) -----> | | | | (Close CDR) | | | <-- ACA (STOP) ------ | | |
ここで ACA START は、OWLCS によるサービス リクエストの受信時に送信されます。ACA INTERIM は、通常、AII タイマーの時間切れ時点で送信されます。ACA STOP は、OWLCS によるサービス終了のリクエスト時に発行されます。
Rf API は、プロファイル データを管理するための Sh アプリケーションと似たような Diameter アプリケーションとしてパッケージされています。Rf Diameter API は、DOMAIN_ROOT/config/custom/diameter.xml に格納されている Diameter コンフィグレーション ファイルを編集するか、Diameter コンソール拡張を使用して、コンフィグレーションおよび有効化することができます。また、CDF レルムおよびホストのコンフィグレーションはいずれも、Diameter Rf アプリケーションへの cdf.realm および cdf.host 初期化パラメータを使用して指定できます。
例 14-3 は、CDF レルム「oracle.com」およびホスト「cdf.oracle.com:」で Rf を有効化する diameter.xml から抜粋したサンプルです。
例 14-3 サンプル Rf アプリケーションの コンフィグレーション (diameter.xml)
<application> <application-id>3</application-id> <accounting>true</accounting> <class-name>com.bea.wcp.diameter.charging.RfApplication</class-name> <param> <name>cdf.realm</name> <value>oracle.com</value> </param> <param> <name>cdf.host</name> <value>cdf.oracle.com</value> </param> </application>
RfApplication は Diameter 基本アカウンティング メッセージを使用するため、Diameter アプリケーション ID は「3」で、ベンダ ID はありません。
OWLCS は、オフライン チャージング API を提供します。この API により、デプロイ済みの任意のアプリケーションが CTF として機能し、オフライン チャージング イベントを発行することが可能になります。この API は、イベント ベースおよびセッション ベースのどちらのチャージング イベントもサポートします。
Com.bea.wcp.diameter.accounting パッケージ内のクラスにより、Diameter アカウンティング メッセージおよびセッションについての全般的なサポートが提供されます。表 14-2 はクラスの概略を説明します。
表 14-2 Diameter アカウンティング クラス
| クラス | 説明 |
|---|---|
|
ACR |
アカウンティング リクエスト メッセージ |
|
ACA |
アカウンティング応答メッセージ |
|
ClientSession |
クライアント ベースのアカウンティング セッション |
|
RecordType |
アカウンティング レコード タイプ定数。 |
さらに、com.bea.wcp.diameter.charging パッケージ内のクラスにより、特に Rf アプリケーションがサポートされます。表 14-3 はクラスの概略を説明します。
表 14-3 Diameter Rf アプリケーション サポート クラス
| チャージング | 3GPP チャージング機能の共通定義 |
|---|---|
|
RfApplication |
オフライン チャージング アプリケーション |
|
RfSession |
オフライン チャージング セッション |
RfApplication クラスを使用して、イベント ベース チャージングの ACR リクエストを直接送信することができます。アプリケーションには、ACR リクエストの送信前にリクエストを直接修正するオプションがあります。これは、リクエストに任意のカスタム AVP を追加するために必要なオプションです。
具体的に言うと、アプリケーションでは、CDF のためのサービス固有パラメータを運ぶ Service-Information AVP を設定する必要があります。ACR リクエストの Service-Information AVP は、アプリケーション固有のチャージング サービスを CTF (WLSS) から CDF (チャージング サーバ) へ送信するために使用されます。これはグループ化された AVP で、その値はアプリケーションとそのチャージング機能に応じて異なります。オフライン チャージング API により、アプリケーションで、リクエストの送信前にこの情報をリクエストに設定することが可能になります。
セッション ベース アカウンティングでは、RfApplication クラスは、セッション ベース チャージング イベント生成のための新しいアカウンティング セッションを作成するためにも使用します。各アカウンティング セッションは、RfSession のインスタンスで表され、セッション用のアカウンティング ステート マシンをカプセル化します。
Rf アプリケーションがデプロイされると、OWLCS でデプロイされたアプリケーションは Diameter ノード (com.bea.wcp.diameter.Node クラス) からアプリケーションのインスタンスを取得することができます。例 14-4 は Diameter Node を取得して Rf アプリケーションにアクセスするため使用するサンプル サーブレット コードを示します。
例 14-4 Rf アプリケーションへのアクセス
ServletContext sc = getServletConfig().getServletContext();
Node node = sc.getAttribute("com.bea.wcp.diameter.Node");
RfApplication rfApp = (RfApplication) node.getApplication(Charging.RF_APPLICATION_ID);
アプリケーションは、RfApplication の単一インスタンスを安全に使用して、オフライン チャージング リクエストを複数のスレッド内で同時に発行できます。RfSession の各インスタンスは、実際には、各呼に対し一意のセッションごとのステートを保持します。
セッション ベース チャージング リクエストでは、アプリケーションは、まず RfApplication を使用して RfSession のインスタンスを作成します。その後、セッション オブジェクトを使用して 1 つまたは複数のチャージング リクエストを作成することができます。
最初のチャージング リクエストは ACR START リクエストである必要があり、その後、ゼロまたは 1 つ以上の ACR INTERIM リクエストが続きます。セッションは ACR STOP リクエストで終了します。対応する ACA STOP メッセージを受信すると、RfApplication が自動で RfSession を終了します。
例 14-5 は、新しいセッション ベース アカウンティング セッションを開始するサンプル コードです。
例 14-5 セッション ベース アカウンティング セッションの開始
RfSession session = rfApp.createSession();
sipRequest.getApplicationSession().setAttribute("RfSession", session);
ACR acr = session.createACR(RecordType.START);
acr.addAvp(Charging.SERVICE_INFORMATION, ...);
ACA aca = acr.sendAndWait(1000);
if (!aca.getResultCode().isSuccess()) {
... error ...
}
例 14-5 では、呼の進捗にともなって追加のアカウンティング リクエストの送信に使用できるように、RfSession が SIP アプリケーション セッション属性として格納されています。例 14-6 は、INTERIM リクエストをどのように送信するかを示します。
例 14-6 INTERIM リクエストの送信
RfSession session = (RfSession) req.getApplicationSession().getAttribute("RfSession");
ACR acr = session.createACR(RecordType.INTERIM);
ACA aca = acr.sendAndWait(1000);
if (!aca.getResultCode().isSuccess()) {
... error ...
}
呼の進行中、アプリケーションが 1 つまたは複数の ACR INTERIM リクエストを送信する必要がある場合があります。ACR INTERIM リクエストの間隔は、通常、CDF により送信された ACA START メッセージ内の Acct-Interim-Interval AVP 値に基づきます。このため、アプリケーション タイマーによって、要求されている間隔で ACR INTERIM を送信する必要があります。INTERIM リクエストの詳細については、3GPP TS 32.299 を参照してください。
Rf アカウンティング セッションの有効期限を示すために、Acct-Interim-Interval (AII) タイマー値が使用されます。この値は、ACR START が CDF に送られてアカウンティング セッションが開始するときに指定されます。CDF は独自の AII 値を返し、CTF はその値を使って、期限切れ時点で ACR INTERIM メッセージを送信するタイマーをスタートさせます。この INTERIM メッセージによって、セッションがまだ使用中であることが CDF に伝えられます。この伝達がない場合、CDF はセッションを自動的に終了します。
更新済みのサービス情報データは ACR INTERIM メッセージで CDF へ送信されるため、アプリケーションはこれらのメッセージを送信する責任があります。Oracle では、AII 値に応じて期限切れになる ServletTimer を作成することをお勧めします。このタイマーが期限切れになった時点で、アプリケーションが ACR INTERIM メッセージを更新済みのサービス情報データとともに送信するようにする必要があります。
通常、アプリケーションは、同期 sendAndWait() メソッドを使用します。ただし、レイテンシが重要な場合は、非同期 API を使用できます。非同期 API では、CDFから応答メッセージを受信する際、アプリケーション サーブレットに対し非同期的に通知が行われます。非同期 API を使用するために、アプリケーションは、まず SessionListener のインスタンスを登録して、セッションに配信されるメッセージを非同期的に受信するようにします。例 14-7 を参照してください。
例 14-7 SessionListener の登録
RfSession session = rfApp.createSession();
session.setAttribute("SAS", sipReq.getApplicationSession());
session.setListener(this);
属性は、SIP アプリケーション セッション属性を格納するのと同じ方法で、RfSession インスタンスに格納できます。上の例では、リスナ コールバックに使用できるように、関連 SIP アプリケーションは RfSession として格納されています。
CDF から Diameter リクエストまたは応答メッセージを受信すると、rcvMessage(Message msg) メソッドを呼び出すことでアプリケーション サーブレットに通知が送られます。例 14-8 に示されているように、関連 SIP アプリケーション セッションをセッション属性として格納しておくと、それを RfSession から取得することが可能になります。
例 14-8 通知後の RfSession の取得
public void rcvMessage(Message msg) {
if (msg.getCommand() != Command.ACA) {
if (msg.isRequest()) {
((Request) msg).createAnswer(ResultCode.UNABLE_TO_COMPLY, "Unexpected request").send();
}
return;
}
ACA aca = (ACA) msg;
RfSession session = (RfSession) aca.getSession();
SipApplicationSession appSession = (SipApplicationSession) session.getAttribute("SAS");
...
}
イベント ベース チャージングの場合、チャージング リクエストは一回限りのイベントであり、対応する EVENT ACA メッセージの受信時点でセッションは自動で終了します。sendAndWait(long timeout) メソッドはEVENT リクエストを同時に送信し、CDF から応答を受信するまでスレッドをブロックするために使用することができます。例 14-9 は RfSession を使用してイベント ベースのチャージング リクエストを送信する場合の例を示します。
例 14-9 RfSession を使用したイベント ベース チャージング
RfSession session = rfApp.createSession();
ACR acr = session.createACR(RecordType.EVENT);
acr.addAvp(Charging.SERVICE_INFORMATION, ...);
ACA aca = acr.sendAndWait(1000);
if (!aca.getResultCode().isSuccess()) {
... send error response ...
}
便宜上、例 14-10 のように、RfApplication を直接使用してイベント ベース チャージング リクエストを送信することもできます。
例 14-10 RfApplication を使用したイベント ベース チャージング
ACR acr = rfApp.createEventACR(); acr.addAvp(Charging.SERVICE_INFORMATION, ...); ACA aca = acr.sendAndWait(1000);
RfApplication は、内部的に ACR リクエストに関連する RfSession のインスタンスを作成します。そのためこのメソッドは、セッションの明示的な作成と同等です。
セッション ベースおよびイベントベース、どちらのアカウンティングの場合でも、RfSession クラスは、セッション ID の作成、および同一のアカウンティング セッション内でのメッセージの並べ替えに使用される Accounting-Record-Number AVP の更新を、自動で処理します。
上の例では、アプリケーションは CDF からの応答の受信を 1000 ミリ秒、待ちます。その間に応答の受信がない場合は、Diameter 中核機能からアプリケーションに UNABLE_TO_COMPLY エラー応答が配信され、リクエストがキャンセルされます。sendAndWait() を使ってタイムアウトを指定しない場合は、デフォルトのリクエスト タイムアウト値である 30 秒が適用されます。このデフォルト値は、Diameter コンソール拡張を使用してコンフィグレーションすることができます。
オフライン チャージングのアカウンティング セッション ステートはシリアライズ可能なので、SIP アプリケーション セッション属性として格納できます。クライアント API は同期的であるため、いったんサーブレットが呼の処理を終了したら、アカウンティング セッションのステートを保持する必要はまったくありません。
イベント ベース チャージング イベントでは、アカウンティング セッション ステートは内部的にのみ使用されるため、アプリケーションによって保持される必要はありません。そのため、いったん ACA 応答が受信された後は、アカウンティング セッション ステートは破棄されます。
