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

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

Administration Console の左上部にある [チェンジセンタ] を見つけます。
[ロックして編集] ボタンをクリックして、ドメインのコンフィグレーションの編集階層をロックします。これで Administration Console を使用して変更できるようになります。
Administration Console の該当するページで必要な変更を行います。変更を行う各ページで [保存] をクリックします。
必要な変更がすべて完了したら、[チェンジセンタ] の [変更のアクティブ化] をクリックします。

注意 :

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 ファイルをクラスパスに追加しておく必要があります。次の手順に従います。

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

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

WLST を起動します。
```
java weblogic.WLST
```
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 の有効化 :

ドメインの Administration Console にアクセスします。
[ロックして編集] ボタンをクリックしてコンフィグレーションロックを取得します (開発環境で有効化されている場合)。
左ペインで [SipServer] ノードをクリックします。コンソールの右ペインにある 2 つのレベルのタブ付きページで Oracle WebLogic Communication Services をコンフィグレーションし、モニタします。
右ペインの [コンフィグレーション｜一般] タブを選択します。
[Timer Affinity の有効化] を選択します。
[保存] をクリックしてコンフィグレーションの変更を保存します。

[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 ミリ秒進んでいると、そのサーバが処理する期限切れタイマーの割合が他のエンジン層サーバに比べて高くなり、割り当てられている間隔の半分の時間が経過した時点で再送信が開始されるようになります。また、メッセージのタイムアウトが本来より早い時点で強制的に発生するおそれもあります。

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