| Oracle® WebLogic Communication Services 管理ガイド 11g リリース 1 （11.1.1) B55505-01 |
|
 戻る |
 次へ |
以下の節は、エンジン層のコンフィグレーション ファイル sipserver.xml に関する詳細なリファレンス情報です。
sipserver.xml ファイルはサーバ インストールのエンジン層にある Oracle WebLogic Communication Services インスタンスで供給された SIP コンテナ機能をコンフィグレーションする XML ドキュメントです。sipserver.xml は、domain_dir /config/CUSTOM サブディレクトリに格納されます。Domain_dir は Oracle WebLogic Communication Services ドメインのルート ディレクトリです。
通常の運用時に 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 ユーティリティを使用してください。 |
プロダクション システムの sipserver.xml に変更を加える必要がある場合は、以下の手順に従ってください。
テキスト エディタで DOMAIN_DIR/config/custom/sipserver.xml ファイルを開きます。ただし、DOMAIN_DIR は Oracle WebLogic Communication Services ドメインのルート ディレクトリを表します。
sipserver.xml ファイルに対して必要な変更を行います。XML 要素の詳細については、節 A.3「XML スキーマ」を参照してください。
変更を保存し、テキスト エディタを終了します。
サーバを再起動して、変更内容を有効にします。
|
警告 : 動作中の Oracle Communications Converged Application Server デプロイメントに変更を行うときは、必ず Administration Console の SipServer ノードまたは WLST ユーティリティを使用してください。 |
更新後のシステムをテストして、コンフィグレーションを検証します。
sipserver.xml、wcp-sipserver.xsd のスキーマ ファイルは、wlss-descriptor-binding.jar ライブラリの中にもインストールされ、WLSS_HOME/server/lib/wlss ディレクトリ に置かれます。
単純な 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>
以下の節では、sipserver.xml コンフィグレーション ファイルの中で使われる各要素について説明します。それぞれの節で、図 A-0 に示したメイン sip-server 要素内に含まれる各 XML 要素について説明します。
enable-timer-affinity 要素は、エンジン層サーバが期限切れタイマーを処理する方法について決定します。デフォルトでは (enable-timer-affinity を sipserver.xml から省略した場合、または「false」に設定した場合)、SIP データ層で期限切れタイマーをポーリングするエンジン層サーバはすべての有効な期限切れタイマーを処理します。enable-timer-affinity を「true」に設定した場合、 SIP データ層をポーリングするエンジン層サーバは、エンジンが最後に変更した呼状態に関連付けられた期限切れタイマー (またはオーナーを持たない呼状態の期限切れタイマー) のみを処理します。
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 |
オーバーロード条件のモニタに使われる測定のタイプを指定する文字列値。
上記のポリシーのどちらか一方を使ってオーバーロード制御を定義する。詳細については、節 A.5.2.1「適切なオーバーロード ポリシーの選択」を参照してください。 |
threshold-value |
Oracle WebLogic Communication Services にオーバーロード条件および新しい SIP リクエストの規制を開始させる測定値を指定します。
|
release-value |
Oracle WebLogic Communication Services にオーバーロード条件および新しい SIP リクエストの規制を「停止」させる測定値を指定します。
|
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 アプリケーションと共に使用される。
以下、これらのポリシーについて詳しく説明します。
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>
デフォルトでは、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 以下に戻ったときに終了します。
ユーザがコンフィグレーションしたオーバーロード制御は (sipserver.xmlに定義されたように) Oracle WebLogic Communication Services で供給されたオーバーロード保護の最初の重大度レベルを示します。ユーザがコンフィグレーションしたオーバーロード制御は、オーバーロード条件の起動をマークし、ドロップされたコールを回避する単純な対策を開始します (新しい要求に対して 503 の応答を生成)。
オーバーロードの原因となった条件が永続化したり悪化した場合は、SIP サーブレット コンテナでワークの実行に使用するワークマ ネージャ コンポーネント自体がオーバーロードとなる可能性があります。この時点でサーバは 503 応答の生成にスレッドの使用をやめ、その代わりにドロップ メッセージを開始します。このように、SIP コンテナのワーク マネージャ コンポーネントのコンフィグレーション サイズは、サーバで使用するオーバーロード保護の 2 番目の最終レベルを示します。
sipserver.xml においてはオーバーロード制御を慎重にコンフィグレーションし、適宜オーバーロードを引き起こした状況を解決します。
message-debug 要素は、Oracle WebLogic Communication Services のログ ローテーションを使用してアクセス ロギングを有効化およびコンフィグレーションするために使用されます。 この要素はデプロイメント環境でのみ使用してください。アクセス ロギングでは、すべての SIP リクエストと応答が記録されるからです。
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 |
プロキシの動作をコンフィグレーションする省略可能な要素。有効な値は次のとおりです。
|
uri |
プロキシ サーバの TCP または UDP URI。 |
例 A-2 に、Oracle WebLogic Communication Services ドメインのデフォルト プロキシ コンフィグレーションを示します。この場合、リクエストは SIP ルーティング ルールに従って作成され、最終的にアウトバウンド プロキシ「sipoutbound.oracle.com」に送られます。
この要素は 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 ミリ秒を使用します。
この要素は SIP プロトコル T2 タイマーの値 (ミリ秒単位) を設定します。タイマー T2 は INVITE 応答と非 INVITE リクエストの再送信間隔を指定するものです。SIP タイマーの詳細については、「SIP: Session Initiation Protocol」を参照してください。
t2-timeout-interval をコンフィグレーションしないと、Oracle WebLogic Communication Services は SIP プロトコルのデフォルト値である 4 秒を使用します。
この要素は SIP プロトコル T4 タイマーの値 (ミリ秒単位) を設定します。タイマー T4 はメッセージがネットワーク内に存続できる時間の上限を指定するものです。タイマー T4 はタイマー I および K の初期値も指定します。これらのタイマーによって UDP による ACK と応答の再送信までの待ち時間が決定されます。
t4-timeout-interval をコンフィグレーションしないと、Oracle WebLogic Communication Services は SIP プロトコルのデフォルト値である 5 秒を使用します。
この要素は SIP プロトコル タイマー B の値 (ミリ秒単位) を設定します。タイマー B はクライアント トランザクションがリクエストの送信を再試行する時間の長さを指定するものです。
timer-b-timeout-interval をコンフィグレーションしないと、タイマー B の値はタイマー T1 から導き出されます (64*T1、デフォルトでは 32000 ミリ秒)。
この要素は SIP プロトコル タイマー F の値 (ミリ秒単位) を設定します。タイマー F は非 INVITE リクエストを再送信するタイムアウト間隔を指定するものです。
timer-f-timeout-interval をコンフィグレーションしないと、タイマー F の値はタイマー T1 から導き出されます (64*T1、デフォルトでは 32000 ミリ秒)。
この要素は、Oracle WebLogic Communication Services によって無効化されるまでの、SIP アプリケーション セッションが存続できる時間 (分単位) の上限を設定します。max-application-session-lifetime は、sip.xml ファイル内の session-timeout 要素または setExpires API を使用して指定した任意のタイムアウト値の上側へのバインドとして機能します。
-1 (デフォルト) は、コンフィグレーションしたタイムアウト値に対する上側へのバインドが存在しないことを示します。
enable-local-dispatch は、メッセージの送信と転送での不必要なネットワーク トラフィックを避けるのに役立つサーバ最適化です。この要素を設定すると、最適化を有効化できます。enable-local-dispatch を有効にした場合、サーバ インスタンスがメッセージを送信または転送する必要があって、メッセージの宛先がエンジン層のクラスタ アドレスかローカル サーバ アドレスであれば、メッセージはネットワーク経由で送られるのではなく、内部的にローカル サーバにルーティングされます。この最適化を使用すると、チェーン化されたアプリケーションが同じリクエストを処理する際のパフォーマンスが大幅に向上します。
内部メッセージのルーティングがエンジン層のサーバの負荷を歪めるような気がして、コンフィグレーションされたロード バランサを通じてすべてのリクエストをルーティングしたいと思うなら、この最適化を無効にするほうがよいでしょう。
enable-local-dispatch のデフォルト設定は「false」です。
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>
詳細については、『操作ガイド』の「ソフトウェアのアップグレード」を参照してください。
この要素は、受信した 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 として振る舞います。
この要素は、受け取った最初のリクエストがデプロイ済みサーブレットに対応しない場合に呼び出すデフォルト 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 は返しません。常にアプリケーション セッションを無効にします。
5xx 応答のためにRetry-Afterヘッダに使用された、秒単位を指定します。この値には、「Retry-After: 18000;時間=3600」または「Retry-After: 120 (私は会議中です)」のようなパラメータまたは理由コードも含めることができます。
この値がコンフィグレーションされていないと Oracle WebLogic Communication Services は デフォルト値の 180 秒を使用します。
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 コンフィグレーションを示します。
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>
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>
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」も参照してください。
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>
persistence 要素は、RDBMS もしくはリモートの地理的に冗長な Oracle WebLogic Communication Services のインストールに呼び出し状態の書込みを有効化するか、無効化するかを定義します。地理的に冗長なレプリケーション機能を利用するサイトのために、persistence 要素は、呼状態データが有効化されるサイト ID と URL についても定義します。
persistence 要素には、表 A-1 で説明するサブ要素が含まれます。
表 A-4 ネストされた永続化要素
| 要素 | 説明 |
|---|---|
default-handling |
Oracle WebLogic Communication Services が、RDBMS 永続化もしくは地理的な冗長に対する永続化ヒントを監視するかどうかを決定します。この要素は、以下のいずれかの値があります。
|
geo-site-id |
このインストールのサイト ID を指定します。地理的に冗長なレプリケーションに属するすべてのインストールは一意なサイト ID が必要です。 |
geo-remote-t3-url |
このサイトは、呼び出し状態データをレプリケーションするリモート Oracle WebLogic Communication Services インストールを指定します。リモートインストールのエンジン層クラスタに対応する単一 URL を指定することができます。各エンジン層サーバに対応するアドレスのカンマ区切りのリストを指定することもできます。URL には、t3 プロトコルを指定する必要があります。 |
例 A-5 は、存続時間が長い呼状態および地理的に冗長なレプリケーションのために RDBMS ストレージを使用するコンフィグレーション サンプルを示します。呼状態は、リモートのロケーションにおいて 2 つのエンジン層サーバにレプリケートされます。
この要素は、SIP メッセージにコンパクト ヘッダを使用または保持するためのサーバ全体のデフォルト動作をコンフィグレーションします。この要素は、以下のいずれかの値に設定できます。
compact - Oracle WebLogic Communication Services は、すべてのシステム生成のヘッダに対してコンパクト フォームを使用します。ただし、送信メッセージからコピーされたヘッダは、(生成のかわりに) 元のフォームを使用します。
force compact - Oracle WebLogic Communication Services は、すべてのヘッダのためにコンパクト フォームを使用し、必要に応じて、既存のメッセージの長いヘッダからコンパクト ヘッダに変換します。
long - Oracle WebLogic Communication Services は、すべてのシステム生成のヘッダのために長いフォームを使用します。ただし、送信メッセージからコピーされたヘッダは、(生成のかわりに) 元のフォームを使用します。
force long - Oracle WebLogic Communication Services は、すべてのヘッダに対して長い フォームを使用し、必要に応じて、既存のメッセージをコンパクト ヘッダから長いヘッダに変換します。
この要素は、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 サーバを使用することをお勧めします。 |
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 |
このプールの名前を識別する文字列値です。すべてのコンフィグレーションされた |
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>
この要素は、ネットワーク要素とコミュニケーションする際に 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 として使用します。
この要素は 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 の拡張の [コンフィグレーション｜一般] タブの [ドメイン エリアス] フィールドを使用して識別することができます。 |
この要素は 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 転送を使用することをお勧めします。 |
この要素は Oracle WebLogic Communication Services 診断イメージファイルで記録する詳細のレベルを指定します。この要素は、以下のいずれかの値に設定できます。
basic - 呼状態データ以外のすべての診断データを記録します。
full - 呼状態データを含むすべての診断データを記録します。
|
注意 : イメージ ファイルへの呼状態データの記録には、時間がかかることがあります。デフォルトでは、イメージ ダンプ ファイルはbasic オプションを使用して記録されます。
SipServer Administration console の拡張の [コンフィグレーション｜一般] タブを使用してこのパラメータを設定することもできます。 |
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 が実行されます。 |
デフォルトでは、Oracle WebLogic Communication Services は To ヘッダを持つ信頼性のない暫定 (1xx) 応答には Contact ヘッダを設定しません。このような 1xx 形式の応答に Contact ヘッダを必要とするアプリケーションをデプロイする場合は、この要素を以下のように「true」に設定します。
<enable-contact-provisional-response>true</enable-contact-provisional-response>
この要素を true に設定しても、100 回の試行応答には影響しません。
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」を参照してください。
use-custom-app-router 要素は、Oracle WebLogic Communication Services がデフォルトで custom-app-router-jar-file-name 要素で組み込みアプリケーション AR (AR) またはカスタム AR を使用するかどうかを決定します。デフォルト値「false」は、デフォルト AR を使用するためサーバをコンフィグレーションします。
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 に渡されません。
custom-app-router-jar-file-name 要素は、使用する JAR ファイルとしてパッケジ化されたカスタム Application Router (AR) のファイル名を指定します。カスタム AR 実装は、$DOMAIN_HOME/approuter サブディレクトリに配置する必要があります。
default-application-name 要素は、カスタム アプリケーション ルータ (AR) が初期リクエストを処理するためのアプリケーションが見つからない場合は、コンテナが呼び出す必要のあるデフォルト アプリケーションの名前を指定します。デフォルト アプリケーションを指定しない場合、AR がアプリケーションを選択できない場合、コンテナは 500 エラーを返します。
|
注意 : アプリケーション名をデフォルト アプリケーション名の値として指定する前に、アプリケーションをデプロイする必要があります。 |
