| Oracle® WebLogic Server SIP Container開発者ガイド 11g リリース1(11.1.1) B61430-01 |
|
 前 |
 次 |
この章では、アプリケーションで、Oracle WebLogic ServerのDiameterプロトコル実装に基づいてDiameter RoインタフェースAPIを使用する方法について説明します。内容は次のとおりです。
クレジット・ベース・チャージングとしても知られているオンライン・チャージングは、プリペイド・サービスの請求に使用されます。典型的なプリペイド・サービスの例としては、音声またはビデオのために購入するテレホン・カードがあります。Roプロトコルを使用することで、チャージング・トリガー機能(CTF)からオンライン・チャージング機能(OCF)へチャージング・イベントを発行することが可能になります。チャージング・イベントは、即時、イベント・ベース、セッション・ベースのいずれかにすることができます。
Oracle WebLogic Server SIP ContainerはDiameterオンライン・チャージング・アプリケーションを提供します。デプロイ済のアプリケーションは、このアプリケーションを利用してRoプロトコルに基づくチャージング・イベントを生成します。これにより、デプロイ済のアプリケーションが、構成されたOCFに対しCTFとして機能することが可能になります。Diameterオンライン・チャージング・アプリケーションは、RfとShの両方のアプリケーションをサポートする基本Diameterプロトコルを使用します。
Diameterオンライン・チャージング・アプリケーションは、IETF RFC 4006: Diameter Credit Control Application(http://www.ietf.org/rfc/rfc4006.txt)に基づいています。ただし、アプリケーションがサポートするのは、3GPP TS 32.299: Telecommunication management; Charging management; Diameter charging applications(http://www.3gpp.org/ftp/Specs/html-info/32299.htm)との整合性のために必要なRFC 4006のサブセットのみです。具体的には、Oracle WebLogic Server SIP ContainerのDiameterオンライン・チャージング・アプリケーションはサービス固有の属性値ペア(AVP)を直接サポートすることはありませんが、提供されるAPIが十分にフレキシブルなものであり、そのためにクレジット管理リクエストにカスタム・サービス固有のAVPを含めることができます。
RFC 4006は、次のような2つの基本的なタイプのクレジット認証モデルを定義します。
ユニット予約方式でのクレジット認証
口座引き落とし方式でのクレジット認証
ユニット予約方式でのクレジット認証では、イベント・ベースまたはセッション・ベースのいずれのチャージング・イベントでも実行することができます。口座引き落とし方式でのクレジット認証では、即時チャージング・イベントを使用します。どちらのモデルでも、CTFはエンド・ユーザーにサービスを配信する前にOCFからのクレジット認証をリクエストします。
以下の項では、各モデルについて詳しく説明します。
RFC 4006は、ユニット予約方式でのイベント・チャージング(ECUR)およびユニット予約方式でのセッション・チャージング(SCUR)を定義します。これらのチャージング・イベントは、どちらもセッション・ベースであり、CTFとOCF間における複数のトランザクションを必要とします。ECURでは、サービスを配信する前にまずユニット数を予約するための問い合わせを行い、その後、サービスの終了時点で実際に使用されたユニット数をOCFへ報告するための問い合わせを実行します。SCURの場合には、CTFが1つまたは複数の中間問い合わせを行って実際にその時点で使用されているユニット数を報告し、必要に応じて追加のユニット数を予約することもできます。いずれの場合も、セッション状態はCTFおよびOCFの両方に保持されます。
ECURとSCURのどちらの場合も、オンライン・チャージング・クライアントはRFC 4006に記載されているCLIENT、SESSION BASEDステート・マシンを実装します。
RoApplicationは、プロファイル・データを管理するためのShアプリケーションと似たDiameterアプリケーションとしてパッケージされています。Ro Diameterアプリケーションは、DOMAIN_ROOT/config/custom/diameter.xmlに格納されているDiameter構成ファイルを編集するか、Diameterコンソール拡張を使用して、構成および有効化できます。
アプリケーションのinitパラメータであるocs.hostが、OCFのホストIDを指定します。この場合、OCFホストは、グローバルDiameter構成の一部としてピア表内に構成されている必要があります。もう1つの方法として、initパラメータocs.realmを使用して、レルム・ベース・ルーティングを使用する1つまたは複数のOCFホストを指定することもできます。この場合、対応するレルム定義がグローバルDiameter構成内にも指定されている必要があります。
例12-1は、Roを「myocs.oracle.com」というOCFホスト名で有効化するdiameter.xmlから抜粋したサンプルです。
例12-1 サンプルRoアプリケーションの構成(diameter.xml)
<application>
<application-id>4</application-id>
<class-name>com.bea.wcp.diameter.charging.RoApplication</class-name>
<param>
<name>ocs.host</name>
<value>myocs.oracle.com</value>
</param>
</application>
RoApplicationはDiameterクレジット管理アプリケーションに基づいているため、DiameterアプリケーションIDは4になります。
Oracle WebLogic Server SIP Containerは、オンライン・チャージングAPIを提供します。このAPIにより、デプロイ済の任意のアプリケーションがCTFとして機能し、Roプロトコルを介してOCSに対しオンライン・チャージング・イベントを発行することが可能になります。すべてのオンライン・チャージング・リクエストは、Diameterクレジット管理リクエスト(CCR)メッセージを使用します。使用されたチャージングのタイプは、CC-Request-Type AVPで示されます。チャージングAPIにおいて、CC-Request-Typeはcom.bea.wcp.diameter.ccパッケージで、RequestTypeクラスによって表されます。表12-1は異なるクレジット認可モデルに関連付けられたリクエスト・タイプを示します。
表12-1 クレジット管理リクエストのタイプ
|
タイプ |
説明 |
com.bea.wcp.diameter.cc.RequestType内のRequestTypeフィールド |
|
IEC |
即時イベント・チャージング |
|
|
ECUR |
ユニット予約方式でのイベント・チャージング |
|
|
SCUR |
ユニット予約方式でのセッション・チャージング |
|
ECURおよびSCURでは、サービスの配信前にユニットを予約し、サービスの完了時点でコミットします。ユニットの予約はINITIAL_REQUESTで行われ、TERMINATION_REQUESTでコミットされます。SCURの場合には、UPDATE_REQUESTでユニットを更新することもできます。
基本Diameterパッケージcom.bea.wcp.diameterには、Roで使用される再認証リクエストをサポートするクラスが含まれています。com.bea.wcp.diameter.ccパッケージにはRoアプリケーションなど、クレジット・コントロール・アプリケーションをサポートするクラスが含まれています。com.bea.wcp.diameter.chargingはRoクレジット・アプリケーションを直接サポートします。表12-2は、Roクレジット・コントロールのクラスの概略を表しています。
表12-2 Roクラスの概略
|
クラス |
説明 |
パッケージ |
|
|
定数定義 |
|
|
|
オンライン・チャージング・アプリケーション |
|
|
|
オンライン・チャージング・セッション |
|
|
|
クレジット管理リクエスト |
|
|
|
クレジット管理応答 |
|
|
ClientSession |
クレジット管理クライアント・セッション |
|
|
RequestType |
クレジット管理リクエスト・タイプ |
|
|
RAR |
再認証リクエスト・メッセージ |
|
|
RAA |
再認証応答メッセージ |
|
Roアプリケーションがデプロイされると、Oracle WebLogic Server SIP Containerでデプロイされたアプリケーションは、Diameterノード(com.bea.wcp.diameter.Nodeクラス)からアプリケーションのインスタンスを取得できます。例12-2は、Diameter Nodeの取得、およびRoアプリケーションへのアクセスに使用するサンプル・サーブレット・コードを示しています。
例12-2 Roアプリケーションへのアクセス
private RoApplication roApp;
void init(ServletConfig conf) {
ServletContext ctx = conf.getServletContext();
Node node = (Node) ctx.getParameter("com.bea.wcp.diameter.Node");
roApp = node.getApplication(Charging.RO_APPLICATION_ID);
}
このコード例では、RoApplicationをインスタンス変数としてサーブレットで使用できるようにします。RoApplicationのインスタンスは、複数の同時スレッドで使用する場合に安全です。
RoApplicationを使用して、セッション・ベース・クレジット認証のための新しいセッションを作成できます。RoSessionクラスは、クレジット管理タイプがECUR(ユニット予約方式でのイベント・ベース・チャージング)かSCUR(ユニット予約方式でのセッション・ベース・チャージング)のいずれかに応じて、適切なステート・マシンを実装します。また、RoSessionクラスはシリアライズ可能なため、SIPセッション属性として格納できます。このため、セッションを終了したり、クレジット認証を更新する必要がある場合に、セッションを復元できます。
表12-3の例では、イベント・ベース・チャージングの新しいRoSessionを作成し、CCRリクエストを送信して最初の問合せを開始します。サービスの終了後、後で終了できるようにRoSessionインスタンスを保存します。
RoSessionクラスはセッションIDの作成を自動で処理することに注意してください。アプリケーションでセッションIDを設定する必要はありません。
例12-3 RoSessionの作成と使用
RoSession session = roApp.createSession();
CCR ccr = session.createCCR(RequestType.INITIAL);
CCA cca = ccr.sendAndWait();
sipAppSession.setAttribute("RoSession", session);
...
OCSが再認証リクエスト(RAR)をCTFに発行して、クレジット再認証を開始させることがあります。このタイプのリクエストを処理するために、アプリケーションはセッション・リスナーを登録できます。RARを受信すると、DiameterサブシステムはRoSessionオブジェクトに対応するアプリケーション上のセッション・リスナーを呼び出します。RFC 4006(http://www.ietf.org/rfc/rfc4006.txt)の5.5項に記載されているように、アプリケーションは適切なRAAメッセージでOCSに応答し、値UPDATE_REQUESTを設定したCC-Request-Type AVPとともにCCRを送信してCTFに対するクレジット再認証を開始させる必要があります。
セッション・リスナーは、SessionListenerインタフェースを実装し、シリアライズ可能である必要があります。または、SipServletのインスタンスである必要があります。サーブレットは次のようにリスナーを登録できます。
RoSession session = roApp.createSession();
session.addListener(new SessionListener() {
public void rcvMessage(Message msg) {
System.out.println("Got message: id = " msg.getSession().getId());
}
});
例12-4は、再認証リクエストを処理するrcvMessage()コードのサンプルを示しています。
例12-4 再認証リクエストの管理
RoSession session = roApp.createSession();
session.addListener(new SessionListener() {
public void rcvMessage(Message msg) {
Request req = (Request)msg;
if (req.getCommand() != Command.RE_AUTH_REQUEST) return;
RoSession session = (RoSession) req.getSession();
Answer ans = req.createAnswer();
ans.setResultCode(ResultCode.LIMITED_SUCCESS); // Per RFC 4006 5.5
ans.send();
CCR ccr = session.createCCR(Ro.UPDATE_REQUEST);
... // Set CCR AVPs according to requested credit re-authorization
ccr.send();
CCA cca = (CCA) ccr.waitForAnswer();
}
例12-4では、再認証リクエストを受信すると、アプリケーションは結果コードDIAMETER_LIMITED_SUCCESSとともにRAAを送信し、OCSに対して処理の完了のために追加のCCRリクエストが必要であることを知らせます。その後CCRが送信され、クレジット再認証が開始されます。
|
注意: Diameterサブシステムは対応するRoSessionにリクエストを配信する前に呼出し状態をロックするため、リクエストがハンドラによって処理されている間、呼出し状態はロックされたままになります。 |
CCRクラスはDiameterクレジット管理リクエスト・メッセージを表し、クレジット管理リクエストをOCFに送信するために使用できます。ECUR(ユニット予約方式でのイベント・ベース・チャージング)とSCUR(ユニット予約方式でのセッション・ベース・チャージング)のどちらの場合でも、新しいCCRリクエストの作成にはRoSessionのインスタンスを使用します。RoApplicationを直接使用してIECにCCRメッセージを作成することもできます。例12-5は、CCRの作成と送信の方法を示しています。
例12-5 CCRの作成と送信
CCR ccr = session.createCCR(RequestType.INITIAL);
ccr.setServiceContextId("sample_id");
CCA cca = ccr.sendAndWait();
CCRリクエストを作成した後は、どのようなアプリケーション固有またはサービス固有のAVPでも設定できます。これらのAVPは、addAvp()メソッドを使用してリクエストを送信する前に必要になります。セッションの各新規リクエストに同じAVPをいくつか含める必要があるため、これらのAVPをセッション自体に設定することもできます。例12-6は、次の項目を設定するサンプルを示しています。
Subscription-Idはセッションのユーザーを特定します。
Service-Identifierはリクエスト対象のサービスを示します。
Requested-Service-Unitはリクエスト対象のユニットを指定します。
また、カスタムAVPをCCRリクエストに直接追加します。
例12-6 CCRでのAVPの設定
session.setSubscriptionId(...); session.setServiceIdentifier(...); CCR ccr = session.createCCR(RequestType.INITIAL); ccr.setRequestedServiceUnit(...); ccr.addAvp(CUSTOM_MESSAGE, "This is a test"); ccr.send();
この例では、セッションの各新規リクエストに、同じSubscription-IdとService-Identifierを追加しています。また、送信前に、メッセージに対しカスタムAVP Custom-Messageを追加しています。
アプリケーションでは、OCFから送られるCCAエラー・レスポンス内のResult-Code AVPを調べることで障害の原因を検出し、適切な対処を行うことができます。使用不可のピアや無効なルート指定といったローカルで発生したエラーの場合は、リクエスト送信のメソッドが呼び出され、障害の内容を示す詳細メッセージとともにIOExceptionがスローされます。
また、アプリケーションでは、DiameterタイマーTx値を使用して、どの時点でOCFがクレジット認証リクエストへの応答に失敗したかを突き止めることができます。タイマーTxのデフォルト値は10秒ですが、RoApplication構成内のtx.timerパラメータを使用してオーバーライドできます。タイマーTxは、CCRがOCFに送信られた時点でスタートします。また、対応するCCAの受信後にタイマーはリセットされます。
対応するCCAの受信前にTxが期限切れになった場合は、waitForAnswerへの呼出しが直ちにnullを返し、リクエストがタイムアウトしたことを示します。そのため、アプリケーションは、リクエストのCredit-Control-Failure-Handling (CCFH) AVPの値に従って適切なアクションを取ることができます。詳細は、RFC 4006(http://www.ietf.org/rfc/rfc4006.txt)の5.7項「Failure Procedures」を参照してください。
例12-7では、CCAの受信前にタイマーTxが期限切れになった場合、クレジット管理セッションは終了します。その後にDiameterサブシステムがCCAを受信すると、セッションはもう存在しないためメッセージは無視されます。
