リリース ノート

Oracle Communications Converged Application Server の機能と変更点

Oracle Communications Converged Application Server リリース 4.0 へようこそ！Oracle Communications Converged Application Server は、SIP サーブレット 1.1 技術と Java EE5 (JEE5) をはじめとする主要なインターネット標準を統合して、可用性、スケーラビリティ、およびセキュリティに優れた通信アプリケーションを開発するための信頼性の高いフレームワークを提供します。Oracle Communications Converged Application Server によって、種類の異なるプラットフォームやアプリケーションがシームレスに統合されるため、ネットワークで既存のソフトウェア資産を活用し、次世代テレフォニ アプリケーションの構築に不可欠なエンタープライズ クラスのサービスとデータを共有することができます。

以下のセクションは Oracle Communications Converged Application Server リリース 4.0 における新機能と変更点について説明します。

Oracle Communications Converged Application Server の新機能

ここでは、Oracle Communications Converged Application Server で導入された新機能について説明します。

Oracle WebLogic Server 10g リリース 3 に基づく

Oracle Communications Converged Application Server はコア Oracle WebLogic Server 10g リリース 3 製品にデプロイされています。これは、複数のキー機能、たとえばより優れた Administration Console、迅速かつフレキシブルなデプロイメント モデル、新しい診断能力、および EJB 3.0 サポートなどを導入します。Oracle WebLogic Server 10g リリース 3 ドキュメントの「WebLogic Server の新機能」を参照してください。

Oracle Communications Converged Application Server でサポートしているファイルは、BEA ホーム ディレクトリ内の WLSS_HOME ディレクトリに格納されています (たとえば、c:\bea\wlcserver_10.3)。これは、WL_HOME ディレクトリに格納されている必要な Oracle WebLogic Server 10g リリース 3 ファイルから分離されています (たとえば、c:\bea\wlserver_10.3)。

改訂文書は必要に応じて WLSS_HOME と WL_HOME ディレクトリを区別します。

SIP サーブレット 1.1 仕様 (JSR 289)

Oracle Communications Converged Application Server は、SIP サーブレット 1.1 仕様 (JSR 289) に準拠している堅牢な SIP コンテナを提供します。SIP サーブレット 1.1 仕様では、1.0 仕様に比べて以下のような多くの新機能が導入されています。

新しい SIP サーブレット API およびコンテナの機能性のための完全ガイドについては、「SIP サーブレット v1.1 仕様」を参照してください。下位互換性および既存の v1.0 SIP サーブレットのポーティングの詳細については、『SIP アプリケーションの開発』の「既存のアプリケーションの Oracle Communications Converged Application Server へのポーティング」を参照してください。

アノテーションとリソース インジェクション

Oracle Communications Converged Application Server は、SIP サーブレット 1.1 仕様で説明されているメタデータ アノテーションに加えて、デプロイメントおよびリソース インジェクションのために JSR 250 および JSR 154 からのアノテーションのサブセットをサポートします。サポート対象のアノテーションは、「表 1-1」および「表 1-2」に説明されています。

このリリースでサポートされている新しい SIP サーブレットに関するアノテーションの詳細については、「SIP サーブレット 1.1 仕様」も参照してください。

未承諾 NOTIFY メッセージのサポート

RFC 3265 への準拠を完全にするために、Oracle Communications Converged Application Server では、アプリケーションが未承諾 NOTIFY メッセージを受信してサブスクリプションと関連付けることができるようになりました。このリリースより前では、Oracle Communications Converged Application Server は未承諾 NOTIFY メッセージを 481 Subscription does not exist メッセージによって拒否します。

グローバルにルーティング可能なユーザ エージェント URI (GRUU) の更新したサポート

Oracle Communications Converged Application Server は、最新の「draft-ietf-sip-gruu-15: Session Initiation Protocol (SIP) におけるグローバルにルーティング可能なユーザ エージェント (UA) URI (GRUU) の取得と使用」に記載されているように、グローバルにルーティング可能なユーザ エージェント URI (GRUU) の取得と使用のための要件を満たしています。

SNMP の変更

Oracle Communications Converged Application Server は、Oracle WebLogic Server 10g リリース 3 によって提供された新しい SNMP 実装を使用します。SNMP をコンフィグレーションするには、ドメインで各エンジンおよび SIP データ層サーバ (必要に応じて、管理サーバ) に対して専用のサーバ SNMP エージェントを作成する必要があります。

ポートがすでに使用中である場合、Oracle Communications Converged Application Server は SNMP ポート番号を自動的にインクリメントしません。代わりに、各エージェントが一意のポート番号でコンフィグレーションされていることを確認する必要があります。また、SNMP エージェント コンフィグレーションをオーバーライドするために -DWLSS.SNMPAgentPort Java オプションは使用できません。

『操作ガイド』の「SNMP のコンフィグレーション」を参照してください。

改名した診断モニタおよびアクション

Oracle Communications Converged Application Server で提供されている診断モニタおよび診断アクションの名称は、プレフィックス occas/ が付けられました。たとえば、WebLogic SIP Server 3.1 Sip_Servlet_Before_Service モニタは、occas/Sip_Servlet_Before_Service という名前になりました。プレフィックスがない名前を参照する既存のどのような診断コンフィグレーション ファイルやアプリケーションも、Oracle Communications Converged Application Server で使用する前に更新する必要があります。

『操作ガイド』の「WebLogic Server 診断フレームワーク (WLDF) の使用」を参照してください。

example インストールの変更

Oracle Communications Converged Application Server example アプリケーションは、デフォルトでインストールされません。example アプリケーションをインストールするには、カスタム インストールを実行して製品のコンポーネント リストから example を選択します。

インストールすると、Oracle Communications Converged Application Server example は、WLSS_HOME/samples ディレクトリに保存されます (たとえば、~/bea/wlcserver_10.3/samples/sipserver/examples)。

専用の example ドメイン テンプレートはこのリリースで含まれていません。代わりに、sipserverdomain.jar を使用して基本的な単一のサーバ ドメインを作成します。その後、必要に応じて、個別の example アプリケーションを構築してデプロイします。

example のインストールと新しいドメインのコンフィグレーションの詳細については、『インストール ガイド』を参照してください。example の構築および実行の詳細については、WLSS_HOME/samples/sipserver/examples/src/index.html にある example のドキュメントを参照してください。

WebLogic SIP Server 3.x の新機能

このセクションでは、前のリリース WebLogic SIP Server 3.0 および 3.1 で導入された主な新機能についてまとめます。

WebLogic 診断フレームワークとの統合

WebLogic SIP Server は WebLogic 診断フレームワーク （WLDF） との統合により、より優れたデータ収集およびロギング、監視および通知、診断イメージ キャプチャ、コード使用を提供します。操作ガイドの「WebLogic 診断フレームワーク (WLDF) の使用」を参照してください。

対称応答ルーティング （RFC 3581 rport パラメータ）

WebLogic SIP Server 3.1 は、対称応答ルーティングに対して RFC 3581 に記載されている rport パラメータをサポートしています。rport パラメータがあるメッセージを受信すると、サーバは Via ヘッダに指定されているポート番号でなく、そのメッセージを受信したリモート UDP ポート番号を使用して応答します。UAC として作動するときに、rport パラメータを Via ヘッダに自動で追加するように、WebLogic SIP Server をコンフィグレーションすることもできます。『コンフィグレーション リファレンス マニュアル』の「enable-rport」を参照してください。

ドメイン エリアス

WebLogic SIP Server 3.1 では、サーバによって制御するドメイン (複数可) をコンフィグレーションできます。ドメイン エリアス コンフィグレーションにより、潜在的なプロキシ問題が回避され、 特定のサーバのインストールに対するドメイン処理サポートが明確になります。『コンフィグレーション リファレンス マニュアル』の「domain-alias-name」を参照してください。

SIP および Diameter ネットワーク チャネル用の追加モニタ機能

Administration Console を使用して、WebLogic SIP Server ネットワーク チャネル （sip、sips、diameter、diameters および diameter-sctp チャネル） の動作をモニタすることができます。SIP および Diameter チャネルをモニタするには、次の操作を行います。

WebLogic SIP Server チャネルは、Connections、Messages Received、Messages Sent、Bytes Received、Bytes Sent 属性についてのみ統計を表示します。

古くなったセッションのコンフィグレーション可能な処理

WebLogic SIP Server は、エンコードされた URI を使用して、メッセージに関連付けられた呼び出し状態およびアプリケーション セッションを識別します。アプリケーションがアンデプロイされるか、新しいバージョンにアップグレードされると、着信リクエストには「古くなった」か存在しない呼び出しやセッション ID を指定するエンコードされた URI がある可能性があります。WebLogic SIP Server 3.1 では、リクエスト内に古くなったセッション データが存在している場合のサーバのアクションをコンフィグレーションすることができます。『コンフィグレーション リファレンス マニュアル』の「stale-session-handling」を参照してください。

WebLogic SIP Server において追加した SIP ヘッダとパラメータの一覧

WebLogic SIP Server では、さまざまな機能をサポートするために、1 つまたは複数の SIP ヘッダおよびパラメータを既存の SIP メッセージに追加することができます。すべてのネットワーク機能において、これらのヘッダおよびパラメータが変更されることなく SIP サーバ インスタンスに渡されるようにする必要があります。または、必要に応じて、Session Border Control 機能がこの情報をアーカイブ/リストアすることができます。

表 1-3 および表 1-4 には、WebLogic SIP Server が SIP メッセージに追加できる情報が記載されています。

地理的に冗長な永続性

複数の地域データ センターがあり、現地サイトに壊滅的な障害が発生した場合でも継続的な稼動が必要な顧客のために、WebLogic SIP Server は地理的に冗長なコンフィグレーションでインストールすることができます。地理的に冗長なコンフィグレーションは、複数の Weblogic SIP Server インストール （エンジンおよび SIP データ層クラスタ） を有効にし、インストール間の呼び出し状態トランザクションをレプリケートします。そのため、管理者は特定の地域のサイトで障害が発生したと判断した場合、レプリケートされたセカンダリのサイトにすべてのネットワークトラフィックをリダイレクトし、呼び出しの損失を最小限にくい止めることができます。『WebLogic SIP Server のコンフィグレーションと管理』の「地理的に冗長なインストールのコンフィグレーション」を参照してください。

Diameter 基本プロトコルおよび IMS Ro、Rf インタフェースのサポート

WebLogic SIP Server 2.2 に導入されている Diameter Sh プロトコル プロバイダに加え、バージョン 3.0 には Ro および Rf プロトコルのための新しいプロバイダが含まれています。追加の Diameter アプリケーションを実装する必要のある開発者のために、Diameter 基本プロトコルの実装も利用可能です。詳細については、『WebLogic SIP Server によるアプリケーション開発』の次のリンクを参照してください。

エンジン層におけるキャッシュ

SIP データ層レプリカ内の SIP 呼び出し状態データの一部をエンジン層でキャッシュすることができるようになりました。SIP-アウェア ロード バランサと組み合わせて使用すると、キャッシュにより呼び出し状態データへのアクセスのパフォーマンスが向上します。『WebLogic SIP Server のコンフィグレーションと管理』の「エンジン層でのキャッシュの有効化」を参照してください。

長期間維持する呼び出し状態データの RDBMS への格納

WebLogic SIP Server 3.0 では、長期間維持する呼び出し状態データを Oracle RDBMS に格納して RAM を節約することができます。呼び出しダイアログの確立後、SIP データ層では呼び出し状態のデータを RDBMS に永続化し、呼び出し状態を変更または削除するために、必要に応じて永続化された呼び出し状態データを取得または削除します。Oracle では、アプリケーション設計者用の API を用意し、どのようなときに呼び出し状態データを SIP データ層に保持すべきかについての「ヒント」を提供しています。『WebLogic SIP Server のコンフィグレーションと管理』の「RDBMS への呼び出し状態データの格納」を参照してください。

JRockit の確定的ガベージ コレクションを使用したトランザクション レイテンシの最小化

WebLogic SIP Server は「リアルタイム」なコンフィグレーションで使用するようにできます。このようなコンフィグレーションでは、JRockit の確定的ガベージ コレクタを使用して SIP トランザクションのレイテンシ パフォーマンスを大幅に改善します。ガベージ コレクタを有効にするには、『コンフィグレーション ガイド』の「JRockit の確定的ガベージ コレクションの使用」を参照してください。

コンバージド SIP/HTTP アプリケーションのプロダクション環境でのアップグレード

WebLogic SIP Server 3.0 は、コンバージド SIP/HTTP アプリケーションのためのアプリケーション アップグレード サポートを提供します。アプリケーション アップグレード サポートは WebLogic Server 9.2 におけるアップグレード サポートを厳密にモデル化しており、プロダクション環境でアプリケーションを安全にテストするために使用できる SIP の管理チャネルを提供します。『操作ガイド』の「デプロイ済み SIP アプリケーションのアップグレード」を参照してください。

Diameter 用の SCTP サポート

WebLogic SIP Server では、Diameter ネットワーク トラフィックのために、一定のオペレーティング システムについて SCTP トランスポート プロトコルをサポートします。『ネットワーク リソースのコンフィグレーション』の「Diameter クライアント ノードとリレー エージェントのコンフィグレーション」を参照してください。

プロキシ検出と応答ルーティングのための DNS サポート

WebLogic SIP Server 3.0 では、RFC 3263 に記載されているように、SIP メッセージを送信するために必要なトランスポート、IP アドレス、およびプロキシのポート番号を解決する DNS をサポートしています。また、DNS は宛先の IP アドレスおよびポート番号を解決するために応答をルーティングするときにも使用できます。バージョン 3.0 以前のバージョンでは、DNS 解決は個別の UA またはプロキシ アプリケーションで実行する必要がありました。

「ネットワーク リソースのコンフィグレーション」の「DNS サポートの有効化」を参照してください。

IPv6 サポート

WebLogic SIP Server では、「RFC 2460: インターネット プロトコル、バージョン 6 (IPv6) 仕様書」に記載されているように、外部ネットワーク インタフェース用の IPv6 をサポートしています。IPv6 を使用するには、基盤のオペレーティング システムがプロトコルをサポートしていなければなりません。さらに、すべてのエンジン層サーバ ノードについて IPv6 ネットワーク チャネルをコンフィグレーションする必要があります。「ネットワーク リソースのコンフィグレーション」の「IPv4 および IPv6」を参照してください。

コンフィグレーション可能なサーバ ヘッダ

管理者は、必要に応じて WebLogic SIP Server が SIP メッセージ本文に挿入するサーバ ヘッダのコンテンツをコンフィグレーションすることができます。ヘッダ コンテンツ全体を省略して、ワイヤレス ネットワークのメッセージ サイズを小さくすることもできます。または、任意の文字列値を設定することも可能です。バージョン 3.0 以前のバージョンでは、ヘッダは常に WebLogic SIP Server インスタンス名とバージョンとともに挿入されていました。『コンフィグレーション リファレンス』の「server-header」および「server-header-value」を参照してください。

SIP メッセージ ヘッダ フォーマットのコンフィグレーション

WebLogic SIP Server では、生成される SID メッセージに関し圧縮ヘッダ フォームを使用するか長いヘッダ フォームを使用するかを制御するために、フレキシブルなコンフィグレーション パラメータを提供します。ヘッダ フォームのルールは、次の 3 つのレベルで設定できます。

WlssSipServletResponse.setUseHeaderForm を SipServletMessage.setHeader およびコンテナ レベル コンフィグレーションと組み合わせて使用して、ヘッダ フォーマットをカスタマイズすることができます。それぞれの設定が相互にどのように作用するかについての詳細は、『アプリケーションの開発』の「SIP メッセージにおける圧縮および長いヘッダ フォーマットの使用」を参照してください。

TelURL 解決のための拡張 API

WebLogic SIP Server は、com.bea.wcp.sip.WlssTelURI インタフェースで javax.servlet.sip.TelURL インタフェースを拡張します。拡張インタフェースにより、SIP URI のユーザ部分に存在する Tel URL の解決が可能になります。RFC 3761 に記載されているように、API では標準サフィックス e164.arpa を使用して Tel URL をドメイン名に解析します。その後、DNS NAPTR レコード検索を実行して、ENUM NAPTR レコード セットを作成します。

たとえば、4.3.2.1.5.5.5.5.1.4.1.e164.arpa の Tel URL ドメイン名について、API は DNS 検索を実行し、以下と似たような ENUM NAPTR レコード セットを取得します。

$ORIGIN 4.3.2.1.5.5.5.5.1.4.1.e164.arpa

    IN NAPTR 100 10 "u" "E2U+sip"    "!^.*$!sip:user@example.com!"   

    IN NAPTR 100 20 "u" "E2U+mailto" "!^.*$!mailto:info@example.com!"

WlssTelURI インタフェース内のメソッドは、完全な ENUM レコード セット、レコード セット内に存在する SIP URI の配列、またはレコード セット内に存在する最優先の SIP URI のいずれかを返します。JavaDoc の com.bea.wcp.sip.WlssTelURI を参照してください。

SAR ファイル デプロイメント

WebLogic SIP Server 3.0 は、SAR ファイル形式でのアプリケーションのデプロイメントをサポートします。SAR ファイルは形式としては WAR ファイルと似ており、HTTP サーブレットおよび SIP サーブレットの両方についてのデプロイメント記述子情報を保持できます。SAR ファイルに weblogic.xml デプロイメント記述子を含める必要はありません。

拡張プロファイル API

WebLogic SIP Server にはパブリック プロファイル サービス API (com.bea.wcp.sip.profile.API) が含まれています。この API を使用して、プロファイル プロバイダの実装を作成することができます。プロファイル プロバイダは、定義されたプロトコルを使用してデータ リポジトリから XML ドキュメントへのアクセスを実行します。デプロイ済みの SIP サブレットやその他のアプリケーションが、基盤のプロトコルまたはドキュメントが保存されているデータ リポジトリについて認識している必要はありません。単純にプロバイダ API を使ったカスタム URL でプロファイル データを参照すれば、WebLogic SIP Server がリクエストの処理を正しいプロバイダに委託します。『WebLogic SIP Server によるアプリケーション開発』の「カスタム プロファイル プロバイダの開発」を参照してください。

TCP 接続を再利用するための接続プール

WebLogic SIP Server には、SBC (Session Border Control) 機能または S-CSCF (Serving Call Session Control Function) との不必要な通信を最小限に抑える新しい接続プール メカニズムが備わっています。サーバは、運用中、接続の切断と再確立を繰り返す代わりに、接続の固定プールをコンフィグレーション済みの SBC または S-CSCF に多重送信します。『コンフィグレーション リファレンス』の「connection-reuse-pool」を参照してください。

グローバルにルーティング可能なユーザ エージェント URI (GRUU) のサポート

WebLogic SIP Server は、「draft-ietf-sip-gruu-10: Session Initiation Protocol (SIP) におけるグローバルにルーティング可能なユーザ エージェント (UA) URI (GRUU) の取得と使用」に記載されているように、グローバルにルーティング可能なユーザ エージェント URI (GRUU) を取得および使用するための要件を満たしています。

ネットワーク要素として動作するときは GRUU を使用するように WebLogic SIP Server に指定するには、『コンフィグレーション リファレンス マニュアル』の「globally-routable-uri」を参照してください。