WebLogic Communication Services 管理ガイド

11g リリース 1 (11.1.1)

B55505-01(原本部品番号:E13806-01)

目次

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

はじめに

- 対象読者

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

- 関連ドキュメント

- 表記規則

第 I 部 一般的なコンフィグレーション

1 Oracle WebLogic Communication Services の概要

- 1.1 Oracle WebLogic Communication Services

- 1.1.1 メッセージング

- 1.1.2 テレフォニ

- 1.1.3 プレゼンス

- 1.1.4 SIP およびコンバージド アプリケーションをサポートする WebLogic Server 10.3 プラットフォーム

2 共通のコンフィグレーション タスク

- 2.1 Oracle WebLogic Communication Services と Oracle WebLogic Serverで共通のコンフィグレーション タスク

- 2.2 Oracle WebLogic Communication Services のコンフィグレーションの概要

- 2.2.1 Diameter のコンフィグレーション

- 2.3 コンフィグレーション タスクを実行するための方法とツール

- 2.3.1 Administration Console

- 2.3.2 WebLogic Scripting Tool (WLST)

- 2.3.3 その他のコンフィグレーション方法

- 2.3.3.1 コンフィグレーション ファイルの編集

- 2.3.3.2 カスタム JMX アプリケーション

- 2.4 サーバの起動と停止

- 2.5 管理サーバのベスト プラクティス

- 2.6 一般的なコンフィグレーション タスク

3 SIP サーブレット コンテナ プロパティのコンフィグレーション

- 3.1 SIP コンテナのコンフィグレーションの概要

- 3.2 Administration Console によるコンテナ プロパティのコンフィグレーション

- 3.2.1 コンフィグレーションのロックと永続化

- 3.3 WLST (JMX) によるコンテナ プロパティのコンフィグレーション

- 3.3.1 コンフィグレーション ロックの管理

- 3.3.2 Oracle WebLogic Communication Services の MBean へのアクセス

- 3.4 WLST のコンフィグレーション

- 3.4.1 WLST の起動

- 3.4.2 MBean の作成と削除

- 3.5 タイマー処理のコンフィグレーション

- 3.5.1 Timer Affinity のコンフィグレーション (省略可能)

- 3.5.2 SIP タイマーの正確な同期に必要な NTP のコンフィグレーション

4 ネットワーク リソースの管理

- 4.1 ネットワーク コンフィグレーションの概要

- 4.1.1 IPv4 と IPv6

- 4.2 ロード バランサのアドレスのコンフィグレーション

- 4.2.1 複数のロード バランサおよびマルチホームのロード バランサを使用する場合

- 4.3 DNS サポートの有効化

- 4.4 SIP または SIPS のネットワーク チャネルのコンフィグレーション

- 4.4.1 既存チャネルの再コンフィグレーション

- 4.4.2 新しい SIP または SIPS チャネルの作成

- 4.4.3 カスタム タイムアウト、MTU および他のプロパティのコンフィグレーション

- 4.4.4 マルチホーム マシンの SIP チャネルのコンフィグレーション

- 4.5 Diameter をサポートするための TCP および TLS チャネルのコンフィグレーション

- 4.6 エンジン サーバで任意の IP インタフェースでリスンする場合のコンフィグレーション

- 4.7 SIP データ層レプリカの一意なリスン アドレス属性のコンフィグレーション

- 4.8 プロダクション環境のネットワーク アーキテクチャとコンフィグレーション

- 4.8.1 TCP チャネルおよび UDP チャネルを使用する単一 NIC のコンフィグレーション

- 4.8.1.1 発信 UDP パケット用の静的ポートのコンフィグレーション

- 4.8.2 マルチホーム サーバのコンフィグレーションの概要

- 4.8.3 すべてのアドレス (IP_ANY) でリスンするマルチホーム サーバ

- 4.8.4 複数のサブネットでリスンするマルチホーム サーバ

- 4.8.4.1 ルート リゾルバについて

- 4.8.4.2 マルチホーム ハードウェアにおける IP エリアス

- 4.8.5 ロード バランサのコンフィグレーション

- 4.8.5.1 単一のロード バランサのコンフィグレーション

- 4.8.5.2 複数のロード バランサおよびマルチホームのロード バランサを使用する場合

- 4.8.5.3 ネットワーク アドレス変換の選択肢

- 4.9 ネットワーク コンフィグレーションの例

- 4.9.1 ネットワーク トポロジの例

- 4.9.2 Oracle WebLogic Communication Services のコンフィグレーション

- 4.9.3 ロード バランサのコンフィグレーション

- 4.9.3.1 NAT ベースのコンフィグレーション

- 4.9.3.2 maddr ベースのコンフィグレーション

- 4.9.3.3 rport ベースのコンフィグレーション

5 セキュリティ機能の管理

- 5.1 SIP サーブレットの認証

- 5.1.1 認証プロバイダ

- 5.2 信頼できるホストでの認証のオーバーライド

- 5.3 ID アサーション サポート

- 5.4 SIP サーブレット宣言型セキュリティのロールの割り当て

- 5.5 セキュリティ イベントの監査

- 5.6 一般的なセキュリティ コンフィグレーション タスク

- 5.7 ダイジェスト認証のコンフィグレーション

- 5.7.1 ダイジェスト認証とは

- 5.7.2 Oracle WebLogic Communication Services でのダイジェスト認証のサポート

- 5.7.3 LDAP ダイジェスト認証のコンフィグレーションの前提条件

- 5.7.4 ダイジェスト認証のコンフィグレーションの手順

- 5.7.4.1 LDAP サーバまたは RDBMS のコンフィグレーション

- 5.7.4.2 DefaultAuthenticator プロバイダのコンフィグレーションの変更

- 5.7.4.3 認証プロバイダのコンフィグレーション

- 5.7.4.4 新しいダイジェスト ID アサーション プロバイダのコンフィグレーション

- 5.7.5 組み込み LDAP を使用したダイジェスト認証のコンフィグレーションのサンプル

- 5.7.5.1 記述フィールドへのユーザ パスワード情報の格納

- 5.7.5.2 組み込み LDAP のパスワードの設定

- 5.7.5.3 ダイジェスト ID アサーション プロバイダのコンフィグレーション

- 5.8 Client-Cert 認証のコンフィグレーション

- 5.8.1 Oracle WebLogic Communication Services での SSL と X509 のコンフィグレーション

- 5.8.1.1 デフォルト ID アサーション プロバイダのコンフィグレーション

- 5.8.1.2 LDAP X509 ID アサーション プロバイダのコンフィグレーション

- 5.8.2 Oracle WebLogic Communication Services での WL-Proxy-Client-Cert のコンフィグレーション

- 5.8.3 カスタム ID アサーション プロバイダによる境界認証のサポート

- 5.9 SIP サーブレット ID アサーション メカニズムのコンフィグレーション

- 5.9.1 P-Asserted-Identity による信頼できるホストへの転送について

- 5.9.2 厳密および非厳密な P-Asserted-Identity アサーション プロバイダの概要

- 5.9.3 P-Asserted-Identity アサーション プロバイダのコンフィグレーション

- 5.9.4 Identity ヘッダと Identity-Info ヘッダによる ID アサーションについて

- 5.9.5 Identity ヘッダ アサーション プロバイダのコンフィグレーション

- 5.10 3GPP HTTP ID アサーション プロバイダのコンフィグレーション

- 5.10.1 X-3GPP-Asserted-Identity プロバイダのコンフィグレーション

- 5.11 HTTP サーブレットの基本認証のコンフィグレーション

- 5.12 Oracle Internet Directory でのリソースのプロビジョニング

- 5.12.1 Oracle Internet Directory のコンフィグレーション

- 5.12.2 静的検証機能のコンフィグレーション

- 5.12.2.1 Oracle WebLogic Communication Services の追加

- 5.12.2.2 静的検証機能のインストール

- 5.12.3 新しい Oracle WebLogic Communication Services の追加

- 5.12.4 Oracle WebLogic Communication Services インスタンスへの検証権限の付与

- 5.13 ユーザのプロビジョニング

- 5.13.1 新しいユーザの作成

- 5.13.2 グループの作成

- 5.13.3 ユーザへのグループ メンバシップの割り当て

- 5.13.4 ユーザの JAAS レルムの設定

- 5.14 OWLCS サーバ インスタンスのコンフィグレーション

- 5.14.1 LDAP 認証の追加 (ロールの設定)

- 5.14.2 LDAP 認証のパフォーマンスの向上

- 5.14.3 OID で使用する Userservice のコンフィグレーション

6 SIP データ層のパーティションとレプリカのコンフィグレーション

- 6.1 SIP データ層のコンフィグレーションの概要

- 6.1.1 datatier.xml コンフィグレーション ファイル

- 6.1.2 コンフィグレーションの要件と制約

- 6.2 SIP データ層サーバのコンフィグレーションと管理のベスト プラクティス

- 6.3 SIP データ層のコンフィグレーションとコンフィグレーション ファイルの例

- 6.3.1 単一パーティションの SIP データ層

- 6.3.2 2 つのパーティションの SIP データ層

- 6.3.3 2 つのパーティション、2 つのレプリカの SIP データ層

- 6.4 長期間維持する呼状態データの RDBMS への格納

- 6.4.1 要件と制約

- 6.4.2 RDBMS への呼状態の格納を有効にする手順

- 6.4.3 コンフィグレーション ウィザード RDBMS 格納テンプレートの使用

- 6.4.3.1 JDBC データソース接続情報の変更

- 6.4.4 RDBMS への呼状態の格納の手動コンフィグレーション

- 6.4.4.1 JDBC リソースのコンフィグレーション

- 6.4.4.2 Oracle WebLogic Communication Services 永続性オプションのコンフィグレーション

- 6.4.4.3 データベース スキーマの作成

- 6.4.5 SIP アプリケーションでの永続性ヒントの使用

- 6.5 地理的な冗長性の導入

- 6.5.1 地理的冗長性を使用するのに最も適切な場面

- 6.5.2 地理的冗長性を使用するのに不適切な場面

- 6.5.3 地理的冗長性の考慮事項 : 始める前に

- 6.6 地理的に冗長な SIP データ層の使用

- 6.6.1 ドメイン コンフィグレーションの例

- 6.6.2 要件と制約

- 6.6.3 地理的永続性のコンフィグレーションの手順

- 6.6.4 地理的永続性のコンフィグレーション ウィザード テンプレートの使用

- 6.6.4.1 プライマリ サイトのインストールとコンフィグレーション

- 6.6.4.2 セカンダリ サイトのインストール

- 6.6.5 地理的冗長性の手動コンフィグレーション

- 6.6.5.1 JDBC リソースのコンフィグレーション (プライマリおよびセカンダリ サイト)

- 6.6.5.2 永続性オプションのコンフィグレーション (プライマリおよびセカンダリ サイト)

- 6.6.5.3 JMS リソースのコンフィグレーション (セカンダリ サイトのみ)

- 6.6.6 地理的冗長性のレプリケーションの動作について

- 6.6.6.1 呼状態のレプリケーションの処理

- 6.6.6.2 フェイルオーバ後の呼状態の処理

- 6.6.7 呼状態のバックアップの削除

- 6.6.8 地域的サイト全体のレプリケーションのモニタ

- 6.6.9 地理的レプリケーションのトラブルシューティング

- 6.7 エンジン層での SIP データのキャッシング

- 6.7.1 エンジン層キャッシングのコンフィグレーション

- 6.7.2 キャッシュ パフォーマンスのモニタとチューニング

- 6.8 SIP データ層サーバのモニタとトラブルシューティング

7 Sash によるユーザのプロビジョニング

- 7.1 Sash の概要

- 7.2 Sash の起動

- 7.2.1 コマンドラインからの Sash の起動

- 7.2.2 外部の OWLCS インスタンスへの Sash の接続

- 7.2.2.1 OWLCS の外部インスタンスへの接続

- 7.3 Sash の使用方法

- 7.3.1 使用できるコマンドの表示

- 7.3.1.1 サブコマンドの表示

- 7.4 ユーザの作成

- 7.4.1 Sash コマンドライン プロンプトからのユーザの作成

- 7.4.2 Command Service MBean でのユーザの作成

- 7.4.3 identity add コマンドによるユーザの作成

- 7.4.3.1 identity delete コマンドによるユーザ アカウントの削除

- 7.5 Sash を使用した XDMS のプロビジョニング

- 7.5.1 CommandService MBean を使用した XDMS ユーザ アカウントのプロビジョニング

- 7.5.2 Sash プロンプトからの XDMS ユーザ アカウントのプロビジョニング

- 7.5.3 xcap コマンドの使用

- 7.5.3.1 XDMS ユーザ アカウントのプロビジョニング

- 7.5.3.2 XDMS ユーザの追加

- 7.5.3.3 XDMS ユーザの削除

- 7.5.3.4 XDMS ユーザのアプリケーション使用方法の検索

- 7.5.3.5 XDMS ユーザのリスト表示

- 7.5.3.6 アプリケーション使用方法のプロビジョニング

- 7.5.3.7 すべてのアプリケーション使用方法のリスト表示

- 7.6 Sash でのスクリプト作成

- 7.7 Sash でのエラー ロギング

8 モニタとトラブルシューティング

- 8.1 サーバ障害の回避とサーバ障害からの回復

- 8.1.1 障害回避機能と自動回復機能

- 8.1.1.1 オーバーロード保護

- 8.1.1.2 クラスタ化されたサービスの冗長性とフェイルオーバ

- 8.1.1.3 障害が発生したサーバ インスタンスの自動的な再起動

- 8.1.1.4 管理対象サーバ独立モード

- 8.1.1.5 障害が発生した管理対象サーバの自動移行

- 8.1.1.6 地域サイトの障害に対応する地理的冗長性

- 8.1.2 障害回復のためのディレクトリとファイルのバックアップ

- 8.1.2.1 自動コンフィグレーションのバックアップの有効化

- 8.1.2.2 ドメインのコンフィグレーション オフラインの格納

- 8.1.2.3 サーバ起動スクリプトのバックアップ

- 8.1.2.4 ロギング サーブレット アプリケーションのバックアップ

- 8.1.2.5 セキュリティ データのバックアップ

- 8.1.2.6 その他のオペレーティング システムのコンフィグレーション ファイルのバックアップ

- 8.1.3 障害の発生した管理サーバの再起動

- 8.1.3.1 同じマシンでの管理サーバの再起動

- 8.1.3.2 別のマシンでの管理サーバの再起動

- 8.1.4 障害の発生した管理対象サーバの再起動

- 8.2 フェイルオーバ検出の概要

- 8.2.1 WlssEchoServer による障害検出

- 8.2.2 障害が発生したレプリカの強制的な停止

- 8.3 物理的なネットワーク障害に対するフェイルオーバ パフォーマンスの向上

- 8.3.1 SIP データ層サーバ マシンでの WlssEchoServer の起動

- 8.3.2 サーバのハートビート メカニズムの有効化とコンフィグレーション

- 8.4 SNMP のコンフィグレーション

- 8.4.1 MIB の参照

- 8.4.2 SNMP のコンフィグレーション手順

- 8.5 SNMP トラップの概要と対処法

- 8.5.1 トラブルシューティングに役立つファイル

- 8.5.2 トラップの説明

- 8.5.2.1 connectionLostToPeer

- 8.5.2.2 connectionReestablishedToPeer

- 8.5.2.3 dataTierServerStopped

- 8.5.2.4 overloadControlActivated、overloadControlDeactivated

- 8.5.2.5 replicaAddedToPartition

- 8.5.2.6 replicaRemovedEnginesRegistration

- 8.5.2.7 replicaRemovedFromPartition

- 8.5.2.8 serverStopped

- 8.5.2.9 sipAppDeployed

- 8.5.2.10 sipAppUndeployed

- 8.5.2.11 sipAppFailedToDeploy

- 8.6 WebLogic 診断フレームワーク (WLDF) の使用

- 8.6.1 データ収集とロギング

- 8.6.2 監視と通知

- 8.6.3 イメージ キャプチャ

- 8.6.4 インスツルメンテーション

- 8.6.4.1 サーバ スコープ モニタのコンフィグレーション

- 8.6.4.2 アプリケーション スコープ モニタのコンフィグレーション

- 8.7 SIP リクエストと応答のロギング

- 8.7.1 sip.xml でのロギング サーブレットの定義

- 8.7.2 ロギング レベルと出力先のコンフィグレーション

- 8.7.3 ロギングするメッセージの条件の指定

- 8.7.3.1 XML ドキュメントを使ったロギング条件の指定

- 8.7.3.2 サーブレットのパラメータを使ったロギング条件の指定

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

- 8.7.5 ログ ローテーションの有効化とログ ファイルの参照

- 8.7.6 trace-pattern.dtd リファレンス

- 8.7.7 SIP サーブレット コードへの追跡機能の追加

- 8.7.8 リスナとロギング サーブレットの起動順序

- 8.8 プロダクション デプロイメントにおける JVM ガベージ コレクションのチューニング

- 8.8.1 サーバ起動スクリプトでの JVM パラメータの変更

- 8.8.2 JRockit を使用したガベージ コレクションのチューニング

- 8.8.3 Oracle JRockit Real Time の使用 (確定的ガベージ コレクション)

- 8.8.4 確定的ガベージ コレクションなしでの Oracle JRockit の使用

- 8.8.5 Sun JDK のガベージ コレクションのチューニング

- 8.9 乱数生成に伴う JVM の遅延の回避

第 II 部 Presence のコンフィグレーション

9 Presence および Presence Web Services のコンフィグレーション

- 9.1 プレゼンスの概要

- 9.2 プレゼンスのコンフィグレーション

- 9.2.1 XDMS のコンフィグレーション

- 9.2.2 Bus

- 9.2.3 PackageManager

- 9.2.4 Presence

- 9.2.5 PresenceEventPackage

- 9.2.6 PresenceWInfoEventPackage

- 9.2.7 UA-ProfileEventPackage

- 9.2.8 Command Service (XDMS プロビジョニング)

- 9.2.9 XCapConfigManager

- 9.2.10 Aggregation Proxy

- 9.2.11 OPTIONS 用のデフォルト アプリケーション ルータのコンフィグレーション

- 9.3 Presence Web Services のコンフィグレーション

- 9.3.1 PresenceSupplierWebService

- 9.3.2 PresenceConsumerWebService

- 9.3.3 MessagingWebServiceConfig

第 III 部 Diameter のコンフィグレーション

10 Diameter クライアント ノードとリレー エージェントのコンフィグレーション

- 10.1 Diameter プロトコルのコンフィグレーションの概要

- 10.2 Diameter クライアント ノードとリレー エージェントをコンフィグレーションする手順

- 10.3 Diameter ドメインのインストール

- 10.4 Diameter コンソール拡張の有効化

- 10.5 Diameter プロトコルの TCP、TLS、および SCTP ネットワーク チャネルの作成

- 10.5.1 Diameter TLS チャネル用の双方向 SSL のコンフィグレーション

- 10.5.2 Diameter メッセージングのため SCTP のコンフィグレーションと使用

- 10.6 Diameter ノードのコンフィグレーション

- 10.6.1 新しいノード コンフィグレーションの作成 (一般ノード コンフィグレーション)

- 10.6.2 Diameter アプリケーションのコンフィグレーション

- 10.6.2.1 Sh クライアント アプリケーションのコンフィグレーション

- 10.6.2.2 Rf クライアント アプリケーションのコンフィグレーション

- 10.6.2.3 Ro クライアント アプリケーションのコンフィグレーション

- 10.6.2.4 Diameter リレー エージェントのコンフィグレーション

- 10.6.2.5 Sh および Rf シミュレータ アプリケーションのコンフィグレーション

- 10.6.2.6 プロファイル サービスの有効化 (Sh バックエンドの使用)

- 10.6.3 ピア ノードのコンフィグレーション

- 10.6.4 ルートのコンフィグレーション

- 10.7 ドメインのコンフィグレーション例

- 10.8 Diameter コンフィグレーションのトラブルシューティング

第 IV 部 Oracle User Messaging Service

11 Oracle User Messaging Service のコンフィグレーション

- 11.1 User Messaging Service の概要

- 11.1.1 コンポーネント

- 11.1.2 アーキテクチャ

- 11.2 Oracle User Messaging Service のコンフィグレーションの概要

- 11.3 User Messaging Service コンフィグレーション ページへのアクセス

- 11.3.1 格納方法の設定

- 11.3.2 User Messaging Preferences のビジネス条件の追加または削除

- 11.3.2.1 ビジネス条件の追加

- 11.3.2.2 ビジネス条件の削除

- 11.4 User Messaging Service ドライバのコンフィグレーション

- 11.4.1 ドライバのコンフィグレーション方法

- 11.4.1.1 ドライバのパラメータについて

- 11.4.1.2 パスワードのセキュリティ保護

- 11.4.1.3 電子メール ドライバのコンフィグレーション

- 11.4.1.4 SMPP ドライバのコンフィグレーション

- 11.4.1.5 XMPP ドライバのコンフィグレーション

- 11.4.1.6 VoiceXML ドライバのコンフィグレーション

- 11.4.1.7 Worklist ドライバのコンフィグレーション

- 11.4.1.8 プロキシ ドライバのコンフィグレーション

- 11.5 User Messaging Service のセキュリティ

- 11.5.1 通知時の Web サービス セキュリティ

- 11.5.2 UMS サービス セキュリティの有効化

- 11.5.3 クライアントのセキュリティの有効化

- 11.5.4 キーストアのコンフィグレーション

- 11.5.5 クライアントのエリアス

- 11.6 Oracle User Messaging Service のトラブルシューティング

12 Oracle User Messaging Service のモニタ

- 12.1 Oracle User Messaging Service のモニタ

- 12.1.1 メッセージ ステータスの使用

- 12.1.2 メッセージ クライアント アプリケーションの登録解除

- 12.1.3 [すべて] タブを使用したドライバのモニタ

- 12.2 ログ ファイル

- 12.2.1 ロギングのコンフィグレーション

- 12.3 メトリックと統計値

13 Oracle User Messaging Service の管理

- 13.1 ドライバのデプロイ

- 13.1.1 WebLogic Server Administration Console の使用

- 13.1.2 Oracle Enterprise Manager を使用したドライバのデプロイ

- 13.1.3 WLST コマンドの使用

- 13.1.3.1 deployUserMessagingDriver

- 13.1.4 Oracle Fusion Middleware Configuration Wizard の使用

- 13.2 ドライバのアンデプロイと登録解除

第 V 部 SIP インフラストラクチャ アプリケーションの信任

14 SIP インフラストラクチャ アプリケーションのコンフィグレーション

- 14.1 Proxy Registrar

- 14.2 STUN サービス

第 VI 部 Oracle WebLogic Communication Services のデプロイ

15 Oracle WebLogic Communication Services 基本プラットフォーム トポロジ

- 15.1 Oracle WebLogic Communication Services 基本プラットフォームの目的

- 15.2 ロード バランサ

- 15.3 エンジン層

- 15.4 SIP データ層

- 15.4.1 呼状態データの記述と取得の例

- 15.4.2 長期間維持する呼状態データの RDBMS への格納

- 15.5 地理的に冗長なインストール

- 15.6 ハードウェア コンフィグレーションの例

- 15.7 他のコンフィグレーション

16 Communication Services のデプロイメント トポロジ

- 16.1 用語

- 16.2 OWLCS のデプロイメント トポロジ

- 16.2.1 単一ノード トポロジ

- 16.3 Oracle WebLogic Communication Services のエンタープライズ デプロイメント トポロジ

- 16.3.1 OWLCS エンタープライズ デプロイメント トポロジの概要

- 16.3.1.1 実行時の手順

- 16.3.1.2 リクエスト フロー

- 16.3.1.3 クライアントの接続

- 16.3.1.4 アーティファクト

- 16.3.1.5 トポロジのコンポーネント

- 16.3.1.6 SIP 状態層のコンフィグレーションの概要

- 16.3.1.7 SIP 状態層のコンフィグレーションとコンフィグレーション ファイルの例

- 16.3.1.8 長期間維持する呼状態データの RDBMS への格納

- 16.3.2 地理的な冗長性

- 16.3.3 フェイルオーバ

- 16.3.3.1 OWLCS プレゼンスのフェイルオーバ

- 16.3.3.2 プレゼンティティの移行

- 16.3.3.3 スタンバイ サーバ プール

- 16.3.3.4 障害の種類

- 16.3.3.5 フェイルオーバ アクション

- 16.3.3.6 オーバーロード ポリシー

- 16.3.3.7 フェイルオーバ イベントの同期化

- 16.3.3.8 クラスタの拡張

- 16.3.3.9 フェイルオーバの使用例

17 デプロイ済み SIP アプリケーションのアップグレード

- 17.1 SIP アプリケーションのアップグレードの概要

- 17.2 デプロイ済みアプリケーションをアップグレードする場合の要件と制約

- 17.3 デプロイ済み SIP アプリケーションをアップグレードする手順

- 17.4 バージョン識別子の割り当て

- 17.4.1 マニフェストでのバージョンの定義

- 17.5 新しいバージョンのアプリケーションのデプロイ

- 17.6 以前のバージョンのアプリケーションのアンデプロイ

- 17.7 アップグレード処理のロールバック

- 17.8 アプリケーション名とバージョン識別子へのアクセス

- 17.9 管理モードの使用

18 Parlay X Web Services のアーキテクチャ

- 18.1 Web サービス クライアント アプリケーションのアーキテクチャ

- 18.2 Web サービスのセキュリティ

- 18.2.1 通知時の Web サービス セキュリティ

- 18.2.2 OWLCS サービス セキュリティの有効化

- 18.2.3 クライアントのセキュリティの有効化

- 18.2.4 キーストアのコンフィグレーション

- 18.2.5 クライアントのエリアス

- 18.3 Web サービスのインストール

第 VII 部 リファレンス

A SIP サーブレット コンテナのコンフィグレーション リファレンス

- A.1 sipserver.xml の概要

- A.2 sipserver.xml の編集

- A.2.1 sipserver.xml を編集する際の手順

- A.3 XML スキーマ

- A.4 sipserver.xml ファイルの例

- A.5 XML 要素の説明

- A.5.1 enable-timer-affinity

- A.5.2 overload

- A.5.2.1 適切なオーバーロード ポリシーの選択

- A.5.2.2 セッション生成レートに基づくオーバーロード制御

- A.5.2.3 容量制限に基づくオーバーロード制御

- A.5.2.4 オーバーロード保護の 2 レベル

- A.5.3 message-debug

- A.5.4 proxy - アウトバウンド プロキシ サーバの設定

- A.5.5 t1-timeout-interval

- A.5.6 t2-timeout-interval

- A.5.7 t4-timeout-interval

- A.5.8 timer-b-timeout-interval

- A.5.9 timer-f-timeout-interval

- A.5.10 max-application-session-lifetime

- A.5.11 enable-local-dispatch

- A.5.12 cluster-loadbalancer-map

- A.5.13 default-behavior

- A.5.14 default-servlet-name

- A.5.15 retry-after-value

- A.5.16 sip-security

- A.5.17 route-header

- A.5.18 engine-call-state-cache-enabled

- A.5.19 server-header

- A.5.20 server-header-value

- A.5.21 persistence

- A.5.22 use-header-form

- A.5.23 enable-dns-srv-lookup

- A.5.24 connection-reuse-pool

- A.5.25 globally-routable-uri

- A.5.26 domain-alias-name

- A.5.27 enable-rport

- A.5.28 image-dump-level

- A.5.29 stale-session-handling

- A.5.30 enable-contact-provisional-response

- A.5.31 app-router

- A.5.32 use-custom-app-router

- A.5.33 app-router-config-data

- A.5.34 custom-app-router-jar-file-name

- A.5.35 default-application-name

B SIP データ層のコンフィグレーション リファレンス

- B.1 datatier.xml の概要

- B.2 datatier.xml の編集

- B.3 XML スキーマ

- B.4 datatier.xml ファイルの例

- B.5 XML 要素の説明

C Diameter のコンフィグレーション リファレンス

- C.1 diameter.xml の概要

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

- C.3 diameter.xml の編集

- C.3.1 diameter.xml の編集手順

- C.4 XML スキーマ

- C.5 diameter.xml ファイルの例

- C.6 XML 要素の説明

- C.6.1 configuration

- C.6.2 target

- C.6.3 host

- C.6.4 realm

- C.6.5 address

- C.6.6 port

- C.6.7 tls-enabled

- C.6.8 sctp-enabled

- C.6.9 debug-enabled

- C.6.10 message-debug-enabled

- C.6.11 application

- C.6.11.1 class-name

- C.6.11.2 param*

- C.6.12 peer-retry-delay

- C.6.13 allow-dynamic-peers

- C.6.14 request-timeout

- C.6.15 watchdog-timeout

- C.6.16 supported-vendor-id+

- C.6.17 include-origin-state

- C.6.18 peer+

- C.6.18.1 host

- C.6.18.2 address

- C.6.18.3 port

- C.6.18.4 protocol

- C.6.19 route

- C.6.19.1 realm

- C.6.19.2 application-id

- C.6.19.3 action

- C.6.19.4 server+

- C.6.20 default-route

- C.6.20.1 action

- C.6.20.2 server+

D 起動コマンド オプション

E サポート対象のプラットホーム、プロトコル、RFC、および標準

- E.1 サポート対象のコンフィグレーション

- E.2 サポート対象の SIP クライアント

- E.3 サポート対象のロード バランサ

- E.4 サポート対象のデータベース

- E.5 Oracle WebLogic Communication Services の標準アラインメントの概要

- E.6 Java Sun Recommendation (JSR) の標準への準拠

- E.7 IETF RFC への準拠

- E.8 3GPP R6 仕様への適合性

F Oracle WebLogic Communication Services のエクスポート/インポートの使用

- F.1 エクスポート

- F.1.1 現在の環境からのデータベース データのエクスポート

- F.2 インポート

G スケーラブルな Presence デプロイメントのデプロイ

- G.1 Presence クラスタ

- G.2 XDM クラスタ

- G.3 Presence ノード

- G.4 XDM ノード

- G.5 完全な Presence クラスタおよび XDM クラスタ

索引

Oracle® WebLogic Communication Services

管理ガイド

11g リリース 1 (11.1.1)

B55505-01(原本部品番号:E13806-01)

2009 年 5 月

Oracle WebLogic Communication Services 管理ガイド 11g リリース 1 (11.1.1)

B55505-01

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

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

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

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

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 Communication Services の概念、トポロジ、およびコンフィグレーションの各トピックの項目について説明します。この章は、以下のトピックで構成されています。

- 対象読者

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

- 関連ドキュメント

- 表記規則

対象読者

このドキュメントは、組織内で Oracle WebLogic Communication Services をセットアップおよび管理するシステム管理者を対象としています。

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

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

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

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

外部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 Communication Services インストール ガイド

- Oracle WebLogic Communication Services 開発者ガイド

- Oracle Fusion Middleware 11g Release Notes

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

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

イタリック体

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

固定幅フォント

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

第 I 部

一般的なコンフィグレーション

以下の章があります。

- 第 1 章「Oracle WebLogic Communication Services の概要」

- 第 2 章「共通のコンフィグレーション タスク」

- 第 3 章「SIP サーブレット コンテナ プロパティのコンフィグレーション」

- 第 4 章「ネットワーク リソースの管理」

- 第 5 章「セキュリティ機能の管理」

- 第 6 章「SIP データ層のパーティションとレプリカのコンフィグレーション」

- 第 7 章「Sash によるユーザのプロビジョニング」

- 第 8 章「モニタとトラブルシューティング」

1 Oracle WebLogic Communication Services の概要

以下の節では、Oracle WebLogic Communication Services (OWLCS) の概要と、Oracle WebLogic Communication Services のデプロイメントをコンフィグレーションおよび管理する方法の概要を示します。

- 節 1.1「Oracle WebLogic Communication Services」

1.1 Oracle WebLogic Communication Services

Oracle WebLogic Communication Services 11g (OWLCS) は、エンタープライズ サービスおよびアプリケーションに通信サービスを統合するために設計された包括的なプラットフォームです。 主な通信チャネルでの対話をサポートする、簡単に使用できるサービスが含まれています。 OWLCS でサポートされるテクノロジは、以下のとおりです。

- 節 1.1.1「メッセージング」

- 節 1.1.2「テレフォニ」

- 節 1.1.3「プレゼンス」

- 節 1.1.4「SIP およびコンバージド アプリケーションをサポートする WebLogic Server 10.3 プラットフォーム」

図 1-1 に Oracle WebLogic Communication Services の簡単な概要を示します。詳細については、以下の章で説明しています。

図 1-1 OWLCS の概要

「図 1-1 OWLCS の概要」の説明

1.1.1 メッセージング

OWLCS では、User Messaging Service (UMS) を通じてマルチ チャネル メッセージングをアプリケーションに統合するための単純で信頼性のある方法がサポートされています。 UMS では、Java API と Web サービスの両方による統合がサポートされています。 サポートされているチャネルには、SMS、電子メール、インスタント メッセージング、音声メッセージがあります。 UMS では、最終的なメッセージの宛先がユーザの設定によって決定されるインテリジェント メッセージングもサポートされています。

UMS のインストールおよびコンフィグレーションの詳細については、第 11 章「Oracle User Messaging Service のコンフィグレーション」を参照してください。

メッセージ アプリケーション開発の詳細については、『Oracle WebLogic Communication Services 開発者ガイド』を参照してください。

1.1.2 テレフォニ

OWLCS では、アプリケーションが 2 台の電話機またはソフト クライアント間で Voice over IP 通話を開始するための Third Party Call Control (TPCC) Web サービス API がサポートされています。 このサービスは、市場を牽引する IP ベースの PBX システム、および VoIP-PSTN ゲートウェイを使用する PSTN と直ちに統合されます。

TPCC のインストールとコンフィグレーション、および TPCC アプリケーションの作成の詳細については、『Oracle WebLogic Communication Services 開発者ガイド』の「Third Party Call サービス」を参照してください。

1.1.3 プレゼンス

OWLCS には、プレゼンス情報の集約機能として動作し、アプリケーションおよびエンドユーザがプレゼンス情報を使用するためのサブスクライブ/通知パラダイムを提供する、プレゼンス サービスが含まれています。Web サービスを使用するか、準拠する SIP ベースのエンドユーザ クライアントを使用して、アプリケーションを統合できます。

プレゼンスのコンフィグレーションの詳細については、第 9 章「Presence および Presence Web Services のコンフィグレーション」を参照してください。 Presence アプリケーションの開発の詳細については、『Oracle WebLogic Communication Services 開発者ガイド』の「Parlay X Presence Web Services」を参照してください。

1.1.4 SIP およびコンバージド アプリケーションをサポートする WebLogic Server 10.3 プラットフォーム

OWLCS では、JSR 289 準拠の SIP コンテナによって WebLogic Server プラットフォームが拡張されています。 これにより、進化した通信アプリケーションに対応した、HTTP および SIP を処理する J2EE アプリケーションを開発できます。 このプラットフォームでは、SIP ベースの IP-PBX、および標準 SIP クライアントなどの他の SIP 要素と統合される、補完的な通信サービスの開発が可能になります。

OWLCS では、SIP ベースのネットワーク構築用に直ちに使用できる主なインフラストラクチャ アプリケーションが提供されます。

SIP コンテナのインストールとコンフィグレーション、および SIP インフラストラクチャ アプリケーションの詳細については、第 I 部「一般的なコンフィグレーション」および「第 V 部「SIP インフラストラクチャ アプリケーションの信任」を参照してください。

2 共通のコンフィグレーション タスク

以下の節では、Oracle WebLogic Communication Services と Oracle WebLogic Server で共通のコンフィグレーション タスクについて概要を説明します。 次のトピックがあります。

- 節 2.1「Oracle WebLogic Communication Services と Oracle WebLogic Serverで共通のコンフィグレーション タスク 」

- 節 2.2「Oracle WebLogic Communication Services のコンフィグレーションの概要」

- 節 2.3「コンフィグレーション タスクを実行するための方法とツール」

- 節 2.4「サーバの起動と停止」

- 節 2.5「管理サーバのベスト プラクティス」

- 節 2.6「一般的なコンフィグレーション タスク」

2.1 Oracle WebLogic Communication Services と Oracle WebLogic Serverで共通のコンフィグレーション タスク

Oracle WebLogic Communication Services は、定評のある Oracle WebLogic Server 10g リリース 3 アプリケーション サーバを基盤としており、システム レベルのコンフィグレーション タスクの多くは両製品で共通しています。このガイドでは、Oracle WebLogic Communication Services に固有のシステム レベルのコンフィグレーション タスクのみを取り上げます。たとえば、ネットワークとセキュリティのコンフィグレーションや、エンジン層と SIP データ層のクラスタ コンフィグレーションに関連するタスクなどです。

HTTP サーバのコンフィグレーションや、その他の基本的なコンフィグレーション タスク (サーバのロギングなど) については、Oracle WebLogic Server のドキュメントを参照してください。インストール概要については、『Oracle Fusion Middleware Oracle WebLogic Server インストールの概要』を参照してください。

2.2 Oracle WebLogic Communication Services のコンフィグレーションの概要

Oracle WebLogic Communication Services の SIP Servlet コンテナ、SIP データ層のレプリケーション、および Diameter プロトコル機能はカスタム リソースとして Oracle WebLogic Server 10g Release 3 製品に実装されています。カスタム リソースの sipserver と datatier のペアには、エンジン層の SIP サブレット コンテナ機能と SIP データ層のレプリケーション機能が実装されています。通常、プロダクション環境へのデプロイには、両方のリソースがインストールされています。特化したデプロイメントでは、節 15.7「他のコンフィグレーション」で説明される SIP 対応ロード バランサと連動する sipserver リソースのみが使用できます。

もう一方のカスタム リソース、diameter は、Diameter に基づくプロトコル機能を提供します。1 つまたは複数の Diameter プロトコル アプリケーションを利用するデプロイメントにのみ必要です。

Oracle WebLogic Communication Services カスタム リソースの割り当ては、ドメイン コンフィグレーション ファイル config.xml で参照できますが、変更はできません。各リソースの定義は、例 2-1 に表示されます。sipserver と datatier リソースは、それぞれ 例 2-1 で同じサーバとクラスタに割り当てる必要があります。リソースはエンジン層と SIP データ層の両方のクラスタでデプロイされます。

例 2-1 Oracle WebLogic Communication Services カスタム リソース

<custom-resource>
<name>sipserver</name>
<target>ORA_DATA_TIER_CLUST,ORA_ENGINE_TIER_CLUST</target>
<descriptor-file-name>custom/sipserver.xml</descriptor-file-name>
<resource-class>com.bea.wcp.sip.management.descriptor.resource.SipServerResource</resource-class>
<descriptor-bean-class>com.bea.wcp.sip.management.descriptor.beans.SipServerBean</descriptor-bean-class>
</custom-resource>
<custom-resource>
<name>datatier</name>
<target>ORA_DATA_TIER_CLUST,ORA_ENGINE_TIER_CLUST</target>
<descriptor-file-name>custom/datatier.xml</descriptor-file-name>
<resource-class>com.bea.wcp.sip.management.descriptor.resource.DataTierResource</resource-class>
<descriptor-bean-class>com.bea.wcp.sip.management.descriptor.beans.DataTierBean</descriptor-bean-class>
</custom-resource>
<custom-resource>
<name>diameter</name>
<target>ORA_ENGINE_TIER_CLUST</target>
<deployment-order>200</deployment-order>
<descriptor-file-name>custom/diameter.xml</descriptor-file-name>
<resource-class>com.bea.wcp.diameter.DiameterResource</resource-class>
<descriptor-bean-class>com.bea.wcp.diameter.management.descriptor.beans.ConfigurationBean</descriptor-bean-class>
</custom-resource>

Oracle WebLogic Communication Services カスタム リソースは、config.xml に定義されたネットワーク チャネル、クラスタとサーバ コンフィグレーション、Java EE リソースのような基本的なドメイン リソースを利用します。しかし、Oracle WebLogic Communication Services の特定のリソースは、機能に基づき別々のコンフィグレーション ファイルで設定されます。

- sipserver.xml は SIP コンテナ プロパティと一般的な Oracle WebLogic Communication Services エンジン層の機能を設定します。

- datatier.xml は、SIP データ層にレプリカとして属するサーバを識別し、SIP データ層パーティションの数とレイアウトも定義します。

- diameter.xml は Diameter ノードおよびドメインで使用する Diameter プロトコル アプリケーションを設定します。

- approuter.xml は、デフォルト アプリケーション ルータをコンフィギュレーションします。 DAR のコンフィギュレーションの詳細については、『Oracle WebLogic Communication Services インストールガイド』を参照してください。

ドメイン コンフィグレーション ファイル config.xml は、ドメインで使用可能なすべての管理対象サーバを定義することに留意してください。sipserver アプリケーションに含まれる sipserver.xml、datatier.xml および diameter.xml コンフィグレーション ファイルは、SIP データ層レプリカ、エンジン層ノード、Diameter クライアント ノードとして行動するかどうかなど、各サーバ インスタンスのロールを決定します。

SIP サーブレット コンテナのプロパティのコンフィグレーションの変更は、Administration Console、または WLST ユーティリティのコマンドラインを使用して、稼動中のサーバに対して動的に適用できます (一部の SIP サーブレット コンテナのプロパティでは再起動の必要性を示すアイコンが表示される場合がありますが、この場合は変更後の再起動が必要であることを示しています)。SIP データ層ノードのコンフィグレーションは動的に変更できないので、パーティションやレプリカの数を変更するには、SIP データ層サーバを再起動する必要があります。

2.2.1 Diameter のコンフィグレーション

Diameter プロトコルの実装は、SIP Servlet コンテナ機能とは別に、カスタム リソースとして行われます。Diameter コンフィグレーション ファイルは、Diameter ノード機能を提供する 1 つまたは複数の Diameter プロトコル アプリケーションを設定します。Oracle WebLogic Communication Services は Diameter プロトコル アプリケーションを提供し、以下のノード タイプをサポートします。

- Diameter Sh インタフェース クライアント ノード (Home Subscriber Service のクエリ用)

- Diameter Rf インタフェース クライアント ノード (オフラインでのチャージ用)

- Diameter Ro インタフェース クライアント ノード (オンラインでのチャージ用)

- Diameter リレー ノード

- HSS シミュレータ ノード (テストおよび開発にのみ適しており、プロダクション デプロイメントには適さない)

Diameter カスタム リソースは、Diameter クライアント ノードまたはリレー エージェントの役割をする必要があるサーバを持つドメイン、あるいは HSS シミュレーション機能を提供するサーバにのみデプロイされます。サーバ インスタンスの実際の機能は、diameter.xml ファイルで定義されるコンフィグレーションによって異なります。

Oracle WebLogic Communication Services ドメインで Diameter Web アプリケーションをコンフィグレーションする手順については、「ネットワーク リソースのコンフィグレーション」の節 10.2「Diameter クライアント ノードとリレー エージェントをコンフィグレーションする手順」を参照してください。 Diameter アプリケーションの開発に関する詳細は、『Oracle WebLogic Communication Services 開発者ガイド』を参照してください。

2.3 コンフィグレーション タスクを実行するための方法とツール

Oracle WebLogic Communication Services には、SIP サーブレット コンテナのコンフィグレーションを変更するための方法として、以下が用意されています。

- 節 2.3.1「Administration Console」

- 節 2.3.2「WebLogic Scripting Tool (WLST)」

- 節 2.3.3「その他のコンフィグレーション方法」

2.3.1 Administration Console

Oracle WebLogic Communication Services には、変更可能な Administration Console 拡張、SIP サーブレット ドメイン、グラフィカル ユーザ インタフェースを使用する Diameter コンフィグレーション プロパティが用意されています。Oracle WebLogic Communication Services の Administration Console の拡張は、Oracle WebLogic Server 10g リリース 3 で利用できるコア コンソールと似ています。すべての Oracle WebLogic Communication Services コンフィグレーションとモニタは、コンソールの左ペインにある次のノードを介して提供されます。

- SipServer — SIP Servlet コンテナのプロパティとその他のエンジン層の機能をコンフィグレーションを行います。この拡張を使って、新規のパーティションの作成と SIP データ層のパーティションとレプリカの表示 (変更は不可) もできます。Administration Console を使用した SIP サーブレット コンテナのコンフィグレーションの詳細については、節 3.1「SIP コンテナのコンフィグレーションの概要」を参照してください。

- Diameter — Diameter ノードとアプリケーションのコンフィグレーションを行います。

注意 :
Oracle WebLogic Server Administration Console の使用方法の詳細については、『Oracle Fusion Middleware Administrator's Guide』の「Getting Started with Oracle WebLogic Server Administration Console」を参照してください。

2.3.2 WebLogic Scripting Tool (WLST)

WebLogic Scripting Tool (WLST) では、コマンドライン インタフェースを使用して、対話形式または自動化された (バッチの) コンフィグレーション操作を実行できます。WLST は稼動中の Oracle WebLogic Communication Services ドメインで利用可能な MBeans の表示や操作ができる JMX ツールです。節 3.1「SIP コンテナのコンフィグレーションの概要」では、WLST を使用して SIP サーブレット コンテナのプロパティを変更する手順を説明します。

注意 :
WLST の使用方法の詳細については、『Oracle Fusion Middleware WebLogic Scripting Tool コマンド リファレンス』を参照してください。

2.3.3 その他のコンフィグレーション方法

Oracle WebLogic Communication Services コンフィグレーションの大半は、Administration Console または WLST を使用して実行されます。コンフィグレーション タスクによっては、以下の節で述べる方法も使用できます。

2.3.3.1 コンフィグレーション ファイルの編集

sipserver.xml、datatier.xml、diameter.xml、および approuter.xml を手動で編集することもできます。 コンフィグレーション ファイルを手動で編集する場合は、コンフィグレーションの変更を適用するために、すべてのサーバを再起動する必要があります。

2.3.3.2 カスタム JMX アプリケーション

Oracle WebLogic Communication Services のプロパティは、JMX-compliant MBeans で表されます。 したがって、適切な Oracle WebLogic Communication Services の MBean を使用して、SIP コンテナ プロパティをコンフィグレーションする JMX アプリケーションをプログラムできます。

JMX を使用して WebLogic SIP Server の MBean プロパティを変更する一般的な手順については、節 3.3「WLST (JMX) によるコンテナ プロパティのコンフィグレーション」で説明されています (WLST 自体、JMX ベースのアプリケーションです)。 SIP コンテナ プロパティの処理に使用する個々の Mbean の詳細については、『Oracle Fusion Middleware Communication Services Java API Reference』を参照してください。

2.3.3.2.1 ログ レベルの設定

ログ レベルの設定は、logging.xml ファイルを手動で編集するか、setLoggerLevel(String loggerName, String logLevel) MBean を設定するか、または Oracle Enterprise Manager から行うことができます。詳細については、節 12.2.1「ロギングのコンフィグレーション」を参照してください。 『Oracle Fusion Middleware 2 Day Administration Guide』も参照してください。

2.4 サーバの起動と停止

Oracle WebLogic Communication Services の起動スクリプトでは、パフォーマンスを左右する多数の JVM パラメータにデフォルト値が使用されています。たとえば、JVM のガベージ コレクションやヒープ サイズのパラメータが省略されていることや、評価や開発以外の目的には適切でない値を使用していることがあります。プロダクション システムでは、十分なパフォーマンスを実現するために、さまざまなヒープ サイズやガベージ コレクションの設定でアプリケーションのプロファイリングを厳密に行う必要があります。プロダクション ドメインで JVM のパフォーマンスを最大限に引き出す方法については、節 8.8「プロダクション デプロイメントにおける JVM ガベージ コレクションのチューニング」を参照してください。

警告 :
複数のエンジン層サーバおよび SIP データ層サーバで構成されるドメインをコンフィグレーションするときには、SIP プロトコル スタックを正しく機能させるために、すべてのシステムの時計を共通の時刻設定元に合わせて、誤差 1 ～ 2 ミリ秒以内で正確に同期する必要があります。詳細は、節 3.5.2「SIP タイマーの正確な同期に必要な NTP のコンフィグレーション」を参照してください。

通常、Oracle WebLogic Communication Services ドメインは、多数のエンジン層サーバと SIP データ層サーバで構成されており、異なる種類のサーバ間に依存関係があります。したがって、ドメインを起動するときには、一般に次の手順に従う必要があります。

1. ドメインの管理サーバを起動する。ドメインでエンジンおよび SIP データ層サーバに初期のコンフィグレーションを提供するには、管理サーバを起動します。管理サーバは、各管理対象サーバの起動/停止のステータスをモニタする目的にも使用します。通常、管理サーバの起動にはコンフィグレーション ウィザードでインストールされた startWebLogic.cmd スクリプトを使用するか、またはカスタムの起動スクリプトを使用します。

2. 各パーティションの SIP データ層サーバを起動する。SIP データ層のサーバで呼状態データを処理できる状態にならないと、エンジン層が機能しません。リクエストの処理を開始するためには、各パーティションのレプリカがすべて利用できる状態になっている必要はありませんが、同時呼状態を処理するためには、コンフィグレーションされた各パーティションにつき少なくとも 1 つのレプリカを利用できる必要があります。プロダクション ネットワーク トラフィックに対してシステムをオープンするためには、全レプリカが起動して利用可能な状態になっている必要があります。
通常、各データ層サーバの起動には、コンフィグレーション ウィザードでインストールされた startManagedWebLogic.cmd スクリプトを使用するか、またはカスタムの起動スクリプトを使用します。startManagedWebLogic.cmd では、起動するサーバの名前と、ドメインの管理サーバの URL を指定する必要があります。たとえば次のように指定します。

startManagedWebLogic.cmd datanode0-0 t3://adminhost:7001

3. エンジン層サーバを起動する。SIP データ層サーバを起動したら、エンジン層でサーバを起動して、クライアント リクエストの処理を開始できます。エンジン層サーバも、SIP データ層サーバと同様に、通常はstartManagedWebLogic.cmd スクリプトまたはカスタムの起動スクリプトを使用して起動します。

以上の起動シーケンスに従うと、すべての管理対象サーバで、最新の SIP サーブレット コンテナと SIP データ層のコンフィグレーションが確実に使用されます。また、この起動シーケンスなら、SIP データ層のサーバを利用できないときに生成されるエンジン層のエラー メッセージも回避できます。

2.5 管理サーバのベスト プラクティス

Oracle WebLogic Communication Services インストールの管理サーバは、サービスおよびアプリケショーンがコンフィグレーションする、デプロイする、およびモニタするには必要です。

注意 :
ハードウェア、ソフトウェア、またはネットワークの問題によって管理サーバで障害が発生した場合に、その影響が及ぶのは、管理、デプロイメント、およびモニタの処理に対してのみです。管理対象サーバが稼動を続けるうえでは、管理サーバは必要ありません。つまり、管理サーバで障害が発生した場合でも、管理対象サーバ インスタンスで実行中の Java EE アプリケーションと SIP 機能は引き続き動作します。

Oracle WebLogic Communication Services ドメインの管理サーバと管理対象サーバのインスタンスをコンフィグレーションするうえでは、以下のベスト プラクティスをお勧めします。

- 管理サーバのインスタンスは、専用のマシンで稼動させます。管理サーバ マシンには管理対象サーバ マシンと同程度のメモリ容量が必要ですが、管理という目的のうえでは、通常は単一の CPU で問題ありません。

- 管理対象サーバのすべてのインスタンスで、管理対象サーバの独立を使用するようにコンフィグレーションします。管理対象サーバの独立とは、ネットワーク、ハードウェア、またはソフトウェアの障害によって管理サーバにアクセスできない場合でも管理対象サーバを再起動できる機能です。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server サーバの起動と停止の管理』を参照してください。

- Oracle WebLogic Communication Services ドメインのすべての管理対象サーバを自動的に再起動するようにノード マネージャ ユーティリティをコンフィグレーションします。詳細については、『Oracle Fusion Middleware Oracle WebLogic Scripting Tool ガイド』を参照してください。

管理サーバのインスタンスまたはマシンで障害が発生した場合でも、その影響が及ぶのは、コンフィグレーション、デプロイメント、およびモニタの各機能のみであり、管理対象サーバは引き続き動作して、クライアント リクエストの処理を続けます。管理サーバの障害によって欠落が生じる可能性があるのは、以下の点です。

- 進行中の管理およびデプロイメントの処理の欠落。

- 進行中のロギング機能の欠落。

- WebLogic Server インスタンスの SNMP トラップ生成の欠落 (Oracle WebLogic Communication Services インスタンスのトラップ生成ではありません)。管理対象サーバでは、Oracle WebLogic Communication Services のトラップは管理サーバがなくても生成されます。

通常の運用を再開するために、障害が発生した管理サーバ インスタンスはできるだけ早く再起動してください。

2.6 一般的なコンフィグレーション タスク

Oracle WebLogic Communication Services の一般的な管理と保守では、WebLogic Server のコンフィグレーション プロパティと Oracle WebLogic Communication Services のコンテナ プロパティの両方を管理することが必要です。こうした一般的なコンフィグレーション タスクを表 2-1 に示します。

表 2-1 Oracle WebLogic Communication Services の一般的なコンフィグレーション タスク

タスク

説明

節 3.1「SIP コンテナのコンフィグレーションの概要」

- Administration Console を使用して SIP コンテナ プロパティをコンフィグレーションします。

- WLST を使用してバッチ コンフィグレーションを実行します。

第 6 章「SIP データ層のパーティションとレプリカのコンフィグレーション」

- Oracle WebLogic Communication Services インスタンスを SIP データ層のパーティションに割り当てます。

- SIP データ層の複数のインスタンスを使用して呼状態をレプリケートします。

第 4 章「ネットワーク リソースの管理」

- SIP および HTTP のトラフィックを処理するように WebLogic Server ネットワーク チャネルをコンフィグレーションします。

- マルチホーム サーバのハードウェアを設定します。

- Oracle WebLogic Communication Services で使用するロード バランサをコンフィグレーションします。

節 5.7「ダイジェスト認証のコンフィグレーション」

- LDAP ダイジェスト認証プロバイダをコンフィグレーションします。

- 信頼性のあるホストのリストをコンフィグレーションします。

節 8.7「SIP リクエストと応答のロギング」

- SIP リクエストと応答を記録するよう、ロギング サーブレットをコンフィグレーションします。

- ログに記録するメッセージをフィルタするためのログの条件を定義します。

- Oracle WebLogic Communication Services のログ ファイルを管理します。

3 SIP サーブレット コンテナ プロパティのコンフィグレーション

以下の節では、Oracle WebLogic Communication Services デプロイメントのエンジン層において SIP コンテナの機能をコンフィグレーションする方法について説明します。

- 節 3.1「SIP コンテナのコンフィグレーションの概要」

- 節 3.2「Administration Console によるコンテナ プロパティのコンフィグレーション」

- 節 3.3「WLST (JMX) によるコンテナ プロパティのコンフィグレーション」

- 節 3.4「WLST のコンフィグレーション」

- 節 3.5「タイマー処理のコンフィグレーション」

3.1 SIP コンテナのコンフィグレーションの概要

Administration Console や WLST (WebLogic Scripting Tool) などの JMX ユーティリティを使用するか、カスタムの JMX アプリケーションをプログラミングすることで SIP コンテナ プロパティをコンフィグレーションできます。節 3.2「Administration Console によるコンテナ プロパティのコンフィグレーション」では、Administration Console グラフィカル ユーザ インタフェースによるコンテナ プロパティのコンフィグレーション方法について説明します。

節 3.3「WLST (JMX) によるコンテナ プロパティのコンフィグレーション」では、JMX MBean に直接アクセスしてコンテナのコンフィグレーションを変更する方法を説明します。後続の節で、JMX によるコンフィグレーション MBean へのアクセスの例として示しているのは、すべて WLST を使用する方法です。

3.2 Administration Console によるコンテナ プロパティのコンフィグレーション

Oracle WebLogic Communication Services に含まれている Administration Console を使用すると、WebLogic Server の中核機能および Oracle WebLogic Communication Services で提供されている SIP サーブレット コンテナ機能のコンフィグレーションとモニタを実行できます。Administration Console を使用して SIP サーブレット機能をコンフィグレーションまたはモニタするには、『Oracle Fusion Middleware 管理者ガイド』の「Getting Started with Oracle WebLogic Server Administration Console」を参照してください。

表 3-1 Oracle WebLogic Communication Services のコンフィグレーションとモニタに使用する各種ページ

ページ

サブページ

機能

[コンフィグレーション]

[一般]

SIP タイマー値、セッション タイムアウト時間、デフォルトの Oracle WebLogic Communication Services の動作 (プロキシやユーザ エージェント)、サーバ ヘッダ フォーマット、呼状態キャッシュ、DNS 名解決、timer affinity、ドメイン エリアス、rport サポート、および診断イメージ フォーマットなどをコンフィグレーションします。

[コンフィグレーション]

[アプリケーション ルーター]

カスタム アプリケーション ルーター (AR) のクラス名、コンフィグレーションまたはデフォルト アプリケーションを設定します。

[コンフィグレーション]

[プロキシ]

プロキシのルーティング URI およびプロキシのポリシーをコンフィグレーションします。

[コンフィグレーション]

[オーバーロード保護]

自動的なオーバーロード制御を有効および無効にする条件をコンフィグレーションします。

[コンフィグレーション]

[メッセージ デバッグ]

開発システムでの SIP メッセージ ロギングを有効または無効にします。

[コンフィグレーション]

[SIP セキュリティ]

認証の実行対象としない信頼性のあるホストを指定します。

[コンフィグレーション]

[永続性]

長期間維持するセッション データの RDBMS への格納、またはリモートの地理的に冗長なサイトに長期間維持するセッション データのレプリケートの永続性オプションをコンフィグレーションします。

[コンフィグレーション]

[データ層]

現在の SIP データ層サーバのコンフィグレーションを表示します。ここでパーティションを追加、削除、およびコンフィグレーションすることもできます。

[コンフィグレーション]

[LoadBalancer マップ]

ソフトウェアをアップグレードする過程で複数のクラスタを内部仮想 IP アドレスに対応付けるマッピングを設定します。

[コンフィグレーション]

[ターゲット]

エンジン層のコンフィグレーションを受けるサーバとクラスタのリストをコンフィグレーションします。対象サーバのリストは、どのサーバまたはクラスタが SIP サーブレット コンテナの機能を提供するかを決定します。

[コンフィグレーション]

[接続プール]

接続再利用プールを、SBC (Session Border Control) 機能または S-CSCF (Serving Call Session Control Function) との通信オーバーヘッドを最小限に抑えるためにコンフィグレーションします。

[モニタ]

[一般]

エンジン層サーバで処理されたメッセージおよびセッションに関する実行時情報を表示します。

[モニタ]

[SIP アプリケーション]

デプロイ済み SIP アプリケーションの実行時セッション情報を表示します。

[モニタ]

[データ層の情報]

現在の SIP データ層サーバの状態および実行されている処理に関する実行時情報を表示します。

3.2.1 コンフィグレーションのロックと永続化

Oracle WebLogic Communication Services のコンフィグレーション ページのいずれかの情報を変更するには、コンフィグレーションをロックする必要があります。コンフィグレーションをロックすると、他の管理者が同時にそのコンフィグレーションを変更することはできなくなります。プロダクション ドメインでは、ロックが自動的に有効になっています。開発ドメインでは、有効または無効にできます。

変更するには、以下の手順を実行します。

1. Administration Console の左上部にある [チェンジ センタ] を見つけます。

2. [ロックして編集] ボタンをクリックして、ドメインのコンフィグレーションの編集階層をロックします。これで Administration Console を使用して変更できるようになります。

3. Administration Console の該当するページで必要な変更を行います。変更を行う各ページで [保存] をクリックします。

4. 必要な変更がすべて完了したら、[チェンジ センタ] の [変更のアクティブ化] をクリックします。

注意 :
Administration Console で行った変更の一部は、アクティブ化するとすぐに反映されます。それ以外の変更については、その変更の影響を受けるサーバまたはモジュールを再起動する必要があります。後者の変更は、動的でない変更と呼ばれます。Administration Console では、動的でない変更に対して警告のアイコンが示されます。
動的でないコンフィグレーション設定に変更があった場合、動的なコンフィグレーション設定に対する変更も再起動の後まで有効になりません。

Oracle WebLogic Server の Administration Console の使用の詳細については、『Oracle Fusion Middleware 管理ガイド』を参照してください。

3.3 WLST (JMX) によるコンテナ プロパティのコンフィグレーション

WebLogic Scripting Tool (WLST) ユーティリティを使用すると、WebLogic Server または Oracle WebLogic Communication Services のインスタンス上で使用可能な JMX MBean を監視または変更することができます。WLST の全ドキュメントは、『Oracle Fusion Middleware Oracle WebLogic Scripting Tool ガイド 』で参照できます。

Oracle WebLogic Communication Services ドメインを設定するために WLST を使用する前に、必須の Oracle WebLogic Communication Services クラスをクラスパスに追加するため環境を設定します。MIDDLEWARE_HOME/server/bin にあるドメイン環境スクリプトまたは setWLSEnv.sh スクリプトを使用します。MIDDLEWARE_HOME は Oracle WebLogic Communication Services インストールのルートです。

3.3.1 コンフィグレーション ロックの管理

表 3-1 は、コンフィグレーションのロックおよび変更の適用に使用する WLST メソッドの概要を示します。

表 3-2 MBean のメソッドの概要

メソッド

説明

activate

現在のコンフィグレーション MBean の属性 (現在の SIP サーブレット コンテナのコンフィグレーション) を sipserver.xml コンフィグレーション ファイルに書き込み、実行中のサーバに変更を適用します。

cancelEdit

編集ロックをリリースして編集セッションを削除し、保存していない変更をすべて破棄します。管理者特権を持つユーザであれば、ユーザが編集セッションを起動していなくてもこの操作を呼び出すことができます。

cd

コンフィグレーション Bean または実行時 Bean の階層を移動します。

connect

WLST を WebLogic Server インスタンスに接続します。

edit

編集セッションを開始します。

save

現在のコンフィグレーション MBean の属性 (現在の SIP サーブレット コンテナのコンフィグレーション) を一時コンフィグレーション ファイルに書き込みます。

set

現在のコンフィグレーション Bean の指定された属性値を設定します。

stopEdit

SIP コンテナのプロパティを変更するために取得したロックを解放し、一時ファイルをすべて破棄し、MBean に対する未保存の変更をすべてロールバックします。

Ｔ1 タイマーの間隔を変更するコマンドの例を以下に示します。

例 3-1 T1 タイマー間隔の変更

connect()
edit()
cd('CustomResources/sipserver/Resource/sipserver')
set('T1TimeoutInterval',505)
activate()

3.3.2 Oracle WebLogic Communication Services の MBean へのアクセス

SIP サーブレット コンテナのすべてのコンフィグレーション MBean は「serverConfig」の MBean ツリーに配置されており、これらの MBean にアクセスするには WLST の serverConfig() コマンドを使用します。MBean ツリー内の各コンフィグレーション MBean にアクセスするには、次のパスを使用します。

CustomResources/sipserver/Resource/sipserver

たとえば、Oracle WebLogic Communication Services ドメインのデフォルトの Proxy MBean を参照するには、以下の WLST コマンドを入力します。

serverConfig()
cd('CustomResources/sipserver/Resource/sipserver/Proxy')
ls()

実行時 MBean はカスタム のMBean ツリーに配置されており、これらの MBean にアクセスするには WLST の custom() コマンドを使用します。実行時 MBean は以下のパスを使用します。

mydomain:Location=myserver,Name=myserver,Type=mbeantype

プロキシやオーバーロード保護の設定などの特定のコンフィグレーション設定は、sipserver.xml においてデフォルトで定義されています。これらの設定に対応したコンフィグレーション MBean は、関連付けられているサーバの起動時に生成されるので、Proxy MBean および OverloadProtection MBean はサーバの起動直後から参照できます。その他のコンフィグレーション設定はデフォルトではコンフィグレーションされないので、それらの設定に対応する MBean にアクセスするには、事前にその MBean を作成する必要があります。節 3.4.2「MBean の作成と削除」を参照してください。

3.4 WLST のコンフィグレーション

以下の節では、SIP サーブレット コンテナのプロパティをコンフィグレーションするための WLST スクリプトおよびコマンドについて説明します。

3.4.1 WLST の起動

Oracle WebLogic Communication Services で WLST を使用するには、Oracle WebLogic Communication Services のすべての JAR ファイルをクラスパスに追加しておく必要があります。次の手順に従います。

1. Oracle WebLogic Communication Services 環境を設定します。

cd MIDDLEWARE_HOME/user_projects/domains/mydomain/bin
./setDomainEnv.sh

2. WLST を起動します。

java weblogic.WLST

3. Oracle WebLogic Communication Services ドメインの管理サーバに接続します。

connect('system','weblogic','t3://myadminserver:<portnumber>')

3.4.2 MBean の作成と削除

SipServer MBean は、sipserver.xml コンフィグレーション ファイル全体の内容を表します。SipServer では、SIP タイマーおよび SIP アプリケーションのセッション タイムアウトをコンフィグレーションするための属性を設定できるだけでなく、プロキシ設定やオーバーロード保護制御を表す MBean を作成または削除するために役立つヘルパー メソッドも使用できます。SipServer の他のヘルパ メソッドの一覧については、表 3-1「Oracle WebLogic Communication Services のコンフィグレーションとモニタに使用する各種ページ」を参照してください。また、『Oracle Fusion Middleware Communication Services Java API Reference』も参照してください。

3.5 タイマー処理のコンフィグレーション

エンジン層のサーバが新しい呼状態データを SIP データ層に追加すると、SIP データ層のインスタンスは、そのデータをキューに格納し、各呼に関連付けられている SIP タイマーおよびアプリケーション タイマーのリストを最新の状態に更新します。エンジン層のサーバは、SIP データ層のすべてのパーティションに対するポーリングを定期的に実行し、その時刻において期限切れになっているタイマーを特定します。デフォルトでは、複数のエンジン層を使用している場合は、タイマー テーブルに対する競合を回避するために、SIP データ層へのポーリングは時間差を置いて行われます。期限切れのすべてのタイマーが見つかった場合、エンジン層のサーバは sip.timer.Default 実行キューで割り当てられているスレッドを使用して、そのタイマーを処理します。

3.5.1 Timer Affinity のコンフィグレーション (省略可能)

タイマー処理がデフォルトの状態で動作している場合、エンジン層サーバはタイマーに関する呼出しを操作するには参加したかにかかわらず、現在に起動されるすべてのタイマーを処理します。しかし、いくつかの展開シナリオが、タイマーがそのタイマーに関する呼出しを最後に変更したと同様なエンジンサーバで処理されるのを必要とします。このシナリオに関する1つの例は、ホットスタンバイ方式です。これらは、別のエンジンで障害が発生するまで、任意の呼出すのデータが処理できないセカンダリ エンジン保存します。Oracle WebLogic Communication Services はこのようなシナリオで Timer Affinity をコンフィグレーションすることができます。

Timer Affinity を有効にすると、レプリカは、それぞれのエンジン層サーバが処理タイマの SIP データ層に対するポーリングを定期的に実行する必要があります。SIPデータ層にポーリングを実行するとき、エンジンはそれによる最後に変更された呼出しのタイマーまたは所有者がいない呼出しのに対するタイマーだけを処理します。

注意 :
エンジン層サーバが失敗する場合、最後にそのエンジンによって変更されたどんな呼出し状態にも、所有者は存在しません。所有者がいない期限切れのタイマーが SIP データ層にポーリングを実行する次のエンジン サーバによって処理されます。

Timer Affinity の有効化 :

1. ドメインの Administration Console にアクセスします。

2. [ロックして編集] ボタンをクリックしてコンフィグレーション ロックを取得します (開発環境で有効化されている場合)。

3. 左ペインで [SipServer] ノードをクリックします。コンソールの右ペインにある 2 つのレベルのタブ付きページで Oracle WebLogic Communication Services をコンフィグレーションし、モニタします。

4. 右ペインの [コンフィグレーション｜一般] タブを選択します。

5. [Timer Affinity の有効化] を選択します。

6. [保存] をクリックしてコンフィグレーションの変更を保存します。

[Timer Affinity の有効化] 設定は enable-timer-affinity 要素の sipserver.xml に永続性します。

3.5.2 SIP タイマーの正確な同期に必要な NTP のコンフィグレーション

SIP プロトコル スタックを正常に機能させるには、エンジン層と SIP データ層のすべてのサーバのシステム時計を共通の時刻設定元に正確に同期して、各時計の差を 1 ～ 2 ミリ秒以内に抑える必要があります。システム時計の時刻に大きな差があると、次のような重大な問題が発生する原因となります。

- 時計が進んだ状態に設定されているサーバでは、本来より早い時点で SIP タイマーが作動します。

- エンジン層におけるタイマーの処理が適切に分散されなくなります。たとえば、期限切れタイマーの処理がすべて 1 つのエンジン層サーバで実行され、その他のエンジン層サーバではタイマーの処理がまったく行われない、といった偏りが生じるおそれがあります。

Oracle WebLogic Communication Services の各インスタンスでは、Network Time Protocol (NTP) のクライアントまたはデーモンを使用して、共通の NTP サーバの時刻に同期することをお勧めします。

警告 :
SIP プロトコル スタックを正常に機能させるには、サーバのシステム時計を共通の時刻設定元に正確に (差が 1 ～ 2 ミリ秒以内になるように) 同期する必要があります。T1 タイマーの初期値として設定される 500 ミリ秒の値は、INVITE リクエストおよび応答の再送信間隔の制御や、その他のタイマーの初期値の設定に使用されるので、システム時計の設定に少しでもずれがあると、SIP プロトコルが適切に動作しなくなるおそれがあります。たとえば、エンジン層の 1 つのサーバのシステム時計の時刻が他のサーバの時計より 250 ミリ秒進んでいると、そのサーバが処理する期限切れタイマーの割合が他のエンジン層サーバに比べて高くなり、割り当てられている間隔の半分の時間が経過した時点で再送信が開始されるようになります。また、メッセージのタイムアウトが本来より早い時点で強制的に発生するおそれもあります。

4 ネットワーク リソースの管理

以下の節では、ネットワーク リソースを Oracle WebLogic Communication Services で使用するためにコンフィグレーションする方法について説明します。

- 節 4.1「ネットワーク コンフィグレーションの概要」

- 節 4.2「ロード バランサのアドレスのコンフィグレーション」

- 節 4.3「DNS サポートの有効化」

- 節 4.4「SIP または SIPS のネットワーク チャネルのコンフィグレーション」

- 節 4.5「Diameter をサポートするための TCP および TLS チャネルのコンフィグレーション」

- 節 4.6「エンジン サーバで任意の IP インタフェースでリスンする場合のコンフィグレーション」

- 節 4.7「SIP データ層レプリカの一意なリスン アドレス属性のコンフィグレーション」

4.1 ネットワーク コンフィグレーションの概要

Oracle WebLogic Communication Services の各インスタンスのデフォルトの HTTP ネットワーク コンフィグレーションは、各サーバのリスン アドレスおよびリスン ポートの設定に基づいて決定されます。ただし、Oracle WebLogic Communication Services では HTTP 上の SIP プロトコルはサポートされていません。SIP プロトコルは、UDP および TCP 転送プロトコル上でサポートされています。また、転送プロトコルとして TLS を使用する SIPS もサポートされています。

UDP、TCP、または TLS による転送を有効にするには、Oracle WebLogic Communication Services instance のインスタンスに対して 1 つまたは複数の「ネットワーク チャネル」をコンフィグレーションします。 ネットワーク チャネルは、そのサーバ インスタンスに対する特定のネットワーク接続の属性を定義するコンフィグレーション可能な WebLogic Server リソースです。基本的なチャネルの属性は次のとおりです。

- 接続でサポートされているプロトコル

- 接続のリスン アドレス (DNS 名または IP アドレス)

- 接続で使用されるポート番号

- 発信される UDP パケットで使用されるポート番号 (省略可能)

- チャネルを発信接続に使用する場合に SIP ヘッダに埋め込まれるパブリック リスン アドレス (ロード バランサのアドレス)

Oracle WebLogic Communication Services の 1 つのインスタンスに複数のチャネルを割り当てて、複数のプロトコルをサポートすることや、マルチホームのサーバ ハードウェアに搭載されている複数のインタフェースを利用することができます。同一のチャネルを複数のサーバ インスタンスに割り当てることはできません。

SIP プロトコル用の新しいネットワーク チャネルをコンフィグレーションすると、UDP および TCP 転送プロトコルの両方が指定されたポートで有効です。UDP または TCP のどちらか一方の転送プロトコルのみを使用する SIP チャネルを作成することはできません。SIPS プロトコル用のネットワーク チャネルをコンフィグレーションすると、そのチャネルの接続では、転送プロトコルとして TLS が使用されます。

新しい SIP Server ドメインをコンフィグレーションする場合は、通常、システム内のエンジン層の各サーバとの通信に使用する複数の SIP チャネルを作成する必要があります。エンジン層のサーバは、レプリカ用にコンフィグレーションされたリスン アドレス属性を使用して、SIP データ層のレプリカと通信できます。ただし、レプリカ間で相互に通信するには、レプリカで一意なリスン アドレスを使用する必要があります。

注意 :
SIP データ層のクラスタで複数のレプリカをコンフィグレーションする場合は、サーバごとに一意なリスン アドレス (一意な DNS 名または IP アドレス) をコンフィグレーションする必要があります。一意なリスン アドレスを指定しない場合は、デフォルトの localhost アドレスにレプリカ サービスがバインドされるため、複数のレプリカがお互いを見つけることができなくなります。

4.1.1 IPv4 と IPv6

オペレーティング システムとハードウェア が IPv6 をサポートしている場合は、は、ネットワーク通信に IPｖ6 を使用できるように Oracle WebLogic Communication Services をコンフィグレーションできます。SIP トラフィックの IPv6 は、IPv6 アドレスでネットワーク チャネルをコンフィグレーションすると有効になります。IPv6 SIP チャネルは、IPv6 トラフィックをサポートする各エンジン層サーバでコンフィグレーションする必要があります。詳細については、節 4.4.2「新しい SIP または SIPS チャネルの作成」を参照してください。

エンジン上でコンフィグレーションした各 SIP ネットワーク チャネルは、IPv6 または IPv4 トラフィックをサポートします。1 つのチャネルで IPv4 と IPv6 トラフィックをいっしょに使用することはできません。1 つのエンジンは、複数の個別のネットワークをサポートするために、IPv4 と IPv6 チャネルの両方でコンフィグレーションすることができます。

Oracle WebLogic Communication Services のエンジンおよび SIP データ層ノードは、外部 SIP トラフィックのために他のプロトコル バージョンをサポートしながら、IPv4 (または IPv6) で通信することもできます。IPv6 ネットワークでエンジンおよび SIP データ層ノードをコンフィグレーションするには、各サーバ インスタンスに対して IPv6 リスン アドレスを指定します。

IPv 4 と IPv6 ネットワーク チャネルのコンフィグレーションの詳細については、節 4.4.2「新しい SIP または SIPS チャネルの作成」を参照してください。

4.2 ロード バランサのアドレスのコンフィグレーション

エンジン層への接続を分散するためにシステムで 1 つまたは複数のロード バランサを使用する場合は、SIP ネットワーク チャネルのコンフィグレーションにおいて、ロード バランサのアドレスを「外部リスン アドレス」として設定する必要があります。 SIP チャネルの外部リスン アドレスがそのチャネルのプライマリ リスン アドレスと異なる場合は、外部リスン アドレスのホストとポート番号が Response などの SIP ヘッダに Oracle WebLogic Communication Services によって埋め込まれます。そのため、その呼に関するそれ以後の通信では外部からの送信先としてロード バランサのパブリック アドレスが使用され、ローカルのエンジン層サーバのアドレスは指定されません (外部クライアントからはエンジン層サーバのアドレスにアクセスできない場合もあります)。

ネットワーク チャネルにおいて外部リスン アドレスがコンフィグレーションされていない場合は、そのチャネルのプライマリ リスン アドレスが SIP ヘッダに埋め込まれます。

4.2.1 複数のロード バランサおよびマルチホームのロード バランサを使用する場合

システムで 2 つのロード バランサを使用する場合は、エンジン層の各サーバにおいて 2 つのチャネル (それぞれのロード バランサへのネットワーク接続につき 1 つずつ) を定義し、それぞれのロード バランサに外部リスン アドレスを割り当てる必要があります。エンジン層サーバ上の特定のネットワーク インタフェースが発信トラフィック用のインタフェースとして選択されているときは、そのネットワーク インタフェース カード (NIC) のアドレスに関連付けられているネットワーク チャネルに基づいて、SIP ヘッダに埋め込む外部リスン アドレスが決定されます。

2 つのパブリック アドレスを持つマルチホームのロード バランサを使用する場合も、同様に 2 つのチャネルを定義して、その両方のパブリック アドレスをコンフィグレーションする必要があります。エンジン層サーバに搭載されている NIC が 1 つのみのときは、ロード バランサの 2 番目のパブリック アドレス専用のチャネルをコンフィグレーションするために、その NIC の 2 番目のアドレスを論理アドレスとして定義しなければなりません。さらに、IP ルーティング ポリシーをコンフィグレーションして、ロード バランサのそれぞれのパブリック アドレスにどの論理アドレスを関連付けるかを指定することも必要です。

4.3 DNS サポートの有効化

Oracle WebLogic Communication Services は、SIP メッセージを送信するのに必要なプロキシ転送、IP アドレスおよびポート番号を解決するマルチホームをサポートしています。これは、RFC 3263 (http://www.ietf.org/rfc/rfc3263.txt) に説明されている動作に一致しています。 また、マルチホームは宛先の IP アドレスおよびポート番号を解決するために応答をルーティングするときにも使用できます。

注意 :
マルチホーム解決は SIP メッセージ処理のコンテクスト内で実行されるため、どのようなマルチホーム パフォーマンス問題でもレイテンシ増加の原因となります。潜在的なパフォーマンス問題を削減するためにプロダクション環境ではキャッシング マルチホーム サーバを使用することをお勧めします。

マルチホーム サポートのコンフィグレーション手順

1. コンフィグレーションする Oracle WebLogic Communication Services ドメインの Administration Console にログインします。

2. コンソールの左ペインの [SipServer] ノードを選択します。

3. 右ペインの [コンフィグレーション｜一般] タブを選択します。

4. [マルチホーム サーバ ルックアップを有効化] を選択します。

5. [保存] をクリックして変更内容を保存します。

マルチホーム ルックアップを有効にすると、サーバは以下の目的でマルチホームを使用できます。

- SIP URI にリクエストを送信する場合、プロキシ サーバ転送、IP アドレスとポート番号を検出します。

- [Sent-by] フィールドの内容に基づいて、応答のルーティングの際に IP アドレスとポート番号を解決します。

プロキシ検出のために Oracle WebLogic Communication Services は、SIP トランザクション毎に一度マルチホーム解決を使用して転送、IP とポート番号に関する情報を決定します。すべての再送信、ACKs または CANCEL リクエストは同じ転送を使用して同じアドレスとポートに配信されます。マルチホーム解決をどのように実行するかについての詳細については、RFC 3263 (http://www.ietf.org/rfc/rfc3263.txt) を参照してください。

プロキシが応答メッセージの送信を要求されている場合、Oracle WebLogic Communication Services は sent-by フィールドとヘッダで提供された情報によっては送信先の IP アドレスおよびポート番号を決定するためマルチホーム ルックアップを使用します。

4.4 SIP または SIPS のネットワーク チャネルのコンフィグレーション

コンフィグレーション ウィザードを使用して新しいドメインを作成すると、Oracle WebLogic Communication Services のインスタンスは、UDP または TCP 上の SIP プロトコルをサポートするデフォルトのネットワーク チャネルを使用するようにコンフィグレーションされます。デフォルト チャネルではリスン ポートとして 5060 が設定されていますが、リスン アドレスは指定されていません。デフォルト チャネルのリスン アドレスまたはリスン ポートの設定を変更するには、節 4.4.1「既存チャネルの再コンフィグレーション」の手順に従ってください。 デフォルト以外のプロトコルやネットワーク インタフェースを追加的にサポートするために新しいチャネル リソースを作成する手順については、節 4.4.2「新しい SIP または SIPS チャネルの作成」を参照してください。

4.4.1 既存チャネルの再コンフィグレーション

既存チャネルでサポートされているプロトコルを変更することはできません。既存のリスン アドレスとリスン ポートの組み合わせを再コンフィグレーションして、別のネットワーク プロトコルを使用するように変更するには、その既存チャネルを削除した上で、節 4.4.2「新しい SIP または SIPS チャネルの作成」の手順に従って新しいチャネルを作成する必要があります。

チャネルをコンフィグレーションするには :

1. コンフィグレーションする Oracle WebLogic Communication Services ドメインの Administration Console にログインします。

2. 左ペインで、[環境｜サーバ] タブを選択します。

3. 右ペインで、コンフィグレーションするサーバの名前を選択します。

4. [プロトコル｜チャネル] タブを選択して、コンフィグレーション済みのチャネルを表示します。

5. 既存チャネルを削除するには、表から選択して、[Delete] をクリックします。

6. 既存チャネルを再コンフィグレーションするには、以下の手順を実行します。

1. チャネル リストからチャネル名 (たとえば、デフォルトの sip チャネル) を選択します。

2. [リスン アドレス] フィールドまたは [リスン ポート] フィールドを編集して、関連付けられているエンジン層マシン上の NIC のアドレスまたは論理アドレスに一致するように変更します。

注意 :
リスン アドレスとリスン ポートを変更する前に、チャネルを無効にする必要があります。

3. [外部リスン アドレス] フィールドまたは [外部リスン ポート] フィールドを編集して、システムのロード バランサのパブリック アドレスに一致するように変更します。

4. 必要に応じて、高度なチャネル属性を編集します (詳細については、節 4.4.2「新しい SIP または SIPS チャネルの作成」を参照してください。)

7. [保存] をクリックします。

4.4.2 新しい SIP または SIPS チャネルの作成

SIP または SIPS の新規チャネルを Oracle WebLogic Communication Services インスタンスのコンフィグレーションに作成するには、以下の手順を実行します。

1. コンフィグレーションする Oracle WebLogic Communication Services ドメインの Administration Console にログインします。

2. 左ペインで、[環境｜サーバ] タブを選択します。

3. 右ペインで、コンフィグレーションするサーバの名前を選択します。

4. [プロトコル｜チャネル] タブを選択して、コンフィグレーション済みのチャネルを表示します。

5. [New] をクリックして、新しいチャネルをコンフィグレーションします。

6. 新規チャネルの各フィールドの値を以下のように指定します。

- [名前] : このチャネルに付ける管理用の名前 (たとえば SIPS-Channel-eth0) を入力します。

- [プロトコル] : UDP および TCP による転送をサポートする SIP、または TLS による転送をサポートする SIPS のいずれかを選択します。 SIP チャネルでは、コンフィグレーションされたポート上で UDP または TCP のどちらか一方のみによる転送をサポートすることはできません。

7. [次へ] をクリックします。

8. 新規チャネルのアドレス指定フィールドの値を以下のように指定します。

- [リスン アドレス] : このチャネルの IP アドレスまたはマルチホーム名を入力します。マルチホーム マシンの場合は、コンフィグレーション対象のインタフェースの正確な IP アドレス、またはその正確な IP アドレスにマッピングされているマルチホーム名を入力します。

- [リスン ポート] : このチャネルを介した通信に使用するポート番号を入力します。[リスン アドレス] と [リスン ポート] の組み合わせは、そのサーバでコンフィグレーションされている他のどのチャネルの設定とも異なる必要があります。SIP チャネルでは、コンフィグレーションされたポート上で UDP および TCP の両方の転送がサポートされます。

- [外部リスン アドレス] および [外部リスン ポート] : このチャネルに関連付けられているロード バランサのパブリック アドレスに一致するように編集します。Oracle WebLogic Communication Services は、発信ネットワーク トラフィックに使用するインタフェースまたは論理アドレスを選択するときに、同じプライマリ 「リスン アドレス」を使用するようにコンフィグレーションされているチャネルを調べます。そのチャネルの「外部リスン アドレス」が異なる場合は、その外部リスン アドレスが SIP メッセージ ヘッダに埋め込まれて、それ以後のコール トラフィックで使用されるようになります。節 4.2「ロード バランサのアドレスのコンフィグレーション」を参照してください。

9. [次へ] をクリックします。

10. 必要があれば、[表示] をクリックして高度なチャネル プロパティを表示し、「接続のタイムアウト」値などの各種プロパティを編集します。 高度なチャネル プロパティについては、以下の制限や推奨事項に留意してください。

- [発信の有効化] - SIP および SIPS のすべてのチャネルはネットワーク接続の発信元になる可能性があるので、この属性のチェックをはずすことはできません。

- [このプロトコルで HTTP を有効化] - Oracle WebLogic Communication Services では、転送に HTTP を使用する SIP プロトコルはサポートされていないので、SIP および SIPS のチャネルでこの属性を選択することはできません。

- [最大メッセージ サイズ] - この属性は、このチャネルを発信元とする通信で使用可能な TCP メッセージの最大サイズを指定します。メッセージのサイズがこの属性でコンフィグレーションされている最大サイズを超えている通信は、Oracle WebLogic Communication Services によってすべて切断されます。デフォルトのサイズは 10,000,000 バイトです。このデフォルトのサイズはかなり大きいので、サーバへのサービス拒否 (DOS) 攻撃に対する防御を重視する場合は、デプロイされているサービスに支障のない範囲でこの属性の値をより小さい値に変更してください。

11. [Finish] をクリックします。

4.4.3 カスタム タイムアウト、MTU および他のプロパティのコンフィグレーション

SIP チャネルは 1 つ以上のカスタム チャネル プロパティを使用してさらにコンフィグレーションすることができます。カスタム プロパティは Administration Console を使用して設定することはできません。その代わりに、ドメインに対して、config.xml ファイルのチャネル コンフィグレーションの一部にある単一の custom-property スタンザへプロパティを追加するためにテキスト エディタを使用する必要があります。

Oracle WebLogic Communication Services には、SIP チャネルの転送プロトコルに影響する次のカスタムプロパティがあります。

- TcpConnectTimeoutMillis - Oracle WebLogic Communication Services が送り先アドレス (発信 TCP 接続) をアクセス不能として宣言する前に、その待機時間を指定します。 このプロパティは SIP チャネルのみに適用されます。Oracle WebLogic Communication Services では、SIPS チャネルのこの属性の値が無視されます。値が 0 の場合、タイムアウトが完全に無効になります。 カスタム プロパティを指定しない場合、デフォルトとして 3000 ミリ秒が使用されます。

- SctpConnectTimeoutMillis - Oracle WebLogic Communication Services が送り先アドレス ( 発信 SCTP 接続 ) をアクセス不能として宣言する前に、その待機時間を指定します。 プロパティは SCPT チャネルのみに適用されます （Diameter トラフィック用）。値が 0 の場合、タイムアウトが完全に無効になります。カスタム プロパティを指定しない場合、デフォルトとして 3000 ミリ秒が使用されます。Diameter の SCTP チャネルを作成する情報については、節 4.8.1.1「発信 UDP パケット用の静的ポートのコンフィグレーション」を参照してください。

- SourcePorts - UDP パケットを作成するためにサーバが使用する 1 つまたは複数の静的ポート番号をコンフィグレーションします。

警告 :
SourcePorts カスタム プロパティを使用するとパフォーマンスが低下するので、ほとんどのコンフィグレーションでは、このプロパティを使用することは望ましくありません。UDP パケットを作成するために Oracle WebLogic Communication Services が使用する正確なポート数を指定する必要がある場合にのみ、このプロパティをコンフィグレーションします。

- Mtu - このチャネルの最大転送ユニット (MTU) 値を指定します。-1 の値を指定すると、転送のためにデフォルトの MTU が使用されます。

- EnabledProtocolVersions - Oracle WebLogic Communication Services が SSL クライントとして動作する場合、このチャネルに使用する SSL プロトコルのバージョンを指定します。 SSL クライントとして動作する場合、チャネルではサポート対象のプロトコルとして TLS V1.0 のバージョンを必要とします。SSL V3.0 が SSL のピアー サーバのサポート対象バージョンのうち最も高バージョンであれば、そのバージョンを使用するようにサーバをコンフィグレーションできます。このプロパティには次のいずれかの値を設定することができます。

- デフォルトの TLS1 に設定すると、TLS V1.0 メッセージのみを送受信するようにチャネルがコンフィグレーションされます。ピアは TLS V1.0 メッセージに応答する必要があります。応答しない場合は、SSL 接続が切断されます。

- SSL3 に設定すると、チャネルが SSL V3.0 メッセージのみを送受信するようにコンフィグレーションされます。ピアは SSL V3.0 メッセージに応答する必要があります。応答しない場合は、SSL 接続が切断されます。

- ALL に設定すると、TLS V1.0 か SSL V3.0 メッセージをサポートします。ピアは TLS V1.0 か SSL V3.0 に応答する必要があります。応答しない場合は、SSL 接続が切断されます。

カスタム プロパティをコンフィグレーションする場合、テキスト エディタを使用して [config.xml] ファイルを直接変更するか、WLST などの JMX クライアントを使用してカスタム プロパティを追加します。[config.xml] ファイルを直接編集する場合、チャネルのコンフィグレーション スタンザの末尾に追加するカスタム-プロパティの要素は 1 つだけにしてください。例 4-1 に示すように、セミコロン (;) を使用して同一要素内の複数のカスタム プロパティを区切ります。

例 4-1 カスタム プロパティの設定

<network-access-point>
<name>sip</name>
<protocol>sip</protocol>
<listen-port>5060</listen-port>
<public-port>5060</public-port>
<http-enabled-for-this-protocol>false</http-enabled-for-this-protocol>
<tunneling-enabled>false</tunneling-enabled>
<outbound-enabled>true</outbound-enabled>
<enabled>true</enabled>
<two-way-ssl-enabled>false</two-way-ssl-enabled>
<client-certificate-enforced>false</client-certificate-enforced>
<custom-properties>EnabledProtocolVersions=ALL;Mtu=1000;SourcePorts=5060</custom-properties>
</network-access-point>

4.4.4 マルチホーム マシンの SIP チャネルのコンフィグレーション

複数のネットワーク インタフェースを持つサーバ (「マルチホーム」サーバ) をコンフィグレーションする場合は、Oracle WebLogic Communication Services で使用する各 IP アドレスのネットワーク チャネルを個別にコンフィグレーションする必要があります。 Oracle WebLogic Communication Services では、SIP メッセージのシステム ヘッダにルーティング情報を埋め込む際に、各チャネルのリスン アドレスおよびリスン ポートの値が使用されます。

注意 :
マルチホーム マシン上に、チャネルがコンフィグレーションされていない IP アドレスがある場合、その IP アドレスを Via、Contact、および Record-Route ヘッダの値として設定することはできません。

4.5 Diameter をサポートするための TCP および TLS チャネルのコンフィグレーション

Oracle WebLogic Communication Services の Diameter 実装では、TCP または TLS 転送プロトコル上の Diameter プロトコルがサポートされています。サーバに対する着信 Diameter 接続を有効にするには、専用のネットワーク チャネルをコンフィグレーションします。転送プロトコルとして TCP を使用する場合は diameter のプロトコル タイプを選択し、TCP および TLS を使用する場合は diameters を選択します。 Diameter 仕様 (RFC 3558) に記述されているように、Diameter 実装アプリケーションは、TLS を使用するために Diameter 接続を自動的にアップグレードする場合があります。

Diameter プロトコルをサポートするためのネットワーク チャネルのコンフィグレーションの詳細については、第 10 章「Diameter クライアント ノードとリレー エージェントのコンフィグレーション」を参照してください。

4.6 エンジン サーバで任意の IP インタフェースでリスンする場合のコンフィグレーション

Oracle WebLogic Communication Services をコンフィグレーションして、使用可能な任意の IP インタフェース上で UDP トラフィックをリスンするには、新しい SIP チャネルを作成して、リスン アドレスとして 0.0.0.0 (または、IPv6 ネットワークには :: ) を指定します。ただし、その場合でも、SIP メッセージの発信用のチャネルとして、IP アドレスが明示的に指定されたチャネルを少なくとも 1 つはコンフィグレーションする必要があります。(マルチホーム マシンでは、メッセージの発信に使用する各インタフェースに対して個別にチャネルをコンフィグレーションする必要があります)。

注意 :
サーバ自体のリスン アドレスがコンフィグレーションされている場合は、チャネルのリスン アドレスを指定しないで SIP チャネルをコンフィグレーションすると、その SIP チャネルにサーバのリスン アドレスが継承されます。この場合、その SIP チャネルでは、IP_ANY に対するリスンは行われません。

注意 :
0.0.0.0 コンフィグレーションの使用は、Linux プラットフォームの UDP トラフィックにのみ影響します。Oracle WebLogic Communication Services では、サーバのコンフィグレーションされたホスト名とローカル ホストに対応する TCP および HTTP リスン スレッドのみが作成されます。ホスト名に複数のアドレスをマップする場合は、Oracle WebLogic Communication Services の起動時に警告メッセージが表示されます。この問題を回避してすべてのアドレスでリスンするには、HTTP と TCP トラフィックに対して IPｖ6 と IPv4 両方で使用可能なすべてのアドレスを含む :: アドレスを指定します。

4.7 SIP データ層レプリカの一意なリスン アドレス属性のコンフィグレーション

SIP データ層のレプリカがピアとして相互に通信できるようにするには、一意なリスン アドレス属性 (一意なマルチホーム名または IP アドレス) を各レプリカにバインドする必要があります。各レプリカに一意なリスン アドレスを割り当てるには、以下の手順を実行します。

1. Oracle WebLogic Communication Services ドメインの Administration Console にアクセスします。

2. 左ペインで、[環境｜サーバ] を選択します。

3. 右ペインで、コンフィグレーションするサーバの名前を選択します。

4. [コンフィグレーション｜一般] タブを選択します。

5. 一意な DNS 名または IP アドレスを [リスン アドレス] フィールドに入力します。

6. [保存] をクリックします。

4.8 プロダクション環境のネットワーク アーキテクチャとコンフィグレーション

プロダクション環境 (エンタープライズ デプロイメント) にインストールされている Oracle WebLogic Communication Services は、ほとんどの場合、以下の特徴を 1 つ以上備えています。

- 複数のエンジン層サーバによってクラスタが構成されています。

- エンジン層の各サーバ インスタンスが複数のネットワーク チャネルを持ち、複数の SIP 転送プロトコル、またはマルチホーム ハードウェア上の複数のネットワーク インタフェース カード (NIC) がサポートされています。

- システムに 1 つまたは複数のロード バランサ、またはマルチホームのロード バランサが含まれているため、サーバのフェイルオーバが可能になっており、必要に応じて、ネットワーク パケットの送信元または送信先のアドレスを書き換えるネットワーク アドレス変換 (NAT) を実行できます。

このような各種のネットワーク要素が組み合わされて使用されていると、各要素が互いにどのように作用し合い、ネットワーク要素やコンフィグレーション オプションの特定の組み合わせが SIP メッセージまたは転送プロトコル データグラムの内容にどのような影響を与えるのかが理解しにくくなる場合があります。

以下の節では、Oracle WebLogic Communication Services の一般的なネットワーク アーキテクチャについて解説し、各アーキテクチャでサーバをコンフィグレーションする方法を説明します。また、SIP メッセージおよび転送データグラム内の情報が各コンフィグレーションによってどのような影響を受けるかについても説明します。図 4-1 は、OSI (Open Systems Interconnect) の典型的なモデルにおいて、さまざまなネットワーク コンフィグレーションの影響を受ける可能性があるレイヤを示したものです。

図 4-1 Oracle WebLogic Communication Services のネットワーク コンフィグレーションの影響を受ける OSI レイヤ

「図 4-1 Oracle WebLogic Communication Services のネットワーク コンフィグレーションの影響を受ける OSI レイヤ」の説明

レイヤ 3 (ネットワーク層) およびレイヤ 4 (トランスポート層) には、発信および受信される転送データグラムの送信元または送信先 IP アドレスとポート番号が格納されています。SIP プロトコルでは、SIP メッセージの送信元にアクセスするためのアドレス情報を特定の SIP ヘッダ内に記述するように規定されているので、レイヤ 7 (アプリケーション層) も影響を受ける可能性があります。

4.8.1 TCP チャネルおよび UDP チャネルを使用する単一 NIC のコンフィグレーション

NIC が 1 枚だけ搭載されたサーバを使用する単純なネットワーク コンフィグレーションでは、1 つまたは複数のネットワーク チャネルを作成して、UDP および TCP 上の SIP メッセージ、または TLS 上の SIPS メッセージをサポートすることができます。この単純なコンフィグレーションが OSI モデルの情報にどのように影響するかを理解しておくと、マルチホーム ハードウェアおよびロード バランサを使用したさらに複雑なコンフィグレーションが、同じ情報にどのような影響を与えるのかが理解できます。

図 4-2 単一 NIC のネットワーク チャネルのコンフィグレーション

「図 4-2 単一 NIC のネットワーク チャネルのコンフィグレーション」の説明

図 4-2 は、単一の NIC を持つ 1 つのエンジン層サーバのインスタンスを示したものです。 このサーバでは、UDP および TCP 上の SIP をサポートする 1 つのネットワーク チャネルがコンフィグレーションされています。(SIP チャネルは、常に UDP 転送と TCP 転送の 2 つともサポートします。2 つのうち一方のみをサポートすることはできません)。図 4-2 では、サーバと 2 つのクライアントが 1 つは UDP もう 1 つは TCP を使用して通信していることを示します。

TCP による転送の場合、発信データグラム (Oracle WebLogic Communication Services からユーザ エージェントに送信されるデータグラム) には次の情報が含まれています。

- レイヤ 3 には、そのネットワーク チャネルで指定されている送信元 IP アドレス (上記例では 10.1.1.10) が含まれています。

- レイヤ 4 には、基盤のオペレーティング システムによって割り当てられた送信元ポート番号が含まれています。

TCP の受信データグラム (ユーザ エージェントから Oracle WebLogic Communication Services に送信されるデータグラム) には次の情報が含まれています。

- レイヤ 3 には、そのネットワーク チャネルで指定されている送信先 IP アドレス (10.1.1.10) が含まれています。

- レイヤ 4 には、そのネットワーク チャネルで指定されている送信先ポート番号 (5060) が含まれています。

UDP の発信データグラムの場合、OSI レイヤの情報には TCP による転送の場合と同じ情報が含まれています。UDP の受信データグラムの場合、OSI レイヤの情報は、受信データグラムのレイヤ 4 の情報以外は TCP の場合と同じです。UDP の受信データグラムのレイヤ 4 には、次のどちらかが含まれています。

- そのネットワーク チャネルで指定されている送信先ポート番号 (5060)

- Oracle WebLogic Communication Services によって事前に割り当てられたエフェメラル ポート番号

デフォルトの場合、Oracle WebLogic Communication Services では、基盤のオペレーティング システムにおいて UDP 発信データグラムのエフェメラル ポート用に確保されているポート番号範囲からポート番号が割り当てられます。Oracle WebLogic Communication Services では、外部からの接続において、ネットワーク チャネルでコンフィグレーションされているポート番号のほかに、任意のエフェメラル ポイントを送信先ポート番号として使用できます。つまり、Oracle WebLogic Communication Services では、サーバによって割り当てられたすべてのエフェメラル ポートで自動的にリスンが行われます。Oracle WebLogic Communication Services でのエフェメラル ポート番号の使用は、必要に応じて無効にできます。エフェメラル ポート番号が使用されないようにするには、サーバの起動時に次のオプションを指定します。

-Dwlss.udp.listen.on.ephemeral=false

Oracle WebLogic Communication Services で特定のエフェメラル ポートが使用されているかどうかを確かめるには、サーバのログ ファイルに記録されている次のような情報を調べて、使用されているポート番号を確認してください。

<Nov 30, 2005 12:00:00 AM PDT> <Notice> <WebLogicServer> <BEA-000202> <Thread "SIP Message Processor (Transport UDP)" listening on port 35993.>

4.8.1.1 発信 UDP パケット用の静的ポートのコンフィグレーション

Oracle WebLogic Communication Services のネットワーク チャネルでは、SourcePorts 属性を使用することにより、サーバから UDP パケットを発信するために使用する 1 つまたは複数の静的ポートをコンフィグレーションできます。

警告 :
SourcePorts カスタム プロパティを使用するとパフォーマンスが低下するので、ほとんどのコンフィグレーションでは、このプロパティを使用することは望ましくありません。UDP パケットを作成するために Oracle WebLogic Communication Services が使用する正確なポート数を指定する必要がある場合にのみ、このプロパティをコンフィグレーションします。

SourcePorts プロパティをコンフィグレーションする場合、WLST などの JMX クライアントを使用するか、config.xml ファイルのネットワーク チャネルのコンフィグレーションを直接変更してカスタム プロパティを追加します。SourcePorts には、ポート番号またはポート番号範囲の配列を指定します。SourcePorts の定義内ではスペースを使用しないでください。ポートの範囲を示すには、ポート番号、ハイフン (「-」) を使用し、範囲や各ポートを区切るにはカンマ (「,」) を使用します。コンフィグレーションの記述例については、例 4-2 を参照してください。

例 4-2 発信 UDP パケットの静的ポート コンフィグレーション

<network-access-point>
<name>sip</name>
<protocol>sip</protocol>
<listen-port>5060</listen-port>
<public-port>5060</public-port>
<http-enabled-for-this-protocol>false</http-enabled-for-this-protocol>
<tunneling-enabled>false</tunneling-enabled>
<outbound-enabled>true</outbound-enabled>
<enabled>true</enabled>
<two-way-ssl-enabled>false</two-way-ssl-enabled>
<client-certificate-enforced>false</client-certificate-enforced>
<custom-properties>SourcePorts=5060</custom-properties>
</network-access-point>

4.8.2 マルチホーム サーバのコンフィグレーションの概要

プロダクション デプロイメントのエンジン層サーバでは、多くの場合、複数の NIC が搭載されたマルチホームのサーバ ハードウェアが利用されます。マルチホーム ハードウェアは、一般に、次のどちらかの目的で使用されます。

- 同一のサブネット内での冗長なネットワーク接続の実現。複数の NIC を使用すると、いずれか 1 つの NIC に障害が発生した場合でも、それ以外の 1 つまたは複数のネットワーク接続を使用して、データ層サーバまたは管理サーバと通信することができます。

- 複数の異なるサブネット間の SIP 通信のサポート。たとえば、異なるサブネット上のユーザ エージェント (UA) が相互に直接通信できない場合は、Oracle WebLogic Communication Services をコンフィグレーションして、1 つのサブネットの UA から別のサブネットの UA に SIP リクエストを送信するためのプロキシとして機能させることができます。

コンフィグレーションの要件および OSI レイヤの情報は、システムでマルチホーム ハードウェアを使用する目的によって異なります。1 つのサブネット内で冗長なネットワーク接続を実現することを目的として複数の NIC を使用する場合は、通常、節 4.8.3「すべてのアドレス (IP_ANY) でリスンするマルチホーム サーバ」で説明している方法により、使用可能なすべてのアドレス (IP_ANY) でリスンするようにサーバをコンフィグレーションします。

複数の異なるサブネットをサポートすることを目的として複数の NIC を使用する場合は、節 4.8.4「複数のサブネットでリスンするマルチホーム サーバ」で説明しているように、サーバ上で複数のネットワークをそれぞれの異なる NIC に対してコンフィグレーションする必要があります。

4.8.3 すべてのアドレス (IP_ANY) でリスンするマルチホーム サーバ

最も単純なマルチホーム コンフィグレーションを使用すると、利用可能なすべての NIC (物理 NIC および論理 NIC) において、Oracle WebLogic Communication Services の 1 つのインスタンスによるリスンを実行できるようになります。このコンフィグレーションは IP_ANY と呼ばれることもあります。これを実現するために必要なのは、1 つのネットワーク チャネルをコンフィグレーションして、チャネルのリスン アドレスとして 0.0.0.0 を指定することだけです。

0.0.0.0 のアドレスは、そのサーバのネットワーク チャネル上で直接コンフィグレーションする必要があります。チャネルの IP アドレスを指定しないと、サーバ インスタンス自体にコンフィグレーションされているリスン アドレスがチャネルに継承されます。節 4.6「エンジン サーバで任意の IP インタフェースでリスンする場合のコンフィグレーション」を参照してください。

4.8.4 複数のサブネットでリスンするマルチホーム サーバ

複数の NIC は、複数のサブネット上でリスンするためにエンジン層サーバで使用することもできます。その場合の最も一般的なコンフィグレーションでは、直接的な相互アクセスが許可されていない複数のサブネット間の通信を実現するために、Oracle WebLogic Communication Services が SIP トラフィックのプロキシとして使用されます。図 4-3 は、このコンフィグレーションを示します。

図 4-3 サブネット間のプロキシ通信を実現するマルチホーム コンフィグレーション

「図 4-3 サブネット間のプロキシ通信を実現するマルチホーム コンフィグレーション」の説明

Oracle WebLogic Communication Services インスタンスを図 4-3 にコンフィグレーションするため、サーバ マシン上で使用した各 NIC にネットワーク チャネルを定義する必要があります。 例 4-3 は、サンプル コンフィグレーションのチャネルを定義する config.xml エントリを示します。

例 4-3 複数のサブネット上の各 NIC で使用するネットワーク チャネル コンフィグレーションのサンプル

<NetworkAccessPoint ListenAddress="10.1.1.10" ListenPort="5060" Name="sipchannelA" Protocol="sip"/>
<NetworkAccessPoint ListenAddress="10.2.1.10" ListenPort="5060" Name="sipchannelB" Protocol="sip"/>

4.8.4.1 ルート リゾルバについて

Oracle WebLogic Communication Services が複数のサブネットでリスンするようにコンフィグレーションされている場合は、route resolver と呼ばれる機能によって、次の処理が行われます。

- OSI レイヤ 7 情報内に (Via、Contact などの SIP システム ヘッダに)、正しいアドレスが格納されます。

- OSI レイヤ 3 情報内に、正しい送信元 IP アドレスが格納されます。

たとえば、図 4-3 に示したコンフィグレーションの場合、各 UA が SIP トランザクションの処理を続行できるようにするには、Oracle WebLogic Communication Services において、正しいサブネット アドレスを SIP システム ヘッダと転送データグラムに追加する必要があります。 不適切なサブネット アドレスが使用されると、どちらの UA も別の UA のサブネットに直接アクセスできないので、応答を配信できなくなります。

ルート リゾルバは、オペレーティング システムが特定の送信先にデータグラムを送信する際に使用する NIC を判別して、その NIC に関連付けられているネットワーク チャネルを調査します。そして、選択されたそのネットワーク チャネルでコンフィグレーションされているアドレスの情報を、SIP ヘッダおよびレイヤ 3 のアドレス情報として格納します。

たとえば、図 4-3 に示すコンフィグレーションでは、Oracle WebLogic Communication Services から UAC B に送信された INVITE メッセージの送り先のアドレスは 10.2.1.16 です。このメッセージは対応するサブネットにコンフィグレーションされた NIC B を使用して送信されます。 ルート リゾルバは、コンフィグレーション済みの sipchannelB に NIC B を関連付け、そのチャネルの IP アドレス (10.2.1.10) を SIP メッセージの VIA ヘッダに埋め込みます。そのため、そのメッセージを受け取った UAC B では、VIA ヘッダの値に基づいて、それ以後のメッセージをサーバの正しい IP アドレスに向けて送信できるようになります。UAC A でも同様の処理が行われるので、適切なサブネット以外にメッセージが配信されることはありません。

4.8.4.2 マルチホーム ハードウェアにおける IP エリアス

IP エリアスを使用すると、1 つの NIC に複数の論理 IP アドレスを割り当てることができます。IP エリアスのコンフィグレーションは、サーバの基盤のオペレーティング システムで行われます。すべての論理アドレスが同一サブネット内のアドレスであるように IP エリアスをコンフィグレーションする場合は、節 4.8.3「すべてのアドレス (IP_ANY) でリスンするマルチホーム サーバ」で説明したように、すべてのアドレスでリスンするように Oracle WebLogic Communication Services を簡単にコンフィグレーションできます。

IP エリアスをコンフィグレーションして、異なるサブネット上の複数の論理 IP アドレスを作成する場合は、それぞれの論理アドレスのネットワーク チャネルを個別にコンフィグレーションする必要があります。このコンフィグレーションにおいて、Oracle WebLogic Communication Services ではすべての論理アドレスが別々の物理インタフェース (NIC) として扱われ、ルート リゾルバの機能により、各インタフェースでコンフィグレーションされているチャネルの情報に基づいて OSI レイヤ 4 およびレイヤ 7 に情報が格納されます。

4.8.5 ロード バランサのコンフィグレーション

ロード バランサは、複数のサーバ間でのフェイルオーバ機能やクライアントからの負荷の分散を実現するだけでなく、クライアントとサーバの間で送受信されるネットワーク情報をコンフィグレーションするためのツールとしても重要です。以下の節では、Oracle WebLogic Communication Services で使用される一般的なロード バランサのコンフィグレーションについて説明します。

4.8.5.1 単一のロード バランサのコンフィグレーション

最も一般的なロード バランサのコンフィグレーションでは、図 4-4 に示したように、単一のロード バランサを使用して、エンジン層サーバのクラスタにアクセスするためのゲートとして利用します。

図 4-4 単一のロード バランサのコンフィグレーション

「図 4-4 単一のロード バランサのコンフィグレーション」の説明

Oracle WebLogic Communication Services をコンフィグレーションして図 4-4 のように単一のロード バランサを使用するには、各サーバで 1 つまたは複数のネットワーク チャネルをコンフィグレーションした上で、ロード バランサの仮想 IP アドレスを使用するように各チャネルのパブリック アドレスをコンフィグレーションします。 このコンフィグレーションでは、その後の返信の クラスタにクライアントが確実に到達できるよう、Oracle WebLogic Communication Services は SIP メッセージ システム ヘッダにロード バランサ IP アドレスを組み込みます。第 4 章「ネットワーク リソースの管理」はロード バランサ アドレスに対してコンフィグレーション ネットワーク チャネルの詳細なステップを示します。

注意 :
ロード バランサとして使用されるスイッチの一部は、1 つの呼び出しのすべての SIP メッセージが同一のエンジン層サーバに送信されるように自動的に再ルーティングする機能を備えていますが、Oracle WebLogic Communication Services のロード バランサとして使用する場合は、この機能は必須ではありません。詳細については、節 15.7「他のコンフィグレーション」を参照してください。

4.8.5.2 複数のロード バランサおよびマルチホームのロード バランサを使用する場合

複数のロード バランサ (またはマルチホームのロード バランサ) をコンフィグレーションすると、Oracle WebLogic Communication Services の 1 つのクラスタに複数の仮想 IP アドレスを割り当てることができます。マルチホームのロード バランサを使用できるように Oracle WebLogic Communication Services をコンフィグレーションするには、各ロード バランサまたはローカル サーバの各 NIC に個別に専用のネットワーク チャネルを作成した上で、そのチャネルのパブリック アドレスとして、適切なロード バランサの仮想 IP アドレスを設定します。このコンフィグレーションでは、コンフィグレーションされたチャネルと、SIP メッセージの発信に使用される NIC との関連付けがルート リゾルバによって行われます。そして、選択されたチャネルのパブリック アドレスは、SIP システム メッセージ内にアドレス情報として格納されます。節 4.8.4.1「ルート リゾルバについて」を参照してください。

4.8.5.3 ネットワーク アドレス変換の選択肢

最も一般的な場合は、クライアントがパブリック IP アドレスを使用して Oracle WebLogic Communication Services の 1 つまたは複数の内部 (プライベート) アドレスと通信できるように、ロード バランサは送信先 NAT を使用するようにコンフィグレーションされます。ロード バランサでは、送信元 NAT を使用するようにコンフィグレーションして、プライベート アドレスから発信されるパケットのレイヤ 3 アドレス情報をロード バランサ自体の仮想 IP アドレスに一致するように変更することもできます。

ルート リゾルバがデフォルトの状態で動作している場合、Oracle WebLogic Communication Services エンジンから発信される UDP パケットの送信元 IP アドレスは、ローカル NIC のアドレス (プライベート アドレス) と一致します。外部からはローカル サーバのアドレスにアクセスできない場合があるので、このように発信元のアドレスとしてローカル アドレスが使用されていると、転送パケットに埋め込まれているレイヤ 3 のアドレスに直接応答しようとするアプリケーションにおいて問題が発生するおそれがあります。使用しているアプリケーションでこの問題が発生する場合は、転送レイヤ 3 のアドレスを外部からアクセス可能な仮想 IP アドレスに変更するために、ロード バランサで送信元 NAT を実行するようにコンフィグレーションすることをお勧めします。

4.8.5.3.1 送信元 NAT の代替としての IP マスカレード

Oracle WebLogic Communication Services では、ロード バランサでの送信元 NAT を有効にしない場合は、限定的な IP マスカレード機能を使用できます。この機能を使用するには、クラスタのロード バランサのパブリック IP アドレスを使用して、エンジン層の各サーバ上の論理アドレスをコンフィグレーションします。(同じ論理 IP アドレスをエンジン層の各サーバ マシン上で重複して使用します)。Oracle WebLogic Communication Services は、コンフィグレーションされているロード バランサの IP アドレス (ネットワーク チャネルのパブリック アドレスとして定義されているアドレス) に一致するローカル サーバ インタフェースを使用して SIP UDP メッセージを発信します。その場合、レイヤ 3 に格納されるアドレスはパブリック アドレスです。

警告 :
Oracle WebLogic Communication Services の IP マスカレード機能を使用すると、複数のサーバ上で重複した IP アドレスを設定することが必要になるので、ネットワークが不安定な状態になるおそれがあります。プロダクション デプロイメントでは、信頼性の高いネットワーク パフォーマンスを実現するために、IP マスカレードの使用は避け、その代わりに、送信元 NAT を行うようにコンフィグレーションされたロード バランサを使用してください。

Oracle Communications Converged Application Server の IP マスカレード機能を無効にするには、次の起動オプションを使用します。

-Dwlss.udp.lb.masquerade=false

4.9 ネットワーク コンフィグレーションの例

Oracle WebLogic Communication Services では SIP 非対応のロード バランサも使用可能です。SIP 非対応のロード バランサとは、サーバへのリクエストをルーティングする際に、進行中の SIP ダイアログを考慮しないロード バランサのことです。このドキュメントでは、ロード バランサと Oracle WebLogic Communication Services のコンフィグレーション、および、さまざまなコンフィグレーションにおいて SIP とネットワーク アドレス変換 (NAT) が相互に及ぼす影響について、実際的な例を示しながら説明します。

以下の節では、Oracle WebLogic Communication Services で SIP 非対応のロード バランサを使用する場合のネットワーク コンフィグレーションについて、ネットワーク コンフィグレーションの具体例を示しながら説明します。

NAT に関する実装固有の問題の詳細については、IETF のドキュメント NAT Behavioral Requirements for Unicast UDP (http://tools.ietf.org/wg/behave/draft-ietf-behave-nat-udp/) を参照してください。

4.9.1 ネットワーク トポロジの例

図 4-5 は、この節で説明するネットワーク トポロジの例を示したものです。 この例では、WLSS 1 および WLSS 2 の 2 つのエンジンで構成された Oracle WebLogic Communication Services クラスタが、プライベート IP ネットワーク 10.1/16 (内部的な 16 ビットのサブネット) 上にコンフィグレーションされています。クラスタのパブリック IP アドレスは 1.2.3.4 であり、このアドレスは、ロード バランサ上にコンフィグレーションされている仮想 IP アドレスです。

2.3.4.5 という IP アドレスを持つユーザ エージェント UAC A からは、Oracle WebLogic Communication Services クラスタのアドレスとしてコンフィグレーションされている内部 IP アドレスはまったく認識できません。ユーザ エージェント UAC A は、この内部アドレスではなく、パブリック アドレスの 1.2.3.4 に対してリクエストを送信し、1.2.3.4 から発信された応答を受信します。

以下の節では、この例のシステムの Oracle WebLogic Communication Services クラスタおよびロード バランサのコンフィグレーションについて説明します。

図 4-5 ネットワーク トポロジの例

「図 4-5 ネットワーク トポロジの例」の説明

4.9.2 Oracle WebLogic Communication Services のコンフィグレーション

WebLogic SIP Server クラスタのコンフィグレーションでは、各エンジンのパブリック アドレスは 5060、パブリック ポートは 1079038 に設定されています (節 4.2「ロード バランサのアドレスのコンフィグレーション」を参照)。 両方の Oracle WebLogic Communication Services エンジン上のデフォルト ルートは、ロード バランサの 10.1/16 ネットワーク インタフェース : 10.1.3.4 を示します。例 4-4 には、Oracle WebLogic Communication Services （WLSS 1 サーバと WLSS 2 サーバ) のルーティング テーブルを示します。

例 4-4 Oracle WebLogic Communication Services ルーティング テーブル

$ /sbin/route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.1.0.0           *            255.255.0.0     U     0      0        0 eth0
default         10.1.3.4        0.0.0.0         UG    0      0

4.9.3 ロード バランサのコンフィグレーション

ロード バランサには 1.2.3.4 という仮想 IP アドレスがコンフィグレーションされており、実際に使用される 2 つのサーバ WLSS 1 および WLSS 2 にはそれぞれ 10.1.1.1 および 10.1.1.2 のアドレスが割り当てられています。また、ロード バランサには、10.1/16 ネットワーク上の内部 IP アドレスである 10.1.3.4 も割り当てられています。UAC のアドレスである 2.3.4.5 は、ロード バランサ上の静的ルートのコンフィグレーションによって、ロード バランサからアクセス可能になっています。例 4-5 に、ロード バランサのルーティング テーブルの内容を示します。

例 4-5 ロード バランサのルーティング テーブル

$ /sbin/route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.1.0.0           *            255.255.0.0     U     0      0        0 eth1
1.2.0.0            *            255.255.0.0     U     0      0

SIP のユーザ エージェントがリクエストまたは応答を送信する際に使用する送信先 IP アドレスと UDP ポート番号は SIP プロトコル仕様 (RFC 3261) で規定されているため、ロード バランサの NAT コンフィグレーションは RFC 3261 の要件に違反しない形で行う必要があります。そのようなコンフィグレーションは、次の 3 つの設定方法で実現できます。

- 節 4.9.3.1「NAT ベースのコンフィグレーション」

- 節 4.9.3.2「maddr ベースのコンフィグレーション」

- 節 4.9.3.3「rport ベースのコンフィグレーション」

以下の節で、それぞれのアプローチについて説明します。

4.9.3.1 NAT ベースのコンフィグレーション

ロード バランサの UDP NAT のデフォルトの動作は、パブリック ネットワーク > プライベート ネットワークの方向に転送されるパケット対しては送信先 IP アドレス変換を実行し、プライベート ネットワーク > パブリック ネットワークの方向に転送されるパケットに対しては送信元 IP アドレス変換を実行することです。つまり、UAC > Oracle WebLogic Communication Services (2.3.4.5 -> 1.2.3.4) 方向のパケットに対しては送信元アドレス変換を行わずに送信先アドレス変換だけを実行し、Oracle WebLogic Communication Services > UAC (10.1/16 > 2.3.4.5) 方向のパケットに対しては送信先アドレス変換を行わずに送信元アドレス変換だけを実行するように設定します。

図 4-6 は、SUBSCRIBE/200OK トランザクション の UDP パケットの流れを示したものです。

図 4-6 SUBSCRIBE シーケンス

「図 4-6 SUBSCRIBE シーケンス」の説明

各 UDP パケットの送信元と送信先の IP アドレスは青字で記してあります。UAC > Oracle WebLogic Communication Services 方向のパケットの転送時にはロード バランサによって送信先 IP アドレス変換が行われますが、送信元 IP アドレスは変換されません。Oracle WebLogic Communication Services > UAC 方向のパケットの転送時にはロード バランサによって送信元 IP アドレス変換が行われますが、送信先 IP アドレスは変換されません。

図 4-6 のシーケンスの (IP ヘッダ、UDP のヘッダ、および SIP ペイロードを含む) 詳細なメッセージ トレースを次の例 4-6 に示します。

例 4-6 SUBSCRIBE の詳細なメッセージ トレース

No.     Time        Source                Destination           Protocol Info
1 1.425250    2.3.4.5           1.2.3.4          SIP      Request: SUBSCRIBE sip:subscribe@1.2.3.4:5060

Internet Protocol, Src: 2.3.4.5 (2.3.4.5), Dst: 1.2.3.4 (1.2.3.4)
User Datagram Protocol, Src Port: 9999 (9999), Dst Port: sip (5060)
Session Initiation Protocol
Request-Line: SUBSCRIBE sip:subscribe@1.2.3.4:5060 SIP/2.0
Message Header
Via: SIP/2.0/UDP 2.3.4.5:9999;branch=1
From: sipp <sip:sipp@2.3.4.5>;tag=1
To: sut <sip:subscribe@1.2.3.4:5060>
Call-ID: 1-25923@2.3.4.5
Cseq: 1 SUBSCRIBE
Contact: sip:sipp@2.3.4.5:9999
Max-Forwards: 70
Event: ua-profile
Expires: 10
Content-Length: 0

No.     Time        Source                Destination           Protocol Info
2 2.426250    2.3.4.5           10.1.1.1          SIP      Request: SUBSCRIBE sip:subscribe@1.2.3.4:5060

Internet Protocol, Src: 2.3.4.5 (2.3.4.5), Dst: 10.1.1.1 (10.1.1.1)
User Datagram Protocol, Src Port: 9999 (9999), Dst Port: sip (5060)
Session Initiation Protocol
Request-Line: SUBSCRIBE sip:subscribe@1.2.3.4:5060 SIP/2.0
Message Header
Via: SIP/2.0/UDP 2.3.4.5:9999;branch=1
From: sipp <sip:sipp@2.3.4.5>;tag=1
To: sut <sip:subscribe@1.2.3.4:5060>
Call-ID: 1-25923@2.3.4.5
Cseq: 1 SUBSCRIBE
Contact: sip:sipp@2.3.4.5:9999
Max-Forwards: 70
Event: ua-profile
Expires: 10
Content-Length: 0

No.     Time        Source                Destination           Protocol Info
3 3.430903    10.1.1.1               2.3.4.5           SIP      Status: 200 OK

Internet Protocol, Src: 10.1.1.1 (10.1.1.1), Dst: 2.3.4.5 (2.3.4.5)
User Datagram Protocol, Src Port: 42316 (42316), Dst Port: 9999 (9999)
Session Initiation Protocol
Status-Line: SIP/2.0 200 OK
Message Header
To: sut <sip:subscribe@1.2.3.4:5060>;tag=82722c03
Content-Length: 0
Contact: <sip:app-12eomtm5h5f77@1.2.3.4:5060;transport=udp;wlsscid=1ae4479ac6ff71>
CSeq: 1 SUBSCRIBE
Call-ID: 1-25923@2.3.4.5

このトランザクションに続いて Oracle WebLogic Communication Services が UAC に向けて NOTIFY リクエストを送信したとすると、次の図 4-7 に示したシーケンスが発生します。

図 4-7 NOTIFY シーケンス

「図 4-7 NOTIFY シーケンス」の説明

前のシーケンスの場合と同様、Oracle WebLogic Communication Services > UAC 方向のパケットの転送時には送信元 IP アドレス変換が行われ、UAC > Oracle WebLogic Communication Services 方向のパケットの転送時には送信先 IP アドレス変換が行われます。

このセットアップでは、ロード バランサがセッション ステート情報を保持する必要はなく、SIP 対応である必要もありません。図 4-7 のシーケンスの詳細なメッセージ トレースを次の例 4-7 に示します。

例 4-7 NOTIFY の詳細なメッセージ トレース

No.     Time        Source                Destination           Protocol Info
1 5.430952    10.1.1.1                2.3.4.5           SIP      Request: NOTIFY sip:sipp@2.3.4.5:9999

Internet Protocol, Src: 10.1.1.1 (10.1.1.1), Dst: 2.3.4.5 (2.3.4.5)
User Datagram Protocol, Src Port: 42316 (42316), Dst Port: 9999 (9999)
Session Initiation Protocol
Request-Line: NOTIFY sip:sipp@2.3.4.5:9999 SIP/2.0
Message Header
To: sipp <sip:sipp@2.3.4.5>;tag=1
Content-Length: 0
Contact: <sip:app-12eomtm5h5f77@1.2.3.4:5060;transport=udp;wlsscid=1ae4479ac6ff71>
CSeq: 1 NOTIFY
Call-ID: 1-25923@2.3.4.5
Via: SIP/2.0/UDP 1.2.3.4:5060;wlsscid=1ae4479ac6ff71;branch=z9hG4bKc5e4c3b4c22be517133ab749adeece4e
From: sut <sip:subscribe@1.2.3.4:5060>;tag=82722c03
Max-Forwards: 70

No.     Time        Source                Destination           Protocol Info
2 6.430952    1.2.3.4          2.3.4.5           SIP      Request: NOTIFY sip:sipp@2.3.4.5:9999

Internet Protocol, Src: 1.2.3.4 (1.2.3.4), Dst: 2.3.4.5 (2.3.4.5)
User Datagram Protocol, Src Port: 2222 (2222), Dst Port: 9999 (9999)
Session Initiation Protocol
Request-Line: NOTIFY sip:sipp@2.3.4.5:9999 SIP/2.0
Message Header
To: sipp <sip:sipp@2.3.4.5>;tag=1
Content-Length: 0
Contact: <sip:app-12eomtm5h5f77@1.2.3.4:5060;transport=udp;wlsscid=1ae4479ac6ff71>
CSeq: 1 NOTIFY
Call-ID: 1-25923@2.3.4.5
Via: SIP/2.0/UDP 1.2.3.4:5060;wlsscid=1ae4479ac6ff71;branch=z9hG4bKc5e4c3b4c22be517133ab749adeece4e
From: sut <sip:subscribe@1.2.3.4:5060>;tag=82722c03
Max-Forwards: 70

No.     Time        Source                Destination           Protocol Info
3 7.431367    2.3.4.5           1.2.3.4          SIP      Status: 200 OK

Internet Protocol, Src: 2.3.4.5 (2.3.4.5), Dst: 1.2.3.4 (1.2.3.4)
User Datagram Protocol, Src Port: 9999 (9999), Dst Port: sip (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 200 OK
Message Header
Via: SIP/2.0/UDP 1.2.3.4:5060;wlsscid=1ae4479ac6ff71;branch=z9hG4bKc5e4c3b4c22be517133ab749adeece4e
From: sut <sip:subscribe@1.2.3.4:5060>;tag=82722c03
To: sipp <sip:sipp@2.3.4.5>;tag=1;tag=1
Call-ID: 1-25923@2.3.4.5
CSeq: 1 NOTIFY
Contact: <sip:2.3.4.5:9999;transport=UDP>

警告 :
ロード バランサは通常、リクエストに対する応答では特定の送信先ポート番号が使用されることを前提としてアドレス変換を行うので、送信元 IP アドレス変換 (SNAT) と送信先 IP アドレス変換 (DNAT) の両方の NAT を実行すると、このコンフィグレーションは正常に機能しません。ポート番号の値は RFC 3261 によって規定されていて、Via ヘッダに記述されている値を使用することが必須となっていますが、このことはロード バランサの NAT の要件と衝突します。RFC 3261 の規定により、SIP リクエストに対する応答は、そのリクエストの送信に使用された IP アドレスに対して送信しなければなりません (ただし、節 4.9.3.2「maddr ベースのコンフィグレーション」で説明しているように、Via ヘッダ内に maddr パラメータの値が記述されている場合は、そのパラメータで指定されているアドレスが使用されます)。 したがって、次の図 4-8 の手順 3 では Oracle WebLogic Communication Services からロード バランサの内部 IP アドレス (10.1.3.4) のポート 5060 に対して 200 OK 応答が送信されます。 この応答はその時点で破棄されます。

図 4-8 送信元 NAT と送信先 NAT を両方有効にした場合のシーケンス

「図 4-8 送信元 NAT と送信先 NAT を両方有効にした場合のシーケンス」の説明

図 4-8 のシーケンスの詳細なメッセージ トレースを次の例 4-8 に示します。

例 4-8 失敗した SUBSCRIBE の詳細なメッセージ トレース

No.     Time        Source                Destination           Protocol Info
1 1.425250    2.3.4.5           1.2.3.4          SIP      Request: SUBSCRIBE sip:subscribe@1.2.3.4:5060

Internet Protocol, Src: 2.3.4.5 (2.3.4.5), Dst: 1.2.3.4 (1.2.3.4)
User Datagram Protocol, Src Port: 9999 (9999), Dst Port: sip (5060)
Session Initiation Protocol
Request-Line: SUBSCRIBE sip:subscribe@1.2.3.4:5060 SIP/2.0
Message Header
Via: SIP/2.0/UDP 2.3.4.5:9999;branch=1
From: sipp <sip:sipp@2.3.4.5>;tag=1
To: sut <sip:subscribe@1.2.3.4:5060>
Call-ID: 1-25923@2.3.4.5
Cseq: 1 SUBSCRIBE
Contact: sip:sipp@2.3.4.5:9999
Max-Forwards: 70
Event: ua-profile
Expires: 10
Content-Length: 0

No.     Time        Source                Destination           Protocol Info
2 2.426250    10.1.3.4           10.1.1.1          SIP      Request: SUBSCRIBE sip:subscribe@1.2.3.4:5060

Internet Protocol, Src: 10.1.3.4 (10.1.3.4), Dst: 10.1.1.1 (10.1.1.1)
User Datagram Protocol, Src Port: 2222 (2222), Dst Port: sip (5060)
Session Initiation Protocol
Request-Line: SUBSCRIBE sip:subscribe@1.2.3.4:5060 SIP/2.0
Message Header
Via: SIP/2.0/UDP 2.3.4.5:9999;branch=1
From: sipp <sip:sipp@2.3.4.5>;tag=1
To: sut <sip:subscribe@1.2.3.4:5060>
Call-ID: 1-25923@2.3.4.5
Cseq: 1 SUBSCRIBE
Contact: sip:sipp@2.3.4.5:9999
Max-Forwards: 70
Event: ua-profile
Expires: 10
Content-Length: 0

No.     Time        Source                Destination           Protocol Info
3 3.430903    10.1.1.1               10.1.3.4           SIP      Status: 200 OK

Internet Protocol, Src: 10.1.1.1 (10.1.1.1), Dst: 10.1.3.4 (10.1.3.4)
User Datagram Protocol, Src Port: 42316 (42316), Dst Port: 9999 (9999)
Session Initiation Protocol

4.9.3.2 maddr ベースのコンフィグレーション

Via ヘッダ内に maddr パラメータの値が記述されている場合、応答はリクエストの送信元の IP アドレスに対してではなく、maddr パラメータで指定されている IP アドレスに送信されます (このことは SNAT が有効に設定されている場合でも同じです)。次の例では、UAC からのリクエストの Via ヘッダ内に maddr パラメータが記述されていて、その値として 2.3.4.5 が設定されています。そのため、SIP サーバからの応答は問題なく UAC に着信します。

図 4-9 maddr シーケンス

「図 4-9 maddr シーケンス」の説明

図 4-9 のシーケンスの詳細なメッセージ トレースを次の例 4-9 に示します。

例 4-9 maddr が指定されている場合の詳細なメッセージ トレース

No.     Time        Source                Destination           Protocol Info
1 1.425250    2.3.4.5           1.2.3.4          SIP      Request: SUBSCRIBE sip:subscribe@1.2.3.4:5060

Internet Protocol, Src: 2.3.4.5 (2.3.4.5), Dst: 1.2.3.4 (1.2.3.4)
User Datagram Protocol, Src Port: 9999 (9999), Dst Port: sip (5060)
Session Initiation Protocol
Request-Line: SUBSCRIBE sip:subscribe@1.2.3.4:5060 SIP/2.0
Message Header
Via: SIP/2.0/UDP 2.3.4.5:9999;maddr=2.3.4.5;branch=1
From: sipp <sip:sipp@2.3.4.5>;tag=1
To: sut <sip:subscribe@1.2.3.4:5060>
Call-ID: 1-25923@2.3.4.5
Cseq: 1 SUBSCRIBE
Contact: sip:sipp@2.3.4.5:9999
Max-Forwards: 70
Event: ua-profile
Expires: 10
Content-Length: 0

No.     Time        Source                Destination           Protocol Info
2 2.426250    10.1.3.4           10.1.1.1          SIP      Request: SUBSCRIBE sip:subscribe@1.2.3.4:5060

Internet Protocol, Src: 10.1.3.4 (10.1.3.4), Dst: 10.1.1.1 (10.1.1.1)
User Datagram Protocol, Src Port: 2222 (2222), Dst Port: sip (5060)
Session Initiation Protocol
Request-Line: SUBSCRIBE sip:subscribe@1.2.3.4:5060 SIP/2.0
Message Header
Via: SIP/2.0/UDP 2.3.4.5:9999;maddr=2.3.4.5;branch=1
From: sipp <sip:sipp@2.3.4.5>;tag=1
To: sut <sip:subscribe@1.2.3.4:5060>
Call-ID: 1-25923@2.3.4.5
Cseq: 1 SUBSCRIBE
Contact: sip:sipp@2.3.4.5:9999
Max-Forwards: 70
Event: ua-profile
Expires: 10
Content-Length: 0

No.     Time        Source                Destination           Protocol Info
3 3.430903    10.1.1.1               2.3.4.5           SIP      Status: 200 OK

Internet Protocol, Src: 10.1.1.1 (10.1.1.1), Dst: 2.3.4.5 (2.3.4.5)
User Datagram Protocol, Src Port: 42316 (42316), Dst Port: 9999 (9999)
Session Initiation Protocol
Status-Line: SIP/2.0 200 OK
Message Header
To: sut <sip:subscribe@1.2.3.4:5060>;tag=82722c03
Content-Length: 0
Contact: <sip:app-12eomtm5h5f77@1.2.3.4:5060;transport=udp;wlsscid=1ae4479ac6ff71>

4.9.3.3 rport ベースのコンフィグレーション

RFC 3581 では、SIP と NAT が相互に及ぼす影響を改善するために、クライアントがサーバに対して、応答の送信先として Via ヘッダに記述されている UDP ポート番号ではなく、リクエストの送信に使用されたポート番号を使用することを要求できるようになっています。この方法で SUBSCRIBE と NOTIFY の両方のメッセージを正常に送受信できるようにするには、UAC と Oracle WebLogic Communication Services の両方で RFC 3581 がサポートされている必要があります。図 4-10 は SUBSCRIBE の流れを示したものです。

図 4-10 rport を使用した場合の SUBSCRIBE シーケンス

「図 4-10 rport を使用した場合の SUBSCRIBE シーケンス」の説明

図 4-10 のシーケンスの詳細なメッセージ トレースを次の例 4-10 に示します。

例 4-10 rport を使用した場合の SUBSCRIBE の詳細なメッセージ トレース

No.     Time        Source                Destination           Protocol Info
1 1.425250    2.3.4.5           1.2.3.4          SIP      Request: SUBSCRIBE sip:subscribe@1.2.3.4:5060

Internet Protocol, Src: 2.3.4.5 (2.3.4.5), Dst: 1.2.3.4 (1.2.3.4)
User Datagram Protocol, Src Port: 9999 (9999), Dst Port: sip (5060)
Session Initiation Protocol
Request-Line: SUBSCRIBE sip:subscribe@1.2.3.4:5060 SIP/2.0
Message Header
Via: SIP/2.0/UDP 2.3.4.5:9999;rport;branch=1
From: sipp <sip:sipp@2.3.4.5>;tag=1
To: sut <sip:subscribe@1.2.3.4:5060>
Call-ID: 1-25923@2.3.4.5
Cseq: 1 SUBSCRIBE
Contact: sip:sipp@2.3.4.5:9999
Max-Forwards: 70
Event: ua-profile
Expires: 10
Content-Length: 0

No.     Time        Source                Destination           Protocol Info
2 2.426250    10.1.3.4           10.1.1.1          SIP      Request: SUBSCRIBE sip:subscribe@1.2.3.4:5060

Internet Protocol, Src: 10.1.3.4 (10.1.3.4), Dst: 10.1.1.1 (10.1.1.1)
User Datagram Protocol, Src Port: 2222 (2222), Dst Port: sip (5060)
Session Initiation Protocol
Request-Line: SUBSCRIBE sip:subscribe@1.2.3.4:5060 SIP/2.0
Message Header
Via: SIP/2.0/UDP 2.3.4.5:9999;rport;branch=1
From: sipp <sip:sipp@2.3.4.5>;tag=1
To: sut <sip:subscribe@1.2.3.4:5060>
Call-ID: 1-25923@2.3.4.5
Cseq: 1 SUBSCRIBE
Contact: sip:sipp@2.3.4.5:9999
Max-Forwards: 70
Event: ua-profile
Expires: 10
Content-Length: 0

No.     Time        Source                Destination           Protocol Info
3 3.430903    10.1.1.1               10.1.3.4           SIP      Status: 200 OK

Internet Protocol, Src: 10.1.1.1 (10.1.1.1), Dst: 10.1.3.4 (10.1.3.4)
User Datagram Protocol, Src Port: 42316 (42316), Dst Port: 2222 (2222)
Session Initiation Protocol
Status-Line: SIP/2.0 200 OK
Message Header
To: sut <sip:subscribe@1.2.3.4:5060>;tag=82722c03
Content-Length: 0
Contact: <sip:app-12eomtm5h5f77@1.2.3.4:5060;transport=udp;wlsscid=1ae4479ac6ff71>
CSeq: 1 SUBSCRIBE
Call-ID: 1-25923@2.3.4.5

図 4-11 は NOTIFY の流れを示したものです。

送信元アドレスの NAT は両方向 (UAS > Oracle WebLogic Communication Services および Oracle WebLogic Communication Services > UA) とも有効に設定されていますが、ロード バランサは、リクエストの送信に使用したポートと同じポートに応答が返されるという前提に基づいて、手順 3 の送信先アドレスを適切に識別することができます。 このことは、ロード バランサによってステート情報が保持されていることを意味します。

図 4-11 rport を使用した場合の NOTIFY シーケンス

「図 4-11 rport を使用した場合の NOTIFY シーケンス」の説明

図 4-11 のシーケンスの詳細なメッセージ トレースを次の例 4-11 に示します。

例 4-11 rport を使用した場合の NOTIFY の詳細なメッセージ トレース

No.     Time        Source                Destination           Protocol Info
1 5.430952    10.1.1.1                2.3.4.5           SIP      Request: NOTIFY sip:sipp@2.3.4.5:9999

Internet Protocol, Src: 10.1.1.1 (10.1.1.1), Dst: 2.3.4.5 (2.3.4.5)
User Datagram Protocol, Src Port: 42316 (42316), Dst Port: 9999 (9999)
Session Initiation Protocol
Request-Line: NOTIFY sip:sipp@2.3.4.5:9999 SIP/2.0
Message Header
To: sipp <sip:sipp@2.3.4.5>;tag=1
Content-Length: 0
Contact: <sip:app-12eomtm5h5f77@1.2.3.4:5060;transport=udp;wlsscid=1ae4479ac6ff71>
CSeq: 1 NOTIFY
Call-ID: 1-25923@2.3.4.5
Via: SIP/2.0/UDP 1.2.3.4:5060;wlsscid=1ae4479ac6ff71;branch=z9hG4bKc5e4c3b4c22be517133ab749adeece4e;rport
From: sut <sip:subscribe@1.2.3.4:5060>;tag=82722c03
Max-Forwards: 70

No.     Time        Source                Destination           Protocol Info
2 6.430952    1.2.3.4          2.3.4.5           SIP      Request: NOTIFY sip:sipp@2.3.4.5:9999

Internet Protocol, Src: 1.2.3.4 (1.2.3.4), Dst: 2.3.4.5 (2.3.4.5)
User Datagram Protocol, Src Port: 2222 (2222), Dst Port: 9999 (9999)
Session Initiation Protocol
Request-Line: NOTIFY sip:sipp@2.3.4.5:9999 SIP/2.0
Message Header
To: sipp <sip:sipp@2.3.4.5>;tag=1
Content-Length: 0
Contact: <sip:app-12eomtm5h5f77@1.2.3.4:5060;transport=udp;wlsscid=1ae4479ac6ff71>
CSeq: 1 NOTIFY
Call-ID: 1-25923@2.3.4.5
Via: SIP/2.0/UDP 1.2.3.4:5060;wlsscid=1ae4479ac6ff71;branch=z9hG4bKc5e4c3b4c22be517133ab749adeece4e;rport
From: sut <sip:subscribe@1.2.3.4:5060>;tag=82722c03
Max-Forwards: 70

No.     Time        Source                Destination           Protocol Info
3 7.431367    2.3.4.5           1.2.3.4          SIP      Status: 200 OK

Internet Protocol, Src: 2.3.4.5 (2.3.4.5), Dst: 1.2.3.4 (1.2.3.4)
User Datagram Protocol, Src Port: 9999 (9999), Dst Port: (2222)
Session Initiation Protocol
Status-Line: SIP/2.0 200 OK
Message Header
Via: SIP/2.0/UDP 1.2.3.4:5060;wlsscid=1ae4479ac6ff71;branch=z9hG4bKc5e4c3b4c22be517133ab749adeece4e;rport
From: sut <sip:subscribe@1.2.3.4:5060>;tag=82722c03
To: sipp <sip:sipp@2.3.4.5>;tag=1;tag=1
Call-ID: 1-25923@2.3.4.5
CSeq: 1 NOTIFY
Contact: <sip:2.3.4.5:9999;transport=UDP

5 セキュリティ機能の管理

以下の節では、Oracle WebLogic Communication Services のセキュリティの概要を説明します。

- 節 5.1「SIP サーブレットの認証」

- 節 5.2「信頼できるホストでの認証のオーバーライド」

- 節 5.3「ID アサーション サポート」

- 節 5.4「SIP サーブレット宣言型セキュリティのロールの割り当て」

- 節 5.5「セキュリティ イベントの監査」

- 節 5.6「一般的なセキュリティ コンフィグレーション タスク」

5.1 SIP サーブレットの認証

Oracle WebLogic Communication Services のユーザは、デプロイされた SIP サーブレット内の保護されたメソッドなど、保護されたリソースへのアクセスを要求するときは常に認証を受ける必要があります。Oracle WebLogic Communication Services では、以下のような手法を使って SIP サーブレットのユーザ認証を実装できます。

- ダイジェスト認証では、単純なチャレンジ/応答メカニズムを使用して、SIP を介してユーザの身元を確認します。この手法の詳細については、節 5.7「ダイジェスト認証のコンフィグレーション」を参照してください。HTTP 経由で認証するには、アプリケーション開発者が独自の実装を提供する必要があります。

- CLIENT-CERT 認証では、SIP アプリケーションに渡される X509 証明書チェーンを使用してユーザを認証します。X509 証明書チェーンは、さまざまな方法で提供することができます。最も一般的なケースでは、チェーンを送信する前に双方向 SSL ハンドシェイクを実行し、クライアントとサーバ間のセキュアな通信を確保します。CLIENT-CERT 認証の詳細については、節 5.8「Client-Cert 認証のコンフィグレーション」を参照してください。

Oracle WebLogic Communication Services 上にデプロイされる SIP サーブレットごとに、必要に応じて別々の認証メカニズムを使うことができます。必要な認証メカニズムは、SIP サーブレットの sip.xml デプロイメント記述子の auth-method 要素で指定します。デプロイメント記述子では、どのリソースを保護するかを定義し、アクセスに必要な特定のロール名を列挙することもできます。SIP サーブレット v1.1 仕様では、アプリケーションで必要なまたはサポート対象のレルム名と ID アサーション メカニズムを指定する能力を紹介します。Servlet 認証および ID アサーション メカニズムの定義については、SIP サーブレット v1.1 仕様を参照してください。

5.1.1 認証プロバイダ

Oracle WebLogic Communication Services の認証サービスは、1 つまたは複数の認証プロバイダを使って実装されます。認証プロバイダは、ユーザやシステム プロセスの ID を証明した後、ID 情報をシステムの他のコンポーネントに送信する働きをします。

複数の認証プロバイダを使用して、別々の認証方式を使うようにコンフィグレーションすることも、連携して認証を行うようにコンフィグレーションすることもできます。たとえばダイジェスト認証を使用する場合、通常はダイジェストの有効性をアサートするダイジェスト ID アサーション プロバイダと、検証済みのユーザのグループ メンバシップを判断する LDAP または RDBMS 認証プロバイダの両方をコンフィグレーションします。

複数の認証プロバイダを連携させる場合は、プロバイダがユーザを評価する順序を指定し、さらに各プロバイダが認証プロセスをどの程度制御するかを指定する必要があります。各プロバイダは、そのユーザを有効と判断するかどうかを表明する「投票」を行うことができます。プロバイダの制御フラグは、プロバイダの投票が認証プロセスでどのように使われるかを示します。

プロバイダのコンフィグレーションの詳細については、節 5.7「ダイジェスト認証のコンフィグレーション」または節 5.8「Client-Cert 認証のコンフィグレーション」を参照してください。

5.2 信頼できるホストでの認証のオーバーライド

Oracle WebLogic Communication Services では、システムにとって信頼できるホストを指定することもできます。信頼できるホストとは、Oracle WebLogic Communication Services が何も認証を行わないホストのことです。コンフィグレーションされている信頼できるホスト名と一致する宛先アドレスを含む SIP メッセージを受け取った場合、サーバは認証なしでメッセージを配信します。詳細については、『Oracle Fusion Middleware Security Guide』を参照してください。

5.3 ID アサーション サポート

Oracle WebLogic Communication Services では、RFC 3325 で規定されている P-Asserted-Identity SIP ヘッダがサポートされています。この機能では、信頼できるホストから送られてきた場合に、P-Asserted-Identity ヘッダで指定された資格を使って自動的にログインを行います。privacy ヘッダと P-Asserted-Identity の組み合わせにより、メッセージを信頼できるホストや信頼できないホストに転送できるかどうかも決まります。

Oracle WebLogic Communication Services では、RFC 4474 で規定されている Identity および Identity-Info ヘッダを使用して、ID アサーションがサポートされています。

両方の ID アサーション メカニズムでは、Oracle WebLogic Communication Services との適当なセキュリティ プロバイダをコンフィグレーションする必要があります。詳細については、節 5.9「SIP サーブレット ID アサーション メカニズムのコンフィグレーション」を参照してください。

5.4 SIP サーブレット宣言型セキュリティのロールの割り当て

SIP サーブレット API 仕様では、SIP サーブレットの宣言型セキュリティおよびプログラムに基づくセキュリティの提供に使用できるデプロイメント記述子要素のセットを定義します。セキュリティ制約を宣言する主な方法は、sip.xml デプロイメント記述子で 1 つまたは複数の security-constraint 要素とロール定義を指定することです。Oracle WebLogic Communication Services では、開発者が SIP サーブレットのロールを、SIP サーブレット コンテナでコンフィグレーションされた実際のプリンシパルやロールに容易にマップできるように、デプロイメント記述子の要素が追加されています。

5.5 セキュリティ イベントの監査

Oracle WebLogic Communication Services に用意されている監査プロバイダをコンフィグレーションすると、セキュリティ レルム内の認証イベントをモニタすることができます。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』を参照してください。

5.6 一般的なセキュリティ コンフィグレーション タスク

表 5-1 は、Oracle WebLogic Communication Services のコンフィグレーション タスクと、追加情報へのリンクを示しています。

表 5-1 セキュリティ コンフィグレーション タスク

タスク

説明

節 5.7「ダイジェスト認証のコンフィグレーション」

- ダイジェスト ID アサーション プロバイダの概要

- LDAP ダイジェスト認証のコンフィグレーション

- RDBMS を使用したダイジェスト認証のコンフィグレーション

節 5.8「Client-Cert 認証のコンフィグレーション」

- Client-Cert 認証ソリューションの概要

- 双方向 SSL を介した X509 証明書の配信

- 境界認証ソリューションの開発

- Oracle WebLogic Communication Services WL_Client_Cert ヘッダを使った X509 証明書の配信

節 5.9「SIP サーブレット ID アサーション メカニズムのコンフィグレーション」

- P-Asserted-Identity ヘッダが含まれる SIP メッセージの転送ルールの概要

- P-Asserted-Identity プロバイダのコンフィグレーション

5.7 ダイジェスト認証のコンフィグレーション

以下の節では、ダイジェスト認証についての概要と、Oracle WebLogic Communication Services でのダイジェスト認証のサポートとコンフィグレーションについて説明します。

5.7.1 ダイジェスト認証とは

ダイジェスト認証とは、SIP または HTTP でユーザ認証に使用するシンプルなチャレンジ/応答メカニズムです。ダイジェスト認証の詳細は RFC 2617 で規定されています。

ダイジェスト認証を使用しているときに、保護されているサーバ リソースに対してクライアントが未認証のリクエストを行うと、サーバからクライアントに対して、nonce 値を使用してチャレンジが送信されます。クライアントは、要求されたアルゴリズム (デフォルトでは MD5) を使用して、暗号化された応答 (ダイジェスト) を生成します。その中には、ユーザ名、パスワード、およびレルムが含まれます。

サーバは、自らダイジェスト値を再作成し、クライアントから受け取ったダイジェストと比較することで、クライアントのダイジェストを検証します。サーバは、ダイジェスト値を再作成するために、A1 値 (RFC 2617 を参照) のハッシュを必要とします。この中には、nonce、ユーザ名、パスワード、およびレルム名が少なくとも必要です。サーバが A1 値のハッシュを再作成するときには、格納してある当該ユーザのクリアテキストのパスワードを取得して求めるか、または計算済みのハッシュ値を取得します。クリアテキストのパスワードまたは計算済みのハッシュ値は、LDAP ディレクトリに格納してあるか、JDBC を使用して RDBMS から利用するかのいずれかです。そしてサーバは、A1 値のハッシュを使用してダイジェストを再作成し、クライアントのダイジェストと比較して、ユーザの ID を検証します。

ダイジェスト認証では、クライアントとサーバの間でクリアテキスト パスワードが送信されないため、HTTP 上で安全な認証を実現できます。また、クライアントのチャレンジで nonce 値を使用するため、ダイジェスト認証はリプレイ攻撃への耐性があります。一般的なリクエストでのチャレンジ/応答のメカニズムの詳細については、図 5-1 を参照してください。

5.7.2 Oracle WebLogic Communication Services でのダイジェスト認証のサポート

Oracle WebLogic Communication Services には、LDAP または RDBMS を使用してクライアントのダイジェストの有効性を確認するための LDAP ダイジェスト ID アサーション セキュリティ プロバイダが含まれています。認証プロセスを完了するためには、認可プロバイダが別途必要です (節 5.7.4.3「認証プロバイダのコンフィグレーション」を参照)。

ダイジェスト ID アサーション プロバイダが行うのは、クライアントのダイジェストを使用したユーザの資格を検証することだけです。ダイジェストを検証した後は、コンフィグレーション済みの認可プロバイダが、ユーザ名に基づいてそのユーザの存在をチェックし、結果の javax.security.auth.Subject のグループ メンバシップを設定して、認証プロセスを完了します。

ダイジェスト ID アサーション プロバイダでは、次のいずれかの形で、LDAP サーバまたは RDBMS にユーザ資格が格納されている必要があります。

- 暗号化されていない (クリア テキスト) パスワード。最も単純なコンフィグレーションで、ユーザの暗号化されていないパスワードをストアに格納します。この方法を使用する場合は、サーバ側のネットワーク トラフィックでクリアテキストのパスワードがそのまま流用されることのリスクを軽減するために、LDAP ストアまたはデータベースへの接続に SSL 接続を使用することをお勧めします。LDAP ストアによっては、暗号化されていないパスワードをデフォルトでサポートしていないものもあります。その場合は、パスワードを格納するための LDAP サーバで専用の資格属性を作成したり使用したりする必要があります。節 5.7.4.1「LDAP サーバまたは RDBMS のコンフィグレーション」を参照してください。

- 逆暗号化パスワード。Oracle WebLogic Communication Services に用意されているユーティリティを使用すると、ダイジェスト認可 ID アサーション プロバイダをコンフィグレーションするときに使用する、暗号化キー、暗号化の初期ベクタ、および暗号化パスワードの各値を計算できます。

- 各パスワード、ユーザ名およびレルムのあらかじめ計算したハッシュ。暗号化されていないパスワードまたは逆暗号化パスワードの格納ができない場合、その代わりに、LDAP または RDBMS の新規または既存の属性内のユーザ名、セキュリティ レルムおよびパスワードのあらかじめ計算したハッシュ値を格納できます。そして、ダイジェスト ID アサーション プロバイダは、ハッシュ値のみを取得し、クライアントが生成したダイジェストのハッシュと比較します。計算済みのハッシュ値を格納する方がセキュリティは高まります。

LDAP ダイジェスト ID アサーション プロバイダは、クリアテキストのパスワードや計算済みのハッシュ値を格納できるすべての LDAP プロバイダと互換性があります。

注意 :
組み込み LDAP ストアのスキーマを変更して、クリアテキストのパスワードや計算済みのハッシュ値を格納するための専用のフィールドを追加することはできません。ただし、テストやデモンストレーションの目的では、定義済みの「記述」フィールドにパスワード情報を格納できます。
認証の判断に DefaultAuthenticator プロバイダを使用しない場合は、ダイジェスト認証を使用する前に、DefaultAuthenticator をオプションのプロバイダにする (制御フラグを SUFFICIENT 以下にする) 必要があります。通常、クリアテキストまたはハッシュのパスワード情報の保持に別個の LDAP ストアを使用するプロダクション インストールでは、これは必須のコンフィグレーションです。

図 5-1 Oracle WebLogic Communication Services でのダイジェスト認証

「図 5-1 Oracle WebLogic Communication Services でのダイジェスト認証」の説明

図 5-1 は、一般的なクライアント リクエストにおける ID アサーション プロバイダの基本的なアーキテクチャと使用法を示します。

1. クライアントが、保護されたアプリケーション リソースに対して、未認証のリクエストを行います (sip-xml デプロイメント記述子でセキュリティ制約を指定すると、SIP サーブレット リソースが保護されます)。

2. ダイジェスト ID アサーション プロバイダは、nonce 値、レルム名、および暗号アルゴリズム (MD5 または MD5-sess) で構成されるチャレンジ文字列を生成します。SIP コンテナがチャレンジ文字列をクライアントに送信します。

注意 :
ダイジェスト ID アサーション プロバイダは、使用された nonce とタイムスタンプのキャッシュを指定の期間保持します。指定したタイムスタンプより古いタイムスタンプのリクエストはすべて拒否されます。また、キャッシュに保持されている最新のタイムスタンプ/nonce ペアと同じタイムスタンプ/nonce ペアを使用するリクエストもすべて拒否されます。

3. クライアントは、暗号化アルゴリズムを使用したダイジェストを作成します。このダイジェストは、ユーザ名、パスワード、実際の名前、nonce、SIP メソッド、リクエストされた URI、および RFC 2617 で定められたその他の情報で構成されます。

4. ダイジェスト ID アサーション プロバイダは、A1 値、nonce、SIP メソッドなどの情報のハッシュを使用したダイジェスト値を再作成し、クライアントのダイジェストを検証します。ID アサーション プロバイダは、A1 値のハッシュを取得するために、クリアテキストのパスワードをストアから取得して HA1 を生成するか、または計算済みの HA1 をストアから取得します。

5. 生成したダイジェスト文字列をクライアントのダイジェストと比較してユーザの ID を検証します。

6. ユーザの ID の検証が済むと、認証プロバイダは、ユーザが存在するかどうかを確認します。そして、存在する場合は、コンフィグレーションされたグループ情報を javax.security.auth.Subject に設定します。認証プロセスは以上で完了します。

注意 :
ユーザが存在するかどうかのチェックやグループの設定が必要ない場合には、特別な「何もしない」ID アサーション認証プロバイダを使用すると、LDAP サーバに対する余分な接続を回避できます。詳細については、節 5.7.4.3「認証プロバイダのコンフィグレーション」を参照してください。

認証が完了した後で、SIP サーブレット コンテナは、サーブレットの sip.xml デプロイメント記述子で定義された宣言によるセキュリティ制約に照らして、ログインした javax.security.auth.Subject の認可チェックを実行します。

LDAP ダイジェスト ID アサーション プロバイダと、コンフィグレーションされた認証プロバイダは、同じ LDAP ストアを使用することも、別々のストアを使用することもできます。

注意 :
複数の LDAP ストアを使用する場合は、図 5-2 に示すように、ユーザ資格の追加、削除、または変更に応じて両方のストアを同期するための何らかのインフラストラクチャを構築する必要があります。LDAP ストアを同期する方法については、このドキュメントでは取り上げません。

図 5-2 複数の LDAP サーバ

「図 5-2 複数の LDAP サーバ」の説明

5.7.3 LDAP ダイジェスト認証のコンフィグレーションの前提条件

ダイジェスト認証をコンフィグレーションするためには、LDAP サーバと LDAP 管理の基本を理解する必要があります。また、使用する LDAP サーバ実装の要件と制約を理解することと、LDAP のコンフィグレーションと Oracle WebLogic Communication Services のコンフィグレーションを変更する特権を持っていることも必要です。

表 5-1 は、Oracle WebLogic Communication Services と連係したダイジェスト認証を行うように LDAP サーバを完全にコンフィグレーションするために必要なすべての情報の概要です。

LDAP 認証プロバイダと、ダイジェスト認証 ID アサーション プロバイダは、複数の LDAP サーバに対してコンフィグレーションして、フェイルオーバ機能を実現できます。複数の LDAP サーバを使用したフェイルオーバ機能を実現するためには、ダイジェスト認証をコンフィグレーションするときに、各サーバに対する接続情報が必要です。節 5.7.4「ダイジェスト認証のコンフィグレーションの手順」を参照してください。

節 5.12「Oracle Internet Directory でのリソースのプロビジョニング」 は、Oracle Internet Directory の正しいリソースをプロビジョニングする方法について説明します。

表 5-2 ダイジェスト ID アサーション プロバイダのチェックリスト

項目

説明

値の例

Host

LDAP サーバのホスト名。

MyLDAPServer

Port

LDAP サーバのポート番号。デフォルトでは 389 番のポートが使用されています。

389

Principal

Oracle WebLogic Communication Services が LDAP サーバへの接続に使用できる識別名 (DN)。

cn=ldapadminuser

Credential

上記のプリンシパル名に対応する資格 (一般にはパスワード)。

ldapadminuserpassword

LDAP Connection Timeout

LDAP サーバへの接続に対してコンフィグレーションされたタイムアウト値 (秒単位)。パフォーマンスを最大限に高めるためには、LDAP サーバにタイムアウト値をコンフィグレーションしないようにします。LDAP サーバにタイムアウト値を設定した場合は、ダイジェスト ID アサーション プロバイダのタイムアウト値が LDAP サーバのタイムアウト値以下となるようにコンフィグレーションする必要があります。

30 秒

User From Name Filter

Oracle WebLogic Communication Services が指定のユーザ名の検索で使用する LDAP 検索フィルタ。この属性に値を指定しない場合、ユーザ スキーマに基づくデフォルトの検索フィルタが使用されます。

(&(cn=%u)(objectclass=person))

User Base DN

ユーザを格納する LDAP ディレクトリ内のツリーの基本識別名 (DN)。

cn=users,dc=mycompany,dc=com

Credential Attribute Name

ダイジェストの計算で使用する資格属性名。これは、暗号化されていないパスワードまたは計算済みのハッシュ値の格納に使用する属性名に対応します。節 5.7.4.1「LDAP サーバまたは RDBMS のコンフィグレーション」を参照してください。

hashvalue

Digest Realm Name

ダイジェスト認証で使用するレルム名。

mycompany.com

Digest Algorithm

暗号化されたダイジェストの作成でクライアントが使用するアルゴリズム。Oracle WebLogic Communication Services は MD5 アルゴリズムと MD5-sess アルゴリズムの両方をサポートします。デフォルトでは MD5 が使用されます。

MD5

Digest Timeout

ダイジェスト認証のタイムアウトの設定。デフォルトでは 2 秒に設定されています。

2

5.7.4 ダイジェスト認証のコンフィグレーションの手順

Oracle WebLogic Communication Services でダイジェスト認証をコンフィグレーションするには、次の手順に従います。

1. 節 5.7.4.1「LDAP サーバまたは RDBMS のコンフィグレーション」

2. 節 5.7.4.2「DefaultAuthenticator プロバイダのコンフィグレーションの変更」

注意 :
DefaultAuthenticator は、必須の認証プロバイダとしてデフォルトで設定されています。組み込み LDAP ストアに対して機能する DefaultAuthentication プロバイダを認証の判断に使用しない場合には、制御フラグを SUFFICIENT に変更する必要があります。

3. 節 5.7.4.3「認証プロバイダのコンフィグレーション」

4. 節 5.7.4.4「新しいダイジェスト ID アサーション プロバイダのコンフィグレーション」

以下の節では、各手順について詳しく説明します。

5.7.4.1 LDAP サーバまたは RDBMS のコンフィグレーション

ダイジェストの検証に使用する LDAP サーバまたは RDBMS には、暗号化されていないクリアテキストのパスワード、計算済みのハッシュ値、標準の暗号化アルゴリズム (デフォルトでは 3DES_EDE/CBC/PKCS5Padding) で暗号化されたパスワードのいずれかが格納されている必要があります。以下の節では、必要な情報を格納するための LDAP サーバまたは RDBMS の設定について、概要を示します。LDAP サーバでは、使用するスキーマや管理ツールが異なるため、以下の手順を実行する方法については、必要に応じて LDAP サーバのドキュメントを参照してください。

複数の LDAP サーバを使用したセキュリティ プロバイダのフェイルオーバ機能を有効にする場合は、各 LDAP サーバを次のようにコンフィグレーションする必要があります。

5.7.4.1.1 暗号化されていないパスワードの使用

RDBMS を使用する場合、または、LDAP サーバのスキーマで、暗号化されていないパスワードをユーザのパスワード属性に格納することが認められている場合は、さらにコンフィグレーションを行う必要はありません。ダイジェスト ID アサーション プロバイダは、デフォルトでは、パスワード フィールドで、暗号化されていないパスワードを検索します。

パスワード属性に対し、暗号化されていないパスワードの格納が認められていないスキーマの場合には、次の 2 つの方法があります。

- LDAP ディレクトリの既存の資格属性で未使用のものに対し、暗号化されていないパスワードを格納します。

- 新しい資格属性を作成して、暗号化されていないパスワードを格納します。

スキーマで利用可能な資格属性の詳細については、LDAP サーバのドキュメントを参照してください。どの方法を使用する場合も、暗号化されていないパスワードの格納に使用する正確な属性名を記録します。LDAP ダイジェスト ID アサーション プロバイダをコンフィグレーションするときに、この属性の名前を入力する必要があります。

5.7.4.1.2 計算済みのハッシュ値の使用

暗号化されていないパスワードではなく、計算済みのハッシュ値を使用する場合には、LDAP ディレクトリの次の 2 つの場所のどちらかにハッシュ値を格納できます。

- 既存の未使用の資格属性。

- ハッシュ値用に作成する新しい資格属性。

新しい資格属性の使用または作成の詳細については、LDAP サーバのドキュメントを参照してください。

RDBMS ストアの場合は、スキーマに含まれる任意のカラムにハッシュ値を格納できます。RDBMS ID アサーション プロバイダをコンフィグレーションするときに、ハッシュ値の取得に使用する SQL コマンドを定義します。

Oracle WebLogic Communication Services では、ユーザ名、レルム名、および暗号化されていないパスワードを指定して簡単なユーティリティ (PreCalculatedHash) で、A1 値のハッシュを生成できます。

また、サード パーティのユーティリティを使用したハッシュ値を生成したり、RFC 2617 の情報に基づいて独自のメソッドを作成することもできます。

ユーザ名、パスワード、またはレルム名の値が変更になったときに、格納したハッシュ値を自動的に更新するためのインフラストラクチャも構築する必要があります。パスワード情報をそのように維持する方法については、このドキュメントでは取り上げません。

5.7.4.1.3 逆暗号化パスワードの使用

Oracle WebLogic Communication Services に用意されているユーティリティを使用すると、ダイジェスト認可 ID アサーション プロバイダをコンフィグレーションするときに使用する、暗号化キー、暗号化の初期ベクタ、および暗号化パスワードの各値を計算できます。そのユーティリティの名前は JSafeEncryptionUtil で、WLSS_HOME/server/lib/wlss ディレクトリの wlss.jar ファイルにパッケージされています。

使用法の説明と構文を参照するには、次の手順に従います。

1. wlss.jar をクラスパスに追加します。デフォルトの場所は以下のとおりです (ただし、ユーザによるカスタマイズが可能です)。

export CLASSPATH=$CLASSPATH:WLSS_HOME=MW_HOME/wlcserver_10.3/server/lib/wlss/wlss.jar

2. オプションを指定せずにユーティリティを実行します。

5.7.4.2 DefaultAuthenticator プロバイダのコンフィグレーションの変更

プロダクション環境では、別個の LDAP プロバイダにパスワード情報を格納することが大半であり、したがって、組み込み LDAP ストアに対して機能する DefaultAuthenticator は認証に必須ではありません。この節の手順に従って、プロバイダの制御フラグを SUFFICIENT に変更します。

注意 :
DefaultAuthenticator は、必須の認証プロバイダとしてデフォルトで設定されています。組み込み LDAP ストアに対して機能する DefaultAuthentication プロバイダを認証の判断に使用しない場合には、制御フラグを SUFFICIENT に変更する必要があります。

DefaultAuthenticator プロバイダのコンフィグレーションを変更するには、次の手順に従います。

1. コンフィグレーションする Oracle WebLogic Communication Services ドメインの Administration Console にログインします。

2. コンソールの左ペインで、[セキュリティ レルム] ノードを選択します。

3. コンソールの右ペインで、セキュリティ レルム名を選択します。(たとえば、myrealm)

4. [プロバイダ｜認証] タブを選択します。

5. DefaultAuthenticator プロバイダを選択します。

6. [コンフィグレーション｜共通] タブで、[制御フラグ] の値を [SUFFICIENT] に変更します。

7. [保存] をクリックして変更内容を保存します。

5.7.4.3 認証プロバイダのコンフィグレーション

クライアントのダイジェストの検証のみを行うダイジェスト ID アサーション プロバイダに加えて、ユーザの存在のチェックとユーザのグループ情報の値の設定を行う認証プロバイダをコンフィグレーションする必要があります。『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』の手順に従って、LDAP サーバ用の LDAP 認証プロバイダを構築します。表 5-1「Oracle WebLogic Communication Services でのダイジェスト認証」の情報を使用して、プロバイダをコンフィグレーションします。

ユーザが存在するかどうかのチェックやグループの設定が必要ない場合には、Digest Identity Asserter プロバイダに加えて、「IdentityAssertionAuthenticator」という名前でパッケージ化された特別な「何もしない」ID アサーション認証プロバイダを使用すると、LDAP サーバに対する余分な接続を回避できます。このプロバイダはユーザ検証を実行しません。ユーザに対しグループ情報が必要ない場合に使用する必要があります。

「何もしない」認可プロバイダをコンフィグレーションするには、次の手順に従います。

1. コンフィグレーションする Oracle WebLogic Communication Services ドメインの Administration Console にログインします。

2. コンソールの左ペインで、[セキュリティ レルム] ノードを選択します。

3. コンソールの右ペインで、セキュリティ レルム名を選択します。(たとえば、myrealm)

4. [プロバイダ｜認証] タブを選択します。

5. [新規] をクリックします。

6. 新しいプロバイダ名を入力し、タイプには [IdentityAssertionAuthenticator] を選択します。

7. [OK] をクリックします。

8. プロバイダのリストから新しいプロバイダ名を選択します。

9. [コンフィグレーション｜共通] タブで、[制御フラグ] の値を [SUFFICIENT] に設定します。

10. [保存] をクリックして変更内容を保存します。

5.7.4.4 新しいダイジェスト ID アサーション プロバイダのコンフィグレーション

以下のどちらかの節の手順に従って、ダイジェスト ID アサーション プロバイダを作成し、LDAP サーバまたは RDBMS ストアと関連付けます。

- 節 5.7.4.4.1「LDAP ダイジェスト ID アサーション プロバイダのコンフィグレーション」

- 節 5.7.4.4.2「RDBMS ダイジェスト ID アサーション プロバイダのコンフィグレーション」

5.7.4.4.1 LDAP ダイジェスト ID アサーション プロバイダのコンフィグレーション

次の手順に従って、新しい LDAP ダイジェスト ID アサーション プロバイダを作成します。

1. コンフィグレーションする Oracle WebLogic Communication Services ドメインの Administration Console にログインします。

2. コンソールの左ペインで、[セキュリティ レルム] ノードを選択します。

3. コンソールの右ペインで、セキュリティ レルム名を選択します。(たとえば、myrealm)

4. [プロバイダ｜認証] タブを選択します。

5. [新規] をクリックします。

6. 新しいプロバイダ名を入力し、タイプには [LdapDigestIdentityAsserter] を選択します。

7. [OK] をクリックします。

8. プロバイダのリストから新しいプロバイダ名を選択します。

9. 右ペインでの [コンフィグレーション｜Provider Specific] タブを選択します。

10. コンフィグレーション ページで、LDAP サーバとダイジェスト認証の情報を各フィールドに次のように入力します (表 5-1 の情報を使用)。

- [User From Name Filter] : Oracle WebLogic Communication Services が指定のユーザ名の検索で使用する LDAP 検索フィルタを入力します。この属性に値を指定しない場合、ユーザ スキーマに基づくデフォルトの検索フィルタが使用されます。

- [User Base DN] : ユーザを格納する LDAP ディレクトリ内のツリーの基本識別名 (DN) を入力します (たとえば、cn=Users,dc=example,dc=com)。

- [Credential Attribute Name] : 計算済みのハッシュ値または暗号化されていないパスワードのいずれかを格納する、LDAP ディレクトリの資格属性を入力します (たとえば、authpassword;wlss)。デフォルトでは、ユーザ エントリのパスワード属性が使用されます。暗号化されていないパスワードではなく計算済みのハッシュ値を使用する場合や、暗号化されていないパスワードが別の属性に格納されている場合は、正しい属性名をここに指定する必要があります。

- [Group Attribute Name] : ユーザが属する一連のグループ名が格納された、LDAP ディレクトリのグループ属性を入力します。

- [Password Encryption Type] : パスワードが格納されている形式を、[PLAINTEXT]、[PRECALCULATEDHASH]、[REVERSIBLEENCRYPTED] のいずれかから選択します。

- [Encryption Algorithm] : 暗号化したパスワードを格納した場合は、ダイジェスト ID アサーション プロバイダが逆暗号化に使用する暗号化アルゴリズムを入力します。

- [Encryption Key] と [Please type again to confirm] : 暗号化されたパスワードを格納した場合は、逆暗号化アルゴリズムの中で使用される Base64 暗号化キーを入力します。

- [Encryption Init Vector] と [Please type again to confirm] : 暗号化されたパスワードを格納した場合は、逆暗号化アルゴリズムの中で使用される Base64 初期ベクタを入力します。

- [Digest Realm Name] : ダイジェスト認証で使用するレルム名を入力します (たとえば、example.com)。

- [Digest Algorithm] : ダイジェストの暗号化に使用するアルゴリズムとして [MD5] または [MD5-sess] を選択します。

- [Digest Timeout] : ダイジェスト チャレンジの nonce タイムアウト値を定義します。クライアントから応答がないままに nonce タイムアウトに達した場合は、新しい nonce でクライアントに対して改めてチャレンジが送信されます。デフォルトでは 120 秒に設定されています。

- [Host] : ダイジェスト認証に使用する LDAP サーバのホスト名を入力します。フェイルオーバ機能として複数の LDAP サーバを使用している場合は、各サーバに対応する hostname:port 値をスペース区切りで入力します。たとえば、「ldap1.mycompany.com:1050 ldap2.mycompany.com:1050」のように指定します。
フェイルオーバのコンフィグレーションの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』を参照してください。

- [Port] : LDAP サーバのポート番号を入力します。

- [SSL Enabled] : Oracle WebLogic Communication Services と LDAP サーバの間で、暗号化されていないパスワードを、SSL を使用して通信している場合は、このオプションをチェックします。

- [Principal] : Oracle WebLogic Communication Services が LDAP サーバへのアクセスに使用するプリンシパルの名前を入力します (たとえば、orclApplicationCommonName=WLSSInstance1,cn=WLSS,cn=Products,cn=OracleContext,dc=example,dc=com)。

- [Credential] と [Please type again to confirm]: 上記のプリンシパル名に対応する資格情報 (一般にはパスワード) を入力します。

- [OIDSupportEnabled] : LDAP プロバイダとして Oracle Internet Directory を使用している場合は、このチェックボックスをチェックします。RFC 2307 に記述されているように Oracle Internet Directory ではハッシュ値に {SASL/MD5} のプレフィックスが付けられるため、計算済みのハッシュ値を使用する場合は、このチェックボックスが必須です。その他の LDAP プロバイダではプレフィックスが省略されます。

11. [保存] をクリックして変更内容を保存します。

12. 右ペインで [パフォーマンス] タブを選択します。

13. [Performance] ページで、キャッシングと接続の情報を以下のフィールドに入力します。

- [LDAP Connection Pool Size] : LDAP サーバへの接続に使用する接続数を入力します。この値は、Oracle WebLogic Communication Services でコンフィグレーションされた実行スレッドの総数以下にする必要があります。現在コンフィグレーションされているスレッド数を参照するには、Administration Console の左ペインで Oracle WebLogic Communication Services の名前を右クリックし、[実行キューを表示] を選択します。SIP コンテナは、sip.transport.Default という名前のキューのスレッド数の値を使用します。LDAP Connection Pool Size のデフォルト値は 10 です。
古い接続 (たとえばロード バランサによりタイム アウトとなった LDAP 接続) は接続プールから自動的に削除されます。

- [Cache Enabled] : 対応する LDAP サーバでキャッシュを使用するかどうかを指定します。

- [Cache Size] : LDAP サーバからの結果の格納に使用するキャッシュのサイズを KB 単位で指定します。デフォルトのキャッシュ サイズは 32KB です。

- [Cache TTL] : LDAP キャッシュ用の存続時間 (TTL) の値を秒単位で指定します。デフォルトの TTL 値は 60 秒です。

- [Results Time Limit] : LDAP の結果を待つ最大ミリ秒数を指定します。この時間を超えるとタイム アウトになります。タイム リミットを設定しない場合は、デフォルト値の 0 をそのまま使用します。

- [Connect Timeout] : LDAP 接続が確立されるのを待つ最大ミリ秒数を指定します。この時間を超えると、接続はタイム アウトになります。タイムアウト値を設定しない場合は、デフォルト値の 0 を使用します。

- [Parallel Connect Delay] : コンフィグレーション済みの複数の LDAP サーバに同時に接続を試みるときに遅延する秒数を指定します。この値を 0 に設定した場合、プロバイダは複数サーバに順次接続します。プロバイダはまず、[Host] リストの最初のコンフィグレーション済み LDAP サーバへの接続を試みます。この接続が失敗した場合、プロバイダは、次のコンフィグレーション済みサーバに接続を試みます。以下同様です。
0 以外の値を設定した場合、プロバイダは、指定した秒数だけ待機したうえで、別の接続を試みるための新しいスレッドを生成します。たとえば、この値を 2 に設定した場合、プロバイダはまず、[Host] リストの最初のコンフィグレーション済み LDAP サーバに接続を試みます。2 秒が経過した時点で接続がまだ確立されていない場合、プロバイダは、新しいスレッドを生成し、[Host] リストの 2 番目のコンフィグレーション済み LDAP サーバへの接続を試みます。以下同様に、コンフィグレーション済みの各 LDAP サーバに対する接続を試みます。

- [Connection Retry Limit]: 接続の確立時に LDAP サーバが例外を送出した場合に、プロバイダが LDAP サーバへの接続の再確立を試行する回数を指定します。

14. [保存] をクリックして変更内容を保存します。

5.7.4.4.2 RDBMS ダイジェスト ID アサーション プロバイダのコンフィグレーション

次の手順に従って、新しい RDBMS ダイジェスト ID アサーション プロバイダを作成します。

1. コンフィグレーションする Oracle WebLogic Communication Services ドメインの Administration Console にログインします。

2. コンフィグレーション ロックを取得するには、[Lock & Edit] をクリックします。

3. コンソールの左ペインで、[セキュリティ レルム] ノードを選択します。

4. コンソールの右ペインで、セキュリティ レルム名を選択します。(たとえば、myrealm)

5. [プロバイダ｜認証] タブを選択します。

6. [新規] をクリックします。

7. 新しいプロバイダの名前を入力し、種類として DBMSDigestIdentityAsserter を選択します。

8. [OK] をクリックします。

9. プロバイダのリストから新しいプロバイダ名を選択します。

10. 右ペインでの [コンフィグレーション｜Provider Specific] タブを選択します。

11. [コンフィグレーション] タブで、RDBMS サーバとダイジェスト認証の情報を各フィールドに次のように入力します。

- [Data Source Name]: パスワード情報のアクセスに使用する JDBC データ ソースの名前を入力します。

- [SQLGet Users Password]: データベースからパスワードまたはハッシュ値を取得するときに使用する SQL 文を入力します。単一のレコードの結果セットを返す SQL 文であることが必要です。

- [SQLList Member Groups]: 指定したユーザ名からグループ情報を取得する SQL 文を入力します。ユーザ名は SQL 文に対して変数として渡します。たとえば、「SELECT G_NAME FROM groupmembers WHERE G_MEMBER = ?」のようにします。

- [Password Encryption Type]: パスワードが格納されている形式を、[PLAINTEXT]、[PRECALCULATEDHASH]、[REVERSIBLEENCRYPTED] のいずれかから選択します。

- [Encryption Algorithm]: 暗号化したパスワードを格納した場合は、ダイジェスト ID アサーション プロバイダが逆暗号化に使用する暗号化アルゴリズムを入力します。

- [Encryption Key] と [Please type again to confirm]: 暗号化されたパスワードを格納した場合は、逆暗号化アルゴリズムの中で使用される Base64 暗号化キーを入力します。

- [Encryption Init Vector] と [Please type again to confirm]: 暗号化されたパスワードを格納した場合は、逆暗号化アルゴリズムの中で使用される Base64 初期ベクタを入力します。

- [Digest Realm Name]: ダイジェスト認証で使用するレルム名を入力します。

- [Digest Algorithm]: ダイジェストの暗号化に使用するアルゴリズムとして [MD5] または [MD5-sess] を選択します。

- [Digest Timeout]: ダイジェスト チャレンジの nonce タイムアウト値を定義します。クライアントから応答がないままに nonce タイムアウトに達した場合は、新しい nonce でクライアントに対して改めてチャレンジが送信されます。デフォルトでは 120 秒に設定されています。

12. [保存] をクリックして変更内容を保存します。

5.7.5 組み込み LDAP を使用したダイジェスト認証のコンフィグレーションのサンプル

Oracle WebLogic Communication Services の組み込み LDAP 実装を利用すると、テストまたはデモ環境でダイジェスト認証を使用できます。組み込み LDAP ストアのスキーマは変更できないので、既存の「記述」フィールドにパスワード情報を格納する必要があります。

組み込み LDAP ストアをダイジェスト認証に使用するには、以下の節の手順に従います。

5.7.5.1 記述フィールドへのユーザ パスワード情報の格納

新しいユーザを作成し、既存の「記述」フィールドにパスワード情報を格納するには、次の手順に従います。

1. コンフィグレーションする Oracle WebLogic Communication Services ドメインの Administration Console にログインします。

2. コンソールの左ペインで、[セキュリティ レルム] ノードを選択します。

3. コンソールの右ペインで、セキュリティ レルム名を選択します。(たとえば、myrealm)

4. [ユーザおよびグループ｜ユーザ] タブを選択します。

5. [新規] をクリックします。

6. [名前] フィールドに、新しいユーザの名前を入力します。

7. [記述] フィールドに、このユーザのダイジェストのパスワード情報を入力します。パスワード情報は、クリアテキスト パスワード、計算済みのハッシュ値、または逆暗号化パスワードのいずれかとします。

8. [パスワード] フィールドと [パスワードの確認] フィールドに、8 文字のパスワードを入力します。標準のパスワード エントリを追加しないと、次へ進むことはできません。

9. [OK] をクリックします。

5.7.5.2 組み込み LDAP のパスワードの設定

次の手順に従って、組み込み LDAP ストアのパスワードを既知のパスワードに設定します。節 5.7.4.4.1「LDAP ダイジェスト ID アサーション プロバイダのコンフィグレーション」で説明するように、ダイジェスト ID アサーション プロバイダをコンフィグレーションするときにこのパスワードを使用します。

1. コンフィグレーションする Oracle WebLogic Communication Services ドメインの Administration Console にログインします。

2. 左ペインで、コンフィグレーションするドメイン名 （たとえば、mydomain） をクリックします。

3. 右ペインで、[Security｜Embedded LDAP] を選択します。

4. 使用するパスワードを、[資格] フィールドと [資格の確認] フィールドに入力します。

5. [保存] をクリックします。

6. サーバを再起動します。

5.7.5.3 ダイジェスト ID アサーション プロバイダのコンフィグレーション

例 5-1 は Oracle WebLogic Communication Services の組み込み LDAP 実装を使用するドメインの config.xml のセキュリティ プロバイダ コンフィグレーションを示します。このようなコンフィグレーションはテスティングや開発のみを目的とする場合に適しています。例 5-1 には、節 5.7.4.4.1「LDAP ダイジェスト ID アサーション プロバイダのコンフィグレーション」に示す手順にしたがってプロバイダをコンフィグレーションする時に定義する必要がある値について説明します。

例 5-1 組み込み LDAP でのセキュリティ プロバイダ コンフィグレーションのサンプル

<sec:authentication-provider xmlns:ext="http://www.bea.com/ns/weblogic/90/security/extension" xsi:type="ext:ldap-digest-identity-asserterType">
<sec:name>myrealmLdapDigestIdentityAsserter</sec:name>
<ext:user-base-dn>ou=people, ou=myrealm, dc=mydomain</ext:user-base-dn>
<ext:credential-attribute-name>description</ext:credential-attribute-name>
<ext:digest-realm-name>wlss.oracle.com</ext:digest-realm-name>
<ext:host>myserver.mycompany.com</ext:host>
<ext:port>7001</ext:port>
<ext:principal>cn=Admin</ext:principal>
</sec:authentication-provider>

5.8 Client-Cert 認証のコンフィグレーション

Client-Cert 認証では、証明書やその他のカスタム トークンを使用してユーザを認証します。トークンは、サーブレットがデプロイされている Oracle WebLogic Communication Services セキュリティ レルムに属するユーザに「マッピング」されています。Client-Cert 認証を使用する SIP サーブレットは、sip.xml デプロイメント記述子で auth-method 要素を CLIENT-CERT に設定する必要があります。

Client-Cert 認証に使用するトークンを取得するには、次のような方法があります。

- SSL の X509 証明書 - 通常、クライアントとサーバの間の双方向の SSL ハンドシェイクの際に、クライアント トークンから X509 証明書が取得されます。SIP サーブレットでは、取得された証明書を、リクエストの javax.servlet.request.X509Certificate 属性で参照できます。この方法による Client-Cert 認証の実行は最も一般的であり、SIP Servlet 仕様 (JSR-116) でも述べられています。Oracle WebLogic Communication Services には、X509 証明書の検証に使用できるセキュリティ プロバイダが つあります。節 5.8.1「Oracle WebLogic Communication Services での SSL と X509 のコンフィグレーション」を参照してください。

- WL-Proxy-Client-Cert ヘッダ - Oracle WebLogic Communication Services には、Client-Cert トークンを提供する方法がもう 1 つ用意されており、こちらはクライアントとサーバの間の双方向の SSL ハンドシェイクを必要としません。この方法では、SSL ハンドシェイクは、宛先の Oracle WebLogic Communication Services に達する前に、クライアントとプロキシ サーバまたはロード バランサの間で実行されます。プロキシは、X509 証明書チェーンを生成し、Base64 エンコーディングを使用して暗号化したうえで、SIP メッセージの特別な WL-Proxy-Client-Cert ヘッダに追加します。宛先の SIP サーブレットをホストするサーバは、この WL-Proxy-Client-Cert ヘッダを使用して証明書を取得します。また、コンテナからサーブレットに対しては、リクエストの javax.servlet.request.X509Certificate 属性を通じて証明書が提供されます。
この方法を使用してクライアント トークンを提供するには、WL-Proxy-Client-Cert ヘッダを使用できるように Oracle WebLogic Communication Services をコンフィグレーションする必要があります。節 5.8.2「Oracle WebLogic Communication Services での WL-Proxy-Client-Cert のコンフィグレーション」を参照してください。また、X509 ID アサーション プロバイダもコンフィグレーションする必要があります。詳細については、節 5.8.1「Oracle WebLogic Communication Services での SSL と X509 のコンフィグレーション」を参照してください。

SIP サーブレットでは、CLIENT-CERT auth-method を使用して境界認証を実装することもできます。境界認証では、カスタム トークンの名前と値、およびカスタム セキュリティ プロバイダを使用してクライアントを認証します。境界認証を実装するために必要な手順の概要については、節 5.8.3「カスタム ID アサーション プロバイダによる境界認証のサポート」を参照してください。

5.8.1 Oracle WebLogic Communication Services での SSL と X509 のコンフィグレーション

Oracle WebLogic Communication Services には、X509 証明書に対して使用できる ID アサーション プロバイダが 2 種類用意されています。LDAP X509 ID アサーション プロバイダは、X509 証明書を受け取り、その証明書に関連付けられたユーザの LDAP オブジェクトを別の LDAP ストアでルックアップして、LDAP オブジェクトの証明書が提示された証明書と一致することを確認したうえで、LDAP オブジェクトからユーザの名前を取得します。デフォルト ID アサーション プロバイダは、コンフィグレーションに基づいてユーザをマッピングしますが、証明書の検証は行いません。

いずれのプロバイダの場合も、Oracle WebLogic Communication Services は、双方向 SSL を使用して、クライアントから提示されたデジタル証明書を検証します。Client-Cert 認証を使用するためには、SIPS トランスポート (SSL) がコンフィグレーションされていることが必要です。セキュア伝送をまだコンフィグレーションしていない場合は、『ネットワーク リソースのコンフィグレーション』の「Oracle WebLogic Communication Services のネットワーク リソースの管理」を参照してください。

デフォルト ID アサーション プロバイダをコンフィグレーションするには、節 5.8.1.1「デフォルト ID アサーション プロバイダのコンフィグレーション」を参照してください。多くのプロダクション インストールでは、LDAP ストアが別個にあり、Client-Cert 認証を使用するように LDAP X1079724 ID アサーション プロバイダをコンフィグレーションする必要があります。詳細については節 5.8.1.2「LDAP X509 ID アサーション プロバイダのコンフィグレーション」を参照してください。

5.8.1.1 デフォルト ID アサーション プロバイダのコンフィグレーション

セキュリティ保護された SSL 接続を通じてクライアントから渡された X509 証明書を検証するように、デフォルト ID アサーション プロバイダをコンフィグレーションできます。デフォルト ID アサーション プロバイダには、デフォルト セキュリティ レルムでコンフィグレーションされたユーザに、対応するクライアントの「証明書」をマッピングするためのユーザ名マッパーが別個に必要です。Oracle WebLogic Communication Services に付属のデフォルト ユーザ名マッパーを使用することも、『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』に説明する方法でカスタム ユーザ名マッパー クラスを作成することもできます。

次の手順に従って、デフォルト ID アサーション プロバイダをコンフィグレーションします。

1. コンフィグレーションする Oracle WebLogic Communication Services ドメインの Administration Console にログインします。

2. コンソールの左ペインで、[セキュリティ レルム] ノードを選択します。

3. コンソールの右ペインで、セキュリティ レルム名を選択します。(たとえば、myrealm)

4. [プロバイダ｜認証] タブを選択します。

5. コンソールの右ペインで、コンフィグレーション済みプロバイダの表から [DefaultIdentityAsserter] を選択します。

6. [コンフィグレーション｜一般] ページでアクティブなタイプ テーブルの [選択可] カラムで X.509 を選択し、矢印をクリックして、[選択済み] カラムに移動します。

7. [保存] をクリックして変更を適用します。

8. カスタム Java クラスを使用して X509 証明書の名前と組み込みの LDAP ストアのユーザ名とをマッピングすることも、デフォルト ユーザ名マッパーを使用することもできます。ユーザ名のマッピングを実行するカスタム Java クラスを指定するには、次の手順に従います。

1. [コンフィグレーション｜Provider Specific] タブを選択します。

2. カスタム クラスの名前を [ユーザ名マッパーのクラス名] フィールドに入力します。

3. [保存] をクリックします。

デフォルト ユーザ名マッパーを使用するには、次の手順に従います。

1. [コンフィグレーション｜Provider Specific] タブを選択します。

2. [デフォルト ユーザ名マッパーを使用] を選択します。

3. [デフォルト ユーザ名マッパー属性タイプ] リストで、[CN （一般名）] または [E（電子メール アドレス）] のどちらかを、セキュリティ レルムに格納したユーザ名属性に応じて選択します。

4. [デフォルト ユーザ名マッパー属性の区切り文字] フィールドで、デフォルトの区切り文字である @ をそのまま使用します。この区切り文字は、[E（電子メール アドレス）] の属性で使用し、クライアント トークンから電子メール部分を抽出します。たとえば、「joe@mycompany.com」のトークンは、デフォルト セキュリティ レルムでコンフィグレーションされたユーザ名「joe」にマッピングされます。

5. [保存] をクリックします。

5.8.1.2 LDAP X509 ID アサーション プロバイダのコンフィグレーション

X509 認証プロバイダを作成およびコンフィグレーションするには、次の手順に従います。

1. コンフィグレーションする Oracle WebLogic Communication Services ドメインの Administration Console にログインします。

2. コンソールの左ペインで、[セキュリティ レルム] ノードを選択します。

3. コンソールの右ペインで、セキュリティ レルム名を選択します。(たとえば、myrealm)

4. [プロバイダ｜認証] タブを選択します。

5. [新規] をクリックします。

6. 新しいプロバイダ名を入力し、[LDAPX509IdentityAsserter] をタイプとして選択します。

7. [OK] をクリックします。

8. プロバイダのリストで、作成したプロバイダ名を選択します。

9. [コンフィグレーション｜Provider Specific] タブで、LDAP サーバ情報を各フィールドに以下のように入力します。

- [ユーザ フィルタの属性] : Oracle WebLogic Communication Services が、指定のユーザ名の検索で使用する LDAP 検索フィルタを入力します。このフィルタは、下記の [証明書のマッピング] 属性で定義されたベース DN の下の LDAP オブジェクトに適用されます。

- [ユーザ名の属性] : ユーザ名を保持する LDAP 属性を入力します。

- [証明書の属性] : ユーザ名に対応する証明書を保持する LDAP 属性を入力します。

- [証明書のマッピング] : ユーザの LDAP オブジェクトの検索に使用される LDAP ベース DN を構築するクエリ文字列を指定します。

- [ホスト] : 受け取った証明書を検証する LDAP サーバのホスト名を入力します。フェイルオーバ機能として複数の LDAP サーバを使用している場合は、各サーバに対応する hostname:port 値をスペース区切りで入力します。たとえば、「ldap1.mycompany.com:1050 ldap2.mycompany.com:1050」のように指定します。
フェイルオーバのコンフィグレーションの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』を参照してください。

- [Port] : LDAP サーバのポート番号を入力します。

- [SSL Enabled] : Oracle WebLogic Communication Services と LDAP サーバの間で、暗号化されていないパスワードを、SSL を使用して通信している場合は、このオプションをチェックします。

- [Principal] : Oracle WebLogic Communication Services が LDAP サーバへのアクセスに使用するプリンシパルの名前を入力します。

- [Credential] : 上記のプリンシパル名に対応する資格 (一般にはパスワード) を入力します。

- [Confirm Credential] : プリンシパルの資格を再入力します。

- [Cache Enabled] : 対応する LDAP サーバでキャッシュを使用するかどうかを指定します。

- [Cache Size] : LDAP サーバからの結果の格納に使用するキャッシュのサイズを KB 単位で指定します。デフォルトのキャッシュ サイズは 32KB です。

- [Cache TTL] : LDAP キャッシュ用の存続時間 (TTL) の値を秒単位で指定します。デフォルトの TTL 値は 60 秒です。

- [Follow Referrals] : LDAP X509 ID アサーション プロバイダのユーザまたはグループの検索で、他の LDAP サーバまたは LDAP ディレクトリ内のブランチの照会先に従う場合は、このボックスをチェックします。

- [Bind Anonymously On Referrals] : デフォルトでは、LDAP X509 ID アサーション プロバイダは、検索時に照会先に従う場合に、LDAP サーバへの接続に使用するものと同じ DN およびパスワードを使用します。匿名ユーザとして接続する場合は、このボックスをチェックします。

- [Results Time Limit] : LDAP の結果を待つ最大ミリ秒数を指定します。この時間を超えるとタイム アウトになります。タイム リミットを設定しない場合は、デフォルト値の 0 をそのまま使用します。

- [Connect Timeout] : LDAP 接続が確立されるのを待つ最大ミリ秒数を指定します。この時間を超えると、接続はタイム アウトになります。タイムアウト値を設定しない場合は、デフォルト値の 0 を使用します。

- [Parallel Connect Delay] : コンフィグレーション済みの複数の LDAP サーバに同時に接続を試みるときに遅延する秒数を指定します。この値を 0 に設定した場合、プロバイダは複数サーバに順次接続します。プロバイダはまず、[Host] リストの最初のコンフィグレーション済み LDAP サーバへの接続を試みます。この接続が失敗した場合、プロバイダは、次のコンフィグレーション済みサーバに接続を試みます。以下同様です。
0 以外の値を設定した場合、プロバイダは、指定した秒数だけ待機したうえで、別の接続を試みるための新しいスレッドを生成します。たとえば、この値を 2 に設定した場合、プロバイダはまず、[Host] リストの最初のコンフィグレーション済み LDAP サーバに接続を試みます。2 秒が経過した時点で接続がまだ確立されていない場合、プロバイダは、新しいスレッドを生成し、[Host] リストの 2 番目のコンフィグレーション済み LDAP サーバへの接続を試みます。以下同様に、コンフィグレーション済みの各 LDAP サーバに対する接続を試みます。

- [Connection Retry Limit] : 接続の確立時に LDAP サーバが例外を送出した場合に、プロバイダが LDAP サーバへの接続の再確立を試行する回数を指定します。

10. [保存] をクリックして変更内容を保存します。

11. 変更したセキュリティ コンフィグレーションを有効にするために、サーバを再起動します。

5.8.2 Oracle WebLogic Communication Services での WL-Proxy-Client-Cert のコンフィグレーション

Oracle WebLogic Communication Services が WL-Proxy-Client-Cert ヘッダを使用するためには、プロキシ サーバまたはロード バランサがクライアント リクエストに対応する X509 証明書をまず送信し、Base-64 エンコーディングを使用して暗号化したうえで、得られたトークンを SIP メッセージの WL-Proxy-Client-Cert ヘッダに追加する必要があります。システムがそのようにコンフィグレーションされている場合には、ローカルの Oracle WebLogic Communication Services インスタンス (または個々の SIP サーブレット インスタンス) で、WL-Proxy-Client-Cert ヘッダを調べて、クライアント トークンをチェックできます。

WL-Proxy-Client-Cert ヘッダを使用するようにサーバ インスタンスをコンフィグレーションするには、次の手順に従います。

1. コンフィグレーションする Oracle WebLogic Communication Services ドメインの Administration Console にログインします。

2. 左ペインで、[環境｜サーバ] ノードを選択します。

3. コンフィグレーションするエンジン層サーバ名を選択します。

4. 右ペインの [コンフィグレーション｜一般] タブを選択します。

5. [クライアント証明書プロキシを有効化] をチェックします。

6. [保存] をクリックして変更内容を保存します。

7. 節 5.8.1「Oracle WebLogic Communication Services での SSL と X509 のコンフィグレーション」の手順に従って、X509 証明書を処理するデフォルト ID アサーション プロバイダまたは LDAP ID アサーション プロバイダをコンフィグレーションします。

8. サーバを再起動して、変更したコンフィグレーションを有効にします。

個別の Web アプリケーションに対して WL-Proxy-Client-Cert ヘッダを有効にするには、アプリケーションの sip.xml デプロイメント記述子で com.bea.wcp.clientCertProxyEnabled コンテキスト パラメータを true に設定します。

5.8.3 カスタム ID アサーション プロバイダによる境界認証のサポート

境界認証では、WebLogic Server の外部にあるシステムがトークンを通じて信頼を確立します。通常このシステムでは認証エージェントを使用します。認証エージェントは、認証ユーザについての情報を後で確認するために提示が必要なアーティファクトまたはトークンを作成します。トークンの実際のフォーマットはベンダごとに異なります (たとえば SAML や SPNEGO など)。

Oracle WebLogic Communication Services では、1 つまたは複数のトークン フォーマットを認識するようにデザインされた ID アサーション プロバイダの使用による境界認証がサポートされています。SIP サーブレットの認証タイプが CLIENT-CERT に設定されている場合、Oracle WebLogic Communication Services の SIP コンテナは、リクエスト ヘッダからの値に対して ID アサーションを実行します。ヘッダの名前が、コンフィグレーションされたプロバイダのアクティブなトークンの種類に合致する場合、ID アサーション用のプロバイダに値が渡されます。

プロバイダは、ユーザ名マッパーを使用して、証明書をセキュリティ レルム内のユーザに解決します。クライアントのデジタル証明書のサブジェクトの識別名 (SubjectDN) 属性に対応するユーザが、サーバのセキュリティ レルムに定義されている必要があります。このユーザが定義されていない場合、WebLogic の保護リソースに対するクライアントからのアクセスは認められません。

境界認証用のクライアント証明書の受け渡しにカスタム トークンを使用するには、前述の LDAP X509 またはデフォルト ID アサーション プロバイダの代わりに、カスタムの ID アサーション プロバイダを作成およびコンフィグレーションする必要があります。境界認証で渡されたトークンを処理するプロバイダの作成の詳細については、WebLogic Server ドキュメントの『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』を参照してください。

5.9 SIP サーブレット ID アサーション メカニズムのコンフィグレーション

次のどちらかの ID アサーション メカニズムを使用するように SIP サーブレットをコンフィグレーションできます。

- P-Asserted-Identity : このメカニズムでは、信頼できるドメインから発信される SIP メッセージの P-Asserted-Identity ヘッダを使用して ID をアサートする必要があります。この ID アサーション メカニズムについては RFC 3325 で説明されています。

- Identity : このメカニズムでは、他のドメインから発生した SIP メッセージの Identity および Identity-Info ヘッダを使用して、ID をアサートする必要があります。この ID アサーションのメカニズムは RFC 4474 に記述されています。

選択した ID アサーション メカニズムは sip.xml デプロイメント記述子の identity-assertion 要素に定義されています。identity-assertion-support 要素は、サーブレットに対して ID アサーション メカニズムが必要かどうか、または、必要なヘッダが含まれていない SIP メッセージに対して別の認証メカニズムを使用できるかどうかを決定します。サーブレットの ID アサーションのコンフィグレーションについては、SIP サーブレット仕様 v1.1 を参照してください。

Oracle WebLogic Communication Services はセキュリティ プロバイダを使用して、ID アサーション メカニズムをサポートします。以下の節では、Oracle WebLogic Communication Services は各 ID アサーション メカニズムでメッセージを処理する方法および必要なセキュリティ プロバイダを設定する方法の詳細について説明します。

注意 :
Oracle WebLogic Communication Services のバージョンは SIP サーブレット v1.0 仕様に準拠しているアプリケーション用の下位互換性を提供します。

5.9.1 P-Asserted-Identity による信頼できるホストへの転送について

P-Asserted-Identity ヘッダは信頼できるドメイン内でのみ処理されます。Oracle WebLogic Communication Services システムでは、信頼できるドメインは純粋にコンフィグレーション ベースで判断されます。このヘッダの使用を有効にするには、節 5.9.3「P-Asserted-Identity アサーション プロバイダのコンフィグレーション」で説明するように、2 つのうちどちらか 1 つの P-Asserted Identity アサーション プロバイダをコンフィグレーションする必要があります。P-Asserted-Identity アサーション プロバイダは、P-Asserted-Identity ヘッダの信頼できるドメインのコンフィグレーションを公開します。プロバイダが 1 つもコンフィグレーションされていない場合、ヘッダでは、信頼できる IP アドレスがないものとして扱われます。

プロバイダでコンフィグレーションされている信頼できるホストから、P-Asserted-Identity ヘッダが含まれるメッセージを受け取ると、Oracle WebLogic Communication Services はヘッダで指定されたユーザのログインを許可し、グループ メンバシップやその他の権限を判断します。P-Asserted-Identity ヘッダに含まれる値は、常に SIP アドレス (sipuser@oracle.com など) です。デフォルトでは、Oracle WebLogic Communication Services はアドレスのドメイン部分 (@oracle.com) が削除され、残りの部分がユーザ名として使用されます。重複するユーザ名 (sipuser@oracle.com と sipuser@cea.com など) を個別のものとして扱う必要がある場合、カスタム ユーザ名マッパーを作成および使用し、ヘッダの情報を処理して一意のユーザ名 (sipsuser_b と sipuser_c) を生成することができます。カスタム ユーザ名マッパーを使用すると、@ 文字を含む WebLogic ユーザ名 (@oracle.com など) をサポートすることもできます。

Privacy ヘッダと組み合わせた P-Asserted-Identity ヘッダを使用すると、Oracle WebLogic Communication Services が受信するリクエストをどのようにプロキシするかを判断できます。sip.xml の identity-assertion-support 要素の値も参考にされます。図 5-3 は、P-Asserted-Identity ヘッダに対する着信 SIP リクエストの管理方法について説明します。

図 5-3 P-Asserted-Identity ヘッダと Privacy ヘッダのある着信リクエストの管理

「P-Asserted-Identity ヘッダと Privacy ヘッダのある着信リクエストの管理」の説明

図 5-4 に、指定されたユーザ名に権限がないため必要なリソースにアクセスできない場合の、セキュリティ チェックの標準的手順を示します。この標準的セキュリティ チェックは、当該アプリケーションの sip.xml 記述子の login-config 要素に定義されている auth-method に従って実行されます。

図 5-4 セキュリティ チェックの標準的手順

「セキュリティ チェックの標準的手順」の説明

P-Asserted-Identity ヘッダまたは P-Preferred-Identity ヘッダを使用すると、発信 SIP リクエストの処理にも影響します。図 5-5 は、行動を説明します。

図 5-5 P-Asserted-Identity ヘッダまたは P-Preferred Identity ヘッダのある発信リクエストの管理

「P-Asserted-Identity ヘッダまたは P-Preferred Identity ヘッダのある発信リクエストの管理」の説明

5.9.2 厳密および非厳密な P-Asserted-Identity アサーション プロバイダの概要

P-Asserted-Identity ヘッダの内容が無効の場合、または信頼できないホストからヘッダを受け取った場合は、セキュリティ プロバイダが SIP サーブレット コンテナに「匿名」ユーザを返します。PAsserted Identity Strict Asserter プロバイダをコンフィグレーションした場合は、例外も送出されるので、匿名ユーザの代用を監査することができます(基本 PAsserted Identity Asserter プロバイダをコンフィグレーションした場合は、例外が送出されません)。

どちらのプロバイダでも、ID のアサーションが失敗して要求されたリソースが保護されている場合 (リクエストが sip.xml の security-constraint と一致する場合)、SIP コンテナは sip.xml デプロイメント記述子に定義されている auth-method を使用してエンド ユーザを認証します。たとえば、サーブレットでダイジェスト認証方式が指定されている場合はダイジェスト認証が使われます。

要求されたリソースが保護されていない場合は、匿名ユーザが認可なしでそのまま SIP サーブレットに渡されます。3GPP TS 24.229 仕様では、リソースが制限されていない (そして機密保護が必要とされていない) 場合でも権限を付与することが推奨されています。これに準拠するため、宣言によるセキュリティを使用して SIP サーブレットのすべてのリソースを保護してください。

匿名ユーザに権限が付与されなかった場合は、チャレンジによるユーザの認証が行われます。

5.9.3 P-Asserted-Identity アサーション プロバイダのコンフィグレーション

P-Asserted-Identity ヘッダをサポートするためのセキュリティ プロバイダをコンフィグレーションするには、次の手順に従います。節 5.9.2「厳密および非厳密な P-Asserted-Identity アサーション プロバイダの概要」で説明したように、2 つのうちどちらか 1 つのプロバイダを選択できます。

上記のプロバイダのどちらか 1 つのコンフィグレーションに加えて、第二のフォールバック的なログイン方法 (DIGEST 認証または CLIENT-CERT 認証の使用など) もコンフィグレーションしてください。

P-Asserted-Identity プロバイダをコンフィグレーションするには、次の手順に従います。

1. コンフィグレーションする Oracle WebLogic Communication Services ドメインの Administration Console にログインします。

2. コンソールの左ペインで、[セキュリティ レルム] ノードを選択します。

3. コンソールの右ペインで、セキュリティ レルム名を選択します。(たとえば、myrealm)

4. [新規] をクリックします。

5. 新しいプロバイダ名を入力し、[Type] フィールドに以下のどちらかのオプションを選択します。

- [PAssertedIdentityAsserter] : P-Asserted-Identity ヘッダが無効の場合、または信頼できないホストからヘッダを受け取り、匿名ユーザが代用された場合に例外を送出しないプロバイダをコンフィグレーションします。

- [PAssertedIdentityStrictAsserter] : P-Asserted-Identity ヘッダが無効の場合、または信頼できないホストからヘッダを受け取り、匿名ユーザが代用された場合に例外を送出するプロバイダをコンフィグレーションします。

詳細については、節 5.9.2「厳密および非厳密な P-Asserted-Identity アサーション プロバイダの概要」を参照してください。

6. [OK] をクリックします。

7. 作成したプロバイダ名を選択します。

8. [コンフィグレーション｜Provider Specific] タブを選択します。

9. [コンフィグレーション] タブの各フィールドに以下の情報を入力します。

- [Trusted Hosts]: プロバイダが信頼できるホストとして扱う 1 つまたは複数のホスト名を入力します。IP アドレスと DNS 名のどちらでも入力できます。また、ワイルドカードを使用することもできます。

注意 :
このプロバイダは、sipserver.xml ファイルに信頼できるホストとしてコンフィグレーションされているホストは使用しません。

- [User Name Mapper Class Name] : P-Asserted-Identity ヘッダのユーザ名をデフォルトのセキュリティ レルムのユーザ名にマップするためのカスタム Java クラスの名前を入力します。カスタム ユーザ名マッパーは、通常、ユーザ名が複数のドメインから送られてきた場合に使用されます。この場合、ここのドメインから受け取ったユーザ名をマップするために追加のロジックが必要とされることもあります。P-Asserted-Identity ヘッダのユーザ名を WebLogic ユーザ名にマップするには、カスタム ユーザ名マッパー クラスが必要です。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』を参照してください。
このフィールドを空白のままにすると、デフォルトのユーザ名マッパーが使われます。デフォルトのユーザ名マッパーでは、ドメイン名を破棄し、残ったユーザ名をそのまま (何のロジックも適用せずに) 使用します。

10. [保存] をクリックします。

5.9.4 Identity ヘッダと Identity-Info ヘッダによる ID アサーションについて

Oracle WebLogic Communication Services は、RFC 4474 に記述されているようにIdentity および Identity-Info ヘッダを使用して、ID アサーションを実行することもできます。p-asserted-identity アサーション メカニズムと同様に、Identity ヘッダ アサーションには、Oracle WebLogic Communication Services の適当なセキュリティ プロバイダ (IdentityHeaderAsserter プロバイダ) を最初にコンフィグレーションする必要があります。

Identity ヘッダおよび Identity-Info ヘッダのある着信リクエストを確認すると、Oracle WebLogic Communication Services は sip.xml の identity-assertion と identity-assertion-support 要素の値およびコンフィグレーション済みのセキュリティ プロバイダの存在を検討します。図 5-6 では、このアサーション メカニズムを使用して着信メッセージを処理する方法について説明します。

図 5-6 Identity ヘッダおよび Identity-Info ヘッダのある着信リクエストの管理

「Identity ヘッダおよび Identity-Info ヘッダのある着信リクエストの管理」の説明

5.9.5 Identity ヘッダ アサーション プロバイダのコンフィグレーション

Identity ヘッダをサポートするためのセキュリティ プロバイダをコンフィグレーションするには、次の手順に従います。

1. コンフィグレーションする Oracle WebLogic Communication Services ドメインの Administration Console にログインします。

2. コンソールの左ペインで、[セキュリティ レルム] ノードを選択します。

3. コンソールの右ペインで、セキュリティ レルム名を選択します。(たとえば、myrealm)

4. 右ペインで [プロバイダ｜認証] タブをクリックします。

5. [新規] をクリックします。

6. 新しいプロバイダ名を入力し、タイプには [IdentityHeaderAsserter] を選択します。

7. [OK] をクリックします。

8. 作成したプロバイダ名を選択します。

9. [プロバイダ固有] タブを選択します。

10. [コンフィグレーション] タブの各フィールドに以下の情報を入力します。

- [Date Period] : Date ヘッダのため有効な期間 (秒単位) を入力します。

- [Https Channel Name] : プロバイダは HTTP クライアントの初期化に使用する HTTP チャネルの名前を入力します。HTTPS を通してリモート証明書を取得される場合、(個別にコンフィグレーションされている) HTTPS チャネルが必要です。

- [User Name Mapper Class Name] (省略可能) : Identity ヘッダのユーザ名をデフォルトのセキュリティ レルムのユーザ名にマップするためのカスタム Java クラスの名前を入力します。Identity ヘッダのユーザ名を WebLogic ユーザ名にマップするには、カスタム ユーザ名マッパー クラスが必要です。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』を参照してください。

11. [保存] をクリックします。

5.10 3GPP HTTP ID アサーション プロバイダのコンフィグレーション

Oracle WebLogic Communication Services は、IMS ネットワーク内でアプリケーション サーバとして機能するように、「3GPP TS Generic Authentication Architecture (GAA); Access to network application functions using Hypertext Transfer Protocol over Transport Layer Security (HTTPS) (http://www.3gpp.org/ftp/Specs/html-info/33222.htm)」の仕様に従って XGPP-Asserted-Identity ヘッダの処理をサポートしています。このサポートは、X3gppAssertedIdentityAsserter または X3gppAssertedIdentityStrictAsserter というコンフィグレーション済みのセキュリティ プロバイダを通じて提供されます。どちらのプロバイダも使用する認証プロセスは同じですが、厳密 (Strict) なアサーション プロバイダの方は、信頼できないホストからヘッダを受け取ると例外を送出します (これにより、信頼できないホストからアサートされた ID リクエストの監査が可能になります)。

X-3GPP-Asserted-Identity ヘッダの HTTP リクエストに対する機能は、P-Asserted-Identity ヘッダの SIP に対する機能と同様です。コンテナは X-3GPP-Asserted-Identity ヘッダ付きの HTTP リクエストを受け取ると、まず、そのリクエストが信頼性できるホストから送信されたものかどうかを確認します。そのホストが信頼できる場合、コンテナはヘッダ内の情報を使用してユーザの ID をアサートして認証し、さらに、要求されているリソースへのアクセス権がそのユーザに与えられている場合はログインを許可します (リクエストが信頼できないホストから送信されたものである場合、コンテナは単にヘッダを無視します)。

X-3GPP-Asserted-Identity ヘッダには、複数の名前のリスト (user1@oracle.com、user2@oracle.com など) が含まれていることもあります。デフォルト ユーザ名マッパー クラスでコンフィグレーションされている場合、Oracle WebLogic Communication Services はアドレスのドメイン部 (@oracle.com) を取り除き、残りをユーザ名として使用します。デフォルト ユーザ名マッパーは常に、リスト内の最初のユーザ名を選択し、それを ID のアサーションに使用します。この動作は、カスタム ユーザ名マッパー クラスを作成およびコンフィグレーションすることにより、変更することができます。たとえば、重複するユーザ名 (sipuser@oracle.com と sipuser@oracle.com など) を個別のものとして扱う必要がある場合、カスタム ユーザ名マッパーを使用してヘッダの情報を処理し、一意のユーザ名 (sipsuser_b と sipuser_c) を生成することができます。カスタム ユーザ名マッパーを使用すると、@ 文字を含む WebLogic ユーザ名 (@oracle.com など) をサポートすることもできます。

SIP サーブレットで X-3GPP-Asserted-Identity ヘッダによる認証をサポートするには、web.xml デプロイメント記述子の auth-method 要素を CLIENT-CERT に設定する必要があります。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』を参照してください。

5.10.1 X-3GPP-Asserted-Identity プロバイダのコンフィグレーション

HTTP リクエストの X-3GPP-Asserted-Identity ヘッダをサポートするためのセキュリティ プロバイダをコンフィグレーションするには、以下の手順に従います。節 5.10「3GPP HTTP ID アサーション プロバイダのコンフィグレーション」でも触れたように、2 つのプロバイダのうち、どちらか 1 つを選択することができます。

1. コンフィグレーションする Oracle WebLogic Communication Services ドメインの Administration Console にログインします。

2. コンソールの左ペインで、[セキュリティ レルム] ノードを選択します。

3. コンソールの右ペインで、セキュリティ レルム名を選択します。(たとえば、myrealm)

4. [プロバイダ｜認証] タブを選択します。

5. [新規] をクリックします。

6. 新しいプロバイダ名を入力し、[Type] フィールドに以下のどちらかのオプションを選択します。

- [X3gppAssertedIdentityAsserter] : ヘッダが無効の場合 (または信頼できないホストから送信されたものである場合) に例外を送出しないプロバイダをコンフィグレーションします。

- [X3gppAssertedIdentityStrictAsserter] : ヘッダが信頼できないホストから送信されたものである場合 (このヘッダは無視されます) に例外を送出するプロバイダをコンフィグレーションします。

詳細については、節 5.10「3GPP HTTP ID アサーション プロバイダのコンフィグレーション」を参照してください。

7. [OK] をクリックします。

8. 作成した新しいプロバイダ名を選択します。

9. [アクティブなタイプの選択] リストで [X-3GPP-Asserted-Identity] を選択し、矢印をクリックして、このタイプを [選択済み] カラムに移動します。

10. [保存] をクリックします。

11. [コンフィグレーション｜Provider Specific] タブを選択します。

12. コンフィグレーション ページの各フィールドに以下の情報を入力します。

- [Trusted Hosts] : プロバイダが信頼できるホストとして扱う 1 つまたは複数のホスト名を入力します。このプロバイダは、sipserver.xml ファイルに信頼できるホストとしてコンフィグレーションされているホストは使用しません (『コンフィグレーション リファレンス マニュアル』の「sip-security」を参照してください)。IP アドレスと DNS 名のどちらでも入力できます。また、ワイルドカードを使用することもできます。

- [User Name Mapper Class Name] : X-3GPP-Asserted-Identity ヘッダのユーザ名をデフォルトのセキュリティ レルムのユーザ名にマップするために使用するカスタム Java クラス名を入力します。カスタム ユーザ名マッパーは、通常、ユーザ名が複数のドメインから送られてきた場合に使用されます。この場合、受け取ったユーザ名をマップするために、ドメインごとに別のロジックが必要とされることもあります。ユーザ名を WebLogic ユーザ名にマップする場合、または X-3GPP-Asserted-Identity ヘッダに指定されているユーザ名のうち最初のユーザ名だけを使用するのではなく、複数のユーザ名を論理的に処理する場合は、カスタム ユーザ名マッパー クラスが必要です。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』を参照してください。
このフィールドを空白のままにすると、デフォルトのユーザ名マッパーが使われます。デフォルトのユーザ名マッパーでは、ドメイン名を取り除き、残った最初のユーザ名を ID のアサーションに使用します。たとえば、デフォルトのユーザ名マッパーは以下のヘッダ

X-3GPP-Asserted-Identity: "user1@oracle.com", "user2@oracle.com"

を処理し、ID "user1" をアサートします。

13. [保存] をクリックします。

5.11 HTTP サーブレットの基本認証のコンフィグレーション

SIP サーブレットでは基本認証の使用が非推奨となりましたが、HTTP サーブレットではこの認証メカニズムを使用することができます。基本認証は LDAPAuthenticator プロバイダを通じてサポートされます。Oracle Internet Directory でプロバイダをコンフィグレーションするには、以下の手順に従います。

1. コンフィグレーションする Oracle WebLogic Communication Services ドメインの Administration Console にログインします。

2. コンソールの左ペインで、[セキュリティ レルム] ノードを選択します。

3. コンソールの右ペインで、セキュリティ レルム名を選択します。(たとえば、myrealm)

4. [プロバイダ｜認証] タブを選択します。

5. [新規] をクリックします。

6. 新しいプロバイダ名を入力し、タイプ フィールドで [LDAPAuthenticator] を選択します。

7. [OK] をクリックします。

8. 作成した新しいプロバイダ名を選択します。

9. [コンフィグレーション｜Provider Specific] タブを選択します。

10. コンフィグレーション ページの各フィールドに以下の情報を入力します。

- [Principal] : Oracle Internet Directory で Oracle WebLogic Communication Services 用にコンフィグレーションされたアプリケーション インスタンスを入力します (たとえば、orclApplicationCommonName=WLSSInstance1,cn=WLSS,cn=Products,cn=OracleContext,dc=example,dc=com)。このインスタンスは、Oracle Internet Directory をインストールした後に手動でプロビジョニングする必要があります。手順の詳細については、節 5.12「Oracle Internet Directory でのリソースのプロビジョニング」を参照してください。

- [Credential] : Oracle Internet Directory でコンフィグレーションされた [Principal] のパスワードを入力します。

- [Group Base DN] : Oracle Internet Directory のグループ オブジェクトの DN を入力します (たとえば、cn=groups,dc=example,dc=com)。

- [User Base DN] : Oracle Internet Directory のユーザ オブジェクトの DN を入力します (たとえば、cn=Users,dc=example,dc=com)。

11. [保存] をクリックします。

5.12 Oracle Internet Directory でのリソースのプロビジョニング

以下の節では、Oracle Internet Directory を LPAD プロバイダとして使用するときに、Oracle WebLogic Communication Services のリソースをプロビジョニングする方法の概要について説明します。これらの手順は、ダイジェスト認証で計算済みのハッシュ値を使用する場合、または HTTP サーブレット用の基本認証をコンフィグレーションする場合に必須です。

これらの手順の詳細については、Oracle Internet Directory の『Oracle Fusion Middleware Administrator's Guide』を参照してください。

5.12.1 Oracle Internet Directory のコンフィグレーション

OID LDAP バックエンドの次のマッピングをコンフィグレーションする必要があります。

- [JAAS Usernames to LDAP User Entries] -- Java Authentication and Authorization Service (JAAS) ユーザ名は、ノード cn=Common,cn=Products,cn=OracleContext の下の orclcommonnicknameattribute の値を基にして、LDAP ユーザにマッピングされます。たとえば、この属性を uid に設定すると、OID に対して認証を実行するユーザは、認証時に対応する LDAP uid をユーザ名として提供する必要があることを示します。この章で説明している残りのコンフィグレーションでは、orclcommonnicknameattribute が uid (デフォルト値) に設定されていることを前提としています。

- [JAAS Realms to LDAP Subscribers] -- JAAS レルムは、OID デプロイメント用の cn=Common,cn=Products,cn=OracleContext ノードのルートの下の orclsubscribernicknameattribute に提供された値を基にして、LDAP レルム エントリにマッピングされます。たとえば、OID デプロイメント用の orclsubscribernicknameattribute の値を o (アルファベットの「o」) に設定すると、OID に対して認証を実行するユーザは o 属性の値によって識別された JAAS レルムに属している必要があることを示します。orclsubscribernicknameattribute の値を o に設定します。

- [JAAS Roles to LDAP Groups] -- グループ メンバシップによって特定のユーザの JAAS ロールが決定されます。LDAP グループから JAAS ロールへのマッピングは、プロビジョニングされた各 LDAP レルムのノード cn=Common,cn=Products,cn=OracleContext の下の orclcommonnamingattribute に提供された値に基づいています。たとえば、ユーザが属する LDAP グループの識別名が cn=Location Service, cn=groups, dc=example, dc=com であり、orclcommonnamingattribute が cn に設定されている場合、その JAAS ユーザは「Location Service」JAAS ロールに設定されます。orclcommonnamingattribute の値を cn に設定します。

5.12.2 静的検証機能のコンフィグレーション

上の手順で Oracle Internet Directory をコンフィグレーションした後は、Oracle WebLogic Communication Services (OWLCS) 用の新製品エントリの作成、静的検証機能のインストール、OWLCS の各インスタンス用のエントリの作成、および新しく作成された各インスタンスへの検証権限の付与を実行する必要があります。これらの手順は OID でユーザをプロビジョニングする前に実行する必要があります。すでに OID にユーザが存在する場合は、静的検証機能を作成およびコンフィグレーションした後で、これらのユーザが正しくログインできるようにパスワードをリセットする必要があります。

5.12.2.1 Oracle WebLogic Communication Services の追加

Oracle Internet Directory に Oracle WebLogic Communication Services 製品を追加するには、以下の手順に従います。

1. $ORACLE_HOME/bin/ で oidadmin ツールを起動し、インストールされた Oracle Internet Directory サーバに接続します。Oracle Internet Directory のインストール中に選択した「orcladmin」アカウントとパスワードを使用してログインします。

2. [Entry Management] ツリーで、
cn=Products,cn=OracleContext,dc=example,dc=com を検索します。正確なドメイン部分 (dc=example,dc=com) は、Oracle Internet Directory のインストールで作成したドメインに依存します。

3. OWLCS の新しいエントリを作成する便利な方法は、既存の製品エントリをクローンすることです。[Products] の下の最初のエントリを選択します (通常は [Calendar] エントリ)。次に、[Calendar] エントリを右クリックして [Create Like] を選択します。結果のダイアログで、以下の手順に従います。
dn の [Calendar] エントリを WLCS と置き換えます。

cn に WLCS と入力します。

4. [OK] をクリックします。

5. [Products] エントリを右クリックし、[Refresh SubTree Entries] を選択します。[Products] の下に新しい製品名 WLCS が表示されていることを確認してください。

5.12.2.2 静的検証機能のインストール

静的検証機能をインストールするには、ldapadd コマンドライン ツールを使用します。以下の手順を実行します。

1. 環境変数 ORACLE_HOME を、OID がインストールされた ORACLE_HOME を指すように設定します。

2. 以下の行を含む ldif ファイルを作成します (ここでも、ドメインの部分をユーザのドメインと置き換えます)。
dn: cn=WLCSVerifierProfileEntry,cn=WLCS,cn=Products,cn=OracleContext,dc=example,dc=com

objectclass:top

objectclass:orclpwdverifierprofile

cn:WLCSVerifierProfileEntry

orclappid:wlcs

orclpwdverifierparams;authpassword: crypto:SASL/MD5 $ realm:example.com $ usernameattribute:uid

3. cd $ORACLE_HOME

4. 次のコマンドを実行します。/bin/ldapadd -D cn=orcladmin -w <password of orcladmin user> -f <yourfile>.ldif

5. oidadmin で、WLCS 製品エントリを右クリックし、[Refresh SubTree Entries] を選択して、WLCS 製品エントリを更新します。WLCSVerifierProfileEntry が表示されます。

5.12.3 新しい Oracle WebLogic Communication Services の追加

新しい Oracle WebLogic Communication Services インスタンスを追加するには、以下の手順に従います。

1. 作成した WLCS 製品エントリを右クリックし、[作成] を選択します。

2. [Distinguished Name (dn)] フィールドで、以下のように入力します。

orclApplicationCommonName=WLCSInstance1,cn=WLCS,cn=Products,cn=OracleContext,dc=example,dc=com" (ドメインの部分をユーザのドメインと置き換えます)

3. [Object Classes] で、[Add] をクリックします。

4. [orclApplicationEntity] を選択します。[Select] をクリックします。

5. [Optional Properties] をクリックし、以下の属性の値を設定します。
userpassword (authpassword ではない) - 任意のパスワードを入力します

orclappfullname - 「Oracle Weblogic Communication Services」と入力します

description - 「Oracle Weblogic Communication Services インスタンスのエントリ」と入力します

6. [OK] をクリックします。

7. エントリを右クリックし、[Refresh SubTree Entries] を選択して、WLCS 製品エントリを更新します。作成した新しいエントリが表示されていることを確認してください。

5.12.4 Oracle WebLogic Communication Services インスタンスへの検証権限の付与

Oracle WebLogic Communication Services インスタンスに検証権限を付与するには、以下の手順に従います。

1. cn=verifierServices,cn=Groups,cn=OracleContext,dc=example,dc=com エントリに移動します (ドメインの部分をユーザのドメインと置き換えます)。

2. [cn=verifierServices] をクリックします。

3. 右ペインで、uniquemember 属性まで下にスクロールします。属性の値に 1 つまたは 2 つのエントリがある場合があります。uniquemember 属性の既存の値に「orclApplicationCommonName=WLCSInstance1,cn=WLCS,cn=Products,cn=OracleContext,dc=example,dc=com」を追加します (ドメインの部分をユーザのドメインと置き換えます)。

4. [適用] をクリックします。

5. 上の 2 つの手順を各 OWLCS インスタンスで繰り返します。
OID と通信する必要がある OWLCS の各インスタンスで、上の 2 つの手順を繰り返す必要があります (新しい OWLCS インスタンスの追加とインスタンスへの検証権限の付与)。

5.13 ユーザのプロビジョニング

ユーザをプロビジョニングするには、以下の手順に従って、ユーザの作成、ユーザの必須属性の設定、グループの作成、および新しいユーザのグループ メンバーとしての割り当てを行う必要があります。

5.13.1 新しいユーザの作成

oiddas を通じてユーザを管理するには、OID のマニュアルを参照してください。

また、テスト ユーザをすばやく作成する必要がある場合は、oidadmin を使用して、次のように orcladmin ユーザをクローンできます。# cn=Users,dc=example,dc=com に移動します (ドメインの部分をユーザのドメインと置き換えます)。

1. [cn=orcladmin] を右クリックし、[Create Like] を選択します。

2. 結果のダイアログで、以下の手順に従います。
識別名の属性値の orcladmin を 「test.user1」に変更します。

cn に test.user1 と入力します

sn に test.user1 と入力します

3. [Optional Properties] タブをクリックします。
givenName に test.user1 と入力します

mail に test.user1@example.com と入力します (この電子メール アドレスはユーザの SIP アドレスとなるため、username@your-domain の形式で入力してください)

description を「OWLCS のテスト ユーザ」に変更します

orclSAMAccountName を test.user1 に変更します

uid に test.user1 と入力します

このテスト ユーザの任意のパスワードを入力します

orclIsVisible プロパティに true と入力します (重要)

4. [OK] をクリックします。

5.13.2 グループの作成

ProxyRegistrar を実行するには、すべてのユーザが「Location Service」グループのメンバである必要があります。そのグループを作成するには、以下の手順に従います。

OIDDAS Web インタフェースを通してグループを追加およびグループへメンバを追加するのが最も簡単な方法です。グループを作成する方法については、OID のドキュメントを参照してください。また、oidadmin ツールを使用して、既存のグループのクローンによって新しいグループを作成できます。以下の手順に従います。

1. [Entry Management] ツリーで、cn=Groups,dc=example,dc=com を検索します (ドメインの部分をユーザのドメインと置き換えます)

2. 既存のグループ (「OCS_Portal_Users」など) を右クリックし、[Create Like] を選択します。

3. 識別名 (dn) を cn=Location Service,cn=Groups,dc=example,dc=com に設定します (OCS_Portal_Users を Location Service に変更します)

4. cn に Location Service と入力します。

5. [Optional Properties] をクリックします。

6. description に「OWLCS の Location Service ロール」と入力します。

7. displayName に Location Service と入力します。

8. [OK] をクリックします。

9. [cn=Groups] をクリックし、[Refresh SubTree Entries] を選択します。新しいグループが表示されていることを確認してください。

5.13.3 ユーザへのグループ メンバシップの割り当て

前に述べたとおり、ProxyRegistrar を実行するには、すべての OWLCS ユーザが上で作成した「Location Service」グループのメンバである必要があります。新しい Location Service グループにユーザを追加するには、以下の手順に従います。

1. 作成した新しい Location Service をクリックします。新しいグループは、[Entry Management] ツリーの cn=Location Service,cn=Groups,dc=example,dc=com にあります (ドメインの部分をユーザのドメインと置き換えます)

2. 右ペインで、uniquemember 属性まで下にスクロールして、任意の既存のエントリに cn=test.user1,cn=Users,dc=example,dc=com を追加します (ドメインの部分をユーザのドメインと置き換えます)。

3. [適用] をクリックします。

5.13.4 ユーザの JAAS レルムの設定

次に、ユーザの JAAS レルムを設定する必要があります。

1. [Entry Management] の dc=example,dc=com に移動します (ドメインをユーザのドメインと置き換えます)

2. [dc=example] エントリをクリックします。

3. [Advanced] ラジオ ボタンをクリックします。

4. [Attribute] ドロップ ダウンで、o を選択します。

5. [Apply] ボタンをクリックします。

6. o 属性の値に example.com と入力します (ユーザのレルムと置き換えます)。

7. [適用] をクリックします。

5.14 OWLCS サーバ インスタンスのコンフィグレーション

OID のサポートで LDAPIdentityAssertionProvider を追加します。

1. WLS 管理コンソールで、ユーザのセキュリティ レルムに移動して [プロバイダ] タブをクリックします。

2. DigestIdentityAsserter がプロバイダのリストにある場合は、これを削除して OWLCS サーバを再起動します (これは用意されている OWLCS のインストールで、デフォルトで作成されます)。

3. サーバを再起動したら、WLS 管理コンソールで [プロバイダ] タブをクリックします。

4. [新規] ボタンをクリックし、[種類] ドロップ ダウンから [LDAPDigestAssertionProvider] を選択して、新しい LDAP ダイジェスト ID アサーション プロバイダを追加します。名前に LDAPDigestAssertionProvider と入力します。[OK] をクリックします。

5. [プロバイダ固有] タブをクリックします。

6. [UserBaseDN] を「cn=Users,dc=example,dc=com」に設定します (ドメインの部分をユーザのドメインと置き換えます)。

7. [CredentialAttributeName] を [authpassword;wlcs] に設定します。

8. [PaswordEncryptionType] を [PRECALCULATEDHASH] に設定します。

9. [DigestRealmName] を「example.com」に設定します (これは、静的検証機能をインストールするときに使用した ldif ファイル内のレルム値と一致します)。

10. [Host] と [Port] を OID サーバと同じように設定します。

11. [Principal] を「orclApplicationCommonName=WLCSInstance1,cn=WLCS,cn=Products,cn=OracleContext,dc=example,dc=com」に設定します (ドメインの部分をユーザのドメインと置き換えます)。

12. [Credential] を上でコンフィグレーションしたインスタンスの userPassword に設定します。認証を確認します。

13. [OIDSupportEnabled] チェックボックスにチェックを入れ、[保存] をクリックします。

14. 手順 1 で説明されている [プロバイダ] タブに戻ります。DefaultAuthenticator エントリがある場合はこれをクリックし、[制御フラグ] を [SUFFICIENT] に設定して [保存] をクリックします。

5.14.1 LDAP 認証の追加 (ロールの設定)

LDAPAuthenticator を追加するには、以下の手順に従います。

1. WLS 管理コンソールで、ユーザのセキュリティ レルムに移動し、[プロバイダ] タブで新しい LDAPAuthenticator を追加します。

2. [共通] タブで、[制御フラグ] を [SUFFICIENT] に変更します。

3. [プロバイダ固有] タブをクリックします。

4. OID サーバのホストとポートを設定します。

5. [プリンシパル] を「orclApplicationCommonName=WLCSInstance1,cn=WLCS,cn=Products,cn=OracleContext,dc=example,dc=com」に設定します (ドメインの部分をユーザのドメインと置き換えます)。

6. [資格] を前の手順と同じようにコンフィグレーションし、[資格の確認] を設定します。

7. [ユーザ ベース DN] を「cn=Users,dc=example,dc=com」に設定します (ドメインの部分をユーザのドメインと置き換えます)。

8. [取得したユーザ名をプリンシパルとして使用する] を有効にします。

9. [グループ ベース DN] を「cn=Groups,example,dc=com」に設定します (ドメインの部分をユーザのドメインと置き換えます)。

10. [保存] をクリックします。

5.14.2 LDAP 認証のパフォーマンスの向上

LDAP 認証のパフォーマンスを向上させることができます。

- ユーザがフラット構造の場合 (通常はこのケース)、[User Search Scope] を [onelevel] に設定します。

- ロールのグループのフラット構造の場合 (こちらも通常のケース)、つまり、グループ内にグループがない場合、[Group Search Scope] を [onelevel] に設定し、[Group Membership Searching] を [limited] に設定します。

変更を保存してください。

5.14.3 OID で使用する Userservice のコンフィグレーション

OID で使用する Userservice をコンフィグレーションする必要があります。

1. subscriberdataservices ear ファイル ($MW_HOME/as11gr1wlcs1/communications/applications にある subscriberdataservices-11.1.1.1.0.ear) にパッケージされた ejb-jar.xml を、jdbc の代わりに LDAP を使用するようコンフィグレーションする必要があります。

2. userservice jar 内のファイルに続けて、subscriberdataservices ear 内のファイルを展開します。

3. META-INF の下の ejb-jar.xml で、UserServiceDSN と UserDAOImpl グループをコメント アウトします。LDAP セクションのコメントを解除し、適切な値でコンフィグレーションします。
java.naming.security.principal を orclApplicationCommonName=WLCSInstance1,cn=WLCS,cn=Products,cn=OracleContext,dc=example,dc=com に設定します (ドメインの部分をユーザのドメインと置き換えます)

前に定義したパスワードを設定します。プレーン テキスト パスワードの先頭に「!」を追加します。たとえば、パスワードを myPassword に設定する場合、<env-entry-value><![CDATA[!myPassword]]></env-entry-value> とコンフィグレーションします。

プロバイダ LDAP URL を設定します。デフォルトのポートは 389 です (非 SSL 接続)。

4. 上の変更を加えた ejb-jar.xml ファイルを保存し、ear ファイルの後に jar ファイルを再パッケージします。$MW_HOME/as11gr1wlcs1/communications/applications の下の既存の subscriberdataservices ear ファイルを、変更したファイルと置き換えます。

5. OWLCS を再起動します。これで Oracle Communicator を使用して OWLCS に test.user1 としてサインインできます。

6 SIP データ層のパーティションとレプリカのコンフィグレーション

以下の節では、デプロイメントの SIP データ層クラスタを構成する Oracle WebLogic Communication Services インスタンスをコンフィグレーションする方法について説明します。

- 節 6.1「SIP データ層のコンフィグレーションの概要」

- 節 6.2「SIP データ層サーバのコンフィグレーションと管理のベスト プラクティス」

- 節 6.3「SIP データ層のコンフィグレーションとコンフィグレーション ファイルの例」

- 節 6.4「長期間維持する呼状態データの RDBMS への格納」

- 節 6.5「地理的な冗長性の導入」

- 節 6.6「地理的に冗長な SIP データ層の使用」

- 節 6.7「エンジン層での SIP データのキャッシング」

- 節 6.8「SIP データ層サーバのモニタとトラブルシューティング」

6.1 SIP データ層のコンフィグレーションの概要

Oracle WebLogic Communication Services SIP データ層は、同時 SIP 呼のアプリケーション呼状態を管理するサーバ インスタンスのクラスタです。SIP データ層では、呼状態の単一のコピーを処理することも、サーバ マシンで障害が発生したりネットワーク接続が中断された場合でも呼状態データが失われないように、必要に応じて複数のコピーを処理することもできます。

SIP データ層クラスタは、1 つまたは複数の「パーティション」として構成します。1 つのパーティションは、同時呼状態データの同じ部分を管理する、1 つまたは複数の SIP データ層サーバ インスタンスで構成されます。単一のサーバ Oracle WebLogic Communication Services インストールや、エンジン層と SIP データ層にそれぞれ 1 つずつサーバがある 2 つのサーバのインストールでは、すべての呼状態データが単一のパーティションで管理されます。同時呼状態のサイズが、単一のサーバ インスタンスで処理できる最大サイズを超える場合には、複数のパーティションが必要です。複数のパーティションを使用する場合、同時呼状態はそれらのパーティション間で分割され、各パーティションはそれぞれデータの別々の部分を処理します。たとえば、2 つのパーティションで構成される SIP データ層の場合、1 つ目のパーティションでは、同時呼状態の半分 (たとえばセッション A ～ M) を処理し、2 つ目のパーティションでは、残りの呼 (セッション N ～ Z) を処理します。

多くの場合、個々のサーバで処理できる呼状態の最大サイズは、Java 仮想マシンの制限に対応し、サーバ 1 つあたり約 1.6GB です。

同じパーティション内でサーバを追加して、呼状態データのコピーを処理できます。同じパーティションに複数のサーバが属する場合には、各サーバは、呼データの同じ部分のコピー (呼状態の「レプリカ」) を処理します。パーティション内のサーバで障害が発生したり、ネットワーク障害のためにアクセスできない場合には、エンジン層に対する呼状態データの提供は、パーティション内の別のレプリカによって行われます。Oracle では機器やネットワークの障害に備え、プロダクション インストール用の各パーティションに 2 つのサーバをコンフィグレーションすることを推薦します。冗長性を強化するため、1 つのパーティションには最大 3 つのレプリカを含めることができます。

6.1.1 datatier.xml コンフィグレーション ファイル

datatier.xml コンフィグレーション ファイルはドメイン ディレクトリの config/custom サブディレクトリにあり、SIP データ層サーバを特定し、呼状態の管理に使うパーティションとレプリカを定義します。サーバ名が datatier.xml にある場合は、そのサーバが起動時に Oracle WebLogic Communication Services SIP データ層の機能を読み込みます。datatier.xml に名前が指定されていないサーバは、エンジン層ノードとして機能し、sipserver.xml コンフィグレーション ファイルでコンフィグレーションされる SIP サーブレット コンテナの機能を提供します。

以下の節では、SIP データ層の一般的なコンフィグレーションに対応する datatier.xml の内容のサンプルを示します。

6.1.2 コンフィグレーションの要件と制約

SIP データ層に属するすべてのサーバは、同一の WebLogic Server クラスタのメンバーです。クラスタ コンフィグレーションにより、各サーバが他のサーバのステータスをモニタできます。また、クラスタを使用すると、すべてのサーバに対して sipserver と datatier カスタム リソースをデプロイすることも簡単です。

信頼性を高めるために、1 つのパーティション内に最大 3 つのレプリカをコンフィグレーションできます。

レプリカやエンジン層ノードの実行中に SIP データ層コンフィグレーションを変更することはできません。SIP データ層のメンバシップの変更や、パーティションまたはレプリカの再コンフィグレーションを行うためには、ドメインのサーバを再起動する必要があります。

図 6-1 に示すように、SipServer ノードの Administration Console の [コンフィグレーション｜データ層] ページから、現在の SIP データ層のコンフィグレーションを参照してコンフィグレーションできます。

図 6-1 Administration Console での SIP データ層のコンフィグレーションの表示 (読み取り専用)

「図 6-1 Administration Console での SIP データ層のコンフィグレーションの表示 (読み取り専用)」の説明

6.2 SIP データ層サーバのコンフィグレーションと管理のベスト プラクティス

レプリカを追加すると、システム全体としての信頼性が向上しますが、パーティションにサーバを追加するごとに、レプリケートされたデータを処理するためのネットワークの帯域幅が余分に必要となるという点には留意が必要です。レプリカが 3 つのパーティションでは、呼状態を変更する各トランザクションに対し、3 つのサーバそれぞれのデータが更新されることになります。

レプリカを使用するときには、高い信頼性を確実に実現するために、同じパーティションの各サーバ インスタンスはそれぞれ別個のマシンに配置します。1 つのマシンで 2 つ以上のレプリカをホストすると、マシンまたはネットワークで障害が発生した場合に、ホストされたそれらのレプリカすべてが影響を受けることになります。

SIP データ層サーバが取り得るステータスは、次の 3 つのいずれかです。

- ONLINE - サーバが呼状態トランザクションを処理できることを示します。

- OFFLINE - サーバが停止中または利用できないことを示します。

- ONLINE_LOCK_AUTHORITY_ONLY - サーバが再起動され、現在の呼状態データで他のレプリカから更新されている途中であることを示します。回復を進行中のサーバでは、呼状態トランザクションの処理は実行できません。そのパーティションが管理する呼状態の完全なコピーをまだ保持していないからです。

定期的な保守のためにいずれかの SIP データ層サーバ インスタンスをオフラインにする必要がある場合、同じパーティション内の少なくとも 1 つのサーバが active であるようにします。active サーバを停止し、同じパーティションの他のすべてのサーバが offline または recovering の場合には、アクティブな呼状態の一部が失われます。

呼状態は、コンフィグレーションされたパーティションすべてに対して均等に、自動的に分割されます。

6.3 SIP データ層のコンフィグレーションとコンフィグレーション ファイルの例

以下の節では、別個の SIP データ層を使用する Oracle WebLogic Communication Services インストールの典型的な例を説明します。

6.3.1 単一パーティションの SIP データ層

単一パーティションで単一サーバの SIP データ層は、最も単純なデータ層のコンフィグレーションを表します。例 6-1 は、単一サーバ デプロイメントでの SIP データ層のコンフィグレーションを示します。

例 6-1 小規模デプロイメントでの SIP データ層のコンフィグレーション

<?xml version="1.0" encoding="UTF-8"?>
<data-tier xmlns="http://www.bea.com/ns/wlcp/wlss/300">
<partition>
<name>part-1</name>
<server-name>replica1</server-name>
</partition>
</data-tier>

既存のパーティションにレプリカを追加するには、同じパーティションに別の server-name エントリを定義するだけです。たとえば、例 6-2 に示した datatier.xml のコンフィグレーション ファイルは、2 つのレプリカのコンフィグレーションを再作成します。

例 6-2 レプリケーションをした小規模デプロイメントでの SIP データ層のコンフィグレーション

<?xml version="1.0" encoding="UTF-8"?>
<data-tier xmlns="http://www.bea.com/ns/wlcp/wlss/300">
<partition>
<name>Partition0</name>
<server-name>DataNode0-0</server-name>
<server-name>DataNode0-1</server-name>
</partition>
</data-tier>

6.3.2 2 つのパーティションの SIP データ層

複数パーティションの作成は簡単です。例 6-3 に示すように、datatier.xml で複数の partition エントリを定義します。

例 6-3 2 つのパーティションの SIP データ層のコンフィグレーション

<?xml version="1.0" encoding="UTF-8"?>
<data-tier xmlns="http://www.bea.com/ns/wlcp/wlss/300">
<partition>
<name>Partition0</name>
<server-name>DataNode0-0</server-name>
</partition>
<partition>
<name>Partition1</name>
<server-name>DataNode1-0</server-name>
</partition>
</data-tier>

6.3.3 2 つのパーティション、2 つのレプリカの SIP データ層

各パーティションに複数の SIP データ層サーバを定義すると、呼状態のレプリカを追加できます。例 6-4 には、各パーティションにある 2 つのパーティションおよび 2 つのサーバ (レプリカ) でシステムを定義するために使用される datatier.xml のコンフィグレーション ファイルを示します。

例 6-4 小規模デプロイメントでの SIP データ層のコンフィグレーション

<?xml version="1.0" encoding="UTF-8"?>
<data-tier xmlns="http://www.bea.com/ns/wlcp/wlss/300">
<partition>
<name>Partition0</name>
<server-name>DataNode0-0</server-name>
<server-name>DataNode0-1</server-name>
</partition>
<partition>
<name>Partition1</name>
<server-name>DataNode1-0</server-name>
<server-name>DataNode1-1</server-name>
</partition>
</data-tier>

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

Oracle WebLogic Communication Services では、RAM を保存するために、長期間維持する呼状態データを Oracle または MySQL RDBMS に格納できます。RDBMS 永続性を有効にすると、SIP データ層は、呼の接続が確立された後、呼状態データをデフォルトで RDBMS に保存します。それ以降のダイアログ境界で、呼状態を変更したり、削除する必要がある場合は、RDBMS に保存した呼状態データを抽出するか、削除します。

Oracle では、アプリケーション設計者用の API を用意し、どのようなときに呼状態データを SIP データ層に保持すべきかについてのヒントを提供しています。呼状態データを頻繁に RDBMS で永続性したり、一定の呼び出しの永続性を無効にするためにこれらのヒントを使用できます。

Oracle WebLogic Communication Services は、インメモリ レプリケーション機能の SIP データ層に追加するためだけに RDBMS を使用します。RDBMS の使用時にレイテンシ パフォーマンスを改善するため、SIP データ層はアクティブに変更されている呼状態 (たとえば、設定中の新しい呼に対応している状態) と共に、メモリにある SIP タイマーを維持します。呼状態はダイアログが確立された後に自動的に保持され、それ以降のダイアログ境界で呼は進行中か、アプリケーション開発者が加えた保持に関するヒントに対応しているかのどちらかです。

RDBMS と組み合わせて使用した場合、SIP データ層はデータベースに書き込む (またはデータベースから削除する) 呼状態を処理するために、レプリカ サーバ インスタンスを 1 つ選択します。使用可能なレプリカならどれでも、次の読み込みのために必要に応じて永続的な保持から呼状態を検索するために使用できます。

ドメインがエンジン層への接続を管理するため SIP 対応ロード バランサを使用している場合、RDBMS への呼状態の格納をエンジン層キャッシュと組み合わせて使用することができます。節 6.7「エンジン層での SIP データのキャッシング」を参照してください。

6.4.1 要件と制約

以下のすべての基準に一致した場合のみ、RDBMS への呼状態の格納が有効になります。

- システムで管理された呼状態は通常、長期間維持されます。

- 格納する呼状態のサイズが大きい。呼状態が非常に大きい場合は、呼状態の格納に大量の RAM が必要です。

- レイテンシ パフォーマンスはデプロイされたアプリケーションに必須ではありません。

RDBMS への呼状態データの格納を選択する前に、特にレイテンシ要件をよく理解しておく必要があります。RDBMS への呼状態の格納のオプションは、SIP データ層クラスタを使用する場合と比較すると、SIP メッセージ処理を行うためにレイテンシがある程度増加します。システムで短い応答時間で多数の存続期間の短い SIP トランザクションを処理しなければならない場合、データ層に呼状態データを格納することをお勧めします。

注意 :
RDBMS の永続性は、大規模な長期間維持する呼状態の SIP データ層で RAM 要件を抑えるように設計されています。永続性されたデータは、障害が発生した SIP データ層パーティションやレプリカを復元する目的では使用できません。

6.4.2 RDBMS への呼状態の格納を有効にする手順

RDBMS への呼状態の格納機能を使用するためには、Oracle WebLogic Communication Services ドメインに必要な JDBC コンフィグレーション、SIP サーブレット コンテナ コンフィグレーション、および呼状態の格納に必要なスキーマを持つデータベースが含まれている必要があります。RDBMS 呼状態テンプレートと共に新しいドメインを設定するコンフィグレーション ウィザードを使用して、ほとんどの必須コンフィグレーションを自動化できます。節 6.4.3「コンフィグレーション ウィザード RDBMS 格納テンプレートの使用」を参照してください。

既存の Oracle WebLogic Communication Services ドメインがある場合、RDBMS ストアをユーザ自身がコンフィグレーションする場合、JDBC および RDBMS 格納を使用する Oracle WebLogic Communication Services のコンフィグレーション方法については、節 6.4.4「RDBMS への呼状態の格納の手動コンフィグレーション」を参照してください。

6.4.3 コンフィグレーション ウィザード RDBMS 格納テンプレートの使用

コンフィグレーション ウィザードでは、RDBMS への呼状態の格納の使用とテストを簡単に行うための単純なテンプレートを提供します。テンプレートから新しいドメインを作成するには、以下の手順に従います。

1. 次のように、コンフィグレーション ウィザード アプリケーション (config.sh) を起動します。

2. デフォルト選択をそのまま使用して、新しい WebLogic ドメインを作成し、[次へ] をクリックします。

3. [既存のテンプレートを、このドメインのベースにする] を選択し、[参照] をクリックして [テンプレートを選択] ダイアログを表示します。

4. replicateddomain.jar という名前のテンプレートを選択し、[OK] をクリックします。

5. [次へ] をクリックします。

6. 新しいドメインの管理者のユーザ名とパスワードを入力し、[次へ] をクリックします。

7. 使用する JDK を選択し、[次へ] をクリックします。

8. ソース テンプレート ファイルに定義されている設定をそのまま使用する場合は [いいえ] を選択し、[次へ] をクリックします。

9. [作成] をクリックしてドメインを作成します。
テンプレートはクラスタに 2 つのエンジン層サーバと SIP データ層サーバ、および管理サーバ (AdminServer) を持つ新しいドメインを作成します。エンジン層クラスタには、以下のリソースおよびコンフィグレーションが含まれます。

- 長期間維持する呼状態データの格納に必要な JDBC データソース、wlss.callstate.datasource。お使いの RDBMS サーバのデータソースをコンフィグレーションするには、このコンフィグレーションを変更する必要があります。節 6.4.3.1「JDBC データソース接続情報の変更」を参照してください。

- RDBMS と地理的冗長、両方の保持に関するヒントのデフォルト処理を定義する永続性コンフィグレーション (Administration Console の ［SipServer］ ノードにある ［コンフィグレーション｜Persistence］ タブ に表示)。

10. [完了] をクリックして、コンフィグレーション ウィザードを終了します。

11. RDBMS に必要なテーブルを変更するには、節 6.4.3.1「JDBC データソース接続情報の変更」にある手順に従います。

12. RDBMS に必要なテーブルを作成するには、節 6.4.4.3 「データベース スキーマの作成」にある手順に従います。

6.4.3.1 JDBC データソース接続情報の変更

新しいドメインのインストール後、RDBMS サーバの接続情報を含めるようテンプレート JDBC データソースを変更します。

1. ブラウザを使用して http://address:port/console にアクセスします。address には管理サーバの実際のリスン アドレスを指定し、port の位置には実際のリスン ポートを指定してください。

2. 左ペインの [サービス｜JDBC｜データ ソース] タブを選択します。

3. 右ペインの wlss.callstate.datasource というデータソースを選択します。

4. 右ペインの [コンフィグレーション｜接続プール] タブを選択します。

5. 以下の接続プール プロパティを変更します。

- URL : RDBMS サーバのホスト名とポート数を指定するため URL を変更します。

- プロパティ : RDBMS の接続情報と一致するようにユーザ、portNumber、SID および serverName プロパティの値を変更します。

- ［パスワード］ および ［パスワードの確認］ : 指定された RDBMS ユーザのパースワードを記入します。

6. [保存] をクリックして変更内容を保存します。

7. 右ペインで ［対象］ タブを選択します。

8. ［Select targets］ ページで、SIP データ層クラスタ名 (たとえば、BEA_DATA_TIER_CLUST) を選択して [保存] をクリックします。

9. [保存] をクリックします。

10. RDBMS に必要なテーブルを作成するには、節 6.4.4.3 「データベース スキーマの作成」にある手順に従います。

6.4.4 RDBMS への呼状態の格納の手動コンフィグレーション

既存の Oracle WebLogic Communication Services ドメインを変更して Oracle または MySQL RDBMS で呼状態データを格納するためには、必要な JDBC データソースをコンフィグレーションし、Oracle WebLogic Communication Services コンフィグレーションを編集して、データベースに必要なスキーマを追加する必要があります。Oracle データベースをコンフィグレーションするには、以下の節にある手順に従います。

6.4.4.1 JDBC リソースのコンフィグレーション

ドメインに必要な JDBC リソースを作成するには、以下の手順に従います。

1. ドメインの管理サーバが実行中でなければ、起動します。

2. ドメインの Administration Console にアクセスします。

3. 左ペインの [サービス｜JDBC｜データ ソース] タブを選択します。

4. [New] をクリックして、新しいデータ ソースを作成します。

5. [Create a New JDBC Data Source] ページの各フィールドに、次の情報を入力します。

- ［Name］ : wlss.callstate.datasource と入力します。

- ［JNDI Name］ : wlss.callstate.datasource と入力します。

- ［Database Type］ : ［Oracle］ を選択します。

- ［Database Driver］ : ［Database Driver］ リストから適切な JDBC ドライバを選択します。このフィールドのリストに記載されたドライバの一部は、ユーザのシステムにデフォルトでインストールできない場合があります。RDBMS ベンダが提供する説明に従い、必要に応じてサード パーティーのドライバをインストールします。

6. [次へ] をクリックします。

7. 使用するデータベースの接続情報を使用して、[接続プロパティ] タブのフィールドに入力します。[次へ] をクリックして続行します。

8. [コンフィグレーションをテスト] をクリックして RDBMS への接続をテストするか、[次へ] をクリックして続行します。

9. ［Select Targets］ ページで、SIP データ層クラスタ名 (たとえば、BEA_DATA_TIER_CLUST) を選択します。

10. [Finish] をクリックして変更内容を保存します。

6.4.4.2 Oracle WebLogic Communication Services 永続性オプションのコンフィグレーション

RDBMS への呼状態の格納を使用するために Oracle WebLogic Communication Services の永続性オプションをコンフィグレーションするには、以下の手順に従います。

1. ドメインの管理サーバが実行中でなければ、起動します。

2. ドメインの Administration Console にアクセスします。

3. 左ペインで [SipServer] ノードをクリックします。

4. 右ペインの [コンフィグレーション｜永続性] タブを選択します。

5. ［Default Handling］ ドロップダウン メニューで「db」または「all」を選択します。［Geo Site ID］ および ［Geo Remote T3 URL］ フィールドが設定されていないかぎり地理的に冗長なレプリケーションが行われないので、「all」を選択しても問題ありません。

6. [保存] をクリックして変更内容を保存します。

6.4.4.3 データベース スキーマの作成

Oracle WebLogic Communication Services には呼状態情報の格納に必要なテーブルを作成するために使用可能な callstate.sql SQL スクリプトが含まれています。コンフィグレーション ウィザードを使用してレプリケートされたドメインをコンフィグレーションした場合、スクリプトはドメイン ディレクトリの user_staged_config サブディレクトリにインストールされます。スクリプトは WLSS_HOME/common/templates/scripts/db/oracle ディレクトリでも使用可能です。

callstate.sql SQL スクリプトの内容を例 6-5 に示します。

例 6-5 呼状態の格納スキーマの callstate.sql スクリプト

drop table callstate;

create table callstate (
key1 int,
key2 int,
bytes blob default empty_blob(),
constraint pk_callstate primary key (key1, key2)
);

SQL*Plus を使用してスクリプト コマンドを実行するには、以下の手順に従います。

1. SQL スクリプトを格納する Oracle WebLogic Communication Services utils ディレクトリに移動します。

cd ~/bea/wlcserver_10.3/common/templates/scripts/db/oracle

2. 必要なテーブルを作成する Oracle データベースに接続し、SQL*Plus アプリケーションを起動します。同じユーザ名とパスワードを使用して、節 6.4.4.1「JDBC リソースのコンフィグレーション」で JDBC ドライバのコンフィグレーション時に指定したのと同じデータベースに接続します。次に例を示します。

sqlplus username/password@connect_identifier

connect_identifier を使って JDBC 接続プールで指定されたデータベースに接続します。

3. Oracle WebLogic Communication Services SQL スクリプト、callstate.sql を実行します。

callstate.sql を起動します。

4. SQL*Plus を終了します。

終了

6.4.5 SIP アプリケーションでの永続性ヒントの使用

Oracle WebLogic Communication Services では簡単な API を用意し、どのようなときに呼状態データを SIP データ層に保持する必要があるかについてのヒントを提供しています。特定の呼び出しまたは SIP リクエストの永続性を無効にしたり、デフォルト設定より (ダイアログ境界で) 頻繁にデータを永続性したりする場合には、API を使用できます。

API を使用するには、WlssSipApplicationSession インスタンスを取得して、永続性の有効化と無効化を行う setPersist メソッドを使用します。RDBMS 格納または地理的に冗長な Oracle WebLogic Communication Services インストールに対して永続性を有効化または無効化できます (節 6.6「地理的に冗長な SIP データ層の使用」を参照してください)。

たとえば、いくつかの SIP 対応ロード バランサ製品では、SIP サーバがアクティブであるかどうかを確認するために SIP OPTIONS メッセージが使用されています。これらのメッセージの RDBMS および地理的に冗長なサイトへの永続性を回避するには、サーブレットは doOptions 例 6-6 に示すように、メソッドを実装して、リクエストをエコーし、永続性を無効にする可能性があります。

例 6-6 オプション メソッドに対する RDBMS 永続性の無効化

protected void doOptions(SipServletRequest req) throws IOException {
WlssSipApplicationSession session =
(WlssSipApplicationSession) req.getApplicationSession();
session.setPersist(WlssSipApplicationSession.PersistenceType.DATABASE,
false);
session.setPersist(WlssSipApplicationSession.PersistenceType.GEO_REDUNDANCY, false);
req.createResponse(200).send();
}

6.5 地理的な冗長性の導入

地理的な冗長性では、地理的に分割された SIP サーバのデプロイメントを使用することで、プロバイダの途切れることのないトランザクションと通信が保証されます。

プライマリ サイトでは、各種の SIP トランザクションおよび通信を処理し、トランザクションの境界が確定した時点で、処理中のトランザクションに関連付けられている状態データをセカンダリ サイトにレプリケートできます。プライマリ サイトに障害が発生すると、呼は処理のために障害の発生したプライマリ サイトからセカンダリ サイトにルーティングされます。同様に、障害からの回復時、呼はプライマリ サイトに再び戻されます。

図 6-2 地理的な冗長性

「図 6-2 地理的な冗長性」の説明

上の図は、地理的な冗長性を示しています。処理は次のように進行します。

1. プライマリ OCCAS クラスタ サイトで呼が開始され、呼の設定と処理が正常に行われます。

2. 呼は通常どおりサイトの SIP 状態層にレプリケートされ、セカンダリ サイトへのレプリケーションが可能になります。

3. 次に SIP 状態層の単一レプリカは、コンフィグレーションされた JMS キューにレプリケートする呼状態データを格納します。

4. WAN 上の JMS を使用して、使用可能ないずれかのエンジンに呼が送信されます。

5. セカンダリ サイトのエンジンは、新しいメッセージをローカル キューでモニタします。メッセージを取得すると、セカンダリ サイト OCCAS クラスタのエンジンは呼状態データを永続化し、それをプライマリ サイトのサイト ID 値に割り当てます。

表 6-1 地理的冗長性のフロー

通常の運用

フェイルオーバ

プライマリ OCCAS サイトでセッションが発生すると、呼の設定と処理が正常に始まります。

グローバル LB ポリシーが更新され、プライマリ サイトからセカンダリ サイトへの呼のルーティングを始めます。

SIP トランザクション境界に達すると、サイトのデータ層に呼がレプリケートされ (インメモリ)、セカンダリ サイトへのレプリケーションが可能になります。

完了すると、セカンダリ サイトはバックアップされた呼状態データのリクエスト処理を始めます。

次にデータ層の単一レプリカは、レプリカ サイトでコンフィグレーションされた JMS キューにレプリケートする呼状態データを格納します。

セカンダリ サイトへのリクエストが行われると、エンジンはデータを取得し、呼のオーナーシップを取得して呼状態を起動します。

データはラウンドロビン方式で、使用可能なエンジンの 1 つに送信されます。

呼に関連するサイト ID をゼロに設定します (ローカルに指定)。

セカンダリ サイトのエンジンは、新しいメッセージをローカル キューでモニタします。

呼状態に存在するすべての休止タイマーを起動します。

メッセージを取得すると、セカンダリ サイトのエンジンは呼状態データを永続化し、それをプライマリ サイトのサイト ID 値に割り当てます。

デフォルトでは、呼状態は個々の呼に対してのみ、またバックアップ サイトでそれらの呼がリクエストされた後にのみ起動されます。

サイト ID はセカンダリ サイトでレプリケートされた呼状態データをセカンダリ サイトで管理されるその他すべての呼状態データから区別します。

サーブレットは WlssSipApplicationSession.getGeoSiteId() メソッドを使用して、呼に関連付けられているサイト ID を検証できます。

レプリケートされた呼状態データのタイマーはセカンダリ サイトで休止状態を続けるので、タイマー処理が動作の妨げになることはありません。

サイト ID の 0 以外の値は、サーブレットがもう一方のサイトからレプリケートされた呼状態データを使用して動作していることを示します。

6.5.1 地理的冗長性を使用するのに最も適切な場面

地理的冗長性を活用するのに最も適切な場面は、以下のとおりです。

- 長時間維持される SIP ダイアログ状態 (SUBSCRIBE ダイアログまたはカンファレンスなど、通常 30 秒以上維持されるダイアログ状態) をアプリケーションが使用する場合

- レプリケートされた状態からアプリケーションが合理的にセッションを再構築できる場合 (再 INVITE、SUBSCRIBE ダイアログを期限切れにして再サブスクリプションをトリガする、など)

- 2 つの OCCAS クラスタまたはサイト間のリンクの帯域幅が小さい (各方向 1Gb/秒未満)、またはレイテンシが高いか変動する (5 ミリ秒 95% を超える) 場合

6.5.2 地理的冗長性を使用するのに不適切な場面

地理的冗長性を使用するのに不適切な場面は、以下のとおりです。

- サイト間で高キャパシティのリンクが使用可能な場合

- 致命的なエラーが発生した際、すべてのトラフィックをセカンダリ サイトに再ルーティングするのに要する時間 (15 ～ 30 秒) よりも長時間維持される可能性のある SIP ダイアログの対応状態に、アプリケーションが到達しない場合

- アプリケーションがセッションを再構築する前に、ユーザがアプリケーション セッションを終了する場合 (たいていのユーザは、セカンダリ サイトからのセッションが再確立される前に呼を切断します)

- アプリケーションによって作成されたセッション ステート オブジェクトの量が、サイトの相互接続でサポートできる量を超えている場合

6.5.3 地理的冗長性の考慮事項 : 始める前に

地理的冗長性を計画する際は、以下の考慮事項に留意してください。

- システムのサイト リンクを設定します。

- 通信時の各ダイアログ状態は 25KB までです (25600 ビット)。

- 一般的な B2BUA には 2 つのダイアログが存在します。

- リンク上の「ジッター」と持続されたレイテンシへの適合のため、25% の活用を目指してください (特定の機器やサイトのトポロジによってはさらに低い値)。
たとえば、100 Mb/秒のリンクは、1 秒間に約 1000 の呼状態を処理できます。一般的な B2BUA は、(デフォルトのコンフィグレーションで) 呼の間に 4 つ (各ダイアログに 2 つ) の状態を生成します。つまり、100 Mb/秒のリンクは、ピーク時の到着速度 (コール レート) が 250 CPS に設定された単一の OWLCS クラスタをサポートします。

- 地理的冗長性は、アプリケーションに対して「透過的」ではありません。多くの場合は、アプリケーションが SetPersist() を適切に使用するように設計する必要があります。開発者は、サイト間のレプリケーションのためアプリケーションがキューに入れる状態の量を考慮する必要があります。

- 長時間維持されるダイアログ状態を選択的に識別するため、SetPersist() をアプリケーション コード内で使用する必要があります。

- セカンダリ サイトにトラフィックをルーティングするのに通常要する時間を考慮すると、より頻繁に状態をレプリケートするアプリケーションでは、JMS キューおよびサイトの相互接続が不必要に飽和状態になります。

- JMS を特定のアプリケーションの環境にチューニングする必要があります。シリアライズ オプション、メッセージの一括処理、信頼性のある配信オプション、およびキュー サイズはすべて、特定のアプリケーションやサイトの特徴に応じて変動します。

- 地理的冗長性のデフォルトの動作は、コンテナで地理的冗長性が有効にされたときに、すべてのダイアログ状態の変更をレプリケートすることです (これはプロダクション デプロイメントでは推奨されません)。

- セカンダリ サイトにトラフィックをルーティングするのに通常要する時間を考慮すると、より頻繁に状態をレプリケートするアプリケーションでは、サイトの相互接続が不必要に飽和状態になります。

- 長時間 (適切なしきい値は 20 ～ 30 秒以上) 維持されるダイアログ状態を選択的に識別するため、SetPersist() をアプリケーション コード内で使用する必要があります。

6.6 地理的に冗長な SIP データ層の使用

Oracle WebLogic Communication Services SIP データ層で使用可能な基本的な呼状態のレプリケーション機能は、単一サイトへのインストールに優れたフェイルオーバ機能を備えています。しかし、SIP データ層内で実行されたアクティブなレプリケーションは、ほとんどのプロダクション ネットワークでレイテンシ パフォーマンスの要求に合わせるために高域のネットワークの帯域幅を必要とします。この帯域幅が要求されると、たとえば 1 つの地域のデータ センターからもう一方の地域のデータ センターまで、単一の SIP データ層クラスタで遠距離間のデータをレプリケートすることが難しくなります。

Oracle WebLogic Communication Services の地理的な永続性の機能は、複数の Oracle WebLogic Communication Services インストール (複数の管理ドメインまたは「サイト」) 全体で、呼状態のトランザクションのレプリケートを可能にします。地理的に冗長なコンフィグレーションは、たとえば長時間の地域的な停電など、サイト全体に壊滅的障害が発生した場合も呼の破棄を最小限にとどめます。

図 6-3 Oracle WebLogic Communication Services の地理的永続性

「図 6-3 Oracle WebLogic Communication Services の地理的永続性」の説明

6.6.1 ドメイン コンフィグレーションの例

別のドメインからデータを永続化するセカンダリ Oracle WebLogic Communication Services ドメイン自体が SIP トラフィックを処理する場合と、単なるアクティブな予備ドメインとして存在する場合があります。最も一般的なコンフィグレーションでは、2 つのサイトが互いの呼状態データをレプリケートするようににコンフィグレーションされ、各サイトがそれぞれのローカル SIP トラフィックを処理します。管理者はどちらかのドメインで障害が発生した場合、もう一方のドメインを「セカンダリ」サイトとして使用することができます。

図 6-4 一般的な地理的冗長性のコンフィグレーション

「図 6-4 一般的な地理的冗長性のコンフィグレーション」の説明

代替コンフィグレーションは複数の他のサイトからのデータを永続性する 1 つのドメインを使用して、それらのサイトのセカンダリ サイトとして機能します。このコンフィグレーションのセカンダリサイトはそれ自体のローカル SIP トラフィックも処理できますが、他のいくつかのインストールからのアクティブなトラフィックを永続性する必要があるため、サイトのリソース要件が大きくなる可能性があります。

図 6-5 地理的冗長性の代替コンフィグレーション

「図 6-5 地理的冗長性の代替コンフィグレーション」の説明

地理的永続性を使用する場合、主要サイトの単一レプリカは、変更された呼状態データを分散された JMS キューに移動します。デフォルトでは、データは SIP ダイアログの境界のみでキューに移動します。(節 6.4.5「SIP アプリケーションでの永続性ヒントの使用」で説明しているように、カスタム API はさらに細かくデータをレプリケートする必要があるアプリケーション開発者向けです)。セカンダリ サイトでは、エンジン層サーバはメッセージを受け取ってデータをそのサーバの SIP データ層クラスタに書き込むために、分散されたキューをモニタするメッセージ リスナを使用します。セカンダリ サイトが長期間維持する呼状態の格納に RDBMS を使用する場合 (推奨) は、分散されたキューから書き込まれるデータはすべて、SIP データ層のメモリ内の格納場所ではなく、RDBMS に直接移動します。

6.6.2 要件と制約

Oracle WebLogic Communication Services の地理的に冗長な永続性の機能は、RDBMS で長期的に維持される呼状態データの管理に非常に便利です。Oracle WebLogic Communication Services はサイト間でレプリケートする前に複数の呼状態データの収集を選択する可能性があるため、存続期間の短い呼はセカンダリ サイトへの移行中に失われることがあります。

所定の地域のサイトで稼動状態をモニタすると共に、地理的に異なる場所の間で呼を分割できる、信頼性のあるサイト対応のロード バランス ソリューションを使用する必要があります。Oracle WebLogic Communication Services には自動的にドメイン全体の障害を検出したり、セカンダリ サイトにフェイルオーバする機能はありません。所定のサイトに障害が発生した場合は、管理者が責任を持って判断を下し、そのサイトの呼を適切なセカンダリ サイトにリダイレクトします。その上、サイト対応のロード バランサは特定の callId へのすべてのメッセージを単一のホーム サイトに向けなければなりません (「アクティブ」サイト)。フェイルオーバの後、障害が発生したサイトが復元されると、ロード バランサは、2 つのサイトの間で呼を分割せずに、アクティブなサイトへの呼を続行しなければなりません。

セカンダリ サイトにフェイルオーバが起こった場合、一部の呼が破棄される可能性があります。一般的に、Oracle WebLogic Communication Services ではサイトのレプリケーションに用いる呼状態データが SIP ダイアログの境界のみでキューイングされるため、このような結果が生じます。データがキューに書き込まれる前に障害が発生すると、キューイングされたデータは削除されます。

また、SIP ダイアログの境界で呼状態を変更する場合のみ、Oracle WebLogic Communication Services はサイト全体の呼状態データをレプリケートします。セカンダリ サイトを起動する前にプライマリ サイトに長期に渡り実行中の呼が存在し、しかも呼状態にずっと変更がない場合、このような呼のデータはセカンダリ サイトにレプリケートされません。長期に渡り実行中の呼状態がレプリケートされる前に障害が発生した場合は、呼はフェイルオーバ中に失われます。

Oracle WebLogic Communication Services インストールのキャパシティを計画するとき、フェイルオーバの後、所定のサイトはそのサイト自体の地理的位置からだけでなく、障害が発生したサイトからすべての呼をサポートできるようにしておく必要があります。つまり、地理的に冗長なコンフィグレーションに関連するすべてのサイトは、フェイルオーバが発生しないかぎり、最大処理能力以下で動作することになります。

6.6.3 地理的永続性のコンフィグレーションの手順

Oracle WebLogic Communication Services の地理的永続性機能を使用するには、プライマリ「ホーム」サイトとセカンダリ レプリケーション サイトの両方で特定のコンフィグレーション タスクを行う必要があります。

表 6-2 地理的永続性のコンフィグレーションの手順

プライマリ「ホーム」サイトでの手順

セカンダリ「レプリケーション」サイトでの手順

1. Oracle WebLogic Communication Services ソフトウェアをインストールして、レプリケートされたドメインを作成します。

2. 長期間維持する呼状態の RDBMS への格納を可能にします (推奨)。

3. 永続性オプションを設定して、以下の作業を行う。一意な地域的サイトの ID を定義する、セカンダリ サイトの URL を識別する、レプリケーションのヒントを有効にします。

1. Oracle WebLogic Communication Services ソフトウェアをインストールして、レプリケートされたドメインを作成します。

2. 長期間維持する呼状態の RDBMS への格納を可能にします (推奨)。

3. データをレプリケートするのに必要な JMS サーバおよびモジュールをコンフィグレーションします。

4. 永続性オプションを設定して一意な地域的サイトの ID を定義します。

注意 :
ほとんどのプロダクション デプロイメントでは、2 つのサイトが相互に複製サービスを行うため、一般的にはインストールをそれぞれプライマリおよびセコンダリ サイトとしてコンフィグレーションします。

Oracle WebLogic Communication Services は、表 6-2 で説明されたほとんどのリソースのコンフィグレーションを自動化するドメイン テンプレートを備えています。テンプレートの使用の詳細については、節 6.6.4「地理的永続性のコンフィグレーション ウィザード テンプレートの使用」を参照してください。

既存の Oracle WebLogic Communication Services ドメインで地理的永続性を使用する場合は、節 6.6.5「地理的冗長性の手動コンフィグレーション」の手順に従ってリソースを作成します。

6.6.4 地理的永続性のコンフィグレーション ウィザード テンプレートの使用

Oracle WebLogic Communication Services は、地理的永続性の機能を使用するために、2 種類のコンフィグレーション ウィザード テンプレートを備えています。

- WLSS_HOME/common/templates/domains/geo1domain.jar は、サイト ID が 1 のプライマリ サイトをコンフィグレーションします。ドメインは geo2domain.jar で作成されたエンジン層サーバにデータをレプリケートします。

- WLSS_HOME/common/templates/domains/geo2domain.jar は、geo1domain.jar で作成されたドメインから呼状態データをレプリケートするセカンダリ サイトをコンフィグレーションします。このインストールのサイト ID は 2 です。

どちらのドメイン テンプレートのサーバ ポート番号も固有の番号であるため、必要に応じて 1 台のマシンで地理的永続性の機能をテストすることができます。各ドメインのインストールとコンフィグレーションを行うには、次の節に示す手順に従います。

6.6.4.1 プライマリ サイトのインストールとコンフィグレーション

テンプレートから新しいプライマリ ドメインを作成するには、以下の手順に従います。

1. 次のように、コンフィグレーション ウィザード アプリケーション (config.sh) を起動します。

2. デフォルト選択をそのまま使用して、新しい WebLogic ドメインを作成し、[次へ] をクリックします。

3. [既存のテンプレートを、このドメインのベースにする] を選択し、[参照] をクリックして [テンプレートを選択] ダイアログを表示します。

4. geo1domain.jar という名前のテンプレートを選択して [OK] をクリックします。

5. [次へ] をクリックします。

6. 新しいドメインの管理者のユーザ名とパスワードを入力し、[次へ] をクリックします。

7. 使用する JDK を選択し、[次へ] をクリックします。

8. ソース テンプレート ファイルに定義されている設定をそのまま使用する場合は [いいえ] を選択し、[次へ] をクリックします。

9. [作成] をクリックしてドメインを作成します。
テンプレートはクラスタに 2 つのエンジン層サーバと SIP データ層サーバ、および管理サーバ (AdminServer) を持つ新しいドメインを作成します。エンジン層クラスタには、以下のリソースおよびコンフィグレーションが含まれます。

- 長期間維持する呼状態データの格納に必要な JDBC データソース、wlss.callstate.datasource。この機能を使用する場合は、節 6.4.3.1「JDBC データソース接続情報の変更」で説明しているように、RDBMS 接続情報を含めるよう JDBC データソースを変更します。

- 永続性なコンフィグレーション ([SipServer] ノードにある Administration Console の [コンフィグレーション｜永続性] タブに表示) は以下の項目を定義します。

- RDBMS および地理的永続性の両方に対する永続性のヒントのデフォルト処理。

- Geo Site ID は 1 です。

- 地理的冗長性のレプリケーション サイトとして「geo2」ドメインのエンジン層サーバを特定する Geo Remote T3 の URL、t3://localhost:8011,localhost:8061。

10. [完了] をクリックして、コンフィグレーション ウィザードを終了します。

11. 節 6.6.4.2「セカンダリ サイトのインストール」に示す手順に従って、レプリケーションを行うドメインを作成します。

6.6.4.2 セカンダリ サイトのインストール

「geo1」ドメインから呼状態データをレプリケートしてセカンダリ サイトを作成するテンプレートを使用するには、以下の手順に従います。

1. 次のように、コンフィグレーション ウィザード アプリケーション (config.sh) を起動します。

2. デフォルト選択をそのまま使用して、新しい WebLogic ドメインを作成し、[次へ] をクリックします。

3. [既存のテンプレートを、このドメインのベースにする] を選択し、[参照] をクリックして [テンプレートを選択] ダイアログを表示します。

4. geo2domain.jar という名前のテンプレートを選択して [OK] をクリックします。

5. [次へ] をクリックします。

6. 新しいドメインの管理者のユーザ名とパスワードを入力し、[次へ] をクリックします。

7. 使用する JDK を選択し、[次へ] をクリックします。

8. ソース テンプレート ファイルに定義されている設定をそのまま使用する場合は [いいえ] を選択し、[次へ] をクリックします。

9. [作成] をクリックしてドメインを作成します。
テンプレートはクラスタに 2 つのエンジン層サーバと SIP データ層サーバ、および管理サーバ (AdminServer) を持つ新しいドメインを作成します。エンジン層クラスタには、以下のリソースおよびコンフィグレーションが含まれます。

- 長期間維持する呼状態データの格納に必要な JDBC データソース、wlss.callstate.datasource。この機能を使用する場合は、節 6.4.3.1「JDBC データソース接続情報の変更」で説明しているように、RDBMS 接続情報を含めるよう JDBC データソースを変更します。

- 永続性なコンフィグレーション ([SipServer] ノードにある Administration Console の [コンフィグレーション｜永続性] タブに表示) は以下の項目を定義します。

- RDBMS および地理的な永続性の両方に対する永続性ヒントのデフォルト処理。

- Geo Site ID は 2 です。

- JMS システム モジュール、SystemModule-Callstate は以下を含みます。

- ConnectionFactory-Callstate、プライマリ サイトからの呼状態データをバックアップするために必要な接続ファクトリ

- ConnectionFactory-Callstate、プライマリ サイトからの呼状態データをバックアップするために必要な均等に分散されたキュー

サイトのエンジン層クラスタには、JMS システム モジュールが割り当てられています。

- 2 つのJMS サーバ、JMSServer-1 および JMSServer-2 はそれぞれ engine1-site2 および engine2-site2 にデプロイされます。

10. [完了] をクリックして、コンフィグレーション ウィザードを終了します。

6.6.5 地理的冗長性の手動コンフィグレーション

既存のレプリケートされた Oracle WebLogic Communication Services インストール、または 1 組のインストールをお持ちの場合、地理的な冗長性を有効にするために必要な JMS および JDBC リソースを手動で作成する必要があります。また、レプリケーションを行うには、各サイトをコンフィグレーションする必要があります。地理的な冗長性を有効化にするための基本的な手順を以下に示します。

1. JDBC リソースのコンフィグレーション。長期間維持する呼状態データを RDBMS に格納する場合、プライマリとセカンダリの両方のサイトをコンフィグレーションすることをお勧めします。

2. 永続性オプションのコンフィグレーション。エンジン層のヒントの RDBMS への書き込みを有効化するか、地理的な冗長なインストールにデータをレプリケートするには、プライマリおよびセカンダリの両方のサイトに永続性のオプションをコンフィグレーションする必要があります。

3. JMS リソースのコンフィグレーション。セカンダリ サイトは、もう一方のサイトから呼状態データをレプリケートするために利用可能な JMS サーバおよび固有の JMS モジュール リソースを持つ必要があります。

以下の節では、各手順について詳しく説明します。

6.6.5.1 JDBC リソースのコンフィグレーション (プライマリおよびセカンダリ サイト)

長期間維持する呼状態を RDBMS へ格納する際に必要な JDBC リソースをコンフィグレーションするには、節 6.4「長期間維持する呼状態データの RDBMS への格納」の手順に従います。

6.6.5.2 永続性オプションのコンフィグレーション (プライマリおよびセカンダリ サイト)

地理的な冗長なレプリケーションを有効化にするために、プライマリおよびセカンダリ サイトに正しく永続性の設定を行う必要があります。永続性をコンフィグレーションするには、以下の手順に従います。

1. ブラウザを使用して http://address : port/console にアクセスします。address には管理サーバの実際のリスン アドレスを指定し、port の位置には実際のリスン ポートを指定してください。

2. コンフィグレーション ロックを取得するには、[Lock & Edit] をクリックします。

3. 左ペインで [SipServer] ノードをクリックします。コンソールの右ペインにある 2 つのレベルのタブ付きページで Oracle WebLogic Communication Services をコンフィグレーションし、モニタします。

4. 右ペインの [コンフィグレーション｜永続性] タブを選択します。

5. 永続性の属性を以下のようにコンフィグレーションします。

- デフォルトの処理 : 長期間維持する呼状態データを RDBMS に永続化し、地理的な冗長性を得るために外部サイトにデータをレプリケートする (推奨) には、[all] を選択します。インストールで呼状態データを RDBMS に格納できない場合は、[all] の代わりに [geo] を選択します。

- Geo Site ID : 他のすべての設定されたサイトからこのサイトを識別するために、1 ～ 9 から固有の番号を 1 つ選んで入力します。0 のサイト ID は、問題のあるサイト (もう一方のサイトから呼状態を複製できないサイト) にローカルな呼状態を示すために使用します。

- Geo Remote T3 URL : プライマリ サイト (またはそのサイトのデータをもう一方のサイトにレプリケートするセカンダリ サイト) では、T3 URL、またはこのサイトの呼状態データを複製するエンジン層サーバの URL を入力します。セカンダリ エンジン層のクラスタがクラスタ アドレスを使用する場合、t3://mycluster:7001 のような単一の T3 URL を入力できます。セカンダリ エンジン層クラスタがクラスタ アドレスを使用しない場合は、t3://engine1-east-coast:7001,t3://engine2-east-coast:7002,t3://engine3-east-coast:7001,t4://engine4-east-coast:7002 のように、エンジン層サーバの URL をカンマで区切って入力します。

6. [保存] をクリックしてコンフィグレーションの変更を保存します。

7. エンジン層サーバに変更を適用するには [変更のアクティブ化] をクリックします。

6.6.5.3 JMS リソースのコンフィグレーション (セカンダリ サイトのみ)

もう一方のサイトから呼状態データをレプリケートするサイトはすべて、特定の JMS リソースをコンフィグレーションする必要があります。一方のサイトからデータをレプリケートしないサイトには、リソースは必要ありません。

JMS リソースを設定するには、以下の手順に従います。

1. ブラウザを使用して http://address : port/console にアクセスします。address には管理サーバの実際のリスン アドレスを指定し、port の位置には実際のリスン ポートを指定してください。

2. コンフィグレーション ロックを取得するには、[Lock & Edit] をクリックします。

3. 左ペインの [サービス｜Messaging｜JMS Servers] タブを選択します。

4. 右ペインの [New] をクリックします。

5. JMS サーバに固有の名前を入力するか、デフォルト名を取得します。[次へ] をクリックして続行します。

6. 対象リストには、インストール内の単一のエンジン層サーバ ノード名を選択します。[Finish] をクリックして、新しいサーバを作成します。

7. インストールで各エンジン層サーバノードに専用の JMS サーバを作成するには、手順 3 ～ 6 を繰り返します。

8. 左ペインの [サービス｜Messaging｜JMS Modules] ノードを選択します。

9. 右ペインの [New] をクリックします。

10. ［JMS System Module] ページのフィールドに、以下の情報を入力します。

- [名前] : 新しいモジュール名を入力するか、デフォルト名を取得します。

- [記述子ファイル名] : JMS モジュール コンフィグレーションを格納するコンフィグレーション ファイル名のプレフィックスを入力します (たとえば、systemmodule-callstate)。

11. [次へ] をクリックして続行します。

12. エンジン層クラスタ名を選択して、［クラスタ内の全サーバ］ オプションを選択します。

13. [次へ] をクリックして続行します。

14. [Would you like to add resources to this JMS system module] を選択し、[終了] をクリックしてモジュールを作成します。

15. モジュールに新しいリソースを追加するには、[New] をクリックします。

16. [Connection Factory] オプションを選択して [次へ] をクリックします。

17. [Create a new JMS System Module Resource] の各フィールドに、以下の情報を入力します。

- [Name] : ConnectionFactory-Callstate のようなリソースの記述名を入力します。

- [JNDI Name] : wlss.callstate.backup.site.connection.factory という名前を入力します。

18. [次へ] をクリックして続行します。

19. [Finish] をクリックして、新しいリソースを作成します。

20. 今作成した接続ファクトリ リソース名を選択します。

21. 右ペインで [コンフィグレーション｜Load Balance] タブを選択します。

22. [Server Affinity Enabled] オプションを選択解除して、[保存] をクリックします。

23. 左ペインの [サービス｜Messaging｜JMS Modules] ノードをもう一度選択します。

24. 右ペインに作成された JMS モジュール名を選択します。

25. もう一つの JMS リソースを作成するため [New] をクリックします。

26. [Distributed Queue] オプションを選択して [次へ] をクリックします。

27. [Create a new JMS System Module Resource] の [名前] フィールドに、DistributedQueue-Callstate のようなリソースの記述名を入力します。

28. [JNDI Name] : 名前を入力し、[Create a new JMS System Module Resource] ページの各フィールドに以下の情報を入力します。

- [Name] : ConnectionFactory-Callstate のようなリソースの記述名を入力します。

- [JNDI Name] : wlss.callstate.backup.site.queue という名前を入力します。

29. [次へ] をクリックして続行します。

30. [Finish] をクリックして、新しいリソースを作成します。

31. [保存] をクリックしてコンフィグレーションの変更を保存します。

32. エンジン層サーバに変更を適用するには [変更のアクティブ化] をクリックします。

6.6.6 地理的冗長性のレプリケーションの動作について

この節では、複数のサイトが呼状態データをレプリケートする方法について詳しく説明します。管理者は地理的に冗長なレプリケーションの仕組みに対する理解を深め、このようなコンフィグレーションで発生する可能性のある問題をより効率的に解決するために、この情報を使用できます。Oracle WebLogic Communication Services インストール全体のレプリケーションの内部機能は、製品の将来的なリリースで変更される可能性があります。

6.6.6.1 呼状態のレプリケーションの処理

Oracle WebLogic Communication Services のプライマリ サイトで呼が発生すると、呼の設定と処理が正常に始まります。SIP ダイアログの境界に達すると、サイトの SIP データ層に呼がレプリケートされ (インメモリ)、セカンダリ サイトへのレプリケーションが可能になります。Oracle WebLogic Communication Services はネットワークの使用を最適化するために、レプリケーションに複数の呼状態を集めることを選択することもあります。

次に SIP データ層の単一レプリカは、レプリカ サイトでコンフィグレーションされた JMS キューにレプリケートする呼状態データを格納します。データはラウンドロビン方式で、使用可能なエンジンの一つ (sipserver.xml の geo-remote-t3-url 要素で指定) に送信されます。セカンダリ サイトのエンジンは、新しいメッセージをローカル キューでモニタします。

メッセージを取得すると、セカンダリ サイトのエンジンは呼状態データを永続性し、それをプライマリ サイトのサイト ID 値に割り当てます。サイト ID はセカンダリ サイトでレプリケートされた呼状態データをセカンダリ サイトで管理されるその他すべての呼状態データから区別します。レプリケートされた呼状態データのタイマーはセカンダリ サイトで休止状態を続けるので、タイマー処理が動作の妨げになることはありません。

6.6.6.2 フェイルオーバ後の呼状態の処理

フェイルオーバを実行するには、管理者はグローバルなロード バランサ ポリシーを変更して障害が発生したプライマリ サイトからセカンダリ サイトへの呼のルーティングを始める必要があります。この処理を終了したあとで、セカンダリ サイトはバックアップされた呼状態データのリクエスト処理を始めます。障害が発生したサイトからレプリケートしたデータへのリクエストが行われると、エンジンはデータを取得し、呼のオーナーシップを取得して呼状態を起動します。起動処理には以下の動作が含まれます。

- 呼に関連するサイト ID をゼロに設定する (ローカルに指定する)。

- 呼状態に存在するすべての休止タイマを起動する。

デフォルトでは、呼状態は個々の呼に対してのみ、またバックアップ サイトでそれらの呼がリクエストされた後にのみ起動されます。SipServerRuntimeMBean にはもう一方のサイトから複製された呼状態データをすべて引き継ぐ際に使用する activateBackup(byte site) メソッドが含まれています。管理者は WLST コンフィグレーション スクリプトを使用してこのメソッドを実行できます。また、サーバでデプロイされたアプリケーションはレプリケートされたサイト データへのリクエストがあるとこれを検出し、その後にメソッドを実行することもできます。例 6-7 にサイト 1 からレプリケートされた呼状態データすべてのオーナーシップを変更し、セカンダリ サイトを起動する JSP のサンプルコードを示します。デプロイされたサーブレット内でも同様のコードを使用できます。JSP またはサーブレットのどちらかを activateBackup メソッドを実行するために特権を持つユーザとして実行する必要があります。

特定の呼状態リクエストかどうかを検出するために、サーブレットは WlssSipApplicationSession.getGeoSiteId() メソッドを使用して呼に関連するサイト ID を検証できます。サイト ID の 0 以外の値は、サーブレットがもう一方のサイトからレプリケートされた呼状態データを使用して動作していることを示します。

例 6-7 JMX を使用したセカンダリ サイトの起動

<%
byte site = 1;

InitialContext ctx = new InitialContext();
MBeanServer server = (MBeanServer) ctx.lookup("java:comp/env/jmx/runtime");
Set set = server.queryMBeans(new ObjectName("*:*,Type=SipServerRuntime"), null);
if (set.size() == 0) {
throw new IllegalStateException("No MBeans Found!!!");
}

ObjectInstance oi = (ObjectInstance) set.iterator().next();
SipServerRuntimeMBean bean = (SipServerRuntimeMBean)
MBeanServerInvocationHandler.newProxyInstance(server,
oi.getObjectName());

bean.activateBackup(site);
%>

フェイルオーバの後、ロード バランサは、新しく起動されたサイトに同じ callId を持っすべての呼をルートしなければならないことに注意してください。障害が発生した元のサイトをサービスに復元しても、ロード バランサは 2 つの地理的なサイトの間で呼を分割してはいけない。

6.6.7 呼状態のバックアップの削除

リモート サイトでメンテナンスを行うため、またはバックアップ サイトを完全に変更するために、リモート サイトへの呼状態のレプリケートを停止することもできます。レプリケーションは節 6.6.5.2「永続性オプションのコンフィグレーション (プライマリおよびセカンダリ サイト)」で説明されるように、プライマリ サイトの Site Handling 属性を「none」に設定すると停止できます。

主要なサイトの地理的レプリケーションを無効にした後で、セカンダリ サイトのバックアップの呼状態も削除することもできます。SipServerRuntimeMBean には、あるサイトでもう一方のサイトからレプリケートされたすべての呼状態データを強制的に削除する際に使用できる deleteBackup(byte site) メソッドが含まれています。管理者は WLST コンフィグレーション スクリプトを使用するか、セカンダリ サイトにデプロイされたアプリケーションを通じてこのメソッドを実行できます。このメソッドを実行する手順は、節 6.6.6.2「フェイルオーバー後の呼状態の処理」で説明される activateBackup メソッドの使用手順と同様です。

6.6.8 地域的サイト全体のレプリケーションのモニタ

ReplicaRuntimeMBean には地理的に冗長なレプリケーションについてデータを取得する 2 つの新しいメソッドが含まれています。

- getBackupStoreOutboundStatistics() はセカンダリ サイトの JMS キューにキューイングされている呼数に関する情報を提供します。

- getBackupStoreInboundStatistics() はセカンダリ サイトがもう一方のサイトからレプリケートする呼状態データに関する情報を提供します。

ReplicaRuntimeMBean の詳細については、『Oracle Fusion Middleware Communication Services Java API Reference』を参照してください。

6.6.9 地理的レプリケーションのトラブルシューティング

節 6.6.8「地域的サイト全体のレプリケーションのモニタ」で説明されている ReplicaRuntimeMBean メソッドの使用に加えて、管理者は障害が発生したデータベースがセカンダリ サイトのインストールに書き込むことを示す、すべての SNMP トラップをモニタする必要があります。

管理者は地理的に冗長なコンフィグレーションに属しているすべてのサイトが固有のサイト ID を使用しているか確認する必要があります。

6.7 エンジン層での SIP データのキャッシング

第 15 章「Oracle WebLogic Communication Services 基本プラットフォーム トポロジ」で説明したように、デフォルトの Oracle WebLogic Communication Servicesでは、エンジン層クラスタはステートレスです。独立した SIP データ層クラスタが 1 つまたは複数のパーティションで呼状態データを管理します。また、エンジン層サーバは必要に応じて SIP データ層にデータを取得し、書き込みます。エンジンは各パーティションにある複数のレプリカに呼状態データを書き込んで、SIP データ層レプリカがオフラインになった場合に自動フェイルオーバを提供することができます。

Oracle WebLogic Communication Services は呼状態データの一部をローカルにキャッシュするオプションをエンジン層サーバに提供し、これを SIP データ層内でも行います。ローカル キャッシュを使用すると、エンジン層サーバは最初に既存の呼び出し状態データのローカル キャッシュをチェックします。キャッシュに必要なデータが含まれており、かつデータのローカルコピーが （SIP データ層コピーと比較して） 最新データの場合、エンジンは SIP データ層の呼び出し状態をロックしますが、直接キャッシュから読み込みます。エンジンは SIP データ層サーバから呼状態データを取り込む必要がないので、リクエストへの応答時間のパフォーマンスが改善されます。

エンジン層キャッシュは、常に最後にエンジン層サーバで使用された呼状態データのみ格納します。クライアントのリクエストに応答するため、または期限切れデータをリフレッシュするために、必要に応じて呼状態データをエンジンのローカル キャッシュに移動します。キャッシュに新しい呼状態を書き込む際にキャッシュがいっぱいだと、アクセスされた順番が古い順に呼状態エントリから削除されます。エンジン層キャッシュのサイズはコンフィグレーション不可です。

SIP 対応ロード バランサがエンジン層クラスタにリクエストを管理する場合は、ローカル キャッシュの使用が最も有利です。SIP 対応ロード バランサでは、確立された呼に対するリクエストはすべて同じエンジン層サーバに転送され、キャッシュの有効性を改善します。同じ呼に次のリクエストが (様々なキャッシュ コンテンツを持つ) 別のエンジン層サーバから分散されるため、SIP 対応ロード バランサを使用しないとキャッシュの有効性が限定されます。

6.7.1 エンジン層キャッシングのコンフィグレーション

デフォルトでは、エンジン層キャッシングは有効になっています。エンジン層で呼状態データの部分的キャッシングを無効にするため、sipserver.xml : の engine-call-state-cache-enabled 要素を指定します。

<engine-call-state-cache-enabled>false</engine-call-state-cache-enabled>

使用可能になると、キャッシュ サイズは呼状態 250 回で固定されます。エンジン層キャッシュのサイズはコンフィグレーション不可です。

6.7.2 キャッシュ パフォーマンスのモニタとチューニング

SipPerformanceRuntime エンジン層キャッシュの動作をモニタします。表 6-3 では MBean 属性を説明します。

表 6-3 SipPerformanceRuntime 属性の概要

属性

説明

cacheRequests

セッション データ項目の総数を追跡します。

cacheHits

セッション データをリクエストした結果、エンジン層サーバのローカル キャッシュに同じデータのバージョンが新たにみつかるたびに、この属性がサーバによりインクリメントされます。このカウンタは、キャッシュ データが期限切れで SIP データ層にあるデータで更新する必要がある場合にもインクリメントされます。

cacheValidHits

この属性は、セッション データのリクエストがデータのキャッシュ バージョンで完全に満たされるごとにインクリメントされます。

使用可能になると、キャッシュ サイズは呼状態 250 回で固定されます。キャッチはメモリを消費するので、パフォーマンスの目的を達成するためには、エンジン層サーバの実行に使用する JVM 設定を変更する必要があります。キャッシュされた呼状態は、ガベージ コレクションの永続的な格納場所で維持されます。キャッシュが使用可能 (たとえば、-XX:MaxNewSize=32m -XX:NewSize=32m） な場合、固定値「NewSize」を削減します。実際の価は、アプリケーションで使用された呼状態サイズだけでなく、アプリケーション自体のサイズにもよります。

6.8 SIP データ層サーバのモニタとトラブルシューティング

実行時 MBean である (ReplicaRuntimeMBean) からは、SIP データ層の現在の状態とコンフィグレーションについての有用な情報が得られます。この MBean が持つ属性の詳細については、『Oracle Fusion Middleware Communication Services Java API Reference』を参照してください。

これらの属性の多くは、図 6-6 に示すように、Administration Console の SIP サーバの [モニタ｜データ層の情報] タブで参照できます。

図 6-6 Administration Console での SIP データ層のモニタ

「図 6-6 Administration Console での SIP データ層のモニタ」の説明

例 6-8 は、単一の管理対象サーバ インスタンスの現在の属性を SIP データ層パーティションでクエリする、シンプルな WLST セッションを示します。表 6-1 は、MBean のサービスについて詳しく説明します。

例 6-8 ReplicaRuntimeMBean の属性の表示

connect('weblogic','weblogic','t3://datahost1:7001')
custom()
cd('com.bea')
cd('com.bea:ServerRuntime=replica1,Name=replica1,Type=ReplicaRuntime')
ls()
-rw-   BackupStoreInboundStatistics                 null
-rw-   BackupStoreOutboundStatistics                null
-rw-   BytesReceived                                0
-rw-   BytesSent                                    0
-rw-   CurrentViewId                                2
-rw-   DataItemCount                                0
-rw-   DataItemsToRecover                           0
-rw-   DatabaseStoreStatistics                      null
-rw-   HighKeyCount                                 0
-rw-   HighTotalBytes                               0
-rw-   KeyCount                                     0
-rw-   Name                                         replica1
-rw-   Parent                                       com.bea:Name=replica1,Type=S
erverRuntime
-rw-   PartitionId                                  0
-rw-   PartitionName                                part-1
-rw-   ReplicaId                                    0
-rw-   ReplicaName                                  replica1
-rw-   ReplicaServersInCurrentView                  java.lang.String[replica1, replica2]
-rw-   ReplicasInCurrentView                        [I@75378c
-rw-   State                                        ONLINE
-rw-   TimerQueueSize                               0
-rw-   TotalBytes                                   0
-rw-   Type                                         ReplicaRuntime

表 6-4 ReplicaRuntimeMBean のメソッドと属性の概要

メソッド/属性

説明

dumpState()

選択した SIP データ層サーバ インスタンスの全体の状態を、Oracle WebLogic Communication Services ログ ファイルに記録します。dumpState() メソッドは、問題が発生した場合に、テクニカル サポートの担当者に追加的な診断情報を提示する目的で使用できます。

BackupStoreInboundStatistics

遠隔地の地理的サイトからレプリケーションされた呼状態データに関する統計を提供します。

BackupStoreOutboundStatistics

遠隔地の地理的サイトにレプリケーションされた呼状態データに関する統計を提供します。

BytesReceived

この SIP データ層サーバが受信した総バイト数です。バイト データを受信するのは、格納する呼状態データがエンジン層のサーバから渡されたときです。

BytesSent

この SIP データ層サーバが送信した総バイト数です。バイト データをエンジン層サーバに送信するのは、格納された呼状態データを提供するよう要求されたときです。

CurrentViewId

現在のビュー ID。SIP データ層のレイアウトが変更になるたびに、ビュー ID はインクリメントされます。たとえば、SIP データ層クラスタの複数サーバが最初に起動されるときには、各サーバが SIP データ層に加わった時点でビュー ID がインクリメントされます。同様に、意図的または障害によって SIP データ層からサーバが抜けたときにも、ビュー ID はインクリメントされます。

DataItemCount

このサーバがデータを持つ、格納された呼状態キーの総数です。サーバが現在データを回復する途中の場合には、この属性の値は KeyCount 属性よりも小さいことがあります。

DataItemsToRecover

パーティション内の他のレプリカから回復する必要がある呼状態キーの総数です。SIP データ層サーバは、保守のためにオフラインにした後で、再起動してパーティションに参加したときに、必要に応じてキーを回復します。

HighKeyCount

このサーバで起動以降に処理した呼状態キーの総数の最大値です。

HighTotalBytes

このサーバで起動以降に処理した呼状態データの総バイト数の最大値です。

KeyCount

レプリカに格納されている呼データ キーの数です。

PartitionId

このサーバのパーティションのパーティション ID を表す数 (0 ～ 7) です。

PartitionName

このサーバのパーティションの名前。

ReplicaId

このサーバのレプリカのレプリカ ID を表す数 (0 ～ 2) です。

ReplicaName

このサーバのレプリカの名前。

ReplicaServersInCurrentView

同じパーティションに属している他の Oracle WebLogic Communication Services インスタンスの名前です。

State

レプリカの現在の状態です。SIP データ層サーバが取り得るステータスは、次の 3 つのいずれかです。

- ONLINE - サーバが呼状態トランザクションを処理できることを示します。

- OFFLINE - サーバが停止中または利用できないことを示します。

- ONLINE_LOCK_AUTHORITY_ONLY - サーバが再起動され、現在の呼状態データで他のレプリカから更新されている途中であることを示します。回復を進行中のサーバでは、呼状態トランザクションの処理は実行できません。そのパーティションが管理する呼状態の完全なコピーをまだ保持していないからです。

TimerQueueSize

SIP データ層サーバにキューイングされたタイマーの現在の数です。通常は KeyCount 値に一致しますが、追加された新しい呼状態に対応するタイマーがまだキューイングされていない場合には、この値の方が小さいこともあります。

注意 : エンジン層サーバは、SIP データ層インスタンスを定期的にチェックして、呼に対応するタイマーが時間切れになったかどうかを判断します。SIP タイマーが適切に機能するためには、共通の時刻設定元に合わせて、すべてのエンジン層サーバがシステム時計をアクティブに同期することが必要です。エンジン層の各インスタンスで、NTP (Network Time Protocol) クライアントまたはデーモンを使用し、特定の NTP サーバに同期することをお勧めします。節 3.5「タイマー処理のコンフィグレーション」を参照してください。

TotalBytes

このサーバで扱った呼状態によって消費された総バイト数です。

7 Sash によるユーザのプロビジョニング

この章では、Sash ユーティリティの使用について説明します。この章は以下の節で構成されています。

- 節 7.1「Sash の概要」

- 節 7.2「Sash の起動」

- 節 7.3「Sash の使用方法」

- 節 7.4「ユーザの作成」

- 節 7.5「Sash を使用した XDMS のプロビジョニング」

- 節 7.6「Sash でのスクリプト作成」

- 節 7.7「Sash でのエラー ロギング」

7.1 Sash の概要

Sapphire Shell (Sash) は、Oracle Database、XDMS (XML Document Management Server)、および RADIUS サーバに OWLCS ユーザをプロビジョニングするためのコマンドライン ユーティリティです。Sash のコマンドライン プロンプト (sash#) から、または CommandService MBean を使用して、ユーザをプロビジョニングできます。

OWLCS デプロイメント用のユーザ プロビジョニング リポジトリとして Oracle Internet Database (OID) を使用する方法については、『Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory』を参照してください。

7.2 Sash の起動

Linux システムでは、OWLCS を起動および停止するスクリプトと同じフォルダに、Sash 起動スクリプト (sash.sh) があります。

7.2.1 コマンドラインからの Sash の起動

OWLCS では、コマンドラインから Sash を起動するための、次のようなショートカットが提供されています。

sash.sh (UNIX)

sash.bat (Windows)

このショートカットは、OWLCS インストール先の Oracle/Middleware/as11gr1wlcs1/communications/sash/bin にあります。

7.2.2 外部の OWLCS インスタンスへの Sash の接続

デフォルトでは、Sash は OWLCS のローカル インスタンスに接続します。必要に応じて、このデフォルト動作を無効にし、OWLCS の外部インスタンスまたは Oracle WebLogic Server の別のインスタンスに Sash を接続できます。

7.2.2.1 OWLCS の外部インスタンスへの接続

Sash は、RMI を通して OWLCS サーバに接続します。例 7-1 は、ホスト IP アドレスが 10.0.0.234 であるサーバに Sash を接続する方法を示しています。

例 7-1 OWLCS への Sash の接続

sash –-host 10.0.0.234

OWLCS に接続するときには、ユーザ名とパスワードの入力を求められます。ユーザ名は、OWLCS 管理者のユーザ名と同じです (OWLCSadmin)。パスワードも、OWLCS 管理者のパスワードと同じです。ログインに成功すると、Sash のコマンド プロンプト (sash) が表示されます。ログインに失敗すると、エラー メッセージが表示されます。

7.3 Sash の使用方法

Sash のコマンドは、2 つのグループに分かれています。1 つはシステム オブジェクトを作成、削除および更新するコマンドで、もう 1 つはシステムに情報を問い合わせるコマンドです。

注意 :
新しいアプリケーション使用方法を追加した場合、その新しいアプリケーション使用方法を使用するには、サーバを再起動する必要があります。
既存のアプリケーション使用方法を削除した場合、削除したアプリケーション使用方法を完全にアンロードするには、サーバを再起動する必要があります (つまり、削除したアプリケーション使用方法は、サーバが再起動されるまではロードされた状態のままであり、アンロードされると完全に使用不可になります)。

ファイル内の sash コマンドの前にスペースがある場合、そのファイルは sash コマンドへの入力として使用されても機能しません。sash 入力ファイルでは、sash コマンドの前のスペースを必ず削除してください。

7.3.1 使用できるコマンドの表示

help と入力すると、サーバで使用できるすべてのコマンドのリストが表示されます (表 7-1 を参照)。コマンドのリストは、サーバにデプロイされているコンポーネントによって異なります。

表 7-1 Sash のコマンド

コマンド

説明

エリアス

サブコマンド

privateIdentity

認証に使用するプライベート通信 ID を追加および削除するコマンドです。

なし

次のサブコマンドがあります。

- add – システムに新しいユーザを追加します。次に例を示します。
privateIdentity add privateId=alice

- delete – システムからユーザを削除します。次に例を示します。
privateIdentity delete privateId=alice

publicIdentity

プライベート ID に関連付けられたパブリック ID を追加および削除するコマンドです。

pubid

次のサブコマンドがあります。

- add – 特定のユーザに関連付けられたパブリック ID をシステムに追加します。次に例を示します。
publicIdentity add publicId=sip:alice@test.company.com privateId=alice

- delete – システムから通信 ID を削除します。次に例を示します。
publicIdentity delete publicId=sip:alice@test.company.com privateId=alice

account

ユーザ アカウント管理用のコマンドが含まれます。このコマンドを使用すると、アカウントを、アクティブ、ロック、または一時的アカウントとして設定できます。

なし

次のサブコマンドがあります。

- add – システムに新しいアカウントを追加します。構文は次のとおりです。
account add uid=<string> [active=<true|false>] [locked=<true|false>] [accountExpiresAt=<accountExpiresAt>] [tempAccount=<true|false>] [description=<string>] [lockExpiresAt=<lockExpiresAt>] [currentFailedLogins=<integer>]

例 : account add uid=alice active=true

- delete – システムからアカウントを削除します。例 : account delete uid=<string>

- update – アカウントを更新します。次に例を示します。
account update uid=<string> [active=<true|false>] [locked=<true|false>] [accountExpiresAt=<accountExpiresAt>] [tempAccount=<true|false>] [description=<string>] [lockExpiresAt=<lockExpiresAt>] [currentFailedLogins=<integer>]

- info – 特定のアカウントについての情報を取得します。例 : account info uid=<string>

role

システム内のロールの種類とユーザ ロールを管理します。role は、追加のセキュリティおよび認可メカニズムであり、sip.xml の <auth-cons raint> 要素で定義されます。このコマンドは、アプリケーションへのユーザ グループのアクセスを認可します。アプリケーションでは、特定のロールに関するチェックを行います。OWLCS では、Proxy Registrar アプリケーションに対して 1 つの Location Services ロールが定義されています。

なし

サブコマンドには role system と role user があります。

role system (role のサブコマンド)

ロールの種類を管理します。

なし

次のサブコマンドがあります。

- list – システム内のロールをリストします。次に例を示します。
role system list

- add – システムに新しいロールを追加します。次に例を示します。
role system add name=<string> [description=<string>]

- update – システム内のロールを更新します。次に例を示します。
role system update name=<string> [description=<string>]

- delete – システムからロールを削除します。次に例を示します。
role system delete name=<string> [description=<string>]

role user (role のサブコマンド)

ユーザ ロールを管理します。

なし

次のサブコマンドがあります。

- add – ユーザにロールを追加します。次に例を示します。
role user add uid=<string> name=<string>

- delete – ユーザからロールを削除します。次に例を示します。
role user delete uid=<string> name=<string>

- list – ユーザのロールをリストします。次に例を示します。
role user list uid=<string>

credentials

資格を管理するコマンドです。

なし

次のサブコマンドがあります。

- add – ユーザに資格を追加します。次に例を示します。
credentials add password=<string> realm=<string> uid=<string>

- addAll – システム内でコンフィグレーション済みのすべてのレルムに対する資格をユーザに追加します。次に例を示します。
credentials addAll password=<string> uid=<string>

- delete – ユーザのレルム資格を削除します。次に例を示します。
credentials delete realm=<string> uid=<string>

- deleteAll – ユーザのすべての資格を削除します。次に例を示します。
credentials deleteall uid=<string>

- update – ユーザの資格を更新します。次に例を示します。
credentials update password=<string> realm=<string> uid=<string>

- updateAll – システム内でプロビジョニング済みのすべてのレルムに対するユーザの資格を更新します。次に例を示します。
credentials updateAll password=<string> uid=<string>

- list – 特定のユーザに対する資格が存在するすべてのレルムをリストします。次に例を示します。
credentials list uid=<string>

identity add

ユーザの基本アカウントを作成できます。

なし

なし。「identity add コマンドによるユーザの作成」を参照してください。

7.3.1.1 サブコマンドの表示

特定のコマンドのサブコマンドを表示するには、help <command> と入力します。たとえば、account コマンドに対して help を入力すると (help account)、account コマンドで使用可能なサブコマンドの概要が表示されます (例 7-2 を参照)。

例 7-2 特定のコマンドのヘルプ情報の取得

*** Description ****
Contains commands for management of user accounts.
In an account you can set if the account is active,
locked or if it perhaps should be a temporarily account.

Aliases: [no aliases]

Syntax:
account

Sub-commands:
# Adds a new account to the system
account add uid=<string> [ active=<true|false> ] [ locked=<true|false> ] [ accountExpiresAt=<accountExpiresAt> ] [ tempAccount=<true|false> ] [ description=<string> ] [ lockExpiresAt=<lockExpiresAt> ] [ currentFailedLogins=<integer> ]

# Deletes an account
account delete uid=<string>

# Updates an account
account update uid=<string> [ active=<true|false> ] [ locked=<true|false> ] [ accountExpiresAt=<accountExpiresAt> ] [ tempAccount=<true|false> ] [ description=<string> ] [ lockExpiresAt=<lockExpiresAt> ] [ currentFailedLogins=<integer> ]

# Retrieve information about a particular account
account info uid=<string>

help <command> と入力して表示される情報には、コマンド グループの概要だけでなく、コマンドのエリアス (ある場合) も含まれます。たとえば、例 7-2 の account コマンドの概要では、[no aliase ] (エリアスなし) と示されています。

注意 :
account、role、role system、role user、privateIdentity、publicIdentity、および identity とともに使用する delete コマンドには、以下のエリアスがあります。

- remove

- del

- rm

コマンドの中には、パラメータを必要とするものがあります。たとえば、help role system add と入力すると、add コマンドにはロールの名前と、オプションで説明を設定するためのコマンドが必要であることが示されます。

role system add name=<string> [description=<string>]

注意 :
[description=<string>] のように、省略可能なコマンドは角括弧 [...] で囲まれています。

必須のパラメータを省略した場合、または認識できないパラメータを渡した場合は、警告が表示されます。

7.4 ユーザの作成

この節では、publicIdentity コマンドと privateIdentity コマンドについて、およびこれらと組み合わせて表 7-1 のサブコマンド add、account、role、および credentials を使用して、Oracle Database にユーザ アカウントをプロビジョニングする方法について説明します。

プライベート ID (privateIdentity) は、特定の認証レルム内のユーザを一意に識別します。パブリック ID (publicIdentity) は、デバイスを登録するためにユーザが入力する SIP アドレスです。このアドレスはユーザの AOR (Address of Record) であり、ユーザが相互に呼び出しを行う手段です。1 人のユーザが持つことのできるプライベート ID は 1 つだけですが、そのプライベート ID に対して複数のパブリック ID を関連付けることができます。

注意 :
サードパーティのデータベース (RADIUS など) に対する認証を有効にする場合、Proxy Registrar および認証が必要な他のアプリケーションが正しく機能するためには、認証データを含み外部に格納されるユーザ アカウントが、プライベート ID と一致している必要があります。

ユーザを作成するには、最初に privateIdentity コマンドと add privateId サブコマンドを使用してプライベート ID を作成することでシステムにユーザを追加した後、publicIdentity コマンドと add publicId サブコマンドを使用してユーザに対するパブリック ID を追加します。

ユーザのプライベート ID とパブリック ID を作成した後は、account add uid コマンドでユーザのアカウントを作成し、必要に応じてアカウントのステータス (アクティブやロックなど) を設定します。role コマンドは、ロールベースのパーミッションに対するロール メンバーシップを設定します。role コマンドを使用してユーザのパーミッションのレベルを設定した後、credentials コマンドでユーザのレルムとパスワードを定義してユーザの資格を設定します。

7.4.1 Sash コマンドライン プロンプトからのユーザの作成

この節では、表 7-1 で説明したコマンドを使用して alice という名前の OWLCS ユーザを作成することで、Sash コマンド プロンプト (sash#、例 7-3 を参照) からユーザを作成する方法を示します。

1. 次のようにして、privateIdentity コマンドを使用してユーザを作成します。

privateIdentity add privateId=alice

2. SIP アドレスを入力して alice のパブリック ID を作成します。

publicIdentity add publicId=sip:alice@test.company.com privateId=alice

3. alice のアカウントを追加し、表 7-1 で説明した省略可能なコマンドのいずれかを使用してアカウントのステータスを設定します。alice に対してアクティブなアカウントを作成するには、次のように入力します。

account add uid=alice active=true

注意 :
OWLCS バージョン 10.1.3.2 では、uid は小文字である必要があります。OWLCS バージョン 10.1.3.2 を使用してプロビジョニングされている Oracle Communicator ユーザも、ログイン時には小文字でアカウント名を入力する必要があります。OWLCS バージョン 10.1.3.3 および 10.1.3.4 では、大文字と小文字が混在した uid がサポートされています。ただし、Oracle Communicator ユーザがログインするには、プロビジョニングされたとおりにユーザ名を入力する必要があります。たとえば、uid が Alice と定義されているユーザは、Alice でログインする必要があります。10.1.3.2 でプロビジョニングされたユーザは、10.1.3.2 から 10.1.3.4 にアップグレードしても、引き続き小文字を使用してログインする必要があります。

4. role コマンドを使用して、Location Service ユーザ グループに alice を追加します。これにより、Proxy Registrar のロケーション サービス検索に対するパーミッションを alice に付与します。

role user add uid=alice name="Location Service"

5. alice のユーザ認証資格を追加します。

credentials add uid=alice realm=test.company.com password=welcome1

RADIUS ログイン モジュールを使用して RADIUS サーバに対してユーザを認証するようにコンフィグレーションされているアプリケーションの場合、credentials コマンドは必要ありません。これらのログイン モジュールの詳細については、第 5 章「セキュリティ機能の管理」を参照してください。

注意 :
Sash を使用してユーザに認証資格を追加する前に、SIP Servlet Container MBean を使用して realms をコンフィグレーションする必要もあります。

例 7-3 Sash コマンドライン プロンプトからのユーザの作成

sash# privateIdentity add privateId=alice
sash# publicIdentity add publicId=sip:alice@test.company.com privateId=alice
sash# account add uid=alice active=true
sash# role user add uid=alice name="Location Service"
sash# credentials add uid=alice realm=test.company.com password=welcome1

ヒント :
Sash バッチ ファイルを作成することで、複数のユーザを作成できます。詳細については、「Sash でのスクリプト作成」を参照してください。

7.4.2 Command Service MBean でのユーザの作成

Command Service MBean の execute 操作を使用して Sash のコマンドを実行できます。Command Service MBean は subscrdataservcommandsear アプリケーションで定義されています。

ユーザを作成するには、次の手順を実行します。

1. execute 操作を選択します。execute 操作の [操作] ページが表示されます。

2. [値] フィールドに privateIdentity add privateId=alice と入力します。

3. [起動操作] をクリックします。このプロセスをユーザ作成コマンドごとに繰り返します。たとえば、この後で publicIdentity コマンドと account コマンドを実行し、そのつど [起動操作] をクリックします。

7.4.3 identity add コマンドによるユーザの作成

identity add コマンドを使用すると、1 つのコマンド文字列でユーザを作成できます。このコマンドは、privateIdentity、publicIdentity、account、role、および credentials の各コマンドに対するエリアスであり、ユーザが SIP クライアント経由で OCMS に接続するために必要な最低限の情報を含む基本的なユーザ アカウントを簡単に作成できます。たとえば、このコマンドを使用してユーザ alice の基本アカウントを作成するには、コマンドラインから、または Command Service Mbean の execute 操作を使用して、次のように入力します。

identity add privateId=alice publicId=sip:sip.alice@company.com role="Location Service" realm=company.com password=welcome1

注意 :
RADIUS システムに対してユーザを認証するようにコンフィグレーションされているアプリケーション (セキュリティ プロバイダとして RADIUS ログイン モジュールを使用するアプリケーション) の場合は、ユーザ アカウントを作成するコマンドは次のようになります。

identity add privateId=alice publicId=sip:sip.alice@company.com role="Location Service"

identity add コマンドを使用して作成できるのは、基本ユーザ アカウントのみです。複数の publicId を単一の privateId と関連付けるような複雑な構成を必要とするアカウントの場合は、例 7-3 で示されているように、複数の Sash コマンドを使用して作成する必要があります。

7.4.3.1 identity delete コマンドによるユーザ アカウントの削除

identity delete コマンドを使用すると、単一のコマンド文字列で、ユーザのロール、資格、アカウント情報、パブリック ID とプライベート ID のすべてを削除できます。たとえば、このコマンドを使用してユーザ alice のアカウントを削除するには、コマンドラインから、または Command Service Mbean の execute 操作を使用して、次のように入力します。

identity delete privateId=alice

7.5 Sash を使用した XDMS のプロビジョニング

XDMS をプロビジョニングするためのコマンドは、xcap グループに含まれます。これらの各コマンドの前には xcap が付きます。ユーザのプロビジョニングをサポートする xcap グループの XDMS コマンドは、user サブグループと applicationUsage サブグループに含まれます。XDMS のプロビジョニングは、Sash プロンプトから、または Presence アプリケーションで提供されている CommandService MBean を使用して行うことができます。

7.5.1 CommandService MBean を使用した XDMS ユーザ アカウントのプロビジョニング

Presence アプリケーションに登録された CommandService MBean で提供されている execute コマンドを使用して、XDMS をプロビジョニングすることができます。XDMS にアカウントをプロビジョニングするには、「Command Service MBean でのユーザの作成」で説明されている CommandService MBean の execute 操作を使用します。MBean 自体の詳細については、「Command Service (XDMS プロビジョニング)」を参照してください。

7.5.2 Sash プロンプトからの XDMS ユーザ アカウントのプロビジョニング

XDMS コマンドを使用して Sash プロンプトからユーザおよびアプリケーション使用方法をプロビジョニングするには、最初に Presence などの XMDS 利用アプリケーションに接続する必要があります。

Windows システムの場合、コマンド プロンプトから次のように入力します。

launch_sash.bat -a <application name>

Linux の場合、次のように入力します。

launch_sash.sh -a <application name>

たとえば、Windows システムで Presence アプリケーションに接続するには、次のようにします。

1. コマンド プロンプトで、Sash の実行可能ファイルが格納されている sbin ディレクトリに移動します。このファイルは MIDDLEWARE_HOME/as11gr1wlcs/communications/sash/sbin にあります。

2. sash.bat -a presenceapplication を使用して、Presence アプリケーションの名前を入力します。

3. プロンプトが表示されたら、OWLCS 管理者の名前とパスワードを使用して Sash にログインします。

4. Sash のコマンド プロンプトから、xcap user list などの XDMS コマンドを入力します。

7.5.3 xcap コマンドの使用

この節では、xcap グループのコマンドを使用してユーザ アカウントとアプリケーション使用方法を管理する方法について説明します。

7.5.3.1 XDMS ユーザ アカウントのプロビジョニング

add、delete、list の各コマンドを使用して、XDMS のユーザ アカウントを管理できます。

7.5.3.2 XDMS ユーザの追加

xcap user add コマンドは、指定したユーザ名とアプリケーション使用方法で XDMS ユーザを追加します。たとえば、Sash プロンプトからユーザを追加するには、次のように入力します。

sash# xcap user add userName=<string> appusage=<string>

注意 :
自動的にユーザを作成するように XDMS がコンフィグレーションされている場合は、add コマンドを使用しないでください。XCAP のコンフィグレーションの詳細については、節 9.2.9「XCapConfigManager」を参照してください。

7.5.3.3 XDMS ユーザの削除

xcap user delete コマンドは、指定したユーザ名の XDMS ユーザ (およびすべての既存ドキュメント) をアプリケーション使用方法から削除します。たとえば、Sash プロンプトからユーザを削除するには、次のように入力します。

sash# xcap user delete userName=<string> [ appusages=<string> ]

アプリケーション使用方法のパラメータ (appusages) は省略可能です。アプリケーションの使用方法を指定しないと、ユーザはすべてのアプリケーション使用方法から削除されます。

7.5.3.4 XDMS ユーザのアプリケーション使用方法の検索

xcap user appusages コマンドは、指定したユーザに該当するすべてのアプリケーション使用方法を返します。ユーザに割り当てられているアプリケーション使用方法を確認するには、Sash プロンプトから次のように入力します。

sash# xcap user appusages userName=<string>

7.5.3.5 XDMS ユーザのリスト表示

xcap user list コマンドは、システム内のすべての XDMS ユーザを返します。オプションを指定して、特定のアプリケーション使用方法に対する XDMS ユーザのみを取得することもできます。

sash# xcap user list [ all=<true|false> ] [ appusage=<string> ]

省略可能な all パラメータを設定しないと、結果の表示は最大 100 ユーザに限定されます。

7.5.3.6 アプリケーション使用方法のプロビジョニング

XDMS アプリケーション使用方法のプロビジョニングのためのコマンドは、appusage グループ (xcap appusage) のものです。resource-lists_au.xml、pidfmanipulation_au.xml、および presrules_au.xml という 3 種類のアプリケーションがサポートされています。

アプリケーション使用方法を追加するための SASH コマンドは、次のようになります。

xcap appusage create appusage=<application_usage> configurationFilename=<application>_au.xml

3 種類のアプリケーションを次の表に示します。

表 7-2 サポートされているアプリケーションの種類

applicationUsage

configurationFilename

resource-lists

resource-lists_au.xml

pidf-manipulation

pidfmanipulation_au.xml

pres-rules

presrules_au.xml

7.5.3.7 すべてのアプリケーション使用方法のリスト表示

xcap appusage list コマンドは、サーバ上のすべてのアプリケーション使用方法を返します。たとえば、Sash プロンプトから次のように入力します。

sash# xcap appusage list

7.6 Sash でのスクリプト作成

複数の操作を含む、よく実行されるタスクのためのスクリプトを作成できます。Sash を起動して、コマンドのリストを含むファイルを実行できます。スクリプトを有効にするために、Sash では次のようなコマンドライン フラグが提供されています。

- -- exec (短縮名 : -e) : こ コマンドライン フラグの後に引用符で囲んだコマンドがある場合、Sash はそのコマンドを実行して終了します。

- -- file (短縮名 : -f) : このコマンドライン フラグの後にファイル名がある場合、Sash はそのファイルを読み取り、入力された場合と同じようにファイル内のすべてのコマンドを実行し、終了します。
例 7-4 は、identity add コマンドで定義されているユーザのグループを含む ocsm_users.txt という名前のテキスト ファイルです。Sash プロンプトから -f OWLCS_users.txt と入力することで、これらのユーザをプロビジョニングできます。

例 7-4 テキスト ファイル (OWLCS_users.txt) からのユーザの作成

identity add privateId=candace publicId=sip:candace@doc.oracle.com role=user password=1234 realm=doc.oracle.com
identity add privateId=deirdre publicId=sip:deirdre@doc.oracle.com role=user password=1234 realm=doc.oracle.com
identity add privateId=evelyn publicId=sip:evelyn@doc.oracle.com role=user password=1234 realm=doc.oracle.com
identity add privateId=frank publicId=sip:frank@doc.oracle.com role=user password=1234 realm=doc.oracle.com

- -- nonewline : このコマンドライン フラグは、実行されたコマンドから返されるメッセージから改行を取り除くことで、出力を解析しやすくします。このコマンドを使用すると解析は容易になりますが、手動でメッセージを読むのは難しくなります。

7.7 Sash でのエラー ロギング

Sash はいずれのファイルにもログを記録しません (デフォルト コンフィグレーション)。コンソールのみにメッセージを出力します。Sash のログ レベルは、$ORACLE _HOME/as11gr1wlcs1/communications/sash/conf でコンフィグレーションされます。

8 モニタとトラブルシューティング

以下の節では、Oracle WebLogic Communication Services の「エコー サーバ」プロセスをコンフィグレーションし、サーバがネットワークから物理的に切断された場合の SIP データ層のフェイルオーバ パフォーマンスを向上させる方法について説明します。

- 節 8.1「サーバ障害の回避とサーバ障害からの回復」

- 節 8.2「フェイルオーバ検出の概要」

- 節 8.3「物理的なネットワーク障害に対するフェイルオーバ パフォーマンスの向上」

- 節 8.4「SNMP のコンフィグレーション」

- 節 8.5「SNMP トラップの概要と対処法」

- 節 8.6「WebLogic 診断フレームワーク (WLDF) の使用」

- 節 8.7「SIP リクエストと応答のロギング」

- 節 8.8「プロダクション デプロイメントにおける JVM ガベージ コレクションのチューニング」

- 節 8.9「乱数生成に伴う JVM の遅延の回避」

8.1 サーバ障害の回避とサーバ障害からの回復

サーバ インスタンスの障害は、さまざまな出来事によって引き起こされます。1 つの障害が別の障害のきっかけになることも少なくありません。停電、ハードウェアの故障、オペレーティング システムのクラッシュ、ネットワーク パーティション、アプリケーションの予期しない動作は、いずれもサーバ インスタンスの障害の一因になり得ます。

Oracle WebLogic Communication Services では、障害発生時の影響を最小限に抑えるための基盤として、高度にクラスタ化されたアーキテクチャを使用しています。ただし、個々のサーバまたはサーバ マシンに障害が発生した場合にそなえて、クラスタ環境でも適切な回復プロセスを用意しておく必要があります。

以下の節では、Oracle WebLogic Communication Services の障害回避機能と回復機能をまとめたものであり、Oracle WebLogic Communication Services ドメインのさまざまな部分を復元するため必要なコンフィグレーション アーティファクトを説明します。

8.1.1 障害回避機能と自動回復機能

Oracle WebLogic Communication Services およびその基盤である WebLogic Server プラットフォームでは、サーバを障害から保護する多くの機能を提供します。プロダクション システムでは、継続的なサービスを保証するためにすべての利用可能な機能を使用する必要があります。

8.1.1.1 オーバーロード保護

Oracle WebLogic Communication Services は、デプロイ済み SIP Servlets のパフォーマンスと安定性に影響を及ぼすおそれのあるシステム負荷の増加を検出し、あらかじめ定義された負荷のしきい値に達するとメッセージの処理を自動的に規制します。

オーバーロード保護を使用すると、予期しないレベルのアプリケーション トラフィックやリソース使用率が原因で発生する障害を回避することができます。

Oracle WebLogic Communication Services は、以下のような特定の状況が発生したときに障害の回避を試みます。

- SIP セッションの作成レートがコンフィグレーション済みの値に達したとき

- SIP タイマーおよび SIP リクエスト処理実行キューのサイズがコンフィグレーション済みの値に達したとき

基盤となる WebLogic SIP Server プラットフォームは、デプロイ済みアプリケーションのパフォーマンスと安定性に影響を及ぼすおそれのあるシステム負荷の増加を検出します。WebLogic Server ではあらかじめ定義されたロードのしきい値で自動的に発生する障害回避アクションのコンフィグレーションを管理者に許可します。自動オーバーロード保護を使用すると、予期しないレベルのアプリケーション トラフィックやリソース使用率が原因で発生する以下のような障害を回避することができます。

- 作業負荷マネージャがキャパシティを超過

- HTTP セッション数があらかじめ定義されたしきい値まで増加

- 差し迫ったメモリ不足

8.1.1.2 クラスタ化されたサービスの冗長性とフェイルオーバ

専用のクラスタで複数のエンジン層サーバを使用すると共に、専用の SIP データ層クラスタで複数の SIP データ層サーバ (レプリカ) を使用することにより、アプリケーションの信頼性と可用性を向上させることができます。エンジン層クラスタは SIP ダイアログ (呼) に関するステートフルな情報を保持しないので、エンジン層サーバで障害が起きてもデータが失われたり呼が切断されたりすることはありません。SIP データ層パーティションの複数のレプリカには呼状態情報の冗長コピーが保存され、1 つのレプリカで障害が起きると相互に自動的にフェイルオーバされます。

8.1.1.3 障害が発生したサーバ インスタンスの自動的な再起動

WebLogic Server の自己管理モニタ機能はドメイン内のサーバ インスタンスの信頼性と可用性を向上させます。各サーバ インスタンス内の選択されたサブシステムは、そのサブシステムに特定の条件に基づいて状態をモニタします (たとえば、JMS サブシステムは JMS スレッド プールの状態をモニタし、コア サーバ サブシステムはデフォルトおよびユーザ定義実行キューの統計をモニタします)。あるサブシステムが一貫した信頼のおける方法で動作しないと判断された場合、その状態がホスト サーバに「failed」として登録されます。

次に各 WebLogic Server インスタンスは、全体的に稼動が可能であるか判断するために、登録されたサブシステムの状態をチェックします。1 つまたは複数の必須のサブシステムが FAILED 状態に達した場合、サーバ インスタンスはアプリケーションを確実にホストできないことを示すためにそれ自体の状態を FAILED にマークします。

ノード マネージャと組み合わせて使用すると、サーバの自動状態モニタ機能で、障害が発生したサーバを自動的に再起動することができます。これにより、ドメインの全体的な信頼性が向上し、管理者による直接の操作が不要になります。

8.1.1.4 管理対象サーバ独立モード

管理対象サーバは、ドメイン コンフィグレーションのローカル コピーを保持しています。起動時に、管理対象サーバは管理サーバに接続し、自身が最後に停止してからドメイン コンフィグレーションに加えられた変更を取得します。起動時に管理サーバに接続できない場合は、ローカルにキャッシュされたコンフィグレーション情報を使用します。この情報は、管理対象サーバが最後に停止した時点で最新だったコンフィグレーションです。管理サーバに接続してコンフィグレーションの更新情報をチェックせずに起動した管理対象サーバは、「管理対象サーバ独立 (MSI)」モードで実行されます。デフォルトでは、MSI モードは有効になっています。

8.1.1.5 障害が発生した管理対象サーバの自動移行

Linux または UNIX オペレーティング システムを使用している場合、ネットワーク層サーバのマシンに障害が発生した場合やネットワークからパーティションされた場合に自動的に候補 (バックアップ) サーバを起動するため、WebLogic Server のサーバ移行機能を使用することができます。サーバ移行機能はノード マネージャを wlsifconfig.sh wlsifconfig.sh スクリプトと組み合わせて使い、浮動 IP アドレスを使用して自動的に候補サーバを起動します。 ネットワーク層インスタンスをホストするプライマリ サーバにアクセスができなくなった場合のみ、候補サーバが起動されます。サーバ移行機能の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』ドキュメントの「Whole Server Migration」を参照してください。

8.1.1.6 地域サイトの障害に対応する地理的冗長性

サーバ レベルの冗長性およびフェイルオーバの機能に加え、Oracle WebLogic Communication Services では、ドメイン全体に影響を及ぼす停電などの破滅的な障害を防ぐためにピア サイトもコンフィグレーションできます。これにより、サービスが完全に停止されることなく、地理的なサイト間でフェイルオーバすることができます。

8.1.2 障害回復のためのディレクトリとファイルのバックアップ

サーバ インスタンスの障害から回復するには、ドメインのコンフィグレーション データにアクセスする必要があります。デフォルトでは、管理サーバはドメインのプライマリ コンフィグレーション データを domain_name/config/config.xml というファイルに保存します。ここで、domain_name はドメインのルート ディレクトリです。一次コンフィグレーション ファイルは、JDBC や JMS など特定の WebLogic Server サービス、および SIP コンテナ プロパティや SIP データ層コンフィグレーションなどの Oracle WebLogic Communication Services サービスに対して、追加コンフィグレーション ファイルを参照する可能性があります。特定のサービス用コンフィグレーションは、domain_name/config ディレクトリのサブディレクトリ内の追加 XML ファイルに保存されます。たとえば、Oracle WebLogic Communication Services コンフィグレーション ファイルの domain_name/config/jms、domain_name/config/jdbc、domain_name/config/custom などです。

管理サーバはドメイン コンフィグレーションの複数のバージョンを自動的にアーカイブすることができます (domain-name/config ディレクトリ全体)。偶発的に変更されたコンフィグレーションを元に戻す必要がある場合、システムを復旧するためにコンフィグレーション アーカイブを使用することができます。たとえば、管理者がコンフィグレーションされたリソースを誤って削除した場合、最後に行われた自動バックアップを使用して以前のコンフィグレーションを復元することができます。

管理サーバは domain_name/config でローカル的に有限数の自動化されたバックアップだけを保存します。このため、ハードディスクに障害が発生した場合などのデータ破損に対処できる自動ドメイン バックアップの機能は限られています。自動バックアップでも、LDAP リポジトリ データおよびサーバ起動スクリプトなど、ドメインを完全に回復するために必要なコンフィグレーションデータは保持されません。コンフィグレーションとセキュリティの複数のバックアップ コピーをオフラインでソース コントロール システムに維持しておくことをお勧めします。

ここでは、Oracle WebLogic Communication Services で自動的に実行されるファイルのバックアップ、および管理者が定期的に実行する手動のバックアップ手順について説明します。

8.1.2.1 自動コンフィグレーションのバックアップの有効化

ドメインの管理サーバ上で、自動ドメイン コンフィグレーション バックアップを有効するには、以下の手順に従います。

1. ドメインの Administration Console にアクセスします。

2. Administration Console の左ペインで、ドメイン名を選択します。

3. 右ペインで、[コンフィグレーション｜一般] タブをクリックします。

4. [詳細] を選択して、詳細なオプションを表示します。

5. [コンフィグレーション アーカイブを有効化] を選択します。

6. [アーカイブ コンフィグレーション数] ボックスに、保存するコンフィグレーション ファイル リビジョンの最大数を入力します。

7. [保存] をクリックします。

コンフィグレーション アーカイブを有効にすると、管理サーバではコンフィグレーション JAR ファイル アーカイブが自動的に作成されます。JAR ファイルには前のコンフィグレーションの完全なコピー (domain-name\config ディレクトリのすべてのコンテンツ) が含まれています。 JAR ファイルのアーカイブ ファイルは domain-name\configArchive ディレクトリに格納されています。 ファイルは命名規則 config-number.jar を使用します。number はアーカイブの連番です。

ドメインのコンフィグレーションに対する変更を保存すると、管理サーバは変更前のコンフィグレーションを domain-name\configArchive\config.xml#n に保存します。 管理サーバが configArchive ディレクトリにファイルを保存するたびに、#n サフィックスの値が、コンフィグレーション可能なコピーの数 (デフォルトでは 5) になるまで増えていきます。 それ以降は、ドメインのコンフィグレーションを変更するたびに、以下のような処理が行われます。

- アーカイブ済みのファイルが循環し、最新のファイルに最も大きい番号のサフィックスが付けられます。

- 以前にアーカイブされたファイルの名前に付いた番号は 1 つずつ小さくなります。

- 最も古いファイルが削除されます。

コンフィグレーション アーカイブはドメイン ディレクトリ内にローカルに格納されるので、選択した最大改訂数を超えると上書きされることに注意してください。このため、節 8.1.2.2「ドメインのコンフィグレーション オフラインの格納」で説明するように、ドメイン コンフィグレーションの独自のオフライン アーカイブも作成する必要があります。

8.1.2.2 ドメインのコンフィグレーション オフラインの格納

自動バックアップにより偶発的なコンフィグレーションへの変更は防止できますが、ドメイン コンフィグレーションを格納するハード ディスクの障害によって発生するデータ損失やドメイン ディレクトリの偶発的削除は防げません。これらの障害から保護するには、ソース コントロール システムでドメイン コンフィグレーション オフライン全体のコピーも格納する必要があります。

定期的にドメイン コンフィグレーションのコピーを保存することをお勧めします。たとえば、次の場合には、コンフィグレーションの最新の改訂をバックアップします。

- プロダクション システムを最初にデプロイした場合

- デプロイされたアプリケーションを追加または除去した場合

- コンフィグレーションをパフォーマンスを向上させるためにチューニングした場合

- その他の恒久的な変更を行った場合

ドメイン コンフィグレーションのバックアップには、domain_name/config ディレクトリのすべてのコンテンツを含める必要があります。 次に例を示します。

cd ~/user_projects/domains/mydomain
tar cvf domain-backup-06-17-2007.jar config

ソース コントロール システムで新しいアーカイブを格納する場合、過去のある時点のドメイン コンフィグレーションを回復するために必要な以前のバージョンを保存します。

8.1.2.3 サーバ起動スクリプトのバックアップ

Oracle WebLogic Communication Services デプロイメントでは、一般にエンジン層サーバおよび SIP データ層サーバの起動に使われる起動スクリプトをカスタマイズし、次のようなドメイン固有のコンフィグレーション情報を指定します。

- SIP メッセージ処理のスループット目標を実現するために必要な JVM ガベージ コレクションのパラメータ (節 8.8「プロダクション デプロイメントにおける JVM ガベージ コレクションのチューニング」を参照)。エンジン層サーバと SIP データ層サーバの起動には、普通は別々のパラメータが (したがって別々の起動スクリプトが) 使用されます。

- Oracle WebLogic Communication Services ハートビート メカニズムのコンフィグレーション パラメータおよび起動情報。ハートビート メカニズムを使用する場合は、エンジン層サーバの起動スクリプトで、ハートビート メカニズムの有効化およびコンフィグレーションを行う起動オプションを指定します。SIP データ層サーバの起動スクリプトでは、ハートビートを有効化して WlssEchoServer プロセスを起動する起動オプションを指定します。

ドメイン内のエンジン層サーバ、SIP データ層サーバ、または Diameter リレー サーバの起動に使われる個別の起動スクリプトをバックアップします。

8.1.2.4 ロギング サーブレット アプリケーションのバックアップ

Oracle WebLogic Communication Services ロギング サーブレット (節 8.7「SIP リクエストと応答のロギング」を参照) を使用して SIP メッセージの定期的なロギングや監査を行う場合は、アプリケーションのソース ファイル全体をバックアップし、ステージング サーバで障害が発生した場合や元のデプロイメント ディレクトリが破損した場合にアプリケーションを簡単に再デプロイできるようにします。

8.1.2.5 セキュリティ データのバックアップ

WebLogic Security サービスは、コンフィグレーション データを config.xml ファイルに保存し、さらに LDAP リポジトリや他のファイルにも保存します。

8.1.2.5.1 SerializedSystemIni.dat とセキュリティ証明書のバックアップ

すべてのサーバは SerializedSystemIni.dat という名前のファイルを作成し、サーバのルート ディレクトリに保存します。このファイルには、サーバの起動時に必要な暗号化されたセキュリティ データが記載されています。このファイルをバックアップする必要があります。

サーバで SSL を使用する場合は、セキュリティ証明書とキーもバックアップします。これらのファイルの場所はユーザがコンフィグレーションできます。

8.1.2.5.2 WebLogic LDAP リポジトリのバックアップ

Oracle WebLogic Communication Services と共にインストールされるデフォルトの認証プロバイダ、認可プロバイダ、ロール マッピング プロバイダ、および資格マッピング プロバイダは、自身のデータを LDAP サーバに保存します。各 Oracle WebLogic Communication Services には、組み込み LDAP サーバがあります。管理サーバにはマスター LDAP サーバがあり、このサーバがすべての管理対象サーバにレプリケートされます。セキュリティ レルムでこれらのインストール済みのプロバイダを使用する場合は、次のディレクトリ ツリーの最新のバックアップを保持しておく必要があります。

domain_name\adminServer\ldap

domain_name はドメインのルート ディレクトリ、adminServer は管理サーバが実行時データやセキュリティ データを保存するディレクトリです。

LDAP ディレクトリは各 Oracle WebLogic Communication Services にありますが、バックアップする必要があるのは管理サーバの LDAP データだけです。セキュリティ データに対する更新があると、マスター LDAP サーバは各管理対象サーバの LDAP データをレプリケートします。WebLogic セキュリティ プロバイダは、ドメインの管理サーバが利用不能の間はセキュリティ データを変更できません。管理対象サーバの LDAP リポジトリはレプリカであり、変更はできません。

ldap/ldapfiles サブディレクトリには、LDAP サーバのデータ ファイルがあります。 このディレクトリ内のファイルには、ユーザ、グループ、グループ メンバシップ、ポリシー、およびロールの情報が定義されています。ldap ディレクトリの下の他のサブディレクトリには、LDAP サーバのメッセージ ログや、レプリケートされた LDAP サーバに関するデータが含まれています。

LDAP データのバックアップが行われている間は、セキュリティ プロバイダのコンフィグレーションを更新しないでください。ldap ディレクトリ ツリーをバックアップしている最中に、たとえば管理者がユーザを追加するなどしてコンフィグレーションを変更すると、ldapfiles サブディレクトリ内のバックアップの整合性が損なわれるおそれがあります。このような事態が生じた場合は、整合性が確保された、ただし最新でない可能性のある LDAP のバックアップを利用できます。

1 日に一度、サーバは書き込み処理を一時停止し、LDAP データの独自のバックアップを作成します。このバックアップは ldap\backup ディレクトリの下の ZIP ファイルにアーカイブされ、その後、書き込み処理が再開されます。このバックアップは整合性が確保されていますが、セキュリティ データが最新でない可能性があります。

8.1.2.6 その他のオペレーティング システムのコンフィグレーション ファイルのバックアップ

オペレーティング システム レベルで保持される特定のファイルも、システム障害からの回復において非常に重要な役割を果たします。システムの必要に応じて、以下の情報をバックアップすることを検討してください。

- ロード バランサのコンフィグレーション スクリプト。たとえば、エンジン層クラスタのロード バランサ プールと仮想 IP アドレス、および NAT コンフィグレーションの設定をコンフィグレーションするために使われる自動化スクリプト。

- エンジン層サーバと SIP データ層サーバのシステム時計を同期するために使われる NTP クライアントのコンフィグレーション スクリプト。

- 各 Oracle WebLogic Communication Services マシンのホスト コンフィグレーション ファイル (ホスト名、マルチホーム マシンの仮想 IP アドレスと実際の IP アドレス、IP ルーティング テーブルの情報)。

8.1.3 障害の発生した管理サーバの再起動

障害が発生した管理サーバを再起動するときに、特別な手順に従う必要はありません。通常どおりの方法で管理サーバを起動してください。

管理対象サーバの実行中に管理サーバが停止した場合、ドメインの管理を回復するために、実行されている管理対象サーバを再起動する必要はありません。アクティブなドメインの管理を回復する手順は、ドメインの開始時に実行されていたのと同じマシンで管理サーバを再起動できるかどうかによって異なります。

8.1.3.1 同じマシンでの管理サーバの再起動

管理対象サーバの実行中に WebLogic 管理サーバを再起動した場合、デフォルトでは、管理サーバは実行中の管理対象サーバの存在を検出することができます。

注意 :
起動コマンドまたは起動スクリプトで -Dweblogic.management.discover=false を指定しないでください。このオプションを指定すると、管理サーバは実行中の管理対象サーバを検出しなくなります。

ドメインのルート ディレクトリに running-managed-servers.xml というファイルがあり、このファイルにドメイン内の管理対象サーバのリストと、それらのサーバが実行中かどうかの情報が記載されています。管理サーバは再起動するときにこのファイルをチェックし、停止前に自身の管理下にあった管理対象サーバを確認します。

管理対象サーバが正常に、または強制的に停止されると、running-managed-servers.xml ファイル内のそのサーバのステータスが「not-running」に更新されます。管理サーバは再起動するときに、「not-running」ステータスの管理対象サーバの検出を試みません。システム クラッシュによって停止した管理対象サーバ、あるいはサーバを実行中の JVM またはコマンド プロンプト (シェル) が強制終了したために停止した管理対象サーバは、running-managed-servers.xml のステータスが「running」のままになります。管理サーバはそれらのサーバの検出を試みて、当該サーバがもはや実行されていないと判断すると例外を送出します。

管理サーバを再起動しても、管理対象サーバは静的な属性のコンフィグレーションを更新しません。「静的な属性」とは、サーバが起動処理時にのみ参照する属性です。静的なコンフィグレーション属性に対する変更を反映するには、サーバ インスタンスを再起動する必要があります。管理対象サーバの検出では、管理サーバは管理対象サーバをモニタするか、サーバの実行中にコンフィグレーションできる属性 (動的な属性) を実行時に変更することのみが可能です。

8.1.3.2 別のマシンでの管理サーバの再起動

マシンがクラッシュし、同じマシンで管理サーバを再起動できない場合は、実行中の管理対象サーバの管理を次のような方法で回復できます。

1. 新しい管理用マシンに Oracle WebLogic Communication Services ソフトウェアをインストールします (まだインストールしていない場合)。

2. アプリケーション ファイルをバックアップからコピーするか、共有ディスクを使用して、新しい管理サーバから利用できるようにします。新しいファイル システムでも、元の管理サーバのときと同じ相対位置でアプリケーション ファイルにアクセスできるようにする必要があります。

3. コンフィグレーション データおよびセキュリティ データをバックアップからコピーするか、共有ディスクを使用して、新しい管理サーバから利用できるようにします。詳細については、節 8.1.2.2「ドメインのコンフィグレーション オフラインの格納」および節 8.1.2.5「セキュリティ データのバックアップ」を参照してください。

4. 新しいマシンで管理サーバを再起動します。
起動コマンドまたは起動スクリプトで -Dweblogic.management.discover=false を指定しないでください。このオプションを指定すると、管理サーバは実行中の管理対象サーバを検出しなくなります。

起動時に、管理サーバは管理対象サーバと通信し、管理サーバが異なる IP アドレスで実行されていることを通知します。

8.1.4 障害の発生した管理対象サーバの再起動

障害が発生した管理サーバが実行しているマシンは、ドメインの管理サーバと連絡を取ることができる場合は、ノード マネジャーを使用して管理対象サーバを手動または自動で再起動することができます。自動化された再起動をサポートするため、ノード マネージャと管理対象サーバをコンフィグレーションする必要があります。

起動時に管理サーバに接続できない場合、管理対象サーバはローカルにキャッシュされたコンフィグレーション データを読み込み、コンフィグレーションを取得することができます。この方法で起動した管理対象サーバは、管理対象サーバ独立 (MSI) モードで実行されます。

管理対象サーバを MSI モードで起動するには、次の手順に従います。

1. 管理対象サーバのルート ディレクトリに以下のファイルがあることを確認します。

- msi-config.xml

- SerializedSystemIni.dat

- boot.properties

管理対象サーバのルート ディレクトリにこれらのファイルがない場合は、次の手順に従います。

1. config.xml および SerializedSystemIni.dat ファイルを管理サーバのルート ディレクトリ (またはバックアップ) から管理対象サーバのルート ディレクトリにコピーします。

2. コンフィグレーション ファイルの名前を msi-config.xml に変更します。サーバを起動すると、コピーしたコンフィグレーション ファイルが使用されます。

注意 :
-Dweblogic.RootDirectory=path 起動オプションを使用して、これらのファイルが置かれているルート ディレクトリを指定する方法もあります。

2. コマンドラインまたはスクリプトを使用して管理対象サーバを起動します。
管理対象サーバは、管理サーバからの接続があるまで MSI モードで実行されます。この状況での管理サーバの再起動については、節 8.1.3「障害の発生した管理サーバの再起動」を参照してください。

8.2 フェイルオーバ検出の概要

プロダクション システムでは、エンジン層サーバは SIP データ層のレプリカに頻繁にアクセスし、呼状態データの取得および書き込みを行います。Oracle WebLogic Communication Services アーキテクチャでは、SIP データ層サーバの障害や切断の検出がエンジン層ノードに任されています。レプリカが利用不能となり、呼状態データにアクセスも書き込みもできなくなると、エンジンは同じパーティション内の別のレプリカに接続し、オフライン状態にあるサーバのことを報告します。レプリカは SIP データ層の現在のビューを更新し、オフライン状態にあるサーバをビューに反映させます。他のエンジンは呼状態データにアクセスしてデータを取得するときに、この更新されたビューの情報を受け取ります。

デフォルトでは、エンジン層サーバはレプリカに対する RMI 接続を使用して、レプリカで障害が発生したのか、ネットワークから切断されたのかを判断します。RMI 接続の障害を判断するために使われるアルゴリズムは、信頼性は高いものの、最終的には TCP プロトコルの再送信タイマーを利用して切断を診断します (たとえば、レプリカへのネットワーク ケーブルが外れているかどうか)。一般に、TCP の再送信タイマーは丸 1 分間以上持続するため、Oracle WebLogic Communication Services には障害を検出するための別の方法が用意されています。この方法では、切断されたレプリカをわずか数秒で診断することができます。

8.2.1 WlssEchoServer による障害検出

WlssEchoServer は、SIP データ層のレプリカと同じサーバ ハードウェア上で実行できる独立したプロセスです。WlssEchoServer の目的は、たとえばネットワーク ケーブルが切断された場合に SIP データ層サーバがオフライン状態になったことを判断できるように、簡単な UDP エコー サービスをエンジン層ノードに提供することです。WlssEchoServer を使って障害を検出するためのアルゴリズムは次のようなものです。

1. 通常のすべてのトラフィックについては、エンジン層サーバは TCP を使用して SIP データ層のレプリカと通信します。WlssEchoServer を使用しているかどうかにかかわらず、エンジン層と SIP データ層の間の基本トランスポートには TCP が使用されます。

2. エンジン層サーバは、コンフィグレーションされた各 WlssEchoServer に対し、UDP を介してハートビート メッセージを定期的に送信します。通常の運用時には、WlssEchoServer はハートビートに応答し、それによってエンジン ノードとレプリカの間の接続が確認されます。

3. SIP データ層スタックで全面的な障害が発生した場合、またはネットワーク ケーブルが切断された場合は、ハートビート メッセージがエンジン ノードに返されません。このような場合、エンジン ノードは通常の TCP 接続タイムアウトを待たずに、レプリカをオフライン状態と見なすことができます。

4. オフライン状態にあるサーバを特定した後、エンジン ノードは利用可能な SIP データ層のレプリカに障害を報告し、前の節で説明したように SIP データ層のビューが更新されます。

また、SIP データ層サーバが、自身のローカル WlssEchoServer プロセスが停止したことを検出すると、そのサーバは自動的に停止します。この動作により、節 8.2「フェイルオーバ検出の概要」で説明したエンジン ノードによる障害の検出と報告が不要になるため、フェイルオーバの時間がさらに短縮されます。

エンジン層サーバでハートビート メカニズムをコンフィグレーションし、必要に応じてフェイルオーバ検出のパフォーマンスを向上させることができます。また、WlssEchoServer がデータ層サーバ上で使用するリスン ポートとログ ファイルをコンフィグレーションすることもできます。

8.2.2 障害が発生したレプリカの強制的な停止

別のエンジン層サーバが特定のレプリカで交信することができない場合、エンジンは SIP データ層でオフライン サーバを報告するために、別の利用可能なレプリカにアクセスします。レプリカは、影響を受けるパーティションのビューを更新してオフラインサーバを削除します。次に更新されたビューはその後パーティションにアクセスするすべてのエンジン層サーバに配布されます。このようにビューを伝播することで、エンジン サーバのオフライン レプリカへのアクセスを防止することができます。

ビューを更新するレプリカは、オフライン レプリカに停止を求めるリクエストを 1 回のみ行ないます。これにより、ネットワーク故障のために 1 つまたは複数のエンジン サーバがアクセスできない実行中のレプリカ サーバを停止することができます。アクティブなレプリカが「オフライン」状態のレプリカに達した場合は、オフライン レプリカは停止します。

8.3 物理的なネットワーク障害に対するフェイルオーバ パフォーマンスの向上

注意 :
Oracle WebLogic Communication Services のすべてのインストール環境で WlssEchoServer を使用する必要はありません。エコー サーバは、コンフィグレーションされた TCP タイムアウト間隔より速くネットワークやレプリカの障害を検出する必要がある場合にのみ有効にしてください。

WlssEchoServer を使用してレプリカの障害を検出する場合は、以下の要件と制約に注意してください。

- ハートビート メカニズムを使用して障害を検出する場合は、各レプリカ サーバ マシンで WlssEchoServer プロセスを常に実行しておく必要があります。WlssEchoServer プロセスで障害が起きたりプロセスが停止したりした場合は、たとえサーバ プロセスに影響が及んでいなくてもレプリカは「オフライン状態」として扱われます。

- WlssEchoServer は、そのサーバ マシン上で利用できるすべての IP アドレスでリスンします。

- WlssEchoServer には、ハートビート メッセージをリスンするための専用のポート番号が必要です。

8.3.1 SIP データ層サーバ マシンでの WlssEchoServer の起動

WlssEchoServer は、シェルまたはコマンド プロンプトから直接起動できる Java プログラムです。WlssEchoServer を起動するための基本的な構文は次のとおりです。

java -classpath WLSS_HOME/server/lib/wlss/wlssechosvr.jar options com.bea.wcp.util.WlssEchoServer

WLSS_HOME は、Oracle WebLogic Communication Services インストール環境のパスです。options には、表 8-1 に示すいずれかのオプションを指定できます。

表 8-1 WlssEchoServer のオプション

オプション

説明

-Dwlss.ha.echoserver.ipaddress

WlssEchoServer インスタンスには、ハートビート メッセージをリスンするための IP アドレスを指定します。IP アドレスを指定しない場合は、インスタンスは、そのサーバ マシン上で利用できるすべての IP アドレス (0.0.0.0) でリスンします。

-Dwlss.ha.echoserver.port

ハートビート メッセージをリスンするポート番号を指定します。サーバ マシンの他のプロセスが同じポート番号を使用していないことを確認します。デフォルトでは、WlssEchoServer はポート 6734 を使用します。

-Dwlss.ha.echoserver.logfile

ログ ファイルの場所と名前を指定します。デフォルトでは、ログ メッセージは ./echo_servertime.log に書き込まれます。time の単位はミリ秒です。

WlssEchoServer を起動するコマンドは、各 Oracle WebLogic Communication Services の SIP データ層インスタンスの起動に使用するのと同じスクリプトで指定することをお勧めします。startManagedWebLogic.sh スクリプトを使ってエンジン層サーバまたは SIP データ層サーバのインスタンスを起動している場合は、サーバを起動する最後のコマンドの前に WlssEchoServer を起動するコマンドを追加します。たとえば、次の行を編集し、

"$JAVA_HOME/bin/java" ${JAVA_VM} ${MEM_ARGS} ${JAVA_OPTIONS}     \
-Dweblogic.Name=${SERVER_NAME}                                 \
-Dweblogic.management.username=${WLS_USER}                     \
-Dweblogic.management.password=${WLS_PW}                       \
-Dweblogic.management.server=${ADMIN_URL}                      \
-Djava.security.policy="${WL_HOME}/server/lib/weblogic.policy" \
weblogic.Server

次のように書き換えます。

"$JAVA_HOME/bin/java" -classpath WLSS_HOME/server/lib/wlss/wlssechosvr.jar    \
-Dwlss.ha.echoserver.ipaddress=192.168.1.4                   \
-Dwlss.ha.echoserver.port=6734 com.bea.wcp.util.WlssEchoServer &
"$JAVA_HOME/bin/java" ${JAVA_VM} ${MEM_ARGS} ${JAVA_OPTIONS}     \
-Dweblogic.Name=${SERVER_NAME}                                 \
-Dweblogic.management.username=${WLS_USER}                     \
-Dweblogic.management.password=${WLS_PW}                       \
-Dweblogic.management.server=${ADMIN_URL}                      \
-Djava.security.policy="${WL_HOME}/server/lib/weblogic.policy" \
weblogic.Server

8.3.2 サーバのハートビート メカニズムの有効化とコンフィグレーション

WlssEchoServer ハートビート メカニズムを有効にするには、すべてのエンジン層サーバおよび SIP データ層サーバを起動するコマンドで -Dreplica.host.monitor.enabled JVM 引数を指定する必要があります。 このオプションは、システムの管理対象サーバを起動するスクリプトに直接追加することをお勧めします。たとえば、startManagedWebLogic.sh スクリプトの次の行を編集し、

# JAVA_OPTIONS="-Dweblogic.attribute=value -Djava.attribute=value"

次のように書き換えます。

JAVA_OPTIONS="-Dreplica.host.monitor.enabled=true"

ハートビート メカニズムの機能をコンフィグレーションする追加の JVM オプションがいくつかあります。表 8-1 に、障害検出をコンフィグレーションするためのオプションを示します。

表 8-2 WlssEchoServer のオプション

オプション

説明

-Dreplica.host.monitor.enabled

ハートビート メカニズムを有効にするには、エンジン層サーバと SIP データ層サーバの両方でこのシステム プロパティを指定する必要があります。

-Dwlss.ha.heartbeat.interval

ハートビート メッセージの間隔をミリ秒単位で指定します。デフォルトでは、ハートビート メッセージは 1,000 ミリ秒ごとに送信されます。

-Dwlss.ha.heartbeat.count

ハートビート メッセージへの応答が、ここで指定した回数だけ連続して返らなかった場合、レプリカはオフライン状態と見なされます。デフォルトでは、サーバの WlssEchoServer プロセスがハートビート メッセージに 3 回応答しなかった場合、レプリカはオフライン状態と見なされます。

-Dwlss.ha.heartbeat.SoTimeout

UDP ソケットのタイムアウト値を指定します。

8.4 SNMP のコンフィグレーション

Oracle WebLogic Communication Services には、エンジン層と SIP データ層のサーバ インスタンスのアクティビティをモニタするための専用 SNMP MIB が用意されています。Oracle WebLogic Communication Services の MIB は、ドメインの管理サーバと管理対象サーバの両方で生成されます。ただし、Oracle WebLogic Communication Services のエンジン層と SIP データ層のトラップを生成するのは、各層を構成する管理対象サーバ インスタンスだけです。管理サーバが sipserver のカスタム リソースのための対象でなければ、(クラスタ内のサーバで障害が起きた場合などに) WebLogic Server の SNMP トラップのみが生成されます。管理者は、ドメイン全体の動作を評価するために、WebLogic Server と Oracle WebLogic Communication Services の両方のトラップをモニタする必要があります。

注意 :
Oracle WebLogic Communication Services の MIB オブジェクトは読み込み専用です。SNMP を使用して Oracle WebLogic Communication Services のコンフィグレーションを変更することはできません。

8.4.1 MIB の参照

Oracle WebLogic Communication Services の MIB ファイルは、WLSS_HOME/server/lib/wlss/BEA-WLSS-MIB.asn1 にインストールされています。 このファイルの内容を表示するには、利用可能な SNMP 管理ツールまたは MIB ブラウザを使用してください。共有 SNMP トラップの説明については、節 8.5.2「トラップの説明」を参照してください。

8.4.2 SNMP のコンフィグレーション手順

Oracle WebLogic Communication Services ドメイン全体の SNMP モニタを有効にするには、次の手順に従います。

1. Oracle WebLogic Communication Services ドメインの Administration Console にログインします。

2. 左ペインで、[Diagnostics｜SNMP] ノードを選択します。

3. 新しいエージェントを作成するには、Server SNMP エージェント テーブルで [New] ボタンをクリックしてください。

注意 :
Domain-Scoped エージェントではなく新しい Server SNMP エージェントを作成することを確認します。

4. 新しい SNMP エージェントに固有の名前 (たとえば、「engine1snmp」) を入力して、[OK] をクリックします。

5. Server SNMP エージェント テーブルから、作成した新しい SNMP エージェントを選択します。

6. [コンフィグレーション｜一般] タブで以下のように選択します。

1. [有効化] チェック ボックスを選択し、エージェントを有効にします。

2. SNMP UDP ポート フィールドで非使用のポート番号を入力します。

注意 :
複数の管理対象サーバ インスタンスを同じマシンで実行する場合、各サーバ インスタンスはユニークな SNMP ポート番号で専用 SNMP エージェントを使用する必要があります。

3. [保存] をクリックします。

7. デプロイメント内の各サーバ （SIP データ層サーバ、エンジン層サーバおよび管理サーバ）に対してユニークな SNMP エージェントを生成するには、上記の手順を繰り返します。

8.5 SNMP トラップの概要と対処法

以下の節では、Oracle WebLogic Communication Services の SNMP トラップについて詳しく説明します。また、個々のトラップに対処するための回復手順についても必要に応じて説明します。

8.5.1 トラブルシューティングに役立つファイル

以下の Oracle WebLogic Communication Services のログ ファイルおよびコンフィグレーション ファイルはトラブルシューティングに役立つことが多く、テクニカル サポートへの問い合わせの際に必要になることがあります。

- $DOMAIN_DIR/config/config.xml

- $DOMAIN_DIR/config/custom/sipserver.xml

- $DOMAIN_DIR/servername/*.log (サーバおよびメッセージ ログ)

- sip.xml (アプリケーションの /WEB-INF サブディレクトリ内)

- web.xml (アプリケーションの /WEB-INF サブディレクトリ内)

テクニカル サポート チームが問題を解決する上で、次のような一般情報が役立つことがあります。

- 以下のソフトウェアの具体的なバージョン番号

- Oracle WebLogic Communication Services

- Java SDK

- オペレーティング システム

- ハングした Oracle WebLogic Communication Services プロセスのスレッド ダンプ

- ネットワーク アナライザのログ

8.5.2 トラップの説明

表 8-3 は、Oracle WebLogic Communication Services の各種 SNMP トラップをエンジン層のサーバで生成されるトラップと SIP データ層のサーバで生成されるトラップに分けて示したものです。 それぞれのトラップについては、表に続く各節で説明します。

表 8-3 Oracle WebLogic Communication Services の SNMP トラップ

トラップが生成されるサーバ ノード

トラップ名

エンジン層サーバ

節 8.5.2.1「connectionLostToPeer」

節 8.5.2.2「connectionReestablishedToPeer」

節 8.5.2.4「overloadControlActivated、overloadControlDeactivated」

節 8.5.2.9「sipAppDeployed」

節 8.5.2.10「sipAppUndeployed」

節 8.5.2.11「sipAppFailedToDeploy」

エンジン層サーバと SIP データ層サーバ (サーバがクラスタのメンバーである場合)

節 8.5.2.8「serverStopped」

SIP データ層サーバ

節 8.5.2.3「dataTierServerStopped」

節 8.5.2.5「replicaAddedToPartition」

節 8.5.2.6「replicaRemovedEnginesRegistration」

節 8.5.2.7「replicaRemovedFromPartition」

8.5.2.1 connectionLostToPeer

エンジン層のサーバ インスタンスが SIP データ層のレプリカに接続できなくなった場合は、そのエンジン層サーバでこのトラップが生成されます。エンジン層と SIP データ層の間でネットワーク接続の問題が起きている可能性があります。また、SIP データ層のサーバで障害が発生している場合は、このトラップと共に追加のトラップが生成されることがあります。

8.5.2.1.1 回復手順

サーバの障害を示す他のトラップとは無関係にこのトラップが発生している場合は、一般にネットワークで障害が起きています。影響を受けるエンジン層のサーバと SIP データ層のサーバ間のネットワーク コネクションを検証または修復してください。

SIP データ層のサーバの障害を示す追加のトラップ (たとえば dataTierServerStopped) と共に発生している場合は、そのトラップの回復手順に従います。

8.5.2.2 connectionReestablishedToPeer

以前に接続に失敗したエンジン層のサーバ インスタンスが (connectionLostToPeer トラップが生成された後で) SIP データ層のサーバへの再接続に成功した場合は、そのエンジン層サーバでこのトラップが生成されます。このトラップが繰り返し発生する場合は、エンジン層と SIP データ層の間で断続的なネットワーク障害が起きている可能性があります。

8.5.2.2.1 回復手順

節 8.5.2.1「connectionLostToPeer」を参照してください。

8.5.2.3 dataTierServerStopped

データ層に属する WebLogic Server インスタンスで回復不能なエラーが発生した場合は、Oracle WebLogic Communication Services の SIP データ層ノードでこのアラームが生成されます。このトラップは、エラーによって停止しようとしているサーバ自体で生成される場合と、同じパーティション内の別のレプリカで生成される場合があり、一部のケースでは両方のサーバで生成されることもあります (ネットワークの障害発生時には両方のサーバで同じトラップが生成されることがあります)。

8.5.2.3.1 回復手順

節 8.5.2.8「serverStopped」の回復手順を参照してください。

8.5.2.4 overloadControlActivated、overloadControlDeactivated

Oracle WebLogic Communication Services のエンジン層ノードでは、処理される新しい SIP リクエストの数を制御できるように、コンフィグレーション可能なスロットル機能のメカニズムが使われています。コンフィグレーションされているオーバーロード状態に達すると、Oracle WebLogic Communication Services は新しい SIP リクエストを破棄し、呼び出し側に「503 Service Unavailable」で応答します。コンフィグレーションされているしきい制御値に従って、オーバーロード状態が解消するまでサーバは新しいリクエストを破棄し続けます。このアラームは、スロットル機能のメカニズムがアクティブになっているときに生成されます。スロットル機能の動作により、サーバは最終的にオーバーロードでない状態に戻るので、それ以上のアクションは必要ありません。

8.5.2.4.1 回復手順

次の回復手順を実行します。

1. 他のサーバをチェックし、オーバーロードに近い状態かどうかを確認します。

2. ロード バランサがアプリケーション サーバ間で正しく負荷を分散しているかどうか、または 1 つまたは複数のサーバをオーバーロード状態にしているかどうかを確認します。追加のサーバがオーバーロードに近い状態の場合は、直ちに Tier 4 サポートに連絡してください。

3. 問題が 1 つのサーバに限られている場合は、1 時間以内に Tier 4 サポートに連絡してください。

8.5.2.4.2 オーバーロードに関するその他の FAQ

キューの長さを着信呼び出しオーバーロード制御として設定すると、Administration Console を使ってキューの長さをモニタすることができます。セッション レート制御を指定すると、Administration Console を使ってセッション レートをモニタできません (Administration Console には、SIP セッションの現在の数だけが表示され、新しいセッションが生成されるレートは表示されません)。

8.5.2.5 replicaAddedToPartition

サーバ インスタンスがデータ層のパーティションに追加された場合は、Oracle WebLogic Communication Services の SIP データ層ノードでこのアラームが生成されます。

8.5.2.5.1 回復手順

このトラップは、SIP データ層のサーバを起動した場合の通常の起動処理時に生成されます。

8.5.2.6 replicaRemovedEnginesRegistration

登録されていない (または登録済みエンジンのリストから削除されている) エンジン サーバ クライアントが SIP データ層と通信しようとすると、SIP データ層ノードでこのアラームが生成されます。 一般に、このトラップはserverStopped トラップの後に続きます。これは、SIP データ層の一貫性を保持するためにエンジン層サーバはシャットダウンされていること示しています。

8.5.2.6.1 回復手順

エンジン層サーバを再起動します。このトラップが繰り返し発生する場合は、エンジン層と 1 つまたは複数のレプリカの間でネットワーク接続の問題が起きている可能性があります。

8.5.2.7 replicaRemovedFromPartition

通常の停止操作によって、または障害が原因でサーバが SIP データ層から削除された場合は、Oracle WebLogic Communication Services の SIP データ層ノードでこのアラームが生成されます。このトラップが生成されるのは、サーバの削除後、そのパーティション内で少なくとも 1 つのレプリカが動作し続けている場合だけです。レプリカが 1 つしか存在しないパーティションでそのレプリカに障害が発生した場合は、トラップを生成できません。また、レプリカに障害が発生したことはエンジン層のノードによって検出されるので、このトラップが生成可能であるためには、いずれかのエンジン層ノードが実行されている必要があります。

8.5.2.7.1 回復手順

サーバ インスタンスの障害が原因でこのトラップが生成された場合は、例外を示す追加のトラップが生成されます。replicaRemovedFromPartition と共に生成されたトラップの回復手順を参照してください。

8.5.2.8 serverStopped

このトラップは、WebLogic Server インスタンスが現在ダウンしていることを示します。このトラップはエンジン層と SIP データ層の両方のサーバ インスタンスに適用されますが、それは、サーバが名前付きの WebLogic Server クラスタのメンバーである場合に限られます。このトラップが、制御された停止によって発生したのではなく、自然に生成された場合は、次の手順に従います。

8.5.2.8.1 回復手順

次の回復手順を実行します。

1. 次のコマンドを使用して、ハングしているプロセスを特定します。

ps – ef | grep java

マシンで実行中の WebLogic Server インスタンスごとに、対応する PID が 1 つだけあります。

2. 影響を受けている PID を特定したら、次のコマンドを使ってプロセスを強制停止します。

kill -3 [pid]

3. このコマンドを実行すると、実際のスレッド ダンプが生成されます。プロセスが直ちに停止しない場合は、潜在的なデッドロックの問題の診断に役立つように、プロセスが停止するまで 5 ～ 10 秒間隔でコマンドを何度か繰り返します。

4. すぐに Oracle WebLogic Communication Services を再起動してみます。

5. トラブルシューティングに役立つように、影響を受けたサーバのすべての SIP ログのバックアップ コピーを作成します。ログの場所は、サーバのコンフィグレーションによって異なります。

6. Tier 4 サポートが問題を解決する際に役立つように、各ログをコピーします。

注意 :
Oracle WebLogic Communication Services のログは、システムのコンフィグレーションに従って切り捨てられます。重要なトラブルシューティングの情報が失われないように、バックアップ ログを直ちに作成してください。

7. Tier 4 サポートに連絡し、トラブル チケットにログ ファイルを含めます。

8. その後 24 時間にわたり、サーバを注意深くモニタします。ログ ファイルで問題の原因を特定できない場合は、ハードウェアやネットワークに問題があり、それが時間をおいて再発することがあります。

8.5.2.8.2 停止に関するその他の FAQ

Administration Console が管理対象 WebLogic Server インスタンスの SNMP メッセージを生成するのは、ServerShutDown メッセージを受け取るまでです。それ以降は、追加のメッセージは生成されません。

8.5.2.9 sipAppDeployed

SIP サーブレットがコンテナにデプロイされた場合は、Oracle WebLogic Communication Services のエンジン層ノードでこのアラームが生成されます。

8.5.2.9.1 回復手順

このトラップは、通常のデプロイメント処理時に生成されます。例外を示しているわけではありません。

8.5.2.10 sipAppUndeployed

SIP アプリケーションが停止した場合、または SIP アプリケーションがアンデプロイされた場合は、Oracle WebLogic Communication Services のエンジン層ノードでこのアラームが生成されます。一般に、アクティブなリクエストがまだ存在するにもかかわらず Oracle WebLogic Communication Services が停止した場合に発生します。

8.5.2.10.1 回復手順

通常の停止の手順では、このアラームは除去されるため、通知されないはずです。通常の運用の最中にこのアラームが発生した場合は、誰かがアプリケーションまたはサーバを突然停止させたか、アプリケーションに問題があることを意味しています。直ちに Tier 4 サポートに連絡してください。

8.5.2.11 sipAppFailedToDeploy

アプリケーションが Web アプリケーションとしては正しくデプロイされたが、SIP アプリケーションとしてデプロイされなかった場合は、Oracle WebLogic Communication Services のエンジン層ノードでこのトラップが生成されます。

8.5.2.11.1 回復手順

無効な sip.xml コンフィグレーション ファイルが原因で起きることが多く、ソフトウェアのインストール時またはアップグレード時にのみ発生します。この問題が発生した場合は、アプリケーションをアンデプロイし、sip.xml ファイルを検証した後、デプロイメントをやり直します。

注意 :
通常の運用時にこのアラームは発生しません。発生した場合は、直ちに Tier 4 サポートに連絡してください。

8.6 WebLogic 診断フレームワーク (WLDF) の使用

WebLogic 診断フレームワーク (WLDF) は、WebLogic Server インスタンスとそのアプリケーションの診断情報を収集、アーカイブおよびアクセスするために共同作業する数多くのコンポーネントから構成されています。Oracle WebLogic Communication Services バージョン は、WLDF のさまざまなコンポーネントと統合することにより、デプロイ済み SIP Servlets と共にエンジンおよび SIP データ層ノードの操作をモニタし、診断します。

- データ コレクタ - Oracle WebLogic Communication Services は、ハーベスタ サービスと統合するとて実行時 MBeans からの情報を収集し、Logger サービスと統合すると SIP リクエストと応答をアーカイブすることができます。

- 監視と通知 - 管理者は監視と通知コンポーネントを使用して、Oracle WebLogic Communication Services の実行時 MBean の属性に基づき複雑なルールを作成することができます。これらの属性は、JMS、JMX、SNMP および SMTP などを使用して自動通知をトリガします。

- イメージ キャプチャ - Oracle WebLogic Communication Services インスタンスは、管理者からリクエストされた場合、一定の診断データを収集し、イメージ ファイルに書き込むことができます。このデータは、実行中のサーバに起こる問題を診断するために使用できます。

- インスツルメンテーション - Oracle WebLogic Communication Services では、モニタを使用してサーバ コードとアプリケーション コードをインスツルメンテーションするので、特定の条件に一致する SIP メッセージ (リクエストと応答) について実行する診断アクションをコンフィグレーションすることができます。

以下の節では、上記の各 WLDF コンポーネントと Oracle WebLogic Communication Services の統合方法の詳細について説明します。

8.6.1 データ収集とロギング

Oracle WebLogic Communication Services は、以下の実行時 MBeans の属性からデータを収集するために WLDF のハーベスタ サービスを使用します。

- ReplicaRuntimeMBean

- SipApplicationRuntimeMBean

- SipServerRuntimeMBean

WLDF コンソール拡張を使用して、ユーザのカスタム ビューにデータの図とグラフを追加することができます。これを行うには、最初に以下のようにドメイン ディレクトリの console-ext サブディレクトリに JAR ファイルをコピーして WLDF コンソール拡張を有効にします。

cp ~/bea/wlserver_10.3/server/lib/console-ext/diagnostics-console-extension.jar ~/bea/user_projects/domains/mydomain/console-ext

WLDF コンソール拡張にアクセスすると、Oracle WebLogic Communication Services 実行時 MBean の属性が拡張の [メトリクス] タブから使用できます。

また、Oracle WebLogic Communication Services は、独立した専用のログ ファイルに SIP と Diameter メッセージをアーカイブするために WLDF Logger サービスを使用します (デフォルトでは、domain_home/logs/server_name/sipMessages.log)。 SIP Server Administration Console 拡張で [コンフィグレーション｜メッセージ デバッグ] タブを使用して、ログ ファイルの名前と場所、ならびにログ ローテーション ポリシーをコンフィグレーションすることができます。独立したロギングとログ ローテーションを開始するためには、サーバの再起動が必要です。

8.6.2 監視と通知

Oracle WebLogic Communication Services の実行時 MBean から収集したデータを使用して、サーバの診断状態を監視する自動モニタまたは「監視」を作成します。 コンフィグレーションされた監視状態およびルールが発生した場合、SMTP、SNMP、JMX、または JMS を使用してメッセージを作成するために 1 つまたは複数の通知を監視で使用するようにコンフィグレーションすることができます。

監視と通知を使用するには、Administration Console の左ペインで [診断｜診断モジュール] ノードを選択し、サーバをモニタするために必要な監視ルールおよび通知を使って新しいモジュールを作成します。監視のルールでは、Oracle WebLogic Communication Services の実行時 MBean、ログ ファイルに書き込まれたメッセージ、または診断フレームワークで作成されたイベントから収集したメトリックスを使用することができます。

8.6.3 イメージ キャプチャ

Oracle WebLogic Communication Services は、独自のイメージ キャプチャ情報を WLDF で作成された診断イメージに追加します。診断イメージは、要求に応じて生成するか、監視ルールをコンフィグレーションして自動的に生成します。

診断イメージに含まれている情報については、Oracle のテクニカル サポート担当者がサーバの問題のトラブルシューティングに使用することを意図しています。これには以下の情報が含まれます。

- SIP データ層パーティションとレプリカのコンフィグレーション

- 呼状態とタイマーの統計

- ワーク マネージャの統計

8.6.4 インスツルメンテーション

WLDF インスツルメンテーション システムは、診断モニタを作成し、実行中に特定のポイントで Oracle WebLogic Communication Services またはアプリケーション コードに挿入します。Oracle WebLogic Communication Services をインスツルメンテーションサービスと統合して、組み込み DyeInjection モニタを提供します。このモニタが使用可能になると、特定の SIP メッセージがシステムに入力された場合、またはすでに存在する場合、診断コンテキストに仕分けフラグがインジェクトされます。仕分けフラグはモニタのコンフィグレーション プロパティと一定のリクエスト属性に基づいてインジェクトされています。

Oracle WebLogic Communication Services は、WebLogic Server の仕分けフラグの USSR と ADDR に加え、以下の表 8-4 に説明されている仕分けフラグも追加します。 詳細については、『Oracle Fusion Middleware Oracle WebLogic Server 診断フレームワークのコンフィグレーションと使い方』を参照してください。

表 8-4 Oracle WebLogic Communication Services DyeInjection フラグ

仕分けフラグ

説明

PROTOCOL_SIP

すべての SIP プロトコル メッセージの診断コンテキストで設定されます。

SIP_REQ

プロパティ SIP_REQ の値に一致するすべての SIP リクエストの診断コンテキストに設定されます。

SIP_RES

SIP 応答がプロパティ SIP_RES の値に一致する場合に設定されます。

SIP_REQURI

SIP リクエストの reqURI がプロパティ SIP_REQURI の値に一致する場合に設定されます。

SIP_ANY_HEADER

SIP リクエストにプロパティ SIP_ANY_HEADER の値に一致するヘッダが含まれている場合、設定されます。

SIP_RES

このフラグは、プロパティ SIP_RES の値に一致するすべての SIP 応答用診断コンテキストに設定されます。

SIP_REQURI

このフラグは、SIP リクエストのリクエスト URI がプロパティ SIP_REQURI の値に一致する場合に設定されます。

SIP_ANY_HEADER

このフラグは、SIP リクエストにプロパティ SIP_ANY_HEADER の値に一致するヘッダが含まれている場合、設定されます。SIP_ANY_HEADER の値は、messageType.headerName=headerValue の形式で指定されます。ここで、headerValue は値または通常の式です。たとえば、プロパティは次のように指定できます。SIP_ANY_HEADER=request.Contact=sip:sipp@localhost:5061 または SIP_ANY_HEADER=response.Contact=sip:findme@172.17.30.50:5060。

仕分けフラグは、着信 SIP メッセージと発信 SIP メッセージの両方に適用できます。仕分けのフィルタリング処理にフラグを使用します。委託モニタが次の診断アクションをトリガするときに使用できます。

Oracle WebLogic Communication Services には、アプリケーションおよびサーバ スコープに適用できる数多くの代理モニタがあります。これらのモニタは、DyeInjection モニタによって設定された仕分けフラグを調査することができます。 代理モニタについては、表 8-4 を参照してください。

表 8-5 Oracle WebLogic Communication Services 診断モニタ

モニタ名

モニタ タイプ

スコープ

ポイントカット

occas/Sip_Servlet_Before_Service

Before

アプリケーション

すべての実装サブクラスの SipServlet.do* または SipServlet.service メソッドのエントリ時。

occas/Sip_Servlet_After_Service

After

アプリケーション

すべての実装サブクラスの SipServlet.do* または SipServlet.service メソッドの終了時。

occas/Sip_Servlet_Around_Service

Around

アプリケーション

すべての実装サブクラスの SipServlet.do* または SipServlet.service メソッドのエントリと終了時。

occas/Sip_Servlet_Before_Session

Before

アプリケーション

SipSession および SipApplicationSession の両方の getAttribute、set、remove、および invalidate メソッドのエントリ時。

occas/Sip_Servlet_After_Session

After

アプリケーション

SipSession および SipApplicationSession の両方の getAttribute、set、remove、および invalidate メソッドの終了時。

occas/Sip_Servlet_Around_Session

Around

アプリケーション

SipSession および SipApplicationSession の両方の getAttribute、set、remove、および invalidate メソッドのエントリと終了時。

occas/SipSessionDebug

Around

アプリケーション

これは、一定のポイントカットとデバッグアクションがある組み込みアプリケーション スコープ モニタです。ポイントカットの前後、モニタは 基になるオブジェクトをシリアライズした後で、SIP セッション のサイズを計算する SipSessionDebug 診断アクションが実行されます。

モニタのポイントカットは以下のとおりです。

1. SipServletMessage クラス階層のgetSession と getApplicationSession の呼び出しの前後。

2. SipSession および SipApplicationSession クラスの getAttribute、setAttribute, および removeAttribute メソッド呼び出しの前後。

注意 : occas/SessionDebugAction-Before イベントは req.getSession() または req.getApplicationSession() ジョインポイントのためにトリガーされません。 ジョインポイントを実行した後でのみ、セッションが検査できるようになると、occas/SessionDebugAction-After のみがトリガーされます。

注意 : Apache Ant を使用してアプリケーションをコンパイルすると、生成されたクラス ファイルに必要なデバッグ情報が埋め込まれるため、debug 属性を有効化する必要があります。

occas/Sip_Servlet_Before_Message_Send_Internal

Before

サーバ

ワイヤにメッセージを書き込む Oracle WebLogic Communication Services コードのエントリ時。

occas/Sip_Servlet_After_Message_Send_Internal

After

サーバ

ワイヤにメッセージを書き込む Oracle WebLogic Communication Services コードの終了時。

occas/Sip_Servlet_Around_Message_Send_Internal

Around

サーバ

ワイヤにメッセージを書き込む Oracle WebLogic Communication Services コードのエントリと終了時。

8.6.4.1 サーバ スコープ モニタのコンフィグレーション

サーバ スコープのモニタを使用するには、新しい診断モジュールを作成して、モジュールに 1 つまたは複数のモニタを作成しコンフィグレーションする必要があります。組み込み DyeInjection モニタの場合、特定のダイ フラグを定義するためにモニタ プロパティを追加します。occas/Sip_Servlet_Before_Message_Send_Internal などの代理モニタについては、モニタ プロパティを追加して診断アクションを定義します。

Oracle WebLogic Communication Services DyeInjection モニタ、代理モニタをコンフィグレーションして仕分けフィルタリングを有効にするには、次の手順に従います。

1. ドメインの Administration Console にアクセスします。

2. コンソールの左ペインの [診断｜診断モジュール] ノードを選択します。

3. [新規] をクリックして、新しい診断モジュールを作成します。モジュールに「instrumentationModule」のようなわかりやすい名前を付けて、[OK] をクリックします。

4. テーブル内のモジュールのリストから新しい「instrumentationModule」を選択します。

5. [ターゲット] タブを選択します。

6. このモジュールを対象とするサーバを選択して、[保存] をクリックします。

7. [診断｜診断モジュール] ノードに戻って、モジュールのリストから「instrumentationModule」を選択します。

8. [コンフィグレーション｜インスツルメンテーション] タブを選択します。

9. [有効化] を選択し、サーバ レベルでのインスツルメンテーションを有効にして、[保存] をクリックします。

10. モジュールに DyeInjection モニタを追加するには、以下の手順に従います。

1. [追加/削除] をクリックします。

2. 利用可能なリストからモニタの名 (たとえば、DyeInjection) を選択し、矢印を使って選択したリストに移動します。

3. [OK] をクリックします。

4. 利用可能なモニタのリストから新たに作成したモニタを選択します。

5. モニタが有効になっていることを確認し、[プロパティ] フィールドを編集して必要なプロパティを追加します。DyeInjection モニタのサンプル プロパティには、以下が含まれています。

SIP_RES=180
SIP_REQ=INVITE
SIP_ANY_HEADER=request.Contact=sip:sipp@localhost:5061

6. [保存] をクリックします。

11. モジュールに 1 つまたは複数の代理モニタを追加するには、以下の手順に従います。

1. 新しいモジュールの名前を入力するには、[コンフィグレーション｜インスツルメンテーション] タブに戻る。

2. [追加/削除] をクリックします。

3. 利用可能なリストから代理モニタ名 (たとえば、occas/Sip_Servlet_Before_Message_Send_Internal) を選択し、矢印を使って選択したリストに移動します。

4. [OK] をクリックします。

5. 利用可能なモニタのリストから、新たに作成したモニタを選択します。

6. モニタが有効になっていることを確認し、利用可能なリストから 1 つまたは複数のアクションを選択して、矢印を使って選択したリストに移動します。occas/Sip_Servlet_Before_Message_Send_Internal モニタでは、サンプル アクションに DisplayArgumentsAction、 StackDumpAction、ThreadDumpAction、および TraceAction が含まれています。

7. [EnableDyeFiltering] の横にあるチェック ボックスを選択します。

8. 利用可能なリストから SIP_REQ のような 1 つまたは複数の仕分けマスクを選択し、矢印を使って選択したリストに移動します。

9. [保存] をクリックします。

注意 :
代理モニタを追加して作成するには、上記の手順を繰り返します。

8.6.4.2 アプリケーション スコープ モニタのコンフィグレーション

アプリケーション スコープ モニタを weblogic-diagnostics.xml という名前の XML コンフィグレーション ファイルにのコンフィグレーションします。weblogic-diagnostics.xml ファイルを SIP モジュールまたはエンタープライズ アプリケーションの META-INF ディレクトリに格納する必要があります。

XML ファイルは、アプリケーション レベルでインスツルメンテーションを有効化にし、ポイントカット、代理モニタ仕分けマスクおよびアクションを定義します。例 8-1 には、occas/Sip_Servlet_Before_Service モニタを使用するコンフィグレーション ファイルのサンプルを示します。

例 8-1 weblogic-diagnostics.xml ファイルのサンプル

<wldf-resource xmlns="http://www.bea.com/ns/weblogic/90/diagnostics">
<instrumentation>
<enabled>true</enabled>
<include>demo.ProxyServlet</include>
<wldf-instrumentation-monitor>
<name>occas/Sip_Servlet_Before_Service</name>
<enabled>true</enabled>
<dye-mask>SIP_ANY_HEADER</dye-mask>
<dye-filtering-enabled>true</dye-filtering-enabled>
<action>DisplayArgumentsAction</action>
</wldf-instrumentation-monitor>
</instrumentation>
</wldf-resource>

この例では、診断コンテキストの着信するリクエストに SIP_ANY_HEADER 仕分けフラグが含まれている場合、occas/Sip_Servlet_Before_Service モニタがトリガされ、DisplayArgumentsAction が実行されます。

8.7 SIP リクエストと応答のロギング

Oracle WebLogic Communication Services では、処理される SIP リクエストと応答の Protocol Data Unit (PDU) ロギングを行うことができます。ロギングされた SIP メッセージは、Oracle WebLogic Communication Services のドメイン全体のログ ファイル、または個々の管理対象サーバ インスタンスのログ ファイルに書き込まれます。SIP メッセージは Oracle WebLogic Communication Services インスタンスと同じログ ファイルを共有するので、ログに記録された SIP メッセージを管理するときに、ログ ローテーション、ドメイン ログ フィルタ、最大ログ サイズ コンフィグレーションなどの高度なサーバ ロギング機能を利用できます。

管理者は SIP PDU ロギングをコンフィグレーションするために、com.bea.wcp.sip.engine.tracing.listener.TraceMessageListenerImpl クラスを使って 1 つまたは複数の SIP サーブレットを定義します。次に、定義したサーブレットのパラメータとして、またはアプリケーションと共にパッケージ化される独立した XML ファイルで、ロギング条件をコンフィグレーションします。

SIP リクエストが処理されるか、SIP 応答が生成される際に、ロギング サーブレットはスタンドアロンの XML コンフィグレーション ファイルまたはサーブレットのパラメータで定義されたフィルタ処理のパターンをメッセージと照合します。指定されたパターンと一致する SIP リクエストと応答は、ロギング サーブレットの名前、コンフィグレーションされているロギング レベル、その他の詳細と共にログ ファイルに書き込まれます。無駄なパターン マッチングを避けるために、サーブレットは最初のパターンが一致すると新しい SIP セッションにマークして、そのセッションのそれ以降のリクエストと応答を自動的にログに記録します。

ロギング条件は、sip.xml でロギング サーブレットのパラメータとして直接定義するか、外部 XML コンフィグレーション ファイルで定義します。節 8.7.3「ロギングするメッセージの条件の指定」を参照してください。

注意 :
技術者は、サーブレットの init() メソッドで TraceMessageListenerFactory を使って委託を作成するか、デプロイする Java アプリケーションで追跡用のクラスを使って、サーブレットに PDU ロギング機能を実装できます。委託を使用すると、デフォルトの追跡メッセージ リスナの実装を使ってカスタム ロギングを行うことや、受信 SIP メッセージを操作することができます。サーブレットの init() メソッドでファクトリを使用する例については、節 8.7.7「SIP サーブレット コードへの追跡機能の追加」を参照してください。

8.7.1 sip.xml でのロギング サーブレットの定義

SIP メッセージのロギング サーブレットを作成するには、実装クラス com.bea.wcp.sip.engine.tracing.listener.TraceMessageListenerImpl を持つサーブレットを定義します。msgTraceLogger サンプルの定義を例 8-2に示します。

例 8-2 サンプルのロギング サーブレット

<servlet>
<servlet-name>msgTraceLogger</servlet-name>
<servlet-class>com.bea.wcp.sip.engine.tracing.listener.TraceMessageListenerImpl</servlet-class>
<init-param>
<param-name>domain</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>level</param-name>
<param-value>full</param-value>
</init-param>
<load-on-startup/>
</servlet>

8.7.2 ロギング レベルと出力先のコンフィグレーション

SIP メッセージのロギングの詳細レベルや出力先ログ ファイルなどのロギング属性は、初期化パラメータとしてロギング サーブレットに渡されます。表 8-5 に、init-param のエントリとして指定できるパラメータとパラメータ値を示します。例 8-2 には、すべての SIP メッセージ情報をドメイン ログ ファイルに記録するサーブレットの init-param サンプルのエントリの例が示されています。

8.7.3 ロギングするメッセージの条件の指定

ログに記録される SIP メッセージを選択するための条件は、ロギング サーブレットのアプリケーションと共にパッケージ化される XML ファイルで定義することも、サーブレットの sip.xml デプロイメント記述子で初期化パラメータとして定義することもできます。以下の節で、それぞれの方法について説明します。

8.7.3.1 XML ドキュメントを使ったロギング条件の指定

ロギング サーブレットの初期化パラメータとしてロギング条件を指定しない場合、サーブレットはロギング アプリケーションの最上位にある 1 組の XML 記述子ファイル内のロギング条件を参照します。request-pattern.xml および response-pattern.xml という名前のこれらの記述子ファイルでは、ログ ファイルに記録される SIP リクエストと応答を選択するために Oracle WebLogic Communication Services が使用するパターンが定義されます。

注意 :
デフォルトでは、Oracle WebLogic Communication Services はリクエストと応答の両方をログに記録します。応答をログに記録する必要がない場合は、空のマッチング条件を指定して response-pattern.xml ファイルを定義する必要があります。

通常のパターン定義では、SIP メッセージ ヘッダ内の特定の値を照合するための条件を定義します。たとえば、msgTraceLogger サーブレットで使われるサンプルの response-pattern.xml では、すべての MESSAGE リクエストが照合されます。この記述子の内容を次に示します。

例 8-3 msgTraceLogger サーブレットのサンプルの response-pattern.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pattern
PUBLIC "Registration//Organization//Type Label//Definition Language"
"trace-pattern.dtd">
<pattern>
<equal>
<var>response.method</var>
<value>MESSAGE</value>
</equal>
</pattern>

SIP メッセージを照合するための追加の演算子と条件については、節 8.7.6「trace-pattern.dtd リファレンス」を参照してください。 equal 条件など、ほとんどの条件には、表 8-3 に示すように評価する SIP メッセージの部分を識別する変数 (var 要素) が必要です。 表 8-5 に、一般的な変数と値の例を示します。 この他の変数名と例については、 SIP Servlet API 1.1 仕様 (http://jcp.org/en/jsr/detail?id=289) の節 16: Mapping Requests to Servlets を参照してください。 Oracle WebLogic Communication Services では、リクエストと応答の両方の変数をロギング サーブレットにマッピングすることができます。

表 8-6 パターン マッチングの変数とサンプル値

変数

値の例

request.method、response.method

MESSAGE、INVITE、ACK、BYE、CANCEL

request.uri.user、response.uri.user

guest、admin、joe

request.to.host、response.to.host

server.mydomain.com

request-pattern.xml と response-pattern.xml では、同じ文書型定義 (DTD) が使われます。詳細は、節 8.7.6「trace-pattern.dtd リファレンス」を参照してください。

8.7.3.2 サーブレットのパラメータを使ったロギング条件の指定

パターン マッチング条件は、独立した XML ドキュメントとしてではなく、ロギング サーブレットの初期化パラメータとして指定することもできます。マッチング条件を指定するためのパラメータ名は、request-pattern-string および response-pattern-string です。これらのパラメータは、節 8.7.2「ロギング レベルと出力先のコンフィグレーション」で説明したロギング レベルや出力先と共に定義されます。

各パターン マッチング パラメータの値は、スタンドアロン パターン定義ドキュメントの DTD に準拠する有効な XML ドキュメントで構成されている必要があります (節 8.7.3.1「XML ドキュメントを使ったロギング条件の指定」を参照してください)。 パターンと値を定義する XML ドキュメントは sip.xml 記述子の一部として解析されてはならないので、コンテンツを [CDATA] タグで囲む必要があります。例 8-4 に、サンプルのロギング サーブレット invTraceLogger の sip.xml エントリ全体を示します。 最後の 2 つの init-param の要素で、INVITE リクエスト メソッドと OPTIONS 応答メソッドだけをログに記録することを指定しています。

例 8-4 init-param の要素として指定されたロギング条件

<servlet>
<servlet-name>invTraceLogger</servlet-name>
<servlet-class>com.bea.wcp.sip.engine.tracing.listener.TraceMessageListenerImpl</servlet-class>
<init-param>
<param-name>domain</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>level</param-name>
<param-value>full</param-value>
</init-param>
<init-param>
<param-name>request-pattern-string</param-name>
<param-value>
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pattern
PUBLIC "Registration//Organization//Type Label//Definition Language"
"trace-pattern.dtd">
<pattern>
<equal>
<var>request.method</var>
<value>INVITE</value>
</equal>
</pattern>
]]>
</param-value>
</init-param>
<init-param>
<param-name>response-pattern-string</param-name>
<param-value>
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pattern
PUBLIC "Registration//Organization//Type Label//Definition Language"
"trace-pattern.dtd">
<pattern>
<equal>
<var>response.method</var>
<value>OPTIONS</value>
</equal>
</pattern>
]]>
</param-value>
</init-param>
<load-on-startup/>
</servlet>

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

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

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

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

例 8-5 に、text/* および application/sdp コンテンツに加え、追加の 3 つの Content-Type 値に対して文字列コンテンツをログする message-debug コンフィグレーションをサンプルとして示します。

例 8-5 追加のコンテンツ タイプのロギング文字列コンテンツ

<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>

8.7.5 ログ ローテーションの有効化とログ ファイルの参照

Oracle WebLogic Communication Services のロギング インフラストラクチャでは、既存のログ ファイルが指定のサイズに達したら、自動的に新しいログ ファイルに書き込まれるようにすることができます。また、Administration Console を使ってログの内容を参照することや、ログに書き込まれる追加のサーバ レベル イベントをコンフィグレーションすることもできます。

8.7.6 trace-pattern.dtd リファレンス

trace-pattern.dtd では、request-pattern.xml および response-pattern.xml ドキュメントの必須コンテンツのほかに、サーブレットの init-param 変数である request-pattern-string と response-pattern-string の値も定義されます。

例 8-6 trace-pattern.dtd

<!--
さまざまなタイプの条件がサポートされています。
- >

<!ENTITY % condition "and | or | not |
equal | contains | exists | subdomain-of">

<!--
pattern は条件で、SIP リクエストのセットの述部です。
- >

<!ELEMENT pattern (%condition;)>

<!--
すべての構成条件が true の場合のみ and 条件が true になります。
- >

<!ELEMENT and (%condition;)+>

<!--
少なくとも 1 つの構成条件が true の場合、or 条件が true になります。
- >

<!ELEMENT or (%condition;)+>

<!--
条件内の値を否定します。
- >

<!ELEMENT not (%condition;)>

<!--
変数の値が指定されたリテラル値と同じである場合、True です。
- >

<!ELEMENT equal (var, value)>

<!--
変数の値が指定されたリテラル値を含む場合、True です。
- >

<!ELEMENT contains (var, value)>

<!--
指定された変数がすでに存在する場合、True です。
- >

<!ELEMENT exists (var)>

<!--
- >

<!ELEMENT subdomain-of (var, value)>

<!--
変数を指定します。 Example:
<var>request.uri.user</var>
- >

<!ELEMENT var (#PCDATA)>

<!--
ルールの指定に使用するリテラル文字列値を指定します。
- >

<!ELEMENT value (#PCDATA)>

<!--
equal テストが大文字と小文字を区別するかどうかを指定します。
- >

<!ATTLIST equal ignore-case (true|false) "false">

<!--
contains テストが大文字と小文字を区別するかどうかを指定します。
- >

<!ATTLIST contains ignore-case (true|false) "false">

<!--
ID メカニズムを使うと、ツールで簡単にデプロイメント記述子の要素
に対するツール固有の参照を行うことができます。これにより、
追加デプロイメント情報 (つまり、標準的な
デプロイメント記述子情報以上の情報) を作成して
非標準情報を別のファイルに格納し、これらの
ツール固有のファイルから簡単に標準 sip-app
デプロイメント記述子を参照することができます。- >

<!ATTLIST pattern id ID #IMPLIED>
<!ATTLIST and id ID #IMPLIED>
<!ATTLIST or id ID #IMPLIED>
<!ATTLIST not id ID #IMPLIED>
<!ATTLIST equal id ID #IMPLIED>
<!ATTLIST contains id ID #IMPLIED>
<!ATTLIST exists id ID #IMPLIED>
<!ATTLIST subdomain-of id ID #IMPLIED>
<!ATTLIST var id ID #IMPLIED>
<!ATTLIST value id ID #IMPLIED>

8.7.7 SIP サーブレット コードへの追跡機能の追加

TraceMessageListenerFactory を使用すると、独自のサーブレットや Java コードに追跡機能を追加することができます。TraceMessageListenerFactory により、クライアントはインスタンスを作成し、そのインスタンスに委託することで、デフォルトの追跡メッセージ リスナ実装の動作を再利用できるようになります。ファクトリ実装インスタンスは、SIP サーブレットのサーブレット コンテキストで TraceMessageListenerFactory.TRACE_MESSAGE_LISTENER_FACTORY 属性の値を検索すると見つかります。

注意 :
ファクトリによって作成されるインスタンスは、SIP メッセージの受信および送信時にコールバックを受け取るように Oracle WebLogic Communication Services に登録されません。

サーブレットに追跡を実装するには、例 8-7 に示すように、サーブレットの init() メソッドでファクトリ クラスを使って委託を作成します。

例 8-7 TraceMessageListenerFactory の使用

public final class TraceMessageListenerImpl extends SipServlet implements MessageListener {
private MessageListener delegate;

public void init() throws ServletException {
ServletContext sc = (ServletContext) getServletContext();
TraceMessageListenerFactory factory = (TraceMessageListenerFactory) sc.getAttribute(TraceMessageListenerFactory.TRACE_MESSAGE_LISTENER_FACTORY);
delegate = factory.createTraceMessageListener(getServletConfig());
}
public final void onRequest(SipServletRequest req, boolean incoming) {
delegate.onRequest(req,incoming);
}
public final void onResponse(SipServletResponse resp, boolean incoming) {
delegate.onResponse(resp,incoming);
}
}

8.7.8 リスナとロギング サーブレットの起動順序

リスナとロギング サーブレットが両方ともデプロイされている場合は、最初にリスナ クラスがロードされ、その後でサーブレットがロードされます。各ロギング サーブレットがデプロイされる順序は、Web アプリケーションのデプロイメント記述子で指定されているロード順序に従います。

8.8 プロダクション デプロイメントにおける JVM ガベージ コレクションのチューニング

一般に、プロダクション環境の Oracle WebLogic Communication Services では、サーバ負荷のピーク時も含めて常時、クライアントに対して非常に短い応答時間 (50 ミリ秒未満) で応答できる必要があります。短い応答時間を維持するための重要な要件の 1 つは、Oracle WebLogic Communication Services のエンジン層のインスタンスで使用する JVM のガベージ コレクション (GC) アルゴリズムを正しく選択し、かつ適切な状態にチューニングすることです。

一部のチューニング方式はガベージ コレクションの平均時間を最短にすることや完全なガベージ コレクションの実行頻度を最小に抑えることを目的として設計されていますが、これらの方式では、長短の GC 間隔を組み合わせて総合的に GC の影響を軽減する方針が採用されているので、結果的に 1 回または数回、非常に時間のかかる (数秒間に及ぶことが多い) ガベージ コレクションが発生することがあります。プロダクション環境の SIP Server では、応答時間の目標を維持するために、長い GC 間隔が一切発生しないようにする必要があります。

以下の節では、JRockit を使用する場合と Sun の JVM を使用する場合のそれぞれについて、応答時間が最短となる最適なパフォーマンスを一般的に実現できるチューニング方式を説明します。

注意 :
JRockit の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server の紹介』を参照してください。

8.8.1 サーバ起動スクリプトでの JVM パラメータの変更

Oracle WebLogic Communication Services エンジンとレプリカを起動するためにカスタムの起動スクリプトを使用する場合、次の節で説明されている、推奨される JVM オプションを含むようにスクリプトを編集します。

新しいドメインをコンフィグレーションする場合、コンフィグレーション ウィザードではデフォルトの起動スクリプトもインストールされます。これらのスクリプトはデフォルトで MIDDLEWARE_HOME/user_projects/domains/domain_name/bin のディレクトリにインストールされており、以下が含まれています。

- startWebLogic.cmd、startWebLogic.sh — これらのスクリプトはドメインの管理サーバを起動します。

- startManagedWebLogic.cmd、startManagedWebLogic.sh — これらのスクリプトはドメインで管理対象のエンジンとレプリカを起動します。

エンジンとレプリカを起動するために Oracle のインストールしたスクリプトを使用する場合、コマンド シェルで USER_MEM_ARGS の環境変数をはじめに設定することで JVM メモリ引数をオーバーライドすることができます。

注意 :
USER_MEM_ARGS の環境変数を設定することで Oracle のインストールしたスクリプトで指定されたすべてのデフォルトの JVM メモリ引数をオーバーライドすることができます。常に使用する意向がある JVM メモリ引数の完全なリストに USER_MEM_ARGS を設定します。たとえば、デフォルトのヒープ領域 (-Xms、-Xmx) パラメータだけ変更する意向がある場合でも、Sun JVM を使用する場合、常に -XX:MaxPermSize=128m を USER_MEM_ARGS の値に追加します。

8.8.2 JRockit を使用したガベージ コレクションのチューニング

JRockit には、任意の時点の JVM ヒープを分析するために役立つ次のようなモニタリング ツールが用意されています。

- JRockit Runtime Analyzer - ガベージ コレクションの実行時の動作および休止時間を確認できます。

- JRockit スタック ダンプ - アプリケーションのスレッド アクティビティを調査して、トラブルシューティングまたはパフォーマンス向上、あるいはその両方に役立てることができます。

JVM の設定は、制御された環境でこれらのツールを使用することによって、その設定の効果や影響を事前に確認した上で、実際のプロダクション環境に適用してください。

以下の節では、JROCKIT JVM で使用する提案された起動時の JVM オプションについて説明します。確定的ガベージ コレクションで JRockit を使用すると (推奨)、節 8.8.3「Oracle JRockit Real Time の使用 (確定的ガベージ コレクション)」 で説明されたオプションを使用します。

8.8.3 Oracle JRockit Real Time の使用 (確定的ガベージ コレクション)

非常に短い応答時間が確定的ガベージ コレクションを実装する JRockit Real Time の使用によって達成される。

レプリケートされたクラスタ コンフィグレーションのエンジン層サーバに以下の JVM 引数を使用することをお勧めします。

-Xms1024m -Xmx1024m -XgcPrio:deterministic -XpauseTarget=30ms -XXtlasize:min=8k -XXnosystemgc

注意 :
コンフィグレーション ウィザードを使用して JRockit JVM による新しいドメインを作成する場合、上記の設定はデフォルトで $WLSS_HOME/common/bin/wlssCommenv.sh ファイルにコンフィグレーションします。
アロケーション インテンシブなアプリケーションに対して、-XpauseTarget 値を高める必要がある可能性があります。この値は、より小さいアプリケーションに対して軽負荷の下で減らすことができます。

デプロイ済みアプリケーションで使用される実データの量に応じて、ヒープ サイズを調整します。開始点として、ヒープ サイズをアプリケーションが必要とする合計の 2 から 3 倍まで設定します。必要な合計の 3 倍に近い値は、通常、最良のパフォーマンスをもたらします。

レプリカ サーバのため、利用可能なメモリの容量を増大させます。

-Xms3072m -Xmx3072m -XgcPrio:deterministic -XpauseTarget=30ms -XXtlasize:min=8k -XXnosystemgc

これらの設定はヒープ サイズを固定して、確定的ガベージ コレクションとともにダイナミック ガベージ コレクタを有効にします。-XpauseTarget は、最大の休止時間を設定し、-XXtlasize=3k はスレッド ローカルの領域サイズを設定します。-XXnosystemgc で System.gc() アプリケーションの呼をガベージ コレクションの強制から防ぎます。

8.8.4 確定的ガベージ コレクションなしでの Oracle JRockit の使用

確定的ガベージ コレクションなしで Oracle JRockit を使用すると (プロダクション デプロイメントでは推奨されません)、世代の同時ガベージ コレクタを使用することで最適な応答時間パフォーマンスが取得されます。

エンジン層サーバの起動オプション例の一覧は以下のとおりです。

-Xms1024m -Xmx1024m -Xgc:gencon -XXnosystemgc -XXtlasize:min=3k -XXkeeparearatio=0 -Xns:48m

注意 :
デプロイ済みアプリケーションで使用される実データの量に応じて、ヒープ サイズを微調整します。

レプリカ サーバの起動オプション例の一覧は以下のとおりです。

-Xms3072m -Xmx3072m -Xgc:gencon -XXnosystemgc -XXtlasize:min=3k -XXkeeparearatio=0 -Xns:48m

8.8.5 Sun JDK のガベージ コレクションのチューニング

Sun の JDK を使用する場合、ガベージ コレクションのパフォーマンス チューニングの目標は、完全なガベージ コレクションの 1 サイクルの実行に要する時間を短縮することです。完全なガベージ コレクションの発生頻度を最小限に抑えようとすると、多くの場合、結果的に、完了までに数秒を要する強制的なガベージ コレクション サイクルの発生を招くことになるので、JVM に対してそのようなチューニングを行うことは避けてください。

プロダクション サーバのライフタイムにおけるガベージ コレクション時間の短縮を実現する最も単純で信頼性の高い方法は、ヒープのサイズを固定してデフォルト コレクタと若い世代用の並行コレクタを使用することにより、新しい世代のサイズを最大でもヒープ全体の 1/3 までに制限することです。

ほとんどのエンジン層サーバには以下の JVM 設定例をお勧めします。

-server -Xmx1024m -XX:MaxPermSize=128m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+UseTLAB -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:CMSIncrementalDutyCycleMin=0 -XX:CMSIncrementalDutyCycle=10 -XX:MaxTenuringThreshold=0 -XX:SurvivorRatio=256 -XX:CMSInitiatingOccupancyFraction=60 -XX:+DisableExplicitGC

レプリカ サーバには、以下の設定例を使用します。

-server -Xmx3072m -XX:MaxPermSize=128m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+UseTLAB -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:CMSIncrementalDutyCycleMin=0 -XX:CMSIncrementalDutyCycle=10 -XX:MaxTenuringThreshold=0 -XX:SurvivorRatio=256 -XX:CMSInitiatingOccupancyFraction=60 -XX:+DisableExplicitGC

上記のオプションには、それぞれ次のような効果があります。

- -XX:+UseTLAB - スレッド ローカルのオブジェクト割り当てブロックを使用します。これにより、共有ヒープ ロックに対する競合の発生が減少して、同時実行性が向上します。

- -XX:+UseParNewGC - 同時 mark-and-sweep コレクタとともに、若い世代用の並行バージョンのコピー コレクタを使用します。これにより、使用可能なすべての CPU が並行して使用されるようになり、休止時間を最小限に抑えられます。この若い世代用のコレクタは、デフォルト コレクタおよび同時マーク アンド スイープ (CMS) コレクタのどちらとも併用できます。

- -Xms, -Xmx - ヒープ サイズに境界を設け、ガベージ コレクションが予測どおりに実行される可能性を高めます。レプリカ サーバでヒープ サイズが制限されているので、完全な GC の実行時にも SIP の再送信が発生することがなくなります。-Xms ヒープの拡張を原因とする休止の発生を防ぐように起動時のヒープ サイズを設定します。

- -XX:MaxTenuringThreshold=0 - すべての NewGC サイクルで NewSize の全体を使用できるようにして、寿命の長いオブジェクト (tenured object) の評価を不要にすることにより、休止時間を短縮します。より技術的に言えば、この設定は、生存しているすべてのオブジェクトを (コピーするのではなく) 古い世代に昇格させることを意味します。

- -XX:SurvivorRatio=128 - 上記のゼロのしきい値の指定によって、生存しているすべてのオブジェクトを寿命の長いオブジェクトと見なすように設定した場合は、このように SurvivorRatio を高く設定することによって、実際には存在しない Survivor オブジェクトのために大きな領域が確保されることを防止できます。

8.9 乱数生成に伴う JVM の遅延の回避

Sun の JVM で乱数を生成するために使用されるライブラリは、UNIX プラットフォームではデフォルトで /dev/random に依存します。一部のオペレーティング システムでは、ホスト マシン上で一定量の「ノイズ」が生成されるのを待ってから結果を返すため、/dev/random が使用されていると、Oracle WebLogic Communication Services のプロセスがブロックされるおそれがあります。セキュリティ上は /dev/random の方がより安全ですが、JVM のデフォルトのコンフィグレーションで Oracle WebLogic Communication Services の起動時に遅延が発生する場合は、その代わりに /dev/urandom を使用することをお勧めします。

実際に使用しているオペレーティング システムでこの遅延の問題が発生するかどうかを確認するには、このファイルの一部分を表示する次のコマンドをシェル プロンプトから実行します。

head -n 1 /dev/random

1. テキスト エディタを使用して $JAVA_HOME/jre/lib/security/java.security ファイルを開きます。

2. 以下の行を編集します。

securerandom.source=file:/dev/random

以下のように変更します。

securerandom.source=file:/dev/urandom

3. 変更を保存して、テキスト エディタを終了します。

第 II 部

Presence のコンフィグレーション

以下の章があります。

- 第 9 章「Presence および Presence Web Services のコンフィグレーション」

9 Presence および Presence Web Services のコンフィグレーション

この章では、Oracle WebLogic Communication Services (OWLCS) の概要について説明します。以下の節で構成されています。

- 節 9.1「プレゼンスの概要」

- 節 9.2「プレゼンスのコンフィグレーション」

- 節 9.3「Presence Web Services のコンフィグレーション」

9.1 プレゼンスの概要

プレゼンスは、エンドユーザの状態、およびチャットや高性能なマルチメディアによる対話に参加できる可能性を表示するために使用されます。 多くの場合、クライアントのプレゼンスは連絡先管理リストとして表示され、ユーザの状態がアイコンとして表示されます。 これらのアイコンによって、ユーザの状態だけでなく、ユーザのロケーション、連絡手段、現在のアクティビティも表示され、ユーザ間の効率的なコミュニケーションが実現します。

Presence アプリケーションでは、サービス プロバイダまたは企業がエンドユーザに対するプレゼンス サービスを拡張できます。 以下の主な機能があります。

- プレゼンス ステータスのパブリケーション

- プレゼンス ステータスのサブスクリプション

- プライバシー

- プレゼンスのハード状態

プレゼンス ステータスのパブリケーション

ここで、「プレゼンティティ」という用語は、「プレゼンス エンティティ」(プレゼンス エンティティ [プレゼンティティ] とは、コミュニケーションの能力と意思によって定義される、人などのエンティティです) を表すために使用されます。 プレゼンティティは、プレゼンス状態が含まれた Presence Information Data Format (PIDF) ドキュメントを Presence サーバにパブリッシュできます。

プレゼンス ステータスのサブスクリプション

Presence サーバではプレゼンティティの (つまりユーザの) ステータスへのサブスクリプションがサポートされています。Presence サーバでは「ウォッチャ情報イベント パッケージ」がサポートされています。このイベント パッケージでは、ウォッチャがプレゼンティティのプレゼンス状態にサブスクリプトすると、直ちにプレゼンティティに通知されます。ウォッチャ (サブスクライバ) がプレゼンティティのステータスを表示する許可を要求すると、Presence サーバはユーザに通知します。また、Presence サーバは、許可されたすべてのアクティブなウォッチャに新しいプレゼンス ドキュメントのパブリケーションを通知します。

プライバシー

プレゼンティティは、プレゼンス状態の特定の部分の表示のみを特定のウォッチャに許可するフィルタ処理ルールを作成できます。ウォッチャがプレゼンティティのプレゼンスにサブスクライブすると、Presence サーバはプレゼンティティが設定した許可ポリシーを常にチェックして、ウォッチャに必要な許可があるかどうかを確認します。

一致するルールが見つからない場合、ウォッチャは保留状態に置かれ、ウォッチャ情報の通知がプレゼンティティに送信されます。通常は、プレゼンティティのクライアント (ユーザ エージェント) によって、新しい保留中のウォッチャの許可または拒否をたずねるポップアップ ボックスが表示されます。回答は、このウォッチャに対するルールの形式でプレゼンティティの許可ポリシー ドキュメントに追加されます。このドキュメントは HTTP を使用して、クライアントによって XDMS 上で更新されます。ドキュメントが更新されると、Presence サーバは新しいポリシー ドキュメントを読み取って新しいルールに従って動作し、必要に応じてサブスクリプション状態を変更します。

プレゼンスのハード状態

プレゼンティティはプレゼンスに関するハード状態のメモを残すことができます (休暇の予定がある場合など : '休暇中 - 15 日に出社')。このプレゼンティティのプレゼンス状態のウォッチャは、この情報を表示できます。

9.2 プレゼンスのコンフィグレーション

Presence サーバは、以下の MBean を通じてコンフィグレーションされます。

- 節 9.2.1「XDMS のコンフィグレーション」

- 節 9.2.2「Bus」

- 節 9.2.3「PackageManager」

- 節 9.2.4「Presence」

- 節 9.2.5「PresenceEventPackage」

- 節 9.2.6「PresenceWInfoEventPackage」

- 節 9.2.7「UA-ProfileEventPackage」

- 節 9.2.8「Command Service (XDMS プロビジョニング)」

- 節 9.2.9「XCapConfigManager」

- 節 9.2.10「Aggregation Proxy」

- 節 9.2.11「OPTIONS 用のデフォルト アプリケーション ルータのコンフィグレーション」

9.2.1 XDMS のコンフィグレーション

以下の MBean を使用して、XDMS (XML Document Management Server) をコンフィグレーションできます。

- Command Service (XDMS プロビジョニング)

- XCapConfigManager

注意 :
以下の MBean のいずれかの属性を変更した場合、それらの変更を有効にするには OWLCS を再起動する必要があります。

- Presence

- PresenceEventPackage

- PresenceWInfoEventPackage

- UAProfileEventPackage

- XCapConfigManager

注意 :
JGroups チャネルは、目的のピアとのみ通信する必要があります。イベント パッケージで JGroups が正しく使用されるようにするには、異なるチャネルがグループ名、マルチキャスト アドレス、およびマルチキャスト ポートの異なる値を使用する必要があります。詳細については、http://www.jboss.org/ を参照してください。

9.2.2 Bus

Bus MBean を通じて、Presence サーバが内部ジョブの実行に使用する内部非同期バスをコンフィグレーションできます。表 9-1 では、Bus MBean の属性について説明します。

表 9-1 Bus MBean の属性

属性

値の型

説明

ThreadPoolSize

int

アプリケーションの有効期間を通じて整合性が維持される、スレッド プールに保持されたスレッドの数。スレッドが使用されない場合は、指定された数のスレッドがアイドル状態のままになります。デフォルト値は 15 です。

HighWatermark

int

バスの不足しきい値レベルに達するまでの、保留中のジョブの上限の数。デフォルト値は 20 です。

KeepAlive

long

削除する前のアイドル状態のスレッドをアライブに維持する秒数。デフォルト値は 60 です。

LogDuration

long

キューのイベントの保持期間が、バスにブロードキャストされるまでの指定期間を超えると、システム ログに警告が記録されます。この警告は、古いジョブがバスに送信されたため、サーバがオーバーロードとなることを示しています。デフォルト値は 60 です。

LowWatermark

int

保留中のジョブ数の低位しきい値レベルを指定します。低い値からこのしきい値に達すると、バスが一杯になることを示す警告がログに記録されます。この時点では、高位のウォーターマーク レベルに達するまで、それ以上の警告は記録されません。デフォルト値は 15 です。

9.2.3 PackageManager

PresenceEventPackage、PresenceWInfoEventPackage、および UA-ProfileEventPackage MBean では、通知者がウォッチャ (サブスクライバ) に報告する状態情報を定義しているイベント パッケージをコンフィグレーションできます。これらのパッケージは、ほとんどのリクエストがこれらを通過するため、Presence サーバの中心となります。

通知者とは、ウォッチャにリソース (ウォッチャが状態情報を要求しているエンティティ) の状態を通知する NOTIFY リクエストを生成するユーザ エージェント (UA) です。通知者は通常、サブスクリプションを作成する SUBSCRIBE リクエストを許可します。ウォッチャは別のタイプの UA であり、通知者によってパブリッシュされた NOTIFY リクエストを受信します。これらのリクエストには、ウォッチャが関心を持っているリソースの状態に関する情報が含まれています。ウォッチャは通常 SUBSCRIBE リクエストを生成し、これらのリクエストを通知者に送信してサブスクリプションを作成します。

PackageManager MBean は、3 つのイベント パッケージ (Presence、Watcher Info、および UA-Profile) のうちロードされるパッケージを決定するコンフィグレーションを設定します。また、これらのイベント パッケージがロードされる環境をコンフィグレーションします。表 9-2 では、PackageManager MBean の属性について説明します。

表 9-2 EventPackageManager MBean の属性

属性

説明

JGroupBroadcastEnabled

true の場合は、この Presence サーバ インスタンスで実行中のすべてのイベント パッケージに対して単一の JGroup チャネルが作成されます。実行中のいずれかのイベント パッケージで新しいリソースが作成されるたびに、この JGroup チャネルでメッセージがブロードキャストされます。

JGroupXMLConfigPath

JGroups の XML コンフィグレーション ファイルへのパス。絶対パスまたはイベント パッケージが実行中の WebLogic ドメイン ディレクトリへの相対パスを指定できます。jgroups 接続の以下のデフォルト値を使用するには、空のままにします : UDP(bind_addr=[ip address of this host];mcast_addr=230.0.0.1;mcast_port=7426;ip_ttl=1)

JGroupChannelName

JGroup チャネルの作成で使用する名前。異なる JGroup クラスタのエリアスを防ぐため、各クラスタには一意のマルチキャスト ポートまたはアドレスに加えて、一意のチャネル名が必要です。

CaseSensitiveUserPart

この属性を true に設定すると、SIP URI のユーザ部分が大文字と小文字を区別して処理されます。このパラメータを false に設定すると、URI のユーザ部分の照合で大文字と小文字が区別されません。たとえば、foo は FoO と同じであると見なされます。URI のドメイン部分では常に大文字と小文字が区別されません。

EventPackageNames

イベント パッケージ名のカンマ区切りのリスト。たとえば、presence,presence.winfo,ua-profile などです。このリストにあるイベント パッケージのみが Presence サーバによって起動されます。

WaitingSubsCleanupInterval

サブスクリプション クリーンアップ チェックが実行される秒単位の間隔。スレッドはこの期間スリープした後、MaxWaitingSubsTimeHours パラメータよりも古いタイムスタンプを持つ待機中のサブスクリプションのチェックを開始します。すべての古いサブスクリプションは、サブスクライブされたリソースから削除されます。

Max WaitingSubsTimeHours

サーバが削除する前に、サブスクリプションが待機状態を維持できる最大時間数。このパラメータは、サブスクリプション クリーンアップ チェック スレッド (waitingsubscleanupinterval) によって、待機中のサブスクリプションがサブスクライブされたリソースから削除できる十分に古いものであるかどうかを判別するのに使用されます。

9.2.4 Presence

Presence MBean は、Presence サーバが接続中のクライアントと対話する方法を制御します。 属性 (表 9-3 で説明) には、プレゼンティティが複数のクライアントからプレゼンス ドキュメントをパブリッシュしている場合に統合されたドキュメントを作成するための複合ポリシーを設定する属性や、ブロッキング、フィルタ処理、およびプレゼンスのハード状態を設定する属性が含まれています。

表 9-3 Presence MBean の属性

属性

説明/値

CompositionPolicyFilename

複合ポリシー ドキュメントのファイル名。値には、OWLCS 複合ポリシー用の compose.xslt、および OMA 複合ポリシー用の compose_OMA.xslt があります。

DefaultSubHandling

認証されたユーザのプレゼンス ルールが見つからない場合に、サーバで決定されるデフォルトのサブスクリプションの許可。定義された値は、以下のとおりです。

- block

- confirm

- polite-block

ルールが見つからない場合、認証されていないユーザは常にブロックされます。

DocumentStorageFactory

DocumentStorage ファクトリ クラスの名前。 デフォルト値は oracle.sdp.presenceeventpackage.document.XMLDocumentStorageFactoryImpl です。

DocumentStorageRootUrl

ドキュメントを格納するためのシステム識別子。ファイル ストレージの場合は、ドキュメントが格納されたルート ファイルの URL パスです。このディレクトリの内容は、サーバの再起動時に削除されます。デフォルト値は file:/tmp/presencestorage/ です。

DocumentStorageType

プレゼンス ドキュメントに使用されるストレージの種類。有効な値は、以下のとおりです。

- file

- memory

デフォルト値は memory です。

HttpAssertedIdentityHeader

Presence サーバから XDMS へのすべての HTTP リクエストで使用されるアサートされた ID ヘッダの種類。この属性には XDMS で予期される値を設定します。有効な値は、以下のとおりです。

- X_3GPP_ASSERTED_IDENTITY

- X_3GPP_INTENDED_IDENTITY

- X_XCAP_ASSERTED_IDENTITY (デフォルト値)

PidfManipulationAuid

「ハード状態」としても知られる、PIDF (Presence Information Data Format) 操作に対するアプリケーション使用状況の ID。 デフォルト値は pidf-manipulation です。

PidfManipulationDocumentName

pidf 操作のアプリケーション使用状況のドキュメント名。たとえば、hardstate などです。 デフォルト値は hardstate です。

PidfManipulationEnabled

PIDF 操作を有効にするには true (デフォルト値) に設定します。

PidfManipulationXcapUri

pidf 操作のアプリケーション使用状況に対する XDMS の SIP URI。 デフォルト値は sip:127.0.0.1;transport=TCP;lr です。 サーバが正しく機能するためには、SIP URI に loose route (lr) パラメータが含まれている必要があります。

PoliteBlockPendingSubscription

保留中のサブスクリプションを polite-blocked にする必要がある場合は、true に設定します。 この機能は、保留中のサブスクリプションのあるプレゼンス ウォッチャからプレゼンティティを隠し、代わりに偽のプレゼンス ドキュメントを送信するために使用します。false に設定すると、サブスクリプションは保留のまま残ります。

PresRulesAuid

presrules のアプリケーション使用状況の ID。デフォルトは pres-rules です。

PresRulesDocumentName

presrules のアプリケーション使用状況のドキュメント名。デフォルト値は presrules です。

PresRulesXcapUri

プレゼンス ルール アプリケーション使用状況に対する XDMS の SIP URI。デフォルト値は sip:127.0.0.1;transport=TCP;lr です。 サーバが正しく機能するためには、SIP URI に loose route (lr) パラメータが含まれている必要があります。

PrivacyFilteringEnabled

プライバシー フィルタ処理を有効にするには、true に設定します。 フィルタ処理を無効にするには、false に設定します。 プライバシー フィルタ処理を無効にすると、プレゼンティティのプレゼンスの表示を許可されたすべてのサブスクリプションで、そのプレゼンティティのパブリッシュされているすべての項目を常に参照できます。

TransformerFactory

TransformerFactory クラスの名前。 デフォルト値は oracle.xml.jaxp.JXSAXTransformerFactory です。

9.2.5 PresenceEventPackage

表 9-4 では、PresenceEventPackage MBean の属性について説明します。 プレゼンス イベント パッケージには、publish と subscribe という 2 つのサブグループがあります。各サブグループには minexpires および maxexpires というパラメータがあります。クライアントは、サブスクリプションまたはパブリッシュ済みの状態の有効期限を示す場合がありますが、示された時間がコンフィグレーション済みの minExpires より短い場合、サーバは 423 (間隔が短すぎる) の応答を返します。

クライアントがコンフィグレーション済みの最大有効期限よりも長い有効期限を示した場合、サーバは示された時間をこのコンフィグレーション済みの時間に短縮します。サーバが選択した値は、リクエストに対する応答で常に送信されます。

パブリケーションまたはサブスクリプションのアライブ状態を維持するため、クライアントは有効期限内に republish または resubscribe をサーバに送信します。クライアントは、パブリケーションまたはサブスクリプションの有効期間中、このタスクを繰り返し実行する必要があります。

表 9-4 PresenceEventPackage の属性

属性

値/説明

Description

PresenceEventPackage の説明。 例 : The event package that enables presence.

DocumentFactory

DocumentFactory クラス名。 デフォルト値は oracle.sdp.presenceeventpackage.document.PresenceDocumentFactoryImpl です。

EscMaxDocumentSize

パブリケーション コンテンツのバイト単位の最大サイズ。指定されたサイズより大きいドキュメントをクライアントがパブリッシュしようとすると、サーバは 413 の応答 (リクエスト エンティティが長すぎる) を送信します。デフォルト値は 10000 です。

ESCMaxExpires

パブリケーションの有効期限の最大値 (秒単位)。デフォルト値は 3600 です。

ESCMaxPubPerRes

リソースごとに許可されているパブリケーションの最大数。新しいパブリッシュを受信したときにリソースの最大数に達すると、サーバは 503 の応答 (サービス使用不可) を送信します。

ESCMinExpires

パブリケーションの有効期限の最小値 (秒単位)。デフォルト値は 60 です。

EventStateCompositor

EventStateCompositor のクラス名。 デフォルト値は oracle.sdp.presenceeventpackage.PublishControl です。

Name

このイベント パッケージの名前。デフォルト値は Presence です。

Notifier

Notifier クラスの名前。 デフォルト値は oracle.sdp.presenceeventpackage.PresenceSubscriptionControl です。

NotifierMaxDocumentSize

SUBSCRIBE リクエストの最大サイズ。

NotifierMaxExpires

SUBSCRIBE の有効期限の最大値 (秒単位)。デフォルト値は 3600 です。

NotifierMaxNoOfSubsPerRes

リソースごとに許可されているサブスクリプションの最大数。リソースの最大数に達すると、新しいプレゼンス サブスクライブが受信され、サーバは 503 の応答 (サービス使用不可) を送信します。

NotifierMinExpires

SUBSCRIBE の有効期限の最小値 (秒単位)。

ResourceManagerClassName

ResourceManager クラスの名前。 デフォルトは oracle.sdp.presenceeventpackage.PresentityManagerImpl です。

9.2.6 PresenceWInfoEventPackage

RFC 3857 で規定されているように、ウォッチャ情報イベント パッケージは、別のイベント パッケージのリソースをモニタして、そのリソースに対するすべてのサブスクリプションの状態を確認します。その後、この情報は、ウォッチャ情報イベント パッケージのサブスクライバに送信されます。その結果、ウォッチャはモニタ対象のリソース サブスクリプションでの変化を認識します。

PresenceWInfoEventPackage MBean (表 9-5 で説明) は、ウォッチャ情報イベント パッケージに対するサブスクリプション状態情報を設定します。

表 9-5 WatcherinfoEventPackage の属性

属性

説明/値

Description

PresenceWInfoEventPackage の説明。 例 : The event package that enables watcherinfo.

DocumentFactory

DocumentFactory クラスの名前。 デフォルトは oracle.sdp.eventnotificationservice.DocumentFactoryImpl です。

Name

イベント パッケージの名前。デフォルト値は presence.winfo です。

Notifier

Notifier クラス名。 デフォルト値は oracle.sdp.presenceeventpackage.PresenceSubscriptionControl です。

NotifierMaxDocumentSize

SUBSCRIBE リクエストの最大ドキュメント サイズ。

NotifierMaxExpires

SUBSCRIBE の有効期限の最大値 (秒単位)。デフォルト値は 3600 です。

NotifierMaxNoSubsPerRes

リソースごとに許可されているサブスクリプションの最大数。新しいプレゼンス サブスクライブを受信したときにリソースの最大数に達すると、サーバは 503 の応答 (サービス使用不可) を送信します。デフォルト値は 100 です。

NotifierMinExpires

SUBSCRIBE の有効期限の最小値 (秒単位)。

ResourceManagerClassName

ResourceManager クラスの名前。 デフォルトは oracle.sdp.winfoeventpackage.WatcherinfoResourceManager です。

9.2.7 UA-ProfileEventPackage

表 9-6 では、UA-ProfileEventPackage MBean の属性について説明します。

表 9-6 UA-ProfileEventPackage の属性

属性

説明/値

Description

UA-ProfileEventPackage の説明。デフォルト値は The event package that enables the ua-profile です。

Document Factory

Document Factory クラス名。 デフォルト値は以下のとおりです。

oracle.sdp.eventnotificationservice.DocumentFactoryImpl

Name

イベント パッケージの名前。デフォルト値は ua-profile です。

Notifier

Notifier クラスの名前。 デフォルト値は oracle.sdp.presenceeventpackage.PresenceSubscriptionControl です。

NotifierMaxDocumentSize

SUBSCRIBE リクエストの最大ドキュメント サイズ。

NotifierMaxExpires

SUBSCRIBE の有効期限の最大値 (秒単位)。デフォルト値は 6000 です。

NotifierMaxNoOfSubsPerRes

リソースごとに許可されているサブスクリプションの最大数。新しいプレゼンス サブスクライブを受信したときにリソースの最大数に達すると、サーバは 503 の応答 (サービス使用不可) を送信します。デフォルト値は 100 です。

NotifierMinExpires

SUBSCRIBE の有効期限の最小値 (秒単位)。デフォルト値は 60 です。

ResourceManager

Resource Manager クラスの名前。 デフォルト値は以下のとおりです。

oracle.sdp.winfoeventpackage.WatcherinfoResourceManager

9.2.8 Command Service (XDMS プロビジョニング)

Command Service MBean は、XDMS に対するユーザ プロビジョニングを有効にします。

9.2.9 XCapConfigManager

XCapConfigManager MBean は、XDMS のコンフィグレーション、ユーザ プレゼンス ルールを含む XML ドキュメントのリポジトリ、およびハード状態情報を制御します。 XDMS が Presence サーバの外部にある場合、XCapConfigManager MBean の設定は無視できます。

表 9-7 XCapConfigManager MBean の属性

属性名

説明/値

CreateNonExistingUserstore

ドキュメントを格納するときにユーザ ストアが存在せず、ユーザ ストアを作成する場合は、true に設定します。それ以外の場合は、false に設定します。このパラメータが false に設定されている場合、存在しないユーザのドキュメントをクライアントが格納しようとすると、格納は失敗します。このパラメータが true に設定されている場合は、まず XDMS にユーザを作成してから、ドキュメントを格納します。デフォルト値は true です。

MaxContentLength

XCAP リクエストのバイト単位の最大サイズ。デフォルトは 1MB です。

ドキュメントのサイズは増減できます。ドキュメント サイズを増やす場合は、XDMS ドキュメント×ユーザ数×アプリケーション数に見合う十分なディスク容量があることを確認してください。ドキュメント当たりのサイズを小さくする場合、この計算は、(max_doc_size_n×ユーザ数) の合計に縮小されます。ここで、各 max_doc_size_n は、アプリケーション n ごとに固有です。

リソース リスト ドキュメントのデフォルト サイズも 1 MBです。

PersistenceRootUrl

XDMS ドキュメントの格納場所。 デフォルトは jpa:xdms であり、これは、インストール時にコンフィグレーションされた JDBC コネクタを通じてドキュメントが Oracle データベースに永続化されることを意味します。永続的な場所をファイルシステムに変更するには、ファイル URL を使用してください (たとえば、file:/tmp/var/xcaproot の値を使用すると、格納場所がローカル ファイルシステム上の /tmp/var/xcaproot ディレクトリに設定されます)。ローカル ファイルシステムを選択した場合は、Presence サーバを実行中のユーザによるディレクトリへの書き込みが可能であることを確認してください。

PidfManipulationAuid

PIDF (Presence Information Data Format) 操作に対するアプリケーション使用状況の ID。デフォルト値は pidf-manipulation です。

PidfManipulationDocname

pidf 操作のアプリケーション使用状況のドキュメント名。たとえば、hardstate などです。

デフォルト値は hardstate です。

PresRulesAU

pres-rules アプリケーション使用状況の名前。デフォルト値は pres-rules です。

PresRulesDocName

pres-rules ドキュメントの名前。デフォルト値は presrules です。

PublicContentServerRootUrl

パブリック コンテンツ サーバ ルートへの URL。URL には、コンテンツ サーバのパブリック URL を設定する必要があります (つまり、認証 HTTP プロキシ サーバの URL)。

PublicXCAPRootUrl

パブリック XDMS ルートへの URL。http://<your.xdms.domain.com>/services/ のように入力します。たとえば、http://127.0.0.1:8001/services などです。

RequireAssertedIdentity

すべての HTTP/XDMS リクエストでアサートされた ID ヘッダが必要な場合は、true に設定します。それ以外の場合は、このパラメータを false に設定します。この属性を true に設定した場合は、すべての XCAP トラフィックが節 9.2.10「Aggregation Proxy」によって認証を受ける必要があります。 この属性を true に設定した場合、アサートされた ID のない着信 XCAP リクエストはアクセスを拒否されます。

9.2.10 Aggregation Proxy

Aggregation Proxy は、XCAP クライアントおよび Web サービス呼び出しのサーバ側エントリ ポイントであり、ID アサーションを提供することで着信トラフィックを認証します。このコンポーネントは、Presence サーバと XDMS を格納する信頼性のあるドメインに対する門番の役割を果します。

Aggregation Proxy MBean の属性 (表 9-8) を使用すると、XDMS に適した ID アサーションの種類を設定できます。 また、Aggregation Proxy からプロキシされるトラフィックを受け取る Web サーバおよび XDMS のホストとポートを設定できます。

表 9-8 Aggregation Proxy の属性

属性

説明

AssertedIdentityType

プロキシされる HTTP リクエストに挿入される、XDMS に適した ID ヘッダに対応する番号を入力します。

1. X_3GPP_ASSERTED_IDENTITY (デフォルト)

2. X_3GPP_INTENDED_IDENTITY

3. X_XCAP_ASSERTED_IDENTITY

ContentHost

Aggregation Proxy がプロキシされたリクエストを送信するコンテンツ サーバのホスト名。

ContentPort

Aggregation Proxy がプロキシされたリクエストを送信するコンテンツ サーバのポート番号。

ContentRoot

コンテンツ サーバのルート URL。

IgnoreUserpartCase

大文字と小文字を区別してユーザ名を処理する必要がない場合は、true に設定します。

Realm

P-Asserted-Identity ヘッダに挿入される sip/sips アドレスの作成に使用するレルム (example.com など)。

TrustedHosts

信頼性のあるホストの IP アドレスのカンマ区切りのリスト。このリストにアドレスが含まれていないリクエストからは、Asserted Identity ヘッダが削除されます。

XCAPHost

Aggregation Proxy がリクエストをプロキシする XDMS のホスト名。

XCAPPort

Aggregation Proxy がリクエストをプロキシする XDMS のポート。

XCAPRoot

XDMS のルート URL。

9.2.11 OPTIONS 用のデフォルト アプリケーション ルータのコンフィグレーション

OPTIONS リクエストを処理する DAR をコンフィグレーションするには、以下の手順を実行します。

1. ブラウザでコンソール アプリケーションを開きます (たとえば、http://owlcs.example.com:7001/console)。

2. ユーザ名とパスワードを入力してログインします。

3. 左ペインで、[SIP サーバ] をクリックします。

4. [アプリケーション ルータ] タブをクリックします。

5. AR コンフィグレーション データの下で、proxyregistrar を通じて OPTIONS リクエストをルーティングする場合は、次のように入力します。

OPTIONS: ("proxyregistrar", "DAR:From", "TERMINATING", "", "NO_ROUTE", "0")

または、OPTIONSResponder アプリケーションを通じてリクエストをルーティングする場合は、次のように入力します。

OPTIONS : ("optionsresponder", "DAR:From", "TERMINATING", "", "NO_ROUTE",
"0")

注意 :
後者の DAR コンフィグレーションを選択する場合は、ドメインの拡張時に Options Responder アプリケーションを選択している必要があります。

9.3 Presence Web Services のコンフィグレーション

OWLCS を使用すると、Web サービス クライアントは、「Open Service Access, Parlay X Web Services, Part 14, Presence ETSI ES 202 391-14」で定義されている Parlay X Presence Web Service のサポートを通じて、プレゼンス サービスにアクセスできます。Parlay X Web Service では、HTTP Web サービス クライアントが、プレゼンス情報をパブリッシュおよびサブスクライブするプレゼンス サービスにアクセスできます。Parlay X Presence Web Service では、このような Web ベースのクライアントを開発するのに SIP プロトコルに精通している必要はありません。Web 開発者は、Web サービスの知識を利用してこのようなクライアントを作成できます。

Presence Web Services アプリケーションには、Web サービス デプロイメント サーバのコンフィグレーションを可能にする以下の MBean が含まれています。

- 節 9.3.1「PresenceSupplierWebService」

- 節 9.3.2「PresenceConsumerWebService」

- 節 9.3.3「MessagingWebServiceConfig」

上記の MBean には、プレゼンス コンシューマおよびプレゼンス サプライヤ インタフェースの OWLCS 実装を通じて可能になる、プレゼンス パブリケーションおよびウォッチャ サブスクリプションを管理するための属性が含まれています。

9.3.1 PresenceSupplierWebService

PresenceSupplierWebService MBean (表 9-9 で説明) を使用すると、ウォッチャに対してパブリッシュされたプレゼンス データを管理できます。 aggregation proxy mbean のコンフィグレーションに関する詳細については、節 9.2.10「Aggregation Proxy」を参照してください。

表 9-9 PresenceSupplierWebService MBean の属性

属性

説明

Expires

プレゼンス ステータスの PUBLISH に対するデフォルトの有効期限 (秒単位)。この属性に入力する値は、SessionTimeout 属性に対する入力に合わせて最適化する必要があります。

PIDFManipulationAU

PIDF (Presence Information Data Format) 操作に対するアプリケーション使用状況の名前。デフォルト値は pidf-manipulation です。

PidfManipulationDocname

pidf 操作のアプリケーション使用状況のドキュメント名。たとえば、hardstate などです。URI で IP アドレスの代わりにドメイン名が含まれている場合は、DNS サーバをコンフィグレーションする必要があります。

デフォルト値は hardstate です。この値は、XDMS のコンフィグレーションで入力した値と一致する必要があります。

PresRulesAU

pres-rules アプリケーション使用状況の名前。デフォルト値は pres-rules です。

PresRulesDocname

pres-rules ドキュメントの名前。デフォルト値は presrules です。

PublicXCAPRootUrl

パブリック XDMS ルートへの URL。http://<your.xdms:domain.com>/services/ のように入力します。 たとえば、http://127.0.0.1:8001/services などです。

SessionTimeout

HTTP セッションのタイムアウト (秒単位)。この属性に入力する値は、Expires 属性に対する入力値に合わせて最適化する必要があります。 このタイムアウトは、新しいセッションに対してのみ有効です。

SIPOutboundProxy

すべてのリクエストが最初のホップで送信される発信プロキシ サーバの IPアドレス。このアドレスは、以下の形式で入力します。

sip:<IP address>[:port];lr;transport=TCP

このアドレスにはデフォルト ポート (5060) を入力することもできます。たとえば、sip:127.0.0.1:5060;lr;transport=TCP などと入力します。

この属性を定義しない場合、発信プロキシは使用されません。

9.3.2 PresenceConsumerWebService

PresenceConsumerWebService MBean (表 9-10 で説明) を使用すると、ウォッチャのサブスクリプション期間を設定できます。

表 9-10 PresenceConsumerWebService MBean の属性

属性

値

Expires

ウォッチャ サブスクリプションのデフォルトの有効期間 (秒単位)。この属性に入力する値は、SessionTimeout 属性に対する入力値に合わせて最適化する必要があります。

SessionTimeout

HTTP セッションのタイムアウト (秒単位)。この属性に入力する値は、Expires 属性に対する入力値に合わせて最適化する必要があります。 このタイムアウトは、新しいセッションに対してのみ有効です。

SIPOutboundProxy

すべてのリクエストが最初のホップで送信される発信プロキシ サーバの IPアドレス。このアドレスは、以下の形式で入力します。

sip:<IP address>[:port];lr;transport=TCP

このアドレスにはデフォルト ポート (5060) を入力することもできます。たとえば、sip:127.0.0.1:5060;lr;transport=TCP などと入力します。

この属性を定義しない場合、発信プロキシは使用されません。

9.3.3 MessagingWebServiceConfig

MessagingWebServiceConfig (表 9-11 で説明) を使用すると、Web サービスで格納されたメッセージを削除する方法およびタイミングを指定できます。

表 9-11 MessagingWebServiceConfig の属性

属性

値

SessionTimeout

HTTP セッションのタイムアウト (秒単位)。この属性に入力する値は、Expires 属性に対する入力値に合わせて最適化する必要があります。 このタイムアウトは、新しいセッションに対してのみ有効です。

SIPOutboundProxy

すべてのリクエストが最初のホップで送信される発信プロキシ サーバの IPアドレス。このアドレスは、以下の形式で入力します。

sip:<IP address>[:port];lr;transport=TCP

この属性を定義しない場合、発信プロキシは使用されません。

MessageLifetime

メッセージ ストアのメッセージの有効期限が切れるまでの秒単位の時間を設定します。この属性を 0 に設定すると、メッセージが無期限にストアに保持されます (期限切れになりません)。メッセージは、MessageLifetime + MessageScanPeriod の最大秒数までメッセージ ストアに残ります。設定した属性は直ちに反映されます (たとえば、値を少なくすると、有効期間よりも古いメッセージは直ちに期限切れになります)。

MessageScanPeriod

有効期限が切れたメッセージをスキャンおよび削除する期間を秒単位で設定します。0 に設定すると、スキャンが無効になります。設定した属性は直ちに反映されます。

第 III 部

Diameter のコンフィグレーション

以下の章があります。

- 第 10 章「Diameter クライアント ノードとリレー エージェントのコンフィグレーション」

10 Diameter クライアント ノードとリレー エージェントのコンフィグレーション

以下の節では、Oracle WebLogic Communication Services ドメイン内の個々のサーバを Diameter ノードまたはリレー エージェントとして使用するためのコンフィグレーションの方法について説明します。

- 節 10.1「Diameter プロトコルのコンフィグレーションの概要」

- 節 10.2「Diameter クライアント ノードとリレー エージェントをコンフィグレーションする手順」

- 節 10.3「Diameter ドメインのインストール」

- 節 10.4「Diameter コンソール拡張の有効化」

- 節 10.5「Diameter プロトコルの TCP、TLS、および SCTP ネットワーク チャネルの作成」

- 節 10.6「Diameter ノードのコンフィグレーション」

- 節 10.7「ドメインのコンフィグレーション例」

- 節 10.8「Diameter コンフィグレーションのトラブルシューティング」

10.1 Diameter プロトコルのコンフィグレーションの概要

Oracle WebLogic Communication Services ドメインは、Diameter ベースのプロトコルと、Diameter クライアント ノードとして動作するエンジン属サーバにデプロイされる 1 つまたは複数の IMS Diameter インタフェース アプリケーション (Sh、Ro、Rf) をサポートしています。エンジン上にデプロイされる SIP サーブレットでは、利用可能な Diameter アプリケーションを使用して、ユーザ プロファイル データ、アカウンティングおよびクレジット管理に対するリクエストを発信することや、プロファイル データの変更通知のサブスクライブおよび受信することができます。

1 つまたは複数のサーバ インスタンスを Diameter リレー エージェントとしてコンフィグレーションすることもできます。Diameter リレー エージェントは、クライアント ノードからの Diameter メッセージをルーティングして、ネットワーク内でコンフィグレーションされている Home Subscriber Server (HSS) や他のノードに転送しますが、メッセージを変更する処理は行いません。ドメイン内の 1 つまたは複数のサーバをリレー エージェントとしてコンフィグレーションすることをお勧めします。リレー エージェントを使用すると Diameter クライアント ノードのコンフィグレーションが容易になり、HSS へのネットワーク接続の数を削減できます。少なくとも 2 つのリレー エージェントを使用すると、1 つのリレー エージェントに障害が発生した場合でも、HSS へのルートを必ず確立することができます。

注意 :
3GPP では、複数の HSS をサポートできるように、適切な HSS を検索するための Dh インタフェースが定義されています。Oracle WebLogic Communication Services には Dh インタフェース アプリケーションは含まれていないため、Oracle WebLogic Communication Services で可能なのは単一の HSS を使用するコンフィグレーションだけです。

リレー エージェント サーバはエンジン層と SIP データ層のどちらのインスタンスとしても機能しません。そのため、リレー エージェントでは、アプリケーションをホストすることや、呼状態データを保持すること、あるいは SIP タイマーを動作させることはできず、SIP プロトコルのネットワーク リソース (sip または sips ネットワーク チャネル) を使用することも避ける必要があります。

Oracle WebLogic Communication Services は Sh と Ro プロトコルのシミュレータ アプリケーションも提供します。Sh と Ro クライアントを開発するとき、シミュレータ アプリケーションをテストのために使用できます。シミュレータ アプリケーションはプロダクション システムのデプロイメント用のものではありません。

10.2 Diameter クライアント ノードとリレー エージェントをコンフィグレーションする手順

Oracle WebLogic Communication Services ドメインで Diameter のサポートをコンフィグレーションするには、以下の手順に従います。

1. Oracle WebLogic Communication Services Diameter のインストール。 Diameter ドメインをインストールします。このドメインには、各種の Diameter ノード タイプ用にコンフィグレーションされたサンプル コンフィグレーションとテンプレート アプリケーションが含まれています。Diameter ドメインは、ユーザ独自のドメインのテンプレートとして使用したり、様々な Diameter ノード タイプをコンフィグレーションする方法について理解を深めるために使用できます。

2. Diameter コンソール拡張の有効化。 サンプルの Diameter ドメインで作業している場合、Diameter コンソール拡張はすでに利用できる状態になっています。基本的な Oracle WebLogic Communication Services ドメインから作業を開始している場合は、拡張を有効にするため [config.xml] ファイルを編集します。

3. Diameter ネットワーク チャネルの作成。 エンジン層サーバおよびリレー エージェント上で、TCP、TLS または SCTP 転送の Diameter をサポートするために必要なネットワーク チャネルを作成します。

4. Diameter ノードの作成およびコンフィグレーション。 エンジン層サーバ上で Diameter プロトコル クライアント アプリケーションをコンフィグレーションするには、リレー エージェントや HSS のような他のネットワーク要素へのルート、ホスト名およびピアを指定します。Oracle WebLogic Communication Services インスタンスなしで、スタンドアロン モードで動作する Diameter ノードもコンフィグレーションすることができます。

以下の節では、各手順について詳しく説明します。節 10.7「ドメインのコンフィグレーション例」も参照してください。

10.3 Diameter ドメインのインストール

コンフィグレーション ウィザードには Diameter ドメインのテンプレートが用意されており、このテンプレートを使用すると、次の 4 つの Oracle WebLogic Communication Services インタスンスを含むドメインが作成されます。

- 管理サーバ (AdminServer)

- Diameter Sh クライアント ノード (hssclient)

- Diameter リレー ノード (リレー)

- HSS シミュレータ (hss)

テンプレートを使用してインストールした Diameter ドメインは、独自のドメインを作成するための土台として使用できます。また、カスタマイズした Diameter Web アプリケーションをテンプレートとして使用して、既存の Oracle WebLogic Communication Services インスタンスを HSS クライアントまたはリレー エージェント ノードとして機能するようにコンフィグレーションすることもできます。以下の節で示すコンフィグレーションの手順は、Diameter ドメインのコンフィグレーションにアクセスできることを前提としたものです。ドメインをインストールするには、以下の手順に従います。

1. WLS_HOME\common\bin デレクトリに変更します。WLS_HOME は Oracle WebLogic Server 10g リリース 3 の Oracle WebLogic Communication Services をインストールしたディレクトリです (たとえば、c:\bea\wlserver_10.3\common\bin)。

2. config.cmd または config.sh スクリプトを実行して、コンフィグレーション ウィザードを起動します。

3. [新しい WebLogic ドメインの作成] を選択し、[Next] をクリックします。

4. [既存のテンプレートを、このドメインのベースにする] を選択し、[参照] をクリックします。

5. diameterdomain.jar を選択して [OK] をクリックします。

6. [次へ] をクリックします。

7. 新しいドメインの管理者のユーザ名とパスワードを入力し、[次へ] をクリックします。

8. 新しいドメインで使用する起動モードと JDK を選択し、[次へ] をクリックします。

9. デフォルト テンプレート オプションを取得するため [いいえ] を選択して [Next] をクリックします。

10. [作成] をクリックします。これにより、デフォルトのドメイン名を持つ新しいドメインが、ドメインのデフォルトの場所 (/user_projects/domains/diameter) に作成されます。

11. [完了] をクリックします。

表 10-2 は、Diameter ドメインにインストールされるサーバのコンフィグレーションの概要をまとめたものです。

表 10-1 Diameter ドメインの主要なコンフィグレーション要素

サーバ名

ネットワーク チャネルのコンフィグレーション

Diameter アプリケーション

注意

AdminServer

なし

なし

Administration Server は SIP または Diameter のプロトコル機能を提供しません。

hssclient

diameter (ポート 3868 上の TCP)

sip (ポート 5060 上の UDP/TCP)

WlssShApplication

hssclient エンジンは、Diameter Sh クライアント ノードとして機能します。このサーバでは、SIP と Diameter トラフィックの両方をサポートするネットワーク チャネルが定義されています。Diameter ノード コンフィグレーションは、デプロイされている SIP サーブレットの IMS Sh インタフェース機能を提供するために、WlssShApplication (com.bea.wcp.diameter.sh.WlssShApplication) をデプロイします。

relay

diameter (ポート 3869 上の TCP)

RelayApplication

relay エンジンは、Diameter Sh リレー ノードとして機能します。このサーバでは、Diameter トラフィックをサポートするネットワーク チャネルが定義されています。リレー ノードは SIP メッセージを処理しないため、SIP トラフィックをサポートするチャネルは定義されていません。

Diameter ノード コンフィグレーションは、リレー サービスを提供するため RelayApplication (com.bea.wcp.diameter.relay.RelayApplication) をデプロイします。ノード コンフィグレーションは hssclient エンジンからメッセージをリレーするために、realm に基づくルートも定義します。

hss

diameter (ポート 3870 上の TCP)

HssSimulator

hss エンジンの Diameter ノード コンフィグレーションは、HssSimulator アプリケーション (com.bea.wcp.diameter.sh.HssSimulator) だけをデプロイします。サーバは Diameter ネットワーク チャネルとともにコンフィグレーションされます。

10.4 Diameter コンソール拡張の有効化

Oracle WebLogic Communication Services は、Diameter ノードを作成してコンフィグレーションするためのコンソール拡張を提供します。拡張による実際のコンフィグレーションは、ドメイン ディレクトリのサブディレクトリ config/custom にある diameter.xml ファイルに格納されます。

サンプル Diameter ドメインでは、Diameter コンソール拡張がすでに利用できます。拡張子を有効化しないドメインで作業している場合、拡張子に対してカスタム リソースを指定するためドメインに対する [config.xml] ファイルを編集します。例 10-1 は、コンソール拡張子を有効にするために [config.xml] ファイルの必要なエントリをハイライトします。テキスト エディタを使用して、config.xml の正しい位置にハイライトされたラインを追加します。

例 10-1 Diameter コンソール拡張子を有効にするための config.xml エントリ

<custom-resource>
<name>sipserver</name>
<target>hssclient</target>
<descriptor-file-name>custom/sipserver.xml</descriptor-file-name>
<resource-class>com.bea.wcp.sip.management.descriptor.resource.SipServerResource</resource-class>
<descriptor-bean-class>com.bea.wcp.sip.management.descriptor.beans.SipServerBean</descriptor-bean-class>
</custom-resource>
<custom-resource>
<name>diameter</name>
<target>hssclient,relay,hss</target>
<deployment-order>200</deployment-order>
<descriptor-file-name>custom/diameter.xml</descriptor-file-name>
<resource-class>com.bea.wcp.diameter.DiameterResource</resource-class>
<descriptor-bean-class>com.bea.wcp.diameter.management.descriptor.beans.DiameterBean</descriptor-bean-class>
</custom-resource>
<custom-resource>
<name>ProfileService</name>
<target>hssclient</target>
<deployment-order>300</deployment-order>
<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>
<admin-server-name>AdminServer</admin-server-name>
</domain>

10.5 Diameter プロトコルの TCP、TLS、および SCTP ネットワーク チャネルの作成

Oracle WebLogic Communication Services の Diameter 実装では、TCP、TLS または SCTP 転送プロトコル上の Diameter プロトコルがサポートされています。(SCTP 転送には、節 10.5.2「Diameter メッセージングのため SCTP のコンフィグレーションと使用」に説明したような特定な制限があります。)

サーバで着信 Diameter 接続が利用できるようにするには、適切なプロトコルタイプの専用ネットワーク チャネルを設定する必要があります。

- 「diameter」チャネルは TCP 転送を使用します。

- 「diameters」チャネルは TCP/TLS 転送を使用します。

- 「diameter-sctp」チャネルは TCP/SCTP 転送を使用します。

Diameter 用の TCP/TLS チャネル (diameters チャネル) を使用するサーバでは、双方向 SSL も有効にする必要があります。Diameter 仕様 (RFC 3558) に記述されているように、Oracle WebLogic Communication Services は、TLS を使用するために Diameter TCP 接続を自動的にアップグレードする場合があります。

Diameter プロバイダで使用する TCP チャネルまたは TCP/TLS チャネルをコンフィグレーションするには、以下の手順に従います。

1. Oracle WebLogic Communication Services ドメインの Administration Console にアクセスします。

2. コンフィグレーション ロックを取得するには、[Lock & Edit] をクリックします。

3. 左ペインで、コンフィグレーションする対象のサーバの名前を選択します。

4. 右ペインで、[プロトコル｜チャネル] を選択して、コンフィグレーション済みのチャネルを表示します。

5. [New] をクリックして、新しいチャネルをコンフィグレーションします。

6. [Identity Properties] ページの各フィールドに、次の情報を入力します。

- [名前] : このチャネルに付ける管理用の名前 (たとえば「Diameter TCP/TLS Channel」) を入力します。

- [プロトコル] : TCP 転送のサポートに「diameter」、TCP および TLS 転送のサポートに「diameters」、または TCP 転送のサポートに「diameter-sctp」を選択します。

注意 :
TLS チャネルが 1 つでもコンフィグレーションされているサーバは TLS モードで動作し、TLS をサポートしていないノードからのピア接続を拒否します (相手が TLS をサポートしているかどうかは、機能情報の交換時に確認されます)。

7. [次へ] をクリックして続行します。

8. [ネットワーク チャネル｜アドレス] ページの各フィールドに、次の情報を入力します。

- [リスン アドレス] : このチャネルの IP アドレスまたは DNS 名を入力します。マルチホーム マシンの場合は、コンフィグレーション対象のインタフェースの正確な IP アドレス、またはその正確な IP アドレスにマッピングされている DNS 名を入力します。

- [リスン ポート] : このチャネルを介した通信に使用するポート番号を入力します。Diameter ノードでは、通常は着信接続ポートとしてポート 3868 が使用されます。

- [外部 リスン ポート] : リスン ポートの値を再入します。

9. [次へ] をクリックして続行します。

10. 以下のように [ネットワーク チャネル プロパティ] ページの属性を選択します。

- [Enabled] : 新しいチャネルがネットワーク トラフィックを受信できるようにこの属性を選択します。

- [Tunneling Enabled] : Diameter チャネルに対してこの属性の選択を解除します。

- [HTTP Enabled for this Protocol] : Diameter チャネルに対してこの属性の選択を解除します。

- [Outbound Enabled] : チャネルを使用してノードが Diameter メッセージを開始できるようにこの属性を選択します。

11. [次へ] をクリックして続行します。

12. 「diameters」チャネルに対して、以下の 2 つの属性を選択します。

- [Two Way SSL Enabled] : TLS 送信には双方向 SSL が必要です。

- [Client Certificate Enforced] : セキュアな通信のために利用できるクライアント証明書を使用するためにこの属性を選択します。

13. [Finish] をクリックして、新しいチャネルを作成します。

14. ネットワーク チャネル テーブルに新たに作成されたチャネルの名前を選択します。

15. [Advanced] リンクをクリックして、新たに作成したチャネルの詳細なコンフィグレーション項目を表示します。

16. [アイドル接続タイムアウト] のデフォルト値 (65 秒) をより大きな値に変更して、Diameter 接続を一貫して利用し続けられるようにします。

注意 :
デフォルト値を変更しないと、アイドル状態の継続時間が 65 秒に達するたびに Diameter 接続の切断と再確立が行われます。

17. [保存] をクリックします。

18. [Activate Changes] をクリックします。

Diameter ドメイン テンプレートを使用してインストールされたサーバでは、TCP 転送を使用する Diameter 用のネットワーク チャネルがコンフィグレーションされています。リレー サーバでは diameter チャネルのみがコンフィグレーションされ、sip チャネルや sips チャネルは作成されません。リレー エージェントは SIP サーブレットやその他のアプリケーションのホストとしては使用できないので、リレー サーバ ノード上では SIP 転送をコンフィグレーションしないでください。

10.5.1 Diameter TLS チャネル用の双方向 SSL のコンフィグレーション

TLS 上の Diameter チャネル (diameters チャネル) を使用するには双方向 SSL も有効にする必要がありますが、双方向 SSL はデフォルトでは無効になっています。上の手順で、[Two Way Enabled SSL] を選択して双方向 SSL を有効にしてください。

10.5.2Diameter メッセージングのための SCTP のコンフィグレーションと使用

SCTP は、テレフォニ ネットワークで使用するために設計された、メッセージに基づく信頼性の高い転送プロトコルです。SCTP は TCP に比べていくつかの利点があります。

- データをエンドポイントに送信する場合、SCTP はメッセージの内部構造を保存します。一方、TCP は順番に受信する必要のある生のバイトを送信します。

- SCTP はマルチホームをサポートし、各エンドポイントに複数の IP アドレスを割り当てることができます。SCTP プロトコルは接続に失敗すると、他の IP アドレスに透過的にフェイルオーバできます。

- SCTP はマルチ ストリーミング機能を提供します。接続された複数のストリームは、互いに関係なくデータを送信します。

Oracle WebLogic Communication Services は、Diameter ネットワーク トラフィック用の SCTP をサポートしますが、いくつかの制限があります。

- 現在サポートされているのは、接続ごとに 1 つのストリームだけです。

- SCTP は Diameter ネットワーク トラフィックにのみ使用できます。SIP トラフィックは設定された SCTP チャネルを使用できません。

- TLS は SCTP でサポートされません。

さらに、Oracle WebLogic Communication Services は、以下のソフトウェア プラットホームの SCTP チャネルのみサポートします。

- 32 または 64 ビット ハードウェア上の Red Hat Enterprise Linux 4.0 AS、ES、WS (カーネル 2.6.9、GCC 3.4 以上)

- SPARC 上の Sun Solaris 10

SCTP チャネルは IPv4 か IPv6 ネットワークで動作します。節 10.5 は、新しい SCTP チャネルを作成する方法を説明します。既存の SCTP チャネルに対してマルチホーム機能を使用するには、IPv4 アドレス 0.0.0.0 をチャネルのリスン アドレスとして指定します （IPv6 ネットワークには :: アドレスを使用します）。

10.6 Diameter ノードのコンフィグレーション

Oracle WebLogic Communication Services エンジンの Diameter ノード コンフィグレーションは、diameter.xml コンフィグレーション ファイルに保存されます。（domain_home/config/custom/diameter.xml）エンジン層サーバで diameter サービス（クライアント、サーバまたはリレー機能）を提供するには、新しいノード コンフィグレーションを作成して、既存のエンジン サーバ インスタンスに適用します。

Diameter ノード コンフィグレーションにはいくつかのカテゴリがあります。

- 一般的なコンフィグレーションは、ノードのホスト ID およびレルム、基本的な接続情報、デフォルト ルーティング ビヘイビアを定義します。

- アプリケーション コンフィグレーションは、ノードで実行される Diameter アプリケーションと、それらのアプリケーションに渡されるオプションのコンフィグレーション パラメータを定義します。

- ピア コンフィグレーションは、このノードで動作する他の Diameter ノードを定義します。

- ルート コンフィグレーションは、ノードがメッセージを解決するために使用できるレルムベースのルートを定義します。

次の節では Diameter ノードの各特徴を設定する方法について説明します。

10.6.1 新しいノード コンフィグレーションの作成 (一般ノード コンフィグレーション)

以下の手順に従って、新しい Diameter ノード コンフィグレーションを作成して、既存の Oracle WebLogic Communication Services エンジン層インスタンスに適用します。

1. コンフィグレーションする Oracle WebLogic Communication Services ドメインの Administration Console にログインします。

2. コンフィグレーション ロックを取得するには、[Lock & Edit] をクリックします。

3. コンソールの左ペインの [Diameter] ノードを選択します。

4. 新しい Diameter コンフィグレーションを作成するため右ペインの [新規] をクリックします。

5. [新しいコンフィグレーションの作成] ページのフィールドに 表 10-2 に説明したように記入して [完了] をクリックします。

表 10-2 Diameter ノード一般コンフィグレーション プロパティ

プロパティ名

説明

名前

この Diameter ノード コンフィグレーションの管理名を入力します。

ホスト

この Diameter ノードのホスト ID を入力します。または、対象となるエンジン層サーバのホスト名を Diameter ノードのホスト ID として自動的に割り当てるには、フィールドを空白のままにします。このホスト ID は DNS 名と同じであっても違っていてもかまいません。

複数の sh クライアント ノードを対象に diameter サポートをコンフィグレーションする場合、[diameter.xml] ファイルの host 要素を省略することをお勧めします。これにより、同じ Diameter Web アプリケーションをエンジン層クラスタのすべてのサーバにデプロイすることができる。その際、各サーバ インスタンスのホスト名が動的に取得されます。

レルム

このノードに責任があるレルム名を入力します。または、対象となるエンジン層サーバの完全なホスト名 (host@oracle.com など) のドメイン名を使用するには、フィールドを空白のままにします。

異なるレルムとリスン ポート番号を使用すると、同一ホスト上で複数の Diameter ノードを運用することができます。

注意 : HSS、アプリケーション サーバ、リレー エージェントは、レルム名がすべて決められている必要があります。HSS とアプリケーション サーバのレルム名は一致していなくてもかまいません。

アドレス

DNS 名か IP アドレスを使用して、この Diameter ノードのリスン アドレスを入力します。または、ホスト ID をリスン アドレスとして使用する場合はフィールドを空白のままにします。

注意 : ホスト ID は Diameter ノードの DNS 名と同じであっても違っていてもかまいません。コンフィグレーション エラーを回避するため、アドレス プロパティを明示的な DNS 名または IP アドレスでコンフィグレーションすることをお勧めします。

TLS

Diameter ノードを TLS サポートとともにコンフィグレーションする場合は、このオプションを選択します（diameter のネットワーク チャネル）。このフィールドは、ノードが他の Diameter ノードから問い合わせを受けるときに TLS 機能を公開するためのものです。

デバッグ

デバッグ メッセージを出力するには、このオプションを選択します。デフォルトでは、デバッグ メッセージの出力は無効化されています。

メッセージ デバッグ

このノードで処理される Diameter メッセージに対してトレーシングを使用する場合は、このオプションを選択します。デフォルトではメッセージ トレーシングは無効です。

動的ピア使用可能

Diameter ピア ノードの動的な検索を可能にするには、このオプションを選択します。デフォルトでは、動的なピアは無効化されています。動的なピアを有効にするのは、TLS 転送を使用する場合のみにします。ピアになるホストを制限するためのアクセス制御メカニズムがないからです。

ピア再試行遅延

このノードがリクエストを Diameter ピアに再要求するまでの時間を秒で入力します。デフォルト値は 30 秒です。

リクエスト タイムアウト

このノードがタイム アウトまで回答メッセージを待つ時間をミリセカンドで入力します。

Watchdog タイムアウト

このノードが Diameter Tw watchdog タイマー間隔のため使用する秒数を入力します。

ターゲット

1 つまたは複数のターゲット エンジン層サーバ名を入力します。Diameter ノード コンフィグレーションは、このフィールドで指定されたサーバにのみ適用されます。

デフォルト ルート アクション

デフォルト ルートを使用するときのこの Diameter ノードのロールを説明するアクションのタイプを指定します。この要素には次の値のいずれかを指定できます。

- none

- local

- relay

- proxy

- redirect

デフォルト ルート サーバ

デフォルト ルートに対して、1 つまたは複数の対象サーバを指定します。この要素に含めるどのサーバも、この Diameter ノードのピアとしても定義されている必要があります。また、動的ピアのサポートが有効化されている必要があります。

6. 対象サーバにコンフィグレーションを適用するには、[Activate Changes] をクリックします。

一般ノード コンフィグレーションを作成すると、Diameter ノードのリストにコンフィグレーション名が表示されます。次の節に説明したように、Diameter アプリケーション、ピアおよびルートをコンフィグレーションするためにノードが選択できます。

10.6.2 Diameter アプリケーションのコンフィグレーション

各 Diameter ノードは、1 つまたは複数のアプリケーションをデプロイできます。選択した Diameter ノードに対して [コンフィグレーション｜アプリケーション] を使用して、Administration Console で Diameter アプリケーションを設定します。次の手順に従います。

1. コンフィグレーションする Oracle WebLogic Communication Services ドメインの Administration Console にログインします。

2. コンフィグレーション ロックを取得するには、[Lock & Edit] をクリックします。

3. コンソールの左ペインの [Diameter] ノードを選択します。

4. コンソールの右ペインで Diameter ノード コンフィグレーションの名前を選択します。

5. [コンフィグレーション｜アプリケーション] タブを選択します。

6. 新しい Diameter アプリケーションを設定するために [New] をクリックします。また、既存のアプリケーション コンフィグレーションを表から選択します。

7. 以下のようにアプリケーション プロパティを記入します。

- [アプリケーション名] : アプリケーション コンフィグレーションの名前を入力します。

- [クラス名] : このノードでデプロィするアプリケーションのクラス名前を入力します。

- [パラメータ] : 起動するとアプリケーションに渡されるオプションのパラメータを入力します。

8. [Finish] をクリックして、新しいアプリケーション コンフィグレーションを作成します。

9. Diameter ノードにコンフィグレーションを適用するために、[Activate Changes] をクリックします。

Oracle WebLogic Communication Services には Sh、Rf、Ro インタフェイス、Diameter リレーおよび Sh と Ro インタフェースのシミュレータを使用するクライアントをサポートするため、複数の Diameter アプリケーションが含まれています。次の節では、こうした Oracle WebLogic Communication Services Diameter アプリケーションの設定について詳しく説明します。

ユーザ独自の Diameter アプリケーションを作成してデプロィするために、Oracle WebLogic Communication Services に含まれる基本的 Diameter API も使用できます。

10.6.2.1 Sh クライアント アプリケーションのコンフィグレーション

Sh クライアントは、プロファイル サービス API へのプロバイダとして実装されます。このアプリケーションは、Sh アプリケーション仕様で定義されている Diameter コマンド コードに対して透過的に生成と応答を行います。プロファイル サービス API を使用すると、SIP サーブレットで XML ドキュメント オブジェクト モデル (DOM) を使ってユーザ プロファイル データを XML ドキュメントとして管理できます。変更されたプロファイル データに関するサブスクリプションと通知を管理するには、SIP サーブレット内でプロファイル リスナ インタフェースを実装します。

Sh クライアント アプリケーションをデプロイする Diameter ノードは、以下のように設定する必要があります。

- ドメインに設定された任意のリレー エージェントのホスト名は、Diameter ピア ノードとして定義します。リレー エージェントを 1 つも使用しない場合は、すべてのエンジン層サーバをピアのリストに追加するか、または動的ピアを有効にする必要があります。

- ドメイン内のリレー エージェント ノード (または HSS) には、1 つまたは複数のルートがアクセスします。

Sh クライアント アプリケーションを設定するため、com.bea.wcp.diameter.sh.WlssShApplication クラスを指定します。WlssShApplication は以下のパラメータを受け取ります。

- destination.host - 目的のホストへの静的ルートを指定します。サーバがリレー エージェントなし直接に HSS (静的ルーティング) に接続する場合は、destination.host パラメータ定義を含めます。リレー エージェントを通じてルーティングする場合は、destination.host パラメータを完全に削除します。

- destination.realm - 目的のホストへの静的ルートを指定します。ドメインがリレー エージェントを使用するかどうかに基づいて、リレー エージェント サーバのレルム名または HSS を指定します。

例 10-2 はリレーを使用する Sh クライアント ノードのサンプル ノード コンフィグレーションを表しています。

例 10-2 Sh クライアント アプリケーションとのサンプル Diameter ノード コンフィグレーション

<?xml version='1.0' encoding='utf-8'?>
<diameter xmlns="http://www.bea.com/ns/wlcp/diameter/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">
<configuration>
<name>hssclient</name>
<target>hssclient</target>
<host>hssclient</host>
<realm>oracle.com</realm>
<!-- ホストおよびレルム要素を省略して、個別のエンジン層サーバの
ホスト名およびドメイン名を動的に割り当てます。 - >
<message-debug-enabled>true</message-debug-enabled>
<application>
<name>WlssShApplication</name>
<class-name>com.bea.wcp.diameter.sh.WlssShApplication</class-name>
<param>
<!-- サーバがリレー エージェントを使用せず直接 HSS (静的ルーティング) に通信する場合にのみ
destination.host param 定義を
含めます。 リレー エージェントを通じてルーティングする場合は
destination.host param を完全に省略します。 - >
<!-- ドメインがリレー エージェントを使用するかどうかに応じて
リレー エージェント サーバまたは HSS のレルム名を指定します。 - >
<name>destination.realm</name>
<value>hss.com</value>
</param>
</application>
<peer>
<!-- ドメインで使用される各リレー エージェント サーバごとにピア エントリを含めます。
リレー エージェントを使用しない場合は、HSS 自体、および
他のすべての Sh クライアント ノード (ドメイン内の他のすべての
エンジン層サーバ) のピア エントリを含めます。
または、ピアが自動的に認識されるように、
allow-dynamic-peers 機能を TLS 転送と組み合わせて
使用します。 - >       <host>relay</host>
<address>localhost</address>
<!-- アドレス要素は DNS 名または IP アドレスのどちらかを指定できます。
一方で、ホスト要素は Diameter ホスト ID を指定する必要があります。
Diameter ホスト ID は、DNS 名と一致してもしなくてもかまいません。 - >
<port>3869</port>
</peer>
<!-- 選択したリレー エージェントへのデフォルトのルートを入力します。ドメインが
リレー エージェントを使用しない場合は、直接 HHS にメッセージをリレーする
デフォルトのルートを指定します。 - >
<default-route>
<action>relay</action>
<server>relay</server>
</default-route>
</configuration>
</diameter>

10.6.2.2 Rf クライアント アプリケーションのコンフィグレーション

Oracle WebLogic Communication Services Rf クライアント アプリケーションでは、IMS Rf インタフェースを使用してオフライン チャージング メッセージを発行する SIP サーブレットが使用できます。Rf アプリケーションをコンフィグレーションするには、com.bea.wcp.diameter.charging.RfApplication クラスを指定してください。Rf アプリケーションは以下のパラメータを受け取ります。

- cdf.host はチャージング データ機能 (CDF) のホスト名前を指定します。

- cdf.realm は CDF のレルムを指定します。

10.6.2.3 Ro クライアント アプリケーションのコンフィグレーション

Oracle WebLogic Communication Services Ro クライアント アプリケーションでは、IMS Ro インタフェースを使用してオンライン チャージング メッセージを発行する SIP サーブレットが使用できます。Rf アプリケーションを設定するには、com.bea.wcp.diameter.charging.RoApplication クラスを指定します。 Ro アプリケーションに以下のパラメータが記入できます。

- ocs.host はオンライン チャージング データ関数 (CDF) のホスト名前を指定します。指定された OCF ホストは、Ro アプリケーションがデプロイされる Diameter ノードのピアとして設定されていることも必要です。

- 1 つまたは複数の OCF ホストを使用する場合、ocs.realm をレルムベース ルーティング用の ocs.host の代わりに使用できます。関連するレルム定義は、Diameter ノードのコンフィグレーションにも指定されている必要があります。

10.6.2.4 Diameter リレー エージェントのコンフィグレーション

Diameter のコンフィグレーションではリレー エージェントの使用は必須ではありませんが、HSS への直接接続の数を制限し、障害の発生に備えて HSS への複数のルートを確保するためにも、少なくとも 2 つのリレー エージェント サーバを使用することをお勧めします。

注意 :
Oracle WebLogic Communication Services エンジン層サーバまたは SIP データ層サーバとしてリレー サーバが動作していないことを確認してください。つまり、サーバは「sip」または「sips」ネットワーク チャネルとともに設定されないことが必要です。

リレー エージェント ノードはクライアント ノードと HSS の間の Sh メッセージのルーティングを行いますが、Diameter Sh 仕様で定義されている処理以外の変更をメッセージに加えることはありません。リレー エージェントは HSS からの応答を必ずそのメッセージの発信元のクライアント ノードに返信し、そのノードに接続できないときは、その応答を破棄します。

Diameter リレー エージェントを設定には、com.bea.wcp.diameter.relay.RelayApplication クラスでアプリケーションをデプロイするノードを設定します。

リレー アプリケーションをデプロイするノードも設定します。

- リレー ノードへのピアとして他のすべてノード

- リレー アクションを指定するデフォルト ルート

例 10-3 では、リレー エージェント ノードのサンプル diameter.xml コンフィグレーションを表しています。

例 10-3 Diameter リレー ノード コンフィグレーション

<?xml version='1.0' encoding='utf-8'?>
<diameter xmlns="http://www.bea.com/ns/wlcp/diameter/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">
<configuration>
<name>relay</name>
<target>relay</target>
<host>relay</host>
<realm>oracle.com</realm>
<message-debug-enabled>true</message-debug-enabled>
<application>
<name>RelayApplication</name>
<class-name>com.bea.wcp.diameter.relay.RelayApplication</class-name>
</application>
<!-- 各 Diameter ノードのピア接続情報を定義するか、
allow-dynamic-peers 機能を TLS 転送と組み合わせて使用して、
ピアが自動的に認識されるようにします。 - >
<peer>
<host>hssclient</host>
<address>localhost</address>
<port>3868</port>
</peer>
<peer>
<host>hss</host>
<address>localhost</address>
<port>3870</port>
</peer>
<route>
<realm>oracle.com</realm>
<application-id>16777217</application-id>
<action>relay</action>
<server>hssclient</server>
</route>
<!-- HSS にメッセージをリレーするこのエージェントの
デフォルトのルートを入力します。 - >
<default-route>
<action>relay</action>
<server>hss</server>
</default-route>
</configuration>
</diameter>

10.6.2.5 Sh および Rf シミュレータ アプリケーションのコンフィグレーション

Oracle WebLogic Communication Services には、Diameter クライアント アプリケーションを評価する環境を開発したりテストする際に使用できる 2 つのシミュレータ アプリケーションが含まれています。シミュレータ アプリケーションをコンフィグレーションするには、関連するクラスを設定された Diameter ノードにデプロイします。

- com.bea.wcp.diameter.sh.HssSimulator は、Sh クライアント アプリケーションをテストするため、ユーザのドメインで HSS をシミュレートします。

- com.bea.wcp.diameter.rf.RfSimulator は、Rf クライアント アプリケーションをテストするため、CDF ホストをシミュレートします。

注意 :
こうしたシミュレータは、テストまたは開発目的でのみ提供されており、プロダクション環境の HSS や CDF の代用として使用されることを想定していません。

シミュレータ アプリケーションをデプロイする Diameter ノードは、起動しているエンジン層サーバの対象にすることができます。または、スタンドアロン Diameter ノードとして起動できます。スタンドアロン モードで起動すると、シミュレータ アプリケーションは表 10-2 に説明されたコマンドライン オプションを取得します。

表 10-3 シミュレータ アプリケーションのコマンドライン オプション

オプション

説明

-r、-realm realm_name

Diameter ノードのレルム名を指定します。

-h、-host host_name

ノードのホスト ID を指定します。

-a、-address address

このノードに対してリスン アドレスを指定します。

-、-port port_number

このノードに対してリスン ポート番号を指定します。

-d、-debug

デバッグ出力を有効にします。

-m、-mdebug

Diameter メッセージ トレーシングを有効にします。

10.6.2.6 プロファイル サービスの有効化 (Sh バックエンドの使用)

前に述べたように、Sh、Ro、および Rf アプリケーションは個別にコンフィグレーションおよび使用できますが、Sh はプロファイル サービス API を活用できます。これを行うには、以下の操作を行います。

1. diameter.xml で ShApplication をコンフィグレーションします (詳細については、例 10-5 を参照してください)。

2. domain_home/config/custom/profile.xml に profile.xml ファイルを追加します。Diameter ドメインをテンプレートとしてインストールしてファイルを変更するか、例 10-4 に示すように手動で profile.xml を作成することもできます。

例 10-4 profile.xml のサンプル

<profile-service xmlns="http://www.bea.com/ns/wlcp/wlss/profile/300">
<mapping>
<map-by>prefix</map-by>
<map-by-prefix>
<provider-prefix-set>
<name>sh</name>
<prefix>sh</prefix>
</provider-prefix-set>
</map-by-prefix>
</mapping>
<provider>
<name>sh</name>
<provider-class>com.bea.wcp.profile.ShProviderCached</provider-class>
</provider>
</profile-service>

10.6.3 ピア ノードのコンフィグレーション

Diameter ノードは、レルムにある互いの Diameter ノードに対してピア接続情報を定義します。または、ピアが自動認識されるようにするために、TLS 転送と組み合わせて動的なピアが使用できるようにします。選択した Diameter ノードに対して [コンフィグレーション｜Peers] ページを使用して、Administration Console に Diameter ピア ノードを設定します。次の手順に従います。

1. コンフィグレーションする Oracle WebLogic Communication Services ドメインの Administration Console にログインします。

2. コンフィグレーション ロックを取得するには、[Lock & Edit] をクリックします。

3. コンソールの左ペインの [Diameter] ノードを選択します。

4. コンソールの右ペインで Diameter ノード コンフィグレーションの名前を選択します。

5. [コンフィグレーション｜Peers] タブを選択します。

6. 新しいピア エントリを定義するため [New] をクリックします。

7. [Create a New Peer] ページの各フィールドに、次の情報を入力します。

- [Host] : ピアノードのホスト ID を入力します。

- [Address] : ピア ノードのアドレス (DNS 名または IP アドレス) を入力します。

- [Port Number] : ピアノードのリスン ポート番号を入力します。

- [プロトコル] : ピア (TCP または SCTP) で通信するために使用するプロトコルを選択します。

注意 :
Oracle WebLogic Communication Services は、指定したプロトコル (TCP または SCTP) のみを使用したピアに接続させようとします。選択したプロトコルを使用して接続に失敗しても、他のプロトコルは使用されません。プロトコルを指定しなければ、デフォルトとして TCP を使用します。

- [Watchdog] : ピアが Diameter Tw watchdog タイマー間隔をサポートするかどうかを示します。

8. [Finish] をクリックして、新しいピア エントリを作成します。

9. コンフィグレーションを適用するには、[Activate Changes] をクリックします。

10.6.4 ルートのコンフィグレーション

リレーとしてのいくつかの Diameter ノードでは、Diameter メッセージを解決する際に使用するためのレルム ベース ルートを設定する必要があります。選択した Diameter ノードに対して [コンフィグレーション｜Routes] ページを使用して、Administration Console に Diameter ルートを設定します。次の手順に従います。

1. コンフィグレーションする Oracle WebLogic Communication Services ドメインの Administration Console にログインします。

2. コンフィグレーション ロックを取得するには、[Lock & Edit] をクリックします。

3. コンソールの左ペインの [Diameter] ノードを選択します。

4. コンソールの右ペインで Diameter ノード コンフィグレーションの名前を選択します。

5. [コンフィグレーション｜Routes] タブを選択します。

6. 新しいルートを設定するため [New] をクリックします。

7. [Create a New Route] ページの各フィールドに、次の情報を入力します。

- [Name] : ルートの管理名を入力します。

- [Realm] : このルートのターゲット レルムを入力します。

- [Application ID] : このルートに対するターゲット Diameter アプリケーション ID を入力します。

- [Action] : 設定したルートを使用する際にこのノードが実行する対応を選択します。対応の種類は none、local、relay、proxy または redirect です。

- [Server Names] : ルートを使用する対象サーバの名前を入力します。

8. [Finish] をクリックして、新しいルート エントリを作成します。

9. コンフィグレーションを適用するには、[Activate Changes] をクリックします。

ルートエントリを含む diameter.xml ノード コンフィグレーションの例については、例 10-3 を参照してください。

10.7 ドメインのコンフィグレーション例

この節では、基本的な Diameter Sh プロトコルの機能を提供する Oracle WebLogic Communication Services のサンプル コンフィグレーションを示します。サンプル ドメインのレイアウトを構成しているサーバは以下のとおりです。

- SIP アプリケーションのホストである 3 つのエンジン層サーバ。これらのサーバには、ユーザ プロファイルにアクセスするための Diameter Sh アプリケーションもデプロイされます。

- 4 つの SIP データ層サーバ。2 つのパーティションにそれぞれ 2 つのレプリカが含まれています。

- Diameter リレー エージェントとして動作する 2 つのサーバ。これらのサーバは、Diameter リクエストを HSS に転送する役割を果たします。

図 10-1 に、サンプル コンフィグレーションの各サーバを示します。

図 10-1 Diameter ドメインの例

「図 10-1 Diameter ドメインの例」の説明

例 10-5 に、サンプル ドメインでエンジン層サーバ (Sh クライアント) をコンフィグレーションするために使用される [diameter.xml] ファイルの内容を示します。例 10-6 に、リレー エージェントをコンフィグレーションするために使用して [diameter.xml] ファイルを示します。

例 10-5 サンプル エンジン層クラスタ (Sh クライアント) の diameter.xml コンフィグレーション ファイル

<?xml version='1.0' encoding='utf-8'?>
<diameter xmlns="http://www.bea.com/ns/wlcp/diameter/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">
<configuration>
<name>clientnodes</name>
<target>Engine1</target>
<target>Engine2</target>
<target>Engine3</target>
<realm>sh_wlss.com</realm>
<application>
<name>WlssShApplication</name>
<class-name>com.bea.wcp.diameter.sh.WlssShApplication</class-name>
<param>
<name>destination.realm</name>
<value>relay_wlss.com</value>
</param>
</application>
<peer>
<host>Relay1</host>
<address>10.0.1.20</address>
<port>3821</port>
</peer>
<peer>
<host>Relay2</host>
<address>10.0.1.21</address>
<port>3821</port>
</peer>
<default-route>
<action>relay</action>
<server>Relay1</server>
</default-route>
<route>
<action>relay</action>
<server>Relay2</server>
</route>
</configuration>
</diameter>

例 10-6 サンプル リレー エージェントの diameter.xml コンフィグレーション

<?xml version='1.0' encoding='utf-8'?>
<diameter xmlns="http://www.bea.com/ns/wlcp/diameter/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">
<configuration>
<name>relaynodes</name>
<target>Relay1</target>
<target>Relay2</target>
<realm>relay_wlss.com</realm>
<application>
<name>RelayApplication</name>
<class-name>com.bea.wcp.diameter.relay.RelayApplication</class-name>
</application>
<peer>
<host>Engine1</host>
<address>10.0.1.1</address>
<port>3821</port>
</peer>
<peer>
<host>Engine2</host>
<address>10.0.1.2</address>
<port>3821</port>
</peer>
<peer>
<host>Engine3</host>
<address>10.0.1.3</address>
<port>3821</port>
</peer>
<peer>
<host>Relay1</host>
<address>10.0.1.20</address>
<port>3821</port>
</peer>
<peer>
<host>Relay2</host>
<address>10.0.1.21</address>
<port>3821</port>
</peer>
<peer>
<host>hss</host>
<address>hssserver</address>
<port>3870</port>
</peer>
<default-route>
<action>relay</action>
<server>hss</server>
</default-route>
</configuration>
</diameter>

10.8 Diameter コンフィグレーションのトラブルシューティング

Oracle WebLogic Communication Services 上にデプロイされる sip サーブレットでは、利用可能な diameter アプリケーションを使用して、ユーザ プロファイル データ、アカウンティングおよびクレジット管理に対するリクエストを発信したり、プロファイル データの変更通知のサブスクライブして受信したりできます。これらの要求の処理中に SIP サーブレットで次のエラー

Failed to dispatch Sip message to servlet ServletName
java.lang.IllegalArgumentException: No registered provider for protocol: Protocol

が発生した場合、このメッセージは、プロトコルに対して関連付けられた Diameter アプリケーションが適切にコンフィグレーションされていないことを示します。詳細については、節 10.6.2「Diameter アプリケーションのコンフィグレーション」を参照してください。

Diameter ピア ノードへの接続に失敗した場合、節 10.6.3「ピア ノードのコンフィグレーション」を使用して、ピアと通信するために正しいプロトコルがコンフィグレーションされていることを確認します。Oracle WebLogic Communication Services はピア コンフィグレーションに対して指定したプロトコル (指定されていない場合、TCP) のみを使用してピアに接続をさせようとすることに注意してください。

第 IV 部

Oracle User Messaging Service

以下の章があります。

- 第 11 章「Oracle User Messaging Service のコンフィグレーション」

- 第 12 章「Oracle User Messaging Service のモニタ」

- 第 13 章「Oracle User Messaging Service の管理」

11 Oracle User Messaging Service のコンフィグレーション

この章では、Oracle User Messaging Service (UMS) をコンフィグレーションする方法について説明します。

この章には、以下のトピックがあります。

- 節 11.1「User Messaging Service の概要」

- 節 11.2「Oracle User Messaging Service のコンフィグレーションの概要」

- 節 11.3「User Messaging Service コンフィグレーション ページへのアクセス」

- 節 11.4「User Messaging Service ドライバのコンフィグレーション」

- 節 11.5「User Messaging Service のセキュリティ」

11.1 User Messaging Service の概要

Oracle User Messaging Service は、ユーザおよびデプロイされたアプリケーションの間の双方向の通信を可能にします。主な機能は、以下のとおりです。

- さまざまなメッセージング チャネルのサポート - 電子メール、IM (XMPP)、SMS (SMPP)、および Voice を通じてメッセージを送受信できます。ユーザの SOA/WebCenter Worklist にメッセージを配信することもできます。

- 双方向のメッセージング - アプリケーションからユーザにメッセージが送信されるだけでなく (「発信メッセージング」と呼ばれます)、ユーザがメッセージングによる対話を開始できます (着信メッセージング)。たとえば、ユーザは指定されたアドレスに電子メールまたはテキスト メッセージを送信できます。メッセージは、ユーザに応答したり、ビジネス ロジックに応じて別のプロセスを起動することのできる適切なアプリケーションにルーティングされます。

- User Messaging Preferences - エンド ユーザは Web インタフェースを使用して、メッセージングの通知をいつどのように受け取るかを定義できます。アプリケーションでは柔軟性が直ちに向上します。ユーザの電子メール アドレスまたはインスタンス メッセージング クライアントのどちらに送信するかを判断する代わりに、アプリケーションではメッセージを単純にユーザに送信し、ユーザの設定に従って UMS でメッセージがルーティングされるようにできます。

- 堅牢なメッセージ配信 - UMS はメッセージング ゲートウェイから提供された配信ステータス情報を追跡し、失敗した配信に応答できるよう、それらの情報をアプリケーションで使用できるようにします。また、アプリケーションでは、最初のアドレスへの配信が失敗した場合に備えて、メッセージに対して 1 つまたは複数の「フェイルオーバ」アドレスを指定できます。UMS のフェイルオーバ機能を使用することで、アプリケーション開発者は厄介な再試行ロジックを実装する必要がなくなります。

- Fusion Middleware 内の全面的な統合 - UMS は、1 つに統合された双方向のユーザ メッセージング サービスを提供する、他の Fusion Middleware コンポーネントと統合されています。

- Oracle BPEL との統合 - Oracle JDeveloper には、メッセージング操作を可能にする組み込みの BPEL アクティビティが含まれています。開発者は目的のアクティビティを任意のワークフローにドラッグ アンド ドロップすることで、メッセージング機能を SOA 複合アプリケーションに追加できます。

- Oracle Human Workflow との統合 - UMS によって、Human Workflow エンジンでは電子メールを通じてアクション可能なメッセージをユーザに送信したり、ユーザからの応答を受信することができます。

- Oracle BAM との統合 - Oracle BAM では UMS を使用して、モニタ イベントへの応答時に電子メール通知を送信できます。

- Oracle WebCenter との統合 - Oracle WebCenter Spaces のアプリケーションを作成する開発者は UMS API を使用できます。この API は、高性能なメッセージングのための標準 Web サービス インタフェースである Parlay X Web Services for Multimedia Messaging バージョン 2.1 の実装です。

11.1.1 コンポーネント

Oracle User Messaging Service は、以下の 3 種類のコンポーネントで構成されます。これらのコンポーネントは標準 Java EE アプリケーションであるため、Oracle WebLogic Server が提供する標準ツールを使用して簡単にデプロイおよび管理できます。

- UMS サーバ : UMS サーバは、アプリケーションとユーザの間でメッセージ フローのオーケストレーションを行います。サーバでは、クライアント アプリケーションから適切なドライバへの発信メッセージ、および適切なクライアント アプリケーションへの着信メッセージがルーティングされます。また、以前送信されたメッセージのリポジトリを永続的なストア内で管理し、以前送信されたメッセージを配信状態の情報と相関させます。

- UMS ドライバ : UMS ドライバは、UMS でサポートされている各種のプロトコルにコンテンツを適合させて、UMS をメッセージング ゲートウェイに接続します。所定のインストールで使用可能なメッセージング チャネルに応じて、ドライバは相互に独立してデプロイまたはアンデプロイできます。

- UMS クライアント アプリケーション : UMS クライアント アプリケーションは、メッセージ送受信のビジネス ロジックを実装します。UMS クライアント アプリケーションは、BPEL ワークフローの 1 ステップとしてメッセージを送信する SOA アプリケーション、または Web インタフェースからメッセージを送信できる WebCenter Spaces アプリケーションになる場合があります。

UMS 自身を構成するコンポーネントに加えて、メッセージング環境内の他の主なエンティティとしては、各メッセージング チャネルに必要な外部ゲートウェイがあります。これらのゲートウェイは UMS または Oracle WebLogic Server の一部ではありません。UMS ドライバでは広く普及しているメッセージング プロトコルがサポートされるため、UMS は企業の電子メール サーバや XMPP (Jabber) サーバなどの既存のインフラストラクチャに統合できます。また、UMS は、SMPP または VoiceXML をそれぞれサポートする SMS または Text-To-Speech サービス用の外部プロバイダに接続できます。

11.1.2 アークテクチャ

図 11-1 に、Oracle User Messaging Service システムのアーキテクチャを示します。

最大限の柔軟性を実現するため、UMS の各コンポーネントは、個別の Java EE アプリケーションです。このため、これらは相互に独立してデプロイおよび管理されます。たとえば、他のすべてのチャネルでのメッセージの配信に影響を与えずに、特定のドライバを停止し、再度コンフィグレーションできます。

UMS クライアント アプリケーションと UMS サーバの間のやり取りは、Web サービス クライアントの場合は SOAP/HTTP Web サービス リクエスト、または BPEL メッセージング アクティビティの場合は Remote EJB および JMS 呼び出しを通じて行われます。UMS サーバと UMS ドライバの間のやり取りは、JMS キューを通じて行われます。

Oracle UMS サーバおよびドライバは、それぞれの WebLogic Server インスタンス内で、SOA または BAM と共にインストールされます。WebCenter のインストールには、SOA インスタンスにデプロイされたサーバを起動して、UMS クライアント アプリケーションとして機能するために必要なライブラリが含まれます。

図 11-1 UMS アーキテクチャ

「図 11-1 UMS アーキテクチャ」の説明

11.2 Oracle User Messaging Service のコンフィグレーションの概要

Oracle User Messaging Service を使用すると、Oracle JDeveloper を使用して開発され、Oracle WebLogic Server にデプロイされた SOA アプリケーションから送信された通知をユーザが受信できるようになります。

アプリケーション レベルでは、特定の配信チャネル (SMS や電子メールなど) の通知アクティビティが発生します。たとえば、電子メール通知を送信する SOA アプリケーションを作成する場合は、JDeveloper コンポーネント パレットからワークフロー内の適切な場所に「電子メール アクティビティ」コンポーネントをドラッグ アンド ドロップします。アプリケーションは接続した後に、通知を送信します。

Oracle JDeveloper の詳細については、JDeveloper のドキュメントを参照してください。

図 11-2 は、SOA 複合アプリケーションの BPEL プロセスに電子メール アクティビティを追加しているユーザを示します。

図 11-2 BPEL ワークフローでの通知アクティビティの設定

「図 11-2 BPEL ワークフローでの通知アクティビティの設定」の説明

ワークフロー参加者が通知を受信および転送できるようにするには、Oracle 11g Enterprise Manager を使用して、ワークフロー アプリケーションをデプロイする同一の Oracle WebLogic Server にある適切なドライバ インスタンスをコンフィグレーションすることで、Oracle User Messaging Service 環境を設定します (図 11-3)。Oracle User Messaging Service には、電子メール、IM、SMS、および音声チャネルを介したメッセージングをサポートするドライバが含まれています。 詳細については、節 11.4「User Messaging Service ドライバのコンフィグレーション」を参照してください。

図 11-3 Oracle Enterprise Manager 11g Fusion Middleware Control

「図 11-3 Oracle Enterprise Manager 11g Fusion Middleware Control」の説明

ワークフロー参加者が実際に通知を受信するには、User Messaging Preferences を通じてメッセージにアクセスするために使用するデバイスを登録する必要があります (図 11-4)。

図 11-4 User Messaging Preferences

「図 11-4 User Messaging Preferences」の説明

11.3 User Messaging Service コンフィグレーション ページへのアクセス

User Messaging Service のコンフィグレーションには、Oracle Enterprise Manager Fusion Middleware Control を使用します。Oracle Enterprise Manager の詳細については、Oracle Enterprise Manager のドキュメントを参照してください。

11.3.1 格納方法の設定

基本のコンフィグレーション ページを使用して、メッセージング サーバのデプロイメント タイプを設定し (つまり、実行時および管理データの格納方法の選択)、メッセージ フィルタの作成に使用する User Messaging Preferences のビジネス条件を追加 (または削除) します。

サーバの再起動時にエントリとメッセージング ストアの永続化を有効にするには、[Persistent] (デフォルト) を選択します。[Transient] モード (軽量なデプロイメントで推奨される) では、メッセージング ストアに保存されていたデータが再起動後にメッセージング サーバで維持されません。

11.3.2 User Messaging Preferences のビジネス条件の追加または削除

基本のコンフィグレーション ページでは、User Messaging Preferences でメッセージ フィルタの作成に使用するビジネス条件を追加または削除できます。ビジネス条件を使用したメッセージ フィルタの作成の詳細については、「ビジネス条件の追加」を参照してください。

11.3.2.1 ビジネス条件の追加

注意 :
ビジネス条件はサーバ インスタンスごとに格納されます。複数のインスタンスが存在する場合は (クラスタ内など)、新しいビジネス条件をインスタンスごとに個別に追加する必要があります。

User Messaging Preferences にビジネス条件を追加するには :

1. [追加] をクリックします。

2. ビジネス条件のわかりやすい名前を入力します。

3. データ型 (文字列、数値、または日付) を選択します。

4. [適用] をクリックします。

11.3.2.2 ビジネス条件の削除

User Messaging Preferences からビジネス条件を削除するには :

1. ビジネス条件を選択します。

2. [削除] をクリックします。

3. [適用] をクリックして、新しいタームを確認します。

11.4 User Messaging Service ドライバのコンフィグレーション

Oracle User Messaging Service に含まれるドライバは、以下のとおりです。

- 電子メール ドライバ

- SMPP ドライバ

- XMPP ドライバ

- Worklist ドライバ

- プロキシ ドライバ

注意 :
クラスタ環境で、個別の管理対象サーバ ノード用に複数のメッセージング ドライバを使用する場合は、すべてのドライバを個別にコンフィグレーションする必要があります。
UMS メッセージング ドライバのコンフィグレーションはインスタンスごとに行います。1 つのドライバのみをコンフィグレーションしても、コンフィグレーションの値は他のクラスタ ノード上のドライバには設定されません。

11.4.1 ドライバのコンフィグレーション方法

ドライバをコンフィグレーションするには :

1. Enterprise Manager Fusion Middleware Control コンソールに管理者としてログインします。

2. Fusion Middleware フォルダを展開します (図 11-5)。

図 11-5 UMS フォルダの展開

「図 11-5 UMS フォルダの展開」の説明

3. User Messaging Service のホーム ページに移動します。

4. [usermessagingserver(soa_server1)] をクリックします。 [Associated Drivers] ページが開きます。

図 11-6 UMS インスタンスに関連付けられたドライバ

「図 11-6 UMS インスタンスに関連付けられたドライバ」の説明

5. [ローカル] タブを選択して、UMS サーバ インスタンスと共に配置されているドライバにアクセスします。 これらのドライバは、コンフィグレーションが適切であるかどうかに応じて、UMS サーバに登録されている場合と登録されていない場合があります。[すべて] タブには、ドメインにデプロイされ、すべての UMS サーバ インスタンスに登録されているすべてのドライバがリストされます。

6. リストで電子メール ドライバを探し、横にある [Configure Driver] アイコンをクリックします。
コンフィグレーション ページが表示されます (図 11-7)。

図 11-7 選択したドライバの基本のコンフィグレーション ページ

「図 11-7 選択したドライバの基本のコンフィグレーション ページ」の説明

7. [Driver-Specific Configuration] セクションを必要に応じて展開し、ドライバのパラメータをコンフィグレーションします。詳細については、節 11.4.1.1「ドライバのパラメータについて」を参照してください。

11.4.1.1 ドライバのパラメータについて

Oracle User Messaging Service ドライバは、メッセージング エンジンによる発信メッセージのルーティングで使用される共通のプロパティ (表 11-1 のリストを参照) を共有します。 一般に、管理者は、ドライバのコスト (Cost)、ドライバの速度 (Speed)、サポートされるキャリア (SupportedCarriers)、サポートされるプロトコル (SupportedProtocols) などのサービス品質プロパティを設定します。 ドライバ開発者は、通常は管理者が変更する必要のない、サポートされる配信タイプ (SupportedDeliveryTypes) やサポートされるコンテンツ タイプ (SupportedContentTypes) などのプロパティをコンフィグレーションします。

注意 :
SendingQueuesInfo などのプロパティは、高度な使用のために用意されており、高度なデプロイメント トポロジ以外での変更の必要はありません。

表 11-1 共通のドライバ プロパティ

名前

説明

必須プロパティ

Capability

メッセージを送受信するドライバの機能を設定します。値は SEND、RECEIVE、および BOTH です。

はい

Cost

ドライバのコスト レベル (0 - 10)。0 は最低、10 は最高です。値がこの範囲内にない場合、コストは 0 と見なされます。

いいえ

DefaultSenderAddress

送信者のデフォルトのアドレス。送信者のアドレスが指定されていないメッセージを送信する場合や、指定された送信者アドレスが送信者リストに含まれておらず、アプリケーションが提供する送信者アドレスの使用がドライバでサポートされていない場合は、ドライバによってこれらのアドレスが使用されます。

いいえ

SenderAddresses

ドライバでサポートされる送信者アドレスのリスト。ドライバで提供される場合、メッセージング エンジンはこれを使用して、メッセージの送信者アドレスと照合することで、送信中のメッセージをドライバにルーティングできます。

いいえ

SendingQueuesInfo

ドライバ送信キューの情報。

はい

Speed

ドライバの速度レベル (0-10。最速は 10)。

いいえ

SupportedCarriers

サポートされているキャリアのカンマ区切りのリスト。

いいえ

SupportedContent Types

ドライバでサポートされているコンテンツ タイプ。

はい

SupportedDelivery Types

ドライバでサポートされている配信タイプ。

はい

SupportedProtocols

サポートされているプロトコルのカンマ区切りのリスト。任意のプロトコルにはアスタリスク (*) を入力します。

いいえ

SupportedStatusTypes

ドライバでサポートされているステータス タイプ。

いいえ

SupportsCancel

メッセージのキャンセル操作をサポートします。

いいえ

SupportsReplace

メッセージの置換操作をサポートします。

いいえ

SupportsStatusPolling

特定のプロトコルでは、以前送信されたメッセージのステータスをチェックするため、リモート ゲートウェイのアクティブなポーリングを実行する必要があります。このプロパティは、このようなステータス ポーリングがドライバでサポートされているかどうかを示します。true に設定すると、メッセージング エンジンでドライバ接続の getStatus() 操作が起動されます。

いいえ

SupportsTracking

メッセージの追跡操作をサポートします。

いいえ

11.4.1.2 パスワードのセキュリティ保護

Oracle Enterprise Manager を使用して、機密性を持つドライバ プロパティ (パスワードなど) を資格ストアに安全に保存できます。プロパティにはフラグ [Encoded Credential] でマークが付けられ、カスタム入力フォーム フィールドがあります。

機密性を持つドライバ プロパティを安全に保存するには :

1. 選択したドライバのドライバ コンフィグレーション ページに移動します。

2. [Driver-Specific Configuration] セクションで、[Encoded Credential] フラグが設定されたプロパティを探します。

3. 資格タイプを選択します (選択した資格タイプに応じて、ユーザ名またはパスワード、あるいはその両方の入力が求められます)。3 つのオプションがあります。

- [Indirect password, create new user] (デフォルトのオプション) - ユーザ名と実際のパスワードを指定します。パスワードはユーザ名をキーの一部として使用して、資格ストアに保存されます。キーおよび固定フォルダ (map name) がドライバ デプロイメントの driverconfig.xml に保存されます。

- [Indirect password, use existing user] - 資格ストアで既存のユーザ名/キーを選択します (以前に保存したパスワードを参照します)。

- [User a clear text password] - 指定したパスワードが driverconfig.xml に直接保存されます。

4. [適用] をクリックして、変更を保存します。

5. 変更を有効にするには、ドライバ アプリケーションまたはコンテナを再起動します。

ドライバ デプロイメント ディレクトリの driverconfig.xml でパスワードを確認できます。間接的なパスワードのフォーマットは、以下のとおりです。

value="->mapName:keyName"    (mapName is the driver target name, and the key is <parameter_name>.<username>)

たとえば、以下は、電子メール ドライバの OutgoingPassword プロパティについての driverconfig.xml 内のサンプル エントリです。

<Property value="-&gt;/Farm_base_domain/base_domain/server_soa/usermessagingdriver-email:OutgoingPassword.ouser" encodedCredential="true" type="java.lang.String" mandatory="no" name="OutgoingPassword" description="oracle.sdp.messaging.EmailDriverConfig.outgoingPassword"/>

11.4.1.3 電子メール ドライバのコンフィグレーション

電子メール ドライバは、メッセージの送信および受信の両方を行います (つまり、Capability プロパティはデフォルトで BOTH に設定されています)。 電子メール ドライバは SMTP 上でメッセージを送信し、IMAP または POP3 を使用してメッセージを受信します。

11.4.1.3.1 電子メール ドライバの相互運用性

この節では、電子メール ドライバの相互運用性の機能について説明します。

電子メール ドライバは、POP3、IMAP4、および SMTP の各プロトコルと互換性があります。

電子メール ドライバには、以下の機能があります。

- 自動的な接続の再試行

- メッセージ送信用の SMTP

- メッセージ受信用の IMAP4 および POP3 (ポーリングを使用)

- 高度なスケーラビリティ

- メッセージの損失および複製の防止

表 11-2 に示すゲートウェイのベンダとバージョンが検証されています。

表 11-2 電子メール ドライバのゲートウェイのベンダおよびバージョン

ベンダ

バージョン

Oracle Beehive

リリース 1 (1.4.3)

Oracle Collaboration Suite

10g リリース 1 (10.1.2)

Microsoft Exchange

2003

Dovecot (IMAP4/POP3)

0.99.11

sendmail (SMTP)

8.13.1

11.4.1.3.2 共通のプロパティ

これらの共通のドライバ プロパティは、発信メッセージをルーティングする際にエンジンによって使用されるこのドライバの機能を示しています。一部のプロパティはドライバ開発者によって設定され、通常は変更の必要はありません。ただし、ルーティングの動作を変更するために管理者が変更できるものもあります。SendingQueuesInfo などのプロパティは、高度な使用のために用意されており、高度なデプロイメント トポロジ以外での変更の必要はありません。これらのプロパティに関する完全な説明と使用可能な値については、DriverConfigPropertyNames の javadoc を参照してください。

表 11-3 共通の電子メール プロパティ

名前

説明

必須

デフォルト値

InstanceName

インスタンス名 (内部使用のみ)

はい

Email-Driver

Capability

メッセージの送受信の機能

はい

Both

SupportedDeliveryTypes

サポートされている配信タイプ

はい

Email

SupportedContentTypes

サポートされているコンテンツ タイプ

はい

text/plain、text/html、multipart/mixed、multipart/alternative、multipart/related

SupportedStatusTypes

サポートされているステータス タイプ

いいえ

DELIVERY_TO_GATEWAY_SUCCESS、DELIVERY_TO_GATEWAY_FAILURE、USER_REPLY_ACKNOWLEDGEMENT_SUCCESS、USER_REPLY_ACKNOWLEDGEMENT_FAILURE

Cost

コスト

いいえ

N/A

Speed

速度

いいえ

N/A

SupportedCarriers

サポートされているキャリア

いいえ

N/A

Supported Protocols

サポートされているプロトコル

いいえ

N/A

SupportsCancel

メッセージのキャンセル操作をサポートします

いいえ

False

SupportsReplace

メッセージの置換操作をサポートします

いいえ

False

SupportsTracking

メッセージの追跡操作をサポートします

いいえ

False

SupportsStatusPolling

メッセージのステータス ポーリング操作をサポートします

いいえ

False

SenderAddresses

送信者のアドレス

いいえ

N/A

DefaultSenderAddress

デフォルトの送信者アドレス

いいえ

N/A

SendingQueuesInfo

ドライバ送信キューの情報

はい

OraSDPM/QueueConnectionFactory:OraSDPM/Queues/OraSDPMDriverDefSndQ1

11.4.1.3.3 電子メールのカスタム プロパティ

これらのプロパティはこのドライバに固有であり、通常は、リモート ゲートウェイへのアクセスのコンフィグレーションと、特定のプロトコルまたはチャネルに固有の動作に関連付けられています。

表 11-4 カスタム電子メール プロパティ

名前

説明

必須

デフォルト値

MailAccessProtocol

電子メール受信のプロトコル。使用可能な値は IMAP および POP3 です。ドライバ インスタンスで電子メールの受信がサポートされている場合にのみ必要です。

いいえ

IMAP

RetryLimit

この値は、何らかの理由で接続が失われた場合に着信メール サーバへの接続を再試行する回数を指定します。デフォルト値は -1 です。これは、無制限の再試行回数を示します。

いいえ

N/A

MailDelFreq

削除されたメッセージが完全に消去される間隔。秒単位で表され、デフォルト値は 300 秒です。負の値はメッセージが消去されないことを示します。POP3 プロトコルの場合、メッセージは処理された後に消去されます。

いいえ

600

AutoDelete

この値は、メッセージが処理された後にドライバが削除のマークを付ける必要があるかどうかを示します。この値には true または false を指定できます。デフォルト値は false です。POP3 プロトコルの場合、メッセージは常に、処理された直後に削除されます。

いいえ

True

CheckMailFreq

メール サーバからメッセージを取得する間隔。秒単位で表され、デフォルト値は 5 秒です。

いいえ

30

ReceiveFolder

ドライバがメッセージをポーリングするフォルダの名前。デフォルト値は INBOX です。

いいえ

INBOX

OutgoingMailServer

SMTP サーバの名前。 電子メールの送信が必要な場合にのみ必須です。

いいえ

N/A

OutgoingMailServerPort

SMTP サーバのポート番号。 通常は 25 です。

いいえ

25

OutgoingMailServerTLS

SMTP サーバへの通信に TLS 暗号化を使用するかどうか。

いいえ

False

OutgoingDefaultFromAddr

デフォルトの FROM アドレス (発信メッセージで指定されていない場合)。

いいえ

N/A

OutgoingUsername

SMTP 認証で使用するユーザ名。SMTP サーバで SMTP 認証がサポートされている場合にのみ必要です。

いいえ

N/A

OutgoingPassword

SMTP 認証で使用するパスワード。SMTP サーバで SMTP 認証がサポートされている場合にのみ必要です。

いいえ

N/A

IncomingMailServer

着信メール サーバのホスト名。ドライバ インスタンスで電子メールの受信がサポートされている場合にのみ必要です。

いいえ

N/A

IncomingMailServerPort

IMAP4 (143 または 993) サーバまたは POP3 (110 または 995) サーバのポート番号。

いいえ

N/A

IncomingMailServerSSL

IMAP4 または POP3 サーバへの接続で SSL を有効にするかどうか。

いいえ

False

IncomingMailIDs

ユーザ名に対応する電子メール アドレス。各電子メール アドレスはカンマで区切られ、ユーザ名リスト内の対応するユーザ名に相当するリスト内の場所に存在している必要があります。ドライバ インスタンスで電子メールの受信がサポートされている場合にのみ必要です。

いいえ

N/A

IncomingUserIDs

ドライバ インスタンスがポーリングするメール アカウントのユーザ名のリスト。それぞれの名前はカンマで区切る必要があります (foo,bar など)。ドライバ インスタンスで電子メールの受信がサポートされている場合にのみ必要です。

いいえ

N/A

IncomingUserPasswords

ユーザ名に対応するパスワードのリスト。各パスワードはカンマで区切られ、ユーザ名リスト内の対応するユーザ名に相当するリスト内の場所に存在している必要があります。ドライバ インスタンスで電子メールの受信がサポートされている場合にのみ必要です。

いいえ

N/A

IncomingProcessingChunkSize

メッセージ ポーリングごとに処理されるメッセージの最大数。

いいえ

100

11.4.1.3.4 クライアント API MessageInfo のサポート

これらのプロパティは、メッセージの配信に関連し、クライアント API を通じて指定されます。表 11-5 は、これらのプロパティがプロトコルまたはドライバの実装で使用されるかどうかを示します。

表 11-5 クライアント API MessageInfo のサポート

名前

説明

サポート

Expiration

Expiration は、メッセージが期限切れになるまで存続する時間を示します。

False

Delay

Delay は、メッセージが送信されるまでに経過する必要のある時間を示します。

False

11.4.1.4 SMPP ドライバのコンフィグレーション

SMPP (Short Message Peer-to-Peer) は、最も普及している GSM SMS プロトコルの 1 つです。User Messaging Service には、ショート メッセージの送信および受信の両方の機能を持つドライバとして SMPP プロトコルの組み込みの実装が含まれています。送信機能が有効な場合、SMPP ドライバは送信者として、SMS-C (Short Message Service Center) への 1 つの TCP 接続を開きます。ドライバの受信機能が有効な場合は、受信者として、SMS-C への別の接続を開きます。ドライバと SMS-C の間のすべての通信に必要なのは、2 つの TCP 接続 (両方ともドライバによって開始される) だけです。

注意 :
SMPP ドライバは SMPP プロトコル バージョン 3.4 を実装し、このバージョンをサポートする SMS-C への接続のみがサポートされます。

11.4.1.4.1 SMPP ドライバの相互運用性

この節では、SMPP ドライバの相互運用性の機能について説明します。

SMPP ドライバは、SMPP v3.4 プロトコルと互換性があります。

SMPP ドライバには、以下の機能があります。

- 自動的な接続の再試行

- ファイアウォール通過の HTTP プロキシ

- 認証コンフィグレーション

- コンフィグレーション可能なチャンク サイズ

- 一括送信

- エンコーディング : UCS2、IA5、GSM_DEFAULT

- 優先順位の設定

- コンフィグレーション可能なウィンドウ サイズ

- プレーン テキスト コンテンツのみ

表 11-6 に示すゲートウェイ ベンダが検証されています。

表 11-6 SMPP ドライバのゲートウェイ ベンダ

ベンダ

Logica CMG

Clickatell

Verisign

OpenSMPP (シミュレータ)

11.4.1.4.2 共通のプロパティ

これらの共通のドライバ プロパティは、発信メッセージをルーティングする際にエンジンによって使用されるこのドライバの機能を示しています。一部のプロパティはドライバ開発者によって設定され、通常は変更の必要はありません。ただし、ルーティングの動作を変更するために管理者が変更できるものもあります。SendingQueuesInfo などのプロパティは、高度な使用のために用意されており、高度なデプロイメント トポロジ以外での変更の必要はありません。これらのプロパティに関する完全な説明と使用可能な値については、DriverConfigPropertyNames の javadoc を参照してください。

表 11-7 共通の SMPP プロパティ

名前

説明

必須

デフォルト値

InstanceName

インスタンス名 (内部使用のみ)

はい

SMPP-Driver

Capability

メッセージの送受信の機能

はい

Both

SupportedDeliveryTypes

サポートされている配信タイプ

はい

SMS

SupportedContentTypes

サポートされているコンテンツ タイプ

はい

text/plain

SupportedStatusTypes

サポートされているステータス タイプ

いいえ

DELIVERY_TO_GATEWAY_SUCCESS、DELIVERY_TO_GATEWAY_FAILURE

Cost

コスト

いいえ

N/A

Speed

速度

いいえ

N/A

SupportedCarriers

サポートされているキャリア

いいえ

N/A

Supported Protocols

サポートされているプロトコル

いいえ

N/A

SupportsCancel

メッセージのキャンセル操作をサポートします

いいえ

False

SupportsReplace

メッセージの置換操作をサポートします

いいえ

False

SupportsTracking

メッセージの追跡操作をサポートします

いいえ

False

SupportsStatusPolling

メッセージのステータス ポーリング操作をサポートします

いいえ

False

SenderAddresses

送信者のアドレス

いいえ

N/A

DefaultSenderAddress

デフォルトの送信者アドレス

いいえ

N/A

SendingQueuesInfo

ドライバ送信キューの情報

はい

OraSDPM/QueueConnectionFactory:OraSDPM/Queues/OraSDPMDriverDefSndQ1

11.4.1.4.3 カスタム プロパティ

これらのプロパティはこのドライバに固有であり、通常は、リモート ゲートウェイへのアクセスのコンフィグレーションと、特定のプロトコルまたはチャネルに固有の動作に関連付けられています。

表 11-8 カスタム SMPP プロパティ

名前

説明

必須

デフォルト値

SmsAccountId

SMS-C のアカウント ID。

はい

N/A

SmsServerHost

SMS-C サーバの名前 (または IP アドレス)。

はい

N/A

TransmitterSystemId

メッセージの送信に使用するアカウント ID。

はい

N/A

ReceiverSystemId

メッセージの受信に使用するアカウント ID。

はい

N/A

TransmitterSystemType

トランスミッタ システムの種類。

はい

デフォルト値は Logica です。

ReceiverSystemType

レシーバ システムの種類。

はい

デフォルト値は Logica です。

TransmitterSystemPassword

トランスミッタ システムのパスワード。

はい

N/A

ReceiverSystemPassword

レシーバ システムのパスワード。

はい

N/A

ServerTransmitterPort

トランスミッタ システムの TCP ポート番号。

はい

N/A

ServerReceiverPort

レシーバ システムの TCP ポート番号。

はい

N/A

DefaultEncoding

SMPP ドライバのデフォルトのエンコーディング。

いいえ

デフォルト値は UCS2 です。

EncodingAutoDetect

true (デフォルト) に設定すると、SMPP ドライバで自動的にエンコーディングが行われます。

いいえ

デフォルト値は true です。

LocalSendingPort

SMPP ドライバが SMS-C へのメッセージの送信に使用するローカルの TCP ポート。

いいえ

N/A

LocalReceivingPort

SMPP ドライバが SMS-C からのメッセージの受信に使用するローカルの TCP ポート。

いいえ

N/A

LocalAddress

SMPP ドライバをホストするサーバのホスト名 (または IP アドレス)。

いいえ

N/A

WindowSize

SMS のウィンドウ サイズ。この値は正の数にする必要があります。

いいえ

デフォルト値は 1 です。

EnquireInterval

SMS-C に照会メッセージを送信する間隔 (秒単位)。

いいえ

デフォルト値は 30 です。

ThrottleDelay

スロットル間の遅延 (秒単位)。

いいえ

デフォルト値は 15 です。

BindRetryDelay

バインディング再試行の遅延 (秒単位)。

いいえ

デフォルト値は 30 です。

ResponseTimer

SMPP リクエストから応答までの間に許可される時間 (秒単位)。デフォルトは 30 です。

いいえ

30

RegisteredDeliveryMask

バインディング再試行の遅延 (秒単位)。

いいえ

0xFF

RangeSetNull

BIND_RECEIVER の「アドレス範囲」フィールドを null に設定するには、true に設定します。 アドレス範囲フィールドを SmsSystemId に設定するには、false (デフォルト値) に設定します。

いいえ

デフォルト値は false です。

PriorityAllowed

SMPP ドライバで許可される最も高い優先順位。範囲は 0 (通常) から 3 (最高) です。

いいえ

デフォルト値は 0 です。

BulkSending

この値を true (デフォルト) に設定すると、SMS-C へのメッセージの一括送信が有効になります。

いいえ

デフォルト値は true です。

PayloadSending

true に設定すると、SMS-C へのメッセージの送信時に、SMPP ドライバで常にメッセージ ペイロード プロパティが使用されます。

いいえ

デフォルト値は false です。

SourceTon

SMPP レシーバ セッションを通じて処理される ESME アドレスの Type of Number (TON)。

いいえ

デフォルト値は 0 です。

SourceNpi

SMPP レシーバ セッションを通じて処理される ESME アドレスの Numbering Plan Indicator (NPI)。

いいえ

デフォルト値は 0 です。

DestinationTon

宛先の Type of Number (TON)。

いいえ

デフォルト値は 0 です。

DestinationNpi

宛先の Numbering Plan Indicator (NPI)。

いいえ

デフォルト値は 0 です。

ExtraErrorCode

エラー コードのカンマ区切りのリスト。

いいえ

N/A

MaxChunks

メッセージの最大の SMS チャンク。

いいえ

デフォルト値は -1 です (最大値なし)。

ChunkSize

各 SMS メッセージ チャンクのサイズ。

いいえ

デフォルト値は 160 です。

LongMessageSending

長いメッセージの送信をサポートします。

いいえ

N/A

DatagramMessageMode

データグラム メッセージ モードをサポートします。

いいえ

N/A

11.4.1.4.4 クライアント API MessageInfo のサポート

これらのプロパティは、メッセージの配信に関連し、クライアント API を通じて指定されます。表 11-9 は、これらのプロパティがプロトコルまたはドライバの実装で使用されるかどうかを示します。

表 11-9 クライアント API MessageInfo のサポート

名前

説明

サポート

Expiration

Expiration は、メッセージが期限切れになるまで存続する時間を示します。

True

Delay

Delay は、メッセージが送信されるまでに経過する必要のある時間を示します。

False

11.4.1.5 XMPP ドライバのコンフィグレーション

XMPP ドライバでは、XMPP (Extensible Messaging and Presence Protocol) 経由でリアルタイムのインスタント メッセージング (IM) を実行する、Oracle Fusion Middleware からエンド ユーザへの一方向および双方向のアクセスが提供されます。このドライバを使用すると、エンド ユーザは通知を受け取ったり、任意の IM クライアントを通じてアプリケーションと対話型のチャットを開始することができます。

11.4.1.5.1 XMPP について

XMPP は、インスタント メッセージングおよびプレゼンスのための XML ベースのオープン プロトコルです。XMPP ベースのソフトウェアはインターネットを通じて何千ものサーバにデプロイされ、全世界の多数のユーザによって使用されています。XMPP はクライアント-サーバ アーキテクチャによって構成され、ユビキタスな電子メール ネットワークに類似しています。XMPP サーバは完全に非集中型であり、任意のユーザが固有のサーバをセットアップできます。メッセージングは電子メール ネットワークと同様に行われ、受信者はユーザ名とホスト名 (たとえば、username@host name) でアドレス指定されます。XMPP ネットワークでは、ユーザを識別する場合に、ユーザ名と接続先の特定の XMPP サーバのホスト名で構成される、XMPP (Jabber) ID が使用されます。XMPP のエンド ユーザは、他の XMPP ユーザにインスタント メッセージを送信するため、XMPP クライアントを使用して XMPP サーバに接続します。しかし、XMPP は単にインスタント メッセージングに使用可能なプロトコル ネットワークというだけではありません。XMPP は拡張可能なモジュール アーキテクチャを使用します。これは、Yahoo、MSN、AOL、ICQ などの独自のネットワークに接続できるトランスポート ゲートウェイを使用して、これらの IM ネットワークと統合されます。これにより、XMPP ユーザと他のネットワーク上のユーザとの通信が可能になります。

UMS で XMPP ドライバを使用するには、Jabber/XMPP サーバへのアクセスと、UMS XMPP ドライバ インスタンスがログインに使用する XMPP アカウントが必要です。また、XMPP ドライバには、IM ネットワーク (Yahoo、MSN、AOL、または ICQ) 上のユーザとの通信を UMS で有効にするためのコンフィグレーション パラメータがあります。このため、これらの独自の IM ネットワーク上で、XMPP ドライバから接続する追加のアカウントが必要になります。これによって、これらの特定のネットワーク上のエンド ユーザと UMS との通信が可能になります。

11.4.1.5.2 XMPP ドライバの相互運用性

この節では、XMPP ドライバの相互運用性の機能について説明します。

XMPP ドライバは、XMPP (RFC 3920、3921) プロトコルと互換性があります。

XMPP ドライバには、以下の機能があります。

- 自動的な接続の再試行

- ファイアウォール通過の HTTP プロキシ

- プレーン テキスト コンテンツのみ

表 11-6 に示すゲートウェイのベンダとバージョンが検証されています。

表 11-10 XMPP ドライバのゲートウェイのベンダおよびバージョン

ベンダ

バージョン

Jabberd

v1、v2

ejabberd

v2

11.4.1.5.3 サードパーティ製ソフトウェア

XMPP ドライバでは、以下のサードパーティ製ソフトウェアが必要です。

表 11-11 必要なサードパーティ製ソフトウェア

名前

説明

バージョン

JabberBeans

このドライバは、JabberBeans Java ライブラリを使用して Jabber/XMPP インスタント メッセージング サーバに接続します。このドライバには、JabberBeans (バージョン 0.9.1) のライセンス コピーが含まれています。

0.9.1

XMPP サーバ

省略可能。独自の Jabber/XMPP サーバをダウンロードおよびインストールするには、http://www.jabber.org からサーバを選択してインストールします。

Yahoo、MSN、AOL(AIM)、および ICQ のトランスポート ゲートウェイ

省略可能。独自の IM ゲートウェイに接続する 1 つまたは複数のトランスポートをインストールおよびコンフィグレーションするには、Jabber/XMPP サーバに付属のトランスポートのインストール ガイドを参照してください。

注意 :
既存のサーバにアクセスできる場合は、独自の XMPP サーバをインストールする必要はありません。パブリック サーバのリストについては、http://www.jabber.org を参照してください。

11.4.1.5.4 ドライバ アプリケーション アーカイブ (EAR)

$ORACLE_HOME/communications/applications/sdpmessagingdriver-xmpp.ear

11.4.1.5.5 共通のプロパティ

これらの共通のドライバ プロパティは、発信メッセージをルーティングする際にエンジンによって使用されるこのドライバの機能を示しています。一部のプロパティはドライバ開発者によって設定され、通常は変更の必要はありません。ただし、ルーティングの動作を変更するために管理者が変更できるものもあります。SendingQueuesInfo などのプロパティは、高度な使用のために用意されており、高度なデプロイメント トポロジ以外での変更の必要はありません。これらのプロパティに関する完全な説明と使用可能な値については、DriverConfigPropertyNames の javadoc を参照してください。

表 11-12 共通の XMPP プロパティ

名前

説明

必須

デフォルト値

InstanceName

インスタンス名 (内部使用のみ)

はい

XMPP-IM-Driver

Capability

メッセージの送受信の機能

はい

Both

SupportedDeliveryTypes

サポートされている配信タイプ

はい

IM

SupportedContentTypes

サポートされているコンテンツ タイプ

はい

text/plain

SupportedStatusTypes

サポートされているステータス タイプ

いいえ

DELIVERY_TO_GATEWAY_SUCCESS、DELIVERY_TO_GATEWAY_FAILURE

Cost

コスト

いいえ

N/A

Speed

速度

いいえ

N/A

SupportedCarriers

サポートされているキャリア

いいえ

N/A

Supported Protocols

サポートされているプロトコル

いいえ

N/A

SupportsCancel

メッセージのキャンセル操作をサポートします

いいえ

False

SupportsReplace

メッセージの置換操作をサポートします

いいえ

False

SupportsTracking

メッセージの追跡操作をサポートします

いいえ

False

SupportsStatusPolling

メッセージのステータス ポーリング操作をサポートします

いいえ

False

SenderAddresses

送信者のアドレス

いいえ

N/A

DefaultSenderAddress

デフォルトの送信者アドレス

いいえ

N/A

SendingQueuesInfo

ドライバ送信キューの情報

はい

OraSDPM/QueueConnectionFactory:OraSDPM/Queues/OraSDPMDriverDefSndQ1

11.4.1.5.6 XMPP カスタム プロパティ

XMPP ドライバには、以下のカスタム プロパティがあります。

表 11-13 カスタム XMPP プロパティ

名前

説明

必須

デフォルト値

IMServerHost

Jabber サーバのホスト名。複数のサーバの場合は、カンマ区切りのリストを使用します (my1.host.com, my2.host.com など)。 ホスト名を 1 つのみ指定した場合は、そのホストがすべてのアカウントで使用されます。

はい

N/A

IMServerPort

対応する Jabber サーバ ポートのカンマ区切りのリスト (5222, 5222 など)。

はい

5222

IMServerUsername

ログインに使用する Jabber ユーザ名のリスト (これらのユーザ アカウントは、対応する Jabber サーバ上で必要に応じて自動的に作成されます)。上のリストに複数のサーバが含まれている場合は、同じ数のユーザ名が存在している必要があります (各サーバにつき 1 つのユーザ名)。上のリストに 1 つのサーバのみが含まれている場合は、そのサーバがこのリスト内のすべてのユーザ名によって使用されます (oracleagent1, oracleagent2 など)。ドメイン名が Jabber サーバのホスト名と異なる場合は、完全な Jabber ID を入力することもできます (たとえば、oracleagent1@host.com)。

はい

N/A

IMServerPassword

上のリストの各ユーザ名に対応するパスワードのカンマ区切りのリスト。

はい

N/A

YahooEnable

上のカンマ区切りのリストで指定した各ユーザ アカウントに対し、Yahoo トランスポートを有効または無効にします (「有効」にするには、true に設定します。「無効」にするには、空のままにするか false に設定します)。

いいえ

N/A

YahooUsername

上の各ユーザ アカウントに対する、Yahoo アカウント ID のカンマ区切りのリスト (Yahoo が不要なアカウントではエントリを空のままにします)。これらの ID は Yahoo ですでに登録されている必要があります。有効な Yahoo アカウント情報を入力すると、Yahoo ユーザがインスタント メッセージングを通じてアプリケーションにアクセスできるようになります。

いいえ

N/A

YahooPassword

対応する Yahoo アカウント パスワードのカンマ区切りのリスト。

いいえ

N/A

MSNEnable

上のカンマ区切りのリストで指定した各ユーザ アカウントに対し、MSN トランスポートを有効または無効にします (有効にするには、「true」に設定します。無効にするには、空のままにするか「false」に設定します)。

いいえ

N/A

MSNUsername

上の各ユーザ アカウントに対する、MSN Messenger (.NET passport と呼ばれる) のアカウント ID のカンマ区切りのリスト (MSN が不要なアカウントではエントリを空のままにします)。これらの ID は .NET passports ですでに登録されている必要があります。有効な .NET アカウント情報を入力すると、MSN Messenger ユーザがインスタント メッセージングを通じてアプリケーションにアクセスできるようになります。

いいえ

N/A

MSNPassword

対応する MSN Messenger アカウント パスワードのカンマ区切りのリスト。

いいえ

N/A

AOLEnable

上のカンマ区切りのリストで指定した各ユーザ アカウントに対し、AOL IM (AIM) トランスポートを有効または無効にします (有効にするには、「true」に設定します。無効にするには、空のままにするか「false」に設定します)。

いいえ

N/A

AOLUsername

上の各ユーザ アカウントに対する、AOL IM (AIM) アカウント ID のカンマ区切りのリスト (AOL が不要なアカウントではエントリを空のままにします)。これらの ID は AOL ですでに登録されている必要があります。有効な AOL アカウント情報を入力すると、AOL ユーザがインスタント メッセージングを通じてアプリケーションにアクセスできるようになります。

いいえ

N/A

AOLPassword

対応する AOL IM アカウント パスワードのカンマ区切りのリスト。

いいえ

N/A

ICQEnable

上のカンマ区切りのリストで指定した各ユーザ アカウントに対し、ICQ IM トランスポートを有効または無効にします (有効にするには、「true」に設定します。無効にするには、空のままにするか「false」に設定します)。

いいえ

N/A

ICQUsername

上の各ユーザ アカウントに対する、ICQ アカウント ID のカンマ区切りのリスト (ICQ が不要なアカウントではエントリを空のままにします)。これらの ID は ICQ ですでに登録されている必要があります。有効な ICQ アカウント情報を入力すると、ICQ ユーザがインスタント メッセージングを通じてアプリケーションにアクセスできるようになります。

いいえ

N/A

ICQPassword

対応する ICQ アカウント パスワードのカンマ区切りのリスト。

いいえ

N/A

RetryLimit

Jabber サーバから切断された場合にドライバが接続を再試行する回数。再試行回数を無制限にするには -1 を入力します。

いいえ

N/A

RetryInterval

接続を再試行する間隔 (秒単位)。

いいえ

N/A

11.4.1.5.7 クライアント API MessageInfo のサポート

これらのプロパティは、メッセージの配信に関連し、クライアント API を通じて指定されます。下の表は、これらのプロパティがプロトコルまたはドライバの実装で使用されるかどうかを示します。

表 11-14 クライアント API MessageInfo のサポート

名前

説明

サポート

Expiration

Expiration は、メッセージが期限切れになるまで存続する時間を示します。

False

Delay

Delay は、メッセージが送信されるまでに経過する必要のある時間を示します。

False

11.4.1.6 VoiceXML ドライバのコンフィグレーション

VoiceXML ドライバは、VoiceXML で作成されたメッセージを送信する Genesys VoiceGenie ゲートウェイの発信通話プロトコルをサポートしています。ゲートウェイでは、Text-To-Speech 処理を使用してメッセージを配信します。

11.4.1.6.1 VoiceXML ドライバの相互運用性

この節では、VoiceXML ドライバの相互運用性の機能について説明します。

VoiceXML ドライバは、VoiceXML over HTTP (VoiceGenie ゲートウェイ プロトコル) と互換性があります。

VoiceXML ドライバには、以下の機能があります。

- VoiceXML コンテンツのみ

表 11-6 に示すゲートウェイのベンダとバージョンが検証されています。

表 11-15 VoiceXML ドライバのゲートウェイのベンダおよびバージョン

ベンダ

バージョン

Genesys VoiceGenie

6.4.2

11.4.1.6.2 共通のプロパティ

これらの共通のドライバ プロパティは、発信メッセージをルーティングする際にエンジンによって使用されるこのドライバの機能を示しています。一部のプロパティはドライバ開発者によって設定され、通常は変更の必要はありません。ただし、ルーティングの動作を変更するために管理者が変更できるものもあります。SendingQueuesInfo などのプロパティは、高度な使用のために用意されており、高度なデプロイメント トポロジ以外での変更の必要はありません。これらのプロパティに関する完全な説明と使用可能な値については、DriverConfigPropertyNames の javadoc を参照してください。

表 11-16 共通の VoiceXML プロパティ

名前

説明

必須

デフォルト値

InstanceName

インスタンス名 (内部使用のみ)

はい

VoiceXML-Driver

Capability

メッセージの送受信の機能

はい

SEND

SupportedDeliveryTypes

サポートされている配信タイプ

はい

VOICE

SupportedContentTypes

サポートされているコンテンツ タイプ

はい

text/vxml、text/x-vxml

SupportedStatusTypes

サポートされているステータス タイプ

いいえ

DELIVERY_TO_GATEWAY_SUCCESS、DELIVERY_TO_GATEWAY_FAILURE

Cost

コスト

いいえ

N/A

Speed

速度

いいえ

N/A

SupportedCarriers

サポートされているキャリア

いいえ

N/A

Supported Protocols

サポートされているプロトコル

いいえ

N/A

SupportsCancel

メッセージのキャンセル操作をサポートします

いいえ

False

SupportsReplace

メッセージの置換操作をサポートします

いいえ

False

SupportsTracking

メッセージの追跡操作をサポートします

いいえ

False

SupportsStatusPolling

メッセージのステータス ポーリング操作をサポートします

いいえ

False

SenderAddresses

送信者のアドレス

いいえ

N/A

DefaultSenderAddress

デフォルトの送信者アドレス

いいえ

N/A

SendingQueuesInfo

ドライバ送信キューの情報

はい

OraSDPM/QueueConnectionFactory:OraSDPM/Queues/OraSDPMDriverDefSndQ1

11.4.1.6.3 VoiceXML カスタム プロパティ

VoiceXML ドライバには、以下のカスタム プロパティがあります。

表 11-17 カスタム VoiceXML プロパティ

名前

説明

必須

デフォルト値

VoiceXMLOutboundServletURI

VoiceXML/VoiceGenie ゲートウェイの URL。

はい

N/A

VoiceXMLOutboundServletUserName

VoiceXML ゲートウェイのユーザ名。

いいえ

N/A

VoiceXMLOutboundServletPassword

VoiceXML ゲートウェイのパスワード。

いいえ

N/A

VoiceXMLOutboundServletDNIS

受信者の ID 表示に表示される数。

いいえ

N/A

VoiceXMLReceiveURL

VoiceXML Gateway からの着信リクエストを処理するこのドライバのサーブレットの URL。フォーマットは http://<host>:<port>/usermessagingdriver-voicexml/receive です。 このプロパティが設定されていない場合、デフォルトの動作では、ローカル コンテナの HTTP リスン ホストおよびリスン ポートが使用されます。自動生成されたデフォルトの URL は、最初のドライバ インスタンスでのみ機能します。その他のインスタンスではコンテキスト ルートが異なるため、/sdpmessagingdriver-voicexml でコンテキスト ルートを適切に置き換えて、このプロパティをコンフィグレーションする必要があります。

いいえ

N/A

11.4.1.6.4 クライアント API MessageInfo のサポート

これらのプロパティは、メッセージの配信に関連し、クライアント API を通じて指定されます。下の表は、これらのプロパティがプロトコルまたはドライバの実装で使用されるかどうかを示します。

表 11-18 クライアント API MessageInfo のサポート

名前

説明

サポート

Expiration

Expiration は、メッセージが期限切れになるまで存続する時間を示します。

False

Delay

Delay は、メッセージが送信されるまでに経過する必要のある時間を示します。

False

11.4.1.7 Worklist ドライバのコンフィグレーション

Worklist ドライバを使用すると、すべてのソースからの通知を、ユーザの WebCenter Unified Worklist に統合される worklist タスクの形でユーザに送信できます。

注意 :
Worklist メッセージ タスクは、Worklist メッセージ ドライバがメッセージを送信する BPEL 接続を検索するようにコンフィグレーションされている WebCenter と、BPEL Worklist アプリケーションの両方からアクセスすることができます。これらのメッセージ ベースのタスクは、BPEL Worklist アプリケーションでも Worklist アイテムとして表示されます。

この統合は、Worklist チャネル (配信タイプ) をアプリケーションとエンド ユーザに公開することで実現します。 ユーザの Worklist チャネルを通じて送信されたメッセージは Worklist ドライバで処理されます。User Messaging Service API のセマンティクスは、IM や電子メールなどの既存のチャネルと同様です。このドライバでは、メッセージの送信のみが処理されます。ドライバ アプリケーション アーカイブ (EAR) は $ORACLE_HOME/communications/applications/sdpmessagingdriver-worklist.ear にあります。

11.4.1.7.1 Worklist ドライバのインストール

メッセージングの worklist 機能を有効にするには、$ORACLE_HOME/common/templates/applications/oracle.ums.driver.worklist_template_11.1.1.jar にある拡張テンプレートを使用して、WebLogic SOA ドメインを拡張する必要があります。 Oracle Fusion Middleware Configuration Wizard を使用して SOA ドメインを拡張するには、以下の手順を実行します。

1. Oracle Fusion Middleware Configuration Wizard ($ORACLE_HOME/common/bin/config.sh または %ORACLE_HOME%\common\bin\config.cmd) を起動します。

2. [既存の WebLogic ドメインの拡張] オプションを選択します。

3. 必要な SOA ドメイン ディレクトリを選択します。

4. [Extend my domain using an existing extension template] オプションを選択します。

5. [参照] をクリックし、$ORACLE_HOME/common/templates/applications に移動します。

6. oracle.ums.driver.worklist_template_11.1.1.jar を選択します。

7. Oracle Fusion Middleware Configuration Wizard の残りの手順を完了し、SOA サーバを再起動します。

注意 :
SOA 管理対象サーバがリモート マシン上にある場合の特殊な考慮事項 : oracle.ums.driver.worklist_template_11.1.1.jar 拡張テンプレートには、$DOMAIN_HOME/soa/autodeploy にコピーされ、サーバの再起動時に SOA Infra ランタイムによって自動デプロイされる SOA 複合アプリケーション (sca_sdpmessagingsca-worklist-composite_rev1.0.jar) が含まれています。 ただし、SOA Infra ランタイムがリモート マシン上にあり、ドメインが -managed=true オプション (使用時の適切なオプション) を使用してパックされた場合は、このディレクトリがアーカイブに含まれません。 この結果、SOA 管理対象サーバの再起動時に複合アプリケーションがデプロイされません。
インストールを完了するには、AdminServer マシンにある $DOMAIN_HOME/soa/autodeploy のコンテンツを SOA 管理対象サーバがあるリモート マシンの対応する場所にコピーし、SOA 管理対象サーバを再起動します。 リモート マシンの $DOMAIN_HOME の下に、ディレクトリ構造 soa/autodeploy を作成する必要がある場合があります。

11.4.1.7.2 共通のプロパティ

これらの共通のドライバ プロパティは、発信メッセージをルーティングする際にエンジンによって使用されるこのドライバの機能を示しています。一部のプロパティはドライバ開発者によって設定され、通常は変更の必要はありません。ただし、ルーティングの動作を変更するために管理者が変更できるものもあります。SendingQueuesInfo などのプロパティは、高度な使用のために用意されており、高度なデプロイメント トポロジ以外での変更の必要はありません。 これらのプロパティに関する完全な説明と、使用可能な値については、DriverConfigPropertyNames の javadoc を参照してください。

表 11-19 共通の Worklist プロパティ

名前

説明

必須

デフォルト値

InstanceName

インスタンス名 (内部使用のみ)

はい

Worklist-Driver

Capability

メッセージの送受信の機能

はい

SEND

SupportedDeliveryTypes

サポートされている配信タイプ

はい

WORKLIST

SupportedContentTypes

サポートされているコンテンツ タイプ

はい

text/plain、text/html

SupportedStatusTypes

サポートされているステータス タイプ

いいえ

DELIVERY_TO_GATEWAY_SUCCESS、DELIVERY_TO_GATEWAY_FAILURE

Cost

コスト

いいえ

N/A

Speed

速度

いいえ

N/A

SupportedCarriers

サポートされているキャリア

いいえ

N/A

SupportedProtocols

サポートされているプロトコル

いいえ

N/A

SupportsCancel

メッセージのキャンセル操作をサポートします

いいえ

False

SupportsReplace

メッセージの置換操作をサポートします

いいえ

False

SupportsTracking

メッセージの追跡操作をサポートします

いいえ

False

SupportsStatusPolling

メッセージのステータス ポーリング操作をサポートします

いいえ

False

SenderAddresses

送信者のアドレス

いいえ

N/A

DefaultSenderAddress

デフォルトの送信者アドレス

いいえ

N/A

SendingQueuesInfo

ドライバ送信キューの情報

はい

OraSDPM/QueueConnectionFactory:OraSDPM/Queues/OraSDPMDriverDefSndQ1

11.4.1.7.3 カスタム プロパティ

以下のカスタム プロパティを使用できます。

表 11-20 カスタム Worklist プロパティ

名前

説明

必須

デフォルト値

BPELConnectionURL

接続先の BPEL サーバの URL。フォーマットは http://<bpel-host>:<bpel-port> です。 デフォルトの動作を変更しない限り、ローカル コンテナの HTTP 接続の URL が使用されます。

11.4.1.7.4 クライアント API MessageInfo のサポート

下の表は、クライアント API を通じて指定された以下のメッセージ配信関連のプロパティが、プロトコルまたはドライバの実装で使用されるかどうかを示します。

表 11-21 クライアント API MessageInfo のサポート

名前

説明

サポート

Expiration

Expiration は、メッセージが期限切れになるまで存続する時間を示します。

False

Delay

Delay は、メッセージが送信されるまでに経過する必要のある時間を示します。

False

11.4.1.8 プロキシ ドライバのコンフィグレーション

プロキシ ドライバは、イントラネットまたはインターネット上の任意の場所にホストされている Fusion Middleware Messaging サーバに対する Messaging Web Service クライアントとして機能します。メッセージの送受信、およびメッセージ配信ステータスの返却には、SOAP over HTTP (Parlay X Multimedia Web Service プロトコル) が使用されます。ParlayX Web Service によって、ある UMS インスタンスから別のインスタンスにメッセージが中継されます。これを使用して、イントラネット内の複数のインスタンスから、SMSC などの外部ゲートウェイや SMTP または IMAP メール サーバなどにコンフィグレーションされているすべてのプロトコル固有のドライバが存在する、終端のインスタンスへのトラフィックが中継されます。

11.4.1.8.1 共通のプロパティ

これらの共通のドライバ プロパティは、発信メッセージをルーティングする際にエンジンによって使用されるこのドライバの機能を示しています。一部のプロパティはドライバ開発者によって設定され、通常は変更の必要はありません。ただし、ルーティングの動作を変更するために管理者が変更できるものもあります。SendingQueuesInfo などのプロパティは、高度な使用のために用意されており、高度なデプロイメント トポロジ以外での変更の必要はありません。これらのプロパティに関する完全な説明と使用可能な値については、DriverConfigPropertyNames の javadoc を参照してください。

表 11-22 共通のプロキシ プロパティ

名前

説明

必須

デフォルト値

InstanceName

インスタンス名 (内部使用のみ)

はい

Proxy-Driver

Capability

メッセージの送受信の機能

はい

SEND

SupportedDeliveryTypes

サポートされている配信タイプ

はい

EMAIL、SMS、VOICE、IM、WORKLIST

SupportedContentTypes

サポートされているコンテンツ タイプ

はい

*

SupportedStatusTypes

サポートされているステータス タイプ

いいえ

DELIVERY_TO_GATEWAY_SUCCESS、DELIVERY_TO_GATEWAY_FAILURE

Cost

コスト

いいえ

N/A

Speed

速度

いいえ

N/A

SupportedCarriers

サポートされているキャリア

いいえ

N/A

Supported Protocols

サポートされているプロトコル

いいえ

N/A

SupportsCancel

メッセージのキャンセル操作をサポートします

いいえ

False

SupportsReplace

メッセージの置換操作をサポートします

いいえ

False

SupportsTracking

メッセージの追跡操作をサポートします

いいえ

False

SupportsStatusPolling

メッセージのステータス ポーリング操作をサポートします

いいえ

False

SenderAddresses

送信者のアドレス

いいえ

N/A

DefaultSenderAddress

デフォルトの送信者アドレス

いいえ

N/A

SendingQueuesInfo

ドライバ送信キューの情報

はい

OraSDPM/QueueConnectionFactory:OraSDPM/Queues/OraSDPMDriverDefSndQ1

11.4.1.8.2 プロキシのカスタム プロパティ

プロキシ ドライバには、以下のカスタム プロパティがあります。

表 11-23 カスタム プロキシ プロパティ

名前

説明

必須

デフォルト値

GatewayURL

ホストされている 11g UMS Web Service ゲートウェイへの URL。 URL のフォーマットは以下のとおりです。

http://<host>:<port>/sdpmessaging/parlayx/SendMessageService

はい

N/A

Username

メッセージング ゲートウェイのユーザ名。

いいえ

N/A

Password

ユーザ名のパスワード。

いいえ

N/A

Policies

プロキシ ドライバのリクエストにアタッチされる Oracle Web Services Manager WS-Security ポリシーのカンマ区切りのリスト。

いいえ

N/A

11.4.1.8.3 クライアント API MessageInfo のサポート

これらのプロパティは、メッセージの配信に関連し、クライアント API を通じて指定されます。下の表は、これらのプロパティがプロトコルまたはドライバの実装で使用されるかどうかを示します。

表 11-24 クライアント API MessageInfo のサポート

名前

説明

サポート

Expiration

Expiration は、メッセージが期限切れになるまで存続する時間を示します。

False

Delay

Delay は、メッセージが送信されるまでに経過する必要のある時間を示します。

False

11.5 User Messaging Service のセキュリティ

User Messaging Preferences ユーザ インタフェースおよび Parlay X Web Services は、セキュア ソケット レイヤ (SSL) を使用してトランスポート レベルで保護できます。デフォルトでは、すべてのデプロイされた Web サービスは保護されていません。プロダクション環境にデプロイされるサービスでは、Web サービス セキュリティを有効にする必要があります。

- Oracle WebLogic Server で SSL を有効にするには、『Oracle Fusion Middleware Administrator's Guide』の「Configure SSL for Oracle WebLogic Server」を参照してください。 User Messaging Preferences ユーザ インタフェースは、この手順によって十分に保護されます。

- Parlay X Web Services を保護するには、WebLogic Web サービスのセキュリティに関するドキュメントの「Configuring Transport-Level Security」を参照してください。

UMS では、UMS Web サービスを保護する Oracle Web Services Manager の WS-Security ポリシーの使用がサポートされています。Oracle Web Services Manager の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server Web サービスのセキュリティ』の「Using Oracle Web Service Security Policies」を参照してください。

Web サービスで推奨されるセキュリティ コンフィグレーションでは、Security Assertion Markup Language (SAML) トークンを使用して、Web サービス クライアントと UMS の間で ID の受け渡しを行います。SAML トークンを使用すると、Web サービス クライアントがユーザ名とパスワードを UMS に渡す代わりに、証明書の交換を通じてクライアントと UMS の間の信頼関係が確立されます。このようなキーストア コンフィグレーションが作成されると、Web サービス クライアントはユーザ ID のみを渡して、ユーザが適切に認証されていることを保証します。

UMS Web サービスで使用が推奨されるポリシーは、以下のとおりです。

- oracle/wss11_saml_token_with_message_protection_service_policy (サーバ側)

- oracle/wss11_saml_token_with_message_protection_service_policy (クライアント側)

11.5.1 通知時の Web サービス セキュリティ

各種の Web サービスには、クライアント側で実行される、対応する通知 Web サービス (MessageNotification、PresenceNotification) が含まれており、これらは該当するイベントが発生すると通知 (メッセージ配信ステータス、メッセージの受信、プレゼンス ステータスの変更) を受け取ります。この実装では、クライアントへの通知時に、デフォルトで Web サービス セキュリティ (WS-Security) が使用されません。つまり、サーバでは、クライアント側で実行される通知 Web サービスで WS-Security が使用されないことを想定し、通知を送信する際に自身の認証を試行しません。クライアント側で WS-Security を有効にすると、通知 SOAP リクエストに必要なヘッダが含まれていないため、サーバからの通知は失敗します。

11.5.2 UMS サービス セキュリティの有効化

UMS Web サービスのポリシーを有効にするには、『Oracle Fusion Middleware Oracle WebLogic Server Web サービスのセキュリティ』の「Configuring Oracle WSM Security Policies in Administration Console」の手順に従って、ポリシー oracle/wss11_saml_token_with_message_protection_service_policy を選択します。保護する必要のあるサービスごとに、このコンフィグレーションを繰り返す必要があります。

11.5.3 クライアントのセキュリティの有効化

Web サービス クライアントのセキュリティはプログラムで有効にする必要があります。「Parlay X Messaging Client API and Client Proxy Packages」(『Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite』を参照) に記述されたクライアント ライブラリを使用する場合は、クライアント オブジェクトの作成時に WS-Security ポリシー コンフィグレーションが提供されます。クライアントのコンストラクタは型 Map<String, Object> の引数を取ります。 SAML 認証を使用する場合は、通常、エンドポイント アドレスなどの他の必須プロパティのほかに、キーと値の組み合わせ (表 11-25) をコンフィグレーション マップに追加する必要があります。

表 11-25 クライアントのセキュリティ キー

キー

型

通常の値

oracle.sdp.parlayx.ParlayXConstants.POLICIES

String[]

oracle/wss11_saml_token_with_message_protection_client_policy

javax.xml.ws.BindingProvider.USERNAME_PROPERTY

String

<有効なユーザ名>

oracle.wsm.security.util.SecurityConstants.Config.KEYSTORE_RECIPIENT_ALIAS_PROPERTY

String

(省略可能) 対象となるサービスのキーストア エリアス。「クライアントのエリアス」を参照してください。

例 11-1 Web サービス クライアントのセキュリティ

import oracle.sdp.parlayx.presence.consumer.PresenceConsumerClient;

...

Map<String, Object> config = new HashMap<String, Object>();
config.put(javax.xml.ws.BindingProvider.ENDPOINT_ADDRESS_PROPERTY, ums_url);
config.put(oracle.sdp.parlayx.ParlayXConstants.POLICIES, new String[] {"oracle/wss11_saml_token_with_message_protection_client_policy"});
config.put(javax.xml.ws.BindingProvider.USERNAME_PROPERTY, "test.user1");

PresenceConsumerClient presenceClient = new PresenceConsumerClient(config);

11.5.4 キーストアのコンフィグレーション

推奨される WS-Security ポリシーを使用するには、OWSM に必要なパブリック キーおよびプライベート キー情報が含まれているキーストアをコンフィグレーションする必要があります。キーストアおよび該当する資格ストア エントリをコンフィグレーションする方法については、『Oracle Fusion Middleware Oracle WebLogic Server Web サービスのセキュリティ』の「Configuring the Credential Store Using WLST」を参照してください。

- Web サービス クライアントと UMS サーバが同じドメイン内にある場合は、キーストアと資格ストアが共有されます。

- Web サービス クライアントと UMS サーバが異なるドメイン内にある場合は、UMS のパブリック キーをクライアント ドメインのキーストアにインポートし、クライアント ドメインのパブリック キーを UMS のキーストアにインポートする必要があります。

11.5.5 クライアントのエリアス

ここで推奨される SAML ポリシーなどの特定の WS-Security ポリシーを使用する場合、クライアントではサーバのパブリック キーを使用して Web サービス リクエストを暗号化する必要があります。ただし、1 つのドメインにつきコンフィグレーションされているキーストアは通常 1 つのみです。このため、あるドメインの Web サービス クライアントが他の複数のドメイン内の Web サービスと通信するようなときは、OWSM で使用されるデフォルトのキーストア エントリをオーバーライドする必要がある場合があります。

たとえば、あるドメインに、UMS Web サービスに対する Web サービス クライアントであるアプリケーション「A」と、他のドメインの Web サービスに対する Web サービス クライアントであるアプリケーション「B」があるとします。この場合、A のリクエストは UMS ドメインのパブリック キーを使用して暗号化し、B のリクエストは他のドメインのパブリック キーを使用して暗号化する必要があります。これを行うには、OWSM で使用されるキーストア エリアスを各リクエストでオーバーライドします。

- (たとえば) UMS パブリック キーにエリアス「ums_public_key」、他のパブリック キーにエリアス「other_public_key」を使用してインポートします。

- UMS Web サービス クライアントを作成する場合に、受信者のキーストア エリアス パラメータを指定します。キーを oracle.wsm.security.util.SecurityConstants.Config.KEYSTORE_RECIPIENT_ALIAS_PROPERTY に設定し、値を「ums_public_key」に設定します (例 11-2 を参照)。

例 11-2 クライアントのエリアス

import oracle.sdp.parlayx.multimedia_messaging.send.SendMessageClient

...

Map<String, Object> config = new HashMap<String, Object>();
config.put(javax.xml.ws.BindingProvider.ENDPOINT_ADDRESS_PROPERTY, ums_url);
config.put(oracle.sdp.parlayx.ParlayXConstants.POLICIES, new String[] {"oracle/wss11_saml_token_with_message_protection_client_policy"});
config.put(javax.xml.ws.BindingProvider.USERNAME_PROPERTY, "test.user1");
config.put(oracle.wsm.security.util.SecurityConstants.Config.KEYSTORE_RECIPIENT_ALIAS_PROPERTY, "ums_public_key")
SendMessageClient sendClient = new SendMessageClient(config);

- 他の Web サービス クライアントでも同様にキーストア エリアスをオーバーライドする必要がありますが、厳密なメカニズムは異なる場合があります。たとえば、JAX-WS クライアント スタブ ディレクトリを使用している場合は、オーバーライド プロパティを JAX-WS リクエスト コンテキストに追加できます。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server Web サービスのセキュリティ』の「Policy Configuration Overrides for the Web Service Client」を参照してください。

11.6 Oracle User Messaging Service のトラブルシューティング

User Messaging Service をデバッグする場合は、まずサーバ診断ログを確認します。ログには、不正な動作の詳細が記載された例外、エラー、または警告メッセージのほか、問題を緩和する方法が含まれている場合があります。以下の表は、User Messaging Service の一般的な問題をデバッグするための追加の方法について説明しています。

表 11-26 UMS のトラブルシューティング

症状

考えられる原因

解決策

SOA の BPEL または Human Workflow コンポーネントから通知が送信されません。

SOA ワークフロー通知のコンフィグレーションで通知モードが NONE に設定されています。

Oracle Fusion Middleware Control を使用して、通知モードの設定を EMAIL または ALL に変更します。

電子メール通知が送信されません。

UMS 電子メール ドライバの発信 (SMTP) メール サーバの設定が正しくありません。

Oracle Fusion Middleware Control を使用して、UMS 電子メール ドライバの以下の設定を確認してください。

- OutgoingMailServer

- OutgoingMailServerPort

注意 : 任意の電子メール クライアントで SMTP サーバへの接続にこれらの値を使用して、値を検証してください。

SMTP サーバで認証またはセキュアな接続が要求されています (TLS または SSL)。

Oracle Fusion Middleware Control を使用して、UMS 電子メール ドライバの以下の設定を確認してください。

- OutgoingUsername

- OutgoingPassword

- OutgoingMailServerSecurity

「送信者アドレス = <address> に一致するドライバが見つからない」ことを示すエラー メッセージのため、通知が送信されません。

該当するチャネルの UMS ドライバが固有の SenderAddresses リストによってコンフィグレーションされているときに、アプリケーションから送信されたメッセージで、これと一致しない送信者アドレスが設定されています。

注意 : UMS サーバでは、発信メッセージの送信者アドレスが設定されている場合に、使用可能なドライバの SenderAddresses との照合を行い、一致するドライバを検索してメッセージの配信に使用します。ドライバに 1 つまたは複数の SenderAddresses が設定されている場合、UMS サーバでは、送信者アドレスがこれに一致するメッセージのみが送信されます。

- Oracle Fusion Middleware Control を使用して、該当する UMS ドライバの以下の設定を確認してください。
SenderAddresses

注意 : SenderAddresses のフォーマットは <DeliveryType>:<Address> のカンマ区切りのリストです。

次に例を示します。

EMAIL:sender@example.com, EMAIL:sender@example2.com

- このドライバで、このチャネル (配信タイプ) のすべての送信者アドレスの発信メッセージを処理する必要がある場合は、このプロパティを空のままにします。

- 同一のチャネル (配信タイプ) に、コンフィグレーションが異なる複数のドライバ インスタンスがデプロイされている場合は、SenderAddresses を使用してドライバ インスタンスを区別します。 たとえば、一方のインスタンスに SenderAddresses の特定の値を設定して、送信者アドレスが一致する発信メッセージのみを処理するようにできます。これに対し、もう一方のインスタンスの SenderAddresses は空のままにして、送信者アドレスが指定されていないメッセージや、最初のドライバ インスタンスと一致しないアドレスを持つメッセージなどのすべての発信メッセージを処理できます。

- SenderAddresses が間違った構文でコンフィグレーションされている場合は (<DeliveryType>: が足りないなど)、UMS サーバでドライバが選択される際に無視されます。

電子メール クライアントで受信される通知に整合性がありません。

UMS 電子メール ドライバの着信メール サーバ設定が、通知が送信される電子メール アカウントと同じアカウントを使用してコンフィグレーションされています。

同じアカウントに通知が送信されると、電子メール クライアントで表示される前に、UMS 電子メール ドライバが電子メールをダウンロードして処理します。

着信メール サーバ設定で専用の電子メール アカウントを使用してください。Oracle Fusion Middleware Control を使用して、UMS 電子メール ドライバの以下の設定を確認してください。

- IncomingMailIDs

- IncomingUserIDs

SOA Human Workflow の通知が送信されますが、アクション可能ではありません。

SOA ワークフロー通知プロパティで、アクション可能な電子メール アドレスがコンフィグレーションされていません。

UMS 電子メール ドライバにコンフィグレーションされた電子メール アカウントのアドレスを使用して、SOA ワークフロー通知プロパティでアクション可能な電子メール アドレスを設定してください。

Human Workflow タスクがアクション可能な通知を送信するように設定されていません。

JDeveloper で Human Workflow タスクの actionable 属性を設定し、SOA 複合アプリケーションを再デプロイしてください。

SOA Human Workflow のアクション可能な通知が送信されますが、応答した後にアクションが実行されません。

UMS 電子メール ドライバの着信メール サーバ設定が正しくありません。

Oracle Fusion Middleware Control を使用して、UMS 電子メール ドライバの以下の設定を確認してください。

- MailAccessProtocol (大文字の IMAP または POP3)

- ReceiveFolder

- IncomingMailServer

- IncomingMailServerPort

- IncomingMailServerSSL

- IncomingMailServerSSL

- IncomingUserIDs

- IncomingUserPasswords

- ImapAuthPlainDisable

注意 : 任意の電子メール クライアントで IMAP または POP3 サーバへの接続にこれらの値を使用して、値を検証してください。

メール アクセス プロトコルが正しくありません。

Oracle Fusion Middleware Control を使用して、UMS 電子メール ドライバの以下の設定を確認してください。

- MailAccessProtocol (大文字の IMAP または POP3)

電子メール サーバで SSL が有効にされています。

Oracle Fusion Middleware Control を使用して、UMS 電子メール ドライバの以下の設定を確認してください。

- IncomingMailServerSS

受信フォルダ名が正しくありません。

Oracle Fusion Middleware Control を使用して、UMS 電子メール ドライバの以下の設定を確認してください。

- ReceiveFolder

注意 : 一部の電子メール サーバでは、値 INBOX に inbox または Inbox が予期される場合があります (つまり、大文字と小文字が区別されます)。使用する電子メール サーバに基づいて、適切な値を使用してください。

通知を受信するデフォルト以外の電子メール クライアントがコンフィグレーションされています。ユーザが承認のリンクをクリックすると、デフォルトのメール クライアントのページが開き、異なるメール サーバに電子メールが送信される場合があります。

アクション可能な通知を受信するデフォルトの電子メール クライアントをコンフィグレーションしてください。

SOA BPEL User Notification または Human Workflow の通知が正しい配信タイプ (電子メール、SMS など) に送信されますが、アドレスが間違っています。

BPEL User Notification または Human Workflow 通知の使用例で使用するため、自己プロビジョニングされたメッセージング チャネルが User Messaging Preferences でユーザによって作成されています。

注意 : User Messaging Preferences の UI では、エンド ユーザがさまざまな使用例で使用する独自のメッセージング チャネルを作成できますが、BPEL User Notification および Human Workflow ではこれらが使用されません。

BPEL User Notification または Human Workflow の使用例では、自己プロビジョニングされたメッセージング チャネルを使用しないでください (つまり、これらの使用例では、デフォルトのチャネルとして設定したり、メッセージ フィルタ内で使用することは避けてください)。BPEL User Notification および Human Workflow では、User Messaging Preferences を配信タイプの設定にのみ使用し、実際のアドレスは ID 管理システムのユーザ プロファイルから取得します。

注意 : ID 管理システムのユーザ プロファイルからのアドレスは、Business Email、Business Mobile、Business Phone、Instant Messaging などの事前定義されたチャネル名を使用することで、User Messaging Preferences を通じて使用できます。BPEL User Notification および Human Workflow の使用例では、これらの事前定義されたメッセージング チャネルを使用してください。

12 Oracle User Messaging Service のモニタ

この章では、Oracle Enterprise Manager Fusion Middleware Control を使用して Oracle User Messaging Service をモニタする方法について説明します。

この章には、以下のトピックがあります。

- 節 12.1「Oracle User Messaging Service のモニタ」

- 節 12.2「ログ ファイル」

- 節 12.3「メトリックと統計値」

12.1 Oracle User Messaging Service のモニタ

Oracle Enterprise Manager Fusion Middleware Control を使用して、Oracle User Messaging Service のログおよびメトリックをモニタできます。この機能にアクセスするには、以下の手順を実行します。

1. SOA ファームの [Enterprise Manager] ページに移動します。

図 12-1 SOA ファームの管理

「図 12-1 SOA ファームの管理」の説明

2. Fusion Middleware、SOA、User Messaging Service の順に選択します。

3. 任意のサーバまたはドライバを選択します。
ドライバを選択すると、ドライバの状態とパフォーマンスを示す簡単な統計値が表示されます。

サーバを選択すると、関連付けられたドライバのリストと、簡単な統計値が表示されます。ドライバの 1 つを選択して統計値を表示するか、[Configure Driver] アイコンをクリックしてドライバをコンフィグレーションできます。ドライバのコンフィグレーションの詳細については、第 11 章「Oracle User Messaging Service のコンフィグレーション」を参照してください。

図 12-2 [Configure Driver] アイコンの使用

「図 12-2 [Configure Driver] アイコンの使用」の説明

4. リスト内のアクションを実行するドライバを右クリックします。

図 12-3 実行可能なアクション

「図 12-3 実行可能なアクション」の説明

表 12-1 ドライバのアクション

選択内容

アクション

[Home]

ホーム ページに選択したドライバの簡単な統計値が表示されます。

[Control]

ドライバを起動または停止します。

[Logs]

選択したドライバのメッセージ ログを表示およびコンフィグレーションします。

[Performance Summary]

カスタマイズ可能なメトリック ページでパフォーマンスの統計値を表示します。このページでは、このドライバの統計値が表示されます。[Metric Palette] を使用してこのページをカスタマイズします。[Metric Palette] を使用すると、使用可能なすべてのメトリックから選択して、最も価値のある情報のみを表示することができます。

[Message Status]

送受信されたメッセージの配信ステータスを確認し、選択されたメッセージを再送信します。検索フィールドを追加したり、必要な演算子や検索値を設定することで、検索をフィルタ処理できます。異なる演算子や補数演算子、または Contains 演算子で使用するために、複数回追加できるフィールドもあります。

[Messaging Client Applications]

アンデプロイされたアプリケーションが、他のアプリケーションに対して有効にする必要のあるアクセス ポイントを保持し続けているような場合に、User Messaging Service に登録されているメッセージング クライアント アプリケーションの登録を手動で解除できます。

[Server Properties]

メッセージの格納方法と、メッセージ フィルタ作成用のビジネス条件をコンフィグレーションします。詳細については、第 11 章「Oracle User Messaging Service のコンフィグレーション」を参照してください。

[System MBean Browser]

[System MBean Browser] は System MBean およびそれらのコンフィグレーション設定を示します。

[General Information]

[General Information] は選択したドライバの名前、バージョン、Oracle ホーム、およびホストを表示します。

ns_geninfo.gif の説明

Oracle Enterprise Manager の詳細については、Oracle Enterprise Manager のドキュメントを参照してください。

12.1.1 メッセージ ステータスの使用

送受信されたメッセージの配信ステータスを確認し、選択されたメッセージを再送信することができます。メッセージ ステータスを確認するには、以下の手順を実行します。

1. ナビゲーション ツリーで、メッセージ ステータスを表示する UMS の対象を右クリックします。

2. [Message Status] を選択します。[Message Status] ページが表示されます。

3. [Search] をクリックすると、デフォルトの条件を使用してメッセージが検索されます。検索によって、メッセージのリストが返されます。

図 12-4 メッセージ ステータス

「図 12-4 メッセージ ステータス」の説明

検索フィールドを追加したり、必要な演算子や検索値を設定して、検索をカスタマイズできます。異なる演算子や補数演算子、または Contains 演算子で使用するために、複数回追加できるフィールドもあります。検索をカスタマイズするには、以下の手順を実行します。

1. [Add Fields] をクリックします。

2. 検索に使用するフィールドを選択します。

3. 演算子を選択し、必要に応じて変数を入力します。

4. [Search] をクリックします。カスタマイズした検索が完了し、結果が返されます。

図 12-5 カスタム検索

「図 12-5 カスタム検索」の説明

5. メッセージを再送信する場合は、リストでメッセージを選択し、[Resend] をクリックします。

12.1.2 メッセージ クライアント アプリケーションの登録解除

アプリケーションがアンデプロイされた後、他のアプリケーションに対して有効にする必要のあるアクセス ポイントを保持し続けている場合は、メッセージング クライアント アプリケーションの登録を手動で解除できます。メッセージング クライアント アプリケーションの登録を解除するには、以下の手順を実行します。

1. ナビゲーション ツリーで対象を右クリックし、[Messaging Client] を選択します。メッセージング クライアントのページが表示されます。

2. 登録解除するメッセージを選択します。

3. [De-register] をクリックします。

図 12-6 [Messaging Client Applications] ページ

「図 12-6 [Messaging Client Applications] ページ」の説明

選択項目の確認を求める確認ボックスが表示されます。

4. 選択項目を確認します。

12.1.3 [すべて] タブを使用したドライバのモニタ

[すべて] タブには、(存在しているすべてのドライバではなく) ドメイン内の正常に登録されているドライバのみが表示されます。

ドライバは、最初はコンフィグレーションされていないため、ユーザがコンフィグレーションするまで登録されません。すべてのドライバがタブに表示されるようにするには、SMPP、VoiceXML、および XMPP ドライバをコンフィグレーションします (使用を検討している場合)。コンフィグレーションが完了すると、ドライバがエンジンに登録され、[すべて] タブに表示されます。

12.2 ログ ファイル

ログ情報を表示するドライバを右クリックし、[Logs]、[View Log Files] を選択します。[Log Messages] ページが表示されます。

図 12-7 ログのクエリ

「図 12-7 ログのクエリ」の説明

このページで、ドライバに関するログ情報をクエリします。各フィールドおよびリストを使用して、クエリをカスタマイズします。検索条件を入力したら、[Log Files] をクリックします。[Log Files] ページが表示されます。

図 12-8 ログの検索結果

「図 12-8 ログの検索結果」の説明

ログ情報を表示するか、ログをダウンロードできます。

12.2.1 ロギングのコンフィグレーション

Enterprise Manager を使用して、ログ レベルをコンフィグレーションします。

図 12-9 ログ レベルのコンフィグレーション

「図 12-9 ログ レベルのコンフィグレーション」の説明

各ロガーの通知レベルを設定します。

図 12-10 通知レベルの選択

「図 12-10 通知レベルの選択」の説明

コンフィグレーション操作の結果、指定したとおりに通知が表示されます。

図 12-11 ログ ファイルの表示

「図 12-11 ログ ファイルの表示」の説明

図 12-12 エラー メッセージ

「図 12-12 エラー メッセージ」の説明

12.3 メトリックと統計値

アプリケーションのパフォーマンスはメトリックと統計値で示されます。ドライバの [Performance Summary] を選択すると、[Performance Summary] ページが表示されます。

図 12-13 UMS のメトリック

「図 12-13 UMS のメトリック」の説明

取得および表示できる多数のメトリックが用意されていますが、最も価値のある情報を特定して取得するには、[Metric Palette] を使用します。[Metric Palette] を表示するには、[Metric Palette] をクリックします。最も関心のあるメトリックを選択します。パレットのメトリックを選択または選択解除すると、メトリックの表示が自動的に更新されます。

図 12-14 [Metric Palette]

「図 12-14 [Metric Palette]」の説明

13 Oracle User Messaging Service の管理

この章では、Oracle User Messaging Service を管理する方法について説明します。

この章には、以下のトピックがあります。

- 節 13.1「ドライバのデプロイ」

- 節 13.2「ドライバのアンデプロイと登録解除」

13.1 ドライバのデプロイ

Oracle UMS をインストールする場合は、プリインストールされたドライバが含まれています (電子メール、XMPP、SMPP、および VoiceXML)。この中で、WebLogic Server にデプロイされるのは電子メール ドライバだけです。他のドライバをデプロイするには、WebLogic Server に対してそのドライバを対象指定します (WebLogic Administration Console を使用するか、または、Oracle Fusion Middleware Configuration Wizard を使用してドメインを作成または拡張する際にドライバを対象指定できます)。

Worklist と統合された UMS を利用する場合は、SOA Server に Worklist ドライバをデプロイする必要があります。この統合では複数の JEE アプリケーションと SOA 複合が必要になるため、この機能を 1 ステップで有効にする、特殊な拡張テンプレートを使用する必要があります。詳細については、「Worklist ドライバのインストール」を参照してください。

WebLogic Server Administration Console、Oracle Enterprise Manager、WLST コマンド、Oracle Fusion Middleware Configuration Wizard などを使用して、さまざまな方法でその他のドライバをデプロイできます。

注意 :
特定のドライバ EAR の複数のドライバ インスタンスをデプロイする場合は、$ORACLE_HOME/communications/plans で使用可能なカスタム デプロイメント プラン テンプレートを使用する必要があります。Oracle Enterprise Manager を使用してドライバをデプロイする手順については、「Oracle Enterprise Manager を使用したドライバのデプロイ」を参照してください。

13.1.1 WebLogic Server Administration Console の使用

WebLogic Server Administration Console を使用してドライバをデプロイします。

1. コンソールの [ドメイン構造] 領域で、[デプロイメント] をクリックします。デプロイメントのホーム ページが表示されます。

図 13-1 デプロイメント

「図 13-1 デプロイメント」の説明

2. [デプロイメント] の下で、[インストール] をクリックします。

図 13-2 インストール

「図 13-2 インストール」の説明

アプリケーション インストール アシスタントが表示されます。 このページで、デプロイする必要のあるアプリケーションを特定します。

3. ファイルへのパスを入力します。

図 13-3 アプリケーション インストール アシスタント

「図 13-3 アプリケーション インストール アシスタント」の説明

4. [次へ] をクリックします。対象指定のスタイルを選択するよう求められます。

図 13-4 対象指定スタイル

「図 13-4 対象指定スタイル」の説明

5. デフォルト (このデプロイメントをアプリケーションとしてインストールする) を使用します。概要ページが表示されます。

図 13-5 概要ページ

「図 13-5 概要ページ」の説明

6. 設定を受け入れます。 設定は変更できますが、この設定のまま使用することをお勧めします。[完了] をクリックします。確認ページが表示されます。

図 13-6 確認ページ

「図 13-6 確認ページ」の説明

7. デプロイメントを完了するには、変更をアクティブ化する必要があります。[変更のアクティブ化] をクリックします。

図 13-7 変更のアクティブ化

「図 13-7 変更のアクティブ化」の説明

最後の確認が表示されます。

図 13-8 最後の確認

「図 13-8 最後の確認」の説明

13.1.2 Oracle Enterprise Manager を使用したドライバのデプロイ

Oracle Enterprise Manager を使用してドライバをデプロイするには、以下の手順を実行します。

1. デプロイメント テンプレート (ORACLE_HOME/communications/plans など) を取得します。

2. 任意の場所 (同じディレクトリまたは他の任意のディレクトリ) にプランをコピーします。

3. プランを編集します。

DriverDeploymentName を、使用する任意の名前で置き換えます (名前のすべての箇所が置換されたことを確認してください)。

DriverShortName を任意の名前で置き換えます。

4. Oracle Enterprise Manager を起動します。

5. .ear ファイルの場所を入力します (図 13-9)。

6. デプロイメント プランの場所を入力します (図 13-9)。

図 13-9 Oracle Enterprise Manager を使用した UMS ドライバのデプロイ

「図 13-9 Oracle Enterprise Manager を使用した UMS ドライバのデプロイ」の説明

[Select Target] 画面が表示されます。

図 13-10 [Select Target] 画面

「図 13-10 [Select Target] 画面」の説明

7. SOA の対象を選択します。

8. [Application Attributes] 画面にアプリケーション名を入力します。 アプリケーション名は、(上の手順 3 の) デプロイメント プランで指定した DriverDeploymentName で使用している文字列と正確に一致する必要があります。 一致しない場合は、デプロイメントとアクティブ化が失敗します。[Deployment Setting] 画面が表示されます。

図 13-11 [Deployment Settings] 画面

「図 13-11 [Deployment Settings] 画面」の説明

9. [Deploy] をクリックします。 [Deployment Completed] 画面が表示されます。

図 13-12 [Deployment Completed] 画面

「図 13-12 [Deployment Completed] 画面」の説明

10. 結果 (デプロイされたドライバ) を確認するには、SOA Server を起動します。

13.1.3 WLST コマンドの使用

WLST コマンド deployUserMessagingDriver を使用して、ドライバをデプロイできます。

13.1.3.1 deployUserMessagingDriver

コマンド カテゴリ : UMS

WLST での使用 : オンライン

13.1.3.1.1 説明

deployUserMessagingDriver は、ユーザ メッセージング ドライバの追加のインスタンスをデプロイするために使用されます。基本のドライバ タイプ (たとえば、email、xmpp、voicexml など) と、新しいドライバ デプロイメントの短い名前を指定します。指定されたアプリケーション名の前に文字列 usermessagingdriver- が付加されます。deploy コマンドの任意の有効なパラメータを指定できます。これらは、ドライバのデプロイ時に渡されます。

13.1.3.1.2 構文

deployUserMessagingDriver(baseDriver, appName, [targets], [stageMode], [options])

引数

定義

baseDriver

基本のメッセージング ドライバ タイプを指定します。
「email」、「proxy」、「smpp」、「voicexml」、「xmpp」などの既知のドライバ タイプを指定する必要があります。

appName

新しいデプロイメントを表す短い名前。指定した値の前に文字列 usermessagingdriver- が付加されます。

targets
stageMode

options

省略可能。deploy コマンドの有効な引数を追加で指定できます。これらは、新しいドライバのデプロイ時に渡されます。

13.1.3.1.3 サンプル

電子メール ドライバの 2 番目のインスタンスを myEmail という名前でデプロイします。

wls:/base_domain/serverConfig> deployUserMessagingDriver(baseDriver='email', appName='myEmail')

デプロイメント対象を指定して、電子メール ドライバの 2 番目のインスタンスをデプロイします。

wls:/base_domain/serverConfig> deployUserMessagingDriver(baseDriver='email', appName='email2', targets='server1,server2')

13.1.4 Oracle Fusion Middleware Configuration Wizard の使用

SMPP、XMPP、および VoiceXML ドライバをインストールするには、$ORACLE_HOME/common/templates/applications/oracle.ums.drivers_template_11.1.1.jar にある拡張テンプレートを使用してドメインを拡張します。Oracle Fusion Middleware Configuration Wizard を使用してドメインを拡張するには、以下の手順を実行します。

1. Oracle Fusion Middleware Configuration Wizard ($ORACLE_HOME/common/bin/config.sh または %ORACLE_HOME%\common\bin\config.cmd) を起動します。

2. [既存の WebLogic ドメインの拡張] オプションを選択します。

3. UMS が含まれている目的のドメイン ディレクトリを選択します。

4. [Extend my domain using an existing extension template] オプションを選択します。

5. [参照] をクリックし、$ORACLE_HOME/common/templates/applications に移動します。

6. oracle.ums.drivers_template_11.1.1.jar を選択します。

7. Oracle Fusion Middleware Configuration Wizard の残りの手順を完了します。また、目的の WebLogic サーバまたはクラスタ、あるいはその両方に、必要なドライバを忘れずに対象指定してください。

8. 該当する WebLogic サーバを再起動します。

13.2 ドライバのアンデプロイと登録解除

メッセージング ドライバは標準の JEE アプリケーションであるため、Admin Console や WLST などの標準の Oracle WebLogic ツールを使用して、Oracle WebLogic Server からアンデプロイできます。

ただし、UMS サーバでは永続ストア (データベース) に登録されているメッセージング ドライバを記録しているため、UMS サーバで公開されたランタイム MBean を使用して、登録を解除する個別の手順を実行する必要があります。Oracle Enterprise Manager からこれを行うには、以下の手順を実行します。

1. UMS サーバが稼動していることを確認します。

2. Oracle Enterprise Manager で、ドメイン内の任意の対象の usermessagingserver を選択します。

3. 対象のメニューから、[System MBean Browser] を選択します。

4. [System MBean Browser] で、usermessagingserver の ComponentAdministration MBean を探します。
[com.oracle.sdp.messaging｜サーバ (サーバ : soa_server1 など)｜SDPMessagingRuntime｜ComponentAdministration] の順にフォルダを展開します。

5. 操作 listDriverInstances を起動します。

1. [Operations] タブをクリックします。

2. 操作 [listDriverInstances] をクリックします。

3. [Invoke] をクリックします。

4. 登録解除するドライバの名前を識別し、コピーします (例 : /Farm_soa_bam_domain/soa_bam_domain/soa_server1/usermessagingdriver-email:oracle_sdpmessagingdriver_email#Email-Driver)。

図 13-13 ドライバ インスタンスのリスト

「図 13-13 ドライバ インスタンスのリスト」の説明

6. [Return] をクリックします。.

7. 目的のドライバ名で、操作 unregisterDriverInstance を起動します。

1. 操作 [unregisterDriverInstance] をクリックします。

2. Value フィールドにドライバ名を貼り付けます (例 : /Farm_soa_bam_domain/soa_bam_domain/soa_server1/usermessagingdriver-email:oracle_sdpmessagingdriver_email#Email-Driver)。

3. [Invoke] をクリックします。

図 13-14 ドライバ インスタンスの登録解除

「図 13-14 ドライバ インスタンスの登録解除」の説明

8. 操作が成功したことを確認ダイアログで確認します。

これによって、指定したドライバの UMS サーバでの登録が解除され、以降のメッセージ配信で使用されなくなります。

第 V 部

SIP インフラストラクチャ アプリケーションの信任

以下の章があります。

- 第 15 章「Oracle WebLogic Communication Services 基本プラットフォーム トポロジ」

14 SIP インフラストラクチャ アプリケーションのコンフィグレーション

この章では、Proxy Registrar と STUN サービスについて説明します。 以下のトピックがあります。

- 節 14.1「Proxy Registrar」

- 節 14.2「STUN サービス」

14.1 Proxy Registrar

Proxy Registrar は、RFC 3261 に規定されているプロキシおよびレジストラ機能を実装するユーザ エージェント サーバ (UAS) です。 この SIP エンティティは、メッセージのルータです。 Proxy Registrar のレジストラ機能では、ユーザ エージェント クライアントからの REGISTER リクエストが処理され、Location Service を使用して、ユーザのレコード アドレス (AOR) と、CONTACT フィールドにあるユーザの SIP または SIPS URI との間のバインディング (関連付け) が格納されます。 AOR へのリクエストが受信されると、プロキシ機能によって、Location Service のルックアップを通じてマップされた URI が特定され、このルックアップで取得されたロケーション情報を使用してリクエストがプロキシされます。 表 14-1 に、Proxy Registrar の属性を示します。

表 14-1 Proxy Registrar の属性

属性

説明

CurrentRegDevices

現在登録されているデバイスの数を示す、読み取り専用の属性です。

DefaultExpires

クライアントで優先的な値が指定されなかった場合の、REGISTER リクエストの有効期限の値を設定します。 この属性のデフォルト値は 3600 秒です。

MaxExpires

サーバが使用できる REGISTER リクエストの有効期限の最大値を設定します。 クライアントは REGISTER リクエストで任意の有効期限の値を要求できますが、サーバが有効期限として使用する最大期間を設定できます。 クライアントが要求した期間が MaxEpires に設定された値よりも長い場合、サーバはその特定の REGISTER リクエストの有効期限を MaxExpires の値に設定します。

この属性のデフォルト値は 7200 秒です。

MinExpires

サーバが使用できる REGISTER リクエストの有効期限の最小値を設定します。クライアントは任意の有効期限を要求できますが、REGISTER リクエストの有効期限として非常に低い値を指定することもできます。 これらの低い値では、クライアントが頻繁に登録情報を更新する必要があるため、ネットワーク上のトラフィックが生じます。 クライアントが要求した値がこの最小有効期限に満たない場合、サーバは REGISTER リクエストを受け入れず、RFC 3261 の 423 (間隔が短すぎる) エラー応答で応答します。 この応答メッセージでは、MinExpires 属性で設定された、許可されている最小有効期限が指定されます。 サーバは有効期限を短縮できますが、延長はできません。

この属性のデフォルト値は 60 秒です。

SipRegAllowThirdParty

Proxy Registrar でサードパーティの登録を許可するかどうかを指定します。 サードパーティの登録の場合、リクエストを発行するエンティティ (From ヘッダ内) は、提供された Contact 情報が適用される、登録されたエンティティ (To ヘッダ内) とは異なります。 true に設定すると、Proxy Registrar でサードパーティの登録が許可されます。 false (デフォルト値) に設定すると、サードパーティの登録は拒否されます (リクエスト側では 403 Forbidden ステータス コードが受信されます)。 これは、常に false に設定された読み取り専用の属性です。

SipRegMaxUsers

Proxy Registrar でサポートされる最大ユーザ数を指定する、読み取り専用の属性です。

14.2 STUN サービス

OWLCS STUN サービスは、STUN (Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)) を実装します。 RFC 3489 に規定されているとおり、STUN によって、NAT 背後の STUN クライアント (つまり、ルータ背後のクライアント) は NAT の存在と NAT の種類を検出し、NAT が割り当てる (IP アドレスを含む) アドレス バインディングを認識できます。

STUN はクライアントとサーバ間のプロトコルであり、STUN クライアントがリクエスト (バインディング リクエスト) をサーバに送信すると、サーバから応答が返されます。 OWLCS ではクライアントからのバインディング リクエストの受信がサポートされます。これらのリクエストは UDP を介して送信され、NAT の存在の検出と、パブリック IP アドレスおよび生成されるポート マッピングの検出の両方に使用されます。 STUN クライアントがバインディング リクエストを STUN サーバに送信すると、STUN サーバはリクエストのソース IP アドレスとポートを調べて、これらがコピーされた応答を再びクライアントに送信します。 STUN クライアントがバインディング レスポンスを受信すると、パケット内の IP アドレスおよびポートと、STUN サーバへのバインディング リクエストの送信時にバインドされていたローカル IP アドレスおよびポートが比較されます。

STUN サービス MBean の属性 (表 14-2 を参照) を使用して、STUN サーバのプライマリおよびセカンダリの IP アドレスとポートを設定できます。これらは、STUN サーバがクライアントからのバインディング リクエストの受信に使用する、RFC 3489 で規定されているアドレス-ポートの 4 つの組み合わせを形成します。 RFC 3489 による組み合わせは、以下のとおりです。

- A1, P1 -- プライマリ アドレスとプライマリ ポート

- A2, P1 -- セカンダリ アドレスとプライマリ ポート

- A1, P2 -- プライマリ アドレスとセカンダリ ポート

- A2, P2 -- セカンダリ アドレスとセカンダリ ポート

通常、STUN サーバのプライマリ ポート (P1) は UDP ポート 3478 に設定されます。 STUN サーバでは、バインディング レスポンスに含まれている CHANGED-ADDRESS 属性のセカンダリ アドレスとセカンダリ ポートの値 (A2, P2) が使用されます。

表 14-2 STUN サービス MBean の属性

属性

値

Autostart

OWLCS の起動時に STUN サーバを自動的に起動するには、true に設定します。

PrimaryAddress

着信バインディング リクエストをリスンするプライマリ STUN アドレス。 デフォルト値は 127.0.0.1 です。

PrimaryPort

着信バインディング リクエストをリスンするプライマリ STUN ポート。 値は UDP ポート 3478 です。これは RFC 3489 で規定されているデフォルトの STUN ポートです。

SecondaryAddress

着信バインディング リクエストをリスンするセカンダリ STUN アドレス。 PrimaryAddress と同じ値にすることはできません。

SecondaryPort

着信バインディング リクエストをリスンするセカンダリ STUN ポート。 デフォルト値は UDP ポート 3479 です。

第 VI 部

Oracle WebLogic Communication Services のデプロイ

以下の章があります。

- 第 15 章「Oracle WebLogic Communication Services 基本プラットフォーム トポロジ」

- 第 16 章「Communication Services のデプロイメント トポロジ」

- 第 17 章「デプロイ済み SIP アプリケーションのアップグレード」

- 第 18 章「Parlay X Web Services のアーキテクチャ」

15 Oracle WebLogic Communication Services 基本プラットフォーム トポロジ

以下の節では、Oracle WebLogic Communication Services アーキテクチャの概要とデプロイメント トポロジについて説明します。

- 節 15.1「Oracle WebLogic Communication Services 基本プラットフォームの目的」

- 節 15.2「ロード バランサ」

- 節 15.3「エンジン層」

- 節 15.4「SIP データ層」

- 節 15.5「地理的に冗長なインストール」

- 節 15.6「ハードウェア コンフィグレーションの例」

- 節 15.7「他のコンフィグレーション」

15.1 Oracle WebLogic Communication Services 基本プラットフォームの目的

Oracle WebLogic Communication Services は、SIP アプリケーションのデプロイを目的とした、高いスケーラビリティと可用性を備えた高性能サーバとしてデザインされています。OWLCS は、JSR 289 準拠の任意の SIP アプリケーションのデプロイに使用されます。OWLCS のすべてのサービスでサポートされるトポロジの詳細については、第 16 章「Communication Services のデプロイメント トポロジ」を参照してください。

Oracle WebLogic Communication Services のアーキテクチャは、管理が容易で、利用可能なハードウェアに簡単に対応できます。基本的なアーキテクチャの構成要素は以下のとおりです。

- 節 15.2「ロード バランサ」

- 節 15.3「エンジン層」

- 節 15.4「SIP データ層」

図 15-1 は、基本的な Oracle WebLogic Communication Services インストールの構成要素を示します。以下の節で、アーキテクチャの各構成要素について詳しく説明します。

図 15-1 Oracle WebLogic Communication Services アーキテクチャ

「図 15-1 Oracle WebLogic Communication Services アーキテクチャ」の説明

15.2 ロード バランサ

ロード バランサは、Oracle WebLogic Communication Services 製品の一部として用意されているものではありませんが、プロダクション インストールにおいては、1 つまたは複数のロード バランサが構成要素として不可欠です。ロード バランサの主な役割は、単一のパブリック アドレスで受け取った SIP リクエストを、Oracle WebLogic Communication Services エンジン層の利用可能なサーバに分散させることです。リクエストの分散によって、Oracle WebLogic Communication Services エンジンは最大限に活用されます。

ロード バランサの多くには、コンフィグレーション可能なポリシーがあり、各マシンのキャパシティと可用性に応じて、またはインストールで必要なその他のロード ポリシーに応じて、クライアント リクエストを分散できるようになっています。ロード バランサの中には、SIP ネットワーク トラフィックを管理するための追加の機能を備えているものがあります。たとえば、SIP メッセージのヘッダに含まれている送信元の IP アドレスやポート番号などのフィールドに基づく、ルーティング ポリシーのサポートなどです。ロード バランサ製品の多くは、テレフォニ ネットワーク向けのフォールト トレランス機能も備えており、特定の呼への SIP リクエストを、その呼が開始された同じエンジン層サーバに常に転送するようにコンフィグレーションすることができます。

Oracle WebLogic Communication Services インストールでは、ロード バランサは、個々のサーバ (Oracle WebLogic Communication Services ソフトウェアまたはハードウェア) をアップグレードしたり、既存の SIP クライアントに影響を及ぼさずにアプリケーションをアップグレードしたりといった保守作業を実行するうえでも不可欠です。管理者は、ロード バランサ ポリシーを変更して、1 つまたは複数のサーバへのクライアント トラフィックを他へ移動したうえで、使用していないサーバ インスタンスに対し、必要なアップグレードを実行します。その後で、アップグレードが済んだサーバでクライアント トラフィックが元どおりに処理されるよう、ロード バランサ ポリシーを再度変更します。

Oracle では、Oracle WebLogic Communication Services エンジン層でロード バランサを設定し、基本的な負荷分散を行うための詳細な情報を提供しています。Oracle WebLogic Communication Services と共に使用するロード バランサのコンフィグレーションについては、節 4.2「ロード バランサのアドレスのコンフィグレーション」を参照してください。

15.3 エンジン層

エンジン層は、SIP クライアントに対して機能を提供する SIP サーブレットおよびその他のアプリケーションをホストする Oracle WebLogic Communication Services インスタンスのクラスタです。エンジン層は、SIP ダイアログの状態について、永続的情報や一時的情報をを格納しないステートレス サーバのクラスタです。その代わりに、SIP ダイアログに関するすべてのステートフル情報は、SIP データ層 (節 15.4) に格納されて取得され、SIP セッション データのレプリケーションおよびフェイルオーバ サービスも提供されます。

エンジン層サーバは SIP データ層で管理するセッション データの一部をキャッシュすることができます。キャッシングは SIP 対応ロード バランサを使用するコンフィグレーションに非常に便利です。節 6.7「エンジン層での SIP データのキャッシング」を参照してください。

エンジン層の主な役割は、SIP クライアントに対し、最大限のスループットを実現し、応答時間を短縮することです。システムが処理する呼の数や平均時間が増したときには、エンジン層にサーバ インスタンスを簡単に追加して、負荷の増加に対応できます。

エンジン層は、複数の Oracle WebLogic Communication Services インスタンスで構成されますが、単一の論理エンティティとして扱います。SIP サーブレットのデプロイは、クラスタ自体を対象とすることにより、すべてのサーバ インスタンスに対して一律に行われますが、ロード バランサは、SIP クライアントとエンジン層のサーバとの間のアフィニティを維持する必要はありません。

注意 :
Oracle WebLogic Communication Services の起動スクリプトでは、パフォーマンスを左右する多数の JVM パラメータにデフォルト値が使用されています。たとえば、JVM のガベージ コレクションやヒープ サイズのパラメータが省略されていることや、評価や開発以外の目的には適切でない値を使用していることがあります。プロダクション システムでは、十分なパフォーマンスを実現するために、さまざまなヒープ サイズやガベージ コレクションの設定でアプリケーションのプロファイリングを厳密に行う必要があります。プロダクション ドメインで JVM のパフォーマンスを最大限に引き出す方法については、節 8.8「プロダクション デプロイメントにおける JVM ガベージ コレクションのチューニング」を参照してください。
エンジン層では SIP データ層サーバを利用して呼状態データを取得するので、エンジン層と SIP データ層のマシンで 2 枚のギガビット イーサネット ネットワーク インタフェース カード (NIC) を使用してネットワーク接続を二重化することをお勧めします。

15.4 SIP データ層

SIP データ層は、SIP サーブレットのセッション ステート データを格納および取得するための、高いパフォーマンスと可用性を備えたインメモリ データベースを提供する Oracle WebLogic Communication Services インスタンスのクラスタです。SIP データ層の役割は次のとおりです。

- Oracle WebLogic Communication Services エンジン層の SIP アプリケーションが必要とするセッション データを格納する、信頼性のある高性能ストレージを実現します。

- 同時呼のセッション ステートに対応できるよう、ハードウェア リソースとソフトウェア リソースの規模を管理者が必要に応じて簡単に変更できるようにします。

SIP データ層の中では、セッション データは 1 つまたは複数の「パーティション」で管理され、各パーティションは同時呼状態の特定の部分を処理します。たとえば、2 つのパーティションを使用するシステムの場合、1 つ目のパーティションでは、同時呼状態の半分 (セッション A ～ M) を処理し、2 つ目のパーティションでは、同時呼状態の残りの半分 (セッション N ～ Z) を処理します。パーティションが 3 つの場合には、各パーティションは呼状態全体の 3 分の 1 ずつを処理します。パーティションが 4 つ以上の場合も同様です。大量の同時呼を管理するときには、必要に応じてパーティションを追加できます。簡単なハッシング アルゴリズムは、1 つの SIP データ層パーティションのみに各呼状態がユニークに割り当てられているか確認するために使用します。

各パーティションには複数のサーバを追加でき、パーティション内の他のサーバで障害が発生した場合の冗長性とフェイルオーバを実現できます。同じパーティションに複数のサーバが属する場合、それらのサーバは「レプリカ」と呼ばれます。各サーバはパーティションの呼状態の複製コピーを処理するからです。たとえば、2 パーティション システムの最初のパーティションに 2 つのサーバがあると、各サーバは A ～ M の呼状態のレプリカを管理します。パーティション内の 1 つまたは複数のサーバが起動しない場合やネットワークから切断されている場合、任意の使用可能なレプリカが呼状態のデータを自動的にエンジン層に提供します。2 つのレベルの冗長性を強化するため、SIP データ層には最大 3 つのレプリカを含めることができます。

可用性を高めるための SIP データ層のコンフィグレーションの詳細については、第 6 章「SIP データ層のパーティションとレプリカのコンフィグレーション」を参照してください。

注意 :
エンジン層では SIP データ層サーバを利用して呼状態データを取得するので、エンジン層と SIP データ層のマシンで 2 枚のネットワーク インタフェース カード (NIC) を使用してネットワーク接続を二重化することをお勧めします。

15.4.1 呼状態データの記述と取得の例

初期の SIP メッセージを受信した場合は、Oracle WebLogic Communication Services は、メッセージをエンジン層でデプロイされた適当な SIP サーブレットに送信するためにサーブレット マッピング ルールを使用します。エンジン層は、SIP ダイアログに関するステートフルな情報を保持しません。その代わりに、SIP トランザクション境界でエンジン層に呼状態を保存します。ハッシング アルゴリズムは、呼状態データを格納する 1 つの SIP データ層パーティションを選択するために呼状態に適用します。次に、エンジン層サーバは、そのパーティション内にある各レプリカの呼状態を「書き込み」、呼状態をロックします。たとえば、SIP データ層は、各パーティション内の 2 つのサーバを使用するようにコンフィグレーションした場合、エンジン層はパーティション内の両方のレプリカへの接続を開き、各レプリカの呼状態を書き込み、ロックします。

デフォルトのコンフィグレーションでは、レプリカはメモリにのみ (利用可能な RAM) 呼状態情報を保持します。呼状態データを RDBMS への長期的な格納に対してコンフィグレーションすることもでき、地理的冗長性を実現するため、オフサイトの Oracle WebLogic Communication Services インストールに対して永続化することもできます。

SIP ダイアログに対応して以降の SIP メッセージが生成された場合は、エンジン層は SIP データ層から呼状態データを取得する必要があります。ハッシング アルゴリズムを再度適用して、呼状態データを格納するパーティションを決定します。次に、エンジン層は、パーティション内の各レプリカのロックを解除し、呼状態データを取得するように求めます。そうすると、エンジン層上のサーブレットは呼状態データを更新することができます。

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

Oracle WebLogic Communication Services では、長期間維持する呼状態データを Oracle RDBMS に格納して RAM を節約することができます。呼ダイアログの確立後、SIP データ層では呼状態のデータを RDBMS に永続化し、呼状態を変更または削除するために、必要に応じて永続化された呼状態データを取得または削除します。節 6.4「長期間維持する呼状態データの RDBMS への格納」を参照してください。

15.5 地理的に冗長なインストール

複数の地域データ センターを持ち、万一現地サイトに壊滅的な障害が発生した場合も継続的に稼動を行う必要があるといった顧客のために、Oracle WebLogic Communication Services は地理的に冗長なコンフィグレーションでインストールすることができます。地理的に冗長なコンフィグレーションは、複数の Oracle WebLogic Communication Services インストール （エンジンおよび SIP データ層クラスタ） を有効にし、インストール間の呼状態トランザクションをレプリケートします。特定のサイトへのインストールが致命的な障害に陥った場合は、管理者は呼損を最少限に留めるため、すべてのネットワーク トラフィックをレプリケートされたセカンダリ サイトにリダイレクトすることができます。節 6.6「地理的に冗長な SIP データ層の使用」を参照してください。

15.6 ハードウェア コンフィグレーションの例

Oracle WebLogic Communication Services のアーキテクチャは柔軟であるため、高いスループットや高可用性を実現できるように、エンジン層および SIP データ層をさまざまな方法でコンフィグレーションできます。

15.7 他のコンフィグレーション

Oracle WebLogic Communication Services の要件によっては、エンジン層と SIP データ層に複数サーバを配置してパフォーマンスと信頼性を高めることが必ずしも必要でないこともあります。たとえば、開発用マシンの場合には、複数サーバのクラスタにではなく単一のサーバにアプリケーションをデプロイしてテストする方が通常は好都合です。

Oracle WebLogic Communication Services では、呼状態のレプリケーションが不要な場合には、エンジン層と SIP データ層のサービスを単一のサーバ インスタンスに組み合わせることができます。こうした組み合わせ層コンフィグレーションでは、SIP サーブレット コンテナの機能と、サーバがホストするアプリケーション向けの呼状態処理の機能を、1 つの Oracle WebLogic Communication Services インスタンスが兼任します。組み合わせ層コンフィグレーションは、開発やテストの目的で使用するのが一般的ですが、呼状態データのレプリケーションが必要ない場合には、プロダクション環境でも使用できます。図 15-2 には、プロダクション環境における複数の組み合わせ層サーバのデプロイメント例を示します。

図 15-2 SIP 対応ロード バランサを使用した単一サーバ コンフィグレーション

「図 15-2 SIP 対応ロード バランサを使用した単一サーバ コンフィグレーション」の説明

組み合わせ層サーバ デプロイメントでは、各サーバは、自らがホストするアプリケーションの呼状態のみを処理します。そのため、ロード バランサは完全に「SIP 対応」であることが必要です。つまり、ロード バランサは、同じ呼に対する複数のリクエストを、同一の Oracle WebLogic Communication Services インスタンスに対してアクティブにルーティングする必要があります。同じ呼のリクエストが同一のサーバに対応付けられない場合は、呼状態を取得できません。また、図 15-2 に示すコンフィグレーションにおいて Oracle WebLogic Communication Services インスタンスで障害が発生した場合は、そのサーバによって処理されたすべての呼が失われるという点にも留意してください。

16 Communication Services のデプロイメント トポロジ

この章の以下の節では、OWLCS のデプロイメント トポロジについて説明します。

- 節 16.1「用語」

- 節 16.2「OWLCS のデプロイメント トポロジ」

- 節 16.3「Oracle WebLogic Communication Services のエンタープライズ デプロイメント トポロジ」

16.1 用語

この章では、以下の用語を使用します。

- 管理サーバ -- ドメインのすべてのリソースをコンフィグレーションおよび管理するドメイン内の特殊なサーバ インスタンス。ドメインには管理サーバが 1 つのみ含まれます。

- ドメイン -- 論理的に関連付けられたサーバ リソースのグループ。

- 高可用性 (HA) -- 妥当とされる長期間に渡って、運用状態が連続的に維持されるシステムまたはコンポーネントを指します。

- JVM -- Java 仮想マシン。

- 管理対象サーバ -- リソースがデプロイされているドメイン内のサーバ インスタンス。ドメイン内には 1 つまたは複数の管理対象サーバが存在できます。

- ノード -- 物理マシン。

- OWLCS クライアント -- OWLCS サーバに接続し、プレゼンス、インスタント メッセージング (IM)、VoIP、Presence Web Services、Messaging Web Service などの機能を使用できるクライアント アプリケーション。たとえば、Oracle Communicator などです。

16.2 OWLCS のデプロイメント トポロジ

OWLCS では、単一ノードおよび複数ノードのデプロイメント トポロジがサポートされています。

- オールインワン管理対象サーバ -- 物理マシン上のドメイン内の管理対象サーバに、すべての OWLCS コンポーネントがデプロイされます。OWLCS コンポーネントは、同じドメインにインストールされた管理サーバを使用してコンフィグレーションおよび管理されます。

図 16-1 オールインワン管理対象サーバ

「図 16-1 オールインワン管理対象サーバ」の説明

詳細については、節 16.2.1「単一ノード トポロジ」を参照してください。

- オールインワン管理サーバ -- 物理マシン上のドメイン内の管理サーバに、すべての OWLCS コンポーネントがデプロイされます。管理対象サーバはありません。OWLCS コンポーネントは、同じ管理サーバを使用してコンフィグレーションおよび管理されます。

図 16-2 オールインワン管理サーバ

「図 16-2 オールインワン管理サーバ」の説明

詳細については、節 16.2.1「単一ノード トポロジ」を参照してください。

- エンタープライズ デプロイメント -- OWLCS のエンタープライズ デプロイメントで推奨される最小の HA トポロジです。OWLCS コンポーネントは、SIP インフラストラクチャ、サービスおよびプレゼンス コンポーネントに分離されます。各コンポーネント グループは、2 つの異なるマシン上の固有のドメイン内にデプロイされます。

図 16-3 エンタープライズ デプロイメント

「図 16-3 エンタープライズ デプロイメント」の説明

節 16.3.1「OWLCS エンタープライズ デプロイメント トポロジの概要」を参照してください。

16.2.1 単一ノード トポロジ

オールインワン管理サーバおよびオールインワン管理対象サーバの 2 つのトポロジは、すぐに使用可能な操作性を提供することを目的としています。プレゼンス、インスタント メッセージング、Voice-Over-IP、Third Party Calling、Presence Web Service、および Messaging Web Service を OWLCS クライアントで使用できます。これらのトポロジはテストおよび評価環境での使用が推奨され、プロダクション環境での使用は推奨されません。高可用性のサポートは含まれていません。

オールインワン管理サーバ トポロジでは、唯一のサーバ (管理サーバ) が単一の JVM で実行されます。オールインワン管理対象サーバ トポロジでは、管理対象サーバがある JVM で実行され、管理サーバが別の JVM で実行されます。

16.3 Oracle WebLogic Communication Services のエンタープライズ デプロイメント トポロジ

この節では、Oracle WebLogic Communication Services (OWLCS) の高可用性トポロジであるエンタープライズ デプロイメントについて説明します。以下の節が含まれています。

- 節 16.3.1「OWLCS エンタープライズ デプロイメント トポロジの概要」

- 節 16.3.2「地理的な冗長性」

- 節 16.3.3「フェイルオーバ」

16.3.1 OWLCS エンタープライズ デプロイメント トポロジの概要

OWLCS では複数ノードのデプロイメント トポロジがサポートされています。「SIP コンテナ クラスタ」は、アプリケーションに関連する状態を共有する一連の SIP コンテナ インスタンスとして定義されます。クラスタは、それぞれが 1 つの OWLCS インスタンスを実行する複数のノードで構成されます。

高可用性の OWLCS クラスタでは、以下の機能が提供されます。

- SIP アプリケーション セッションに含まれるオブジェクトと値のレプリケーション

- データベースによってバックアップされるロケーション サービス データ

- OWLCS SIP ノード間での着信リクエストのロード バランシング

- オーバーロード発生時にサーバを誤動作から保護し、適切に処理できないトラフィックを拒否するオーバーロード保護

- クラスタ内のアプリケーション間の透過的なフェイルオーバ。アプリケーションのあるインスタンスに障害が発生した場合、インスタンスは応答しなくなり、セッションはクラスタ内の別のノード上の別のアプリケーション インスタンスにフェイルオーバできます。

注意 :
スケーラブルなプレゼンス デプロイメントとしての OWLCS の詳細については、付録 G「スケーラブルな Presence デプロイメントのデプロイ」を参照してください。

注意 :
OWLCS エンタープライズ デプロイメント トポロジのインストールおよびコンフィグレーションについては、『Oracle WebLogic Communication Services インストール ガイド』を参照してください。

16.3.1.1 実行時の手順

Oracle WebLogic Communication Services の起動スクリプトでは、パフォーマンスを左右する多数の JVM パラメータにデフォルト値が使用されています。たとえば、JVM のガベージ コレクションやヒープ サイズのパラメータが省略されていることや、評価や開発以外の目的には適切でない値を使用していることがあります。プロダクション システムでは、十分なパフォーマンスを実現するために、さまざまなヒープ サイズやガベージ コレクションの設定でアプリケーションのプロファイリングを厳密に行う必要があります。プロダクション ドメインで JVM パフォーマンスを最大化するための推奨事項については、『Oracle WebLogic Communication Services 管理ガイド』を参照してください。

通常、Oracle WebLogic Communication Services ドメインは多数のエンジンおよびサーバで構成されており、異なる種類のサーバ間に依存関係があります。ドメインを起動するときは、一般に次の手順に従う必要があります。

1. ドメインの管理サーバを起動します。初期コンフィグレーションを提供するため、管理サーバを起動します。管理サーバは、各管理対象サーバの起動/停止のステータスをモニタする目的にも使用します。通常、管理サーバの起動には Configuration Wizard でインストールされた startWebLogic.sh/cmd スクリプトを使用するか、またはカスタムの起動スクリプトを使用します。

2. 管理対象サーバを起動します。次に、startManagedWebLogic.sh/cmd スクリプトを使用するか、カスタムの起動スクリプトを使用して、管理対象サーバを起動できます。

16.3.1.2 リクエスト フロー

リクエスト フローは JSR 289 に規定されています。 この仕様は SIPServlet 仕様に対する拡張です。

JSR 289 の詳細については、http://www.oracle.com/technology/tech/java/standards/jsr289/index.html を参照してください。

16.3.1.3 クライアントの接続

Oracle WebLogic Communication Services の各インスタンスのデフォルトの HTTP ネットワーク コンフィグレーションは、各サーバの「リスン アドレス」および「リスン ポート」の設定に基づいて決定されます。 ただし、Oracle WebLogic Communication Services では HTTP 上の SIP プロトコルはサポートされていません。SIP プロトコルは、UDP および TCP 転送プロトコル上でサポートされています。また、転送プロトコルとして TLS を使用する SIPS もサポートされています。

UDP、TCP、または TLS による転送を有効にするには、Oracle WebLogic Communication Services の各インスタンスに対して 1 つまたは複数の「ネットワーク チャネル」をコンフィグレーションします。ネットワーク チャネルは、そのサーバ インスタンスに対する特定のネットワーク接続の属性を定義するコンフィグレーション可能な WebLogic Server リソースです。基本的なチャネルの属性は次のとおりです。

- 接続でサポートされているプロトコル

- 接続のリスン アドレス (DNS 名または IP アドレス)

- 接続で使用されるポート番号

- 発信 UDP パケットで使用されるポート番号 (省略可能)

- チャネルを発信接続に使用する場合に SIP ヘッダに埋め込まれるパブリック リスン アドレス (ロード バランサのアドレス)

Oracle WebLogic Communication Services の 1 つのインスタンスに複数のチャネルを割り当てて、複数のプロトコルをサポートすることや、マルチホームのサーバ ハードウェアに搭載されている複数のインタフェースを利用することができます。同一のチャネルを複数のサーバ インスタンスに割り当てることはできません。

SIP プロトコル用の新しいネットワーク チャネルをコンフィグレーションすると、UDP および TCP 転送プロトコルの両方が指定されたポートで有効です。UDP または TCP のどちらか一方の転送プロトコルのみを使用する SIP チャネルを作成することはできません。SIPS プロトコル用のネットワーク チャネルをコンフィグレーションすると、そのチャネルの接続では、転送プロトコルとして TLS が使用されます。

新しい SIP Server ドメインをコンフィグレーションする場合は、通常、システム内のエンジン層の各サーバとの通信に使用する複数の SIP チャネルを作成する必要があります。エンジン層のサーバは、レプリカ用にコンフィグレーションされたリスン アドレス属性を使用して、SIP 状態層のレプリカと通信できます。ただし、レプリカ間で相互に通信するには、レプリカで一意なリスン アドレスを使用する必要があります。

16.3.1.4 アーティファクト

インストール、コンフィグレーション、およびデプロイメントでは、OWLCS の以下のアーティファクトが作成されます。

16.3.1.4.1 .ear ファイル

アプリケーションをデプロイするための .ear ファイルはミドルウェア ホーム ディレクトリにあります (例) : $MW_HOME/as11gr1wlcs1/communications/applications。通常、これらはファイル名で簡単に識別されます (たとえば、SMPP ドライバをデプロイする sdpmessagingdriver-smpp.ear など)。

16.3.1.4.2 コンフィグレーション ファイル

コンポーネントのコンフィグレーションは、各種の .xml ファイルで行われます。これらはミドルウェア ホーム ディレクトリにあります (例) : $DOMAIN_HOME/config/communications。通常、これらはファイル名で簡単に識別されます (たとえば、SMPP をコンフィグレーションする usermessagingdriver-smpp_Plan.xml など)。

16.3.1.4.3 ログ ファイル

ログ アクティビティはログ ファイルに格納されます。多数のログ ファイルがありますが、特に重要なのは、インストール、アクティビティ、エラー、および診断のログ ファイルです。これらはミドルウェア ホーム ディレクトリにあります (例) : $DOMAIN_HOME/servers/wlcs_server1/logs。

16.3.1.5 トポロジのコンポーネント

以下に、高可用性の OWLCS トポロジ内のコンポーネントの詳細を示します。 図 16-4 に、トポロジをサポートする OWLCS ホストの詳細を示します。

図 16-4 OWLCS のホストの詳細

「図 16-4 OWLCS のホストの詳細」の説明

- 節 16.3.1.5.1「SIP コンテナ」

- 節 16.3.1.5.2「サードパーティ製ロード バランサ」

- 節 16.3.1.5.3「Proxy Registrar」

- 節 16.3.1.5.4「プレゼンス サービス」

- 節 16.3.1.5.5「Presence Web Services」

- 節 16.3.1.5.6「Third-Party Call Control Web サービス」

- 節 16.3.1.5.7「Aggregation Proxy」

- 節 16.3.1.5.8「Authentication Proxy」

- 節 16.3.1.5.9「ファイル転送サービス」

- 節 16.3.1.5.10「メッセージング サービス」

- 節 16.3.1.5.11「STUN サービス」

- 節 16.3.1.5.12「DAR コンフィグレーション」

- 節 16.3.1.5.13「Oracle Communicator クライアント」

- 節 16.3.1.5.14「状態層」

- 節 16.3.1.5.15「User Dispatcher」

- 節 16.3.1.5.16「Oracle RAC データベース」

注意 :
これらのコンポーネントのコンフィグレーションの詳細については、『Oracle Fusion Middleware Enterprise Deployment Guide for Oracle WebCenter』を参照してください。

図 16-5 OWLCS の高可用性の詳細

「図 16-5 OWLCS の高可用性の詳細」の説明

16.3.1.5.1 SIP コンテナ

OWLCS では、JSR 289 準拠の SIP コンテナによって WebLogic Server プラットフォームが拡張されています。 これにより、進化した通信アプリケーションに対応した、HTTP および SIP を処理する J2EE アプリケーションを開発できます。 このプラットフォームでは、SIP ベースの IP-PBX、および標準 SIP クライアントなどの他の SIP 要素と統合される、補完的な通信サービスの開発が可能になります。SIP コンテナの詳細については、『Oracle WebLogic Communication Services 管理ガイド』を参照してください。

複数の SIP コンテナは、OWLCS SIP 状態のレプリケーションを通じて相互にリンクしています。ある SIP コンテナ ノードに障害が発生した場合にノードのレプリケートされた状態を使用して別のコンテナ ノードが処理を引き継げるように、各コンピュータ上の OWLCS SIP 状態は SIP 状態層にある他のノードにレプリケートされます。

16.3.1.5.2 サードパーティ製ロード バランサ

サードパーティ製ロード バランサは、着信トラフィックの負荷を分配します。また、障害が発生したノードから稼働中のノードにトラフィックをリダイレクトします。使用するロード バランサは、HTTP および SIP の両方のトラフィックをルーティングする機能を持ち、この機能がコンフィグレーションされている必要があります。ロード バランサの詳細については、『Oracle Fusion Middleware Enterprise Deployment Guide for Oracle WebCenter』を参照してください。

16.3.1.5.3 Proxy Registrar

OWLCS Proxy Registrar は、SIP プロキシ サーバとレジストラの機能を結合します。 主なタスクとしては、サブスクライバの登録、サブスクライバのロケーションの検索、前方へのリクエストのプロキシなどがあります。Proxy Registrar は、ユーザのロケーション データと登録データを Oracle データベースに格納します。これはオプションのコンポーネントです。Proxy Registrar の詳細については、節 14.1「Proxy Registrar」を参照してください。

16.3.1.5.4 プレゼンス サービス

OWLCS には、プレゼンス情報の集約機能として動作し、アプリケーションおよびエンドユーザがプレゼンス情報を使用するためのサブスクライブ/通知機能を提供する、プレゼンス サービスが含まれています。Web サービスを使用するか、または準拠する SIP ベースのエンドユーザ クライアントを使用して、アプリケーションを統合できます。

16.3.1.5.5 Presence Web Services

OWLCS を使用すると、Web サービス クライアントは、「Open Service Access, Parlay X Web Services, Part 14, Presence ETSI ES 202 391-14」で定義されている Parlay X Presence Web Service のサポートを通じて、プレゼンス サービスにアクセスできます。Parlay X Web Service では、HTTP Web サービス クライアントが、プレゼンス情報をパブリッシュおよびサブスクライブするプレゼンス サービスにアクセスできます。Parlay X Presence Web Service では、このような Web ベースのクライアントを開発するのに SIP プロトコルに精通している必要はありません。Web 開発者は、Web サービスの知識を利用してこのようなクライアントを作成できます。

16.3.1.5.6 Third-Party Call Control Web サービス

Third Party Call Parlay X 2.1 通信サービスは Parlay X 2.1 Third Party Call インタフェースを実装します (標準参照 : ETSI ES 202 391-2 V1.2.1 (2006-12), Open Service Access (OSA); Parlay X Web Services; Part 2: Third Party Call (Parlay X 2))。Third-Party Call Control Web サービスの詳細については、『Oracle WebLogic Communication Services 開発者ガイド』を参照してください。

16.3.1.5.7 Aggregation Proxy

Aggregation Proxy は、Web サービス呼び出しを承認し、XCAP トラフィックを認証します。その後、Aggregation Proxy は、このトラフィックを Parlay X Web Service および XDMS にプロキシします。これはオプションのコンポーネントです。

16.3.1.5.8 Authentication Proxy

Authentication Proxy は、認証の成功時に P-Asserted-Identity ヘッダをリクエストに挿入する SIP アプリケーションです。 Authentication Proxy アプリケーションでは認証自体は実行されません。すべての SIP アプリケーションに対し、SIP ダイジェスト ベースの認証が通常の方法でコンフィグレーションされています。P-Asserted-Identity ヘッダの値は、外部に格納された (たとえば、Oracle Identity Management または Database 内など) 認証済みユーザの優先的な SIP- または TEL-URL、あるいはその両方になります。

16.3.1.5.9 ファイル転送サービス

OWLCS には、ユーザが相互にファイルを転送できる Oracle 固有のファイル転送サービスが含まれています。

16.3.1.5.10 メッセージング サービス

メッセージング サービスでは、「ETSI ES 202 391-5 V1.2.1 (2006-12), Open Service Access (OSA), Parlay X Web Services Part 5: Multimedia Messaging (Parlay X 2)」で定義されているように、SendMessage、ReceiveMessage、および MessageNotificationManager の各インタフェースの操作のサブセットのサポートが実装されています。

16.3.1.5.11 STUN サービス

OWLCS STUN サービスは、STUN (Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)) を実装します。 STUN サービスの詳細については、節 14.2「STUN サービス」を参照してください。

16.3.1.5.12 DAR コンフィグレーション

DAR コンフィグレーションです。アプリケーション ルータは、着信 SIP リクエストを適切なアプリケーションにルーティングする SIP アプリケーションです。アプリケーション ルータでは、処理される各 SIP リクエストにルート ヘッダを配置することにより、リクエストをルーティングします。リクエストには、それぞれ異なる宛先 URI を表すいくつかのルート ヘッダを配置できます。SIP リクエストは宛先 URI のチェーンを通じて送信されるか、または最初の宛先への到着時に新しい URI にプロキシされます。

16.3.1.5.13 Oracle Communicator クライアント

Oracle Communicator は、組織内のユーザが相互に連絡を取り合うことのできるクライアント通信アプリケーションです。連絡先のプレゼンス (連絡先の状態) を表示し、インスタント メッセージの送信やファイルの共有を通じて相互に通信できます。

16.3.1.5.14 状態層

Oracle WebLogic Communication Services の SIP 状態層ノードでは、同時 SIP 呼に対するアプリケーション呼状態を管理します。SIP 状態層では、呼状態の単一のコピーを管理することも、サーバ マシンで障害が発生したりネットワーク接続が中断された場合でも呼状態データが失われないように、必要に応じてクラスタ間で複数のコピーを管理することもできます。

16.3.1.5.15 User Dispatcher

User Dispatcher を使用すると、Presence アプリケーションと XDMS アプリケーションのスケール変更を行えます。User Dispatcher は、SIP および XCAP の各リクエストを (HTTP 上で) 適切な宛先に一貫した基準でディスパッチするプロキシです。

Presence アプリケーションではデプロイメント内のすべてのユーザの状態が維持されるため、User Dispatcher を使用して Presence アプリケーションのスケール変更 (分散) を行えます。User Dispatcher では、(HTTP 上で) SIP および XCAP プロトコルを使用する、Presence サーバおよび XDMS サブアプリケーションへのリクエストのディスパッチをサポートします。

16.3.1.5.16 Oracle RAC データベース

Oracle RAC 環境では、Oracle RDBMS がインストールされ、運用可能な状態である必要があります。 サポートされているバージョンは、10.2.0.4 および 11.1.0.7 です。『Oracle Clusterware Installation Guide 11g Release 1 (11.1.)』、『Oracle Real Application Clusters: For 11g Release 1 (11.1)』、および 『Oracle Real Application Clusters Installation Guide 11g Release 1』を参照してください。

16.3.1.6 SIP 状態層のコンフィグレーションの概要

Oracle WebLogic Communication Services の SIP 状態層は、同時 SIP 呼のアプリケーション呼状態を管理するサーバ インスタンスのクラスタです。SIP 状態層では、呼状態の単一のコピーを管理することも、サーバ マシンで障害が発生したりネットワーク接続が中断された場合でも呼状態データが失われないように、必要に応じて複数のコピーを管理することもできます。

SIP 状態層クラスタは、1 つまたは複数の「パーティション」として構成します。 1 つのパーティションは、同時呼状態データの同じ部分を管理する、1 つまたは複数の SIP 状態層サーバ インスタンスで構成されます。単一サーバの Oracle WebLogic Communication Services インストールや、エンジン層と SIP 状態層にそれぞれ 1 つずつサーバがある 2 つのサーバのインストールでは、すべての呼状態データが単一のパーティションで管理されます。同時呼状態のサイズが、単一のサーバ インスタンスで処理できる最大サイズを超える場合には、複数のパーティションが必要です。複数のパーティションを使用する場合、同時呼状態はそれらのパーティション間で分割され、各パーティションはそれぞれデータの別々の部分を処理します。たとえば、2 つのパーティションで構成される SIP 状態層の場合、1 つ目のパーティションでは、同時呼状態の半分を管理し (たとえば、セッション A ～ M)、2 つ目のパーティションでは、残りの呼 (セッション N ～ Z) を管理します。

多くの場合、個々のサーバで管理できる呼状態の最大サイズは、Java 仮想マシンのヒープ サイズによって制限されます。

同じパーティション内でサーバを追加して、呼状態データのコピーを処理できます。同じパーティションに複数のサーバが属する場合には、各サーバは、呼データの同じ部分のコピー (呼状態の「レプリカ」) を処理します。パーティション内のサーバで障害が発生したり、ネットワーク障害のためにアクセスできない場合には、エンジン層に対する呼状態データの提供は、パーティション内の別のレプリカによって行われます。Oracle では機器やネットワークの障害に備え、プロダクション インストール用の各パーティションに 2 つのサーバをコンフィグレーションすることを推薦します。冗長性を強化するため、1 つのパーティションには最大 3 つのレプリカを含めることができます。

16.3.1.7 SIP 状態層のコンフィグレーションとコンフィグレーション ファイルの例

以下の節では、別個の SIP 状態層を使用する Oracle WebLogic Communication Services インストールの典型的な例を説明します。

16.3.1.7.1 単一パーティションの SIP 状態層

単一のパーティションに 2 つのサーバがある SIP 状態層は、最も単純な状態層のコンフィグレーションです。

たとえば、例 16-1 に示す datatier.xml コンフィグレーション ファイルは、2 つのレプリカのコンフィグレーションを作成します。

例 16-1 レプリケーションによる小規模デプロイメントでの SIP 状態層のコンフィグレーション

<?xml version="1.0" encoding="UTF-8"?>
<data-tier xmlns="http:....">
<partition>
<name>Partition0</name>
<server-name>DataNode0-0</server-name>
<server-name>DataNode0-1</server-name>
</partition>
</data-tier>

16.3.1.7.2 2 つのパーティションの SIP 状態層

例 16-2 に示すように、datatier.xml で複数の partition エントリを作成することで、複数のパーティションを作成できます。

例 16-2 2 つのパーティションの SIP 状態層のコンフィグレーション

<?xml version="1.0" encoding="UTF-8"?>
<data-tier xmlns="http:....">
<partition>
<name>Partition0</name>
<server-name>DataNode0-0</server-name>
</partition>
<partition>
<name>Partition1</name>
<server-name>DataNode1-0</server-name>
</partition>
</data-tier>

16.3.1.7.3 2 つのパーティション、2 つのレプリカの SIP 状態層

各パーティションに複数の SIP 状態層サーバを定義すると、呼状態のレプリカを追加できます。例 16-3 は、それぞれ 2 つのサーバ (レプリカ) を含む 2 つのパーティションを持つシステムの定義に使用される datatier.xml コンフィグレーション ファイルを示します。

例 16-3 小規模デプロイメントでの SIP 状態層のコンフィグレーション

<?xml version="1.0" encoding="UTF-8"?>
<data-tier xmlns="http:....">
<partition>
<name>Partition0</name>
<server-name>DataNode0-0</server-name>
<server-name>DataNode0-1</server-name>
</partition>
<partition>
<name>Partition1</name>
<server-name>DataNode1-0</server-name>
<server-name>DataNode1-1</server-name>
</partition>
</data-tier>

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

Oracle WebLogic Communication Services では、長期間維持する呼状態データを Oracle RDBMS に格納して RAM を節約することができます。RDBMS の永続性を有効にすると、SIP 状態層は、呼のダイアログが確立された後、呼状態データをデフォルトで RDBMS に保存します。それ以降のダイアログ境界で、呼状態を変更したり、削除する必要がある場合は、保存された呼状態データを抽出したり、削除します。

Oracle では、アプリケーション設計者用の API を用意し、どのようなときに呼状態データを SIP 状態層に保持すべきかについての「ヒント」を提供しています。呼状態データを頻繁に RDBMS で保存したり、特定の呼の永続性を無効にするためにこれらのヒントを使用できます。

Oracle WebLogic Communication Services では、RDBMS を使用して、SIP 状態層のインメモリ レプリケーション機能を補うことができます。RDBMS 使用時にレイテンシ パフォーマンスを改善するため、SIP 状態層はアクティブに変更されている呼状態 (たとえば、設定中の新しい呼に対応している状態) と共に、SIP タイマーをメモリ内で管理します。呼状態はダイアログが確立された後に自動的に保持され、それ以降のダイアログ境界で呼は進行中か、アプリケーション開発者が加えた保持に関するヒントに対応しているかのどちらかです。

RDBMS と共に使用する場合、SIP 状態層は (このドキュメントでは、「状態層」という用語を「データ層」に代わるものとして使用しています)、すべての呼状態のデータベースへの書き込み (または削除) を処理する 1 つのレプリカ サーバ インスタンスを選択します。使用可能なレプリカならどれでも、次の読み込みのために必要に応じて永続的な保持から呼状態を検索するために使用できます。

ドメインがエンジン層への接続を管理するため SIP-aware ロード バランサを使用している場合、RDBMS への呼状態の格納をエンジン層キャッシャと組み合わせて使用することができます。

16.3.2 地理的な冗長性

地理的な冗長性では、地理的に分割された SIP サーバのデプロイメントを使用することで、プロバイダの途切れることのないトランザクションと通信が保証されます。

プライマリ サイトでは、各種の SIP トランザクションおよび通信を処理し、トランザクションの境界が確定した時点で、処理中のトランザクションに関連付けられている状態データをセカンダリ サイトにレプリケートできます。プライマリ サイトに障害が発生すると、呼は処理のために障害の発生したプライマリ サイトからセカンダリ サイトにルーティングされます。同様に、障害からの回復時、呼はプライマリ サイトに再び戻されます。詳細については、『Oracle WebLogic Communication Services 管理ガイド』を参照してください。

図 16-6 地理的な冗長性

「図 16-6 地理的な冗長性」の説明

上の図は、地理的な冗長性を示しています。処理は次のように進行します。

1. プライマリ クラスタ サイトで呼が開始され、呼の設定と処理が正常に行われます。

2. 呼は通常どおりサイトの SIP 状態層にレプリケートされ、セカンダリ サイトへのレプリケーションが可能になります。

3. SIP 状態層にある単一のレプリカによって、レプリケート対象の呼状態データが、レプリカ サイトにコンフィグレーションされた JMS キューに配置されます。

4. WAN 上の JMS を使用して、使用可能ないずれかのエンジンに呼が送信されます。

5. セカンダリ サイトのエンジンは、新しいメッセージをローカル キューでモニタします。メッセージを受信すると、セカンダリ サイトのエンジンが呼状態データを保存し、プライマリ サイトのサイト ID 値を割り当てます。

16.3.3 フェイルオーバ

Oracle の高可用性ソリューションには、あらゆるレベルのシステムに対するフェイルオーバのサポートが含まれています。フェイルオーバでは、正しく機能していない、または稼動していないコンポーネントの機能が、スタンバイ コンポーネントまたは代替コンポーネントによって処理されます。これは手動による介入なしに行われ、多くの場合、システムがフェイルオーバ アクションを実行していることをエンドユーザ側では検出できません。フェイルオーバには、「セッション フェイルオーバ」と「サービス フェイルオーバ」という 2 つの主な種類があります。

「セッション フェイルオーバ」は、セッション、接続、または電源が中断した場合に発生します。セッション フェイルオーバ時は、進行中の呼またはリクエストがバックアップ ノードによって処理され、この状態が発生したことをユーザ側では検出しません。SIP コンテナは、セッションの障害からの回復に役立つサービスを上位レベルに対して提供します。SIP プロトコルは、事前定義された特定の時間 (毎時など) に状態を再構築します。これは、信頼性のないネットワークを保護するために設計されています。

「サービス フェイルオーバ」が発生すると (クラスタ内のあるノードが停止した場合など)、クラスタ内の他のノードによって負荷が処理されます。その時点で処理中の個別のリクエストは失敗しますが、後続のリクエストは稼働中のノードによって処理されます。

高可用性のコンフィグレーションでは、Proxy Registrar、Third-Party Call Control および他の分散可能アプリケーションなどの、wlcs-services ドメインで実行中のサービスで、セッション フェイルオーバがサポートされています。また、プレゼンスおよび他の非分散型アプリケーションなどの、wlcs_presence ドメインで実行中のサービスでは、サービス フェイルオーバがサポートされています。

16.3.3.1 OWLCS プレゼンスのフェイルオーバ

高可用性のデプロイメントで複数のノードを使用している場合、OWLCS プレゼンスはノード (サーバ) 間でサービスを分散します。エンティティ (E1) のプレゼンス情報に対するリクエストが作成されると、リクエストはノード 1 (N1) に渡されます。リクエスト中に N1 が停止すると、障害の発生がユーザに通知されます。リクエストを再送信すると、リクエストはノード 2 (N2) で処理されます。再送信されたリクエスト、または最初の障害後に作成されたその他のリクエストでは、障害は発生しません。

フェイルオーバは、Presence サーバのより高度な可用性を実現するために User Dispatcher が使用できる手法です。Presence サーバでは (確立されたサブスクリプションなどの) 状態がレプリケートされないため、クライアントは新しいサブスクリプションを設定することで新しいサーバ ノード上に状態を再作成する必要があります。また、サブスクリプションは SIP ダイアログであり、User Dispatcher はレコード ルーティングではないため、あるノードから別のノードへのサブスクリプションをフェイルオーバすることはできません。すべての後続のリクエストはルート セットに続き、「古い」ノードで終了します。

これは、「障害が発生している」サーバからフェイルオーバするときの問題ではありません。該当するノードはトラフィックを処理しておらず、ダイアログ内のリクエストは最終的にエラー応答やタイムアウトを取得してダイアログが終了するためです。ただし、バックアップ ノードから (修復された) 元のノードにユーザを再び戻して、障害後の分散を均等に保つ必要がありますが、これによってプレゼンス機能の不具合が起きる可能性があります。実行中のあるサーバから別のサーバにサブスクリプションを移行するには、クライアントまたはサーバのいずれかを再起動するしかありません。

ただし、サブスクリプションを保持しているサーバでは、終了の NOTIFY を送信し、サブスクリプション状態を破棄することで、これをアクティブに終了させることができます。これにより、クライアントでは新しい最初の SUBSCRIBE が発行され、新しいダイアログが確立されます。ある稼働中のノードから別のノードにサブスクリプションを移行する場合、User Dispatcher は (最初のリクエストにのみ影響する) トラフィックをフェイルオーバし、サブスクリプションを終了するよう現在のサーバに指示する必要があります。

16.3.3.2 プレゼンティティの移行

ノード セットが変更された場合は、プレゼンティティを移行する必要があります。移行するには、Presence アプリケーションで一部または全部のサブスクリプションを終了する必要があります。

16.3.3.2.1 ステートレスな User Dispatcher と分散の均等化

最も基本的な方法では、すべてのノード上の Presence アプリケーションに通知し、すべてのサブスクリプションを終了させます。この場合の問題は、一定期間にわたるとはいえ、大量のトラフィックが突発的に生成されることです。終了期間が長いほど、すべてのユーザが正しいプレゼンス状態を取得するまでに時間がかかるため、この期間に不適切なプレゼンス状態が生じます。

この問題を最適化するため、実際に終了する必要のあるサブスクリプション (移行されたサブスクリプション) のみを終了できます。問題は、どのユーザがこれらに該当するのかを User Dispatcher が認識しておらず (アルゴリズムに基づいてステートレスな分散を行うため)、Presence アプリケーションでも認識していない点です (どのユーザがサブスクリプションを保持しているかのみ認識しているため)。ただし、Presence アプリケーションがすべてのサブスクリプションを反復処理し、各サブスクリプションについて、このユーザがこの Presence ノードに移動するかどうかを User Dispatcher に尋ねることができれば、Presence サーバでは戻らないサブスクリプションのみを終了できます。これは負荷の大きい操作かもしれませんが、各 Presence サーバが User Dispatcher と共に配置されるという制約の下で、これらの各コールバックは同じ JVM 内で行われます。

16.3.3.2.2 Presence アプリケーションのブロードキャスト

もう 1 つの解決策は、ある時点ではユーザが 1 つの Presence ノードにのみ存在することを Presence サーバで保証することです。これを実行するには、Presence アプリケーションが新しいプレゼンティティ (まだ状態がないプレゼンティティ) の PUBLISH または SUBSCRIBE を受信したときに、近隣のすべてのノードにメッセージをブロードキャストするようにします。このブロードキャスト メッセージを受信した他の Presence ノードが、このプレゼンティティのアクティブなサブスクリプションをすでに保持している場合、クライアントが新しいサーバで新しいサブスクリプションを確立できるように、そのサーバは該当するサブスクリプションを終了する必要があります。

Presence アプリケーションでこの機能を使用する場合、User Dispatcher では、ある稼働中のノードから別のノードにユーザを移行するために追加の手順を実行する必要はありません。

16.3.3.3 スタンバイ サーバ プール

別の方法として、障害の発生したノードからトラフィックを引き継ぐ準備が整っている、アイドル状態のサーバのスタンバイ プールを用意することもできます。アクティブ ノードに障害が発生すると、User Dispatcher はそのすべてのトラフィックをスタンバイ プールの 1 つのサーバに再分散します。これで、このノードがアクティブになります。障害の発生したノードが最終的に修復されると、そのノードはスタンバイ プールに追加されます。そのため、障害の発生したノードが再開しても、稼働中のノードからユーザを「再び」移行する必要はありません。

この方法ではハードウェアを追加する必要があり、ハードウェア リソースの使用が最適化されません。

16.3.3.4 障害の種類

Presence サーバでは、いくつかの種類の障害が発生する可能性があります。User Dispatcher では、障害の種類に応じて異なるアクションを実行する必要があります。

16.3.3.4.1 致命的な障害

致命的な障害の場合、すべての状態情報は失われ、確立されたセッションは失敗します。ただし、エラー応答に応じて、新しい SIP ダイアログを使用することで、サブスクリプション (プレゼンス サブスクライブ セッション) は存続することができます。応答コードが 481 の場合、プレゼンス クライアントは RFC 3265 に従って新しい SUBSCRIBE ダイアログを確立する必要があります。これはプレゼンス側からは障害と見なされません。その他のエラー応答はすべて、(クライアントの実装に応じて) クライアントでエラーとして処理され、障害と見なされます。

致命的な障害の後、サーバには障害発生前の時点からのダイアログ状態はなく、このため、この時点で到着したすべての後続のリクエストに対して 481 応答が返されます。障害時は、(最初および後続の) すべてのトランザクションは 481 以外のエラー コードで終了します。最も可能性があるのは 500、または内部 503 または 408 です (ルート パスにプロキシが含まれているかどうか、および障害の性質に応じて異なります)。

通常は、致命的な障害の結果、サーバ プロセスまたはマシン全体が再起動されます。

16.3.3.4.2 一時的な障害

一時的な障害では、データはまったくまたはほとんど失われないため、障害後もサーバにセッション状態が残ります。このため、サーバが障害から回復した後に到着した後続のリクエストは、障害の前と同じように処理され、同じ結果になります。

障害時に到着したすべてのリクエストでは、503 などの、481 以外のエラー応答が返されます。

一般に、一時的な障害は期間が短く、典型的な例として、サーバが一部またはすべてのリクエストに対して 503 で応答するオーバーロードの状態などがあります。

16.3.3.5 フェイルオーバ アクション

Presence サーバ ノードで障害が検出された場合、User Dispatcher はいくつかのアクションを実行できます。このアクションの目的は、失敗したサブスクリプションとパブリケーションの数、および回復にかかる時間の点から、障害の影響を最小限に抑えることです。User Dispatcher ではこの他にも、アクティブなサーバ間で分散を可能な限り均等に保つ必要があります。

このバージョンの User Dispatcher で使用されるフェイルオーバ アクションは、プール内のノードを無効にする方法です。ResizableBucketServerPool を使用する場合は、追加操作と削除操作が確定的でないため、これはノードを削除するよりも適切な方法です。つまり、ノードを追加した結果が以前の追加操作と削除操作のシーケンスに依存するのに対し、無効化の操作では、アクティブなノードと無効なノードのセットがある場合に、分散内で常に同じ変更が行われます。

16.3.3.6 オーバーロード ポリシー

アクティブにされたオーバーロード ポリシーでは、複数の種類の障害を示すことがありますが、この主な目的は、システムが処理するトラフィックの負荷が大きくなりすぎないように保護することにあります。このような状況が障害として検出されると、トラフィックが適度に均等に分散されている場合にすべてのノードがオーバーロード状態、またはそれに近い状態になるため、フェイルオーバ アクションによってクラスタ全体が停止する可能性があります。ディスパッチャがクラスタのあるノードを削除し、そのノードのトラフィックを残りのノードに再分散した場合、それらのノードは確実にオーバーロード状態に陥り、連鎖反応が起こります。

このオーバーロード状態は、システムに負荷がかかっていなくてもオーバーロード ポリシーのアクティブ化を引き起こすソフトウェア障害と区別することが困難ですが、オーバーロード ポリシーが無効でない限り、フェイルオーバ アクションを実行することが適切な場合があります。システムが実際にオーバーロード状態にある場合、システムの機能は制限される可能性があり、フェイルオーバは無効になります。

User Dispatcher は、(オーバーロード ポリシーがアクティブであることを示す) 503 応答が検出された場合、フェイルオーバを行いません。ただし、サーバが 503 応答を返す代わりにメッセージが削除される最大のオーバーロード ポリシー状態にある場合、User Dispatcher モニタは内部 408 を受信します。これは応答のないサーバと区別されずに、フェイルオーバが発生します。

16.3.3.7 フェイルオーバ イベントの同期化

障害検出メカニズムに応じて、異なるディスパッチャ インスタンス間で、フェイルオーバ イベント (または結果として生じる状態) を同期する必要があります。これは、エラー応答など、クラスタ全体での検出メカニズムの整合性が保証されていない場合に必要です。たとえば、あるサーバ ノードがあるリクエストに対して 503 応答を送信した後、すぐに正常に動作するとします (これは、オーバーロード ポリシーの一時的な障害により起こる場合があります)。1 つの 503 のみが送信された場合、これは 1 つのディスパッチャ インスタンスでのみ受信されます。このイベントがフェイルオーバを発生させると、このディスパッチャ インスタンスはクラスタの残りのインスタンスと同期しなくなります。さらに、一定期間にいくつかの 503 応答を受け取ってフェイルオーバを発生させるように猶予期間が実装されている場合でも、障害期間が猶予期間と同じである場合は、依然として競合状態のリスクが生じます。

以下の方法を使用すると、ディスパッチャ インスタンスのクラスタ全体で、フェイルオーバ後の状態が確実に同期されます。

16.3.3.7.1 フェイルオーバ イベントのブロードキャスト

この方法では、フェイルオーバ アクションを実行し、サーバ セットを変更することを決定した場合、各ディスパッチャ インスタンスは他のすべてのインスタンスに (通常は、JGroups などのマルチキャスト手法を使用して) 通知を送信する必要があります。この方法でも、2 つのインスタンスがフェイルオーバし、2 つの異なるサーバ ノードに対して同時に通知を送信する場合があるため、競合状態が発生することがあります。

16.3.3.7.2 状態の共有

クラスタのすべてのディスパッチャ ノードが「信頼性のある唯一のソース」からの同一の状態を共有する場合は、(フェイルオーバ アクションにより) いずれかのインスタンスによって状態が変更されると、他のすべてのインスタンスで変更が認識されます。

16.3.3.8 クラスタの拡張

Presence アプリケーションでは、各ユーザが複数の (増え続ける可能性のある) 他のユーザをサブスクライブするため、急激に増大する負荷が生成される可能性があります。このため、多くの混乱を伴わずにクラスタを動的に拡張するための方法が必要です。たとえば、従来の電気通信アプリケーションではクラスタのアップグレードのためトラフィックが少ない時間帯にすべてのサーバを停止することが容認されますが、これと比較すると、プレゼンス システムではより高度な可用性の要件が求められます。

クラスタの拡張では、Presence ノードと User Dispatcher ノードの両方を追加する必要がある場合があります。

新しい Presence サーバをクラスタに追加した場合、分散を適度に均等化するために、一部のプレゼンティティを古いノードから新しいノードに移行する必要があります。クラスタ変更時にシステム上のトラフィックが膨大にならないように、移行は最小限に抑える必要があります。

新しい User Dispatcher をクラスタに追加した場合、その User Dispatcher ノードは、他のディスパッチャ ノードと同じディスパッチ状態を達成する必要があります。プールの実装に応じて、他のディスパッチャ ノードと状態を同期する必要があります (たとえば、永続性のあるバケット プール実装を使用している場合など)。

注意 :
プレゼンス クラスタ内の各 User Dispatcher では、ディスパッチ先となる Presence サーバのリストに、クラスタ内のすべての Presence サーバ インスタンスが含まれるようにコンフィグレーションする必要があります。

16.3.3.8.1 ノード セットの更新

指定のプレゼンティティのサーバ ノードを検出するために使用されるアルゴリズムに応じて、新しいノードを追加または削除する際に別のノードに「移行される」プレゼンティティの数は異なります。プールの実装を最適化することで、この数は最小限に抑えられます。

16.3.3.8.2 プレゼンティティの移行

ノード セットが更新された場合、分散を均等にするために、一部のプレゼンティティを移行する必要があります。各種の移行方法については、「プレゼンティティの移行」で説明しています。

16.3.3.9 フェイルオーバの使用例

これらの使用例では、1 つまたは複数の Presence サーバ ノードでのさまざまな障害状況に対して、User Dispatcher がどのように対処するかを示しています。

16.3.3.9.1 1 つの Presence サーバが 60 秒間オーバーロードする

クラスタは 4 つの Presence サーバで構成され、各ノードは User Dispatcher と Presence アプリケーションがデプロイされた 1 つの OWLCS インスタンスで構成されています。100.000 ユーザが 4 つのサーバに均等に分散されます (各ノードに 25.000)。この中の 1 つのサーバで異常に長い GC による中断が原因で、メッセージの処理がガベージ コレクタによってブロックされるため、取得中の SIP キューがいっぱいになり、オーバーロード ポリシーがアクティブになります。60 秒後、処理が再開され、サーバは引き続きメッセージを処理します。

User Dispatcher はフェイルオーバを行いませんが、障害が発生したノードへのトラフィックの送信を続けます。この場合、すべての PUBLISH リクエストと最初の SUBSCRIBE リクエストは、障害が発生したノードに送信されるため、別のノードに移行されるセッションはありません。障害時に到着する最初の SUBSCRIBE は失敗し、481 以外のエラー (503 など) が発生します。障害が発生したノードの期限が切れるか、障害が報告される場合、新しいサブスクリプションを試して設定するかどうかはクライアント次第です。すべての PUBLISH リクエストと最初の SUBSCRIBE リクエストでは、失敗が生成されます。

障害が発生したノードが通常操作に戻る場合、すべてのトラフィックは再度処理され、失敗するリクエストはありません。セッションがフェイルオーバされないため、すべてのプレゼンス状態が再び「正常」になるまでにかかる時間は最小限で済みます。

このような場合のノードを「停止」として検出する方法でモニタ機能が実装される場合、一部のユーザは別のノードに移行され、このノードが復旧すると、ユーザは再び戻されます。このため、一定期間にある程度の負荷が増加します。トラフィックの負荷がきわめて高いためにオーバーロード ポリシーがアクティブになった場合、この移行は適切ではありません。この状態は再度発生する可能性が高く、その他のサーバもオーバーロードに近い状態になるためです。これにより、連鎖反応が生じるため、クラスタ全体が停止したり、サービスが完全に失われたりします。

16.3.3.9.2 1 つの Presence サーバが 5 秒間に複数回オーバーロードする

この使用例では、短期間 (たとえば 5 秒間) でオーバーロード状態とそうでない状態を行き来する Presence サーバについて説明します。これは、システムの機能が制限され、かろうじてトラフィックの負荷を処理できる場合によく発生します。ただし、特定のノード上の他の障害のみが原因で発生することもあります。User Dispatcher は、「1 つの Presence サーバが 60 秒間オーバーロードする」の場合とまったく同様に動作します。障害の期間がより短いために、失敗したセッション数とフェイルオーバ セッション数が少ないことを除けば、同じ結果になります。

16.3.3.9.3 オーバーロード ポリシーが OWLCS ソフトウェア障害によってトリガされる

OWLCS ソフトウェアまたはその上位にデプロイされたアプリケーションに障害が発生すると、すべてのスレッドがロックされます (デッドロック)。これにより、最終的にキュー内がいっぱいになるため、実際にシステムがオーバーロード状態ではなくても、オーバーロード ポリシーがアクティブになります。これは永続的なエラーのため、解決するにはサーバを再起動するしかありません。

モニタ機能が実装されているかどうか、およびモニタ機能の実装方法に応じて、影響を受けるユーザ数を最小限に抑えることができます。ただし、この状態を「実際の」オーバーロード状態と区別することはできません。この場合、フェイルオーバの実行は最適な方法ではありません。

16.3.3.9.4 Presence サーバのハードウェア障害

クラスタは 4 つの Presence サーバで構成され、各ノードは User Dispatcher と Presence アプリケーションがデプロイされた 1 つの OWLCS インスタンスで構成されています。100.000 ユーザが 4 つのサーバに均等に分散されます (各ノードに 25.000)。これらの Presence サーバのうちの 1 台がハードウェア障害が原因で停止します。故障したサーバを新しいサーバと交換するには手動による操作が必要です。2 時間が経過した後、サーバは再び起動し、実行します。障害の種類に応じて、障害が発生したノードにプロキシされるトランザクションに対して戻される応答コードは、408 または 503 になります。

この場合、障害の期間がサブスクリプションの有効期間よりも (ほとんどの場合) 長いため、このノード上のすべてのセッションは失敗します。モニタ サーバがフェイルオーバで実装される場合、障害時間は検出時間 (秒) に対して最小限で済みます。ユーザは移行機能によって移行されます。これにより、期間中の負荷が増加します。

User Dispatcher も障害が発生したノードで実行していたため、サーバを新しいマシンに交換する際に、User Dispatcher に関して維持されていたデータはすべて失われます。

16.3.3.9.5 1 つの Presence ノードを含むクラスタの拡張

クラスタは 3 つの Presence サーバで構成され、各ノードは User Dispatcher と Presence アプリケーションがデプロイされた 1 つの OWLCS インスタンスで構成されています。100.000 ユーザが 3 つのサーバに均等に分散されます (各ノードに 33.000)。新しいノードがインストールされ、クラスタに追加されます。新しいノードを追加するには、次の一連の操作を実行します。

1. 新しいノード上の User Dispatcher と Presence アプリケーションは、クラスタの残りのノードと同じ設定でコンフィグレーションされます。この設定では、永続性のあるプール実装の場合、新しい User Dispatcher に分散状態を同期する必要があります。

2. addServer JMX 操作は、クラスタの User Dispatcher MBean に対して新しいノードで起動されます。これにより、すべての User Dispatcher ノード (新しいノードを含む) に対して addServer 操作が起動されます。

3. ロード バランサは、最初のリクエストが新しい User Dispatcher ノードに送信されるように、新しいノードで再びコンフィグレーションされます。

4. 移行方法に応じて、Presence アプリケーションに対して (クラスタ MBean サーバを使用して) さらに JMX 操作を起動できます。

この結果、8.000 ユーザが移行され、ユーザの新しい分散は各ノードで 25.000 になります。移行方法に応じて、一定期間でシステムにかかるトラフィックの負荷が増加します。

16.3.3.9.6 クラスタからのノードの削除

クラスタは 4 つの Presence サーバで構成され、各ノードは User Dispatcher と Presence アプリケーションがデプロイされた 1 つの OWLCS インスタンスで構成されています。100.000 ユーザが 4 つのサーバに均等に分散されます (各ノードに 25.000)。1 つの Presence ノードがクラスタから削除されます。ノードを削除するには、次の一連の操作を実行します。

1. 削除するノードを含めないように、ロード バランサを再びコンフィグレーションします。

2. クラスタのすべての User Dispatcher からノードを削除するために、removeNode JMX 操作が起動されます。クラスタ MBean を使用して、操作を委任します。

3. 移行方法に応じて、削除するノードに対してさらに JMX 操作を起動できます。

4. 削除するノードからすべてのユーザが移行されると (この期間は移行方法によって異なります)、ノードは最終的に停止され、クラスタから削除されます。

この結果、8.000 ユーザが移行され、ユーザの新しい分散は各ノードで 33.000 になります。

16.3.3.9.7 Presence サーバの停止後、OPMN が再開する

4 ノードのクラスタがあり、各ノードに User Dispatcher と Presence アプリケーションがデプロイされているとします。そのうちの 1 つのノード上の Presence サーバ JVM が停止し、OPMN がそのプロセスを再開します。この再開には 1 分かかります。

16.3.3.9.8 アプリケーションからの 503 応答

ソフトウェアの不具合、またはアプリケーションでの誤動作が原因で、すべての着信トラフィックに対して 503 応答が送信されます。SIP サーバ自体は、著しい負荷の状態ではないため、オーバーロード ポリシーはアクティブになりません。これは、永続的なエラー状態になる場合とならない場合があります。

17 デプロイ済み SIP アプリケーションのアップグレード

以下の節では、アクティブな呼を失わずに、デプロイ済み SIP Servlets およびコンバージド SIP/HTTP アプリケーションを新しいバージョンにアップグレードする方法について説明します。

- 節 17.1「SIP アプリケーションのアップグレードの概要」

- 節 17.2「デプロイ済みアプリケーションをアップグレードする場合の要件と制約」

- 節 17.3「デプロイ済み SIP アプリケーションをアップグレードする手順」

- 節 17.4「バージョン識別子の割り当て」

- 節 17.5「新しいバージョンのアプリケーションのデプロイ」

- 節 17.6「以前のバージョンのアプリケーションのアンデプロイ」

- 節 17.7「アップグレード処理のロールバック」

- 節 17.8「アプリケーション名とバージョン識別子へのアクセス」

- 節 17.9「管理モードの使用」

17.1 SIP アプリケーションのアップグレードの概要

Oracle WebLogic Communication Services では、アプリケーションで処理中の既存の呼を失わずに、デプロイ済み SIP アプリケーションを新しいバージョンにアップグレードすることができます。このような形でアプリケーションのアップグレードを行うには、新しいバージョンのアプリケーションを以前のバージョンと並行してデプロイします。Oracle WebLogic Communication Services は、新しいリクエストが新しいバージョンに転送されるように SIP サーブレットのマッピングを自動的に管理します。確立されている既存のダイアログへのメッセージは、それ以降も呼が完了するまで以前のバージョンのアプリケーションに転送されます。既存のダイアログがすべて完了し、以前のバージョンのアプリケーションが処理する呼がなくなった後で、そのアプリケーションを安全にアンデプロイすることができます。

Oracle WebLogic Communication Services のアップグレード機能を利用すると、プロダクション アプリケーションのアップグレード中に呼が失われることがなくなります。また、アプリケーションのアップグレード処理を元に戻す (またはロールバックする) こともできます。たとえば、新しいバージョンのデプロイ済みアプリケーションに問題があると判断した場合は、新しいバージョンをアンデプロイして以前のバージョンをアクティブ化することができます。

注意 :
アプリケーションのアクティブなバージョンをアンデプロイすると、以前のアプリケーションのバージョンは管理モードのままになります。アプリケーションに新しいリクエストを転送するには、以前のバージョンを明示的にアクティブ化しなければなりません。

SIP 管理チャネルでアップグレード機能を使用すると、最終テストへのアクセスを制限して新しいアプリケーション バージョンをデプロイすることもできます。管理チャネルを使用して最終テストを行った後、アプリケーションを一般的な SIP トラフィックに開くことができます。

Oracle WebLogic Communication Services アプリケーションのアップグレードは、Oracle WebLogic Server 10g リリース 3 アプリケーションのアップグレードと同一の機能を提供しますが、以下の例外があります。

- Oracle WebLogic Communication Services では、以前のバージョンのアプリケーションの「滞りのない」リタイアをサポートしていません。代わりに、-retiretimeout オプションを weblogic.Deployer に対して使用することによる、タイムアウト ベースのアンデプロイメントのみをサポートします。

- SIP サーブレットまたはコンバージド アプリケーションで管理モードを使用する場合は、TLS 転送を使用する sips-admin チャネルのコンフィグレーションが必要です。

- Oracle WebLogic Communication Services は、レプリケートされた環境とレプリケートされない環境では、異なる方法でアプリケーションのアップグレードを処理します。レプリケートされた環境で、サーバは weblogic.xml コンフィグレーション ファイルで save-sessions-enabled 要素が true に設定された場合と同じように動作します。これにより、再デプロイメント処理間のセッションを維持します。
レプリケートされない環境では、セッションは再デプロイメント後直ちに破棄されます。

17.2 デプロイ済みアプリケーションをアップグレードする場合の要件と制約

Oracle WebLogic Communication Services のアプリケーション アップグレード機能を使用する場合の要件と制約は以下のとおりです。

- 以前のバージョンのアプリケーションと区別するために、新しいアプリケーションにバージョン情報を割り当てる必要があります。バージョン情報の割り当てが必要なのは、新しいバージョンのアプリケーションだけです。現在デプロイされているアプリケーションにバージョンの指定がない場合、Oracle WebLogic Communication Services はそのアプリケーションを自動的に「以前の」バージョンとして扱います。節 17.4「バージョン識別子の割り当て」を参照してください。

- 同時にデプロイできるバージョン違いの同じアプリケーションは 2 つまでです。

- アプリケーション名の使用をハードコード化しているアプリケーション (たとえば、1 つの呼を複数の SIP サーブレットで処理するように構成されたアプリケーション) の場合は、そのアプリケーション名を、基本アプリケーション名を取得するヘルパー メソッドの呼で置き換える必要があります。WebLogic Server には、基本アプリケーション名とバージョン識別子を取得すると共に、現在のバージョンのアプリケーションがアクティブか廃止中かを確認する ApplicationRuntimeMBean メソッドが用意されています。節 17.8「アプリケーション名とバージョン識別子へのアクセス」を参照してください。

- アプリケーションが (アプリケーション構成手法を使って) 構成されたアプリケーションに参加するときに、基本名しか指定されていない場合は、Oracle WebLogic Communication Services は常にアプリケーションの最新バージョンを使用します。

- 管理モードてアプリケーションをデプロイする場合、TLS 転送を使用する sips-admin チャネルのコンフィグレーションが必要です。

17.3 デプロイ済み SIP アプリケーションをアップグレードする手順

デプロイ済み SIP アプリケーションを新しいバージョンにアップグレードするには、次の手順に従います。

1. バージョン識別子の割り当て - バージョン識別子を使って新しいバージョンのアプリケーションをパッケージ化します。

2. 新しいバージョンのアプリケーションのデプロイ - 新しいバージョンのアプリケーションを以前のバージョンと並行してデプロイし、アップグレード処理を開始します。

3. 以前のバージョンのアプリケーションのアンデプロイ - 確立された呼への SIP メッセージを以前のバージョンのアプリケーションがすべて処理し終わると、そのバージョンを安全にアンデプロイすることができます。それ以降のすべての呼の処理は、新しくデプロイされたアプリケーションに任されます。

以下の節で、それぞれの手順について説明します。新しくデプロイされたアプリケーションで問題が見つかった場合は、アップグレード処理をロールバックすることもできます。複数の SIP サーブレットで構成されるアプリケーションでは、アプリケーション名とバージョン識別子へアクセスするために ApplicationRuntimeMBean を使用する場合もあります。

17.4 バージョン識別子の割り当て

Oracle WebLogic Communication Services では、アプリケーション名の後ろに追加されるバージョン識別子 (文字列値) を使用して、同じアプリケーションの複数のバージョンを区別します。バージョン文字列には最大で 215 文字まで指定できます。表 17-1 に示す有効な文字以外は使用できません。

表 17-1 有効な文字と無効な文字

有効な ASCII 文字

無効なバージョン文字

a-z

..

A-Z

.

0-9

他の文字と組み合わせたピリオド (「.」)、アンダースコア (「_」)、ハイフン (「-」)

デプロイ可能な SIP サーブレット WAR ファイルの場合、アプリケーションの MANIFEST.MF ファイルでバージョン識別子を定義するか、デプロイメント時にコマンド ラインで指定する必要があります。

17.4.1 マニフェストでのバージョンの定義

WAR および EAR のデプロイメントでは、どちらも MANIFEST.MF ファイルでバージョン識別子を指定する必要があります。例 17-1 に、バージョン識別子「v2」を指定したアプリケーションを示します。

例 17-1 マニフェストのバージョン識別子

Manifest-Version: 1.0
Created-By: 1.4.1_05-b01 (Sun Microsystems Inc.)
Weblogic-Application-Version: v2

バージョン識別子を割り当てずにアプリケーションをデプロイし、後からバージョン識別子を割り当ててデプロイした場合、Oracle WebLogic Communication Services はそれらのデプロイメントを同じアプリケーションの異なるバージョンとして認識します。

17.5 新しいバージョンのアプリケーションのデプロイ

アップグレード処理を開始するには、Administration Console または weblogic.Deployer ユーティリティを使用して、新しいアプリケーション アーカイブをデプロイします。一定の時間後に以前のバージョンのアプリケーションを自動的にアンデプロイするには、weblogic.Deployer ユーティリティに -retiretimeout オプションを使用します。次に例を示します。

java weblogic.Deployer -name MyApp -version v2 -deploy -retiretimeout 7

Oracle WebLogic Communication Services は、マニフェスト ファイルでバージョン識別子を調べ、現在アプリケーションの他のバージョンがデプロイされているか確認します。2 つのバージョンがデプロイされている場合、サーバは最後にデプロイされたアプリケーションに自動的に新しいリクエストを転送し始めます。もう一方のアプリケーションには新しい呼を転送せず、現在処理中の呼を完了できるようにします。この処理を、以前のバージョンのアプリケーションの「廃止」と呼びます。最終的に、以前のバージョンのアプリケーションは SIP メッセージを処理しなくなるからです。

Oracle WebLogic Communication Services は、デプロイされている 2 つのアプリケーションの実際のバージョン文字列を比較して、新しい方のバージョンを見分けるわけではありません。新しい呼は、常に最後にデプロイされたアプリケーションに転送されます。

Oracle WebLogic Communication Services は、バージョン識別子が指定されていない (マニフェストにバージョン文字列がない) デプロイメントと、バージョン識別子が指定されたそれ以降のバージョンのデプロイメントとを区別することもできます。このため、節 17.4「バージョン識別子の割り当て」で説明した方法でバージョン番号を指定し始める前にパッケージ化されたアプリケーションも簡単にアップグレードすることができます。

17.6 以前のバージョンのアプリケーションのアンデプロイ

既存のアプリケーションの新しいバージョンをデプロイした後、元のデプロイメントは、現在処理中の呼 (元のデプロイメントを使って開始された呼) へのメッセージだけを処理するようになります。処理中の呼が完了した後は、元のデプロイメントは新しい SIP メッセージを処理しません。ほとんどのプロダクション環境では、アプリケーションをアンデプロイする前に、元のデプロイメントがメッセージを処理していないことを確認する必要があります。

デプロイ済みアプリケーションがメッセージを処理しているかどうかを確認するには、アプリケーションの SipApplicationRuntimeMBean インスタンスからアクティブなセッション数を取得します。例 17-2 に、デフォルトの単一サーバ ドメインの findme サンプル アプリケーションのアクティブなセッション数を表示する WLST コマンドの例を示します。

アクティブなセッション数の値に基づいて、アプリケーションを安全にアンデプロイするか (処理中の呼は失われない)、強制的にアンデプロイするか (アンデプロイメントの時点でアクティブなセッションが失われる) を判断します。

適切なデプロイメントをアンデプロイするには、Administration Console または weblogic.Deployer ユーティリティを使用します。

例 17-2 セッション数を調べる WLST セッションの例

connect()
custom()
cd ('examples:Location=myserver,Name=myserver_myserver_findme_findme,ServerRuntime=myserver,Type=SipApplicationRuntime')
ls()
-rw-   ActiveAppSessionCount                        0
-rw-   ActiveSipSessionCount                        0
-rw-   AppSessionCount                              0
-rw-   CachingDisabled                              true
-rw-   MBeanInfo                                    weblogic.management.tools.In
fo@5ae636
-rw-   Name                                         myserver_myserver_findme_fin
dme
-rw-   ObjectName                                   examples:Location=myserver,N
ame=myserver_myserver_findme_findme,ServerRuntime=myserver,Type=SipApplicationRu
ntime
-rw-   Parent                                       examples:Location=myserver,N
ame=myserver,Type=ServerRuntime
-rw-   Registered                                   false
-rw-   SipSessionCount                              0
-rw-   Type                                         SipApplicationRuntime

-rwx   preDeregister                                void :

17.7 アップグレード処理のロールバック

アプリケーションの新しいバージョンをデプロイする場合や問題が見つかった場合は、次の手順に従ってアップグレード処理をロールバックすることもできます。

1. アクティブなバージョンのアプリケーションをアンデプロイします。

2. 以前のバージョンのアプリケーションをアクティブ化します。次に例を示します。

java weblogic.Deployer -name MyApp -appversion v1 -start

注意 :
アプリケーションのアクティブなバージョンをアンデプロイすると、以前のアプリケーションのバージョンは管理モードのままになります。アプリケーションに新しいリクエストを転送するために以前のバージョンを明示的にアクティブ化しなければなりません。

代わりに、-start オプションを使用すると、以前のバージョンのアプリケーションが起動されて新しいリクエストを処理し、新バージョンを終了します。

17.8 アプリケーション名とバージョン識別子へのアクセス

Oracle WebLogic Communication Services のプロダクション アップグレード機能を利用する予定がある場合は、複数の SIP サーブレットで構成されるアプリケーションでアプリケーション名をハードコード化しないでください。アプリケーション名をハードコード化する代わりに、ApplicationRuntimeMBean のいくつかのヘルパー メソッドを使用することにより、アプリケーションからデプロイメント名、またはバージョン識別子に動的にアクセスすることができます。

17.9 管理モードの使用

-adminmode オプションと weblogic.Deployer を必要に応じて使用して、管理モードでアプリケーションの新しいバージョンをデプロイすることができます。管理モードでは、TLS 転送を持つ sips-admin というコンフィグレーションされたネットワーク チャネル名を通してのみ SIP トラフィックを受け付けます。sips-admin チャネルがコンフィグレーションされていない場合、または別のチャネルを使用してリクエストを受けた場合は、サーバは 503 メッセージを返してリクエストを拒否します。

管理モードから一般に利用可能なモードにアプリケーションを遷移するには、weblogic.Deployer の -start オプションを使用します。

注意 :
お使いのアプリケーションで TLS を使用できない場合は、サーブレット ロール マッピング ルールを変更して 1 ユーザしかアプリケーションの新しいバージョンを使用できないように設定することもできます。これにより、新しいバージョンへのアクセスを制限しながら、以前のバージョンと並行して新しいバージョンをデプロイすることができます。

18 Parlay X Web Services のアーキテクチャ

この章では、OWLCS Parlay X Web Services のアーキテクチャ、セキュリティ、およびインストールについて説明します。この章の内容は以下のとおりです。

- 節 18.1「Web サービス クライアント アプリケーションのアーキテクチャ」

- 節 18.2「Web サービスのセキュリティ」

- 節 18.3「Web サービスのインストール」

18.1 Web サービス クライアント アプリケーションのアーキテクチャ

クライアント アプリケーションのアーキテクチャでは、Web サービスの 1 つのクライアントが、システムの多数のエンド ユーザに代わって機能します。

複数のユーザが同じ Web サービス クライアントに同時に接続でき、クライアントはこれらのユーザの代わりに Web サービスを起動します。次の使用時のガイドラインに注意してください。

- セキュリティ – Web サービスを実行している OWLCS Web サーバは、エンド ユーザではなくクライアントを認証します。クライアントは信頼できるエンティティであり、クライアントがいったん認証されると、クライアントのすべてのエンド ユーザは認証済みであると見なされます。このため、エンド ユーザを認証するタスクは Web サービス クライアントが行います。クライアントが正しく認証されるためには、エンド ユーザが事前に決定された認証資格を使用して接続する必要があります。

- Web クライアントはすべての Web サービスを起動する必要はない – つまり、Web クライアントは、SendMessage Web サービスに対してのみメソッドを起動できるため、その他の Web サービスを気にする必要はありません。ただし、クライアント アプリケーションのニーズに応じてその目的を達成するために、異なる Web サービスに対し、特定のメソッドを特定の順序で起動する場合があります。たとえば、メッセージを送信するクライアント アプリケーションが、送信されたすべてのメッセージのメッセージ通知を受け取る必要もある場合は、送信されたメッセージの通知を受け取る前に、MessageNotificationManager インタフェースの startMessageNotification メソッドを最初に呼び出す必要があります。

18.2 Web サービスのセキュリティ

デフォルトでは、すべてのデプロイされた OWLCS Web サービスは保護されていません。プロダクション環境にデプロイされるサービスでは、Web サービス セキュリティを有効にする必要があります。

OWLCS では、OWLCS Web サービスを保護する Oracle Web Services Manager の WS-Security ポリシーの使用がサポートされています。Oracle Web Services Manager の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server Web サービスのセキュリティ』の「Using Oracle Web Service Security Policies」を参照してください。

OWLCS Web サービスで推奨されるセキュリティ コンフィグレーションでは、Security Assertion Markup Language (SAML) トークンを使用して、Web サービス クライアントと OWLCS の間で ID の受け渡しを行います。SAML トークンを使用すると、Web サービス クライアントがユーザ名とパスワードを OWLCS に渡す代わりに、証明書の交換を通じてクライアントと OWLCS の間の信頼関係が確立されます。このようなキーストア コンフィグレーションが作成されると、Web サービス クライアントはユーザ ID のみを渡して、ユーザが適切に認証されていることを保証します。

OWLCS Web サービスで使用が推奨されるポリシーは、以下のとおりです。

- oracle/wss11_saml_token_with_message_protection_service_policy (サーバ側)

- oracle/wss11_saml_token_with_message_protection_client_policy (クライアント側)

18.2.1 通知時の Web サービス セキュリティ

各種の Web サービスには、クライアント側で実行される、対応する通知 Web サービス (MessageNotification、PresenceNotification) が含まれており、これらは該当するイベントが発生すると通知 (メッセージ配信ステータス、メッセージの受信、プレゼンス ステータスの変更) を受け取ります。この実装では、クライアントへの通知時に、デフォルトで Web サービス セキュリティ (WS-Security) が使用されません。つまり、サーバでは、クライアント側で実行される通知 Web サービスで WS-Security が使用されないことを想定し、通知を送信する際に自身の認証を試行しません。クライアント側で WS-Security を有効にすると、通知 SOAP リクエストに必要なヘッダが含まれていないため、サーバからの通知は失敗します。

18.2.2 OWLCS サービス セキュリティの有効化

OWLCS Web サービスのポリシーを有効にするには、『Oracle Fusion Middleware Oracle WebLogic Server Web サービスのセキュリティ』の「Configuring Oracle WSM Security Policies in Administration Console」の手順に従って、ポリシー oracle/wss11_saml_token_with_message_protection_service_policy を選択します。保護する必要のあるサービスごとに、このコンフィグレーションを繰り返す必要があります。

18.2.3 クライアントのセキュリティの有効化

Web サービス クライアントのセキュリティはプログラムで有効にする必要があります。『Oracle WebLogic Communication Services 開発者ガイド』に記述されたクライアント ライブラリを使用する場合は、クライアント オブジェクトの作成時に WS-Security ポリシー コンフィグレーションが提供されます。クライアントのコンストラクタは型 Map<String, Object> の引数を取ります。 SAML 認証を使用する場合は、通常、エンドポイント アドレスなどの他の必須プロパティのほかに、キーと値の組み合わせ (表 18-1) をコンフィグレーション マップに追加する必要があります。

表 18-1 クライアントのセキュリティ キー

キー

型

通常の値

oracle.sdp.parlayx.ParlayXConstants.POLICIES

String[]

oracle/wss11_saml_token_with_message_protection_client_policy

javax.xml.ws.BindingProvider.USERNAME_PROPERTY

String

<有効なユーザ名>

oracle.wsm.security.util.SecurityConstants.Config.KEYSTORE_RECIPIENT_ALIAS_PROPERTY

String

(省略可能) 対象となるサービスのキーストア エリアス。「クライアントのエリアス」を参照してください。

例 18-1 Web サービス クライアントのセキュリティ

import oracle.sdp.parlayx.presence.consumer.PresenceConsumerClient;

...

Map<String, Object> config = new HashMap<String, Object>();
config.put(javax.xml.ws.BindingProvider.ENDPOINT_ADDRESS_PROPERTY, owlcs_url);
config.put(oracle.sdp.parlayx.ParlayXConstants.POLICIES, new String[] {"oracle/wss11_saml_token_with_message_protection_client_policy"});
config.put(javax.xml.ws.BindingProvider.USERNAME_PROPERTY, "test.user1");

PresenceConsumerClient presenceClient = new PresenceConsumerClient(config);

18.2.4 キーストアのコンフィグレーション

推奨される WS-Security ポリシーを使用するには、OWSM に必要なパブリック キーおよびプライベート キー情報が含まれているキーストアをコンフィグレーションする必要があります。キーストアおよび該当する資格ストア エントリをコンフィグレーションする方法については、『Oracle Fusion Middleware Oracle WebLogic Server Web サービスのセキュリティ』の「Configuring the Credential Store Using WLST」を参照してください。

- Web サービス クライアントと OWLCS サーバが同じドメイン内にある場合は、キーストアと資格ストアが共有されます。

- Web サービス クライアントと OWLCS サーバが異なるドメイン内にある場合は、OWLCS のパブリック キーをクライアント ドメインのキーストアにインポートし、クライアント ドメインのパブリック キーを OWLCS のキーストアにインポートする必要があります。

18.2.5 クライアントのエリアス

ここで推奨される SAML ポリシーなどの特定の WS-Security ポリシーを使用する場合、クライアントではサーバのパブリック キーを使用して Web サービス リクエストを暗号化する必要があります。ただし、1 つのドメインにつきコンフィグレーションされているキーストアは通常 1 つのみです。このため、あるドメインの Web サービス クライアントが他の複数のドメイン内の Web サービスと通信するようなときは、OWSM で使用されるデフォルトのキーストア エントリをオーバーライドする必要がある場合があります。

たとえば、あるドメインに、SOA Web サービスに対する Web サービス クライアントであるアプリケーション「A」と、OWLCS Web サービスに対する Web サービス クライアントであるアプリケーション「B」があるとします。この場合、A のリクエストは SOA ドメインのパブリック キーを使用して暗号化し、B のリクエストは OWLCS ドメインのパブリック キーを使用して暗号化する必要があります。これを行うには、OWSM で使用されるキーストア エリアスを各リクエストでオーバーライドします。

- 2 つのサーバ ドメインのパブリック キーを、それぞれ異なるキーストア エリアスを使用してクライアント ドメインのキーストアにインポートします。たとえば、OWLCS パブリック キーにエリアス「owlcs_public_key」、SOA パブリック キーにエリアス「soa_public_key」を使用してインポートします。

- OWLCS Web サービス クライアントを作成する場合に、受信者のキーストア エリアス パラメータを指定します。キーを oracle.wsm.security.util.SecurityConstants.Config.KEYSTORE_RECIPIENT_ALIAS_PROPERTY に設定し、値を「owlcs_public_key」に設定します (例 18-2 を参照)。

例 18-2 クライアントのエリアス

import oracle.sdp.parlayx.presence.consumer.PresenceConsumerClient;

...

Map<String, Object> config = new HashMap<String, Object>();
config.put(javax.xml.ws.BindingProvider.ENDPOINT_ADDRESS_PROPERTY, owlcs_url);
config.put(oracle.sdp.parlayx.ParlayXConstants.POLICIES, new String[] {"oracle/wss11_saml_token_with_message_protection_client_policy"});
config.put(javax.xml.ws.BindingProvider.USERNAME_PROPERTY, "test.user1");
config.put(oracle.wsm.security.util.SecurityConstants.Config.KEYSTORE_RECIPIENT_ALIAS_PROPERTY, "owlcs_public_key")
PresenceConsumerClient presenceClient = new PresenceConsumerClient(config);

- SOA などの Web サービス クライアントでも同様にキーストア エリアスをオーバーライドする必要がありますが、厳密なメカニズムは異なる場合があります。たとえば、JAX-WS クライアント スタブ ディレクトリを使用している場合は、オーバーライド プロパティを JAX-WS リクエスト コンテキストに追加できます。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server Web サービスのセキュリティ』の「Policy Configuration Overrides for the Web Service Client」を参照してください。

18.3 Web サービスのインストール

Web サービスは標準の .ear ファイルとしてパッケージ化されており、Enterprise Manager から任意の他の Web サービスと同様にデプロイできます。.ear ファイルには、2 つのインタフェースを実装する 2 つの .war ファイルが含まれています。Web サービスは、oracle.sdp.client、oracle.sdp.platform、oracle.sdp.presencecommons という共有ライブラリに依存しています。

クライアント アプリケーションでは、OWLCS で提供される oracle.sdp.client 共有ライブラリをインポート (およびコンパイル) する必要があります。この場合、プロジェクトに parlayx.jar をインポートします。

oracle.sdp.client 共有ライブラリは、これに対してコンパイルするだけでなく、対象のランタイム環境で使用可能にする必要があります (つまり、oracle.sdp.client は対象の Weblogic Server に共有ライブラリとしてデプロイされます)。

これらの共有ライブラリ以外に、OWLCS のインストールには通知 Web サービス用の war ファイルが含まれています。これらの war ファイルには、開発者がさまざまな Web サービスの通知を有効にするためにインポートする必要のあるすべての jar ファイルが含まれています。

- messagingwsnotification-<version>.war – メッセージ配信ステータスおよびメッセージ受信の通知を受け取るクライアントを作成する場合にインポートする必要のある jar を含む、デプロイ可能な war ファイル。OWLCS サーバがメッセージング通知 Web サービスを起動できるように、クライアント アプリケーションと共にこの war もデプロイする必要があります。

- presencewsnotification-<version>.war – プレゼンス ステータス変更の通知を受け取るクライアントを作成する場合にインポートする必要のある jar を含む、デプロイ可能な war ファイル。OWLCS サーバがプレゼンス通知 Web サービスを起動できるように、クライアント アプリケーションと共にこの war もデプロイする必要があります。

第 VII 部

リファレンス

以下の付録があります。

- 付録 A「SIP サーブレット コンテナのコンフィグレーション リファレンス」

- 付録 B「SIP データ層のコンフィグレーション リファレンス」

- 付録 C「Diameter のコンフィグレーション リファレンス」

- 付録 D「起動コマンド オプション」

- 付録 E「サポート対象のプラットホーム、プロトコル、RFC、および標準」

A SIP サーブレット コンテナのコンフィグレーション リファレンス

以下の節は、エンジン層のコンフィグレーション ファイル sipserver.xml に関する詳細なリファレンス情報です。

- 節 A.1「sipserver.xml の概要」

- 節 A.2「sipserver.xml の編集」

- 節 A.3「XML スキーマ」

- 節 A.4「sipserver.xml ファイルの例」

- 節 A.5「XML 要素の説明」

A.1 sipserver.xml の概要

sipserver.xml ファイルはサーバ インストールのエンジン層にある Oracle WebLogic Communication Services インスタンスで供給された SIP コンテナ機能をコンフィグレーションする XML ドキュメントです。sipserver.xml は、domain_dir /config/CUSTOM サブディレクトリに格納されます。Domain_dir は Oracle WebLogic Communication Services ドメインのルート ディレクトリです。

A.2 sipserver.xml の編集

通常の運用時に sipserver.xml ファイルを移動、変更、または削除することは絶対に避けてください。

sipserver.xml ファイルに変更を加えるときは、直接編集せずに、Administration Console を使って間接的に行うようお勧めします。Administration Console を使用すれば、sipserver.xml が確実に有効な XML になります。『コンフィグレーション ガイド』の「WLST (JMX) によるコンテナ プロパティのコンフィグレーション」も参照してください。

しかし場合によっては、問題のあるコンフィグレーションを修正したり、壊れたファイルを修復したり、Oracle WebLogic Communication Services のアップグレード時にカスタム コンフィグレーションを多数のマシンに展開するために、sipserver.xml を手動で表示または編集しなければならないことがあります。sipserver.xml を手動で編集したときは、変更内容を適用するために Oracle WebLogic Communication Services インスタンスを再起動する必要があります。

警告 :
動作中の Oracle Communications Converged Application Server デプロイメントに変更を行うときは、必ず Administration Console の SipServer ノードまたは WLST ユーティリティを使用してください。

A.2.1 sipserver.xml を編集する際の手順

プロダクション システムの sipserver.xml に変更を加える必要がある場合は、以下の手順に従ってください。

1. テキスト エディタで DOMAIN_DIR/config/custom/sipserver.xml ファイルを開きます。ただし、DOMAIN_DIR は Oracle WebLogic Communication Services ドメインのルート ディレクトリを表します。

2. sipserver.xml ファイルに対して必要な変更を行います。XML 要素の詳細については、節 A.3「XML スキーマ」を参照してください。

3. 変更を保存し、テキスト エディタを終了します。

4. サーバを再起動して、変更内容を有効にします。

警告 :
動作中の Oracle Communications Converged Application Server デプロイメントに変更を行うときは、必ず Administration Console の SipServer ノードまたは WLST ユーティリティを使用してください。

5. 更新後のシステムをテストして、コンフィグレーションを検証します。

A.3 XML スキーマ

sipserver.xml、wcp-sipserver.xsd のスキーマ ファイルは、wlss-descriptor-binding.jar ライブラリの中にもインストールされ、WLSS_HOME/server/lib/wlss ディレクトリ に置かれます。

A.4 sipserver.xml ファイルの例

単純な sipserver.xml ファイルの例を以下に示します。

<?xml version="1.0" encoding="UTF-8"?>
<sip-server xmlns="http://www.bea.com/ns/wlcp/wlss/300">
<overload>
<threshold-policy>queue-length</threshold-policy>
<threshold-value>200</threshold-value>
<release-value>150</release-value>
</overload>
</sip-server>

A.5 XML 要素の説明

以下の節では、sipserver.xml コンフィグレーション ファイルの中で使われる各要素について説明します。それぞれの節で、図 A-0 に示したメイン sip-server 要素内に含まれる各 XML 要素について説明します。

A.5.1 enable-timer-affinity

enable-timer-affinity 要素は、エンジン層サーバが期限切れタイマーを処理する方法について決定します。デフォルトでは (enable-timer-affinity を sipserver.xml から省略した場合、または「false」に設定した場合)、SIP データ層で期限切れタイマーをポーリングするエンジン層サーバはすべての有効な期限切れタイマーを処理します。enable-timer-affinity を「true」に設定した場合、 SIP データ層をポーリングするエンジン層サーバは、エンジンが最後に変更した呼状態に関連付けられた期限切れタイマー (またはオーナーを持たない呼状態の期限切れタイマー) のみを処理します。

A.5.2 overload

overload 要素を使用すると、コンフィグレーションしたオーバーロード条件に従って SIP リクエストの受信を規制することができます。オーバーロード条件が発生すると、Oracle WebLogic Communication Services は新しい SIP リクエストを破棄し、「503 Service Unavailable」で応答します。この処置は、コンフィグレーションされたリリース値が実際に測定されるか、サーバの容量制限が減少されるまで行われます (「節 A.5.2.3「容量制限に基づくオーバーロード制御」を参照してください)。

ユーザのコンフィグレーションによるオーバーロード制御が適用されるのは、初期 SIP リクエストだけです。オーバーロード条件が発生したときに既にアクティブになっていた SIP ダイアログは、規制されない SIP リクエストをさらに生成することがあります。

オーバーロード制御をコンフィグレーションするには、表 A-1 で説明する 3 つの要素を定義します。

表 A-1 ネストされた overload 要素

要素

説明

threshold-policy

オーバーロード条件のモニタに使われる測定のタイプを指定する文字列値。

- session-rate では、新しい SIP リクエストが生成されるレートが測定されます。Oracle WebLogic Communication Services は、直前の 5 秒間に作成された新しい SIP アプリケーション接続の数を計算してセッション レートを求めます。節 A.5.2.2「セッション生成レートに基づくオーバーロード制御」を参照してください。

- queue-length では、SIP リクエストと SIP タイマーを処理する容量制限ワーク マネージャ コンポーネントのサイズの合計が測定されます。節 A.5.2.3「容量制限に基づくオーバーロード制御」を参照してください。

- 注意 : 実行キューは非推奨になりました、Oracle WebLogic Communication Services では使用されません。容量制限は、実行キューの代わりに使用できます。ポリシー名「queue-length」は、下位互換性のために保管します。

上記のポリシーのどちらか一方を使ってオーバーロード制御を定義する。詳細については、節 A.5.2.1「適切なオーバーロード ポリシーの選択」を参照してください。

threshold-value

Oracle WebLogic Communication Services にオーバーロード条件および新しい SIP リクエストの規制を開始させる測定値を指定します。

- しきい値ポリシーとして session-rate を使用する場合は、オーバーロード条件をトリガする 1 秒あたりの新しい SIP リクエストの数を threshold-value で指定します。節 A.5.2.2「セッション生成レートに基づくオーバーロード制御」を参照してください。

- しきい値ポリシーとして queue-length を使用する場合は、オーバーロード条件をトリガする SIP 転送と SIP タイマーのためのリクウェストの数の合計の長さを threshold-value で指定します。節 A.5.2.3「容量制限に基づくオーバーロード制御」を参照してください。

- threshold-value を観察した後で、Oracle WebLogic Communication Services は、新しい SIP リクエストが抑制する時間に最小 512 ミリ秒のオーバーロード条件を認識します。短時間に複数のオーバーロードを発生すると、512 ミリ秒の最小オーバーロードは、反復オーバーロードを回避するために動的に増加します。

- 最小オーバーロード認識時間が満了した後、オーバーロード条件はコンフィグレーションされた release-value を観察した後終了しました。

release-value

Oracle WebLogic Communication Services にオーバーロード条件および新しい SIP リクエストの規制を「停止」させる測定値を指定します。

- しきい値ポリシーとして session-rate を使用する場合は、セッション規制を終了させる 1 秒あたりの新しい SIP リクエストの数を release-value で指定します。節 A.5.2.2「セッション生成レートに基づくオーバーロード制御」を参照してください。

- しきい値ポリシーとして queue-length を使用する場合は、セッション規制を終了させる容量制限のリクエスト数の合計を release-value で指定します。節 A.5.2.3「容量制限に基づくオーバーロード制御」を参照してください。

A.5.2.1 適切なオーバーロード ポリシーの選択

SIP リクエストを規制するためのポリシーは 2 種類あります。

- session-rate ポリシーは、新しい SIP セッションがコンフィグレーションされたレート (1 秒あたりのセッション数) に達したときセッションを規制します。

- queue-length ポリシーは、wlss.connect ワーク マネージャと wlss.timer.capacity 容量制限コンポーネントの合計サイズがコンフィグレーションされたサイズに達した後、リクエストを規制します。

利用可能なオーバーロード ポリシーは 1 つしか選択できません。同時に両方のポリシーを使用することはできません。

既知の最大スループット (RDBMS など) を持つバックエンド リソースが SIP コールの設定に使用されている場合は、session-rate ポリシーが―般的に利用されている。この場合は、session-rate ポリシーを使用すると、バックエンド リソースの既知のスループット機能に Oracle WebLogic Communication Services オーバーロード ポリシーを関連付けることができる。

queue-length ポリシーでは、Oracle WebLogic Communication Services はオーバーロード状態を診断するため CPU と I/O ボトルネックの両方をモニタする。queue-length ポリシーは、一般的にコール レートに関連した予測される上側へのバインドを持たないシステム内で CPU 集中 SIP アプリケーションと共に使用される。

以下、これらのポリシーについて詳しく説明します。

A.5.2.2セッション生成レートに基づくオーバーロード制御

Oracle WebLogic Communication Services は、直前の 5 秒間に作成されたアプリケーション セッションの数をモニタすることで、セッション生成レート (1 秒あたりのセッション数) を計算します。セッション生成レートが threshold-value で指定されたレートを超えると、Oracle WebLogic Communication Services は初期 SIP リクエストを規制し、セッション生成レートが release-value で指定された値より小さくなるまでこの規制を続けます。

次の例では、50 セッション/秒 を超えるレートで新しいセッションが作成されたとき Oracle WebLogic Communication Services が SIP リクエストの規制を開始するように設定しています。この規制はセッション生成レートが 40 セッション/秒まで低下したときに終了します。

<overload>
<threshold-policy>session-rate</threshold-policy>
<threshold-value>50</threshold-value>
<release-value>40</release-value>
</overload>

A.5.2.3 容量制限に基づくオーバーロード制御

デフォルトでは、SIP メッセージは wlss.connect というワーク マネージャによって処理され、SIP タイマは wlss.timerというワーク マネージャによって処理されます。各ワーク マネージャには、SIP メッセージ処理とタイマ処理のリクエストの数を割り当てる、関連付けられた容量制限コンポーネントがあります。 ワーク マネージャは Oracle WebLogic Communication Services の config.xml ファイルにコンフィグレーションされます。起動オプション -Dweblogic.threadpool.MinPoolSize=number_of_threads を使用して起動時に追加のスレッドはサーバに割り当てる。

Oracle WebLogic Communication Services は、コンフィグレーション容量制限の合計長をモニタすることにより、queue-length オーバーロード制御を行います。この 2 つの制限の合計長が threshold-value 要素で指定された長さを超えると、Oracle WebLogic Communication Services は初期 SIP リクエストを規制し、合計長が release-value で指定された値まで減少するまでこの規制を続けます。

例 A-1 に、sipserver.xml の overload コンフィグレーションを示します。ここでは、制限の合計サイズが 200 リクエストを超える場合は、Oracle WebLogic Communication Services が SIP リクエスト規制を開始します。この規制は同時リクエスト数が 200 以下に戻ったときに終了します。

例 A-1 サンプルのオーバーロード定義

<overload>
<threshold-policy>queue-length</threshold-policy>
<threshold-value>200</threshold-value>
<release-value>150</release-value>
</overload>

A.5.2.4 オーバーロード保護の 2 レベル

ユーザがコンフィグレーションしたオーバーロード制御は (sipserver.xmlに定義されたように) Oracle WebLogic Communication Services で供給されたオーバーロード保護の最初の重大度レベルを示します。ユーザがコンフィグレーションしたオーバーロード制御は、オーバーロード条件の起動をマークし、ドロップされたコールを回避する単純な対策を開始します (新しい要求に対して 503 の応答を生成)。

オーバーロードの原因となった条件が永続化したり悪化した場合は、SIP サーブレット コンテナでワークの実行に使用するワークマ ネージャ コンポーネント自体がオーバーロードとなる可能性があります。この時点でサーバは 503 応答の生成にスレッドの使用をやめ、その代わりにドロップ メッセージを開始します。このように、SIP コンテナのワーク マネージャ コンポーネントのコンフィグレーション サイズは、サーバで使用するオーバーロード保護の 2 番目の最終レベルを示します。

sipserver.xml においてはオーバーロード制御を慎重にコンフィグレーションし、適宜オーバーロードを引き起こした状況を解決します。

A.5.3 message-debug

message-debug 要素は、Oracle WebLogic Communication Services のログ ローテーションを使用してアクセス ロギングを有効化およびコンフィグレーションするために使用されます。 この要素はデプロイメント環境でのみ使用してください。アクセス ロギングでは、すべての SIP リクエストと応答が記録されるからです。

A.5.4 proxy - アウトバウンド プロキシ サーバの設定

RFC 3261 では、アウトバンド プロキシを次のように定義しています。「クライアントからのリクエストを受信するプロキシ。Request-URI で解決されるサーバでなくてもこう呼ぶ。一般に、UA では手動でアウトバンド プロキシがコンフィグレーションされるか、自動コンフィグレーション プロトコルによってアウトバンド プロキシのことを知ることができる。」

Oracle WebLogic Communication Services では、アウトバウンド プロキシ サーバを sipserver.xml 内で proxy 要素を使って指定します。proxy 要素では 1 つまたは複数のプロキシ サーバ URI を定義します。プロキシ プロセスの動作は、proxy-policy タグでプロキシ ポリシーを設定することで変更できます。例 A-0 で proxy 要素に指定可能な値を説明します。

デフォルトの動作は proxy ポリシーが有効であるかのようになっています。 この proxy ポリシーは次のことを意味します。リクエストが、コンフィグレーションされたアウトバウンド プロキシに送られること、そしてリクエスト内のルート ヘッダが Oracle WebLogic Communication Services によってなされたルーティング決定を保持し続けることです。これにより、アウトバウンド プロキシがリクエストに対してアクションを実行した後でリクエストを目的の受信者に届けることが可能になります。proxy ポリシーは初期リクエストに対してのみ実施されます。後続のリクエストについては、ルート セットがダイアログ内のどのポリシーにも優先します (アウトバウンド プロキシがルート セットに入れられることを望む場合は、レコード ルーティングをオンにすることができます)。

また、Oracle WebLogic Communication Services 上で書かれたプロキシ アプリケーションで、アウトバウンド プロキシ通過についてコンフィグレーションされた動作をオーバーライドしたい場合は、「X-BEA-Proxy-Policy」という名前と「domain」という値を持つ特別なヘッダを追加することができます。このヘッダは送信中にリクエストから削除されますが、コンフィグレーションされたアウトバウンド プロキシを無視するという効果があります。アプリケーションで X-BEA-Proxy-Policy カスタム ヘッダを使用することにより、コンフィグレーションされたポリシーをリクエストごとに個別にオーバーライドすることができます。このヘッダの有効な値は「domain」または「proxy」です。ただし、ポリシーが「proxy」にオーバーライドされる場合、アウトバウンド プロキシの URI がコンフィグレーションに含まれていなければアウトバウンド プロキシにルーティングすることはできません。

表 A-2 ネストされた proxy 要素

要素

説明

routing-policy

プロキシの動作をコンフィグレーションする省略可能な要素。有効な値は次のとおりです。

- domain - RFC 3261 で定義されているルーティング ルールを使ってメッセージをプロキシします。アウトバウンド プロキシが指定されていても無視します。

- proxy - メッセージをデフォルト プロキシ URI で指定されている下流のプロキシに送ります。複数のプロキシ指定がある場合は、それらのプロキシが指定されている順序で試行されます。ただし、UDP プロキシが試行される場合、後続のプロキシの設定は無視されます。

uri

プロキシ サーバの TCP または UDP URI。proxy 要素として少なくとも 1 つの URI を指定する必要があります。複数 URIs を proxy 要素内の複数 uri 要素に配置します。

例 A-2 に、Oracle WebLogic Communication Services ドメインのデフォルト プロキシ コンフィグレーションを示します。この場合、リクエストは SIP ルーティング ルールに従って作成され、最終的にアウトバウンド プロキシ「sipoutbound.oracle.com」に送られます。

例 A-2 サンプルの proxy 定義

<proxy>
<routing-policy>proxy</routing-policy>
<uri>sip:sipoutbound.oracle.com:5060</uri>
<!-- Other proxy uri tags can be added. - >
</proxy>

A.5.5 t1-timeout-interval

この要素は SIP プロトコル T1 タイマーの値 (ミリ秒単位) を設定します。タイマー T1 はタイマー A、E、および G の初期値も指定します。これらのタイマーによって UDP による INVITE リクエストと応答の再送信の間隔が決定されます。

タイマー T1 はタイマー F、H、および J の値にも影響を与えます。これらのタイマーによって INVITE 応答とリクエストの再送信の間隔が決定されます。これらのタイマーの値は 64*T1 ミリ秒に設定されます。SIP タイマーの詳細については、「SIP: Session Initiation Protocol」を参照してください。

t1-timeout-interval をコンフィグレーションしないと、Oracle WebLogic Communication Services は SIP プロトコルのデフォルト値である 500 ミリ秒を使用します。

A.5.6 t2-timeout-interval

この要素は SIP プロトコル T2 タイマーの値 (ミリ秒単位) を設定します。タイマー T2 は INVITE 応答と非 INVITE リクエストの再送信間隔を指定するものです。SIP タイマーの詳細については、「SIP: Session Initiation Protocol」を参照してください。

t2-timeout-interval をコンフィグレーションしないと、Oracle WebLogic Communication Services は SIP プロトコルのデフォルト値である 4 秒を使用します。

A.5.7 t4-timeout-interval

この要素は SIP プロトコル T4 タイマーの値 (ミリ秒単位) を設定します。タイマー T4 はメッセージがネットワーク内に存続できる時間の上限を指定するものです。タイマー T4 はタイマー I および K の初期値も指定します。これらのタイマーによって UDP による ACK と応答の再送信までの待ち時間が決定されます。

t4-timeout-interval をコンフィグレーションしないと、Oracle WebLogic Communication Services は SIP プロトコルのデフォルト値である 5 秒を使用します。

A.5.8 timer-b-timeout-interval

この要素は SIP プロトコル タイマー B の値 (ミリ秒単位) を設定します。タイマー B はクライアント トランザクションがリクエストの送信を再試行する時間の長さを指定するものです。

timer-b-timeout-interval をコンフィグレーションしないと、タイマー B の値はタイマー T1 から導き出されます (64*T1、デフォルトでは 32000 ミリ秒)。

A.5.9 timer-f-timeout-interval

この要素は SIP プロトコル タイマー F の値 (ミリ秒単位) を設定します。タイマー F は非 INVITE リクエストを再送信するタイムアウト間隔を指定するものです。

timer-f-timeout-interval をコンフィグレーションしないと、タイマー F の値はタイマー T1 から導き出されます (64*T1、デフォルトでは 32000 ミリ秒)。

A.5.10 max-application-session-lifetime

この要素は、Oracle WebLogic Communication Services によって無効化されるまでの、SIP アプリケーション セッションが存続できる時間 (分単位) の上限を設定します。max-application-session-lifetime は、sip.xml ファイル内の session-timeout 要素または setExpires API を使用して指定した任意のタイムアウト値の上側へのバインドとして機能します。

-1 (デフォルト) は、コンフィグレーションしたタイムアウト値に対する上側へのバインドが存在しないことを示します。

A.5.11 enable-local-dispatch

enable-local-dispatch は、メッセージの送信と転送での不必要なネットワーク トラフィックを避けるのに役立つサーバ最適化です。この要素を設定すると、最適化を有効化できます。enable-local-dispatch を有効にした場合、サーバ インスタンスがメッセージを送信または転送する必要があって、メッセージの宛先がエンジン層のクラスタ アドレスかローカル サーバ アドレスであれば、メッセージはネットワーク経由で送られるのではなく、内部的にローカル サーバにルーティングされます。この最適化を使用すると、チェーン化されたアプリケーションが同じリクエストを処理する際のパフォーマンスが大幅に向上します。

内部メッセージのルーティングがエンジン層のサーバの負荷を歪めるような気がして、コンフィグレーションされたロード バランサを通じてすべてのリクエストをルーティングしたいと思うなら、この最適化を無効にするほうがよいでしょう。

enable-local-dispatch のデフォルト設定は「false」です。

A.5.12 cluster-loadbalancer-map

cluster-loadbalancer-map 要素は、Oracle WebLogic Communication Services ソフトウェアをアップグレードするか、プロダクション SIP サーブレットを新しいバージョンにアップグレードするときにだけ使用します。サーバの通常の運用時には使用しません。

ソフトウェアのアップグレード時には、ソフトウェアの古いバージョンと新しいバージョンをホストするために複数のエンジン層クラスタを定義します。 cluster-loadbalancer-map は、アップグレード用にコンフィグレーションしたエンジン層クラスタに対応する仮想 IP アドレスを定義します。 Oracle WebLogic Communication Services はこのマッピングを使って、呼び出し状態データとタイマーに対するエンジン層リクエストが間違いなくクラスタの正しい「バージョン」から受信されるようにします。リクエストがソフトウェアの誤ったバージョンから来た場合、cluster-loadbalancer-map エントリが使用され、そのリクエストを正しいクラスタに転送します。

それぞれの cluster-loadbalancer-map エントリには、表 A-1 で説明する 2 つの要素が含まれます。

表 A-3 ネストされた cluster-loadbalancer-map 要素

要素

説明

cluster-name

エンジン層クラスタのコンフィグレーションされた名前。

sip-uri

エンジン層クラスタにマップする内部 SIP URI。これはロード バランサでコンフィグレーションした仮想 IP アドレスに対応します。内部 URI はアップグレード時にリクエストを正しいクラスタ バージョンに転送するために使用されます。

例 A-3 に、アップグレード時に使用されるサンプルの cluster-loadbalancer-map エントリを示します。

例 A-3 サンプルの cluster-loadbalancer-map エントリ

<cluster-loadbalancer-map>
<cluster-name>EngineCluster</cluster-name>
<sip-uri>sip:172.17.0.1:5060</sip-uri>
</cluster-loadbalancer-map>
<cluster-loadbalancer-map>
<cluster-name>EngineCluster2</cluster-name>
<sip-uri>sip:172.17.0.2:5060</sip-uri>
</cluster-loadbalancer-map>

詳細については、『操作ガイド』の「ソフトウェアのアップグレード」を参照してください。

A.5.13 default-behavior

この要素は、受信した SIP リクエストをデプロイ済みの SIP サーブレットに対応付けられない (または対応するアプリケーションが無効化されているかタイムアウトになっている) 場合の Oracle WebLogic Communication Services インスタンスのデフォルト動作を定義します。有効な値は次のとおりです。

- proxy - ステートレス プロキシ サーバとして振る舞います。

- ua - ユーザ エージェントとして振る舞います。

値を指定しなければ、デフォルトとして proxy が使用されます。

ユーザ エージェント (UA) として振る舞うとき、Oracle WebLogic Communication Services が行う SIP リクエストへの応答は次のようになります。

- ACK リクエストは通知なしに破棄されます。

- CANCEL または BYE リクエストは応答コード 481 (トランザクションが存在しない) を受け取ります。

- それ以外のすべてのリクエストは応答コード 500 (内部サーバ エラー) を受け取ります。

ステートレス プロキシとして振る舞う場合、リクエストは自動的にアウトバウンド プロキシ (コンフィグレーションされている場合) に転送されます (節 A.5.4「proxy - アウトバウンド プロキシ サーバの設定」を参照してください)。 プロキシが定義されていないと、Oracle WebLogic Communication Services は、リクエスト URI が SIP サーブレット コンテナの既知のローカル アドレスまたはサーバに対してコンフィグレーションされているロード バランサ アドレスの IP とポート番号に一致しない場合にのみ、指定されたリクエスト URI にプロキシします。これにより、リクエストが絶えず同じサーバにループすることが防止されます。リクエスト URI がローカル コンテナ アドレスまたはロード バランサ アドレスと一致する場合、Oracle WebLogic Communication Services は UA として振る舞います。

A.5.14 default-servlet-name

この要素は、受け取った最初のリクエストがデプロイ済みサーブレットに対応しない場合に呼び出すデフォルト SIP サーブレットの名前を指定します (sip.xml の標準 servlet-mapping 定義を使用します)。default-servlet-name 要素に指定する名前は、デプロイ済みの SIP サーブレットの servlet-name 値と一致する必要があります。次に例を示します。

<default-servlet-name>myServlet</default-servlet-name>

default-servlet-name に定義されている名前がデプロイ済みサーブレットに対応しない場合、または、値が何も指定されていない (デフォルト コンフィグレーションが使用された) 場合、Oracle WebLogic Communication Services では com.bea.wcp.sip.engine.BlankServlet という名前がデフォルト サーブレットとして登録されます。 BlankServlet 名は、default-servlet-name として登録されたデプロイ済みサーブレットがコンテナからアンデプロイされた場合にも使用されます。

BlankServlet の動作は、default-behavior 要素によりコンフィグレーションされます。 デフォルトでは、このサーブレットは対応しないすべてのリクエストをプロキシします。しかし、default-behavior 要素が「ua」モードに設定されている場合、BlankServlet は CANCEL リクエストと BYE リクエストに対して 481 応答を返し、それ以外のすべてのケースでは 500/416 応答を返します。BlankServlet は ACK は返しません。常にアプリケーション セッションを無効にします。

A.5.15 retry-after-value

5xx 応答のためにRetry-Afterヘッダに使用された、秒単位を指定します。この値には、「Retry-After: 18000;時間=3600」または「Retry-After: 120 (私は会議中です)」のようなパラメータまたは理由コードも含めることができます。

この値がコンフィグレーションされていないと Oracle WebLogic Communication Services は デフォルト値の 180 秒を使用します。

A.5.16 sip-security

Oracle WebLogic Communication Services では、認証が行われない 1 つまたは複数の信頼性のあるホストをコンフィグレーションすることができます。 Oracle WebLogic Communication Services は SIP メッセージを受け取ると、SIP サーブレット メッセージに対して getRemoteAddress() を呼び出します。 このアドレスがサーバの信頼性のあるホストのリストで定義されているアドレスと一致する場合は、メッセージに対してそれ以上認証は行われません。

sip-security 要素は、認証が行われない 1 つまたは複数の信頼性のあるホストを定義します。sip-security 要素には 1 つまたは複数の trusted-authentication-host 要素または trusted-charging-host 要素が含まれ、それぞれの要素には信頼性できるホストの定義が含まれます。信頼性のあるホストの定義は ip アドレス (ワイルド カード プレースホルダ有りまたは無し) または DNS 名から成ります。例 A-4 に、サンプル sip-security コンフィグレーションを示します。

例 A-4 信頼できるホストのサンプル コンフィグレーション

<sip-security>
<trusted-authentication-host>myhost1.mycompany.com</trusted-authentication-host>
<trusted-authentication-host>172.*</trusted-authentication-host>
</sip-security>

A.5.17 route-header

3GPP TS 24.229 Version 7.0.0 (http://www.3gpp.org/ftp/Specs/archive/24_series/24.229/24229-700.zip) では、新しいリクエストを (B2BUA などとして) 生成する IMS アプリケーション サーバに対して、S-CSCF ルート ヘッダを含めることが要求されています。 Oracle WebLogic Communication Services では、この S-CSCF ルート ヘッダは、sipserver.xml の route-header 要素の値として静的に定義する必要があります。次に例を示します。

<route-header>
<uri>Route: sip:wlss1.bea.com</uri>
</route-header>

A.5.18 engine-call-state-cache-enabled

Oracle WebLogic Communication Services は呼状態データの一部をローカルにキャッシュするオプションをエンジン層サーバに提供し、これを SIP データ層内でも行うことで SIP-aware ロード バランサのパフォーマンスを向上させます。ローカル キャッシュを使用すると、エンジン層サーバは最初に既存の呼状態データのローカル キャッシュをチェックします。キャッシュに必要なデータが含まれており、かつデータのローカルコピーが (SIP データ層コピーと比較して) 最新データの場合、エンジンは SIP データ層の呼状態をロックしますが、直接キャッシュから読み込みます。

デフォルトでは、エンジン層キャッシュは有効です。キャッシュを無効化するには、engine-call-state-cache-enabled を false に設定します。

<engine-call-state-cache-enabled>false</engine-call-state-cache-enabled>

A.5.19 server-header

Oracle WebLogic Communication Services は、サーバ ヘッダが SIP メッセージ に挿入された時に制御可能にします。この機能により、サーバ ヘッダを制限または削除することで、ワイヤレス ネットワークに対するメッセージ サイズを減少したり、セキュリティを増強することができます。

デフォルトでは、Oracle WebLogic Communication Services は、サーバ ヘッダを SIP メッセージに挿入します。server-header に、以下のいずれかの文字列値を設定し動作をコンフィグレーションします。

- none (デフォルト) サーバ ヘッダを挿入しません。

- request は、サーバにより生成された SIP リクエストのためにだけ サーバ ヘッダを挿入します。

- response は、サーバにより生成された SIP 応答のためにだけ サーバ ヘッダを挿入します。

- all は、すべての SIP リクエストと応答に対してサーバ ヘッダを挿入します。

たとえば、以下の要素は、すべての生成された SIP メッセージに対してサーバ ヘッダを挿入するように Oracle WebLogic Communication Services をコンフィグレーションします。

<server-header>all</server-header>

節 A.5.20「server-header-value」も参照してください。

A.5.20 server-header-value

Oracle WebLogic Communication Services は、生成されたメッセージのサーバ ヘッダに挿入された、テキストの制御を有効化します。これは SIP メッセージ サイズやセキュリティ強化のためサーバ エンティティをマスクすることも可能な追加制御を提供します。デフォルトで、Oracle WebLogic Communication Services は、生成された SIP メッセージにサーバ ヘッダを挿入しません (節 A.5.19「server-header」を参照してください)。サーバ ヘッダの挿入が有効化されても server-header-value が指定されないと、Oracle WebLogic Communication Services は「WebLogic SIP Server」という値を入力します。ヘッダ コンテンツをコンフィグレーションするには、String 値を入力します。次に例を示します。

<server-header-value>MyCompany Application Server</server-header-value>

A.5.21 persistence

persistence 要素は、RDBMS もしくはリモートの地理的に冗長な Oracle WebLogic Communication Services のインストールに呼び出し状態の書込みを有効化するか、無効化するかを定義します。地理的に冗長なレプリケーション機能を利用するサイトのために、persistence 要素は、呼状態データが有効化されるサイト ID と URL についても定義します。

persistence 要素には、表 A-1 で説明するサブ要素が含まれます。

表 A-4 ネストされた永続化要素

要素

説明

default-handling

Oracle WebLogic Communication Services が、RDBMS 永続化もしくは地理的な冗長に対する永続化ヒントを監視するかどうかを決定します。この要素は、以下のいずれかの値があります。

- all - 呼状態データが RDBMS ストアと地理的に冗長な Oracle WebLogic Communication Services インストール両方に永続化される可能性を指定します。これはデフォルトの動作です。どちらの送り先へ実際のレプリケーションをする場合も、利用可能なリソース (JDBC データソースと リモート JMS キュー) を準備しておく必要があります。

- db - 必要な JDBC データソースとスキーマが利用可能な場合、存続時間が長い呼状態データが RDBMS にレプリケーションされることを指定します。

- geo - コンフィグレーションされた サイト URL に必要な JMS リソースが含まれてる場合、リモート、地理的に冗長なサイトに対する呼状態データを永続化することを指定します。

- none - SIP データ層クラスタでは他のレプリカに対するインメモリ レプリケーションだけ実行されることを指定します。呼状態データは、RDBMS または外部サイトに対して永続化されません。

geo-site-id

このインストールのサイト ID を指定します。地理的に冗長なレプリケーションに属するすべてのインストールは一意なサイト ID が必要です。

geo-remote-t3-url

このサイトは、呼び出し状態データをレプリケーションするリモート Oracle WebLogic Communication Services インストールを指定します。リモートインストールのエンジン層クラスタに対応する単一 URL を指定することができます。各エンジン層サーバに対応するアドレスのカンマ区切りのリストを指定することもできます。URL には、t3 プロトコルを指定する必要があります。

例 A-5 は、存続時間が長い呼状態および地理的に冗長なレプリケーションのために RDBMS ストレージを使用するコンフィグレーション サンプルを示します。呼状態は、リモートのロケーションにおいて 2 つのエンジン層サーバにレプリケートされます。

例 A-5 サンプル永続コンフィグレーション

<persistence>
<default-handling>all</default-handling>
<geo-site-id>1</geo-site-id>
<geo-remote-t3-url>t3://remoteEngine1:7050,t3://remoteEngine2:7051</geo-remote-t3-url>
</persistence>

A.5.22 use-header-form

この要素は、SIP メッセージにコンパクト ヘッダを使用または保持するためのサーバ全体のデフォルト動作をコンフィグレーションします。この要素は、以下のいずれかの値に設定できます。

- compact - Oracle WebLogic Communication Services は、すべてのシステム生成のヘッダに対してコンパクト フォームを使用します。ただし、送信メッセージからコピーされたヘッダは、(生成のかわりに) 元のフォームを使用します。

- force compact - Oracle WebLogic Communication Services は、すべてのヘッダのためにコンパクト フォームを使用し、必要に応じて、既存のメッセージの長いヘッダからコンパクト ヘッダに変換します。

- long - Oracle WebLogic Communication Services は、すべてのシステム生成のヘッダのために長いフォームを使用します。ただし、送信メッセージからコピーされたヘッダは、(生成のかわりに) 元のフォームを使用します。

- force long - Oracle WebLogic Communication Services は、すべてのヘッダに対して長い フォームを使用し、必要に応じて、既存のメッセージをコンパクト ヘッダから長いヘッダに変換します。

A.5.23 enable-dns-srv-lookup

この要素は、Oracle WebLogic Communication Services DNS ルックアップ機能を有効化または無効化します。要素を「true」に設定した場合、サーバは DNS を使用できます。

- SIP URI にリクエストを送信する場合、プロキシ サーバ転送、IP アドレスとポート番号を検出します。

- [Sent-by] フィールドの内容に基づいて、応答のルーティングの際に IP アドレスとポート番号を解決します。

プロキシ検出のために Oracle WebLogic Communication Services は、SIP トランザクション毎に一度 DNS 解決を使用して転送、IP とポート番号に関する情報を決定します。すべての再送信、ACKs または CANCEL リクエストは同じ転送を使用して同じアドレスとポートに配信されます。DNS 解決をどのように実行するかについての詳細については、「RFC 3263: セッション 開始 プロトコル (SIP): SIP Servers の配置 (http://www.ietf.org/rfc/rfc3263.txt)」を参照してください。

プロキシから応答メッセージを送信する必要がある場合、Oracle WebLogic Communication Services は sent-by フィールドと Via ヘッダで提供された情報によっては送信先の IP アドレスおよびポート番号を決定するため DNS ルックアップを使用する。

デフォルトでは、DNS 解決は使用しません(「false」)。

注意 :
DNS 解決は SIP メッセージ処理のコンテクスト内で実行されるため、どのような DNS パフォーマンス問題でもレイテンシ パフォーマンス増加の原因となります。潜在的なパフォーマンス問題を削減するためにプロダクション環境ではキャッシング DNS サーバを使用することをお勧めします。

A.5.24 connection-reuse-pool

Oracle WebLogic Communication Services には、SBC (Session Border Control) 機能または S-CSCF (Serving Call Session Control Function) との通信オーバーヘッドを最小限に抑える接続プール メカニズムが備わっています。別々のアドレスに複数の固定接続プールをコンフィグレーションできます。

Oracle WebLogic Communication Services は、要求に応じて接続プールから新しい接続を開き、サーバはコンフィグレーションされたアドレスにリクエストをします。サーバは接続の切断と再確立を繰り返す代わりに、既に開いている接続を使用して、新しい SIP リクエストを多重送信します。開いた接続はラウンドロビン方式で再使用されます。開いた接続はリモート アドレスによって明示的に終了されるまで閉じられるまで開いたままです。

接続再使用プールは、コンフィグレーションされたアドレスからの受信リクエストには使用されません。

接続再使用プールをコンフィグレーションするために、表 A-1 の 4 つのネストされた要素を定義します。

表 A-5 ネストされた connection-reuse-pool 要素

要素

説明

pool-name

このプールの名前を識別する文字列値です。すべてのコンフィグレーションされた pool-name 要素はドメインに対して一意である必要があります。

destination

送信先 SBC または S-CSCF の IP アドレスまたはホスト名前を指定します。Oracle WebLogic Communication Services は、コンフィグレーションされたアドレスにリクエストをする場合に限り、このプールに接続を開くか、再使用します。

destination-port

送信先 SBC または S-CSCF のポート番号を指定します。

maximum-connections

このプールで保持する開いた接続の最大数を指定します。

例 A-6 は、2 つのプールがあるコンフィグレーション サンプル connection-reuse-pool を示します。

例 A-6 connection-reuse-pool のサンプル コンフィグレーション

<connection-reuse-pool>
<pool-name>SBCPool</pool-name>
<destination>MySBC</destination>
<destination-port>7070</destination-port>
<maximum-connections>10</maximum-connections>
</connection-reuse-pool>
<connection-reuse-pool>
<pool-name>SCSFPool</pool-name>
<destination>192.168.1.6</destination>
<destination-port>7071</destination-port>
<maximum-connections>10</maximum-connections>
</connection-reuse-pool>

A.5.25 globally-routable-uri

この要素は、ネットワーク要素とコミュニケーションする際に Oracle WebLogic Communication Services が自動的に Contact および Route-Set ヘッダに自動的に挿入される Globally-Routable User Agent URI (GRUU) を指定できるようにします。この要素に指定された URI は、すべての Oracle WebLogic Communication Services クラスタに対する GRUU である必要があります。(単位サーバ ドメンでは、GRUU をサーバ自体のために使用します。)

一般にユーザ エージェント (UAs) は、登録リクエスト経由で GRUUs を入手して Oracle WebLogic Communication Services にデプロイします。この場合、アプリケーション コードは、リクエストとその後に GRUU を処理することの両方を担当します。GRUU をリクエストするため、GRUU を必要とする各 contact の「+sip.instance」contact ヘッダ フィールド パラメータを UA に含めます。GRUU を受信すると、UA は新しいリクエストの生成に際して GRUU を Contact ヘッダ フィールドの URI として使用します。

A.5.26 domain-alias-name

この要素は Oracle WebLogic Communication Services で担当する 1 つ以上のドメインを定義します。メッセージが domain-alias-name 要素で指定するドメインと同じ出力先のドメインを持っている場合、Oracle WebLogic Communication Services はメッセージを転送せずローカル処理をします。

sipserver.xml コンフィグレーション ファイルには、複数の main-alias-name 要素を持つことができます。各要素は以下のどちらも指定することができます。

- myserver.mycompany.com のような独立した完全修飾ドメイン名、および

- *.mycompany.com のようなワイルドカード文字で始まるドメイン名が全体照合ドメインを示すため使用されます。サポートされるのは単一のワイルドカード文字のみで、この文字をドメイン名の最初の要素として使用する必要があります。

注意 :
これらのドメイン名は SipServer Administration console の拡張の [コンフィグレーション｜一般] タブの [ドメイン エリアス] フィールドを使用して識別することができます。

A.5.27 enable-rport

この要素は UAC として動作する場合、Oracle WebLogic Communication Services が自動的に rport パラメータを Via ヘッダに追加するかどうかを決定する。デフォルトでは、サーバは rport パラメータを追加しないため、要素を「true」に設定して rport をサーバで生成されたリクエストに自動的に追加します。

注意 :
SipServer administration コンソールの拡張の [コンフィグレーション｜一般] タブで [対称応答ルーティング オプション] を選択してこのパラメータを「true」に設定することができます。

rport パラメータは対称応答ルーティングに対して使用されます (「RFC 3581」http://www.ietf.org/rfc/rfc3581.txt に説明があります)。 Oracle WebLogic Communication Services などの RFC 3581 対応サーバでメッセージを受信すると、サーバは Via ヘッダで指定されたポート番号ではなく、メッセージを受信したリモート UDP ポート番号を使用して応答します。Network Address Translation (NAT) を行うゲートウェイ機器がサーバ内にある場合、この動作がひんぱんに行われます。NAT 機器は内部ポート番号と外部ポート番号間のバインディングを維持し、通信はすべてゲートウェイ ポートを通じて起動する必要があります。

Oracle WebLogic Communication Services は RFC 3581 に準拠しており、enable-rport の要素を「false」に設定した場合でも rport パラメータを受け付けます。enable-rport 要素は UAC として機能する場合、サーバが自動的に rport を生成するリクエストに追加するかどうかを指定するだけです。rport 処理を完全に (RFC 3581 サポートを無効化) 無効化にするには、コマンドライン オプション -Dwlss.udp.uas.rport=false を使用してサーバを起動しなければなりません。

注意 :
RFC3581 で説明される rport サポートは、元の SIP 要求のソース ポートを含む SIP 応答を必要とします。ソース ポート情報は極秘データとして扱われることが多いので、TLS 転送を使用することをお勧めします。

A.5.28 image-dump-level

この要素は Oracle WebLogic Communication Services 診断イメージファイルで記録する詳細のレベルを指定します。この要素は、以下のいずれかの値に設定できます。

- basic - 呼状態データ以外のすべての診断データを記録します。

- full - 呼状態データを含むすべての診断データを記録します。

注意 :
イメージ ファイルへの呼状態データの記録には、時間がかかることがあります。デフォルトでは、イメージ ダンプ ファイルは basic オプションを使用して記録されます。
SipServer Administration console の拡張の [コンフィグレーション｜一般] タブを使用してこのパラメータを設定することもできます。

A.5.29 stale-session-handling

Oracle WebLogic Communication Services は、エンコード化された URI を使用してメッセージに関連付けられる呼状態およびアプリケーションのセッションを識別します。アプリケーションが新しいバージョンにアンデプロイ、またはアップグレードされた場合、着信リクエストは「古くなった」、または存在しないコールやセッション ID を指定するエンコードされた URI を持っている可能性があります。stale-session-handling 要素を使用すると、Oracle WebLogic Communication Services がリクエストに含まれた古いセッション データを検出した場合、WebLogic SIP Server が取るアクションをコンフィグレーションすることができます。以下のアクションが可能です。

- drop - エラーを記録せずにメッセージをドロップします。この設定は Oracle WebLogic Communication Services のインプレース アップグレード機能を使用してアプリケーションをひんぱんにアップグレードするシステムに適しています。drop - アクションを使用すると、デプロイされたアプリケーションの古い不適合バージョン専用のメッセージが確実にドロップされます。

- error - UAC で問題を解決できるよう、エラーに対応します。これはデフォルトの動作です。To:タグを持つメッセージは、481 Call/Transaction Does Not Exist エラーの原因となり、このタグを持たないメッセージは 404 Not Found エラーを発生させます。

- continue - 古くなったセッションのデータを無視してリクエスト処理を続行します。

注意 :
古くなったセッション データを検出すると、Oracle WebLogic Communication Services は default-behavior 要素の値を考慮する前に stale-session-handling で指定したアクションを適用します。 つまり、continue の動作を行うために stale-session-handling をコンフィグレーションした場合のみ、default-behavior が実行されます。

A.5.30 enable-contact-provisional-response

デフォルトでは、Oracle WebLogic Communication Services は To ヘッダを持つ信頼性のない暫定 (1xx) 応答には Contact ヘッダを設定しません。このような 1xx 形式の応答に Contact ヘッダを必要とするアプリケーションをデプロイする場合は、この要素を以下のように「true」に設定します。

<enable-contact-provisional-response>true</enable-contact-provisional-response>

この要素を true に設定しても、100 回の試行応答には影響しません。

A.5.31 app-router

app-router スタンザは、SIP Servlet v1.1 アプリケーション ルータの動作をコンフィグレーションするいくつかの要素を含めます。節 A.5.32「use-custom-app-router」、節 A.5.33「app-router-config-data」、節 A.5.34「custom-app-router-jar-file-name」および節 A.5.35「default-application-name」を参照してください。

A.5.32 use-custom-app-router

use-custom-app-router 要素は、Oracle WebLogic Communication Services がデフォルトで custom-app-router-jar-file-name 要素で組み込みアプリケーション AR (AR) またはカスタム AR を使用するかどうかを決定します。デフォルト値「false」は、デフォルト AR を使用するためサーバをコンフィグレーションします。

A.5.33 app-router-config-data

app-router-config-data 要素は、init メソッド内で デフォルトまたはカスタム Application Router (AR) を渡すプロパティを定義します。すべてのコンフィグレーション プロパティを Java プロパティ形式に準拠している必要があり、それぞれのプロパティは、スペースや改行をしないで別々の行に入れます。DAR プロパティは、http://jcp.org/en/jsr/detail?id=289 の付録 C で説明される詳細のプロパティ形式を準拠している必要があります。 例 A-7 はコンフィグレーションの例を示します。

例 A-7 サンプル app-router-config-data 要素

<?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:wls="http://www.bea.com/ns/weblogic/90/security/wls" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<app-router>
<use-custom-app-router>false</use-custom-app-router>
<app-router-config-data>INVITE:("OriginatingCallWaiting","DAR:From","ORIGINATING","","NO_ROUTE","0"),("CallForwarding","DAR:To","TERMINATING","","NO_ROUTE","1")
SUBSCRIBE:("CallForwarding","DAR:To","TERMINATING","","NO_ROUTE","1")</app-router-config-data>
<custom-app-router-jar-file-name></custom-app-router-jar-file-name>
<default-application-name></default-application-name>
</app-router>
</sip-server>

Oracle WebLogic Communication Services のインスタンスを起動する場合は、必要に応じて -Djavax.servlet.sip.ar.dar.configuration Java オプションを含めて AR の初期化プロパティを指定できます。 (URI ではなくプロパティ ファイルを指定するには、プリフィックス file:/// を含む) Java 起動オプションを指定した場合、コンテナは、app-router-config-data に定義されたコンフィグレーション プロパティを無視します。プロパティをいつでも変更できますが、-Djavax.servlet.sip.ar.dar.configuration オプションを指定せずにサーバを再起動しないまでにプロパティが AR に渡されません。

A.5.34 custom-app-router-jar-file-name

custom-app-router-jar-file-name 要素は、使用する JAR ファイルとしてパッケジ化されたカスタム Application Router (AR) のファイル名を指定します。カスタム AR 実装は、$DOMAIN_HOME/approuter サブディレクトリに配置する必要があります。

A.5.35 default-application-name

default-application-name 要素は、カスタム アプリケーション ルータ (AR) が初期リクエストを処理するためのアプリケーションが見つからない場合は、コンテナが呼び出す必要のあるデフォルト アプリケーションの名前を指定します。デフォルト アプリケーションを指定しない場合、AR がアプリケーションを選択できない場合、コンテナは 500 エラーを返します。

注意 :
アプリケーション名をデフォルト アプリケーション名の値として指定する前に、アプリケーションをデプロイする必要があります。

B SIP データ層のコンフィグレーション リファレンス

以下の節は、SIP データ層のコンフィグレーション ファイルである datatier.xml の詳細なリファレンスです。

- 節 B.1「datatier.xml の概要」

- 節 B.2「datatier.xml の編集」

- 節 B.3「XML スキーマ」

- 節 B.4「datatier.xml ファイルの例」

- 節 B.5「XML 要素の説明」

B.1 datatier.xml の概要

Datatier.xml コンフィグレーション ファイルでは、SIP アプリケーションの同時呼状態を処理するサーバの指定と、SIP データ層のパーティションへ各サーバを配置する方法の定義を行います。「パーティション」とは、同時呼状態データの同じ部分を管理する、1 つまたは複数の SIP データ層サーバ インスタンスを指します。同じパーティションに属する複数のサーバは、すべて呼状態の同じ部分のコピーを処理するため、「レプリカ」と呼ばれます。

datatier.xml は、DOMAIN_DIR/config/custom サブディレクトリに格納されます。DOMAIN_DIR は Oracle WebLogic Communication Services ドメインのルート ディレクトリです。

B.2 datatier.xml の編集

datatier.xml の編集には、Administration Console かテキスト エディタを使用します。SIP データ層のコンフィグレーションに加えた変更は、サーバに対して動的に適用することはできません。SIP データ層のメンバシップの変更またはパーティションの再コンフィグレーションを行うために、サーバを再起動する必要があります。

B.3 XML スキーマ

WLSS_HOME/server/lib/wlss ディレクトリにインストールされた wcp-sipserver.xsd ライブラリ内にスキーマがバンドルされています。

B.4 datatier.xml ファイルの例

例 B-1 は、コンフィグレーション ウィザードを使用して作成された datatier.xml ファイルのテンプレートです。

例 B-1 デフォルトの datatier.xml ファイル

<st:data-tier xmlns:st="http://www.bea.com/ns/wlcp/wlss/300">
<st:partition>
<st:name>partition-0</st:name>
<st:server-name>replica1</st:server-name>
<st:server-name>replica2</st:server-name>
</st:partition>
</st:data-tier>

B.5 XML 要素の説明

datatier.xml には、1 つまたは複数の partition 要素が含まれており、SIP データ層パーティションのサーバのメンバシップを定義します。すべての SIP データ層クラスタには、少なくとも 1 つの パーティション が必要です。各パーティションには、表 B-0 に示す XML 要素が含まれています。

表 B-1 ネストされたパーティション要素

要素

説明

name

パーティションの名前を識別する文字列値です。管理をしやすくするために、0 始まりのパーティションの番号を名前の一部に含めることをお勧めします。たとえば「partition-0」などです。

server-name

このパーティションで呼び出し状態を管理する Oracle WebLogic Communication Services インスタンスの名前を指定します。partition 要素 1 つにつき、最大 3 つのサーバを定義できます。同一のパーティションに属する複数のサーバは「レプリカ」と呼ばれ、同じ呼状態データを保持します。

管理をしやすくするために、0 始まりのサーバ番号とパーティション番号をサーバ名の一部に含めることをお勧めします。たとえば「replica-0-0」などです。

C Diameter のコンフィグレーション リファレンス

以下の節は、Diameter のコンフィグレーション ファイル diameter.xml の詳細なリファレンスです。

- 節 C.1「diameter.xml の概要」

- 節 C.2「グラフィカルな表示」

- 節 C.3「diameter.xml の編集」

- 節 C.4「XML スキーマ」

- 節 C.5「diameter.xml ファイルの例」

- 節 C.6「XML 要素の説明」

C.1 diameter.xml の概要

diameter.xml ファイルには、以下の Diameter ノード属性が定義されています。

- Diameter ノードのホスト ID

- ノードにデプロイされている Diameter アプリケーション

- Diameter ピアノードの接続情報

- Diameter メッセージの処理に使用されるルーティング情報とデフォルト ルート

Diameter プロトコルの実装は、コンフィグレーション ファイルの起動時に読み出される。datatier.xml は、domain_dir/config/CUSTOM サブディレクトリに格納されます。Domain_dir は Oracle WebLogic Communication Services ドメインのルート ディレクトリです。

C.2 グラフィカルな表示

図 C-1 に diameter.xml ファイルの要素階層を示します。

図 C-1 diameter.xml の要素階層

「図 C-1 diameter.xml の要素階層」の説明

C.3 diameter.xml の編集

通常の運用時に diameter.xml ファイルを移動、変更、または削除することは絶対に避けてください。

diameter.xml ファイルに変更を加えるときは、直接編集せずに、Administration Console を使って間接的に行うようお勧めします。Administration Console を使用すれば、diameter.xml に常に有効な XML になります。

問題のあるコンフィグレーションを修正したり、壊れたファイルを修復したり、Oracle WebLogic Communication Services のアップグレード時にカスタム Diameter ノード コンフィグレーションを多数のマシンに展開するために、diameter.xml を手動で表示または編集する可能性もあります。手動編集の時 diameter.xml、変更を適用するために Diameter ノード をリブートする必要があります。

警告 :
動作中の Oracle WebLogic Communication Services デプロイメントに変更を行うときは、必ず Administration Console の Diameter ノードまたは WLST ユーティリティを使用してください。『コンフィグレーション ガイド』の「エンジン層コンテナのプロパティのコンフィグレーション」を参照してください。

C.3.1 diameter.xml の編集手順

プロダクション システムの sipserver.xml に変更を加える必要がある場合は、以下の手順に従ってください。

1. テキスト エディタで DOMAIN_DIR/config/custom/diameter.xml ファイルを開きます。ただし、DOMAIN_DIR は Oracle WebLogic Communication Services ドメインのルート ディレクトリを表します。

2. diameter.xml ファイルに対して必要な変更を行います。XML 要素の詳細については、節 C.6「XML 要素の説明」を参照してください。

3. 変更を保存し、テキスト エディタを終了します。

4. サーバを再起動して、変更内容を有効にします。

警告 :
動作中の Oracle WebLogic Communication Services デプロイメントに変更を行うときは、必ず Administration Console の Diameter ノードまたは WLST ユーティリティを使用してください。『コンフィグレーション ガイド』の「エンジン層コンテナのプロパティのコンフィグレーション」を参照してください。

5. 更新後のシステムをテストして、コンフィグレーションを検証します。

C.4 XML スキーマ

WLSS_HOME/server/lib/wlss ディレクトリにインストールされた wlss-descriptor-binding.jar ライブラリ内に xml スキーマ (wcp-diameter.xsd) がバンドルされています。

C.5 diameter.xml ファイルの例

サンプル コンフィグレーション ファイル diameter.xml の複数リストについては、『ネットワーク リソースのコンフィグレーション』の「クライアント ノードとリレーエージェントのコンフィグレーション」を参照してください。

C.6 XML 要素の説明

以下の節では、diameter.xml の各 XML 要素について説明します。

C.6.1 configuration

最上位レベルの configuration 要素には、Diameter 全体のコンフィグレーションノードが含まれます。

C.6.2 target

ノード コンフィグレーション適用されたターゲットの Oracle WebLogic Communication Services インスタンスを １ つまたは複数指定します。ドメンの config.xml ファイルにターゲット サーバを定義する必要があります。

C.6.3 host

Diameter ノードのホスト ID を指定します。host 要素が何も指定されていない場合、ローカル サーバのホスト名から ID が取得されます。このホスト ID は DNS 名と同じであっても違っていてもかまいません。

注意 :
複数の sh クライアント ノードを対象に diameter サポートをコンフィグレーションする場合は、diameter.xml ファイルの host 要素を省略することをお勧めします。これにより、同じ Diameter Web アプリケーションをエンジン層クラスタのすべてのサーバにデプロイすることができます。その際、各サーバ インスタンスのホスト名が動的に取得されます。

C.6.4 realm

Diameter ノードに対応するレルム名を指定します。異なるレルムとリスン ポート番号を使用すると、同一ホスト上で複数の Diameter ノードを運用することができます。HSS、アプリケーション サーバ、リレー エージェントはすべて、レルム名または名前が一致している必要があります。HSS とアプリケーション サーバのレルム名は一致していなくてもかまいません。

realm 要素を省略した場合は、完全修飾されたホスト名 (host@oracle.com など) のドメイン名部分から派生したレルム名が作成されます。

C.6.5 address

Diameter ノードのリスン アドレス (DNS 名または IP アドレス) を指定します。アドレスを省略した場合は、このノードでは host ID がリスン アドレスとして使用されます。

注意 :
host ID は Diameter ノードの DNS 名と同じであっても違っていても、どちらでもかまいません。コンフィグレーション エラーを回避するため、address 要素と一緒に DNS 名または IP アドレスを明示的に指定することをお勧めします。

C.6.6 port

Diameter ノードの TCP または TLS リスン ポートを指定します。デフォルト ポートは 3868 です。

C.6.7 tls-enabled

この要素は、TLS 機能を使用するためにスタンドアロン ノード操作だけに使用されます。

サーバ インスタンスに動作中ノードの tls-enabled 要素は Oracle WebLogic Communication Services では無視されます。その代わり、サーバ インスタンスで TLS 対応のネットワーク チャネル (Diameter チャネル) がコンフィグレーションされている場合は、TLS 転送が有効として報告されます。『ネットワーク リソースのコンフィグレーション』の「Diameter プロトコルのネットワーク チャネルの作成」を参照してください。

C.6.8 sctp-enabled

この要素は、SCTP 機能を使用するためにスタンドアロン ノード操作だけに使用されます。

サーバ インスタンスに動作中ノードの sctp-enabled 要素は Oracle WebLogic Communication Services では無視されます。 その代わり、サーバ インスタンスで SCTP 対応のネットワーク チャネル (diameter-sctp チャネル) がコンフィグレーションされている場合は、SCTP 転送が有効として報告されます。『ネットワーク リソースのコンフィグレーション』の「Diameter プロトコルのネットワーク チャネルの作成」を参照してください。

C.6.9 debug-enabled

デバッグ メッセージの出力を有効/無効にする boolean 値を指定します。デフォルトでは、デバッグ メッセージの出力は無効化されています。

C.6.10 message-debug-enabled

Diameter メッセージのトレースを有効/無効にする boolean 値を指定します。デフォルトでは、この要素は無効化されています。

C.6.11 application

選択したノード上で実行する Diameter アプリケーションを指定します。Oracle WebLogic Communication Services には、Diameter Sh、Ro と Rf クライアント、Diameter リレー エージェント、または Home Subscriber Servers (HSS) として動作するノードをサポートする 3 つのアプリケーションが含まれています。HSS アプリケーションは、開発またはテスティングのみを目的として提供されるシミュレータです。

C.6.11.1 class-name

ロードするアプリケーション クラス ファイルを指定します。

C.6.11.2 param*

アプリケーション クラスに渡す任意のパラメータを 1 つまたは複数指定します。

C.6.11.2.1 name

アプリケーション パラメータの名前を指定します。

C.6.11.2.2 value

パラメータ値を指定します。

C.6.12 peer-retry-delay

ノードが Diameter ピアへのアクセスを再試行する間隔を秒単位で指定します。デフォルト値は 30 秒です。

C.6.13 allow-dynamic-peers

ピアの動的なコンフィグレーションを有効または無効にする boolean 値を指定します。デフォルトでは、動的なピアは無効化されています。動的なピアを有効にするのは、TLS 転送を使用する場合のみにする。ピアになるホストを制限するためのアクセス制御メカニズムがないからである。

C.6.14 request-timeout

タイミング アウトの前にピアから応答間隔をミリ秒単位で指定します。.

C.6.15 watchdog-timeout

Diameter Tw watchdog タイマの秒単位を指定します。

C.6.16 supported-vendor-id+

機能交換で Supported-Version-Ids AVP に追加された一つ以上の vendor ID を指定する。

C.6.17 include-origin-state

ノードにリクエストと応答で origin state AVP を含めるかどうか指定します。

C.6.18 peer+

個々の Diameter ピアの接続情報を指定します。ピア ノードごとに接続情報を設定するか、ノードをピアとして動的に追加することを許可するかの、どちらかを選択することができます。ただし、動的なピアを有効にするのは、TLS 転送を使用する場合のみにしてください。なぜなら、動的なピアを有効にすると、ピアになるホストを選別したり制限したりできなくなるからです。

Sh クライアント ノードをコンフィグレーションする場合、peers 要素には、システムにデプロイされている各 Diameter リレー エージェントのピア定義を含める必要があります。システムでリレー エージェントを使用しない場合は、システム内の Home Subscriber Server (HSS) のピア エントリと、Sh クライアント ノードとして動作するその他すべてのエンジン層ノードのピア エントリを含める必要があります。

Diameter リレー エージェント ノードをコンフィグレーションする場合は、HSS の他に、ピアにアクセスするすべての Diameter クライアント ノードのピア エントリを peers 要素に含める必要があります。

C.6.18.1 host

Diameter ピアのホスト ID を指定します。

C.6.18.2 address

Diameter ピアのリスン アドレスを指定します。アドレスを何も指定していない場合、ホスト ID が使用されます。

C.6.18.3 port

Diameter ピアの TCP または TLS ポート番号を指定します。デフォルト ポートは 3868 です。

C.6.18.4 protocol

ピアのプロトコルを指定します。この要素は tcp または sctp の １ つになります。

C.6.19 route

メッセージを解決するためにノードが使用するレルムベースのルートを指定します。

Sh クライアント ノードをコンフィグレーションする場合は、システム内にデプロイされている各 Diameter リレー エージェントへのルートと、選択したリレーへの default-route を指定することをお勧めします。システムでリレー エージェントを使用していない場合は、HSS への default-route を 1 つ指定してください。

Diameter リレー エージェント ノードをコンフィグレーションする場合は、HSS への default-route を 1 つ指定してください。

C.6.19.1 realm

このルートで使用される目的レルムを指定します。

C.6.19.2 application-id

このルートの目的アプリケーション ID を指定します。

C.6.19.3 action

このルートを使用するときの Diameter ノードのロールを説明するアクションの種類を指定します。この要素には次の値のいずれかを指定できます。

- none

- local

- relay

- proxy

- redirect

C.6.19.4 server+

このルートの目的サーバを 1 つまたは複数指定します。server 要素に指定されているサーバは、Diameter ノードの peer として定義されている必要があります。または、動的ピアのサポートが有効化されている必要があります。

C.6.20 default-route

コンフィグレーションされたルートとリクエスト対応しない場合に使用するデフォルト ルートを指定します。

C.6.20.1 action

Diameter ノードのデフォルトのルーティング動作を指定します。節 C.6.19.3「action」を参照してください。

C.6.20.2 server+

デフォルト ルートに対して、1 つまたは複数の対象サーバを指定します。この要素に含めるサーバはいずれも、この Diameter ノードの peer としても定義されている必要があります。または、動的ピアのサポートが有効化されている必要があります。

D 起動コマンド オプション

表 D-1 に、Oracle WebLogic Communication Services とその他の Oracle WebLogic Communication Services ユーティリティで使用できる起動コンフィグレーション オプションを示します。

表 D-1 起動コマンド オプション

アプリケーション

起動オプションのリンク

SIP サーブレット アプリケーション ルータ

-Djavax.servlet.sip.dar.configuration

-Djavax.servlet.sip.ar.spi.SipApplicationRouterProvider

Oracle WebLogic Communication Services

-Dwlss.udp.listen.on.ephemeral

-Dwlss.udp.lb.masquerade

-Dweblogic.management.discover

-Dweblogic.RootDirectory

Oracle WebLogic SIP Server

-Dwlss.udp.listen.on.ephemeral

-Dwlss.udp.lb.masquerade

-Dweblogic.management.discover

-Dweblogic.RootDirectory

-DWLSS.SNMPAgentPort

インストーラ

-Djava.io.tmpdir

WlssEchoServer

-Dwlss.ha.echoserver.port

-Dwlss.ha.echoserver.logfile

-Dreplica.host.monitor.enabled

-Dwlss.ha.heartbeat.interval

-Dwlss.ha.heartbeat.count

-Dwlss.ha.heartbeat.SoTimeout

これらおよびその他のオプションの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server コマンド リファレンス』を参照してください。

E サポート対象のプラットホーム、プロトコル、RFC および標準

以下の節では、Oracle WebLogic Communication Services のさまざまな仕様と RFC への準拠方法について説明します。

- 節 E.1「サポート対象のコンフィグレーション」

- 節 E.2「サポート対象の SIP クライアント」

- 節 E.3「サポート対象のロード バランサ」

- 節 E.4「サポート対象のデータベース」

- 節 E.5「Oracle WebLogic Communication Services の標準アラインメントの概要」

- 節 E.6「Java Sun Recommendation (JSR) の標準への準拠」

- 節 E.7「IETF RFC への準拠」

- 節 E.8「3GPP R6 仕様への適合性」

E.1 サポート対象のコンフィグレーション

Oracle WebLogic Communication Services は、http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html に示すオペレーティング システム、ハードウェア、および JVM の組み合わせでのプロダクションがサポートされます。

注意 :
プロダクション ドメインは Linux および UNIX プラットフォームに対してのみサポートされています。Windows プラットフォームは開発目的にのみサポートされています。

Oracle WebLogic Communication Services には、Oracle WebLogic Server 10g リリース 3 と同様の要件があります。基本的な WebLogic Server 要件に加え、以下の項目が必要です。

- ほとんどのプロダクション デプロイメントでは、エンジン層サーバと SIP データ層サーバの間にギガビット イーサネットを接続する必要があります。

- プロダクション環境でフェイルオーバ機能を提供するには、Dual NIC が必要です。

- 多くのプロダクション インストールのスループット要件をサポートするには、追加 RAM が必要です。

- プロダクション インストールのために互換性のあるロード バランサが必要です。

E.2 サポート対象の SIP クライアント

Oracle WebLogic Communication Services および付属のサンプル アプリケーションでは、以下の SIP ソフトフォンがサポートされます。

- Oracle Communicator (デフォルトのクライアント)

E.3 サポート対象のロード バランサ

Oracle WebLogic Communication Services は以下の環境で動作テストを行っています。F5 Networks, Inc. BIG-IP ロード バランサ、バージョン 9.0.5 ～ 9.2.3 ビルド 34.3

その他のロード バランサ ソリューションのサポートについては、「Oracle Technology Network (http://www.oracle.com/global/index.html)」を参照してください。

E.4 サポート対象のデータベース

Oracle WebLogic Communication Services は長命のセッション データを保存し、地域のサイト全体 （地理的永続性） の呼び出し状態情報をレプリケートするため、以下のデータベースと組み合わせて動作することがテスト済みです。

- Oracle Database 10g (10.2.0.3 またはそれ以上) Oracle Database 11g (11.1.0.6 またはそれ以上)

E.5 Oracle WebLogic Communication Services の標準アラインメントの概要

Oracle WebLogic Communication Services は、Internet Engineering Task Force および 3rd Generation Partnership Project の仕様に特に注意を払って開発されています。機能の開発は、市場の全般的傾向の現状分析と予測に従って優先順位が付けられています。特定の仕様が旧式である場合、またインターネット ドラフトが「Request For Comments (RFC)」基準に従って形式化されている場合、Oracle WebLogic Communication Services はこれらの仕様に準拠することを優先します。仕様が 3GPP のように大きなリリース計画の一部をなす場合、最新のリリース (この場合、リリース 6) への準拠が優先されます。このドキュメントではコンポーネント仕様の後続バージョンへの準拠については説明していませんが、製品はそれらの仕様に準拠しないわけではありません。

E.6 Java Sun Recommendation (JSR) の標準への準拠

Oracle WebLogic Communication Services は、Java EE バージョン 5.0 および対応した Java EE コンポーネント仕様書に準拠しています。

Oracle WebLogic Communication Services は JSR 289:「SIP サーブレット API」で定義されている SIP サーブレット コンテナを追加することで拡張できます。

Oracle WebLogic Communication Services は、関連するすべての Test Compatibility Kits (TCK) を実行済みで、Sun Microsystem が規定した準拠の公式発表に必要な形式要件も満たしています。

E.7 IETF RFC への準拠

以下の表に、一般的な Internet Engineering Task Force (IETF) の Requests for Comment (RFC) とインターネット ドラフトに対する Oracle WebLogic Communication Services の準拠レベルを示します。準拠レベルの意味は次のとおりです。

- 準拠 - Oracle WebLogic Communication Services がその機能や仕様を直接サポートしていることを表します。

- 準拠 (プラットフォーム) - RFC を実装しているアプリケーションやコンポーネントを Oracle WebLogic Communication Services がホストしていることを表します。 ただし、RFC や機能がプロトコルのトランザクション層や SIP Servlet コンテナの動作に影響することはありません。

表 E-2 Oracle WebLogic Communication Services の IETF への準拠

RFC または仕様番号

タイトル

準拠レベル

説明

761

DoD Standard Transmission Control Protocol

準拠

「http://www.ietf.org/rfc/rfc761.txt」を参照してください。

768

User Datagram Protocol

準拠

「http://www.ietf.org/rfc/rfc768.txt」を参照してください。

1157

Simple Network Management Protocol (SNMP)

準拠

Oracle WebLogic Communication Services は、SNMP V2c トラップをサポートしています。 「http://www.ietf.org/rfc/rfc1157.txt」を参照してください。

1847

Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted

準拠 (プラットフォーム)

Oracle WebLogic Communication Services は、署名付きまたは暗号化された MIME オブジェクトを使用または生成するアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc1847.txt」を参照してください。

1901

Introduction to Community-based SNMPv2

準拠

Oracle WebLogic Communication Services は、SNMP V2c トラップをサポートしています。 「http://www.ietf.org/rfc/rfc1901.txt」を参照してください。

1905

Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)

準拠

Oracle WebLogic Communication Services は、SNMP V2c トラップをサポートしています。 「http://www.ietf.org/rfc/rfc1905.txt」を参照してください。

1906

Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)

準拠

Oracle WebLogic Communication Services は、SNMP over TCP と SNMP over UDP の両方をサポートしています「http://www.ietf.org/rfc/rfc1906.txt」を参照してください。

1907

Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)

準拠 (プラットフォーム)

「http://www.ietf.org/rfc/rfc1907.txt」を参照してください。

2183

Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field

準拠 (プラットフォーム)

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc2183.txt」を参照してください。

2246

The TLS Protocol Version 1.0

準拠

Oracle WebLogic Communication Services は TLS をサポートしています。 「http://www.ietf.org/rfc/rfc2246.txt」を参照してください。

2327

SDP: Session Description Protocol

準拠

Oracle WebLogic Communication Services SDP を使用または生成するアプリケーションをサポートしています。 「http://www.ietf.org/rfc/rfc2327.txt」を参照してください。

2460

Internet Protocol, Version 6 (IPv6) Specification

準拠

「http://www.ietf.org/rfc/rfc2460.txt」を参照してください。

2543

SIP: Session Initiation Protocol (v1)

準拠

Oracle WebLogic Communication Services は、この仕様に定義されている下位互換性をサポートしています。「http://www.ietf.org/rfc/rfc2543.txt」を参照してください。

2616

Hypertext Transfer Protocol -- HTTP 1.1

準拠

「http://www.ietf.org/rfc/rfc2616.txt」を参照してください。

2617

HTTP Authentication: Basic and Digest Access Authentication

準拠

「http://www.ietf.org/rfc/rfc2617.txt」を参照してください。

2782

A DNS RR for specifying the location of services (DNS SRV)

準拠

「http://www.ietf.org/rfc/rfc2782.txt」を参照してください。

2806

URLs for Telephone Calls

準拠

「http://www.ietf.org/rfc/rfc2806.txt」を参照してください。

2848

The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services

準拠 (プラットフォーム)

PINT サービスを実装することは、IMS 以前のアーキテクチャであることを意味します。Oracle では 3GPP/TISPAN アーキテクチャとクラス 4/5 Service Emulation のアプローチを推奨し、PINT は推奨しませんが、Oracle WebLogic Communication Services を使用して PINT サービス エレメントを実装することは可能です。 「http://www.ietf.org/rfc/rfc2848.txt」を参照してください。

2916

E.164 number and DNS

準拠

「http://www.ietf.org/rfc/rfc2916.txt」を参照してください。

2960

Stream Control Transmission Protocol

準拠

SCTP は Diameter トラフィックのみをサポートします。「http://www.ietf.org/rfc/rfc2960.txt」を参照してください。

2976

The SIP INFO Method

準拠

「http://www.ietf.org/rfc/rfc2976.txt」を参照してください。

3204

MIME media types for ISUP and QSIG Objects

準拠 (プラットフォーム)

Oracle WebLogic Communication Services は、それ自体が ISUP オブジェクトや QSIG オブジェクトを使用または生成することはありませんが、これらのオブジェクトを使用または生成するアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc3204.txt」を参照してください。

3261

SIP: Session Initiation Protocol

準拠

「http://www.ietf.org/rfc/rfc3261.txt」を参照してください。

3262

Reliability of Provisional Responses in the Session Initiation Protocol (SIP)

準拠

「http://www.ietf.org/rfc/rfc3262.txt」を参照してください。

3263

Session Initiation Protocol (SIP): Locating SIP Servers

準拠

「http://www.ietf.org/rfc/rfc3263.txt」を参照してください。

3264

An Offer/Answer Model with Session Description Protocol (SDP)

準拠 (プラットフォーム)

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc3264.txt」を参照してください。

3265

Session Initiation Protocol (SIP)-Specific Event Notification

準拠

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc3265.txt」を参照してください。

3266

Support for IPv6 in Session Description Protocol (SDP)

Yes

「http://www.ietf.org/rfc/rfc3266.txt」を参照してください。

3268

Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)

準拠 (プラットフォーム)

Oracle WebLogic Communication Services は暗号化サービスをサポートしていますが、一部のアルゴリズムについては、地域によって使用できない場合や、輸出規制の対象となっている場合があります。「http://www.ietf.org/rfc/rfc3268.txt」を参照してください。

3311

The Session Initiation Protocol (SIP) UPDATE Method

準拠

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc3311.txt」を参照してください。

3312

Integration of Resource Management and Session Initiation Protocol (SIP)

準拠 (プラットフォーム)

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc3312.txt」を参照してください。

3313

Private Session Initiation Protocol (SIP) Extensions for Media Authorization

準拠 (プラットフォーム)

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc3313.txt」を参照してください。

3323

A Privacy Mechanism for the Session Initiation Protocol (SIP)

準拠 (プラットフォーム)

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc3323.txt」を参照してください。

3325

Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks

準拠

「http://www.ietf.org/rfc/rfc3325.txt」を参照してください。

3326

The Reason Header Field for the Session Initiation Protocol (SIP)

準拠 (プラットフォーム)

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc3326.txt」を参照してください。

3326

Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts

準拠 (プラットフォーム)

「http://www.ietf.org/rfc/rfc3327.txt」を参照してください。

3351

User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired Individuals

準拠 (プラットフォーム)

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc3351.txt」を参照してください。

3372

Session Initiation Protocol for Telephones (SIP-T): Context and Architectures

準拠 (プラットフォーム)

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc3372.txt」を参照してください。

3388

Grouping of Media Lines in the Session Description Protocol (SDP)

準拠 (プラットフォーム)

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc3388.txt」を参照してください。

3420

Internet Media Type message/sipfrag

「http://www.ietf.org/rfc/rfc3420.txt」を参照してください。

3428

Session Initiation Protocol (SIP) Extension for Instant Messaging

準拠

「http://www.ietf.org/rfc/rfc3428.txt」を参照してください。

3455

Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)

準拠 (プラットフォーム)

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc3455.txt」を参照してください。

3489

STUN-SimpleTraversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)

準拠

「http://www.ietf.org/rfc/rfc3489.txt」を参照してください。

3515

The Session Initiation Protocol (SIP) Refer Method

準拠

「http://www.ietf.org/rfc/rfc3515.txt」を参照してください。

3524

Mapping of Media Streams to Resource Reservation Flows

準拠 (プラットフォーム)

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc3524.txt」を参照してください。

3556

Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth

準拠 (プラットフォーム)

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc3556.txt」を参照してください。

3578

Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP)

準拠 (プラットフォーム)

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしていますが、ISUP インタフェースはサポートしていません。「http://www.ietf.org/rfc/rfc3578.txt」を参照してください。

3581

An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing

準拠

「http://www.ietf.org/rfc/rfc3581.txt」を参照してください。

3589

Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5

準拠

「http://www.ietf.org/rfc/rfc3589.txt」を参照してください。

3588

Diameter Base Protocol

準拠

「http://www.ietf.org/rfc/rfc3588.txt」を参照してください。

3605

Real Time Control Protocol (RTCP) attribute in Session Description Protocol ((SDP)

「http://www.ietf.org/rfc/rfc3605.txt」を参照してください。

3608

Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration.

準拠 (プラットフォーム)

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしていますが、登録中に確立された ServiceRoute を格納する機能はありません。この機能はアプリケーション側で実装することができます。「http://www.ietf.org/rfc/rfc3608.txt」を参照してください。

3665

Session Initiation Protocol (SIP) Basic Call Flow Examples.

準拠

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc3665.txt」を参照してください。

3666

Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows

準拠 (プラットフォーム)

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc3666.txt」を参照してください。

3680

A Session Initiation Protocol (SIP) Event Package for Registrations

準拠 (プラットフォーム)

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc3680.txt」を参照してください。

3689

General Requirements for Emergency Telecommunication Service (ETS)

準拠 (プラットフォーム)

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc3689.txt」を参照してください。

3690

IP Telephony Requirements for Emergency Telecommunication Service (ETS)

準拠 (プラットフォーム)

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc3690.txt」を参照してください。

3702

Authentication, Authorization, and Accounting Requirements for the Session Initiation Protocol (SIP)

準拠

Oracle WebLogic Communication Services version は JDBC と LDAP をサポートしています。 「http://www.ietf.org/rfc/rfc3702.txt」を参照してください。

3725

Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)

準拠

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc3725.txt」を参照してください。

3761

The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)

準拠

「http://www.ietf.org/rfc/rfc3761.txt」を参照してください。

3764

Enumservice Registration for Session Initiation Protocol (SIP) Addresses-of-Record

準拠 (プラットフォーム)

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc3764.txt」を参照してください。

3824

Using E.164 numbers with the Session Initiation Protocol (SIP)

準拠

「http://www.ietf.org/rfc/rfc3824.txt」を参照してください。

3840

Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)

準拠 (プラットフォーム)

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc3840.txt」を参照してください。

3841

Caller Preferences for the Session Initiation Protocol (SIP)

準拠 (プラットフォーム)

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc3841.txt」を参照してください。

3853

S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)

準拠 (プラットフォーム)

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc3853.txt」を参照してください。

3856

Presence Event Package for the Session Initiation Protocol (SIP)

準拠

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc3856.txt」を参照してください。

3857

Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)

準拠

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc3857.txt」を参照してください。

3858

Extensible Markup Language (XML) Based Format for Watcher Information

準拠

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc3858.txt」を参照してください。

3863

Presence Information Data Format (PIDF)

準拠

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc3863.txt」を参照してください。

3891

The Session Initiation Protocol (SIP) "Join" Header

準拠 (プラットフォーム)

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc3891.txt」を参照してください。

3892

The Session Initiation Protocol (SIP) Referred-By Mechanism

準拠 (プラットフォーム)

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc3892.txt」を参照してください。

3893

Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format

準拠 (プラットフォーム)

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc3893.txt」を参照してください。

3903

Session Initiation Protocol (SIP) Extension for Event State Publication

準拠

「http://www.ietf.org/rfc/rfc3903.txt」を参照してください。

3911

The Session Initiation Protocol (SIP) "Join" Header

準拠 (プラットフォーム)

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc3911.txt」を参照してください。

3959

The Early Session Disposition Type for the Session Initiation Protocol (SIP)

「http://www.ietf.org/rfc/rfc3959.txt」を参照してください。

3960

Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)

準拠 (プラットフォーム)

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc3960.txt」を参照してください。

3966

The tel URI for Telephone Numbers

準拠

「http://www.ietf.org/rfc/rfc3966.txt」を参照してください。

4028

Session Timers in the Session Initiation Protocol (SIP)

準拠 (プラットフォーム)

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc4028.txt」を参照してください。

4032

Update to the Session Initiation Protocol (SIP) Preconditions Framework

準拠 (プラットフォーム)

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc4032.txt」を参照してください。

4244

An Extension to the Session Initiation Protocol (SIP) for Request History Information

準拠 (プラットフォーム)

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc4244.txt」を参照してください。

4320

Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction

「http://www.ietf.org/rfc/rfc4320.txt」を参照してください。

4321

Problems Identified Associated with the Session Initiation Protocol's (SIP) Non_INVITE Transaction

「http://www.ietf.org/rfc/rfc4321.txt」を参照してください。

4474

Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)

準拠

「http://www.ietf.org/rfc/rfc4474.txt」を参照してください。

4479

Data Model for Presence

準拠

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc4479.txt」を参照してください。

4480

RPID: Rich Presence Extensions to the Presence Information Data Format

暗黙的にサポートされています。

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc4480.txt」を参照してください。

4481

Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals

暗黙的にサポートされています。

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc4481.txt」を参照してください。

4483

A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages

準拠 (プラットフォーム)

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「http://www.ietf.org/rfc/rfc4483.txt」を参照してください。

4825

The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)

部分的にサポートされています。

部分的なドキュメント操作 (XPath) はサポートされていません

4827

Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents

準拠

draft-ietf-simple-xcap-pidf-manipulation-usage-02 を置換します

draft-levy-sip-diversion-08

Diversion Indication in SIP

準拠 (プラットフォーム)

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=6002」を参照してください。

draft-donovan-mmusic-183-00

SIP 183 Session Progress Message Draft

準拠 (プラットフォーム)

Oracle WebLogic Communication Services は、この仕様に準拠しているアプリケーションをサポートしています。「https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=4308」を参照してください。

draft-ietf-sip-gruu-15

Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)

準拠

「http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-15.txt」を参照してください。

Presence Authorization Rules

draft-ietf-simple-presence-rules-04

準拠

「http://tools.ietf.org/html/draft-ietf-simple-presence-rules-10」を参照してください。

プレゼンス データ モデルに対する OMA 拡張機能

OMA-TS-Presence_SIMPLE-V1_0-20051122-C

準拠

geopriv 共通ポリシーに対する OMA 拡張機能

OMA-TS-XDM_Core-V1_0-20051122-C

準拠

プレゼンス ルールに対する OMA 拡張機能

OMA-TS-Presence_SIMPLE_XDM-V1_0-20051122-C

準拠

E.8 3GPP R6 仕様への適合性

表 E-3 は、Oracle WebLogic Communication Services が適用可能な各 3GPP リリース 6 の仕様で識別されたイネイブラー、またはアプリケーション機能の実装をサポートする機能をまとめたものです。

例外が明記されないかぎり、Oracle WebLogic Communication Services では仕様で説明するアプリケーション サーバ エンティティに関連付けられた基準に準拠するアプリケーションまたは機能の実装に制限を加えることはありません。一部のケースでは、アプリケーションは SIP メソッドまたはヘッダをサポートする必要があります。Oracle WebLogic Communication Services Sip サーブレット コンテナのデフォルトの動作は、通常の SIP サーブレット API 手順を使用して、認識されていないヘッダ、リクエスト メソッドおよびペイロードを SIP サーブレットに渡すことです。

表 E-3 3GPP R6 仕様への適合性

仕様

コメント

3GPP TS 23.228: "IP Multimedia Subsystem (IMS); Stage 2 (Release 6)"

- コメントなし

3GPP TS 24.229: "IP Multimedia Call Control Protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 (Release 6)"

- Oracle WebLogic Communication Services では、sub-section 5.7.1.2 で説明するように、SIP リクエストごとに p-charging-function-address ヘッダ 1 つのみという要件を適用しません。ただし、一意性は適用します。

- Oracle WebLogic Communication Services では、sub-section 5.7.3 で説明される privacy サポートは行いません。

3GPP TS 23.141: "Presence Service; Architecture and Functional description (Release 6)"

- Oracle WebLogic Communication Services では、Ph (MAP)、Pl (LIF-MLP)、Px (DIAMETER Cx/Dx)、Pg (フェーズ 4、3GPP リリース 5)、Pc (CAMEL (フェーズ 4、3GPP リリース 5) または Pr、Pk、Pp (RADIUS) のリファレンス ポイントを本来サポートしません。

- Oracle WebLogic Communication Services は、sub-section 4.3.1 で必要とされる Presence User Agent (Peu) リファレンス ポイントに必要な IPv6 をサポートしません。

3GPP TS 23.218: "IP Multimedia (IM) session handling; IM call model; Stage 2 (Release 6)"

- コメントなし

3GPP TS 24.247 "Messaging using the IP Multimedia (IM) Core Network (CN) subsystem; Stage 3 (Release 6)"

- MSRP リレーは一般的に IMS アーキテクチャにメディア リソース機能として実装されると仮定されますが、Oracle WebLogic Communication Services は Message Session Relay Protocol (MSRP) をサポートしません。

3GPP TS 24.841: "Presence service based on Session Initiation Protocol (SIP); Functional models, information flows and protocol details (Release 6)"

- Oracle WebLogic Communication Services は、IETF RFC 3310: 『Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)』をサポートしません。

3GPP TS 24.109: "Bootstrapping interface (Ub) and Network application function interface (Ua); Protocol details (Release 6)"

- Oracle WebLogic Communication Services は、IETF RFC 3310: 『Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)』をサポートしません。

- Oracle WebLogic Communication Services は、統合セキュリティ フレームワーク内でアクセス制御と認証制約の適用に使用する「X-3GPP-Asserted-Identity 拡張ヘッダ」をサポートします。

3GPP TS 29.328: "IP Multimedia Subsystem (IMS) Sh interface; Signalling flows and message contents"

- コメントなし

3GPP TS 29.329: "Sh interface based on the Diameter protocol; Protocol details"

- コメントなし

3GPP TS 32.299:「電気通信管理、チャージング管理、Diameter チャージング アプリケーション」

- コメントなし

3GPP TS 33.222: "Generic Authentication Architecture (GAA); Access to network application functions using Hypertext Transfer Protocol over Transport Layer Security (HTTPS) (Release 6)"

- Oracle WebLogic Communication Services は、GAA でアプリケーション サーバのロールをサポートしています。

F Oracle WebLogic Communication Services のエクスポート/インポートの使用

以下の節では、Oracle WebLogic Communication Services のエクスポートおよびインポート機能の使用方法について説明します。

- 節 F.1「エクスポート」

- 節 F.2「インポート」

注意 :
このドキュメント内のすべての例では Linux コマンドを使用しています。他のオペレーティング システムの場合は、該当するコマンドを使用してください。

F.1 エクスポート

この節では、OWLCS データのエクスポートに必要な手順を示します。

F.1.1 現在の環境からのデータベース データのエクスポート

注意 :
この手順の最初の 4 つのステップは、RDBMS マシン上で実行します。

Oracle データベース エクスポート ユーティリティのうちのいずれかを使用して、データをエクスポートします。エクスポート コマンドを実行する前に、既存のデータベース マシン上で、エクスポートされたデータのダンプ ファイルとログ ファイルが格納されるディレクトリをファイル システムに作成します。

$ mkdir ~/owlcs_data_pump_dir

1. データベース インストールの $ORACLE_HOME/bin ディレクトリに移動して、以下のコマンドを実行します。 以下のコマンドは、sys ユーザまたは system ユーザとして実行できます。

2. 以下のコマンドを使用して、データベースに DATA_PUMP_DIR を作成します。

- $ ./sqlplus sys@<db_service> as sysdba

- プロンプトで、sys ユーザのパスワードを入力します。

- SQL プロンプトで、以下のコマンドを実行します。

SQL> create or replace directory DATA_PUMP_DIR as '<full_path_to_the_data_pump_dir_created_above>';
SQL> commit;
SQL> quit

3. サブスクライバ データ サービス スキーマのデータをエクスポートします。

- $ ./expdp "'sys@<db_service> as sysdba'" SCHEMAS=<current_prefix>_orasdpsds DIRECTORY=DATA_PUMP_DIR DUMPFILE=<current_prefix>_orasdpsds.dmp LOGFILE=<current_prefix>_orasdpsds.log

- プロンプトで、sys ユーザのパスワードを入力します。

注意 :
上のコマンド ラインの DIRECTORY パラメータの値は、ファイル システム上の実際のディレクトリではなく、DATA_PUMP_DIR として指定する必要があります。コマンドが終了したら、DUMPFILE と LOGFILE にそれぞれ該当する 2 つのファイルが data pump ディレクトリに作成されていることを確認します。

4. XDMS スキーマのデータをエクスポートします。

- $ ./expdp "'sys@<db_service> as sysdba'" SCHEMAS=<current_prefix>_orasdpsds DIRECTORY=DATA_PUMP_DIR DUMPFILE=<current_prefix>_orasdpsds.dmp LOGFILE=<current_prefix>_orasdpsds.log

- プロンプトで、sys ユーザのパスワードを入力します。

注意 :
上のコマンド ラインの DIRECTORY パラメータの値は、ファイル システム上の実際のディレクトリではなく、DATA_PUMP_DIR として指定する必要があります。コマンドが終了したら、DUMPFILE と LOGFILE にそれぞれ該当する 2 つのファイルが data pump ディレクトリに作成されていることを確認します。

クライアントがサーバにサインインしたときにロケーション データが再作成されるため、Location Service スキーマのエクスポートは必要ありません。

5. OWSM ポリシーの移行を完了します。 以下のコマンドを実行して、WLST を開始します。

$ORACLE_HOME/common/bin/wlst.sh.

6. 以下のコマンドを実行して、ローカルの WLS インスタンスに接続します。

wls:/offline> connect('weblogic','weblogic','127.0.0.1:7001')

この例の 'weblogic'/'weblogic' はサンプルの WLS admin ユーザ名/パスワードです。 環境内で実際に使用する値でこれらを置き換えてください。実行中の別の WLS インスタンスがある場合、ポートは変更される場合があります (これは WLS AdminServer ポートです)。

7. 以下の WLST コマンドを実行して、ポリシーとアサーション テンプレートをエクスポートします。 "wlcs_server1" は OWLCS インスタンス名で置き換えます。

wls:/base_domain/serverConfig> exportMetadata(application='wsm-pm',server='wlcs_server1',docs='/assertiontemplates/**',toLocation='/tmp/owsmexport/')
wls:/base_domain/serverConfig> exportMetadata(application='wsm-pm',server='wlcs_server1',docs='/policies/**',toLocation='/tmp/owsmexport/')

8. 以下のコマンドを使用して、WLST コマンド ライン ツールを終了します。

wls:/base_domain/serverConfig> exit()

9. (OWLCS インスタンスがインストールされた [ミドルウェア マシン] であるマシン上で実行します) 次に、「資格ストア」をエクスポートします。OWSM は、クライアント ポリシーのユーザ名およびパスワードの資格と、キーストアのパスワードを資格ストアに格納します。現在のマシンから新しいマシンに <domain>/config/fmwconfig/cwallet.sso をコピーします。 OPSS 移行の一部としてすでに実行している場合は、この手順を省略できます。

10. UMS 関連の詳細を、新しい環境にエクスポートします (UMS を環境にインストールしている場合)。UMS 関連の詳細を、使用する新しい環境にエクスポートします (UMS を環境にインストールしている場合)。現在の環境と新しい環境で User Messaging Service を使用する場合は、以下の手順を実行します。

- 以下のコマンドを実行して、WLST を開始します。

$ORACLE_HOME/common/bin/wlst.sh

注意 :
これはミドルウェア インスタンスの ORACLE_HOME です。 デフォルトは <middleware_home>/as11gr1wlcs1 ディレクトリです。<middleware_home> は OWLCS がインストールされているディレクトリです。

11. 以下の WLST コマンドを実行して、ユーザ メッセージング プリファレンス をバックエンド データベースから指定された xml ファイルにダウンロードします。

wls:/offline> manageUserMessagingPrefs(operation='download', filename='/tmp/userprefs-dump.xml', url='t3://localhost:8001', username='weblogic', password='weblogic')

注意 :
上の例の 'weblogic'/'weblogic' は、サンプルの WLS admin ユーザ名/パスワードの組み合わせです。 環境内で実際に使用する値でこれらを置き換えてください。8001 は UMS が実行している管理対象サーバ ポートです。 必要に応じて、適切な値で置き換えてください。

12. 以下のコマンドを使用して、WLST コマンド ライン ツールを終了します。

wls:/offline> exit()

F.2 インポート

この節では、OWLCS データのインポートに必要な手順を示します。

1. データベースのデータをプロダクション環境にインポートします。 Oracle データベース インポート ユーティリティのいずれかを使用して行います。 インポート コマンドを実行する前に、新しいデータベース マシン上で、データ ダンプ ファイルのインポート先およびログ ファイルの格納先となるディレクトリをファイル システムに作成します。

$ mkdir ~/owlcs_data_pump_dir

2. 古いデータベース マシンの data pump ディレクトリにあるすべての dmp ファイルを上のディレクトリにコピー (ftp またはリモート コピー) します。

3. プロダクション データベース インストールの $ORACLE_HOME/bin ディレクトリに移動して、以下のコマンドを実行します。 以下のコマンドは、sys ユーザまたは system ユーザとして実行できます。

1. 以下のコマンドを使用して、プロダクション データベースに DATA_PUMP_DIR を作成します。

$ ./sqlplus sys@<db_service> as sysdba

プロンプトで、sys ユーザのパスワードを入力します。

SQL プロンプトで、以下のコマンドを実行します。

SQL> create or replace directory DATA_PUMP_DIR as '<full_path_to_the_data_pump_dir_created_above>'
SQL> commit;
SQL> quit

2. 以下のコマンドを使用して、<production_prefix>_orasdpsds スキーマのすべてのシーケンスを削除します。

# $ ./sqlplus sys@<db_service> as sysdba

プロンプトで、sys ユーザのパスワードを入力します。

SQL プロンプトで、以下のコマンドを実行します。

SQL> alter session set current_schema=<production_prefix>_orasdpsds;
SQL> drop sequence ACCOUNT_SEQ;
SQL> drop sequence CREDENTIALS_SEQ;
SQL> drop sequence PRIVATE_IDENTITY_SEQ;
SQL> drop sequence PUBLIC_IDENTITY_SEQ;
SQL> drop sequence REALM_SEQ;
SQL> drop sequence ROLE_SEQ;
SQL> commit;
SQL> quit

3. サブスクライバ データ サービス スキーマにデータをインポートします。

$ ./impdp "'sys@<db_service> as sysdba'" REMAP_SCHEMA=<test_prefix>_orasdpsds:<production_prefix>_orasdpsds TABLE_EXISTS_ACTION=REPLACE DIRECTORY=DATA_PUMP_DIR DUMPFILE=<test_prefix>_orasdpsds.dmp LOGFILE=<production_prefix>_orasdpsds.log

プロンプトで、sys ユーザのパスワードを入力します。

上のコマンド ラインの DIRECTORY パラメータの値は、ファイル システム上の実際のディレクトリではなく、DATA_PUMP_DIR として指定する必要があります。ユーザがすでに存在することを示すエラーは無視します。

4. XDMS スキーマにデータをエクスポートします。

$ ./impdp "'sys@<db_service> as sysdba'" REMAP_SCHEMA=<test_prefix>_orasdpxdms:<production_prefix>_orasdpxdms TABLE_EXISTS_ACTION=REPLACE DIRECTORY=DATA_PUMP_DIR DUMPFILE=<test_prefix>_orasdpxdms.dmp LOGFILE=<production_prefix>_orasdpxdms.log

プロンプトで、sys ユーザのパスワードを入力します。

上のコマンド ラインの DIRECTORY パラメータの値は、ファイル システム上の実際のディレクトリではなく、DATA_PUMP_DIR として指定する必要があります。ユーザがすでに存在することを示すエラーは無視します。

クライアントがサーバにサインインしたときにロケーション データが再作成されるため、Location Service スキーマのインポートは必要ありません。

4. /tmp/owsmexport ディレクトリを新しいマシンにコピーします。

5. 以下のコマンドを実行して、WLST を開始します。

$ORACLE_HOME/common/bin/wlst.sh

6. 以下のコマンドを実行して、ローカルの WLS インスタンスに接続します。

wls:/offline> connect('weblogic','weblogic','127.0.0.1:7001')

注意 :
上の例の 'weblogic'/'weblogic' は、サンプルの WLS admin ユーザ名/パスワードです。 環境内で実際に使用する値でこれらを置き換えてください。実行中の別の WLS インスタンスがある場合、ポートは変更される場合があります (これは WLS AdminServer ポートです)。

7. 以下の WLST コマンドを実行して、ポリシーとアサーション テンプレートを置き換えます。 wlcs_server1 は OWLCS インスタンス名で置き換えます。

wls:/base_domain/serverConfig> deleteMetadata(application='wsm-pm',server='wlcs_server1',docs='/assertiontemplates/**')
wls:/base_domain/serverConfig> deleteMetadata(application='wsm-pm',server='wlcs_server1',docs='/policies/**')
wls:/base_domain/serverConfig> importMetadata(application='wsm-pm',server='wlcs_server1',docs='/assertiontemplates/**',fromLocation='/tmp/owsmexport/')
wls:/base_domain/serverConfig> importMetadata(application='wsm-pm',server='wlcs_server1',docs='/policies/**',fromLocation='/tmp/owsmexport/')

8. 以下のコマンドを使用して、WLST コマンド ライン ツールを終了します。

wls:/base_domain/serverConfig> exit()

注意 :
OWSM キーストアのインポートに関して

- 現在の環境と新しい環境ではプライベート キーが異なります。このため、これらを移行する必要はありません。

- パブリック キー、中間証明書、およびルート証明書は、現在の環境から新しい環境に移行できます。これらを移動するには、java keytool の export および import コマンドを使用します。この操作が完了したら、新しい環境内でサービスを呼び出すクライアントに基づいて、これらの証明書が新しい環境に適用できることを確認してください。

- 新しい環境内でサービスを呼び出すクライアントに基づいて、クライアント証明書、中間 CA 証明書、またはルート CA 証明書の新しいパブリック キーを新しいキーストアに追加する必要があるかどうかを確認してください。

詳細については、『Oracle Fusion Middleware Security and Administrator's Guide for Web Services』を参照してください。

9. 新しいマシンに移動します。

10. 以下のコマンドを実行して、WLST を開始します。

$ORACLE_HOME/common/bin/wlst.sh

11. 以下の WLST コマンドを実行して、User Messaging Preferences をファイルからバックエンド データベースにアップロードします。

wls:/offline> manageUserMessagingPrefs(operation='upload', filename='/tmp/userprefs-dump.xml', url='t3://localhost:8001', username='weblogic', password='weblogic')

注意 :
上の例の 'weblogic'/'weblogic' は、サンプルの WLS admin ユーザ名/パスワードです。 環境内で実際に使用する値でこれらを置き換えてください。8001 は UMS が実行している管理対象サーバ ポートです。 必要に応じて、適切な値で置き換えてください。

12. アップロードが成功したことを示すメッセージを確認します。以下のコマンドを使用して、WLST コマンド ライン ツールを終了します。

wls:/offline> exit()

注意 :
ダウンロードまたはアップロード実行時のさまざまなオプションについては、wls:/offline> プロンプトで help ('manageUserMessagingPrefs') を実行してください。LDAP ストアでプロビジョニングされたユーザ デバイスは動的です。現在の環境と新しい環境が両方とも同じ LDAP ストアをポイントするか、または同じ情報セットを使用するようにコンフィグレーションされることが想定されています。

G スケーラブルな Presence デプロイメントのデプロイ

この節では、Presence、XDMS、および User Dispatcher を必要とする大規模な Presence ソリューションに対して推奨およびサポートされているデプロイメント トポロジについて説明します。複数ノードの観点から、一般的な流れを示します。以下のトピックがあります。

- 節 G.1「Presence クラスタ」

- 節 G.2「XDM クラスタ」

- 節 G.3「Presence ノード」

- 節 G.4「XDM ノード」

- 節 G.5「完全な Presence クラスタおよび XDM クラスタ」

G.1 Presence クラスタ

Presence クラスタは、Presence ノードのセットが 1 つ以上のロード バランサの後に接続されている状態として定義されます。Presence クラスタは、プレゼンス イベント パッケージに対して行われた着信 SUBSCRIBE リクエストと PUBLISH リクエストを処理し、必要に応じて通知を送信します。presence.winfo イベント パッケージに対する SUBSCRIBE リクエストの受信と処理も行います。Presence クラスタは、この作業の完了に必要な情報を取得するために XDM クラスタと対話します。XDM クラスタに問い合わせる情報は、ユーザの presence-rules と pidf-manipulation のドキュメントです。

Presence クラスタは、次の 3 つの異なる層で構成されます。

- load-balancing レイヤは、着信トラフィックを User Dispatcher にディスパッチします。ロード バランサはステートレスであり、SIP をプロトコルとして認識する必要がありません。

- user-dispatching レイヤは、ユーザ情報に基づいてトラフィックをディスパッチします。ユーザは特定の Presence サーバ インスタンスに割り当てられます。そのユーザ宛てのすべてのトラフィックは、同じ Presence サーバ インスタンスにディスパッチされます。各 User Dispatcher がステートレスで、他の User Dispatcher と状態を共有しない場合でも、User Dispatcher は Presence サーバ層を同じ観点で捉える必要があります。

- 下層レイヤは、Presence サーバ インスタンスが存在する場所です。各インスタンスはそれ以外のインスタンスと分けられ、他のインスタンスと状態を共有しません。Presence サーバ層の目的は、プレゼンス イベント パッケージ宛ての着信 SUBSCRIBE リクエストおよび PUBLISH リクエストを処理し、presence.winfo イベント パッケージに対するサブスクリプションを処理することです。

Presence クラスタは、次の物理ノードで構成されています。

- ロード バランサ (F5 Networks の BigIP など)

- 次のコンポーネントで構成される Presence ノード

- User Dispatcher

- Presence サーバ

G.2 XDM クラスタ

XDM クラスタは、XDM ノードのセットが 1 つ以上のロード バランサの後に接続されている状態として定義されます。XDM クラスタは、XDM 関連のすべてのトラフィック、つまり ua-profile イベント パッケージに対する SIP SUBSCRIBE トラフィックと、XCAP トラフィックを処理します。同様に、XDM 文書の操作に関連があるすべてのトラフィックを処理します。XDM クラスタは、XDM 文書の実際の記憶域のデータベースを使用しますが、データベース (場合によってはそのクラスタ) が XDM クラスタの一部ではない点に注意してください。

XDM クラスタは、次のレイヤで構成されます。

- load-balancing 層 - SIP トラフィックと XCAP トラフィックの両方を次のレイヤにディスパッチします。XCAP トラフィックの場合、次の層は Aggregation Proxy ですが、SIP の場合、トラフィックは User Dispatcher レイヤに直接移動します。

- Aggregation Proxy レイヤ - 着信トラフィックを認証します。認証が成功するとすぐに、リクエストを User Dispatcher レイヤに転送します。外部ネットワークからの XCAP トラフィック (XDM クラスタの外部らのトラフィックなど) はすべて、Aggregation Proxy レイヤを通過します。内部トラフィックは Aggregation Proxy を通過せず、User Dispatcher に直接移動します。

- User Dispatcher レイヤ - SIP の観点では、Presence クラスタ内と厳密に同じ作業を実行し、同様に機能します (結局は同じ種類のトラフィックになります)。XDM クラスタと Presence クラスタを比較した場合の主な違いは、XDM クラスタでは User Dispatcher が XCAP トラフィックも処理する必要がある点です。ただし、XCAP トラフィックは SIP と厳密に同じ方法で処理されます。XCAP トラフィックに対する User Dispatcher の目的は SIP の場合と同じです。つまり、リクエストに基づいてユーザ情報を抽出してから、その情報を正しい XDMS インスタンスにディスパッチします。

- XDM サーバ レイヤには、Presence クラスタの Presence サーバと同じ機能があります。XDMS インスタンスは、イベント パッケージ ua-profile に対する着信 SUBSCRIBE リクエストを処理し、登録されているすべてのサブスクライバに NOTIFY メッセージを適宜送信します。XDMS は PUBLISH リクエストを受け入れない点に注意してください。XCAP 操作により、リソース (XML 文書) の状態を更新します。XDM クライアントは、適切な XCAP 操作を発行することにより、XDMS で管理する文書を操作できます。XCAP 操作が成功すると、文書の内容が変更される場合があります。その場合、XDMS はその文書のすべてのサブスクライバに NOTIFY メッセージを送信して変更を知らせます。XDMS が XML 文書を取得する必要がある場合は、常に次のレイヤ (データベース レイヤ) に問い合わせを行います。

- データベース層は、XDMS で管理する XML 文書を物理的に格納します。この層では、データベース レイヤのいずれかのノードに障害が発生した場合でも、データやサービスが失われることなく、そのノード上に存在するドキュメントに XDMS から引き続きアクセスできるように高可用性とスケーラビリティが保証されます。

XDM クラスタは、次の物理ノードで構成されます。

- ロード バランサ (F5 Networks の Big IP など)

- 次のコンポーネントで構成される XDM ノード

- Aggregation Proxy

- User Dispatcher

- XDM サーバ (XDMS)

- データベース

G.3 Presence ノード

Presence クラスタの主要コンポーネントである Presence ノードは、着信トラフィックを適切な Presence サーバにディスパッチし、プレゼンス情報によるユーザへのサービスを提供します。User Dispatcher は、単一ノード デプロイメントでも複数ノード デプロイメントでも同じ役割を果たします。つまり、その目的は特定の Presence サーバ インスタンスに着信トラフィックをディスパッチすることです。ディスパッチ先の Presence サーバ インスタンスが User Dispatcher と同じ物理ノード上にあるかどうかは、User Dispatcher にとって重要ではありません。

Presence ノードには、ノード自体への入り口として機能する User Dispatcher が常にデプロイされます。通常、User Dispatcher はポート 5060 でリスニングし、そのノード上の Presence サーバは他のポートでリスニングします。この方法では、単一ノードはクライアントに対して 1 つの Presence サーバのように見えますが、実際は User Dispatcher の後ろで複数のインスタンスが実行されています。Presence ノードにデプロイされている各コンポーネントは、各自の Java 仮想マシンで実行されています。つまり、User Dispatcher と Presence サーバ インスタンスは、それぞれの OWLCS コンテナおよび SIP コンテナで実行されます。これは、そのマシン上の使用可能なメモリをすべて利用できるようにするためです。

G.4 XDM ノード

XDM ノードには、XCAP トラフィックの場合に通常ポート 80 でリスニングする Aggregation Proxy が必ずデプロイされます。Aggregation Proxy は着信トラフィックを認証します。認証が成功するとすぐに、リクエストを User Dispatcher に転送します。Presence ノードと同様に、XDM ノードにも User Dispatcher がデプロイされます (通常のポートは5060)。SIP トラフィックの場合、XDM ノードと Presence ノードとの間に違いはありません。2 種類のノード間の違いは、User Dispatcher が XCAP トラフィックもディスパッチする点です。SIP と同様に、User Dispatcher はユーザ ID をリクエストから抽出し、それに基づいて転送先の特定の XDMS インスタンスにリクエストをマップします。

User Dispatcher が SIP トラフィックと XCAP トラフィックの両方をディスパッチする宛先として、数多くの XDMS インスタンスがデプロイされます。Presence ノード上の Presence サーバ インスタンスの場合と同じように、各 XDMS インスタンスは他のインスタンスを認識することなく、個別に実行されます。

G.5 完全な Presence クラスタおよび XDM クラスタ

図 G-1 に、必要なすべてのコンポーネントを備えた完全な Presence クラスタと XDM クラスタを示します。この図では、2 つのクラスタ (Presence および XDM) が 2 つの別々のクラスタとして扱われ、最初のトラフィックがその 2 つのネットワークに入るには、必ず各自のロード バランサを経由します。サブスクリプションを設定する際に、Presence サーバも XDM クラスタのロード バランサを実際に通過します。ただし、一度サブスクリプションが確立されると、その後のリクエストはロード バランサを通過せず、サブスクリプションをホストする XDMS インスタンスに直接移動します。XDM クラスタのすべてのノードには、Presence クラスタから直接アクセスできます。

図 G-1 Presence ノードおよび XDM ノード

「図 G-1 Presence ノードおよび XDM ノード」の説明

索引

A  B  C  D  E  G  H  I  J  L  M  N  O  P  S  T  U  W  X

A

Administration Console、2.3.1

コンテナ プロパティのコンフィグレーション、3.2

Administration Server

ベスト プラクティス、2.5

Aggregation Proxy、9.2.10、16.3.1.5.7

XCAP トラフィックの認証、9.2.10

オールインワン管理対象サーバ、16.2 認証プロバイダ、5.1.1

B

Bus MBean、9.2.2

C

チャネル

SIP と SIPS、4.4.2

TCP と TLS、4.5

Client-Cert 認証、5.8 Command Service (XDMS プロビジョニング)、9.2.8 コンフィグレーション

ロックと永続化、3.2.1

コンフィグレーション ロック、管理、3.3 コンフィグレーション

単一の NIC、4.8.1

カスタム チャネル

プロパティ、4.4.3

D

datatier.xml、6.1.1

デフォルト アプリケーション ルータ (DAR)、2.2

デプロイ済み SIP Servlets

アップグレード、 17

デプロイメント トポロジ、16.2, 16.3.1 デプロイメント トポロジ、16 Diameter

コンフィグレーション、2.2.1

Diameter

コンフィグレーション、C

ドメイン、10.3

ノードおよびリレー、10

Diameter アプリケーション

コンフィグレーション、10.6.2

Diameter コンソール、10.4 Diameter ノード

コンフィグレーション、10.6

Diameter、リソース、2.2 ダイジェスト認証、5.7.4

コンフィグレーション、5.7

DNS

サポート、4.3

DNS 名、4.1 ドライバ

デプロイ

Oracle User Messaging Service、13.1

E

エンジン層、15.3

エンタープライズ デプロイメント、4.8、16.3

エクスポートとインポート

Oracle WebLogic Communication Services (OWLCS)、F

G

地理的冗長性、6.5

H

高可用性、16.2、16.3.1

HTTP サーブレット

コンフィグレーション、5.11

I

ID アサーション サポート、5.3

IP_ANY、4.6

IPv4、4.1.1

IPv6、4.1.1

J

JMX、3.3

JMX-compliant MBeans、2.3.3.2

jrockit、8.8.4

L

LDAP

組み込み、5.7.5

LDAP 管理、5.7.3 リスン アドレス、4.1 リスン ポート、4.1 ロード バランサ、15.2

SIP 対応、2.2

ロード バランサ

コンフィグレーション、4.2、4.8.5

マルチホーム、4.2.1

ログ レベル、設定、2.3.3.2.1 ロギング

Sash でのエラー ロギング、7.5.1

M

MBean

通信サービス、3.3.2

MBeans

作成と削除、3.4.2

MessagingWebServiceConfig、9.3.3

N

NAT (Network Address Translation、4.8.5.3

ネットワーク リソース

管理、4

NTP

コンフィグレーション、3.5.2

O

Oracle Internet Directory (OID)、5.12

コンフィグレーション、5.12.1

Oracle User Messaging Service (UMS)

コンフィグレーション、11

管理、13

モニタ、12

Oracle WebLogic Communication Services (OWLCS)

アーキテクチャ、15

一般的なコンフィグレーション タスク、2.6

一般的なセキュリティ コンフィグレーション タスク、5.5

コンフィグレーション、4.8.5.3

Presence のコンフィグレーション、9

デプロイメント トポロジ、16

エクスポートとインポート、F

概要、1

概要、1.1

プレゼンス サービス、1.1.3

セキュリティ、5

共有のコンフィグレーション、2

SIP データ層のパーティション、6

Oracle WebLogic Communication Services (OWLCS) カスタム リソース、2.2

P

PackageManager、9.2.3

Parlay X Web Services のアーキテクチャ、18

Presence

コンフィグレーション、9.1

スケーラブルなデプロイメント、G

Presence MBean、9.2.4 Presence サーバ

コンフィグレーション、9.2

Presence Web Services

コンフィグレーション、9.3

PresenceConsumerWebService、9.3.2 PresenceEventPackage、9.2.5 PresenceSupplierWebService、9.3.1 PresenceWInfoEventPackage、9.2.6 Proxy Registrar、14.1、16.3.1.5.3

コンフィグレーション、14.1

S

Sash

コマンドとサブコマンド、7.3

コマンド、7.3.1

外部インスタンスへの接続、7.2.2

ユーザの作成、7.4.1

エラー ロギング、7.5.1

エラー ロギング、7.7

起動、7.2

XDMS のプロビジョニング、7.5

スクリプトの作成、7.6

使用、7.3

ユーティリティ、7

SCTP、10.5.2 セキュリティ イベントの監査、5.5 サーバ

停止と起動、2.4

SIP アプリケーション サーバ、16.3.1.5.1 SIP コンテナ

コンフィグレーション、3

SIP データ層

コンフィグレーション リファレンス、B

SIP データ層、15.4 SIP インフラストラクチャ アプリケーション

コンフィグレーション、14

SIP サーブレット コンテナ

コンフィグレーション リファレンス、A

SIP サーブレット コンテナ、2.2 SIP サーブレット宣言型セキュリティ、5.4 SIP サーブレット ID アサーション、5.9 SIP タイマー、3.5.2 起動

コマンド オプション、D

STUN

STUN サーバのコンフィグレーション、14.2, 14.2

T

Third Party Call Control (TPCC)、1.1.2

サードパーティ製ロード バランサ、16.3.1.5.2

Timer Affinity、3.5.1

タイマー、3.5

トラブルシューティング、8

U

UA-ProfileEventPackage、9.2.7

User Messaging Service (UMS)

メッセージング、1.1.1

ユーザ

一括プロビジョニング、7.6

Sash によるユーザのプロビジョニング、7.4

CommandService MBean によるプロビジョニング、7.4.2

W

WebLogic Scripting Tool (WLST)、2.3.2

WebLogic Server プラットフォーム、1.1.4

WLST

コンフィグレーション、3.4

呼び出し、3.4.1

X

XCapConfigManager、9.2.9

XDMS

コンフィグレーション、9.2.1

Sash によるプロビジョニング、7.5

CommandService MBean によるプロビジョニング、7.5.1

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