WebLogic Server SIP Container 開発者ガイド

11g リリース1 (11.1.1)

B61430-01(原本部品番号:E15461-01)

目次

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティ

- 関連ドキュメント

- 表記規則

第I部 概要

1 SIPサーブレット・アプリケーション開発の概要

- 1.1 SIPサーブレットとは

- 1.2 SIPサーブレットとHTTPサーブレットの比較

- 1.2.1 複数のレスポンス

- 1.2.2 レスポンスの受信

- 1.2.3 プロキシ機能

- 1.2.4 メッセージ本文

- 1.2.4.1 サーブレットのリクエスト

- 1.2.4.2 サーブレットのレスポンス

- 1.2.4.3 SipServletMessage

- 1.2.5 サーブレット・コンテナの役割

- 1.2.5.1 アプリケーション管理

- 1.2.5.2 SIPメッセージング

- 1.2.5.3 ユーティリティ機能

第II部 SIPアプリケーションの開発とプログラミング

2 コンバージド・アプリケーションの開発

- 2.1 コンバージド・アプリケーションの概要

- 2.2 コンバージド・アプリケーションのアセンブルとパッケージ化

- 2.3 SIPセッションとHTTPセッションの設定

- 2.3.1 SipApplicationSessionの変更

- 2.3.1.1 同期アクセス

- 2.3.1.2 非同期アクセス

- 2.4 コンバージド・アプリケーションのサンプルの使用

3 SIPプロトコルのプログラミング

- 3.1 SIPメッセージの圧縮および長いヘッダー・フォーマットの使用

- 3.1.1 ヘッダー・フォーマットAPIと構成の概要

- 3.1.2 圧縮ヘッダーの概要

- 3.1.3 WlssSipServletMessageでのヘッダー・フォーマットの割当て

- 3.1.4 APIおよび構成の動作の概要

- 3.2 SIPサーブレットにおけるコンテンツの間接化の使用

- 3.2.1 コンテンツの間接化の概要

- 3.2.2 コンテンツ間接化APIの使用

- 3.2.3 追加情報

- 3.3 アプリケーション・コードからのSNMPトラップ生成

- 3.3.1 概要

- 3.3.2 SipServletSnmpTrapRuntimeMBeanへのアクセスの要件

- 3.3.3 SipServletSnmpTrapRuntimeMBeanへの参照の取得

- 3.3.4 SNMPトラップの生成

4 SIPアプリケーションの要件とベスト・プラクティス

- 4.1 分散型アプリケーションの開発の概要

- 4.2 アプリケーションではスレッドを作成しない

- 4.3 サーブレットは非ブロッキングでなければならない

- 4.4 すべてのアプリケーション・データをセッションに格納する

- 4.5 すべてのセッション・データがシリアライズ可能でなければならない

- 4.6 setAttribute()を使用して「No-Call」Scopeのセッション・データを変更する

- 4.7 send()呼出しがバッファされる

- 4.8 SIPサーブレットを配布可能としてマークする

- 4.9 SipApplicationSessionActivationListenerを慎重に使用する

- 4.10 セッションの有効期限のベスト・プラクティス

- 4.11 Java EEアプリケーションのベスト・プラクティスに従う

5 SIPアプリケーションの構成

- 5.1 アプリケーション構成モデル

- 5.2 デフォルト・アプリケーション・ルーターの使用

- 5.3 カスタム・アプリケーション・ルーターの構成

- 5.4 セッション・キーに基づくリクエストのターゲット

6 SIPサーブレット・リソースのセキュリティ

- 6.1 SIPサーブレット・セキュリティの概要

- 6.2 SIPレスポンス・コードのトリガー

- 6.3 セキュリティ・レルムの指定

- 6.4 ロール・マッピング機能

- 6.5 暗黙的なロール割当ての使用

- 6.6 security-role-assignmentを使用したロールの割当て

- 6.6.1 重要な要件

- 6.6.2 デプロイメント時のロールの割当て

- 6.6.3 管理コンソールを使用した動的なロールの割当て

- 6.7 run-asロールの割当て

- 6.8 SIPサーブレット・ロールのロール割当て優先順位

- 6.9 セキュリティ機能のデバッグ

- 6.10 weblogic.xmlデプロイメント記述子リファレンス

7 メッセージ・ロギングの有効化

- 7.1 概要

- 7.2 メッセージ・ロギングの有効化

- 7.2.1 あらかじめ定義されているロギング・レベルの指定

- 7.2.2 ログ・レコードのカスタマイズ

- 7.3 暗号化されていないロギングのコンテンツ・タイプの指定

- 7.4 メッセージ・ログ構成と出力の例

- 7.5 ログ・ファイル・ローテーションの構成

第III部 Diameterの使用

8 Diameter基本プロトコルAPIの使用

- 8.1 Diameterプロトコル・パッケージ

- 8.2 Diameter APIの概要

- 8.2.1 Diameter APIを使用してアプリケーションをコンパイルするのに必要なファイル

- 8.3 Diameterノードの設定

- 8.4 Diameterアプリケーションの実装

- 8.5 Diameterセッションの設定

- 8.6 Diameterメッセージの設定

- 8.6.1 リクエスト・メッセージの送信

- 8.6.2 応答メッセージの送信

- 8.6.3 新しいコマンド・コードの作成

- 8.7 AVPの設定

- 8.7.1 新しい属性の作成

- 8.8 コンバージドDiameterとSIPアプリケーションの作成

9 プロファイル・サービスAPIの使用

- 9.1 プロファイル・サービスAPIおよびShインタフェースのサポートの概要

- 9.2 Shインタフェース・プロバイダの有効化

- 9.3 プロファイル・サービスAPIの概要

- 9.4 アプリケーション管理下のプロファイル・データに関するドキュメント・セレクタ・キーの作成

- 9.5 作成されたドキュメント・キーによるプロファイル・データ管理

- 9.6 ProfileListenerによるプロファイル・データのモニター

- 9.6.1 リスナー実装の前提条件

- 9.6.2 ProfileListenerの実装

10 カスタム・プロファイル・サービス・プロバイダの開発

- 10.1 プロファイル・サービスAPIの概要

- 10.2 プロファイル・サービスAPIメソッドの実装

- 10.3 プロファイル・プロバイダの構成とパッケージ化

- 10.3.1 プロファイル・プロバイダへのプロファイル・リクエストのマッピング

- 10.4 管理コンソールを使用したプロファイル・プロバイダの構成

11 オフライン・チャージング用のDiameter RfインタフェースAPIの使用

- 11.1 Rfインタフェースのサポートの概要

- 11.2 オフライン・チャージング・イベントについて

- 11.2.1 イベント・ベース・チャージング

- 11.2.2 セッション・ベース・チャージング

- 11.3 Rfアプリケーションの構成

- 11.4 オフライン・チャージングAPIの使用

- 11.4.1 Rfアプリケーションへのアクセス

- 11.4.2 セッション・ベース・チャージングの実装

- 11.4.2.1 セッション有効期限の指定

- 11.4.2.2 非同期イベントの送信

- 11.4.3 イベント・ベース・チャージングの実装

- 11.4.4 アカウンティング・セッション状態の使用

12 オンライン・チャージング用のDiameter RoインタフェースAPIの使用

- 12.1 Roインタフェースのサポートの概要

- 12.2 クレジット認証モデルについて

- 12.2.1 ユニット決定方式でのクレジット認証

- 12.2.2 口座引き落とし方式でのクレジット認証

- 12.2.3 ユニットの決定とレーティング

- 12.3 Roアプリケーションの構成

- 12.4 オンライン・チャージングAPIの概要

- 12.5 Roアプリケーションへのアクセス

- 12.6 セッション・ベース・チャージングの実装

- 12.6.1 再認証リクエスト・メッセージの処理

- 12.7 クレジット管理リクエスト・メッセージの送信

- 12.8 障害の処理

第IV部 リファレンス

A プロファイル・サービス・プロバイダ構成リファレンス(profile.xml)

- A.1 profile.xmlの概要

- A.2 グラフィカルな表示

- A.3 profile.xmlの編集

- A.3.1 profile.xmlの編集の手順

- A.4 XMLスキーマ

- A.5 profile.xmlファイルのサンプル

- A.6 XML要素の説明

- A.6.1 profile-service

- A.6.2 mapping

- A.6.2.1 map-by

- A.6.2.2 map-by-prefix

- A.6.2.3 map-by-router

- A.6.3 provider

- A.6.3.1 name

- A.6.3.2 provider-class

- A.6.3.3 param

B Eclipseを使ったSIPサーブレットの開発

- B.1 概要

- B.1.1 SIPサーブレットの編成

- B.2 開発環境の設定

- B.2.1 Oracle WebLogic Server SIP Containerドメインの作成

- B.2.2 デフォルトのEclipse JVMの確認

- B.2.3 新しいEclipseプロジェクトの作成

- B.3 プロジェクトのビルドとデプロイ

- B.4 SIPサーブレットのデバッグ

C 既存のアプリケーションのOracle WebLogic Server SIP Containerへの移植

- C.1 アプリケーション・ルーターとレガシー・アプリケーション構成

- C.2 シリアライズ可能でないSipSessionおよびSipApplicationSession

- C.3 SipServletResponse.setCharacterEncoding() APIの変更

- C.4 SipServletRequestおよびSipServletResponseに対するトランザクション制限事項

- C.5 新しいパラメータ・インタフェースの不変パラメータ

- C.6 非推奨のステートレス・トランザクション・プロキシ

- C.7 v1.0デプロイメントの下位互換性モード

- C.7.1 v1.0 Servletデプロイメント用の検証警告

- C.7.2 コミット・メッセージの変更

- C.7.3 システム・ヘッダーとしてのパス・ヘッダー

- C.7.4 SipServletResponse.createPrack()の例外

- C.7.5 Proxy.proxyTo()の例外

- C.7.6 プロキシ・ブランチ・タイマーへの変更

- C.8 非推奨となったAPI

- C.9 SNMP MIBの変更

- C.10 改名された診断モニターと診断アクション

索引

Oracle® WebLogic Server SIP Container

開発者ガイド

11g リリース1 (11.1.1)

B61430-01(原本部品番号:E15461-01)

2009年10月

Oracle WebLogic Server SIP Container開発者ガイド, 11g リリース1(11.1.1)

B61430-01

Copyright © 2006, 2009, Oracle and/or its affiliates. All rights reserved.

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。 ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。 このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。 誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントが、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供される場合は、次のNoticeが適用されます。

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

このソフトウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。 このソフトウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。 このソフトウェアを危険が伴うアプリケーションで使用する際、このソフトウェアを安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。 このソフトウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleはOracle Corporationおよびその関連企業の登録商標です。 その他の名称は、それぞれの所有者の商標または登録商標です。

このソフトウェアおよびドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。 オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。 オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

はじめに

この章の内容は次のとおりです。

- 対象読者

- ドキュメントのアクセシビリティ

- 関連ドキュメント

- 表記規則

対象読者

このガイドは、Oracle WebLogic Server SIP Containerを使用してアプリケーションを開発、パッケージ、デプロイおよびテストする開発者およびプログラマを対象としています。

ドキュメントのアクセシビリティについて

オラクル社は、障害のあるお客様を含めたすべてのお客様に、オラクル社の製品、サービスおよびサポート・ドキュメントをご利用いただけることを目標としています。 オラクル社のドキュメントには、ユーザーが障害支援技術を使用して情報を利用できる機能が組み込まれています。 HTML形式のドキュメントで用意されており、障害のあるお客様が簡単にアクセスできるようにマークアップされています。 標準規格は改善されつつあります。オラクル社はドキュメントをすべてのお客様がご利用できるように、市場をリードする他の技術ベンダーと積極的に連携して技術的な問題に対応しています。 オラクル社のアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/accessibility/を参照してください。

ドキュメント内のサンプル・コードのアクセシビリティについて

スクリーン・リーダーは、ドキュメント内のサンプル・コードを正確に読めない場合があります。コード表記規則では閉じカッコだけを行に記述する必要があります。しかしJAWSはカッコだけの行を読まない場合があります。

外部Webサイトのドキュメントのアクセシビリティについて

このドキュメントにはオラクル社およびその関連会社が所有または管理しないWebサイトへのリンクが含まれている場合があります。 オラクル社およびその関連会社は、それらのWebサイトのアクセシビリティに関しての評価や言及は行っておりません。

聴覚に障害があるお客様のOracleサポート・サービスへのアクセス

Oracleサポート・サービスに連絡するには、テレコミュニケーション・リレー・サービス(TRS)を使用してOracleサポート(+1-800-223-1711)までお電話ください。Oracleサポート・サービスの技術者が、Oracleサービス・リクエストのプロセスに従って、技術的な問題を処理し、お客様へのサポートを提供します。TRSの詳細は、http://www.fcc.gov/cgb/consumerfacts/trs.htmlを参照してください。電話番号の一覧は、http://www.fcc.gov/cgb/dro/trsphonebk.htmlを参照してください。

関連ドキュメント

詳細は、Oracle WebLogic Server SIP Containerセットの次のドキュメントを参照してください。

- 『Oracle WebLogic Server SIP Container管理者ガイド』

- 『Oracle WebLogic Server SIP Containerインストレーション・ガイド』

表記規則

このドキュメントでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

斜体

イタリックは、ユーザーが特定の値を指定するプレースホルダー変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

第I部

概要

ここでは、概要情報について説明します。

第I部は、次の章で構成されます。

- 第1章「SIPサーブレット・アプリケーション開発の概要」

1 SIPサーブレット・アプリケーション開発の概要

この章では、SIPサーブレット・アプリケーション開発について説明します。内容は次のとおりです。

- 1.1項「SIPサーブレットとは」

- 1.2項「SIPサーブレットとHTTPサーブレットの比較」

1.1 SIPサーブレットとは

SIP Servlet APIは、JCP (Java Community Process)のJSR289として標準化されています。

注意:
このドキュメントでは、「SIP Servlet」という用語でAPIを表し、このAPIを使って作成されたアプリケーションを「SIPサーブレット」と称しています。

Javaサーブレットはサーバー側アプリケーションの開発に使用され、HTTPサーブレットはサーブレットのサブクラスでWebアプリケーションの作成に使用されます。SIPサーブレットは、SIP固有の機能が追加された汎用サーブレットAIPとして定義されます。

図1-1 Servlet APIとSIP Servlet API

「図1-1 Servlet APIとSIP Servlet API」の説明

SIPサーブレットはHTTPサーブレットとよく似ているので、HTTPサーブレットの開発者はこのプログラミング・モデルにすぐに慣れるでしょう。HTTPサーブレットで定義されているサービス・レベルとSIPサーブレットで定義されているサービス・レベルはよく似ているので、HTTPとSIPの両方をサポートするアプリケーションを設計するのは簡単です。例1-1は単純なSIPサーブレットの例です。

例1-1 SimpleSIPServlet.java

package oracle.example.simple;
import java.io.IOException;
import javax.servlet.*;
import javax.servlet.sip.*;

public class SimpleSIPServlet extends SipServlet {
protected void doMessage(SipServletRequest req)
throws ServletException, IOException
{
SipServletResponse res = req.createResponse(200);
res.send();
}
}

上の例は、SIP MESSAGEリクエストに対して200 OKレスポンスを返す単純なSIPサーブレットを示しています。このリストからわかるように、SIP ServletとHTTP Servletには次のような多くの共通点があります。

1. サーブレットはAPIが提供するベース・クラスを継承する必要があります。HTTPサーブレットはHttpServletを継承し、SIPサーブレットはSipServletを継承する必要があります。

2. メソッドdoXxxをオーバーライドして実装する必要があります。HTTPサーブレットにはGET/POSTメソッドに対応するdoGet/doPostメソッドがあります。同様に、SIPサーブレットにはメソッド名(上の例ではMESSAGEメソッド)に対応するdoXxxメソッドがあります。アプリケーション開発者は必要なメソッドをオーバーライドして実装します。

3. SIP Servletのライフサイクルおよび管理メソッド(init、destroy)はHTTP Servletとまったく同じです。セッションおよび属性の操作も同じです。

4. 上の例では表示されませんが、web.xmlに対応するSIPサーブレットのsip.xmlという名前のデプロイメント記述子があります。アプリケーション開発者とサービス・マネージャは、複数のSIPサーブレットを使用してアプリケーションを構成するためにこのファイルを編集できます。

ただし、SIPサーブレットとHTTPサーブレットの間には相違点もいくつかあります。重要な違いの1つにプロトコルによるものがあります。次の項では、こうした相違点とSIPサーブレットの特徴について説明します。

1.2 SIPサーブレットとHTTPサーブレットの比較

このセクションでは、SIPサーブレットとHTTPサーブレットの違いについて説明します。

1.2.1 複数のレスポンス

例1-1のdoMessageメソッドには引数が1つしかありませんでした。HTTPでは、トランザクションは1対のリクエストとレスポンスから成っているので、doXxxメソッドの引数でリクエスト(HttpServletRequest)とレスポンス(HttpServletResponse)を指定します。アプリケーションはリクエストを実行するために、そこからパラメータなどの情報を取り出し、結果をレスポンスの本体で返します。

protected void doGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException

SIPでは、1つのリクエストに対して複数のレスポンスを返すこともできます。

図1-2 SIPにおけるリクエストとレスポンスの例

「図1-2 SIPでのリクエストとレスポンスの例」の説明

上の図はINVITEリクエストへのレスポンス例を示しています。この例では、サーバーが1つのINVITEリクエストに対して3つのレスポンス(100、180、200)を返しています。SIPサーブレットでこのようなシーケンスを実装するには、doXxxメソッドでリクエストのみを指定し、アプリケーションがオーバーライドしたメソッドで必要なレスポンスを生成して返します。

現在、SIP Servletでは以下のdoXxxメソッドが定義されています。

protected void doInvite(SipServletRequest req);
protected void doAck(SipServletRequest req);
protected void doOptions(SipServletRequest req);
protected void doBye(SipServletRequest req);
protected void doCancel(SipServletRequest req);
protected void doSubscribe(SipServletRequest req);
protected void doNotify(SipServletRequest req);
protected void doMessage(SipServletRequest req);
protected void doInfo(SipServletRequest req);
protected void doPrack(SipServletRequest req);

1.2.2 レスポンスの受信

SIPの重要な特徴の1つとして、クライアントとサーバーが固定されないという点があります。HTTPの場合、Webブラウザは常にHTTPリクエストを送信し、HTTPレスポンスを受信します。HTTPリクエストを受信し、HTTPレスポンスを送信することはありません。しかし、SIPでは各端末がクライアントとサーバーの両方の機能を持っている必要があります。

図1-3では、両方のSIP電話が相手に電話をかけたり通話を切ったりできる必要があります。

図1-3 SIPにおけるクライアントとサーバーの関係

「図1-3 SIPでのクライアントとサーバーの関係」の説明

上の例は、呼出しまたは切断を行う端末がクライアントとして動作していることを示しています。SIPでは、クライアントとサーバーの役割を1回のダイアログの中で逆転できます。このクライアント機能をUAC (User Agent Client)、サーバー機能をUAS (User Agent Server)、端末をUA (User Agent)と呼びます。SIPサーブレットではレスポンスを受信するためのメソッドも定義されています。

protected void doProvisionalResponse(SipServletResponse res);
protected void doSuccessResponse(SipServletResponse res);
protected void doRedirectResponse(SipServletResponse res);
protected void doErrorResponse(SipServletResponse res);

これらのdoXxxレスポンス・メソッドはリクエストのメソッド名ではありません。次のようにレスポンスのタイプによって名前が付けられています。

- doProvisionalResponse - 暫定レスポンス(1xxレスポンス)の受信時に呼び出されるメソッド

- doSuccessResponse - 成功レスポンスの受信時に呼び出されるメソッド

- doRedirectResponse - リダイレクト・レスポンスの受信時に呼び出されるメソッド

- doErrorResponse - エラー・レスポンス(4xx、5xx、6xxレスポンス)の受信時に呼び出されるメソッド

レスポンスを受信するためのメソッドが存在するということは、SIP Servletではリクエストとレスポンスがそれぞれ別々のスレッドでアプリケーションに送られることを意味しています。アプリケーションはSIPメッセージの関連を明示的に管理する必要があります。リクエストとレスポンスがそれぞれ独立していると、処理のプロセスはいくらか複雑になりますが、より柔軟なプロセスを記述することが可能になります。

SIP Servletを使用すると、アプリケーションでリクエストを明示的に作成することもできます。これらの機能を使用することで、SIPサーブレットはサーバー(UAS)としてリクエストを待つだけでなく、クライアント(UAC)としてリクエストを送信することができます。

1.2.3 プロキシ機能

HTTPプロトコルと異なるもう1つの機能に「フォーク」があります。フォークとは、1つのリクエストを複数のサーバーに同時に(またはシーケンシャルに)プロキシするプロセスのことで、1つの電話番号に複数の端末(オペレータ)が関連付けられている場合(コール・センターなど)に使用されます。

図1-4 プロキシ・フォーク

「図1-4 プロキシ・フォーク」の説明

SIP Servletには、プロキシ機能を持つアプリケーションのためにSIPリクエストをプロキシするユーティリティが備わっています。

1.2.4 メッセージ本文

図1-5に示すように、SIPメッセージの構造はHTTPと同じです。

図1-5 SIPメッセージの例

「図1-5 SIPメッセージの例」の説明

HTTPは本質的にHTMLファイルと画像を転送するためのプロトコルです。転送するコンテンツはメッセージ・ボディに格納されます。HTTP Servletでは、大量のコンテンツを送受信できるようにするストリーム操作ベースのAPIが定義されています。

1.2.4.1 サーブレットのリクエスト

ServletInputStream getInputStream()
BufferedReader     getReader()

1.2.4.2 サーブレットのレスポンス

ServletOutputStream getOutputStream()
PrintWriter         getWriter()
int  getBufferSize()
void setBufferSize(int size)
void resetBuffer()
void flushBuffer()

それに対してSIPでは、メッセージ本文に少量のコンテンツしか格納されません。なぜなら、SIPはリアル・タイムのコミュニケーションを想定しているからです。したがって、上記のメソッドは互換性を維持するためだけに存在し、機能は無効になっています。

SIPにおいてボディに格納されるコンテンツとしては以下のものがあります。

- SDP (Session Description Protocol) - 端末間で使用されるマルチ・メディア・セッションを定義するためのプロトコル。このプロトコルはRFC2373で定義されています。

- プレゼンス情報 - CPIMで定義されているプレゼンス情報を記述するメッセージ。

- IMメッセージ - IM (インスタント・メッセージ)ボディ。ユーザー入力メッセージはメッセージ・ボディに格納されます。

メッセージ本文は小さいので、これをストリーミングで処理するとオーバーヘッドが増加します。SIPサーブレットはAPIを再定義して、次のようにメッセージをメモリー上で操作するようにしています。

1.2.4.3 SipServletMessage

void   setContent(Object content, String contentType)
Object getContent()
byte[] getRawContent()

1.2.5 サーブレット・コンテナの役割

次の項では、SIPサーブレット・コンテナとしてOracle WebLogic Server SIP Containerが提供する主な機能について説明します。

- アプリケーション管理 - サーブレット・コンテキストによるアプリケーション管理、サーブレットのライフサイクル管理、デプロイメント記述子によるアプリケーション初期化などの機能について説明します。

- SIPメッセージング - 着信したSIPメッセージを解析して適切なSIPサーブレットに渡す、SIPサーブレットによって作成されたメッセージを適切なUASに送信する、SIPヘッダー・フィールドを自動的に設定するといった機能について説明します。

- ユーティリティ機能 - セッション、ファクトリ、プロキシなど、SIPサーブレットで使用できる機能について説明します。

1.2.5.1 アプリケーション管理

HTTPサーブレット・コンテナと同様、SIPサーブレット・コンテナもサーブレット・コンテキストによってアプリケーションを管理します(図1-6を参照)。サーブレット・コンテキスト(アプリケーション)は通常はWAR形式で保管され、各アプリケーション・サーバーにデプロイされます。

注意:
アプリケーション・サーバーにデプロイする方法は、製品によって異なります。詳細は、お使いのアプリケーション・サーバーのドキュメントを参照してください

図1-6 サーブレット・コンテナとサーブレット・コンテキスト

「図1-6 サーブレット・コンテナとサーブレット・コンテキスト」の説明

コンバージドSIP/Webアプリケーションのサーブレット・コンテキストには、SIPサーブレット、HTTPサーブレット、およびJSPを含めることができます。

Oracle WebLogic Server SIP Containerでは、プラットフォームとしてお使いのアプリケーション・サーバーと同じ方法でアプリケーションをデプロイできます。ただし、SIPサーブレットを含むアプリケーションをデプロイする場合は、SIPサーブレットで定義されたSIP固有のデプロイメント記述子(sip.xml)が必要です。一般的なコンバージドSIP/Webアプリケーションのファイル構造を表1-1に示します。

表1-1 アプリケーションのファイル構造の例

ファイル

説明

WEB-INF/

コンバージドSIP/Webアプリケーションの構成ファイルと実行ファイルをこのディレクトリに配置します。このディレクトリ内のファイルをWeb上で直接参照することはできません(サーブレットではできます)。

WEB-INF/web.xml

WebアプリケーションのJava EE標準構成ファイル。

WEB-INF/sip.xml

SIPアプリケーションのSIP Servlet定義の構成ファイル。

WEB-INF/classes/

コンパイル済みのクラス・ファイルをこのディレクトリに保存します。HTTPサーブレットとSIPサーブレットの両方を保存することができます。

WEB-INF/lib/

JARファイルとしてアーカイブされたクラス・ファイルをこのディレクトリに保存します。HTTPサーブレットとSIPサーブレットの両方を保存することができます。

*.jsp, *.jpg

JSPなどのWebアプリケーションを構成するファイルをJava EEと同じ方法でデプロイできます。

sip.xmlファイルで指定する情報はweb.xmlのものと似ていますが、<servlet-mapping>設定はHTTPサーブレットとは異なります。HTTPでは、URLのファイル名部分に関連するサーブレットを指定します。しかし、SIPにはファイル名という概念がありません。SIPリクエストのヘッダー・フィールドまたはURIを使ってフィルタ条件を設定します。例1-2では、「register」というSIPサーブレットがすべてのREGISTERメソッドに割り当てられています。

例1-2 sip.xmlのフィルタ条件の例

<servlet-mapping>
<servlet-name>registrar</servlet-name>
<pattern>
<equal>
<var>request.method</var>
<value>REGISTER</value>
</equal>
</pattern>
</servlet-mapping>

デプロイされた後、サーブレット・コンテキストのライフサイクルはサーブレット・コンテナによって保守されます。サーブレット・コンテキストの起動/停止は通常はサーバーの起動/停止時に行われますが、システム管理者がサーブレット・コンテキストの起動、停止、再ロードを明示的に行うこともできます。

1.2.5.2 SIPメッセージング

SIPサーブレット・コンテナが提供するSIPメッセージング機能は以下のタイプに分類されます。

- 受信したSIPメッセージを解析します。

- 解析したメッセージを適切なSIPサーブレットに渡します。

- SIPサーブレット生成のメッセージを適切なUAに送信します。

- レスポンス(「100 Trying」など)を自動的に生成します。

- SIPヘッダー・フィールドを自動的に管理します。

SIPサーブレットが処理するすべてのSIPメッセージは、SipServletRequestオブジェクトまたはSipServletResponseオブジェクトとして表現されます。受信したメッセージはパーサーによって解析されてから、これらのオブジェクトのいずれかに変換され、SIPサーブレット・コンテナに送られます。

SIPサーブレット・コンテナは以下の3種類のSIPメッセージを受信します。いずれであるかにより、ターゲット・サーブレットが決められます。

- 最初のSIPリクエスト - SIPサーブレット・コンテナは、どのSIPセッションにも属していないリクエストを受け取ると、前述したsip.xmlファイル内のフィルタ条件を使ってターゲットのSIPサーブレットを決定します。コンテナは初期リクエストを受け取ったときに新しいSIPセッションを作成するので、その時点以降に受け取ったSIPリクエストは後続のリクエストと見なされます。

注意:
フィルタ処理は慎重に行ってください。Oracle WebLogic Server SIP Containerでは、受信したSIPメッセージが複数のSIPサーブレットに合致する場合に、いずれか1つのSIPサーブレットに渡されます。
リクエスト・パラメータなどの追加の基準を使用して、サーブレットにリクエストを転送できます。

- 後続のSIPリクエスト - SIPサーブレット・コンテナは、いずれかのSIPセッションに属するリクエストを受け取ると、そのリクエストをそのセッションに関連付けられたSIPサーブレットに渡します。リクエストがセッションに属するかどうかは、ダイアログIDを使って判別されます。
SIPサーブレットはメッセージを処理するたびに、コンテナが呼出しIDをロックします。SIPサーブレットは、後続のリクエストを受け取るときに同じ呼出しIDの以前のリクエストを処理している場合、SIPサーブレット・コンテナは後続のリクエストをキューイングします。キューイングされたメッセージは、サーブレットが最初のメッセージの処理を終了し、SIPサーブレット・コンテナに制御を返した後にのみ処理されます。

この同時実行性制御は、1つのコンテナとクラスタリングされた環境の両方で保証されています。アプリケーション開発者は、どのような特定のコールIDに対しても1つのメッセージだけが所定の時間に処理されることを理解して、アプリケーションのコードを作成できます。

- 受信したレスポンスがSIPサーブレットがプロキシしたリクエストに対するものであれば、そのSIPセッションは特定されているため、レスポンスは自動的に同じサーブレットに渡されます。SIPサーブレットがそれ自身のリクエストを送信する場合は、最初にSIPセッションでレスポンスを受け取るサーブレットを指定する必要があります。たとえば、リクエストを送信するSIPサーブレットでレスポンスも受信する場合は、SIPセッションで次のハンドラ設定を指定する必要があります。

SipServletRequest req = getSipFactory().createRequest(appSession, ...);
req.getSession().setHandler(getServletName());

SIPで「セッション」というと、通常はRTP/RTSPによるリアル・タイム・セッションを意味します。それに対してHTTPサーブレットでは、「セッション」が複数のHTTPトランザクションを関連付ける方法を意味します。このドキュメントでは、セッション関連の用語を次のように定義します。

表1-2 セッション関連の用語

リアル・タイム・セッション

RTP/RTSPによって確立されたリアル・タイム・セッション。

HTTPセッション

HTTP Servletによって定義されたセッション。複数のHTTPトランザクションを関連付ける方法。

SIPセッション

HTTPセッションと同じ概念をSIPで実装する方法。SIP (RFC3261)には似通った概念として「ダイアログ」がありますが、ライフサイクルと生成の条件が異なるため、このドキュメントではこれを別の用語として扱います。

アプリケーション・セッション

複数のプロトコルおよびダイアログを使って複数のHTTPセッションおよびSIPセッションを関連付けるアプリケーションのための方法。「APセッション」ともいいます。

Oracle WebLogic Server SIP Containerは、次に示すレスポンス・プロセスと再送信プロセスを自動的に実行します。

- 「100 Trying」の送信 - Oracle WebLogic Server SIP ContainerはINVITEリクエストを受信すると、自動的に「100 Trying」を作成して送信します。

- CANCELへのレスポンス - Oracle WebLogic Server SIP ContainerはCANCELリクエストを受信すると、そのリクエストが有効なら次のプロセスを実行します。

1. CANCELリクエストに対して200レスポンスを送信します。

2. 取消し対象のINVITEリクエストに対して487レスポンスを送信します。

3. SIPサーブレット上でdoCancelメソッドを呼び出します。これにより、アプリケーションはdoCancelメソッド内でプロセスを中止することができ、明示的にレスポンスを返す必要がなくなります。

- INVITEへのエラー・レスポンスに対してACKを送信 - SIPサーブレットによって送信されたINVITEに対して4xx、5xxまたは6xxレスポンスが返されたとき、Oracle WebLogic Server SIP Containerは自動的にACKを作成して送信します。なぜなら、ACKはSIPシーケンスでのみ必要であり、SIPサーブレットはこれを必要としないからです。
SIPサーブレットがINVITEへの4xx、5xx、または6xxレスポンスを送信した場合は、そのレスポンスに対するACKを決して受信することはありません。

- UDP使用時の再送信プロセス - SIPでは、UDPなどの信頼性の低いトランスポートが使われている場合に、送信されたメッセージが再送信されることが規定されています。Oracle WebLogic Server SIP Containerは、この仕様に従って再送信プロセスを自動的に実行します。

多くの場合、HTTPサーブレットではアプリケーションがヘッダー・フィールドを明示的に設定したり調べたりする必要はありません。HTTPサーブレット・コンテナがContent-LengthやContent-Typeなどのフィールドを自動的に管理するからです。SIPサーブレットにも同じヘッダー管理機能があります。

ただし、SIPではメッセージ配信に関する重要な情報を入れるフィールドがいくつかあるので、これらのヘッダーをアプリケーションでは変更できません。SIPサーブレットで変更できないヘッダーは「システム・ヘッダー」と呼ばれます。表1-3はシステム・ヘッダーの一覧です。

表1-3 システム・ヘッダー

ヘッダー名

説明

Call-ID

複数のSIPメッセージをCallとして関連付けるためのID情報が含まれます。

From、To

SIPリクエストの送信者と受信者に関する情報(SIP、URIなど)が含まれます。サーブレット・コンテナによってタグ・パラメータが与えられます。

CSeq

シーケンス番号とメソッド名が含まれます。

Via

SIPメッセージが通過したサーバーのリストが含まれます。これはリクエストへのレスポンスを送信するためにパスを追跡したい場合に使用します。

Record-Route、Route

プロキシ・サーバーが後続のリクエストを仲介するときに使われます。

Contact

端末間の直接的なコミュニケーションに使われるネットワーク情報(IPアドレスやポート番号など)が含まれます。REGISTERメッセージ、3xx、または485レスポンスについては、これはシステム・ヘッダーと見なされないので、SIPサーブレットがこの情報を直接編集することができます。

1.2.5.3 ユーティリティ機能

SIP Servletでは、SIPサーブレットで使用できる次のユーティリティが定義されています。

1. SIPセッション、アプリケーション・セッション

2. SIPファクトリ

3. プロキシ

1.2.5.3.1 SIPセッション、アプリケーション・セッション

前述したように、SIPサーブレットは「SIPセッション」を提供し、その概念はHTTPセッションと同じです。HTTPでは、Cookieなどの情報を使って複数のトランザクションが関連付けられます。SIPでは、この関連付けがヘッダー情報(Call-IDおよびFromとToのタグ・パラメータ)を使って行われます。サーブレット・コンテナがSIPセッションを保守し管理します。同じダイアログ内のメッセージは同じSIPセッションを参照できます。また、ダイアログを作成しないメソッド(MESSAGEなど)の場合、同じヘッダー情報を持つメッセージをセッションとして管理できます。

SIPサーブレットには「アプリケーション・セッション」という概念がありますが、これはHTTPサーブレットにはないものです。アプリケーション・セッションとは、複数のSIPセッションおよびHTTPセッションを関連付けて管理するためのオブジェクトです。これはB2BUAなどのアプリケーションに適しています。

1.2.5.3.2 SIPファクトリ

SIPファクトリ(SipFactory)は、アプリケーションの実行に必要なSIP Servlet固有のオブジェクトを作成するためのファクトリ・クラスです。次のオブジェクトを生成することができます。

表1-4 SipFactoryで生成されるオブジェクト

クラス名

説明

URI、SipURI、Address

文字列からSIP URIなどのアドレス情報を生成できます。

SipApplicationSession

新しいアプリケーション・セッションを作成します。SIPサーブレットが新しいSIPシグナル・プロセスを開始するときに呼び出されます。

SipServletRequest

SIPサーブレットがUACとして振る舞ってリクエストを作成するときに使われます。このようなリクエストはProxy.proxyToと一緒に送信することができません。SipServletRequestと共に送信する必要があります。

SipFactoryは、次のコードに示すように、サーブレット・コンテキスト属性のデフォルト名の下にあります。

ServletContext context = getServletContext();
SipFactory factory =
(SipFactory) context.getAttribute("javax.servlet.sip.SipFactory");

1.2.5.3.3 プロキシ

プロキシはリクエストをプロキシするためにSIPサーブレットによって使用されるユーティリティです。SIPでは、プロキシ処理にフォークなどの独自のシーケンスがあります。Proxyによるプロキシ処理では以下の設定を指定することができます。

- 再帰的ルーティング(recurse) - プロキシ処理の宛先が3xxレスポンスを返した場合、リクエストは指定のターゲットにプロキシされます。

- Record-Routeの設定 - 指定されたリクエストでRecord-Routeヘッダーを設定します。

- パラレル/シーケンシャル(parallel) - フォークをパラレルに実行するかシーケンシャルに実行するかを決定します。

- ステートフル - プロキシ処理がトランザクション・ステートフルかどうかを決定します。ステートフル・プロキシ・モードはJSR289で非推奨になったため、このパラメータは関係ありません。

- スーパーバイジング・モード - プロキシ処理の状態が変化した場合(レスポンス受領)、アプリケーションはこれを報告します。

第II部

SIPアプリケーションの開発とプログラミング

ここでは、SIPアプリケーションのプログラミングのガイドラインおよび手順について説明します。

第II部は、次の章で構成されます。

- 第2章「コンバージド・アプリケーションの開発」

- 第3章「SIPプロトコルのプログラミング」

- 第4章「SIPアプリケーションの要件とベスト・プラクティス」

- 第5章「SIPアプリケーションの構成」

- 第6章「SIPサーブレット・リソースのセキュリティ」

- 第7章「メッセージ・ロギングの有効化」

2 コンバージド・アプリケーションの開発

この章では、Oracle WebLogic Server SIP Containerを使用してHTTPとSIPのコンバージド・アプリケーションを開発する方法について説明します。内容は次のとおりです。

- 2.1項「コンバージド・アプリケーションの概要」

- 2.2項「コンバージド・アプリケーションのアセンブルとパッケージ化」

- 2.3項「SIPセッションとHTTPセッションの設定」

- 2.4項「コンバージド・アプリケーションのサンプルの使用」

2.1 コンバージド・アプリケーションの概要

コンバージド・アプリケーションでは、SIPプロトコルの機能とHTTPまたはJava EEのコンポーネントを組み合せることで、統合的な通信サービスを実現します。たとえば、オンラインのPush-to-Talkアプリケーションで、ユーザーがショッピング・カート内の商品について質問するために音声コールを開始するという機能を実現できます。この音声コールのために開始されるSIPセッションは、ユーザーのHTTPセッションに関連付けられています。そのため、音声コールに答える従業員は、ユーザーのショッピング・カートの中身や購入履歴を見ることができます。

アプリケーション・アーカイブ(.EARファイル)へJava EEコンポーネント(EJBなど)を利用するコンバージド・アプリケーションをパッケージ化する必要があります。SIPおよびHTTPプロトコルを利用するコンバージド・アプリケーションは、sip.xmlおよびweb.xml両方のデプロイメント記述子ファイルを含む1つのSARまたはWARファイルでパッケージする必要があります。オプションで、1つのEARファイル内で別々のSARおよびWARコンポーネントにコンバージド・アプリケーションのSIPおよびHTTPサーブレットをパッケージできます。

コンバージド・アプリケーションで使用されるHTTPセッションとSIPセッションには、共通のアプリケーション・セッション・オブジェクトを通じてプログラム的にアクセスできます。HTTPセッションをアプリケーション・セッションに関連付けるためのSIP Servlet APIが用意されています。

2.2 コンバージド・アプリケーションのアセンブルとパッケージ化

SIP Servlet仕様では、コンバージド・アプリケーションのアセンブルに関する要件と制約が詳しく規定されています。SIP Servlet仕様の内容を簡潔にまとめると、次のようになります。

- コンバージド・アプリケーションでは標準的なSIP Servletディレクトリ構造を使用します。

- SIPサーブレットのファイルはすべてWEB-INFサブディレクトリの下に配置します。これにより、HTTPサーブレットがこれらのファイルを静的ファイルとして提供することはなくなります。

- アプリケーションのHTTPコンポーネントとSIPコンポーネントの両方に関するデプロイメント記述子が必要です。つまり、sip.xmlとweb.xmlの両方のデプロイメント記述子が必要になります。Oracle WebLogic Server SIP Containerコンテナ内でのServlet機能を構成するために、weblogic.xmlデプロイメント記述子を用意することもあります。

- デプロイメント記述子の要素には、次の制約があります。

- distributableタグは、sip.xmlとweb.xmlの両方に記述するか、どちらにも記述しません。

- context-param要素は、1つのコンバージド・アプリケーションで共有されます。sip.xmlおよびweb.xml内に同じcontext-param要素を定義する場合は、どちらのパラメータ定義にも同じ値を指定します。

- display-nameまたはicons要素が必要な場合は、その要素をsip.xmlとweb.xmlの両方に定義し、どちらのデプロイメント記述子にも同じ値を指定します。

2.3 SIPセッションとHTTPセッションの設定

図2-1に示すように、Oracle WebLogic Server SIP Containerコンテナにデプロイされるコンバージド・アプリケーションは必ず一意のSipApplicationSessionを持ち、その中に1つまたは複数のSipSessionオブジェクトとConvergedHttpSessionオブジェクトを含めることができます。

図2-1 コンバージド・アプリケーションのセッション

「図2-1 コンバージド・アプリケーションのセッション」の説明

javax.servlet.SipApplicationSessionのAPIにより、そのアプリケーションのSipApplicationSession内のすべての使用可能セッションを反復処理できます。コンバージド・アプリケーションを開発する場合、ユニーク・アプリケーション・セッションでURLをエンコーディングするメソッドも用意されています。

以前のリリースで、Oracle WebLogic Server SIP Containerは次の処理を行うメソッドを提供するために、基本SIP Servlet APIを拡張しました。

- SIP Servletから新しいHTTPセッションを作成するメソッド

- SipApplicationSession内のHTTPセッションを追加および削除するメソッド

- 呼出しIDまたはセッションIDを使用してSipApplicationSessionオブジェクトを取得するメソッド

- SIP Servlet内からセッションIDを使用してHTTP URLをエンコードするメソッド

この機能は、SIP Servlet APIバージョン1.1の一部として直接提供され、独自のAPI(com.bea.wcp.util.Sessions)は、非推奨になりました。表2-0は、非推奨になったメソッドのかわりに使用するSIP Servlet APIを示します。詳細は、SIP Servlet v1.1 API JavaDocを参照してください。

表2-1 非推奨com.bea.wcp.util.Sessionsのメソッド

非推奨になったメソッド(com.bea.wcp.util.Sessions)

置換えメソッド

説明

getApplicationSession

javax.servlet.sip.SipSessionsUtil.

getApplicationSession

指定したセッションIDに基づいてSipApplicationSessionオブジェクトを取得します。

getApplicationSessionsByCallId

なし。

指定した呼出しIDに関連付けられているSipApplicationSessionオブジェクト群のイテレータを取得します。

createHttpSession

なし。

かわりに、HttpSessionをConvergedHttpSessionにキャストできます。

setApplicationSession

javax.servlet.sip.ConvergedHttpSession.

getApplicationSession

HTTPセッションを既存のSipApplicationSessionに関連付けます。

removeApplicationSession

なし。

既存のSipApplicationSessionからHTTPセッションを削除します。

getEncodeURL

javax.servlet.sip.ConvergedHttpSession.

encodeURL

既存のHTTPセッション・オブジェクトのjsessionidを使用してHTTP URLをエンコードします。

注意:
com.bea.wcp.util.Sessions APIは、下位互換性のためにのみ提供されています。すべての新しい開発に対してはSIP Servlet APIを使用します。com.bea.wcp.util.Sessions APIとJSR 289コンバージェンスAPIが混在するコンバージド・アプリケーションはサポートされていません。
具体的には、非推奨のSessions.getApplicationSessionsByCallId(String callId)メソッドは、初期リクエストと既存のSipApplicationSessionオブジェクトとの関連付けにセッション・キーに基づくターゲット・メソッドを使用するv1.1 SIPサーブレットでは使用できません(このターゲット・メカニズムの詳細は、SIPサーブレット仕様v1.1(http://jcp.org/en/jsr/detail?id=289)の15.11.2項を参照してください)。

2.3.1 SipApplicationSessionの変更

replicatedドメインを使用している場合は、SIPサーブレットからSipApplicationSessionオブジェクトを変更するときに、Oracle WebLogic Server SIP Containerによって自動的に同時実行性制御が行われます。つまり、SIPサーブレットからSipApplicationSessionオブジェクトを変更するときに、そのオブジェクトが他のアプリケーションによって同時に変更されるのを防ぐために、SIPコンテナによってオブジェクトが自動的にロックされます。

HTTPサーブレットなどの非SIPアプリケーションでは、アプリケーションの呼出し状態を変更する前に、その呼出し状態を明示的にロックする必要があります。また、単一のSIPサーブレットが他の呼出し状態オブジェクトを変更する必要がある場合(会議開催サブレットが複数の呼出しを結合する場合など)にも必要です。

アプリケーション・セッション・オブジェクトへの同時アクセスの管理を容易にするために、Oracle WebLogic Server SIP Containerでは、標準のSipApplicationSessionオブジェクトを拡張したcom.bea.wcp.sip.WlssSipApplicationSessionが用意され、セッション変更を実行するタスクをカプセル化するために、2つのインタフェースcom.bea.wcp.sip.WlssActionとcom.bea.wcp.sip.WlssAsynchronous Actionが追加されています。これらのAPIを使用すると、SIPコンテナの働きにより、WlssActionおよびWlssAsynchronousActionオブジェクト内に含まれているすべてのビジネス・ロジックが、関連付けられているSipApplicationSessionインスタンスのロックされたコピーに対して確実に適用されます。次のセクションで、各インタフェースについて説明します。

2.3.1.1 同期アクセス

トランザクションおよび同期によってセッション属性を読取りおよび更新を行うアプリケーションは、WlssAction APIを使用する必要があります。WlssActionは、セッションに対してアクション期間の明示的なロックを取得します。例2-1は、このAPIの使用例を示しています。

例2-1 WlssAction APIを使用するサンプル・コード

final SipApplicationSession appSession = ...;
WlssSipApplicationSession wlssAppSession = (WlssSipApplicationSession) appSession;
wlssAppSession.doAction(new WlssAction() {
public Object run() throws Exception {
// Add all business logic here.
appSession.setAttribute("counter", latestCounterValue);
sipSession.setAttribute("currentState", latestAppState);
// The SIP container ensures that the run method is invoked
// while the application session is locked.
return null;
}
});

WlssAction APIは関連するセッションに対して排他的なロックを取得するため、アクション内で別のアプリケーション・セッション属性を変更しようとするとデッドロックが発生することがあります。

2.3.1.2 非同期アクセス

ロックされたSipApplicationSessionのコンテキスト内で異なるSipApplicationSessionを更新するアプリケーションは、WlssAsynchronousAction APIを使用して非同期更新を実行できます。このAPIは、複数のアプリケーションが同じSipApplicationSessionの属性を同時に更新する必要がある場合の競合を軽減します。例2-2に、このAPIの使用例を示します。

このAPIを使用してアプリケーションをコンパイルするには、MIDDLEWARE_HOME/server/lib/wlss/wlssapi.jarとMIDDLEWARE_HOME/server/lib/wlss/sipservlet.jarを含める必要があります。

例2-2 WlssAsynchronousAction APIを使用するサンプル・コード

SipApplicationSession sas1 = req.getSipApplicationSession(); // SipApplicationSession1 is already locked by the container
// Obtain another SipApplicationSession to schedule work on it
WlssSipApplicationSession wlssSipAppSession = SipSessionsUtil.getApplicationSessionById(conferenceAppSessionId);
// The work is done on the application session asynchronously
appSession.doAsynchronousAction(new WlssAsynchronousAction() {
Serializable run(SipApplicationSession appSession) {
// Add all business logic here.
int counter = appSession.getAttribute("counter");
++ counter;
appSession.setAttribute("counter", counter);
return null;
}
});

appSessionに対する処理を非同期的に実行することで、ネストされたロックおよび関連するデッドロックを防ぐことができます。

2.4 コンバージド・アプリケーションのサンプルの使用

Oracle WebLogic Server SIP Containerには、com.bea.wcp.util.Sessions APIを使用したサンプルのコンバージド・アプリケーションが含まれています。すべてのソース・コード、デプロイメント記述子およびサンプルのビルド・ファイルは、WEBLOGIC_HOME\samples \sipserver\examples\src\convergenceにインストールされています。サンプルをビルドして実行する方法については、サンプル・ディレクトリのreadme.htmlファイルを参照してください。

3 SIPプロトコルのプログラミング

この章では、SIPアプリケーションのプログラミングについて説明します。内容は次のとおりです。

- 3.1項「SIPメッセージの圧縮および長いヘッダー・フォーマットの使用」

- 3.2項「SIPサーブレットにおけるコンテンツの間接化の使用」

- 3.3項「アプリケーション・コードからのSNMPトラップ生成」

3.1 SIPメッセージの圧縮および長いヘッダー・フォーマットの使用

この項では、Oracle WebLogic Server SIP Container SipServletMessageインタフェースおよび構成パラメータを使用して、SIPメッセージ・ヘッダー・フォーマットを制御する方法について説明します。

3.1.1 ヘッダー・フォーマットAPIと構成の概要

ワイヤレス・ネットワークで動作するアプリケーションでは、メッセージのサイズを縮小して帯域を節約するために、SIPヘッダーのサイズを制限できます。JSR 289のSipServletMessage.setHeaderメソッドを使用すると、アプリケーション開発者は所定のヘッダーの値に長いまたは圧縮されたフォーマットを設定できます。

JSR 289で提供されたSipServletMessage APIの機能の1つは、setHeaderFormメソッドを使用してSIPメッセージ全体に長いヘッダまたは圧縮ヘッダー・フォーマットを設定できることです。

WlssSipServletMessageに加え、Oracle WebLogic Server SIP Containerには、システムで生成されたすべてのヘッダーに対してSIPヘッダー・フォーマットを制御できるコンテナ全体の構成パラメータが用意されています。このシステム全体のパラメータをWlssSipServletMessage.setUseHeaderFormおよびSipServletMessage.setHeaderとともに使用してヘッダー・フォーマットをさらにカスタマイズできます。

3.1.2 圧縮ヘッダーの概要

表3-1は、SIP仕様(http://www.ietf.org/rfc/rfc3261.txt)に説明されている圧縮ヘッダーの省略形を定義しています。追加ヘッダーを説明する仕様には、圧縮ヘッダーの省略形が含まれることもあります。

表3-1 圧縮ヘッダーの省略形

ヘッダーの名(長いフォーマット)

圧縮フォーマット

Call-ID

i

Contact

m

Content-Encoding

e

Content-Length

l

Content-Type

c

From

f

Subject

s

Supported

k

To

t

Via

v

3.1.3 WlssSipServletMessageでのヘッダー・フォーマットの割当て

メッセージで使用されるヘッダー・フォーマットの割当ておよび取得には、setHeaderFormやgetHeaderFormのようなgetter/setterメソッドのペアを使用します。これらのメソッドは、ヘッダー・フォーマットを説明する単純な列挙オブジェクトであるHeaderFormオブジェクトを割り当てたり返したりします。

- COMPACT - メッセージのすべてのヘッダーに圧縮フォーマットを使用するように強制します。この動作は、構成リファレンス・マニュアルのuse-compact-formに説明した「force compact」のコンテナ全体の構成値と同じです。

- LONG - メッセージのすべてのヘッダーに対して長いフォーマットを使用するように強制します。この動作は、構成リファレンス・マニュアルのuse-compact-formに説明した「force long」のコンテナ全体の構成値と同じです。

- DEFAULT — use-compact-formに設定されたコンテナ全体の構成値にヘッダー・フォーマットを指定します。

SipServletResponse.setHeaderFormはSipServletMessage.setHeaderとコンテナ・レベルの構成パラメータuse-compact-formと組み合せて使用できます。

3.1.4 APIおよび構成の動作の概要

ヘッダー・フォーマットは、ヘッダー、メッセージおよびSIPサーブレット・コンテナ・レベルで設定できます。表3-1は、SipServletMessage.setHeaderForm.で様々なコンテナ構成およびメッセージ・レベルが設定されている場合に、SipServletMessage.setHeaderで新しいヘッダーを追加するときのヘッダー・フォーマットを示しています。

表3-2 ヘッダーを追加する時のAPIの動作

SIPサーブレット・コンテナ・ヘッダー構成(use-compact-form設定)

.SIPServletMessage

setHeaderFormの設定

SipServletMessage.

setHeaderの値

取得したヘッダー

COMPACT

DEFAULT

「Content-Type」

「Content-Type」

COMPACT

DEFAULT

「c」

「c」

COMPACT

COMPACT

「Content-Type」

「c」

COMPACT

COMPACT

「c」

「c」

COMPACT

LONG

「Content-Type」

「Content-Type」

COMPACT

LONG

「c」

「Content-Type」

LONG

DEFAULT

「Content-Type」

「Content-Type」

LONG

DEFAULT

「c」

「c」

LONG

COMPACT

「Content-Type」

「c」

LONG

COMPACT

「c」

「c」

LONG

LONG

「Content-Type」

「Content-Type」

LONG

LONG

「c」

「Content-Type」

FORCE_COMPACT

DEFAULT

「Content-Type」

「c」

FORCE_COMPACT

DEFAULT

「c」

「c」

FORCE_COMPACT

COMPACT

「Content-Type」

「c」

FORCE_COMPACT

COMPACT

「c」

「c」

FORCE_COMPACT

LONG

「Content-Type」

「Content-Type」

FORCE_COMPACT

LONG

「c」

「Content-Type」

FORCE_LONG

DEFAULT

「Content-Type」

「Content-Type」

FORCE_LONG

DEFAULT

「c」

「Content-Type」

FORCE_LONG

COMPACT

「Content-Type」

「c」

FORCE_LONG

COMPACT

「c」

「c」

FORCE_LONG

LONG

「Content-Type」

「Content-Type」

FORCE_LONG

LONG

「c」

「Content-Type」

表3-1は、コンテナ構成値が異なる場合に、WlssSipServletResponse.setUseHeaderFormでヘッダー・フォーマットを設定したときのシステム・ヘッダー・フォーマットを示しています。

表3-3 システム・ヘッダーに対するAPIの動作

SIPサーブレット・コンテナ・ヘッダー構成(use-compact-form設定)

SipServletMessage.

setHeaderFormの設定

取得した コンタクト・ヘッダー

COMPACT

DEFAULT

「m」

COMPACT

COMPACT

「m」

COMPACT

LONG

「Contact」

LONG

DEFAULT

「Contact」

LONG

COMPACT

「m」

LONG

LONG

「Contact」

FORCE_COMPACT

DEFAULT

「m」

FORCE_COMPACT

COMPACT

「m」

FORCE_COMPACT

LONG

「Contact」

FORCE_LONG

DEFAULT

「Contact」

FORCE_LONG

COMPACT

「m」

FORCE_LONG

LONG

「Contact」

3.2 SIPサーブレットにおけるコンテンツの間接化の使用

この項では、SIPメッセージ本文で指定されている間接的なコンテンツを扱うことのできるSIP Servletの開発方法について説明します。

3.2.1 コンテンツの間接化の概要

SIPメッセージのボディで提供するデータは、SIPメッセージ・ボディに直接含めることも、間接的に含めることもできます。後者の場合は、URLコンテンツを示すHTTP URLとメタデータを指定するという方法を使用します。メッセージ・ボディのコンテンツを間接的に指定するという方法は、主に次の状況で使用されます。

- メッセージ・ボディに含まれるデータの量が多い場合。この場合は、コンテンツの間接化を行うことで、大きなデータを(別の接続またはプロトコルを使用して) SIPネットワークの外部に移動させることができます。

- 帯域幅に制約があるアプリケーションの場合。この場合は、コンテンツの間接化を行うことで、メッセージ本文を取得すべきかどうかをアプリケーションがメタデータに基づいて判断できるようになります(メッセージ本文の取得は、アプリケーションのパフォーマンスやレスポンス時間を低下させる可能性があります)。

Oracle WebLogic Server SIP Containerには、SIPメッセージ内に指定されている間接的なコンテンツを取り扱うための単純なAPIが用意されています。

3.2.2 コンテンツ間接化APIの使用

Oracle WebLogic Server SIP Containerのコンテンツ間接化APIを使用すると、SIPメッセージでコンテンツの間接化が行われているかどうかをすばやく判断したり、間接的なコンテンツに関連付けられているすべてのメタデータを簡単に取得したりできます。この基本APIは、ユーティリティ・クラスcom.bea.wcp.sip.engine.server.ContentIndirectionUtilと、コンテンツ・メタデータのアクセスに使用するインタフェースcom.bea.wcp.sip.engine.server.ICParsedDataから成ります。

SIPサーブレットでは、このユーティリティ・クラスを使用することで、間接的なコンテンツを含んでいるSIPメッセージを識別したり、コンテンツ・メタデータを表すICParsedDataオブジェクトを取得したりできます。ICParsedDataオブジェクトには、様々なメタデータ属性を返す単純なゲッター・メソッドが用意されています。

3.2.3 追加情報

コンテンツの間接化の詳細は、RFC 4483にあります。

コンテンツ間接化APIの追加のドキュメントについては、Oracle Fusion Middleware WebLogic Server APIリファレンスを参照してください。

3.3 アプリケーション・コードからのSNMPトラップ生成

この項では、Oracle WebLogic Server SIP ContainerのSipServletSnmpTrapRuntimeMBeanを使用してSIP サーブレット内からSNMPトラップを生成する方法について説明します。

3.3.1 概要

Oracle WebLogic Server SIP Containerでは、実行時MBeanとしてSipServletSnmpTrapRuntimeMBeanが含まれており、これを使用することで、アプリケーションでSNMPトラップを簡単に生成できます。Oracle WebLogic Server SIP ContainerのMIBには、アプリケーションによって生成されるトラップ用に予約された7個の新しいOIDが含まれます。それぞれのOIDはアプリケーションがトラップに割り当てる重大度に対応しており、重大度の最も低いものから順番に並べると次のようになります。

- Info

- Notice

- Warning

- Error

- Critical

- Alert

- Emergency

アプリケーションからトラップを生成するには、SipServletSnmpTrapRuntimeMBeanのインスタンスを取得して、目的のトラップの重大度に対応するメソッドを実行します(sendInfoTrap()、sendWarningTrap()、sendErrorTrap()、sendNoticeTrap()、sendCriticalTrap()、sendAlertTrap()、sendEmergencyTrap())。各メソッドにはパラメータが1つあり、このパラメータには生成するトラップ・メッセージの文字列値を指定します。

この方法でSNMPトラップを生成すると、Oracle WebLogic Server SIP Containerは自動的に、サーブレット名、アプリケーション名および呼出し側サーブレットに関連付けられているOracle WebLogic Server SIP Containerインスタンスの名前を送信します。

3.3.2 SipServletSnmpTrapRuntimeMBeanへのアクセスの要件

SipServletSnmpTrapRuntimeMBeanを取得するには、呼出し側のSIPサーブレットがサーブレット・コンテキストからMBeanルックアップを実行できる必要があります。この機能を有効化するには、Oracle WebLogic Server SIP Container管理者のrole-nameエントリをsip.xmlデプロイメント記述子内のsecurity-roleとrun-asロール要素に割り当てる必要があります。例3-1に、必須ロール要素を強調表示したsip.xmlファイルのサンプルを示します。

例3-1 sip.xmlでのロール要件のサンプル

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sip-app
PUBLIC "-//Java Community Process//DTD SIP Application 1.0//EN"
"http://www.jcp.org/dtd/sip-app_1_0.dtd">
<sip-app>
<display-name>My SIP Servlet</display-name>
<distributable/>
<servlet>
<servlet-name>myservlet</servlet-name>
<servlet-class>com.mycompany.MyServlet</servlet-class>
<run-as>
<role-name>weblogic</role-name>
</run-as>
</servlet>
<servlet-mapping>
<servlet-name>myservlet</servlet-name>
<pattern>
<equal>
<var>request.method</var>
<value>INVITE</value>
</equal>
</pattern>
</servlet-mapping>
<security-role>
<role-name>weblogic</role-name>
</security-role>
</sip-app>

3.3.3 SipServletSnmpTrapRuntimeMBeanへの参照の取得

SNMPトラップを発生するSIPサーブレットはすべて、最初にSipServletSnmpTrapRuntimeMBeanへの参照を取得する必要があります。例3-2に、MBeanを取得するメソッドのサンプル・コードを示します。

例3-2 SipServletSnmpTrapRuntimeMBeanにアクセスするメソッドのサンプル

public SipServletSnmpTrapRuntimeMBean getServletSnmpTrapRuntimeMBean() {
MBeanHome localHomeB = null;
SipServletSnmpTrapRuntimeMBean ssTrapMB = null;

try
{
Context ctx = new InitialContext();
localHomeB = (MBeanHome)ctx.lookup(MBeanHome.LOCAL_JNDI_NAME);
ctx.close();
} catch (NamingException ne){
ne.printStackTrace();
}

Set set = localHomeB.getMBeansByType("SipServletSnmpTrapRuntime");
if (set == null || set.isEmpty()) {
try {
throw new ServletException("Unable to lookup type 'SipServletSnmpTrapRuntime'");
} catch (ServletException e) {
e.printStackTrace();
}
}
ssTrapMB = (SipServletSnmpTrapRuntimeMBean) set.iterator().next();
return ssTrapMB;
}

3.3.4 SNMPトラップの生成

例3-3は、例3-2のメソッドを使用して、SIP INVITEへのレスポンス時にMBeanインスタンスを通じてSIPサーブレットからSNMPトラップを生成する方法を示しています。

例3-3 SNMPトラップの生成

public class MyServlet extends SipServlet {
private SipServletSnmpTrapRuntimeMBean sipServletSnmpTrapMb = null;

public MyServlet () {
}

public void init (ServletConfig sc) throws ServletException {
super.init (sc);
sipServletSnmpTrapMb = getServletSnmpTrapRuntimeMBean();
}

protected void doInvite(SipServletRequest req) throws IOException {
sipServletSnmpTrapMb.sendInfoTrap("Rx Invite from " + req.getRemoteAddr() + "with call id" + req.getCallId());
}
}

4 SIPアプリケーションの要件とベスト・プラクティス

この章では、Oracle WebLogic Server SIP Containerにデプロイするアプリケーションを開発するための要件とベスト・プラクティスについて説明します。内容は次のとおりです。

- 4.1項「分散型アプリケーションの開発の概要」

- 4.2項「アプリケーションではスレッドを作成しない」

- 4.3項「サーブレットは非ブロッキングでなければならない」

- 4.4項「すべてのアプリケーション・データをセッションに格納する」

- 4.5項「すべてのセッション・データがシリアライズ可能でなければならない」

- 4.6項「setAttribute()を使用して「No-Call」Scopeのセッション・データを変更する」

- 4.7項「send()呼出しがバッファされる」

- 4.8項「SIPサーブレットを配布可能としてマークする」

- 4.9項「SipApplicationSessionActivationListenerを慎重に使用する」

- 4.10項「セッションの有効期限のベスト・プラクティス」

- 4.11項「Java EEアプリケーションのベスト・プラクティスに従う」

4.1 分散型アプリケーションの開発の概要

典型的な本番環境では、SIPアプリケーションはエンジン層クラスタを形成するOracle WebLogic Server SIP Containerインスタンスのクラスタにデプロイされます。SIPデータ層内のサーバーのクラスタは、アクティブな呼出しについての呼出し状態のレプリケートされたインメモリー・データベースを提供します。この環境でアプリケーションを確実に機能させるには、次の項に説明されているプログラミングの作法と慣行に従い、デプロイ後のアプリケーションの複数のコピーがクラスタ環境で期待どおりに動作するようにしてください。

旧バージョンのOracle WebLogic Server SIP Containerのアプリケーションを移植しようとしている場合、次に説明する規約や制約の多くは馴染みのないものかもしれません。というのも、以前のWebLogic Server実装ではクラスタリングをサポートしていなかったからです。アプリケーションを移植したら徹底的なテストとプロファイリングを行って問題を洗い出し、新しい環境で満足な結果が得られるようにしてください。

4.2 アプリケーションではスレッドを作成しない

Oracle WebLogic Server SIP Containerはマルチ・スレッド・アプリケーション・サーバーであり、ホストしているモジュールについてリソースの割当て、同時実行性およびスレッドの同期化を慎重に管理します。Oracle WebLogic Server SIP Containerアーキテクチャを最大限に生かすには、SIPサーブレットおよびJava EE APIの仕様に従ってアプリケーションのモジュールを構築してください。

SIPサーブレットなどのサーバー側モジュール内に新たなスレッドを作成するようなアプリケーション設計は避けてください。

- SIPサーブレット・コンテナは、SIPサーブレットのdoxxxメソッドを呼び出すとき、関連する呼出し状態を自動的にロックします。doxxxメソッドが追加のスレッドを生成したり、制御を返す前に別の呼出し状態にアクセスしたりすると、シナリオのデッドロックやセッション・データの更新の喪失が発生する恐れがあります。

- 独自のスレッドを作成するアプリケーションはあまり効率がよくありません。JVMのスレッドは、慎重に割り当てる必要のある限られたリソースです。サーバーの負荷が増大すると、アプリケーションが停止するか、Oracle WebLogic Server SIP Containerのパフォーマンスが低下することがあります。デッドロックやスレッド不足などの問題は、アプリケーションに重い負荷がかかるまで明らかにならない可能性があります。

- マルチスレッド・モジュールは複雑なため、デバッグが困難になります。アプリケーションが生成したスレッドとWebLogic Serverスレッドの間の対話の場合、特に予測や分析が難しくなります。

- 「setAttribute()を使用して「No-Call」Scopeのセッション・データを変更する」に説明されているようにWlssSipApplicationSession.doAction()メソッドは、生成するJavaスレッドに対し同期化しません。doAction()内に作成したスレッドは同じWlssSipApplicationSessionに他のdoAction()を実行します。同様に、着信したSIPメッセージを処理する際にコンテナがメイン・スレッドを自動的にロックするため、異なるwlssSipApplicationSessionにアクセスするためにdoAction()を使用するメイン・スレッドは、デッドロックを引き起こす場合があります。「setAttribute()を使用して「No-Call」Scopeのセッション・データを変更する」では、デッドロック状況の可能性について説明します。

警告:
アプリケーションによるスレッドの生成が必要な場合、デッドロックが起こらないよう、慎重にセッション・データへの同時アクセスを管理しなければなりません。少なくとも、SIPサーブレットのサービス・メソッド内にスレッドを生成することは避けてください。かわりに、サービス・メソッドの外で別々のスレッド・プールを保持してください。そして、すべてのセッション・データへのアクセスを同期するように注意してください。

4.3 サーブレットは非ブロッキングでなければならない

SIPおよびHTTPサーブレットは、メソッドが呼び出されるとき呼出し状態がロックされた状態になるので、SIPメソッドの本体でスレッドをブロックしないようにする必要があります。たとえば、サーブレット・メソッドがSIPサーブレット・コンテナに制御を返す前にデータの取得や書込みを積極的に待機するような設計は避けてください。

4.4 すべてのアプリケーション・データをセッションに格納する

アプリケーションを複数のエンジン層サーバー(レプリケートされたOracle WebLogic Server SIP Container構成内)にデプロイする場合は、すべてのアプリケーション・データをセッション属性としてセッションに格納する必要があります。レプリケートされた構成では、エンジン層サーバーはキャッシュされた情報を保持しないので、すべてのアプリケーションをSIPデータ層サーバーにあるセッション属性からデシリアライズする必要があります。

4.5 すべてのセッション・データがシリアライズ可能でなければならない

SIPアプリケーション呼出し状態のインメモリー・レプリケーションをサポートするためには、SIPサーブレット・セッションに格納されるオブジェクトをすべてシリアライズ可能にする必要があります。オブジェクトがシリアライズ可能と見なされるには、オブジェクトのすべてのフィールドがシリアライズ可能か一時的なフィールドである必要があります。サーブレットでシリアライズ可能なオブジェクトとシリアライズ不可能なオブジェクトが組み合せて使用した場合、Oracle WebLogic Server SIP Containerはシリアライズ不可能なオブジェクトのセッション状態をレプリケートすることができません。

4.6 setAttribute()を使用して「No-Call」Scopeのセッション・データを変更する

SIPサーブレット・コンテナは、SIPサーブレットのdoxxxメソッドを呼び出す時、関連する呼出し状態を自動的にロックします。しかし、アプリケーションは、「No-Call」Scopeのセッション・データを変更する場合もあります。No-call scopeは、通常のdoxxxメソッドの範囲外で呼出し状態データが変更されたコンテキストを参照します。たとえば、HTTPサーブレットがSIPセッション・データを変更しようとする場合、またはサーブレットを呼び出す前にコンテナがロックした呼出し状態以外の呼出し状態をSIPサーブレットが変更しようとする場合、データはno-call scopeに変更されます。

アプリケーションは常に、SIPセッションのsetAttributeメソッドを使用してno-call scopeの属性を変更する必要があります。同様に、セッション・オブジェクトから属性を削除するには、removeAttributeを使用してください。セッション・データを更新するためにsetAttribute/removeAttributeが使用されるたびに、SIPサーブレット・コンテナは関連する呼出し状態のロックを取得および解除します。(メソッドは、更新するオブジェクトを待ち行列化させ、直ちに制御を返します。)これにより、1回に1つのアプリケーションだけがデータを変更し、クラスタのSIPデータ層ノード間で変更がレプリケートされることが確実になります。

その他のsetメソッドを使ってセッションの内部でオブジェクトを変更した場合、Oracle WebLogic Server SIP Containerはその変更をレプリケートできません。

Oracle WebLogic Server SIP Containerコンテナは、setattributeを呼び出した後に加えられた変更を呼出し状態に維持しません。たとえば、次のコード・サンプルでは、setAttributeを呼び出すと呼出し状態が直ちに変更されますが、続いてmodifyState()を呼び出すと、呼出し状態が変更されません。

Foo foo = new Foo(..);
appSession.setAttribute("name", foo); // This persists the call state.
foo.modifyState(); // This change is not persisted.

そのかわりに、次のように呼出し状態属性の値を変更してから、setAttributeを呼び出すようにしてください。

Foo foo = new Foo(..);
foo.modifyState();
appSession.setAttribute("name", foo);

また、SIPサーブレット・コンテナには、それぞれのsetAttributeの呼出しに対して呼出し状態がロックされるという点にも留意してください。たとえば、HTTPサーブレットで次のコードを実行する時、SIPサーブレット・コンテナは呼出し状態のロックを2回ずつ取得して解除します。

appSess.setAttribute("foo1", "bar2");
appSess.setAttribute("foo2", "bar2");

このようにロックすると、1つのスレッドだけが常に呼状態を変更することが確実になります。しかし、他のプロセスは順次更新の間に呼状態を変更することができます。次のコードは、no-call状態を行なった場合、スレッド・セーフと見なされません。

Integer oldValue = appSession.getAttribute("counter");
Integer newValue = incrementCounter(oldValue);
appSession.setAttribute("counter", newValue);

上のコードをスレッド・セーフにするには、wlssAppSession.doActionメソッドを使用して囲む必要があります。これにより、呼出し状態へのすべての変更が、次のように単一のトランザクション・ロック内で行われます。

wlssAppSession.doAction(new WlssAction() {
public Object run() throws Exception {
Integer oldValue = appSession.getAttribute("counter");
Integer newValue = incrementCounter(oldValue);
appSession.setAttribute("counter", newValue);
return null;
}
});

最後に、doInvite()などの「doSipMethod」で呼出し状態をロックした場合、デッドロック状況を回避するようにしてください。doSipMethodの手順が実行されると、Oracle WebLogic Server SIP Containerコンテナは、すでに呼出し状態をロックしていることに注意してください。アプリケーション・コードがメソッド内からの現在の呼出し状態にアクセスしようとすると、(たとえば、データ構造や属性に保存されているセッションへのアクセス)、ロックの発注結果はデッドロックになります。

例4-1は、デッドロックとなる例を示しています。コンテナによってcallAppSessionに関連付けられた呼出しのコードが実行されると、ロックの順が逆転してgetApplicationSession(callId)とのセッションを取得しようとするとデッドロックの原因になります。

例4-1 デッドロックを引き起こすセッション・アクセス

WlssSipApplicationSession confAppSession = (WlssSipApplicationSession) appSession;
confAppSession.doAction(new WlssAction() {
// confAppSession is locked
public Object run() throws Exception {
String callIds = confAppSession.getAttribute("callIds");
for (each callId in callIds) {
callAppSess = Session.getApplicationSession(callId);
// callAppSession is locked
attributeStr += callAppSess.getAttribute("someattrib");
}
confAppSession.setAttribute("attrib", attributeStr);
}
}

com.bea.wcp.sip.WlssActionインタフェースの使用については、6.3.1項「SipApplicationSessionの変更」を参照してください。

4.7 send()呼出しがバッファされる

SIPサーブレットがdoInvite()、doAck()、doNotify()などのSIPリクエスト・メソッド内でsend()メソッドを呼び出す場合は、Oracle WebLogic Server SIP Containerコンテナによってすべてのsend()呼出しがバッファされ、SIPリクエスト・メソッドの復帰後にそれらが順に転送されるという点に注意してください。send()呼出しが即座に転送されることを前提にアプリケーションを設計しないでください。

警告:
リクエストやレスポンスは制御がSIPサーブレット・コンテナに返るまで送信されないので、send()を呼び出した後でアプリケーションが待機したりスリープしたりしないようにする必要があります。

4.8 SIPサーブレットを配布可能としてマークする

SIPサーブレットをクラスタ環境にデプロイすることを前提として設計およびプログラムした場合は、アプリケーションをエンジン層サーバーのクラスタにデプロイするときに、サーブレットのデプロイメント記述子にdistributableマーカー要素を入れる必要があります。distributable要素を省略すると、Oracle WebLogic Server SIP Containerはそのサーブレットをエンジン層サーバーのクラスタにデプロイしません。sip.xmlでdistributableをマークした場合は、WARファイルのweb.xmlでもマークする必要があります。

distributable要素は必須ではなく、単一の組合せ層(レプリケートされない)Oracle WebLogic Server SIP Containerインスタンスにデプロイする場合は無視されます。

4.9 SipApplicationSessionActivationListenerを慎重に使用する

SIPサーブレット1.1仕様は、SIPセッションがアクティブ化されるかパッシブ化される場合アプリケーションにコールバックを提供するSipApplicationSessionActivationListenerについて説明します。レプリケートされたOracle WebLogic Server SIP Containerデプロイメントのみにコールバックが発生することに注意してください。単一サーバー・デプロイメントはSIPデータ層を使用しません。そのためSIPセッションはパッシブ化されません。

レプリケートされたデプロイメントOracle WebLogic Server SIP Containerは、セッションに対してSIPメッセージが処理される前後にSIPセッションを何度もアクティブ化し、パッシブ化します。(RDBMSベースの永続性が構成されない場合でも、通常、どのレプリケートされたデプロイメントにおいてもこれは発生します。)アクティブ化およびパッシブ化のこの定数サイクルは、頻繁なコールバックになるため、アプリケーションでSipApplicationSessionActivationListenerの使用を控えます。

4.10 セッションの有効期限のベスト・プラクティス

JSR289アプリケーションでは、コンテナでのセッションの削除がよりインテリジェントに行われます。たとえば、セッションまたはsipappsessionに対し、invalidate()を明示的に呼び出す必要はありません。

ただし、セッションでsetExpirs()が使用され、アプリケーションがJRS289型である場合は、セッションでsetInvalidateWhenReat(false)を呼び出さないかぎり、この呼出しの効果はありません。

4.11 Java EEアプリケーションのベスト・プラクティスに従う

他のJava EE APIを使用したアプリケーションをデプロイする場合は、それらのAPIの基本的なクラスタリング・ガイドラインに従ってください。たとえばEJBをデプロイする場合は、すべてのメソッドを多重呼出し不変として設計し、デプロイメント記述子の中でEJBホームをクラスタ化可能として指定してください。

5 SIPアプリケーションの構成

この章では、Oracle WebLogic Server SIP Containerアプリケーションの構成機能を使用する方法を説明します。内容は次のとおりです。

- 5.1項「アプリケーション構成モデル」

- 5.2項「デフォルト・アプリケーション・ルーターの使用」

- 5.3項「カスタム・アプリケーション・ルーターの構成」

- 5.4項「セッション・キーに基づくリクエストのターゲット」

注意:
SIPサーブレットv1.1仕様(http://jcp.org/en/jsr/detail?id=289)では、正式なアプリケーションの選択および構成処理が説明されており、これはOracle WebLogic Server SIP Containerに完全に実装されています。新規の開発についてはすべて、このドキュメントで説明されているSIPサーブレットv1.1の手法を使用します。Oracle WebLogic Server SIP Containerの前のバージョンで説明されているアプリケーション構成手法は非推奨になっています。
Oracle WebLogic Server SIP Containerでは、次の場合にかぎって、バージョン1.0の構成手法を使用してアプリケーションに下位互換性を提供します。

- カスタム・アプリケーション・ルーターを構成しない場合、および

- デフォルトのアプリケーション・ルーター・プロパティを構成しない場合。

5.1 アプリケーション構成モデル

アプリケーション構成は、SIPリクエストにサービスを適用するための複数のSIPアプリケーションを論理パスにチェーンする処理です。SIPサーブレットv1.1仕様は、SIPアプリケーションの構成に重要な役割を果たすアプリケーション・ルーター(AR)デプロイメントを導入します。アプリケーション・ルーターは、初期のSIPリクエストを調べて、カスタム・ロジックを使用して、リクエストを処理するSIPアプリケーションを決定します。Oracle WebLogic Server SIP Containerでは、初期リクエストが、まずリクエストを処理するのに使用するアプリケーションを決定するARに送信されます。

Oracle WebLogic Server SIP Containerでは、テキスト・ファイルを使用して構成できるデフォルト・アプリケーション・ルーターを提供します。ただし、ほとんどのインストールでは、SipApplicationRouterインタフェースを実装することでカスタム・アプリケーション・ルーターを開発およびデプロイします。カスタム・アプリケーション・ルーターを使用すると、リクエストを処理するSIPアプリケーションを決定するときデータ・ストアを調べることができます。

アプリケーション・ルーターと違って、メッセージを処理するために使用可能なSIPアプリケーションの情報を必要としません。個々のSIPアプリケーションがお互いに独立しています。個別のアプリケーションは、システムにデプロイされている他のアプリケーションを認識する必要がなく、SIPリクエストに対して特定のサービスを実行します。(アプリケーション・ルーターにはデプロイされているアプリケーションの認識が必要で、SipApplicationRouterインタフェースによって自動的にアプリケーションのデプロイメントおよびアンデプロイメントが通知されます。)

個別SIPアプリケーションは、プロキシ処理またはリレー処理で初期リクエストの処理を完了するか、UAS(User Agent Server)としてリクエストを終了します。初期リクエストがプロキシまたはリレーされていた場合、SIPコンテナによってリクエストが再びアプリケーション・ルーターに転送され、リクエスト用のサービスを提供する次のSIPアプリケーションが選択されます。このように、ARはリクエストを処理するのに必要である複数のSIPアプリケーションをチェーンすることができます。チェーン処理が次の場合に、終了されます。

- 選択したSIPアプリケーションはチェーンを終了させるUASとして動作する場合、または

- そのリクエストに対して選択できるアプリケーションがない場合(この場合、リクエストが出力されます。)

チェーンが終了され、リクエストが送信された場合、SIPコンテナは、後続のリクエストを処理するためにアプリケーションの定義されたパスを使用します。ARは調べられません。

図5-1は、アプリケーション・ルーターを使用してSIPリクエストに複数のサービスを適用する方法を示します。

図5-1 構成されたアプリケーション・モデル

「図1-5 構成されたアプリケーション・モデル」の説明

ARはリモートおよびローカルの両方のアプリケーションを選択でき、サービスのチェーンを同じOracle WebLogic Server SIP Containerコンテナに配置する必要はありません。

5.2 デフォルト・アプリケーション・ルーターの使用

Oracle WebLogic Server SIP Containerには、基本機能のあるDAR(デフォルト・アプリケーション・ルーター)が含まれており、基本機能はSIPサーブレット仕様v1.1(http://jcp.org/en/jsr/detail?id=289)の付録C「Default Application Router」に説明されています。Oracle WebLogic Server SIP Container DARは、SipApplicationRouterインタフェースのメソッドをすべて実装し、v1.1仕様で説明されている単純なJavaプロパティ・ファイルを使用して構成されます。

DARプロパティ・ファイルの各行に1つ以上のSIPメソッドが指定され、カンマで区切った形式でSIPルーティング情報も指定されます。起動時にDARは最初にプロパティ・ファイルを読み込みます。また、SIPアプリケーションがコンテナにデプロイまたはアンデプロイされるたびにもプロパティ・ファイルを読み込みます。

DARによって使用される構成ファイルの場所を指定するには、「カスタム・アプリケーション・ルーターの構成」の説明に従って管理コンソールを使用してプロパティを設定するか、またはOracle WebLogic Server SIP Containerインスタンスを起動するときに次のパラメータを含めます。

-Djavax.servlet.sip.ar.dar.configuration

(プロパティ・ファイルを指定するには、URIではなく、file:///という接頭辞を含めます)。このJavaパラメータはコマンド・ラインで指定されるため、サーバー起動スクリプトに含めることができます。

デフォルト・アプリケーション・ルーターで使用されるルーティング情報の形式の詳細は、SIPサーブレット仕様v1.1(http://jcp.org/en/jsr/detail?id=289)の付録Cを参照してください。

Oracle WebLogic Server SIP Container DARでは、「発信」、「終了」、「ニュートラル」のほかにルート・リージョン文字列を受け入れます。新しい各文字列値は、拡張されたルート・リージョンとして扱われます。また、Oracle WebLogic Server SIP Container DARでは、構成ファイルのプロパティの順序を使用してルート・エントリ・シーケンスを判定します。state_info値は、DAR構成で指定される場合効果がありません。

5.3 カスタム・アプリケーション・ルーターの構成

デフォルトでは、Oracle WebLogic Server SIP Containerは、独自のDAR実装を使用します。

カスタム・アプリケーション・ルーターを開発する場合、ARの実装をドメイン・ホーム・ディレクトリの/approuterサブディレクトリに保存する必要があります。ARのサポートティング・ライブラリは、/approuter内の/libサブディレクトリに保存できます。(SipApplicationRouterの複数の実装があれば、どちらを使用するかを指定するには、起動時に-Djavax.servlet.sip.ar.spi.SipApplicationRouterProviderのオプションを使用します)。

注意:
クラスタ環境の場合、カスタムARはドメインの全体のエンジン層インスタンスにデプロイされます。同じドメインに別のAR実装がデプロイできません。

AR機能の詳細は、SIPサーブレット仕様v1.1(http://jcp.org/en/jsr/detail?id=289)の15項を参照してください。カスタムARを実装する方法の詳細は、SIPサーブレットv1.1 APIを参照してください。

5.4 セッション・キーに基づくリクエストのターゲット

SIPサーブレット・バージョン1.1の仕様では、初期リクエストを既存のSipApplicationSessionオブジェクトに関連付けるためのメカニズムも提供します。このメカニズムはセッション・キー・ベースのターゲットと呼ばれます。セッション・キー・ベースのターゲットを使用して、特定のサブスクライバ(リクエストURI)、地域またはその他の機能を持つ初期リクエストを、新しいセッションを生成することなく、既存のSipApplicationSessionに送ります。アプリケーションにおいてこのターゲットのメカニズムを使用するには、一意のキーを生成するメソッドを作成し、このメソッドに@SipApplicationKeyアノテーションを付けます。SIPコンテナがアプリケーションを選択する場合(たとえば、初期リクエストに対してARによって選択されたアプリケーション)、アノテーション付きのメソッドを使用してキーを取得します。そして、SipApplicationSessionが存在するかどうかを判別するには、キーおよびアプリケーション名を使用します。存在する場合、コンテナは、新しいセッションを生成ではなく、既存のセッションに新しいリクエストを関連付けます。

注意:
ターゲットのメカニズムを使用してスパイラル・プロキシ・アプリケーションを開発し、アプリケーションによって複数回にレコード・ルーターが変更される場合は、レコード・ルーター・ホップの実行時に、必要に応じて、初期リクエストに対して異なるキーが生成される必要があります。生成されない場合、アプリケーションは後続リクエスト用のレコード・ルーター・ホップを差別できません。

セッション・キー・ベースのターゲットの使用の詳細は、SIPサーブレット仕様v1.1(http://jcp.org/en/jsr/detail?id=289)の15項を参照してください。

6 SIPサーブレット・リソースのセキュリティ

この章では、Oracle WebLogic Server SIP Containerへのデプロイ時にSIPサーブレット・リソースにセキュリティ制約を適用する方法を説明します。内容は次のとおりです。

- 6.1項「SIPサーブレット・セキュリティの概要」

- 6.2項「SIPレスポンス・コードのトリガー」

- 6.3項「セキュリティ・レルムの指定」

- 6.4項「ロール・マッピング機能」

- 6.5項「暗黙的なロール割当ての使用」

- 6.6項「security-role-assignmentを使用したロールの割当て」

- 6.7項「run-asロールの割当て」

- 6.8項「SIPサーブレット・ロールのロール割当て優先順位」

- 6.9項「セキュリティ機能のデバッグ」

- 6.10項「weblogic.xmlデプロイメント記述子のリファレンス」

6.1 SIPサーブレット・セキュリティの概要

SIP Servlet API仕様では、SIPサーブレットの宣言型セキュリティおよびプログラムに基づくセキュリティの提供に使用できるデプロイメント記述子要素のセットを定義します。セキュリティ制約を宣言するための主要な方法は、sip.xmlデプロイメント記述子の中で1つまたは複数のsecurity-constraint要素を定義することです。security-constraint要素は保護対象であるresource-collectionの要素で定義されたSIPサーブレットで実際のリソースを定義します。security-constraintはリソースにアクセスするため公認されたロール名も識別します。security-constraint内で使用されるすべてのロール名は、sip.xmlのsecurity-role要素内の他の場所で定義されます。

SIPサーブレットでは、サーブレット・コード内でロール名をプログラム的に参照し、そのハード・コード化されたロール名をデプロイメント時にsip.xmlのsecurity-role-ref要素内で別のロールにマップすることもできます。security-role-ref要素内でハード・コード化された名前にマップしようとするロールは、security-role要素内の他の場所で定義しておく必要があります。

SIPサーブレット仕様によると、サーブレットではrun-as要素を使って呼出し先のEnterprise JavaBeans (EJB)にセキュリティ・ロールを伝播することもできます。run-as要素内で使用するロールは、sip.xmlの別個のsecurity-role要素内で定義する必要があります。

SIP Servlet API仕様の第14章には、SIPサーブレットで使用できるセキュリティのタイプに関して、さらに詳しい記述があります。SIPサーブレットのセキュリティ機能は、HTTPサーブレットで使用できるセキュリティ機能に似ています。Oracle WebLogic Server SIP Containerドキュメントの次の項には、HTTPサーブレットのセキュリティについての情報が記載されています。

- WebLogic Securityプログラマーズ・ガイドの「Webアプリケーションのセキュリティ対策」では、サーブレットの宣言によるセキュリティ・モデルとプログラムによるセキュリティ・モデルについて概説されています。

- 「Enterprise JavaBeans (EJB)のセキュリティ対策」のEJBのセキュリティ関連のデプロイメント記述子に関する項には、EJBのセキュリティ関連のデプロイメント記述子の全要素が記述されています。呼出し先のEJBにロールを伝播する際に使用するrun-as要素についても、ここで解説されています。

例6-1「sip.xml内の宣言によるセキュリティ制約」に示す、サンプルのsip.xmlの抜粋も参照してください。

6.2 SIPレスポンス・コードのトリガー

401 SIPレスポンス・コードまたは407 SIPレスポンス・コードのどちらか適切なSIPレスポンス・コードをトリガーするようコンテナを構成することで、プロキシ・アプリケーションかUASアプリケーションかを識別できます。招待をプロキシする必要がある場合は、407コードが適切です。レジストラ・アプリケーションの場合は、401コードを使用する必要があります。

401 SIPレスポンス・コードではなく407 SIPレスポンス・コードで応答するようコンテナを構成するには、セキュリティ制約に<proxy-authentication>要素を追加する必要があります。

6.3 セキュリティ・レルムの指定

sip.xmlファイル内の現在のセキュリティ・レルムの名前を、次のように指定する必要があります。

<login-config>
<auth-method>DIGEST</auth-method>
<realm-name>myrealm</realm-name>
</login-config>

6.4 ロール・マッピング機能

SIPサーブレットをデプロイするときは、宣言およびプログラムによるセキュリティとして作成したsecurity-role定義を、サーブレット・コンテナで使用できる実際のプリンシパルやロールに割り当てる必要があります。Oracle WebLogic Server SIP Containerでは実際のプリンシパルやロールにsecurity-role定義をマップする際にweblogic.xmlでsecurity-role-assignment要素を使用します。security-role-assignmentは後でロール割当てを変更する際に必要な柔軟性の程度によって、2通りのセキュリティ・ロールのマップ方法を備えています。

- security-role-assignment要素では、sip.xml内で定義されたロールにマップするプリンシパル名とロールのリストを定義できます。この方法ではロール割当てをデプロイメント時に定義しますが、柔軟性が犠牲になります。たとえばロールにプリンシパルを追加したり逆に削除したりするには、weblogic.xmlを編集して、SIPサーブレットを再デプロイする必要があります。

- security-role-assignment内でexternally-defined要素を使用する方法では、管理コンソールからいつでもプリンシパル名とロールをsip.xmlのロールに割り当てることができます。externally-defined要素を使用した場合、プリンシパルとロールをsip.xmlのロールに追加したり削除したりしてもSIPサーブレットを再デプロイする必要はありません。

さらに、sip.xmlのrun-as要素へのロールの割当てに使用できるXML要素が2つあります。それはrun-as-principal-nameとrun-as-role-assignmentです。これらのロール割当て要素を使用した場合は、security-role-assignment要素よりも優先されます。これについては、「run-asロールの割当て」で説明します。

また、weblogic.xml内でロール・マッピング要素を指定せずに、暗黙的なロール・マッピングを使用することもできます。これについては、「暗黙的なロール割当ての使用」で説明します。

この項では、Oracle WebLogic Server SIP Containerのロール割当てについて詳しく説明します。

6.5 暗黙的なロール割当ての使用

暗黙的なロール割当てを使用して、Oracle WebLogic Server SIP Containerはsip.xml内のsecurity-role名を同名のロールに割り当てます。このロールはOracle WebLogic Server SIP Containerセキュリティ・レルムで構成する必要があります。暗黙的なロール・マッピングを使用するには、weblogic.xmlでsecurity-role-assignment要素を省略します。run-asロールをマップするためのrun-as-principal-nameおよびrun-as-role-assignment要素も省略します。

weblogic.xml内に使用できるロール・マッピング要素がなければ、Oracle WebLogic Server SIP Containerはsip.xmlのsecurity-role要素を同名のロールに自動的にマップします。なお、暗黙的なロール・マッピングは、sip.xmlで定義されたロール名が実際にセキュリティ・レルムにあるかどうかに関係なく行われます。Oracle WebLogic Server SIP Containerで暗黙的なロール割当てが使用されるときは常に警告メッセージが表示されます。たとえば、sip.xmlで「everyone」ロールを使用し、weblogic.xmlでこのロールを明示的に割り当てなかった場合、次のような警告メッセージが表示されます。

<Webapp: ServletContext(id=id,name=application,context-path=/context), the role: everyone defined in web.xml has not been mapped to principals in security-role-assignment in weblogic.xml. Will use the rolename itself as the principal-name.>

対応するロールをOracle WebLogic Server SIP Containerセキュリティ・レルムで定義してあれば、この警告メッセージは無視できます。weblogic.xmlで明示的なロール・マッピングを定義すれば、このメッセージを無効にできます。

暗黙的なロール割当ては、デプロイメント時のロール・マッピングを既知のプリンシパル名にハード・コード化したい場合に使用してください。

6.6 security-role-assignmentを使用したロールの割当て

weblogic.xml内でsecurity-role-assignment要素を使用すると、ロールの割当てをデプロイメント時に行えるほか、管理コンソールでいつでも行えます。次の項で、それぞれのアプローチについて説明します。

6.6.1 重要な要件

weblogic.xml内でsecurity-role-assignment要素を指定する場合、Oracle WebLogic Server SIP Containerではweb.xmlデプロイメント記述子内でもsecurity-role要素を定義する必要があります。この要件は純粋なSIPサーブレットをデプロイする場合にも適用されます。通常、純粋なSIPサーブレットをデプロイする場合にはweb.xmlデプロイメント記述子は必要とされません(一般にHTTP Webアプリケーション用に確保されています)。

注意:
weblogic.xmlでsecurity-role-assignmentを指定する場合に、web.xml内に対応するsecurity-role要素がないと、Oracle WebLogic Server SIP Containerでは次のようなエラー・メッセージが表示されます

The security-role-assignment references an invalid security-role: rolename

「暗黙的なロール割当ての使用」で説明されているように、sip.xml内で定義されているsecurity-roleが同名のロールに自動的にマップされます。

例として、例6-1に、ロールroleadminでセキュリティ制約を定義するsip.xmlデプロイメント記述子の一部を示します。例6-2は、roleadminにプリンシパルとロールを割り当てるために、weblogic.xmlで定義されているsecurity-role-assignment要素を示します。Oracle WebLogic Server SIP Containerでは、このサーブレットを、roleadminロールも定義するweb.xmlデプロイメント記述子でデプロイする必要があります(例6-3を参照)。

web.xmlの内容が使用できない場合、Oracle WebLogic Server SIP Containerは暗黙的なロール割当てを使用し、セキュリティ・レルムでroleadminロールが定義されているものと見なします。その場合、weblogic.xmlで割り当てられたプリンシパルとロールは無視されます。

例6-1 sip.xml内の宣言によるセキュリティ制約

...
<security-constraint>
<resource-collection>
<resource-name>RegisterRequests</resource-name>
<servlet-name>registrar</servlet-name>
</resource-collection>
<auth-constraint>
<javaee:role-name>roleadmin</javaee:role-name>
</auth-constraint>
</security-constraint>

<security-role>
<javaee:role-name>roleadmin</javaee:role-name>
</security-role>
...

例6-2 weblogic.xml内のsecurity-role-assignmentの例

<weblogic-web-app>
<security-role-assignment>
<role-name>roleadmin</role-name>
<principal-name>Tanya</principal-name>
<principal-name>Fred</principal-name>
<principal-name>system</principal-name>
</security-role-assignment>
</weblogic-web-app>

例6-3 web.xmlに必須のsecurity-role要素

<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<security-role>
<role-name>roleadmin</role-name>
</security-role>
</web-app>

6.6.2 デプロイメント時のロールの割当て

weblogic.xml内の基本的なsecurity-role-assignment要素定義は、sip.xml内で定義されたsecurity-roleとOracle WebLogic Server SIP Containerセキュリティ・レルム内で使用できる1つまたは複数のプリンシパルやロールとの間でのマッピングを宣言します。security-roleをsip.xmlのrun-as要素と組み合せて使用した場合、Oracle WebLogic Server SIP Containerはsecurity-role-assignmentで指定された最初のプリンシパル名またはロール名をrun-asロールに割り当てます。

例6-2「weblogic.xml内のsecurity-role-assignmentの例」は、security-role-assignment要素の例を示しています。この例では、例6-3「sip.Xml内の宣言によるセキュリティ制約」で定義されているroleadminロールに3人のユーザーを割り当てています。このロール割当てを変更するには、weblogic.xml記述子を編集し、SIPサーブレットを再デプロイする必要があります。

6.6.3 管理コンソールを使用した動的なロールの割当て

<principal-name>要素のかわりにexternally-defined要素を使用すると、sip.xmlのrole-name要素で定義したセキュリティ・ロールに、管理コンソールで割り当てるマッピングを適用することを指定できます。externally-defined要素を使用すると、デプロイメント時にセキュリティ・ロールごとに特定のセキュリティ・ロール・マッピングを指定する必要がなくなります。この場合、管理コンソールを使って、いつでもロール割当てを指定したり変更したりできます。

なお、この要素を使用するかどうかの選択はSIPサーブレットによって違ってくるはずなので、セキュリティ・レルムに関してデプロイメント記述子のロールとポリシーを無視オプションを選択する必要はありません(このオプションの選択は、管理コンソールの「セキュリティ」>「レルム」>「myrealm」コントロール・パネルの「一般」タブの今後の再デプロイの設定:フィールドで行います)。したがって、同じセキュリティ・レルム内で、セキュリティの指定や変更の手段としてデプロイメント記述子と管理コンソールをアプリケーションに応じて使い分けることができます。

注意:
セキュリティ・ロール名を指定するときは、次の規約と制限に従ってください。

- セキュリティ・ロール名の正しい構文は、XML (Extensible Markup Language)推奨仕様でNmtokenに関して定義されているとおりです(http://www.w3.org/TR/REC-xml#NT-Nmtoken)。

- スペース、カンマ、ハイフン、\t、< >、#、|、&、~、?、( )、{ }を使用しないでください。

- セキュリティ・ロール名では大文字と小文字が区別されます。

- Oracleのネーミング・ルールではセキュリティ・ロール名は単数形です。

例6-4は、例6-1「sip.xml内の宣言によるセキュリティ制約」で定義されているroleadminロールでのexternally-defined要素の使用例を示しています。既存のプリンシパルとロールをroleadminロールに割り当てるには、Oracle WebLogic Server SIP Containerの管理コンソールを使用します。

例6-4 weblogic.xmlの外部で定義された要素のサンプル

<weblogic-web-app>
<security-role-assignment>
<role-name>webuser</role-name>
<externally-defined/>
</security-role-assignment>
</weblogic-web-app>

6.7 run-asロールの割当て

「security-role-assignmentを使用したロールの割当て」で説明したsecurity-role-assignmentは、sip.xml内で定義されたrun-asロールをマップするのにも使用できます。ただし、weblogic.xml内で使われる2つの要素はsecurity-role-assignmentよりも優先されます。この2つの要素とは、run-as-principal-nameとrun-as-role-assignmentです。

run-as-principal-nameでは、すべてのrun-asロール割当てに適用されるセキュリティ・レルム内の既存のプリンシパルを指定します。weblogic.xmlのservlet-descriptor要素内で定義する場合は、run-as-principal-nameがその他のrun-asロールのロール割当て要素より優先されます。

run-as-role-assignmentでは、すべてのrun-asロール割当てに適用されるセキュリティ・レルム内の既存のロールまたはプリンシパルを指定します。この要素はweblogic-web-app要素内で定義します。

weblogic.xmlの個々の要素の詳細は、「weblogic.xmlデプロイメント記述子リファレンス」を参照してください。run-asロール・マッピングならびに宣言およびプログラムによるセキュリティのロール・マッピング優先順位については、「SIPサーブレット・ロールのロール割当て優先順位」も参照してください。

6.8 SIPサーブレット・ロールのロール割当て優先順位

Oracle WebLogic Server SIP Containerでは、デプロイメント時にsip.xmlのロールをSIPコンテナ内の実際のロールにマップする方法が何通りかあります。sip.xml内で定義される宣言およびプログラムによるセキュリティに関しては、ロール割当ての優先順位は次のようになります。

1. weblogic.xmlのsecurity-role-assignment要素内でsip.xmlのロールを割り当てた場合は、そのsecurity-role-assignmentが使われます。

注意:
Oracle WebLogic Server SIP Containerでsecurity-role-assignmentを使用するには、web.xml内にロール定義が存在する必要があります。「重要な要件」を参照してください。

2. 使用できるsecurity-role-assignmentがない場合は(または必要なweb.xmlロール割当てがない場合)、暗黙的なロール割当てが使われます。

run-asロール割当てに関しては、ロール割当ての優先順位は次のようになります。

1. weblogic.xmlのservlet-descriptor内で定義したrun-as-principal-name要素内でsip.xmlのrun-asロールを割り当てた場合は、そのrun-as-principal-name割当てが使われます。

注意:
Oracle WebLogic Server SIP Containerでrun-as-principal-nameを使用してロールを割り当てるには、web.xml内にロール定義が存在する必要があります。「重要な要件」を参照してください。

2. weblogic.xmlのrun-as-role-assignment要素内でsip.xmlのrun-asロールを割り当てた場合は、そのrun-as-role-assignment要素が使われます。

注意:
Oracle WebLogic Server SIP Containerでrun-as-role-assignmentを使用してロールを割り当てるには、web.xml内にロール定義が存在する必要があります。「重要な要件」を参照してください。

3. weblogic.xmlがsecurity-role-assignment要素でsip.xml run-asロールを割り当てる場合は、security-role-assignmentを使用します。

注意:
Oracle WebLogic Server SIP Containerでsecurity-role-assignmentを使用するには、web.xml内にロール定義が存在する必要があります。「重要な要件」を参照してください。

4. 使用できるsecurity-role-assignmentがない場合は(または必要なweb.xmlロール割当てがない場合)、暗黙的なロール割当てが使われます。

6.9 セキュリティ機能のデバッグ

開発したSIPサーブレットのセキュリティ機能をデバッグする場合は、Oracle WebLogic Server SIP Containerの起動時に-Dweblogic.Debug=wlss.Security startupオプションを指定します。このデバッグ・オプションを使用すると、Oracle WebLogic Server SIP Containerでセキュリティ関連の追加のメッセージが標準出力に表示されるようになります。

6.10 weblogic.xmlデプロイメント記述子リファレンス

weblogic.xml DTDには、この項で説明したロール・マッピング要素に関する詳細情報が記載されています。

7 メッセージ・ロギングの有効化

この章では、開発システムでメッセージ ロギング機能を使用する方法について説明します。内容は次のとおりです。

- 7.1項「概要」

- 7.2項「メッセージ・ロギングの有効化」

- 7.3項「暗号化されていないロギングのコンテンツ・タイプの指定」

- 7.4項「メッセージ・ログ構成と出力の例」

- 7.5項「ログ・ファイル・ローテーションの構成」

7.1 概要

メッセージ・ロギングではOracle WebLogic Server SIP Containerが受信したSIPとDiameterメッセージ(リクエストとレスポンスの両方)が記録されます。これには、ロギング・レベルをINFOレベル以上に設定する必要があります。開発環境でメッセージ・ログを使用して、外部のSIPリクエストとSIPレスポンスがどのように受信されるかチェックできます。アプリケーション・ログからSIPダイアログの識別可能な情報(Call-IDなど)を出力し、メッセージ・ログから関連するSIPメッセージを抽出することにより、HTTPサーブレットなどからのSIP呼出しをチェックすることもできます。

メッセージ・ロギングを有効にすると、Oracle WebLogic Server SIP Containerによって、各エンジン層サーバー・インスタンスに関連付けられた管理対象サーバー・ログ・ファイルにメッセージ・ログ・レコードがデフォルトで記録されます。「ログ・ファイル・ローテーションの構成」に示しているように、必要に応じてメッセージを個別の専用のログ・ファイルに記録できます。

7.2 メッセージ・ロギングの有効化

メッセージ・ロギングの有効化と構成は、sipserver.xml構成ファイルにmessage-debug要素を追加することによって行います。Oracle WebLogic Server SIP Containerには、記録する情報を構成する方法が2通りあります。

- あらかじめ定義されているロギング・レベル(terse、basic、またはfull)を指定する

- 指定された順序で、ログ・レコードに含めたいSIPメッセージの正確な部分を識別する

次の項では、sipserver.xmlファイルで要素を使用して、各メソッドのメッセージ・ロギング機能の構成を説明します。SipServerコンソール拡張ノードの「構成」->「メッセージのデバッグ」タブで管理コンソールを使用してこれらの要素を設定できます。

7.2.1 あらかじめ定義されているロギング・レベルの指定

message-debug内のlevel要素(オプション)で、SIPの各リクエストとレスポンスについて記録する情報の定義済コレクションを指定します。次のレベルがサポートされています。

- terse(簡潔) - domain設定、ロギング・サーブレット名、ロギングlevelおよびメッセージが受信メッセージかどうかのみを記録します。

- basic - terseの項目に加えて、SIPメッセージのステータス、Reason-Phrase(説明句)、レスポンスまたはリクエストのタイプ、SIPメソッド、FromヘッダーおよびToヘッダーがログに記録されます。

- full - basicの項目に加え、すべてのSIPメッセージ・ヘッダー、タイム・スタンプ、プロトコル、リクエストURI、リクエスト・タイプ、レスポンス・タイプ、コンテンツ・タイプおよびrawコンテンツがログに記録されます。

例7-1は、fullロギング・レベルを指定する構成エントリです。

例7-1 sipserver.xmlでのメッセージ・ロギング・レベルの構成の例

<message-debug>
<level>full</level>
</message-debug>

7.2.2 ログ・レコードのカスタマイズ

Oracle WebLogic Server SIP Containerでは、各メッセージのログ・レコードの内容と順序をカスタマイズすることもできます。カスタム・ログ・レコードを構成するには、format要素を使って、ログ・レコードのpatternと各レコードに記録する1つまたは複数のtokenを定義する必要があります。

注意:
message-debug内にformat要素と<level>full</level>要素(または未定義のlevel要素)を一緒に指定すると、Oracle WebLogic Server SIP Containerはformatエントリを無視して「full」のメッセージ・デバッグを使用します。formatエントリは、message-debugの「terse」または「basic」レベルと組み合せて使用できます。

表7-1に、format要素内でネストして使用される要素を示します。

表7-1 ネストされるフォーマット要素

パラメータ名

パラメータ値の説明

pattern

メッセージ・ログ・エントリをフォーマットするため使用したパターンを指定します。このフォーマットは、1つまたは複数の整数を「{」と「}」で囲んで指定することにより定義されます。各整数は、format定義の中で後で指定されるtokenを表します。

token

ログ・レコードに含めるSIPメッセージの一部を識別する文字列トークン。表7-2では、利用可能な文字列トークンのリストを示します。必要に応じて複数のtoken要素を定義してログ・レコードをカスタマイズできます。

表7-2に、メッセージ・ログ・レコードに含める情報を指定するための文字列token値を示します。

表7-2 メッセージ・ログ・レコードに利用可能なトークン

トークン

説明

例またはタイプ

%call_id

Call-IDヘッダー。転送のときは空白。

43543543

%content

rawコンテンツ。

バイト配列

%content_length

コンテンツ長。

文字列値

%content_type

コンテンツ・タイプ。

文字列値

%cseq

CSeqヘッダー。転送のときは空白。

INVITE 1

%date

メッセージの受信日付。「yyyy/MM/dd」の形式。

2004/05/16

%from

Fromヘッダー(全部)。転送のときは空白。

sip:foo@oracle.com;tag=438943

%from_addr

Fromヘッダーのアドレス部分。

foo@oracle.com

%from_tag

Fromヘッダーのタグ・パラメータ。転送のときは空白。

12345

%from_uri

FromヘッダーのSIP URI部分。転送のときは空白。

sip:foo@oracle.com

%headers

2要素配列に格納されるメッセージ・ヘッダーのリスト。最初の要素はヘッダーの名前で、2番目の要素はヘッダーの全値のリストです。

ヘッダーのリスト

%io

メッセージが受信メッセージかどうか。

TRUE

%method

SIPメソッドの名前。転送時に呼び出すメソッド名を記録します。

INVITE

%msg

サマリーCall ID

文字列値

%mtype

受信のタイプ。

SIPREQ

%protocol

使用プロトコル。

UDP

%reason

レスポンス理由。

OK

%req_uri

リクエストURI。このトークンはSIPリクエストについてのみ有効です。

sip:foo@oracle.com

%status

レスポンス・ステータス。

200

%time

メッセージの受信時刻。「HH:mm:ss」の形式。

18:05:27

%timestampmillis

ミリ秒単位のタイム・スタンプ。

9295968296

%to

Toヘッダー(全部)。転送のときは空白。

sip:foo@oracle.com;tag=438943

%to_addr

Toヘッダーのアドレス部分。

foo@oracle.com

%to_tag

Toヘッダーのタグ・パラメータ。転送のときは空白。

12345

%to_uri

ToヘッダーのSIP URI部分。転送のときは空白。

sip:foo@oracle.com

2つのトークンを使ってカスタム・ログ・レコードを定義したサンプルのsipserver.xmlファイルについては、「メッセージ・ログ構成と出力の例」を参照してください。

7.3 暗号化されていないロギングのコンテンツ・タイプの指定

デフォルトでは、Oracle WebLogic Server SIP Containerは、テキストまたはapplication/sdpのContent-Type値を持つSIPメッセージのコンテンツをログするために、文字列フォーマット(UTF-8エンコーディング)を使用します。他のすべてのContent-Type値では、文字列セットが指定されている場合、Oracle WebLogic Server SIP Containerはメッセージのcharsetパラメータに指定した文字列セットを使用してメッセージのコンテンツをログします。charsetパラメータが指定されていない場合、またはcharset値が無効かサポートされていない場合、Oracle WebLogic Server SIP Containerは、メッセージをログする前にメッセージ・コンテンツを暗号化するためにBase-64エンコーディングを使用します。

こうした状況でメッセージのコンテンツの暗号化を回避するには、sipserver.xmlのstring-rep要素を使用してString-representable Content-Type値のリストを指定します。string-rep要素は1つまたは複数の一致するcontent-type要素を持つことができます。ログされたメッセージが構成されたcontent-type要素のいずれかに一致する場合、Oracle WebLogic Server SIP Containerはcharsetパラメータが含まれているか否かにかかわらず、UTF-8エンコーディングを使用して文字列フォーマットにコンテンツをログします。

注意:
text/*またはapplication/sdpのコンテンツ・タイプはデフォルトとして文字列フォーマットにログされているため、指定する必要はありません。

例7-2に、text/*およびapplication/sdpコンテンツに加え、追加の3つのContent-Type値に対して文字列コンテンツをログするmessage-debug構成をサンプルとして示します。

例7-2 追加のコンテンツ・タイプのロギング文字列コンテンツ

<message-debug>
<level>full</level>
<string-rep>
<content-type>application/msml+xml</content-type>
<content-type>application/media_control+xml</content-type>
<content-type>application/media_control</content-type>
</string-rep>
</message-debug>

7.4 メッセージ・ログ構成と出力の例

例7-3には、sipserver.xmlでのメッセージ・ログ構成の例を示します。例7-4「メッセージ・ログ出力の例」には、管理対象サーバーのログ・ファイルからの出力の例を示します。

例7-3 sipserver.xmlでのメッセージ・ログ構成の例

<message-debug>
<format>
<pattern>{0} {1}</pattern>
<token>%headers</token>
<token>%content</token>
</format>
</message-debug>

例7-4 メッセージ・ログ出力の例

####<Aug 10, 2005 7:12:08 PM PDT> <Info> <WLSS.Trace> <jiri.bea.com> <myserver> <ExecuteThread: '11' for queue: 'sip.transport.Default'> <<WLS Kernel>> <> <BEA- 331802> <SIP Tracer: logger Message: To: sut <sip:invite@10.32.5.230:5060> <mailto:sip:invite@10.32.5.230:5060>
Content-Length: 136
Contact: user:user@10.32.5.230:5061
CSeq: 1 INVITE
Call-ID: 59.3170.10.32.5.230@user.call.id
From: user <sip:user@10.32.5.230:5061> <mailto:sip:user@10.32.5.230:5061> ;tag=59
Via: SIP/2.0/UDP 10.32.5.230:5061
Content-Type: application/sdp
Subject: Performance Test
Max-Forwards: 70
v=0
o=user1 53655765 2353687637 IN IP4 127.0.0.1
s=-
c=IN IP4       127.0.0.1
t=0 0
m=audio 10000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
>
####<Aug 10, 2005 7:12:08 PM PDT> <Info> <WLSS.Trace> <jiri.bea.com> <myserver> <ExecuteThread: '11' for queue: 'sip.transport.Default'> <<WLS Kernel>> <> <BEA- 331802> <SIP Tracer: logger Message: To: sut <sip:invite@10.32.5.230:5060> <mailto:sip:invite@10.32.5.230:5060>
Content-Length: 0
CSeq: 1 INVITE
Call-ID: 59.3170.10.32.5.230@user.call.id
Via: SIP/2.0/UDP 10.32.5.230:5061
From: user <sip:user@10.32.5.230:5061> <mailto:sip:user@10.32.5.230:5061> ;tag=59
Server: Oracle WebLogic Communications Server 10.3.1.0
>

7.5 ログ・ファイル・ローテーションの構成

SIPとDiameterメッセージのメッセージ・ログ・エントリは、デフォルトではメインOracle WebLogic Server SIP Containerのログ・ファイルに格納されています。必要に応じて、専用のログ・ファイルにメッセージを格納できます。別々のファイルを使用すると、メッセージ・ログの場所を簡単に特定でき、しかも記録されたデータをより適切に管理できるよう、Oracle WebLogic Server SIP Containerのログ・ローテーション機能を使用できます。

ログ・ローテーションは、sipserver.xmlにあるメインのmessage-debug要素の中にネストされたいくつかの要素を使用して構成されます。この項で説明されている他のXML要素と同様に、SIP Server管理コンソール拡張の「構成」->「メッセージのデバッグ」タブを使用して値を構成できます。

表7-3では、各要素を説明しています。独立したロギングとログ・ローテーションを開始するためには、サーバーの再起動が必要です。

表7-3 ログ・ローテーション構成のXML要素

要素

説明

logging-enabled

メッセージ・デバッグのログ・メッセージの格納に個別のログ・ファイルを使用するかどうかを決定します。デフォルトでは、この要素はfalseに設定されており、メッセージは一般的なログ・ファイルに記録されます。

file-min-size

最小サイズ(KB)を構成し、その後サーバーがログ・メッセージを別のファイルに自動的にローテーションします。この値は、rotation-type要素がbySizeに設定されている時に使用します。

log-filename

メッセージを格納するためにログ・ファイル名を定義します。デフォルトでは、ログ・ファイルはdomain_home/servers/server_name/logsに格納されます。

rotation-type

古いログ・メッセージを別のファイルに移動するための基準を構成します。この要素には、以下のいずれかの値を取ります。

- bySize - このデフォルト設定は、指定されたfile-min-sizeに基づき、ログ・メッセージをローテーションします。

- byTime - この設定は、指定されたrotation-timeに基づき、ログ・メッセージをローテーションします。

- none - ログのローテーションを無効にします。

number-of-files-limited

サーバーがログのローテーション後に格納されたログ・ファイルの総数を制限するかどうかを指定します。デフォルトでは、この要素はfalseに設定されています。

file-count

number-of-files-limitedがtrueに設定された場合は、維持するログ・ファイルの最大数を構成します。

rotate-log-on-startup

サーバーがサーバーの起動時にログ・ファイルをローテーションするかどうかを決定します。

log-file-rotation-dir

ローテーションされたログ・ファイルを格納するディレクトリを構成します。デフォルトでは、アクティブなログ・ファイルとして、同一ディレクトリ内でローテーションされたログ・ファイルを格納します。

rotation-time

byTimeをログ・ローテーションの基準に使用する場合、ログ・ローテーションの起動時刻を構成します。

file-time-span

間隔を時間単位で指定してからログ・ファイルをローテーションします。この値は、rotation-type要素がbyTimeに設定されている場合に使用します。

date-format-pattern

ログ・ファイル・エントリで日付の設定に使用するパターンを指定します。要素の値はjava.text.SimpleDateFormatクラスに準拠する必要があります。

例7-5に、ログ・ローテーションを使用するmessage-debug構成の例を示します。

例7-5 ログ・ローテーション構成の例

<?xml version='1.0' encoding='UTF-8'?>
<sip-server xmlns="http://www.bea.com/ns/wlcp/wlss/300" xmlns:sec="http://www.bea.com/ns/weblogic/90/security" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:wls="http://www.bea.com/ns/weblogic/90/security/wls">
<message-debug>
<logging-enabled>true</logging-enabled>
<file-min-size>500</file-min-size>
<log-filename>sip-messages.log</log-filename>
<rotation-type>byTime</rotation-type>
<number-of-files-limited>true</number-of-files-limited>
<file-count>5</file-count>
<rotate-log-on-startup>false</rotate-log-on-startup>
<log-file-rotation-dir>old_logs</log-file-rotation-dir>
<rotation-time>00:00</rotation-time>
<file-time-span>20</file-time-span>
<date-format-pattern>MMM d, yyyy h:mm a z</date-format-pattern>
</message-debug>
</sip-server>

第III部

Diameterの使用

ここでは、Diameterを使用したアプリケーション開発について説明します。Diameterは、属性値ペア(AVP)の配信を行うピア・ツー・ピア・プロトコルです。Diameterメッセージには、1つのヘッダーと1つまたは複数のAVPが含まれています。各メッセージ内のAVPのコレクションはDiameterアプリケーションの種類によって決まります。また、Diameterプロトコルは、コマンドやAVPを新しく追加することで拡張することもできます。Diameterは、複数のピアがそれぞれの処理能力を相互に比較することを可能にし、それによりセッション処理機能およびアカウンティング機能のルールを定義します。

Oracle WebLogic Server SIP Containerには、RFC 3588(http://www.ietf.org/rfc/rfc3588.txt)に説明されている中核機能およびアカウンティング機能をサポートする、Diameter基本プロトコルの実装が含まれています。Oracle WebLogic Server SIP Containerは、Diameterの基本機能を使用して、このドキュメントに後述されているSh、Rf、Roなどの複数のDiameterアプリケーションを実装します。

また、Diameter基本プロトコルを使用して、クライアントやサーバー側のDiameterアプリケーションを追加で実装することもできます。Diameter基本APIはサーブレットに似た単純なプログラミング・モデルを提供します。これにより、コンバージド・アプリケーション内でDiameter機能とSIPまたはHTTP機能を組み合せることが可能になります。

第VI部は、次の章で構成されます。

- 第8章「Diameter基本プロトコルAPIの使用」

- 第9章「プロファイル・サービスAPIの使用」

- 第10章「カスタム・プロファイル・サービス・プロバイダの開発」

- 第11章「オフライン・チャージング用のDiameter RfインタフェースAPIの使用」

- 第12章「オンライン・チャージング用のDiameter RoインタフェースAPIの使用」

8 Diameter基本プロトコルAPIの使用

この章では、Oracle WebLogic Server SIP Container Diameter基本プロトコル実装を使用して独自のDiameterアプリケーションを作成する方法の概要を説明します。内容は次のとおりです。

- 8.1項「Diameterプロトコル・パッケージ」

- 8.2項「Diameter APIの概要」

- 8.3項「Diameterノードの設定」

- 8.4項「Diameterアプリケーションの実装」

- 8.5項「Diameterセッションの設定」

- 8.6項「Diameterメッセージの設定」

- 8.7項「AVPの設定」

- 8.8項「コンバージドDiameterとSIPアプリケーションの作成」

8.1 Diameterプロトコル・パッケージ

以下の項では、クライアントおよびサーバー側のDiameterアプリケーションを開発するために使用するDiameter基本プロトコル・パッケージ、クラス、プログラミング・モデルの概要について説明します。また、付属しているDiameterプロトコル・アプリケーションのSIPサーブレット内での使用に関する情報は、以下の項を参照してください。

- 第9章「プロファイル・サービスAPIの使用」には、Diameter Shアプリケーションを使用してサブスクライバのプロファイル・データにアクセスし、管理する方法が記載されています。

- 第11章「オフライン・チャージング用のDiameter RfインタフェースAPIの使用」には、Diameter Rfアプリケーションを使用してオフライン・チャージング・リクエストを発行する方法が記載されています。

- 第12章「オンライン・チャージング用のDiameter RoインタフェースAPIの使用」には、Diameter Roアプリケーションを使用してオンライン・チャージングを実行する方法が記載されています。

8.2 Diameter APIの概要

Diameter基本プロトコルAPI内のすべてのクラスは、ルートのcom.bea.wcp.diameterパッケージに格納されます。表8-1では、このパッケージ内の主なクラス、インタフェースおよび例外について説明します。

表8-1 Diameter基本プロトコルAPIの主要な要素

カテゴリ

要素

説明

Diameterノード

Node

Diameterノード実装を表すクラス。Diameterノードは、クライアント・ベースまたはサーバー・ベースのDiameterアプリケーションおよびDiameterリレー・エージェントを表します。

Diameterアプリケーション

Application、ClientApplication

基本的なDiameterアプリケーションを表すクラス。宛先ホストやレルムの指定などのような、クライアント固有の機能の場合は、ClientApplicationでApplicationを拡張します。すべてのDiameterアプリケーションは、これらのクラスのうちの1つを拡張してアプリケーション識別子を返す必要があります。また、新しいDiameterセッションを作成するために、これらのクラスを直接使用することもできます。

ApplicationId

DiameterアプリケーションIDを表すクラス。Diameterプロトコルでは、このIDを使用してメッセージが適切なアプリケーションにルーティングされます。ApplicationIdは、Diameterメッセージに含まれるAuth-Application-Id、Acct-Application-Id、Vendor-Specific-Application-Id AVPのいずれかに相当します。

Session

Diameterセッションを表すクラス。セッション・ベースの処理を実行するアプリケーションでは、リクエストと応答メッセージを管理するためのアプリケーション固有の動作を提供する目的でこのクラスを拡張する必要があります。

メッセージ処理

Message、Request、Answer

Messageクラスは、リクエストおよび応答メッセージのタイプを表すために使用するベース・クラスです。RequestおよびAnswerはベース・クラスを拡張します。

Command

Diameterコマンド・コードを表すクラス。

RAR、RAA

これらのクラスは、RequestおよびAnswerクラスを拡張し、再認証メッセージを表します。

ResultCode

Diameter結果コードを表すクラス。Diameter基本プロトコルの結果コードのための定数値を提供します。

AVPの処理

Attribute

Diameterの属性情報を提供するクラス。

Avp、AvpList

メッセージ内の1つまたは複数の属性値ペアを表すクラス。AvpListは、グループ化されたAVPに含まれるAVPを表すのにも使用します。

Type

サポート対象のAVPデータ型を定義するクラス。

エラー処理

DiameterException

Diameter例外の基本例外クラス。

MessageException

無効なDiameterメッセージが検出された場合に発生する例外。

AvpException

無効なAVPメッセージが検出された場合に発生する例外。

インタフェースのサポート

Enumerated

このインタフェースを実装するenum値は、INTEGER32、INTEGER64またはENUMERATED型のAVP値として使用できます。

SessionListener

Diameterセッションに配信されるメッセージにサブスクライブするためにアプリケーションに実装できるインタフェース。

MessageFactory

受信したメッセージについてデフォルトのメッセージ・レコーダをオーバーライドし、新しいタイプのRequestおよびAnswerオブジェクトをアプリケーションが作成できるようにするインタフェース。

デフォルトのデコーディング処理は、MessageFactoryのインスタンスを使用して、メッセージ・バイトからメッセージ・ヘッダーをデコードすることから開始されます。これは、メッセージ・ヘッダーが無効な場合は早期のエラー・メッセージを生成できるようにするためです。実際のメッセージAVPは、別の手順でdecodeAvpsを呼び出してデコードされます。validateを呼び出すことにより、AVP値を完全にデコードします。その後、メッセージ内の部分的にデコードされた各AVPについてvalidateAvpを呼び出します。

これらの基本のDiameterクラスに加え、com.bea.wcp.diameter.accountingパッケージ内にアカウンティング関連のクラスが、com.bea.wcp.diameter.cc内にクレジット管理関連のクラスが、それぞれ格納されています。これらのパッケージ内のクラスの詳細は、第11章「オンライン・チャージング用のDiameter RfインタフェースAPIの使用」と第12章「オフライン・チャージング用のDiameter RoインタフェースAPIの使用」を参照してください。

8.2.1 Diameter APIを使用してアプリケーションをコンパイルするのに必要なファイル

次のjarファイルは、公開されるDiameter APIの一部です。このAPIに対してコンパイルを実行するには、次の場所のファイルにアクセスします。

wlssdiameter.jarファイルはMIDDLEWARE_HOME/server/lib/wlss/にあります。

8.3 Diameterノードの設定

Diameterノードは、com.bea.wcp.diameter.Nodeクラスで表します。Diameterノードは、diameter.xmlファイル内の構成に従って、1つまたは複数のDiameterアプリケーションをホストすることが可能です。Diameterアプリケーションにアクセスするには、デプロイされたアプリケーション(SIPサーブレットなど)がDiameterノード・インスタンスを取得して、アプリケーションをリクエストする必要があります。例8-1は、Rfアプリケーションへのアクセスに使用されるコードのサンプルを表したものです。

例8-1 Diameterノードとアプリケーションへのアクセス

ServletContext sc = getServletConfig().getServletContext();
Node node = sc.getAttribute("com.bea.wcp.diameter.Node");
RfApplication rfApp = (RfApplication) node.getApplication(Charging.RF_APPLICATION_ID);

Diameterノードは、通常、Oracle WebLogic Server SIP Containerインスタンスの一部として構成し、起動します。ただし、開発やテストのために、Diameterノードを単独の処理として実行することもできます。これを行うには、次の操作を行います。

1. 次のように、ドメインの環境を設定します。

cd ~/bea/user_projects/domains/diameter/bin
. ./setDomainEnv.sh

2. 起動するノードのdiameter.xml構成ファイルを検索します。

cd ../config/custom

3. 使用するdiameter.xml構成ファイルを指定して、Diameterノードを起動します。

java com.bea.wcp.diameter.Node diameter.xml

8.4 Diameterアプリケーションの実装

すべてのDiameterアプリケーションについて、基本Applicationクラス(クライアント・アプリケーションの場合にはClientApplicationクラス)を拡張する必要があります。Diameterアプリケーションを作成するためのモデルは、次の方法でサーブレットを実装する場合のモデルと似ています。

- Diameterアプリケーションにより、初期化のためのinit()メソッドがオーバーライドされます。

- diameter.xml内でアプリケーションに対して構成されている初期化パラメータが、アプリケーションに対して使用可能になります。

- セッション・ファクトリの使用により、新しいアプリケーション・セッションが生成されます。

適切なアプリケーションIDを返すには、DiameterアプリケーションでgetId()メソッドも実行する必要があります。このIDは、Diameterメッセージを正しいアプリケーションに通信するために使用されます。

必要に応じて、rcvRequest()またはrcvAnswer()を実装できます。デフォルトでは、rcvRequest()はUNABLE_TO_COMPLYという応答を返し、rcvRequest()は、Diameterメッセージを削除します。

例8-2は、セッションを使用しない単純なDiameterクライアント・アプリケーションを表したものです。

例8-2 単純なDiameterアプリケーション

public class TestApplication extends ClientApplication {
protected void init() {
log("Test application initialized.");
}
public ApplicationId getId() {
return ApplicationId.BASE_ACCOUNTING;
}
public void rcvRequest(Request req) throws IOException {
log("Got request: " + req.getHopByHopId());
req.createAnswer(ResultCode.SUCCESS).send();
}
}

8.5 Diameterセッションの設定

セッション・ベースの処理を実行するアプリケーションでは、基本Sessionクラスを拡張して、リクエストを管理し、メッセージに応答するためのアプリケーション固有の動作を提供する必要があります。基本Sessionクラスを拡張する場合は、rcvRequest()またはrcvAnswer()を実装する必要があり、両方のメソッドを実装することも可能です。

基本Applicationクラスを使用して新しいSessionオブジェクトを生成します。セッションの作成後、すべてのセッション関連のメッセージがSessionオブジェクトに直接に配信されます。Oracle WebLogic Server SIP Containerコンテナが、自動でセッションIDを生成し、各メッセージにIDをエンコードします。セッション属性は、SipApplicationSession内の属性とほとんど同じ方法でサポートされます。

例8-3は、単純なDiameterセッションの実装を表したものです。

例8-3 単純なDiameterセッション

public class TestSession extends Session {
public TestSession(TestApplication app) {
super(app);
}
public void rcvRequest(Request req) throws IOException {
getApplication().log("rcvReuest: " + req.getHopByHopId());
req.createAnswer(ResultCode.SUCCESS).send();
}
}

サンプルのSessionクラスを使用するには、例8-2のTestApplicationに次のようなファクトリ・メソッドを追加する必要があります。

public class TestApplication extends Application {
...
public TestSession createSession() {
return new TestSession(this);
}
}

この後、TestSessionを使用して新しいリクエストを次のように作成できます。

TestSession session = testApp.createSession();
Request req = session.creatRequest();
req.sent();

応答はSessionオブジェクトに直接配信されます。

8.6 Diameterメッセージの設定

基本Messageクラスは、リクエストと応答のいずれのメッセージ・タイプに対しても使用します。メッセージにはアプリケーションIDが常に含まれていて、必要に応じてセッションIDが含まれています。デフォルトでは、メッセージは次の方法で処理されます。

1. メッセージ・バイトを解析します。

2. アプリケーションIDおよびセッションIDの値を確認します。

3. 以下のルールに従って、メッセージを対応するセッションまたはアプリケーションに配信します。

1. Session-Id AVPが存在する場合は、関連セッションを検索し、セッションのrcvMessage()メソッドを呼び出します。

2. Session-Id AVPが存在しない場合、またはセッションが見つからない場合は、DiameterアプリケーションのrcvMessage()メソッドを呼び出します。

3. アプリケーションが見つからない場合は、UNABLE_TO_DELIVERレスポンスを生成します。

メッセージのタイプはDiameterコマンド・コードから特定します。RAR、RAA、ACR、ACA、CCR、CCAなどのような特別なメッセージ・タイプは、便宜上、Messageオブジェクトにgetterおよびsetterメソッドを含みます。

8.6.1 リクエスト・メッセージの送信

SessionまたはApplicationはいずれも、リクエスト・メッセージを送信および受信できます。リクエストは、createRequest()メソッドを使用して生成します。新規のリクエスト・メッセージについては、コマンド・コードを提供する必要があります。ルーティング用に、通常は、送信元のセッションまたはアプリケーションによって宛先ホストまたは宛先レルムAVPが設定されます。

受信した応答は、Request.getAnswer()で取得できます。応答の受信後、getSession()を使用して関連セッションIDを取得し、getResultCode()で結果を判定できます。また、Answer.getRequest()を使用して、オリジナルのリクエスト・メッセージを取得することもできます。

リクエストは、非同期ではsend()メソッドを使用して、同期ではブロッキングsendAndWait()メソッドを使用して送信できます。非同期で送信されたリクエストに対する応答は、送信元のセッションまたはアプリケーションに配信されます。リクエスト・タイムアウト値はメッセージの送信時に指定するか、またはdiameter.xml内のグローバルrequest-timeout構成要素を使用できます。応答を配信する前にタイムアウト値に達した場合、UNABLE_TO_DELIVER結果コードが生成されます。配信された応答上のgetResultCode()によって結果コードが返されます。

8.6.2 応答メッセージの送信

新規の応答メッセージは、createAnswer()を使用してRequestオブジェクトから生成されます。生成された応答はすべて、ResultCodeと、必要に応じてError-Message AVP値を指定します。ResultCodeクラスは、使用可能な事前定義済のコードを含みます。

応答は常にsend()メソッドで配信されます。これは、常に非同期(非ブロッキング)です。

8.6.3 新しいコマンド・コードの作成

Diameterコマンド・コードはメッセージのタイプを特定します。たとえば、リクエスト・メッセージを送信する場合、コマンド・コードを指定する必要があります。

Commandクラスは、Diameter基本プロトコルのための事前定義済のコマンド・コードを表します。このクラスを使用して、新しいコマンド・コードを作成できます。コマンド・コードは、コード自体に基づく共通のネームスペースを共有します。

次のようにして、define()メソッドでコードを定義できます。

static final Command TCA = Command.define(1234, "Test-Request", true, true);

define()メソッドは新しいコマンドを登録するか、すでにそのコマンドが定義済の場合はそのコマンド定義を返します。コマンドは、参照型等価演算子(==)を使用して比較できます。

8.7 AVPの設定

属性値ペア(AVP)は、Diameterメッセージに関連する情報をカプセル化する方法です。AVPはDiameter基本プロトコル、DiameterアプリケーションまたはDiameterを使用する上位レベルのアプリケーションで使用されます。

AVPクラスは、Diameter属性値のペアを表します。次のように新しいAVPを属性値とともに作成できます。

Avp avp = new Avp(Attribute.ERROR_MESSAGE, "Bad request");

また、以下のように、属性名を直接指定することもできます。

Avp avp = new Avp("Error-Message", "Bad request");

指定する値は、指定した属性タイプに対して有効である必要があります。

グループにまとめたAVPを作成するには、次のようにAvpListクラスを使用します。

AvpList avps = new AvpList();
avps.add(new Avp("Event-Timestamp", 1234));
avps.add(new Avp("Vendor-Id", 1111));

8.7.1 新しい属性の作成

Diameterアプリケーションを拡張する新しい属性を作成できます。AttributeクラスはAVP属性を表し、AVPコード、名前、フラグ、ベンダID(オプション)および属性タイプを含みます。また、このクラスは、定義済の属性のレジストリも保持します。すべての属性は、属性コードおよびベンダーIDに基づく共通のネームスペースを共有します。

次のようにして、define()メソッドで新しい属性を定義できます。

static final Attribute TEST = Attribute.define(1234, "Test-Attribute", 0, Attribute.FLAG_MANDATORY, Type.INTEGER32);

表8-1には、使用可能な属性タイプと、それらがJavaタイプへマップされる方法が記載されています。

define()メソッドは新しい属性を登録するか、すでにその属性が定義済の場合はその定義を返します。属性は、参照型等価演算子(==)を使用して比較できます。

表8-2 属性タイプ

Diameterタイプ

タイプ定数

Java型

Integer32

Type.INTEGER32

Integer

Integer64

Type.INTEGER64

Long

Float32

Type.FLOAT32

Float

OctetString

Type.BYTES

ByteBuffer(読取り専用)

UTF8String

Type.STRING

String

Address

Type.ADDRESS

InetAddress

Grouped

Type.GROUPED

AvpList

8.8 コンバージドDiameterとSIPアプリケーションの作成

Diameter APIにより、SIPおよびDiameter機能の両方を利用するコンバージド・アプリケーションを作成できます。例8-4に示されているように、SIPサーブレットはDiameterノード経由して使用可能なDiameterアプリケーションにアクセスできます。

例8-4 SIPサーブレットからRfアプリケーションへのアクセス

ServletContext sc = getServletConfig().getServletContext();
Node node = (Node) sc.getAttribute("com.bea.wcp.diameter.Node");
RfApplication rfApp = (RfApplication) node.getApplication(Charging.RF_APPLICATION_ID);

SIPはコールID (SIP-Call-IDヘッダー)を使用して2ユーザー間の特定のコール・セッションを識別します。Oracle WebLogic Server SIP ContainerはSIPコールIDをDiameterセッションIDにエンコードして、Diameterセッションを現在のアクティブな呼出し状態に自動的にリンクします。Diameterメッセージを受信すると、コンテナは関連付けられた呼出し状態を自動的に取得し、Diameterセッションを検索します。Diameterセッションはシリアライズ可能であるため、セッションを属性として(または、その反対に属性をセッションとして)SipApplicationSessionオブジェクトに格納できます。

コンバージド・アプリケーションでは、セッションがDiameterメッセージを受信した際、Diameter SessionListenerインタフェースを使用して通知を受信できます。SessionListenerインタフェースで単一なメソッドrcvMessage()が定義されます。例8-5は、実装方法の例を示します。

例8-5 SessionListenerの実装

Session session = app.createSession();
session.setListener(new SessionListener() {
public void rcvMessage(Message msg) {
if (msg.isRequest()) System.out.println("Got request!");
}
});

注意:
SessionListenerの実装は、分散型アプリケーションの場合はシリアライズ可能である必要があります。

9 プロファイル・サービスAPIの使用

この章では、アプリケーションで、Oracle WebLogic ServerのDiameterプロトコル実装に基づいてDiameter Shプロファイル・サービスおよびプロファイル・サービスAPIを使用する方法について説明します。内容は次のとおりです。

- 9.1項「プロファイル・サービスAPIおよびShインタフェースのサポートの概要」

- 9.2項「Shインタフェース・プロバイダの有効化」

- 9.3項「プロファイル・サービスAPIの概要」

- 9.4項「アプリケーション管理下のプロファイル・データに関するドキュメント・セレクタ・キーの作成」

- 9.5項「作成されたドキュメント・キーによるプロファイル・データ管理」

- 9.6項「ProfileListenerによるプロファイル・データのモニター」

9.1 プロファイル・サービスAPIおよびShインタフェースのサポートの概要

IMS仕様では、Shプロファイル・サービスを、アプリケーション・サーバー(AS)の機能とHome Subscriber Server (HSS)の間、または複数のIMSアプリケーション・サーバーの間の通信手段として定義しています。アプリケーション・サーバーは基本的にShプロファイル・サービスを次の2つの目的で使用します。

- HSSに格納されているユーザーのデータの問合せまたは更新のため

- HSS上のユーザーのデータが変更されたときに通知をサブスクライブして受信するため

アプリケーション・サーバーから使用できるユーザー・データには、アプリケーション・サーバー上のサービスによって定義されるもの(リポジトリ・データ)と、HSS上で管理されているユーザーのIMSプロファイル・データのサブセットがあります。Shインタフェースの仕様3GPP TS 29.328は、Shを通じて問合せの実行や更新ができるIMSプロファイル・データを定義します。Shプロファイル・サービスからアクセス可能なすべてのユーザー・データは、3GPP TS 29.328で定義されたスキーマを持つXMLドキュメントとして示されます。

IMSのShプロファイル・サービスは、Oracle WebLogic Server SIP ContainerのDiameterベース・プロトコルをサポートするプロバイダとして実装されています。このプロバイダは、Shアプリケーション仕様で定義されているDiameterコマンド・コードの透過的な生成と応答を行います。より高レベルのプロファイル・サービスAPIを使用すると、SIPサーブレットでXMLドキュメント・オブジェクト・モデル(DOM)を使ってユーザー・プロファイル・データをXMLドキュメントとして管理できます。変更されたプロファイル・データに関するサブスクリプションと通知を管理するには、SIPサーブレット内でプロファイル・リスナー・インタフェースを実装します。

図9-1 プロファイル・サービスAPIとShプロバイダの実装

「図9-1 プロファイル・サービスAPIとプロバイダの実装」の説明

Oracle WebLogic Server SIP Containerには、Diameter Shプロファイル・サービスのプロバイダが含まれます。今後のリリースでは、IMS仕様で定義された追加のインタフェースをサポートするために、いくつかのプロバイダが提供される可能性があります。このプロファイル・サービスAPIを使用するアプリケーションは、新しいプロバイダが使用可能になったときに、そのプロバイダを使用できます。

9.2 Shインタフェース・プロバイダの有効化

Diameterサポートの設定方法については、ネットワーク・リソースの構成のDiameter Shクライアント・ノードとリレー・エージェントの構成に関する項を参照してください。

9.3 プロファイル・サービスAPIの概要

Oracle WebLogic Server SIP Containerには、SIPサーブレットからサブスクライバのプロファイル・データを問合せまたは変更したり、変更されたプロファイル・データについて通知を受信するようにサブスクリプションを管理したりするときに使用できる、単純なプロファイル・サービスAPIが用意されています。このAPIを使用すると、SIPサーブレットからShプロバイダ・アプリケーションを通じて明示的にユーザー・プロファイル・ドキュメントをリクエストできます。ShプロバイダはXMLドキュメントを返し、SIPサーブレットは標準的なDOMテクニックを使って、このローカル・ドキュメント内のプロファイル・データを読み取ったり変更したりできます。ローカル・ドキュメントに加えた変更は、「put」操作後にHSSに反映されます。

9.4 アプリケーション管理下のプロファイル・データに関するドキュメント・セレクタ・キーの作成

ドキュメント・セレクタ・キーは、Diameterインタフェースを通じて取得するXMLドキュメントを識別し、protocol://uri/reference_type[/access_key]という形式を使用します。プロファイル・データを管理するサーブレットは、ドキュメント・セレクタ・キーを使用してプロファイル・サービスからSh XMLドキュメントを明示的に取得した後で、DOMを使用してこのドキュメントを処理します。

セレクタのprotocolの部分は、ドキュメントの取得に使用するDiameterインタフェース・プロバイダを識別します。Sh XMLドキュメントには、sh://プロトコルの指定が必要です。

Shドキュメント・セレクタの場合、2番目の要素uriは、通常はプロファイル・データが取得されるユーザーのUser-IdentityまたはPublic-Identityに対応します。LocationInformationまたはUserStateタイプのShデータ参照をリクエストする場合は、目的のユーザーのUser-IdentityまたはMSISDNをURI値に指定できます。

表9-2に、リクエストできるShデータ参照のタイプと、その際に指定するURI値を示します。使用可能なデータ参照と関連する参照タイプの詳細は、3GPP TS 29.328を参照してください。

表9-1 Shデータ参照で使用できるURI値

Shデータ参照番号

データ参照タイプ

ドキュメント・セレクタに指定するURI値

0

RepositoryData

User-IdentityまたはPublic-Identity

10

IMSPublicIdentity

11

IMSUserState

12

S-CSCFName

13

InitialFilterCriteria

14

LocationInformation

User-IdentityまたはMSISDN

15

UserState

17

Charging information

User-IdentityまたはPublic-Identity

17

MSISDN

ドキュメント・セレクタの最後の要素reference_typeは、リクエストするデータ参照のタイプを指定します。一部のデータ参照リクエストでは、uriとreference_typeだけを指定します。その他に、アクセス・キーを使用するShリクエストもあります。その場合は、ドキュメント・セレクタ・キーの3番目の要素として、ドキュメント・セレクタ・キー内で定義されているAttribute-Value Pair (AVP)の値を指定します。

表9-2は、各タイプのShデータ参照リクエストで必要なドキュメント・セレクタ・キー要素を示しています。

表9-2 Shデータ参照リクエストで使用するドキュメント・セレクタ要素のまとめ

データ参照タイプ

必要なドキュメント・セレクタ要素

ドキュメント・セレクタの例

RepositoryData

sh://uri/reference_type/Service-Indication

sh://sip:user@oracle.com/RepositoryData/Call Screening/

IMSPublicIdentity

sh://uri/reference_type/[Identity-Set]

Identity-Setには次のいずれかを指定します。

- All-Identities

- Registered-Identities

- Implicit-Identities

sh://sip:user@oracle.com/IMSPublicIdentity/Registered-Identities

IMSUserState

sh://uri/reference_type

sh://sip:user@oracle.com/IMSUserState/

S-CSCFName

sh://uri/reference_type

sh://sip:user@oracle.com/S-CSCFName/

InitialFilterCriteria

sh://uri/reference_type/Server-Name

sh://sip:user@oracle.com/InitialFilterCriteria/www.oracle.com/

LocationInformation

sh://uri/reference_type/(CS-Domain | PS-Domain)

sh://sip:user@oracle.com/LocationInformation/CS-Domain/

UserState

sh://uri/reference_type/(CS-Domain | PS-Domain)

sh://sip:user@oracle.com/UserState/PS-Domain/

Charging information

sh://uri/reference_type

sh://sip:user@oracle.com/Charging information/

MSISDN

sh://uri/reference_type

sh://sip:user@oracle.com/MSISDN/

9.5 作成されたドキュメント・キーによるプロファイル・データ管理

Oracle WebLogic Server SIP Containerには、プロファイル・データ・ドキュメントを簡単に取得するためのcom.bea.wcp.profile.ProfileServiceというヘルパー・クラスがあります。getDocument()メソッドは、作成されたドキュメント・キーを受け取り、読取り専用のorg.w3c.dom.Documentオブジェクトを返します。ドキュメントを変更するには、コピーを作成して編集した後で、変更後のドキュメントとキーを引数としてputDocument()メソッドに渡します。

注意:
getDocument()の実行時にOracle WebLogic Server SIP Containerインスタンス上でDiameter Shクライアント・ノード・サービスが使用可能になっていないと、プロファイル・サービスから「No registered provider for protocol」という例外がスローされます。

Oracle WebLogic Server SIP Containerは、サービス・メソッドの呼出しの間、プロファイル・サービスから返されたドキュメントをキャッシュします(たとえば、doRequest()メソッドを呼び出した場合)。サービス・メソッドが同じプロファイル・ドキュメントを何度もリクエストする場合は、後続のリクエストはキャッシュから提供され、HSSを再度問い合せません。

例9-1は、プロファイル・データを取得して変更するSIPサーブレットのサンプルを示しています。

例9-1 Profileserviceを使用してユーザー・プロファイル・データの取得と書込みを行うサンプル・サーブレット

package demo;
import com.bea.wcp.profile.*;
import javax.servlet.sip.SipServletRequest;
import javax.servlet.sip.SipServlet;
import org.w3c.dom.Document;
import java.io.IOException;
public class MyServlet extends SipServlet {
private ProfileService psvc;
public void init() {
psvc = (ProfileService) getServletContext().getAttribute(ProfileService.PROFILE_SERVICE);
}
protected void doInvite(SipServletRequest req) throws IOException {
String docSel = "sh://" + req.getTo() + "/IMSUserState/";
// Obtain and change a profile document.
Document doc = psvc.getDocument(docSel); // Document is read only.
Document docCopy = (Document) doc.cloneNode(true);
// Modify the copy using DOM.
psvc.putDocument(docSel, docCopy); // Apply the changes.
}
}

9.6 ProfileListenerによるプロファイル・データのモニター

IMS Shインタフェースにより、アプリケーションはサブスクライバのプロファイル・データが変更されたときに通知を自動的に受信できます。Oracle WebLogic Server SIP Containerには、プロファイル・データのサブスクリプションを管理するための便利なAPIが用意されています。SIPサーブレットで通知を受信するには、com.bea.wcp.profile.ProfileListenerインタフェースを実装します。このインタフェースは1つのupdateメソッドから成り、サーブレットをサブスクライブしているプロファイルに変更が生じると、このメソッドが自動的に呼び出されます。同じサーブレットからプロファイル情報を変更した場合には、通知は送信されません(たとえばユーザーが自分でプロファイル・データを変更した場合など)。

注意:
レプリケートされた環境では、Diameterリレー・ノードは、プロファイルの更新がサブスクライブされているエンジン層サーバーに通知を直接プッシュしようとします。そのエンジン層サーバーが使用可能でない場合は、エンジン層クラスタの別のサーバーが選択されて通知を受信します。このモデルが機能するのは、セッション情報がエンジン層ではなくSIPデータ層に格納されているからです。

9.6.1 リスナー実装の前提条件

サブスクライブしたプロファイル・データのコールバックを受信するには、SIPサーブレットは以下の手順に従う必要があります。

- com.bea.wcp.profile.ProfileListenerを実装します。

- com.bea.wcp.profile.ProfileServiceヘルパー・クラスでsubscribeメソッドを使用して1つ以上のサブスクリプションを作成します。

- sip.xmlのlistener要素を使用して、それ自体をリスナーとして登録します。

「ProfileListenerの実装」は、ProfileListenerを実装してsusbscribeメソッドを使用する方法を示しています。有効なリスナーの実装があることに加えて、サーブレットはsip.xmlデプロイメントの記述子ファイルでそれ自体をリスナーとして宣言する必要があります。たとえば、次のようなlistener要素の宣言を追加する必要があります。

<listener>
<lisener-class>com.mycompany.MyLisenerServlet</listener-class>
</listener>

9.6.2 ProfileListenerの実装

実際のサブスクリプションは、com.bea.wcp.profile.ProfileServiceヘルパー・クラスのsubscribeメソッドを使って管理されます。subscribeメソッドには、現在のSipApplicationSessionと、モニター対象となるプロファイル・データ・ドキュメントのキーを指定します。「アプリケーション管理下のプロファイル・データに関するドキュメント・キーの作成」を参照してください。

サブスクリプションを取り消すには、ProfileSubscription.cancel()を呼び出します。保留状態のサブスクリプションは、アプリケーション・セッションの終了時に自動的に取り消されます。

例9-2は、ProfileListenerインタフェースを実装したサーブレットのサンプル・コードを示しています。

例9-2 ProfileListenerインタフェースを実装したサーブレットのサンプル

package demo;
import com.bea.wcp.profile.*;
import javax.servlet.sip.SipServletRequest;
import javax.servlet.sip.SipServlet;
import org.w3c.dom.Document;
import java.io.IOException;
public class MyServlet extends SipServlet implements ProfileListener {
private ProfileService psvc;
public void init() {
psvc = (ProfileService) getServletContext().getAttribute(ProfileService.PROFILE_SERVICE);
}
protected void doInvite(SipServletRequest req) throws IOException {
String docSel = "sh://" + req.getTo() + "/IMSUserState/";
// Subscribe to profile data.
psvc.subscribe(req.getApplicationSession(), docSel, null);
}
public void update(ProfileSubscription ps, Document document) {
System.out.println("IMSUserState updated: " + ps.getDocumentSelector());
}
}

10 カスタム・プロファイル・サービス・プロバイダの開発

この章では、プロファイル・サービスAPIを使用してカスタム・プロファイル・プロバイダを開発する方法について説明します。内容は次のとおりです。

- 10.1項「プロファイル・サービスAPIの概要」

- 10.2項「プロファイル・サービスAPIメソッドの実装」

- 10.3項「プロファイル・プロバイダの構成とパッケージ化」

- 10.4項「管理コンソールを使用したプロファイル・プロバイダの構成」

10.1 プロファイル・サービスAPIの概要

Oracle WebLogic Server SIP Containerにはプロファイル・サービスAPI com.bea.wcp.profile.APIが含まれており、これには複数のプロファイル・サービス・プロバイダの実装が含まれています。プロファイル・プロバイダは、定義されたプロトコルを使用してデータ・リポジトリからXMLドキュメントへのアクセスを実行します。デプロイ済のSIPサーブレットやその他のアプリケーションが、基盤のプロトコルについて、またはドキュメントが保存されているデータ・リポジトリについて認識している必要はありません。カスタムURLを使用してプロファイル・データが参照されると、Oracle WebLogic Server SIP Containerはリクエストの処理を正しいプロファイル・プロバイダに任せます。

プロバイダは、ドキュメントを操作するのに必要なプロトコル処理を実行します。すべてのプロバイダはXML DOM形式でドキュメントを処理するため、クライアント・コードは、様々なタイプのプロファイル・データを共通の方法で処理することができます。

図10-1 プロファイル・サービスAPIとプロバイダの実装

「図10-1 プロファイル・サービスAPIとプロバイダの実装」の説明

APIを使用して実装された各プロファイル・プロバイダには、プロファイル・データに対して次の操作が可能になります。

- 新しいドキュメントの作成

- 既存のドキュメントの問合せと更新

- ドキュメントの削除

- プロファイル・ドキュメントの変更の通知を受信するためのサブスクリプションの管理

プロファイル・プロバイダを使用するクライアントは、サーブレット・コンテキスト属性を通じてプロファイル・サービス・インスタンスを取得します。次に、適切なURLを確立し、利用できる1つのプロファイル・サービスAPIでこのURLを使用してプロファイル・データを処理します。プロファイル・プロバイダの構成と組み合されたURLのコンテンツは、Oracle WebLogic Server SIP Containerのプロバイダの実装を決定してクライアントのリクエストを処理します。

以下の項では、カスタム・プロファイル・プロバイダにプロファイル・サービスAPIインタフェースを実装する方法について説明します。

10.2 プロファイルAPIメソッドの実装

カスタム・プロファイル・プロバイダは、エンジン層クラスタにデプロイされた共有のJava EEライブラリ(一般的に単純なJARファイル)として実装されます。プロバイダJARファイルには、少なくともcom.bea.wcp.profile.ProfileServiceSpiを実装するクラスが含まれる必要があります。このインタフェースは、com.bea.wcp.profile.ProfileServiceからメソッドを継承し、プロバイダの登録と未登録で呼び出される新しいメソッドを定義します。

プロバイダ実装に加え、プロバイダがプロファイル・データの更新についてサブスクリプション・ベースの通知をサポートする場合、com.bea.wcp.profile.ProfileSubscriptionインタフェースを実装する必要があります。プロファイル・ドキュメントが変更されると、ProfileSubscriptionがクライアント・サブスクライバに返されます。

Oracle Fusion Middleware WebLogic Server APIリファレンスに、プロファイル・サービスAPIの各メソッドについて詳しく説明されています。プロファイル・サービス・インタフェースを実装するときには、次の注意点とベスト・プラクティスに留意する必要があります。

- putDocument、getDocumentとdeleteDocumentメソッドには、それぞれ2つの個別メソッド・シグネチャがあります。メソッドの基本的なバージョンは、処理が行われるドキュメント・セレクタだけを渡します。別のメソッド・シグネチャは、リクエスタについて明示的な情報が必要となるプロトコルに対してリクエストの送信者のアドレスも渡します。

- subscribeメソッドには、送信者のアドレスを渡すために、そして、時間ベースのサブスクリプションをサポートするために、複数のメソッド・シグネチャがあります。

- com.bea.wcp.profile.ProfileServiceSpiにメソッドを実装しない場合は、OperationNotSupportedExceptionをスローする「no-op」メソッドをインクルードします。

com.bea.wcp.profile.ProfileServiceSpiは、登録と未登録で呼び出されるプロバイダ・メソッドを定義します。プロバイダはデータ・ストアに接続を作成したり、registerメソッドにおいて必要な初期化を実行できます。registerメソッドは、ProviderBeanインスタンスも提供します。このインスタンスには、profile.xmlにおいてプロバイダの構成要素で構成されたコンテキスト・パラメータが含まれています。

unregisterメソッドの場合、プロバイダはバッキング・ストア接続をリリースし、保持している状態を消去する必要があります。

10.3 プロファイル・プロバイダの構成とパッケージ化

デプロイされた他のすべてのアプリケーションが実装にアクセスできる必要があるため、プロバイダは共有Java EEライブラリとしてデプロイされる必要があります。

ほとんどのプロファイル・プロバイダに対して、実装クラスをJARファイルに簡単にパッケージ化できます。その後、Oracle WebLogic Server SIP Containerにライブラリを登録します。

プロバイダをライブラリとしてインストールした後、profile.xmlファイルでプロバイダ・クラスをプロバイダとして識別する必要があります。name要素は、プロバイダ構成を一意に識別し、class要素は、プロファイル・サービスAPIインタフェースを実装するJavaクラスを識別します。プロバイダには１つまたは複数のコンテキスト・パラメータを定義でき、registerメソッドの場合、これらが実装クラスに配信されます。たとえば、コンテキスト・パラメータは、プロファイル・データを取得するバッキング・ストアの識別に使用できます。

例10-1は、XCAPを使用してデータにアクセスするプロバイダの構成サンプルを示しています。

例10-1 profile.xmlでのプロバイダ・マッピング

<profile-service xmlns="http://www.bea.com/ns/wlcp/wlss/profile/300"
xmlns:sec="http://www.bea.com/ns/weblogic/90/security"
xmlns:xsi="http://www.w3.org/2001/XMLSchema=instance"
xmlns:wls="http;//www.bea.com/ns/weblogic/90/security/wls">
<mapping>
<map-by>provider-name</map-by>
</mapping>
<provider>
<name>xcap</name>
<provider-class>com.mycompany.profile.XcapProfileProvider</provider-class>
<param>
<name>server</name>
<value>example.com</name>
</param>
...
</provider>
</profile-service>

10.3.1 プロファイル・プロバイダへのプロファイル・リクエストのマッピング

アプリケーションがプロファイルAPIを使用してリクエストを実行する場合、Oracle WebLogic Server SIP Containerは、そのリクエストを処理するために対応するプロバイダを見つける必要があります。デフォルトでは、Oracle WebLogic Server SIP Containerは、profile.xmlに定義されたプロバイダname要素に対して、リクエストされたURLの接頭辞をマップします。たとえば、例10-1に示した基本的な構成では、Oracle WebLogic Server SIP Containerは、xcap://で始まるプロファイルAPIリクエストをプロバイダ・クラスcom.mycompany.profile.XcapProfileProviderにマップします。

または、名前を付けた各プロバイダに対応する接頭辞をまとめた>profile.xmlにあるmappingエントリを定義できます。例10-2は、2つの代替接頭辞を使ったマッピングを示しています。

例10-2 複数の接頭辞へのプロバイダのマッピング

...
<mapping>
<map-by>prefix</map-by>
<provider>
<provider-name>xcap</provider-name>
<doc-prefix>sip</doc-prefix>
<doc-prefix>subscribe</doc-prefix>
</provider>
<by-prefix>
<mapping>
...

Profile.xmlの明示的なマッピング機能が不十分な場合は、com.bea.wcp.sip.profile.profilerouterインタフェースを実装するカスタム・マッピング・クラスを作成し、そのクラスをmap-by-router要素で識別できます。例10-3は、構成の例を示しています。

例10-3 カスタム・マッピング・クラスの使用

...
<mapping>
<map-by-router>
<class>com.bea.wcp.profile.ExampleRouter</class>
</map-by-router>
</mapping>
...

10.4 管理コンソールを使用したプロファイル・プロバイダの構成

profile.xmlファイルを作成または変更するために、オプションで管理コンソールを使用できます。この場合、ドメインに対してconfig.xmlファイルのプロファイル・プロバイダ・コンソール拡張を有効化する必要があります。

例10-4 config.xmlでのプロファイル・サービス・リソースの有効化

...
<custom-resource>
<name>ProfileService</name>
<target>AdminServer</target>
<descriptor-file-name>custom/profile.xml</descriptor-file-name>
<resource-class>com.bea.wcp.profile.descriptor.resource.ProfileServiceResource</resource-class>
<descriptor-bean-class>com.bea.wcp.profile.descriptor.beans.ProfileServiceBean</descriptor-bean-class>
</custom-resource>
</domain>

プロファイル・プロバイダ拡張は、コンソールの左ペインでSipServerノードの下に表示されます。このプロファイル・プロバイダ拡張で新しいプロバイダ・クラスとマッピング動作の構成を実行することができます。

11 オフライン・チャージング用のDiameter RfインタフェースAPIの使用

この章では、アプリケーションで、Oracle WebLogic ServerのDiameterプロトコル実装に基づいてDiameter RfインタフェースAPIを使用する方法について説明します。内容は次のとおりです。

- 11.1項「Rfインタフェースのサポートの概要」

- 11.2項「オフライン・チャージング・イベントについて」

- 11.3項「Rfアプリケーションの構成」

- 11.4項「オフライン・チャージングAPIの使用」

11.1 Rfインタフェースのサポートの概要

オフライン・チャージングは、定期的に支払いを行うネットワーク・サービスに使用します。たとえば、毎月支払いを行う必要がある音声コール・サブスクリプションをユーザーが利用する場合です。Rfプロトコルを使用することで、IMSチャージング・トリガー機能(CTF)からオフライン・イベントをチャージング・データ機能(CDF)へ発行することが可能になります。チャージング・イベントは、1回かぎりの(ワンタイム)イベントとすることも、セッション・ベースとすることもできます。

Oracle WebLogic Server SIP ContainerはDiameterオフライン・チャージング・アプリケーションを提供します。デプロイ済のアプリケーションは、このアプリケーションを利用してRfプロトコルに基づくチャージング・イベントを生成します。オフライン・チャージング・アプリケーションはDiameter基本プロトコル実装を使用し、Oracle WebLogic Server SIP Containerにデプロイ済のアプリケーションが、構成済のCDFのためにCTFとして機能することを可能にします。

オフライン・チャージングの基本情報については、RFC 3588: Diameter Base Protocol(http://www.ietf.org/rfc/rfc3588.txt)を参照してください。Rfプロトコルの詳細は、3GPP TS 32.299(http://www.3gpp.org/ftp/Specs/html-info/32299.htm)を参照してください。

11.2 オフライン・チャージング・イベントについて

イベントとセッションに基づく両方のチャージングに関しては、CTFはRFC 3588で説明されているアカウンティング状態のマシンを実行します。サーバー(CDF)はRFC 3588で指定されているようにアカウンティング状態のマシン「SERVER、STATELESS ACCOUNTING」を実行します。

CDFへのオフライン・チャージング・イベントのレポーティングは、Diameterアカウンティング・リクエスト(ACR)メッセージを通じて管理されます。Rfは、表11-1に記載されているACRイベント・タイプをサポートします。

表11-1 Rf ACRイベント・タイプ

リクエスト

説明

START

アカウンティング・セッションの開始

INTERIM

アカウンティング・セッションの更新

STOP

アカウンティング・セッションの終了

EVENT

1回かぎりの(ワンタイム)アカウンティング・イベント

START、INTERIMおよびSTOPイベント・タイプは、セッション・ベース・アカウンティングに対し使用します。EVENTタイプは、イベント・ベース・アカウンティングに対し使用するか、セッションの確立が失敗したことを示すために使用します。

11.2.1 イベント・ベース・チャージング

イベント・ベースのチャージング・イベントは、ACR EVENTメッセージを通じて報告されます。例11-1は、基本的なメッセージ・フローです。

例11-1 イベント・ベースのチャージングのメッセージ・フロー

CTF (WLSS)           CDF (Server)
|                     |
| --- ACR (EVENT) --> |
|                     |
|                (Process accounting request)
|                     |
| <-- ACA (EVENT) --- |
|                     |

11.2.2 セッション・ベース・チャージング

セッション・ベース・チャージングでは、ACR START、INTERIMおよびSTOPリクエストを使用して、CDFの使用を報告します。セッション中、セッション・ライフサイクルによってはCTFが複数のACR INTERIMリクエストを報告する可能性があります。例11-2は、基本的なメッセージ・フローです。

例11-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は、Oracle WebLogic Server SIP Containerによるサービス・リクエストの受信時に送信されます。ACA INTERIMは通常、AIIタイマーの時間切れ時点で送信されます。ACA STOPは、Oracle WebLogic Server SIP Containerによるサービス終了のリクエスト時に発行されます。

11.3 Rfアプリケーションの構成

Rf APIは、プロファイル・データを管理するためのShアプリケーションと似たようなDiameterアプリケーションとしてパッケージされています。Rf Diameter APIは、DOMAIN_ROOT/config/custom/diameter.xmlに格納されているDiameter構成ファイルを編集するか、Diameterコンソール拡張を使用して、構成および有効化できます。また、CDFレルムとホストの構成はいずれも、Diameter Rfアプリケーションへのcdf.realmおよびcdf.host初期化パラメータを使用して指定できます。

例11-3は、CDFレルム「oracle.com」およびホスト「cdf.oracle.com:」でRfを有効化するdiameter.xmlから抜粋したサンプルです。

例11-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はありません。

11.4 オフライン・チャージングAPIの使用

Oracle WebLogic Server SIP Containerは、オフライン・チャージングAPIを提供します。このAPIにより、デプロイ済の任意のアプリケーションがCTFとして機能し、オフライン・チャージング・イベントを発行することが可能になります。このAPIは、イベント・ベースおよびセッション・ベースのどちらのチャージング・イベントもサポートします。

Com.bea.wcp.diameter.accountingパッケージ内のクラスにより、Diameterアカウンティング・メッセージおよびセッションについての全般的なサポートが提供されます。表11-2に、クラスの概要を示します。

表11-2 Diameterアカウンティング・クラス

クラス

説明

ACR

アカウンティング・リクエスト・メッセージ

ACA

アカウンティング応答メッセージ

ClientSession

クライアント・ベースのアカウンティング・セッション

RecordType

アカウンティング・レコード・タイプ定数

さらに、com.bea.wcp.diameter.chargingパッケージ内のクラスにより、特にRfアプリケーションがサポートされます。 表11-3に、クラスの概要を示します。

表11-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のインスタンスで表され、セッション用のアカウンティング状態のマシンをカプセル化します。

11.4.1 Rfアプリケーションへのアクセス

Rfアプリケーションがデプロイされると、Oracle WebLogic Server SIP Containerでデプロイされたアプリケーションは、Diameterノード(com.bea.wcp.diameter.Nodeクラス)からアプリケーションのインスタンスを取得できます。例11-4は、Diameter Nodeを取得してRfアプリケーションにアクセスするため使用するサンプル・サーブレット・コードを示しています。

例11-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の各インスタンスは、実際には、各呼出しに対し一意のセッションごとの状態を保持します。

11.4.2 セッション・ベース・チャージングの実装

セッション・ベース・チャージング・リクエストでは、アプリケーションは、最初にRfApplicationを使用してRfSessionのインスタンスを作成します。その後、セッション・オブジェクトを使用して1つまたは複数のチャージング・リクエストを作成できます。

最初のチャージング・リクエストはACR STARTリクエストである必要があり、その後、ゼロまたは1つ以上のACR INTERIMリクエストが続きます。セッションはACR STOPリクエストで終了します。対応するACA STOPメッセージを受信すると、RfApplicationが自動的にRfSessionを終了します。

例11-5は、新しいセッション・ベース・アカウンティング・セッションを開始するサンプル・コードです。

例11-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 ...
}

例11-5では、呼出しの進捗にともなって追加のアカウンティング・リクエストの送信に使用できるように、RfSessionがSIPアプリケーション・セッション属性として格納されています。例11-6は、INTERIMリクエストをどのように送信するかを示します。

例11-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を参照してください。

11.4.2.1 セッション有効期限の指定

Rfアカウンティング・セッションの有効期限を示すために、Acct-Interim-Interval (AII)タイマー値が使用されます。この値は、ACR STARTがCDFに送られてアカウンティング・セッションが開始するときに指定されます。CDFは独自のAII値を返し、CTFはその値を使って、期限切れ時点でACR INTERIMメッセージを送信するタイマーをスタートさせます。このINTERIMメッセージによって、セッションがまだ使用中であることがCDFに伝えられます。この通知がない場合、CDFはセッションを自動的に終了します。

更新済のサービス情報データはACR INTERIMメッセージでCDFへ送信されるため、アプリケーションはこれらのメッセージを送信する責任があります。AII値に応じて期限切れになるServletTimerを作成することをお薦めします。このタイマーが期限切れになった時点で、アプリケーションは更新済のサービス情報データとともにACR INTERIMメッセージを送信する必要があります。

11.4.2.2 非同期リクエストの送信

通常、アプリケーションは同期sendAndWait()メソッドを使用します。ただし、待機時間が重要な場合は、非同期APIを使用できます。非同期APIでは、CDFから応答メッセージを受信する際、アプリケーション・サーブレットに対し非同期的に通知が行われます。非同期APIを使用するために、アプリケーションは、まずSessionListenerのインスタンスを登録して、セッションに配信されるメッセージを非同期的に受信するようにします(例11-7を参照)。

例11-7 SessionListenerの登録

RfSession session = rfApp.createSession();
session.setAttribute("SAS", sipReq.getApplicationSession());
session.setListener(this);

属性は、SIPアプリケーション・セッション属性を格納するのと同じ方法で、RfSessionインスタンスに格納できます。上の例では、リスナー・コールバックに使用できるように、関連SIPアプリケーションはRfSessionとして格納されています。

CDFからDiameterリクエストまたは応答メッセージを受信すると、rcvMessage(Message msg)メソッドを呼び出すことでアプリケーション・サーブレットに通知が送られます。例11-8に示されているように、関連SIPアプリケーション・セッションがセッション属性として格納されていれば、RfSessionから取得できます。

例11-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");
...
}

11.4.3 イベント・ベース・チャージングの実装

イベント・ベース・チャージングの場合、チャージング・リクエストは1回かぎりのイベントであり、対応するEVENT ACAメッセージの受信時点でセッションは自動で終了します。sendAndWait(long timeout)メソッドは、EVENTリクエストを同時に送信し、CDFからレスポンスを受信するまでスレッドをブロックするために使用できます。例11-9では、RfSessionを使用してイベント・ベースのチャージング・リクエストを送信する場合の例を示します。

例11-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 ...
}

便宜上、例11-10のように、RfApplicationを直接使用してイベント・ベース・チャージング・リクエストを送信することもできます。

例11-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コンソール拡張を使用して構成できます。

11.4.4 アカウンティング・セッション状態の使用

オフライン・チャージングのアカウンティング・セッション状態はシリアライズ可能なので、SIPアプリケーション・セッション属性として格納できます。クライアントAPIは同期的であるため、いったんサーブレットが呼出し処理を終了したら、アカウンティング・セッションの状態を保持する必要はまったくありません。

イベント・ベースのチャージング・イベントでは、アカウンティング・セッション状態は内部的にのみ使用されるため、アプリケーションが保持する必要はありません。そのため、いったんACAレスポンスが受信された後は、アカウンティング・セッション状態は破棄されます。

12 オフライン・チャージング用のDiameter RoインタフェースAPIの使用

この章では、アプリケーションで、Oracle WebLogic ServerのDiameterプロトコル実装に基づいてDiameter RoインタフェースAPIを使用する方法について説明します。内容は次のとおりです。

- 12.1項「Roインタフェースのサポートの概要」

- 12.2項「クレジット認証モデルについて」

- 12.3項「Roアプリケーションの構成」

- 12.4項「オンライン・チャージングAPIの概要」

- 12.5項「Roアプリケーションへのアクセス」

- 12.6項「セッション・ベース・チャージングの実装」

- 12.7項「クレジット管理リクエスト・メッセージの送信」

- 12.8項「障害の処理」

12.1 Roインタフェースのサポートの概要

クレジット・ベース・チャージングとしても知られているオンライン・チャージングは、プリペイド・サービスの請求に使用されます。典型的なプリペイド・サービスの例としては、音声またはビデオのために購入するテレホン・カードがあります。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を含めることができます。

12.2 クレジット認証モデルについて

RFC 4006は、次のような2つの基本的なタイプのクレジット認証モデルを定義します。

- ユニット予約方式でのクレジット認証

- 口座引き落とし方式でのクレジット認証

ユニット予約方式でのクレジット認証では、イベント・ベースまたはセッション・ベースのいずれのチャージング・イベントでも実行することができます。口座引き落とし方式でのクレジット認証では、即時チャージング・イベントを使用します。どちらのモデルでも、CTFはエンド・ユーザーにサービスを配信する前にOCFからのクレジット認証をリクエストします。

以下の項では、各モデルについて詳しく説明します。

12.2.1 ユニット決定方式でのクレジット認証

RFC 4006は、ユニット予約方式でのイベント・チャージング(ECUR)およびユニット予約方式でのセッション・チャージング(SCUR)を定義します。これらのチャージング・イベントは、どちらもセッション・ベースであり、CTFとOCF間における複数のトランザクションを必要とします。ECURでは、サービスを配信する前にまずユニット数を予約するための問い合わせを行い、その後、サービスの終了時点で実際に使用されたユニット数をOCFへ報告するための問い合わせを実行します。SCURの場合には、CTFが1つまたは複数の中間問い合わせを行って実際にその時点で使用されているユニット数を報告し、必要に応じて追加のユニット数を予約することもできます。いずれの場合も、セッション状態はCTFおよびOCFの両方に保持されます。

ECURとSCURのどちらの場合も、オンライン・チャージング・クライアントはRFC 4006に記載されているCLIENT、SESSION BASEDステート・マシンを実装します。

12.2.2 口座引き落とし方式でのクレジット認証

口座引き落としの場合は、即時イベント・チャージング(IEC)が使用されます。IECでは、単一のトランザクションを作成し、クレジット認証の完了後にOCFが直ちにユーザーの口座から一定の金額を引落します。認証の受信後、CTFがサービスを配信します。このクレジット認証の形態は、1回かぎりの(ワンタイム)イベントであり、セッション状態は保持されません。

IECでは、オンライン・チャージング・クライアントは、IETF RFC 4006に記載されているCLIENT、EVENT BASEDステート・マシンを実装します。

12.2.3 ユニットの決定とレーティング

ユニットの決定は、サービスの配信に先立って割り当てることのできる、非貨幣的な単位ユニット数(サービス・ユニット、時間、イベントなど)の計算を参照します。ユニットのレーティングは、ユニット決定機能によって算出された非貨幣的なユニット数に基づいた価格決定を参照します。

ユニットの決定およびユニット・レーティングは、OCF、CTFのいずれでも処理可能です。どちらで処理を行うかは、OCFに送信されるクレジット管理リクエスト内のAVPの選択を制御するクライアント・アプリケーションによって決まります。

12.3 Roアプリケーションの構成

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になります。

12.4 オンライン・チャージングAPIの概要

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

即時イベント・チャージング

EVENT_REQUEST

ECUR

ユニット予約方式でのイベント・チャージング

INITIALまたはTERMINATION_REQUEST

SCUR

ユニット予約方式でのセッション・チャージング

INITIAL、UPDATEまたはTERMINATION_REQUEST

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クラスの概略

クラス

説明

パッケージ

Charging

定数定義

com.bea.wcp.diameter.charging

RoApplication

オンライン・チャージング・アプリケーション

com.bea.wcp.diameter.charging

RoSession

オンライン・チャージング・セッション

com.bea.wcp.diameter.charging

CCR

クレジット管理リクエスト

com.bea.wcp.diameter.cc

CCA

クレジット管理応答

com.bea.wcp.diameter.cc

ClientSession

クレジット管理クライアント・セッション

com.bea.wcp.diameter.cc

RequestType

クレジット管理リクエスト・タイプ

com.bea.wcp.diameter.cc

RAR

再認証リクエスト・メッセージ

com.bea.wcp.diameter

RAA

再認証応答メッセージ

com.bea.wcp.diameter

12.5 Roアプリケーションへのアクセス

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のインスタンスは、複数の同時スレッドで使用する場合に安全です。

12.6 セッション・ベース・チャージングの実装

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);
...

12.6.1 再認証リクエスト・メッセージの処理

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にリクエストを配信する前に呼出し状態をロックするため、リクエストがハンドラによって処理されている間、呼出し状態はロックされたままになります。

12.7 クレジット管理リクエスト・メッセージの送信

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を追加しています。

12.8 障害の処理

アプリケーションでは、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を受信すると、セッションはもう存在しないためメッセージは無視されます。

例12-7 タイマーTxの有効期限の確認

CCR ccr = session.createCCR(RequestType.INITIAL);
ccr.setCreditControlFailureHandling(RequestType.TERMINATION);
ccr.send();
CCA cca = ccr.waitForAnswer();
if (cca == null) {
session.terminate();
}

第IV部

リファレンス

この部は、次の付録で構成されます。

- 付録A「プロファイル・サービス・プロバイダ構成リファレンス(profile.xml)」

- 付録B「Eclipseを使ったSIPサーブレットの開発」

- 付録C「既存のアプリケーションのOracle WebLogic Server SIP Containerへの移植」

A プロファイル・サービス・プロバイダ構成リファレンス(profile.xml)

この付録では、プロファイル・プロバイダの構成ファイルであるprofile.xmlの詳細なリファレンスを提供します。内容は次のとおりです。

- A.1項「profile.xmlの概要」

- A.2項「グラフィカルな表示」

- A.3項「profile.xmlの編集」

- A.4項「XMLスキーマ」

- A.5項「profile.xmlファイルのサンプル

- A.6項「XML要素の説明」

A.1 profile.xmlの概要

diameter.xmlファイルには、次のプロファイル・サービス・プロバイダ属性が定義されています。

- プロバイダの名前

- 実装プロバイダのクラス名

- プロバイダに渡した任意の引数

- プロバイダを使用するためのマッピング・ルール。

profile.xmlは、DOMAIN_DIR/config/customサブディレクトリに格納されます。DOMAIN_DIRはOracle WebLogic Server SIP Containerドメインのルート・ディレクトリです。

A.2 グラフィカルな表示

図A-1では、profile.xmlファイルの要素階層を表示します。

図A-1 profile.xmlの要素階層

「図A-1 profile.xmlの要素階層」の説明

A.3 profile.xmlの編集

profile.xmlファイルに変更を加えるときは、直接編集せずに、管理コンソールのプロファイル・サービス拡張を使って間接的に行うことをお薦めします。管理コンソールを使用すると、profile.xmlドキュメントが確実に有効なXMLになります。Oracle WebLogic Server SIP Containerでのアプリケーションの開発には、「管理コンソールを使用したプロファイル・プロバイダの構成」を参照してください。

とはいえ、問題のある構成を修正したり、壊れたファイルを修復したり、Oracle WebLogic Server SIP Containerのアップグレード時にカスタム・プロファイル・プロバイダ構成を多数のマシンに展開したりするために、profile.xmlを手動で表示したり編集する可能性もあります。profile.xmlを手動で編集したときは、変更内容を適用するためにサーバーを再起動する必要があります。

A.3.1 profile.xmlの編集の手順

本番システムのprofile.xmlに変更を加える必要がある場合は、次の手順に従います。

1. テキスト・エディタでDOMAIN_DIR/config/custom/profile.xmlファイルを開きます。DOMAIN_DIRはOracle WebLogic Server SIP Containerドメインのルート・ディレクトリを表します。

2. 必要に応じてprofile.xmlファイルを変更します。XML要素の詳細は、「XML要素の説明」を参照してください。

3. 変更を保存し、テキスト・エディタを終了します。

4. サーバーを再起動して、変更内容を有効にします。

5. 更新後のシステムをテストして、構成を検証します。

A.4 XMLスキーマ

WLSS_HOME/server/lib/wlssディレクトリにインストールされたprofile-service-descriptor-binding.jarライブラリ内にprofile.xmlファイルのすべてのスキーマがバンドルされています。

A.5 profile.xmlファイルのサンプル

構成ファイルprofile.xmlのコード・リストについては、SIPアプリケーションの開発のカスタム・プロファイル・プロバイダの開発に関する項を参照してください。

A.6 XML要素の説明

次の項では、profile.xmlの各XML要素について説明します。

A.6.1 profile-service

最上位レベルのprofile-service要素には、全体のプロファイル・サービス構成が含まれます。

A.6.2 mapping

プロファイル・データに対するリクエストをプロファイル・プロバイダ実装にマッピングする方法を指定します。

A.6.2.1 map-by

ドキュメントをプロバイダにマッピングするための手法を指定します。

- プロバイダを判定するためにrouterはmap-by-routerに指定された、カスタム・ルーター・クラスを使用します。

- ドキュメントをプロバイダにマップするためにprefixは指定された、map-by-prefixエントリを使用します。

- プロバイダにドキュメントをマップするためにprovider-nameはproviderエントリに指定された、name要素を使用します。

A.6.2.2 map-by-prefix

プリフィックスによるマッピング時にドキュメントをプロファイル・プロバイダにマップするために使用するプリフィックスを指定します。

A.6.2.3 map-by-router

ルーター・ベース・マッピングでドキュメントをプロファイルにマップするために使用する(com.bea.wcp.profile.ProfileRouterを実装)ルーター・クラスを指定します。

A.6.3 provider

プロファイル・プロバイダ実装と起動オプションを構成します。

A.6.3.1 name

プロバイダ構成の名前を指定します。provider-nameマッピング手法を指定する場合、name要素はドキュメントをプロバイダにマッピングするためにも使用されます。

A.6.3.2 provider-class

(com.bea.wcp.profile.ProfileServiceSpiの実装)プロファイル・プロバイダ・クラスを指定します。

A.6.3.3 param

プロバイダ実装に任意パラメータを指定するためにnameおよびvalue要素を使用します。

B Eclipseを使ったSIPサーブレットの開発

この付録では、Eclipseを使用してOracle WebLogic Server SIP Containerで使用するSIPサーブレットを開発する方法について説明します。内容は次のとおりです。

- B.1項「概要」

- B.2項「開発環境の設定」

- B.3項「プロジェクトのビルドとデプロイ」

- B.4項「SIPサーブレットのデバッグ」

B.1 概要

このドキュメントでは、Oracle WebLogic Server SIP ContainerでSIPサーブレットを開発してデプロイするためのツールとしてEclipse IDEを使用する方法を詳しく説明します。完全な開発環境を構築するためには次のコンポーネントが必要です。まず、これらを入手してインストールしてください。

- Oracle WebLogic Server SIP Container

- JDK 1.6.05

- Eclipseバージョン3.4またはEclipse 3.3 Europe。CVSクライアントとサーバーが含まれます(バージョン管理にのみ必要)。

B.1.1 SIPサーブレットの編成

SIPサーブレットをビルドすると、最終生成物としてWebアーカイブ(WARファイルまたはディレクトリ)が作成されます。基本的なSIPサーブレットWARファイルには、図B-1に示すサブディレクトリとファイルが含まれます。

図B-1 SIPサーブレットWARの内容

「図B-1 SIPサーブレットWARの内容」の説明

B.2 開発環境の設定

以下の手順に従って、新しいSIPサーブレット・プロジェクトのための開発環境を設定してください。

1. 新しいOracle WebLogic Server SIP Containerドメインを作成します。

2. 新しいEclipseプロジェクトを作成します。

以下の項では、各手順について詳しく説明します。

B.2.1 Oracle WebLogic Server SIP Containerドメインの作成

SIPサーブレットをデプロイしてテストするには、必要に応じて再構成と再起動が可能なOracle WebLogic Server SIP Containerドメインにアクセスできる必要があります。『Oracle WebLogic Server SIP Containerインストレーション・ガイド』の説明に従って、構成ウィザードを使用して新しいドメインを作成します。新しいドメインを生成するには、次の作業が必要です。

- 新しいドメインの起動モードとして開発モードを選択します。

- 新しいドメインのSDKとしてSun SDK 1.6.05を選択します。

B.2.2 デフォルトのEclipse JVMの確認

Eclipse 3.4はデフォルトで、必要なバージョンのJava 6(1.6)を使用します。構成されたJVMを検証するには、次の手順に従います。

1. Eclipseを起動します。

2. 「ウィンドウ」>「プリファレンス」を選択します。

3. 左ペインでJavaカテゴリを展開し、「Installed JREs」を選択します。

4. Java 6(1.6)が構成されていることを確認します。構成されている場合は、ステップ10に進みます。

5. 正しく構成されていない場合は、「追加」をクリックして新しいJREを追加します。

6. 新しいJREに使用する名前をJRE名フィールドに入力します。

7. JREホーム・ディレクトリ・フィールドの横にある「参照」ボタンをクリックします。MIDDLEWARE_HOME/jdk160_05ディレクトリに移動して、「OK」をクリックします。

8. 「OK」をクリックして、新しいJREを追加します。

9. 新しいJREの横にあるチェック・ボックスを選択して、それをデフォルトにします。

10. 「OK」をクリックして、「プリファレンス」ダイアログを終了します。

B.2.3 新しいEclipseプロジェクトの作成

SIPサーブレットを開発するための新しいEclipseプロジェクトを作成し、アプリケーションのビルドとデプロイに必要なOracle WebLogic Server SIP Containerのライブラリを追加するには、次の手順に従います。

1. Eclipseを起動します。

2. 「ファイル」>「新規」>「プロジェクト」を選択します。

3. 「Javaプロジェクト」を選択し、「次へ」をクリックします。

4. 「Project Name」フィールドにプロジェクトの名前を入力します。

5. まだSIPサーブレット・コードを書き始めていなければ、「場所」フィールドでワークスペースにプロジェクトを作成を選択します。利用できるソース・コードが別の場所にある場合は、外部の場所でプロジェクトを作成を選択し、そのディレクトリを指定します。「次へ」をクリックします。

6. 「Libraries」タブをクリックし、以下の手順に従って、必要なJARをプロジェクトに追加します。

1. 外部JARを追加...をクリックします。

2. JAR選択ダイアログを使用して、MIDDLEWARE_HOME/server/lib/weblogic.jarファイルをプロジェクトに追加します。

3. 作業を繰り返して、MIDDLEWARE_HOME/server/lib/wlss/sipservlet.jarおよびMIDDLEWARE_HOME/server/lib/wlss/wlssapi.jarファイルをプロジェクトに追加します。

7. そのプロジェクトに必要と思われるJARファイルが他にもあれば、それらも追加します。

8. eclipseから直接デプロイできるようにするには、ビルド・フォルダを/src/buildから/src/WebContent/WEB-INF/classesに変更します。これにより、デプロイする前にアプリケーションをパッケージ化する必要がなくなります。

9. 「終了」をクリックして、新しいプロジェクトを作成します。EclipseのPackage Explorerに新しいプロジェクトの名前が表示されます。

10. プロジェクトの名前を右クリックし、図B-1「SIPサーブレットWARの内容」に示したディレクトリ構造を、「新規」>「フォルダ」コマンドを使用して再作成します。

B.3 プロジェクトのビルドとデプロイ

作成したbuild.xmlファイルにより、コードがコンパイルされ、WARファイルが作成され、WARファイルが開発ドメインの/applicationsサブディレクトリにコピーされます。Oracle WebLogic Server SIP Containerは/applicationsサブディレクトリに置かれた有効なアプリケーションを自動的にデプロイします。

B.4 SIPサーブレットのデバッグ

SIPサーブレットをデバッグするには、Oracle WebLogic Server SIP Containerの起動時に、いくつかのデバッグ・オプションを有効にする必要があります。次の手順に従って、必要なデバッグ・オプションをOracle WebLogic Server SIP Containerの起動用スクリプトに追加し、Eclipse内部からデバッガをアタッチします。

注意:
Linuxでは、開発モードでインストールするとデバッグがデフォルトで有効になります。ただし、ポートは8453に設定されます。

1. 開発ドメインのためのStartWebLogic.cmdスクリプトをテキスト・エディタで開きます。

2. 次のような行を探します。

set JAVA_OPTIONS=

Enter the following line:

set DEBUG_OPTS=-Xdebug -Xrunjdwp:transport=dt_socket,address=9000,server=y,suspend=n

3. ファイルの最後のラインの次に示す位置に%DEBUG_OPTS%変数を追加します。

"%JAVA_HOME%\bin\java" %JAVA_VM% %MEM_ARGS% %JAVA_OPTIONS% %DEBUG_OPTS%
-Dweblogic.Name=%SERVER_NAME% -Dweblogic.management.username=%WLS_USER%
-Dweblogic.management.password=%WLS_PW%
-Dweblogic.management.server=%ADMIN_URL%
-Djava.security.policy="%MIDDLEWARE_HOME%\server\lib\weblogic.policy" weblogic.Server

4. ファイルを保存し、スクリプトを使用してOracle WebLogic Server SIP Containerを再起動します。

5. Eclipse内部からデバッガをアタッチするには、「実行」>デバッグをオープンダイアログを選択します。

6. 新しいリモートJavaアプリケーションを作成します。

7. DEBUG_OPTSに対応するホストとポートを入力します。

C 既存のアプリケーションのOracle WebLogic Server SIP Containerへの移植

この章では、SIPサーブレットv1.0仕様に基づく既存のアプリケーションのOracle WebLogic Server SIP Containerへの移植に関するガイドラインと問題点、およびSIPサーブレット仕様について説明します。内容は次のとおりです。

- C.1項「アプリケーション・ルーターとレガシー・アプリケーション構成」

- C.2項「シリアライズ可能でないSipSessionおよびSipApplicationSession」

- C.3項「SipServletResponse.setCharacterEncoding() APIの変更」

- C.4項「SipServletRequestおよびSipServletResponseに対するトランザクション制限事項」

- C.5項「新しいパラメータ・インタフェースの不変パラメータ」

- C.6項「非推奨のステートレス・トランザクション・プロキシ」

- C.7項「v1.0デプロイメントの下位互換性モード」

- C.8項「非推奨となったAPI」

- C.9項「SNMP MIBの変更」

- C.10項「改名された診断モニターと診断アクション」

C.1 アプリケーション・ルーターとレガシー・アプリケーション構成

SIPサーブレットv1.1仕様では、正式なアプリケーションの選択および構成処理が説明されており、これはOracle WebLogic Server SIP Containerに完全に実装されています。新規の開発についてはすべて、SIPサーブレットv1.1の手法を使用します。前のバージョンで説明されているアプリケーション構成手法は、非推奨になっています。

Oracle WebLogic Server SIP Containerでは、次の場合にかぎって、SIPサーブレット・バージョン1.0の構成手法を使用してアプリケーションに下位互換性を提供します。

- カスタム・アプリケーション・ルーターを構成しない場合、および

- デフォルトのアプリケーション・ルーター・プロパティを構成しない場合。

C.2 シリアライズ可能でないSipSessionおよびSipApplicationSession

SIPサーブレットv1.1仕様では、SipSessionおよびSipApplicationSessionインタフェースをシリアライズできません。Oracle WebLogic Server SIP Containerは、旧v1.0仕様のバイナリ互換性を維持します。したがって、これらのインタフェースをシリアライズ可能なオブジェクトとして扱うコンパイルされたアプリケーションも操作できます。ただし、このアプリケーションをOracle WebLogic Server SIP Containerで再コンパイルする前に、アプリケーションのソース・コードを変更する必要があります。

TimerService.createTimer APIを使用して、SipSessionをシリアライズ可能なInfoオブジェクトとして保存するバージョン1.0サーブレットでは、SipSession IDをシリアライズ可能なinfoオブジェクトとして保存することによって同様な機能を実現できます。タイマー有効期限のコールバックを受け取ったら、アプリケーションがSipApplicationSessionおよびServletTimerによって返されたシリアライズされたIDオブジェクトを使用してSipApplicationSession内に、取得されたIDでSipSessionを検索する必要があります。詳細は、SIP Servlet v1.1 API JavaDocを参照してください。

C.3 SipServletResponse.setCharacterEncoding() APIの変更

SipServletResponse.setCharacterEncoding()はUnsupportedEncodingExceptionをスローしなくなりました。このメソッドでUnsupportedEncodingExceptionを明示的に捕捉するアプリケーションがある場合、既存のコンパイルされたアプリケーションを変更せずにそのままOracle WebLogic Server SIP Containerにデプロイできます。ただし、再コンパイルする前に例外を捕捉しないように、ソース・コードを変更する必要があります。

C.4 SipServletRequestおよびSipServletResponseに対するトランザクション制限事項

SIPサーブレットv1.1はSipServletRequestおよびSipServletResponseオブジェクトがSIPトランザクションに属することを認証します。仕様では、メッセージのコミットの条件も定義されます。これをした後、どのアプリケーションもメッセージを変更または再送信できません。SIPメッセージをコミットする条件のリストについては、SIPサーブレット仕様v1.1の(http://jcp.org/en/jsr/detail?id=289)暗黙的なトランザクション状態に関する項を参照してください。

この変更により、コミットされたメッセージを変更(ヘッダーの設定、追加または削除)、または送信しようとする場合、IllegalStateExceptionが発生します。既存のコードによって、SipServletMessage.isCommitted()を使用して、メッセージを変更または送信する前に、メッセージがコミットされていることを確認する必要があります。

C.5 新しいパラメータ・インタフェースの不変パラメータ

SIPサーブレットv1.1は、様々なSIPヘッダーのパラメータをアクセス、作成、および変更するために新しいjavax.servlet.sip.Parameterableインタフェースを導入しています。表C-1に示したシステム・ヘッダー・パラメータは不変であり、この新しいインタフェースを使用して変更できないことに注意してください。

表C-1 不変システム・ヘッダー・パラメータ

ヘッダー

不変パラメータ

From

タグ

To

タグ

Via

branch、received、rport、wlsslport、wlssladdr、maddr、ttl

Record-Route

すべてのパラメータは不変です。

Route

初期リクエストの場合、Routeヘッダーをプッシュするアプリケーションは、ヘッダーのパラメータを変更できます。他の場合、Routeヘッダーのパラメータは不変です。

Path

登録リクエストの場合、Pathヘッダーをプッシュするアプリケーションは、ヘッダーのパラメータを変更できます。他の場合、Pathヘッダーのパラメータは不変です。

C.6 非推奨のステートレス・トランザクション・プロキシ

Oracle WebLogic Server SIP Container内のアプリケーションは、プロキシが常にトランザクション・ステートフルである必要があり、プロキシ・オブジェクトをステートレスに設定しても効果はありません。

Proxy.setStateful()およびProxy.getStateful()メソッドは冗長です。Proxy.getStateful()は常にtrueを返し、Proxy.setStateful()は操作を実行しません。

C.7 v1.0デプロイメントの下位互換性モード

Oracle WebLogic Server SIP Containerは、プリコンパイル済のv1.0デプロイメントを自動的に検出し、下位互換性を保持するために、SIPコンテナの動作を変更します。次の項では、v1.0 SIPサーブレットをOracle WebLogic Server SIP Containerにデプロイするときに発生する動作の違いについて説明します。

C.7.1 v1.0 Servletデプロイメントの検証警告

SIPサーブレットv1.1仕様では、サーブレットのデプロイメントについて、前の仕様よりも厳密な検証が必要です。次の場合、v1.0 SIPサーブレットはOracle WebLogic Server SIP Containerに正常にデプロイされますが、デプロイ時に警告メッセージが表示されます。

- v1.0のデプロイメント記述子のlistener-class要素でリスナーが宣言されているが、対応するクラスがEventListenerインタフェースを実装していない場合、デプロイ時に警告が表示されます。(リスナーを宣言するバージョン1.1 SIPサーブレットはEventListenerを実装している必要があり、そうでなければアプリケーションをデプロイできません)。

- v1.0のデプロイメント記述子のservlet-class要素でSIPサーブレットが宣言されているが、対応するクラスがSipServlet抽象クラスを拡張していない場合、警告が表示されます。(バージョン1.1 SIPサーブレットはSipServletを拡張している必要があり、そうでなければアプリケーションをデプロイできません)。

C.7.2 コミット・メッセージの変更

SIPサーブレットv1.1仕様では、アプリケーションがコミット・メッセージを変更しようとした場合、SIPコンテナがIllegalStateExceptionをスローすることを推奨しています。下位互換性を保つために、Oracle WebLogic Server SIP Containerは、バージョン1.1 SIPサーブレット・デプロイメントによりコミット・メッセージが変更される場合のみ、IllegalStateExceptionをスローします。

C.7.3 システム・ヘッダーとしてのパス・ヘッダー

SIPサーブレットv1.1仕様では、Pathヘッダーはシステム・ヘッダーとして定義されており、アプリケーションによって変更できなくなりました。バージョン1.0 SIPサーブレットではPathヘッダーを変更できますが、警告メッセージが生成されます。バージョン1.0 SIPサーブレットでPathヘッダーの変更を試行すると、IllegalArgumentExceptionで失敗します。

C.7.4 SipServletResponse.createPrack()の例外

Oracle WebLogic Server SIP Containerでは、SipServletResponse.createPrack()によってバージョン1.1 SIPサーブレットの場合のみ、Rel100Exceptionがスローされます。下位互換性を保つするために、createPrack()はバージョン1.0 SIPサーブレットの場合、例外をスローしません。

C.7.5 Proxy.proxyTo()の例外

バージョン1.1 SIPサーブレットによってProxy.proxyTo(uri)またはProxy.proxyTo(uris)で重複するブランチURIが指定された場合、Oracle WebLogic Server SIP ContainerによってIllegalStateExceptionがスローされます。下位互換性を保つするために、バージョン1.0 SIPサーブレットがこれらのメソッドで重複するURIを指定された場合、Oracle WebLogic Server SIP Containerによって無視されます(例外がスローされません)。

C.7.6 プロキシ・ブランチ・タイマーへの変更

SIPサーブレットv1.1では、シーケンシャルやパラレルの両方のプロキシ処理のプロキシ分岐の行動に影響をもたらすいくつかのプロトコルの変更があります。

v1.1仕様では、シーケンシャル・プロキシ処理については、Oracle WebLogic Server SIP Containerによって、sip.xmlまたはSIPプロトコルTimer C(3分以上)に構成されたsequential-search-timeoutの最大値を使用してブランチ・タイマーを起動することを必要とします。Oracle WebLogic Server SIP Containerの旧バージョンでは、常にsequential-search-timeoutの値を使用してシーケンシャル・ブランチ・プロキシ・タイムアウトが設定されます。この動作はv1.0デプロイメントに対して維持されます。

パラレル・プロキシ処理について、v1.1仕様は、プロキシ処理をコントロールする新しいproxyTimeout値を提供します。この仕様は、Oracle WebLogic Server SIP Containerが、SIPサーブレットv1.0仕様が必要とするTimer C値ではなく、構成したproxyTimeout値を使用してブランチ・タイマーをリセットすることを必要とします。Timer C値はv1.0デプロイメントのためにまだ使用されます。

C.8 非推奨となったAPI

WebLogic SIP Serverの以前のバージョンは、SIPサーブレットv1.0仕様でサポートされない機能およびRFCをサポートするため、独自のAPIを提供します。SIPサーブレットv1.1仕様により、新しいRFCサポートおよび機能が追加され、独自のAPIが冗長になります。表C-2には、非推奨となったWebLogic SIP Serverのメソッドのかわりに使用できる新しいSIPサーブレットv1.1メソッドを示します。v1.0アプリケーションに下位互換性を提供するため、非推奨のメソッドはまだこのリリースで利用可能です。

表C-2 非推奨となったAPI

非推奨のメソッド(WebLogic SIP Server独自)

置換えメソッド(SIPサーブレットv1.1)

WlssSipServlet.doRefer()、WlssSipServlet.doUpdate()、WlssSipServlet.doPrack()

SipServlet.doRefer()、SipServlet.doUpdate()、SipServlet.doPrack()

WlssSipServletResponse.createPrack()

SipServletResponse.createPrack()

WlssProxy.getAddToPath()、WlssProxy.setAddToPath()

Proxy.getAddToPath()、Proxy.setAddToPath()

WlssSipServletMessage.setHeaderForm()、WlssSipServletMessage.getHeaderForm()

SipServletMessage.setHeaderForm()、SipServletMessage.getHeaderForm()

com.bea.wcp.util.Sessions

表6–1「コンバージド・アプリケーションのセッション」を参照。

C.9 SNMP MIBの変更

Oracle WebLogic Server SIP Containerの前のバージョンのSNMP MIB定義はWebLogic MIBのネーミング規則に準拠していませんでした。特に、MIB表列名のラベルは表名から始まっていません。Oracle WebLogic Server SIP Containerは、WebLogicのネーミング規則に準拠し、メタデータ・ファイルを生成するWebLogicツールとの互換性を提供するために、ラベルの先頭にsipServerを付加します。

たとえば、バージョン3.xでのSipServerEntry MIB定義を次に示します。

SipServerEntry  ::=  SEQUENCE {
sipServerIndex  DisplayString,
t1TimeoutInterval  INTEGER,
t2TimeoutInterval  INTEGER,
t4TimeoutInterval  INTEGER,
....
}

Oracle WebLogic Server SIP Containerでの定義は次のようになります。

SipServerEntry  ::=  SEQUENCE {
sipServerIndex  DisplayString,
sipServerT1TimeoutInterval  Counter64,
sipServerT2TimeoutInterval  INTEGER,
sipServerT4TimeoutInterval  INTEGER,
.....
}

アプリケーションまたはスクリプトが直接にMIB表列名のラベルを使用している場合は、このMIBの変更により下位互換性の問題が生じる場合があります。表名を先頭にするように、iso.org.dod.internet.private.enterprises.bea.wlss.sipServerTable.t1TimeoutIntervalのようなハード・コード化されたラベルをすべて変更する必要があります(iso.org.dod.internet.private.enterprises.bea.wlss.sipServerTable.sipServerT1TimeoutInterval)。

注意:
常に、クライアント側のSNMPツールによってMIBがロードされ、MIBのロードされたラベルに基づく値を取得するコマンドが発行されます。これらのツールは上記の変更に影響を受けません。
Oracle WebLogic Server SIP Containerの完全なMIBファイルは、$WLSS_HOME/server/lib/wlss/BEA-WLSS-MIB.asn1としてインストールされます。

C.10 改名された診断モニターと診断アクション

Oracle WebLogic Server SIP Containerで提供される診断モニターと診断アクションの先頭に、occas/が付加されるようになりました。たとえば、SIP Server 3.1 Sip_Servlet_Before_Serviceモニターはoccas/Sip_Servlet_Before_Serviceと名付けられます。接頭辞が付いていない既存の診断構成ファイルまたはアプリケーションは、Oracle WebLogic Server SIP Containerで使用する前に更新する必要があります。

索引

A  B  C  D  H  L  O  P  R  S  U

A

アプリケーション構成, 5.1

アプリケーション・ルーター, 5.1

カスタムの構成, 5.3

ロールの割当て

デプロイメント時, 6.6.2

動的, 6.6.2

属性値ペア(AVP), 8.7 AVP, 8.7

B

バッファ, 4.7

C

CDF, 11.1

チャージング

イベントベース, 11.2.1, 11.4.3

オフライン・チャージングAPI, 11.4

セッションベース, 11.2.2, 11.4.2, 12.6

チャージング・データ機能(CDF), 11.1 チャージング・トリガー機能(CTF), 11.1, 12.1 作成されたドキュメント・キー, 9.5 コンテンツの間接化, 3.2 コンバージド・アプリケーション, 2.1 ConvergedHttpSessionオブジェクト, 2.3 クレジット認証モデル, 12.2 CTF, 11.1, 12.1

D

デフォルト・アプリケーション・ルーター(DAR), 5.2

Diameter

API, 概要, 8.2

属性値ペア(AVP), 8.7

コンバージドDiameterとSIPアプリケーションの作成

SIPアプリケーション, 8.8

クレジット管理リクエスト(CCR)メッセージ, 12.4, 12.6.1 アプリケーションの実装, 8.4 メッセージ, 8.6 ノード, 8.3 オフライン・チャージングAPI, 11.4 プロトコル・パッケージ, 8.1 Rfアプリケーション, 構成, 11.3 Rfインタフェース, 11.1 Roインタフェース, 12 セッション, 8.5 Shインタフェースのサポート, 9.1 Diameterアプリケーション, 8 Diameter Rfインタフェース, 11.1 Diameter Roアプリケーション

構成, 12.3

Diameter Roインタフェース, 12 Diameter Shインタフェース

ProfileListenerによるデータのモニター, 9.6

Diameter Shプロファイル・サービス, 9 分散型アプリケーション, 4.1 ドキュメント・セレクタ・キー, 9.4

H

ヘッダー, 3.1

L

ログ・レコード

トークン, 7.2.2

ロギング, 7.1

メッセージ・ロギングの有効化, 7.2

メッセージ・ログ構成と出力の例, 7.4

SIPメッセージのロギングする部分の特定, 7.2

レベル, 7.2

ログ・ファイルのローテーション, 7.5

ログ・レコード, カスタマイズ, 7.2.2

コンテンツ・タイプの指定, 7.3

O

OCF, 12.1

オフライン・チャージングAPI, 11.4

オンライン・チャージングAPI, 12.4

オンライン・チャージング機能(OCF), 12.1

P

移植, 4.1

プロファイル・サービスAPI, 9

R

レスポンス・コード, 6.2

RFC 4006, 12.1, 12.2

ロール・マッピング, 6.4

S

セキュリティ, 6.1

デバッグ, 6.9

セキュリティ・レルム, 6.3 セキュリティ・ロールの定義, 6.4 セッションの有効期限, 4.10 セッション・キー・ベースのターゲット, 5.4 SIPアプリケーション

非同期アクセス, 2.3.1.2

ベスト・プラクティス, 4

分散型アプリケーションの開発, 4.1

セッション・データ, 4.5

セッションの有効期限, 4.10

セッションへのアプリケーション・データの格納, 4.4

同期アクセス, 2.3.1.1

setAttributeによるセッション・データの変更, 4.6

SIPメッセージ

圧縮および長いヘッダー・フォーマットの使用, 3.1

SIPレスポンス・コード, 6.2 SIPサーブレット

コンテンツの間接化, 内部, 3.2

配布可能としてマーク, 4.8

非ブロッキングとする要件, 4.3

セキュリティ, 6.1

仕様, 5.2, 5.4

SipApplicationRouterインタフェース, 5.1 SipApplicationSessionオブジェクト, 2.3 SIPApplicationSessionActivationListener, 4.9 SIPServletMessageインタフェース, 3.1 sip.xml, 6.3, 6.5, 6.6.1 SNMPトラップ, 3.3 仕様

SIPサーブレット, 5.4

U

ユーザー・エージェント・サーバー(UAS), 5.1

Copyright © 2006, 2009, Oracle and/or its affiliates. All rights reserved.