コンフィグレーション リファレンス マニュアル

     前  次    新しいウィンドウで目次を開く     
コンテンツの開始位置

エンジン層のコンフィグレーション リファレンス (sipserver.xml)

以下の節は、エンジン層のコンフィグレーション ファイル sipserver.xml に関する詳細なリファレンス情報です。

 

sipserver.xml の概要

sipserver.xml ファイルはサーバ インストールのエンジン層にある Oracle Communications Converged Application Server インスタンスで供給された SIP コンテナ機能をコンフィグレーションする XML ドキュメントです。sipserver.xml は、DOMAIN_DIR/config/CUSTOM サブディレクトリに格納されます。DOMAIN_DIR は Oracle Communications Converged Application Server ドメインのルート ディレクトリです。

グラフィカルな表現

図 1-1 は、sipserver.xml デプロイメント記述子ファイルの要素階層を表しています。

図 1-1 sipserver.xml の要素階層

sipserver.xml の要素階層

 

sipserver.xml の編集

通常の運用時に sipserver.xml ファイルを移動、変更、または削除することは絶対に避けてください。

sipserver.xml ファイルに変更を加えるときは、直接編集せずに、Administration Console を使って間接的に行うようお勧めします。Administration Console を使用すれば、sipserver.xml が確実に有効な XML になります。『コンフィグレーション ガイド』の「WLST (JMX) によるコンテナ プロパティのコンフィグレーション」も参照してください。

しかし場合によっては、問題のあるコンフィグレーションを修正したり、壊れたファイルを修復したり、Oracle Communications Converged Application Server のアップグレード時にカスタム コンフィグレーションを多数のマシンに展開するために、sipserver.xml を手動で表示または編集しなければならないことがあります。sipserver.xml を手動で編集したときは、変更内容を適用するために Oracle Communications Converged Application Server インスタンスを再起動する必要があります。

警告 : 動作中の Oracle Communications Converged Application Server デプロイメントに変更を行うときは、必ず Administration Console の SipServer ノードまたは WLST ユーティリティを使用してください。『コンフィグレーション ガイド』の「エンジン層コンテナのプロパティのコンフィグレーション」を参照してください。

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

プロダクション システムの sipserver.xml に変更を加える必要がある場合は、以下の手順に従ってください。

  1. テキスト エディタで DOMAIN_DIR/config/custom/sipserver.xml ファイルを開きます。ただし、DOMAIN_DIR は Oracle Communications Converged Application Server ドメインのルート ディレクトリを表します。
  2. sipserver.xml ファイルに対して必要な変更を行います。XML 要素の詳細については、「XML スキーマ」を参照してください。
  3. 変更を保存し、テキスト エディタを終了します。
  4. サーバを再起動して、変更内容を有効にします。
警告 : 動作中の Oracle Communications Converged Application Server デプロイメントに変更を行うときは、必ず Administration Console の SipServer ノードまたは WLST ユーティリティを使用してください。『コンフィグレーション ガイド』の「エンジン層コンテナのプロパティのコンフィグレーション」を参照してください。
  1. 更新後のシステムをテストして、コンフィグレーションを検証します。

 

XML スキーマ

sipserver.xml、wcp-sipserver.xsd のスキーマ ファイルは、wlss-descriptor-binding.jar ライブラリの中にもインストールされ、WLSS_HOME/server/lib/wlss ディレクトリ に置かれます。

 

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>

 

XML 要素の説明

以下の節では、sipserver.xml コンフィグレーション ファイルの中で使われる各要素について説明します。それぞれの節で、図 1-1 に示したメイン sip-server 要素内に含まれる各 XML 要素について説明します。

enable-timer-affinity

enable-timer-affinity 要素は、エンジン層サーバが期限切れタイマーを処理する方法について決定します。デフォルトでは (enable-timer-affinity は、sipserver.xml から省略したか、「false」に設定した場合)、タイマー期限の SIP データ層をポーリングするエンジン層サーバがすべての有効なタイマー期限を処理します。enable-timer-affinity は、「true」に設定した場合、エンジン層サーバは、エンジンが最後に変更した (またはオーマーを持たない呼状態のタイマー期限) 呼状態に関連付けるタイマー期限のみの SIP データ層をポーリングします。

詳細については、『コンフィグレーション ガイド』の「タイマー処理のコンフィグレーション」を参照してください。

overload

overload 要素を使用すると、コンフィグレーションした過負荷 (オーバーロード) 条件に従って SIP リクエストの受信を規制することができます。過負荷条件が発生すると、Oracle Communications Converged Application Server は新しい SIP リクエストを破棄し、「“503 Service Unavailable」で応答します。この処置は、コンフィグレーションされたリリース値が実際に測定されるか、サーバの容量制限が減少されるまで行われます (「容量制限に基づく過負荷制御」を参照してください)。

ユーザのコンフィグレーションによる過負荷制御が適用されるのは、初期 SIP リクエストだけです。過負荷条件が発生したときに既にアクティブになっていた SIP ダイアログは、規制されない SIP リクエストをさらに生成することがあります。

過負荷制御をコンフィグレーションするには、表 1-1 で説明する 3 つの要素を定義します。

表 1-1 ネストされた overload 要素
要素
説明
threshold-policy
過負荷条件のモニタに使われる測定のタイプを指定する文字列値。
  • session-rate では、新しい SIP リクエストが生成されるレートが測定される。Oracle Communications Converged Application Server は、直前の 5 秒間に作成された新しい SIP アプリケーション接続の数を計算してセッション レートを求めます。「セッション生成レートに基づく過負荷制御」を参照。
  • queue-length では、SIP リクエストと SIP タイマーを処理する容量制限ワーク マネージャ コンポーネントのサイズの合計が測定される。「容量制限に基づく過負荷制御」を参照してください。

    • 注意 : 実行キューは非推奨になりました、Oracle Communications Converged Application Server では使用されません。容量制限は、実行キューの代わりに使用できます。ポリシー名「queue-length」は、下位互換性のために保管します。

上記のポリシーのどちらか一方を使って過負荷制御を定義する。詳細については、「適切な過負荷ポリシーの選択」を参照。
threshold-value
Oracle Communications Converged Application Server にオーバーロード条件および新しい SIP リクエストの規制を開始させる測定値を指定します。
  • しきい値ポリシーとして session-rate を使用する場合は、過負荷条件をトリガする 1 秒あたりの新しい SIP リクエストの数を threshold-value で指定する。「セッション生成レートに基づく過負荷制御」を参照。
  • しきい値ポリシーとして queue-length を使用する場合は、過負荷条件をトリガする SIP 転送と SIP タイマーのためのリクウェストの数の合計の長さを threshold-value で指定する。「容量制限に基づく過負荷制御」を参照してください。
threshold-value を観察した後で、Oracle Communications Converged Application Server は、新しい SIP リクエストが抑制する時間に最小 512 ミリ秒のオーバーロード条件を認識します。短時間に複数のオーバーロードを発生すると、512 ミリ秒の最小オーバーロードは、反復オーバーロードを回避するために動的に増加します。
最小オーバーロード認識時間が満了した後、オーバーロード条件はコンフィグレーションされた release-value を観察した後終了しました。
release-value
Oracle Communications Converged Application Server にオーバーロード条件および新しい SIP リクエストの規制を停止させる測定値を指定します。
  • しきい値ポリシーとして session-rate を使用する場合は、セッション規制を終了させる 1 秒あたりの新しい SIP リクエストの数を release-value で指定する。「セッション生成レートに基づく過負荷制御」を参照。
  • しきい値ポリシーとして queue-length を使用する場合は、セッション規制を終了させる容量制限のリクエスト数の合計を release-value で指定する。「容量制限に基づく過負荷制御」を参照してください。

適切な過負荷ポリシーの選択

Oracle Communications Converged Application Server は、SIP リクエストを規制するためのポリシーは 2 種類あります。

利用可能なオーバーロード ポリシーは 1 つしか選択できません。同時に両方のポリシーを使用することはできません。

既知の最大スループット (RDBMS など) を持つバックエンド リソースが SIP コールの設定に使用されている場合は、session-rate ポリシーが―般的に利用されている。この場合は、session-rate ポリシーを使用すると、バックエンド リソースの既知のスループット機能に Oracle Communications Converged Application Server オーバーロード ポリシーを関連付けることができる。

queue-length ポリシーでは、Oracle Communications Converged Application Server はオーバーロード状態を診断するため CPU と I/O ボトルネックの両方をモニタする。queue-length ポリシーは、一般的にコール レートに関連した予測される上側へのバインドを持たないシステム内で CPU 集中 SIP アプリケーションと共に使用される。

以下、これらのポリシーについて詳しく説明します。

セッション生成レートに基づく過負荷制御

Oracle Communications Converged Application Server は、直前の 5 秒間に作成されたアプリケーション セッションの数をモニタすることで、セッション生成レート (1 秒あたりのセッション数) を計算します。セッション生成レートが threshold-value で指定されたレートを超えると、Oracle Communications Converged Application Server は初期 SIP リクエストを規制し、セッション生成レートが release-value で指定された値より小さくなるまでこの規制を続けます。

次の例では、50 セッション/秒 を超えるレートで新しいセッションが作成されたとき Oracle Communications Converged Application Server が 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 Server 10 g リリース 3 ドキュメントの「ワーク マネージャを使用したスケジューリング済み作業の最適化」で説明したように、ワーク マネージャは Oracle Communications Converged Application Server インストールの config.xml ファイルにコンフィグレーションされ、スレッドは自動的に割り当てられる。起動オプション -Dweblogic.threadpool.MinPoolSize=number_of_threads を使用して起動時に追加のスレッドはサーバに割り当てる。

Oracle Communications Converged Application Server は、コンフィグレーション容量制限の合計長をモニタすることにより、queue-length 過負荷制御を行います。この 2 つの制限の合計長が threshold-value 要素で指定された長さを超えると、Oracle Communications Converged Application Server は初期 SIP リクエストを規制し、合計長が release-value で指定された値まで減少するまでこの規制を続けます。

コード リスト 1-1 に、sipserver.xml のデフォルト overload コンフィグレーションを示します。ここでは、制限の合計サイズが 200 リクウェストを超える場合は、Oracle Communications Converged Application Server が SIP リクウェスト規制を開始します。この規制は同時リクエスト数が 200 以下に戻ったときに終了します。

コード リスト 1-1 サンプルの過負荷定義 
<overload>
  <threshold-policy>queue-length</threshold-policy>
  <threshold-value>200</threshold-value>
  <release-value>150</release-value>
</overload>

過負荷保護の 2 レベル

ユーザがコンフィグレーションしたオーバーロード制御は (sipserver.xml に定義されたように) Oracle Communications Converged Application Server で供給された過負荷保護の最初の重大度レベルを示します。ユーザがコンフィグレーションしたオーバーロード制御は、オーバーロード条件の起動をマークし、ドロップされたコールを回避する単純な対策を開始します (新しい要求に対して 503 の応答を生成)。

オーバーロードの原因となった条件が永続化したり悪化した場合は、SIP サーブレット コンテナでワークの実行に使用するワークマ ネージャ コンポーネント自体がオーバーロードとなる可能性があります。この時点でサーバは 503 応答の生成にスレッドの使用をやめ、その代わりにドロップ メッセージを開始します。このように、SIP コンテナのワーク マネージャ コンポーネントのコンフィグレーション サイズは、サーバで使用する過負荷保護の 2 番目の最終レベルを示します。

sipserver.xml においてはオーバーロード制御を慎重にコンフィグレーションし、適宜オーバーロードを引き起こした状況を解決します。

message-debug

Message-debug 要素は、Oracle Communications Converged Application Server のログ ローテーションを使用してアクセス ロギングを有効化およびコンフィグレーションするために使用されます。この要素は開発環境でのみ使用してください。アクセス ロギングでは、すべての SIP リクエストと応答が記録されるからです。アクセス ロギングのコンフィグレーションと使用については、『SIP アプリケーションの開発』の「アクセス ロギングの有効化」を参照してください。

プロダクション環境でさらに選択的なロギングを行う場合は、『操作ガイド』の「SIP リクエストと応答のロギング」を参照してください。

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

RFC 3261 では、アウトバンド プロキシを次のように定義しています。「クライアントからのリクエストを受信するプロキシ。Request-URI で解決されるサーバでなくてもこう呼ぶ。一般に、UA では手動でアウトバンド プロキシがコンフィグレーションされるか、自動コンフィグレーション プロトコルによってアウトバンド プロキシのことを知ることができる。」

Oracle Communications Converged Application Server では、アウトバウンド プロキシ サーバを sipserver.xml 内で proxy 要素を使って指定します。proxy 要素では 1 つまたは複数のプロキシ サーバ URI を定義します。プロキシ プロセスの動作は、proxy-policy タグでプロキシ ポリシーを設定することで変更できます。コード リスト 1-2 で proxy 要素に指定可能な値を説明する。

デフォルトの動作は domain ポリシーが有効であるかのようになっています。この proxy ポリシーは次のことを意味します。リクエストが、コンフィグレーションされたアウトバウンド プロキシに送られること、そしてリクエスト内のルート ヘッダが Oracle Communications Converged Application Server によってなされたルーティング決定を保持し続けることです。これにより、アウトバウンド プロキシがリクエストに対してアクションを実行した後でリクエストを目的の受信者に届けることが可能になります。proxy ポリシーは初期リクエストに対してのみ実施されます。後続のリクエストについては、ルート セットがダイアログ内のどのポリシーにも優先します (アウトバウンド プロキシがルート セットに入れられることを望む場合は、レコード ルーティングをオンにすることができます)。

また、Oracle Communications Converged Application Server 上で書かれたプロキシ アプリケーションで、アウトバウンド プロキシ通過についてコンフィグレーションされた動作をオーバーライドしたい場合は、「X-BEA-Proxy-Policy」という名前と「domain」という値を持つ特別なヘッダを追加することができます。このヘッダは送信中にリクエストから削除されますが、コンフィグレーションされたアウトバウンド プロキシを無視するという効果があります。アプリケーションで X-BEA-Proxy-Policy カスタム ヘッダを使用することにより、コンフィグレーションされたポリシーをリクエストごとに個別にオーバーライドすることができます。このヘッダの有効な値は「domain」または「proxy」です。ただし、ポリシーが「proxy」にオーバーライドされる場合、アウトバウンド プロキシの URI がコンフィグレーションに含まれていなければアウトバウンド プロキシにルーティングすることはできません。

表 1-2 ネストされた proxy 要素
要素
説明
routing-policy
プロキシの動作をコンフィグレーションする省略可能な要素。有効な値は次のとおりである。
  • domain - RFC 3261 で定義されているルーティング ルールを使ってメッセージをプロキシします。アウトバウンド プロキシが指定されていても無視する。
  • proxy - メッセージをデフォルト プロキシ URI で指定されている下流のプロキシに送る。複数のプロキシ指定がある場合は、それらのプロキシが指定されている順序で試行される。ただし、UDP プロキシが試行される場合、後続のプロキシの設定は無視される。
uri
プロキシ サーバの TCP または UDP URI。proxy 要素として少なくとも 1 つの URI を指定する必要がある。複数 URIs を proxy 要素内の複数 uri 要素に配置する。

コード リスト 1-2 に、Oracle Communications Converged Application Server ドメインのデフォルト プロキシ コンフィグレーションを示します。この場合、リクエストは SIP ルーティング ルールに従って作成され、最終的にアウトバウンド プロキシ「sipoutbound.oracle.com」に送られます。

コード リスト 1-2 サンプルの proxy 定義 
<proxy>
     <routing-policy>proxy</routing-policy>
     <uri>sip:sipoutbound.oracle.com:5060</uri>
     <!-- Other proxy uri tags can be added. -->
</proxy>

t1-timeout-interval

この要素は SIP プロトコル T1 タイマーの値 (ミリ秒単位) を設定します。タイマー T1 はタイマー A、E、および G の初期値も指定します。これらのタイマーによって UDP による INVITE リクエストと応答の再送信の間隔が決定されます。

タイマー T1 はタイマー F、H、および J の値にも影響を与えます。これらのタイマーによって INVITE 応答とリクエストの再送信の間隔が決定されます。これらのタイマーの値は 64*T1 ミリ秒に設定されます。SIP タイマーの詳細については、「SIP: Session Initiation Protocol」を参照してください。『コンフィグレーション ガイド』の「SIP タイマーの正確な同期に必要な NTP のコンフィグレーション」も参照してください。

t1-timeout-interval をコンフィグレーションしないと、Oracle Communications Converged Application Server は SIP プロトコルのデフォルト値である 500 ミリ秒を使用します。

t2-timeout-interval

この要素は SIP プロトコル T2 タイマーの値 (ミリ秒単位) を設定します。タイマー T2 は INVITE 応答と非 INVITE リクエストの再送信間隔を指定するものです。SIP タイマーの詳細については、「SIP: Session Initiation Protocol」を参照してください。『コンフィグレーション ガイド』の「SIP タイマーの正確な同期に必要な NTP のコンフィグレーション」も参照してください。

t2-timeout-interval をコンフィグレーションしないと、Oracle Communications Converged Application Server は SIP プロトコルのデフォルト値である 4 秒を使用します。

t4-timeout-interval

この要素は SIP プロトコル T4 タイマーの値 (ミリ秒単位) を設定します。タイマー T4 はメッセージがネットワーク内に存続できる時間の上限を指定するものです。タイマー T4 はタイマー I および K の初期値も指定します。これらのタイマーによって UDP による ACK と応答の再送信までの待ち時間が決定されます。SIP タイマーの詳細については、「SIP: Session Initiation Protocol」を参照してください。『コンフィグレーション ガイド』の「SIP タイマーの正確な同期に必要な NTP のコンフィグレーション」も参照してください。

t4-timeout-interval をコンフィグレーションしないと、Oracle Communications Converged Application Server は SIP プロトコルのデフォルト値である 5 秒を使用します。

timer-b-timeout-interval

この要素は SIP プロトコル タイマー B の値 (ミリ秒単位) を設定します。タイマー B はクライアント トランザクションがリクエストの送信を再試行する時間の長さを指定するものです。SIP タイマーの詳細については、「SIP: Session Initiation Protocol」を参照してください。『コンフィグレーション ガイド』の「SIP タイマーの正確な同期に必要な NTP のコンフィグレーション」も参照してください。

timer-b-timeout-interval をコンフィグレーションしないと、タイマー B の値はタイマー T1 から導き出されます (64*T1、デフォルトでは 32000 ミリ秒)。

timer-f-timeout-interval

この要素は SIP プロトコル タイマー F の値 (ミリ秒単位) を設定します。タイマー F は非 INVITE リクエストを再送信するタイムアウト間隔を指定するものです。SIP タイマーの詳細については、「SIP: Session Initiation Protocol」を参照してください。『コンフィグレーション ガイド』の「SIP タイマーの正確な同期に必要な NTP のコンフィグレーション」も参照してください。

timer-f-timeout-interval をコンフィグレーションしないと、タイマー F の値はタイマー T1 から導き出されます (64*T1、デフォルトでは 32000 ミリ秒)。

max-application-session-lifetime

この要素は、Oracle Communications Converged Application Server によってセッションが無効化されるまでの、SIP アプリケーション セッションが存続できる時間 (分単位) の上限を設定します。max-application-session-lifetime は、sip.xml ファイル内の session-timeout 要素または setExpires API を使用して指定した任意のタイムアウト値の上側へのバインドとして機能します。

-1 (デフォルト) は、コンフィグレーションしたタイムアウト値に対する上側へのバインドが存在しないことを示します。

enable-local-dispatch

enable-local-dispatch は、メッセージの送信と転送での不必要なネットワーク トラフィックを避けるのに役立つサーバ最適化です。この要素を「true」に設定すると、最適化が有効になります。enable-local-dispatch を有効にした場合、サーバ インスタンスがメッセージを送信または転送する必要があって、メッセージの宛先がエンジン層のクラスタ アドレスかローカル サーバ アドレスであれば、メッセージはネットワーク経由で送られるのではなく、内部的にローカル サーバにルーティングされます。この最適化を使用すると、チェーン化されたアプリケーションが同じリクエストを処理する際のパフォーマンスが大幅に向上します (『SIP アプリケーションの開発』の「SIP アプリケーションの構成」を参照してください)。

内部メッセージのルーティングがエンジン層のサーバの負荷を歪めるような気がして、コンフィグレーションされたロード バランサを通じてすべてのリクエストをルーティングしたいと思うなら、この最適化を無効にするほうがよいでしょう。

enable-local-dispatch のデフォルト設定は「false」です。

cluster-loadbalancer-map

cluster-loadbalancer-map 要素は、Oracle Communications Converged Application Server ソフトウェアをアップグレードするか、プロダクション SIP サーブレットを新しいバージョンにアップグレードするときにだけ使用します。サーバの通常の運用時には使用しません。

ソフトウェアのアップグレード時には、ソフトウェアの古いバージョンと新しいバージョンをホストするために複数のエンジン層クラスタを定義します。cluster-loadbalancer-map は、アップグレード用にコンフィグレーションしたエンジン層クラスタに対応する仮想 IP アドレスを定義します (ロード バランサ上で定義)。Oracle Communications Converged Application Server はこのマッピングを使って、呼状態データとタイマーに対するエンジン層リクエストが間違いなくクラスタの正しい「バージョン」から受信されるようにします。リクエストがソフトウェアの誤ったバージョンから来た場合、cluster-loadbalancer-map エントリが使用され、そのリクエストを正しいクラスタに転送します。

それぞれの cluster-loadbalancer-map エントリには、以下で説明する 2 つの要素が含まれます。

表 1-3 ネストされた cluster-loadbalancer-map 要素
要素
説明
cluster-name
エンジン層クラスタのコンフィグレーションされた名前。
sip-uri
エンジン層クラスタにマップする内部 SIP URI。これはロード バランサでコンフィグレーションした仮想 IP アドレスに対応する。内部 URI はアップグレード時にリクエストを正しいクラスタ バージョンに転送するために使用される。

コード リスト 1-3 に、アップグレード時に使用されるサンプルの cluster-loadbalancer-map エントリを示します。

コード リスト 1-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>

詳細については、『操作ガイド』の「ソフトウェアのアップグレード」を参照してください。

default-behavior

この要素は、受信した SIP リクエストをデプロイ済みの SIP サーブレットに対応付けられない (または対応するアプリケーションが無効化されているかタイムアウトになっている) 場合の Oracle Communications Converged Application Server インスタンスのデフォルト動作を定義します。有効な値は次のとおりです。

値を指定しなければ、デフォルトとして proxy が使用されます。

ユーザ エージェント (UA) として動作するとき、Oracle Communications Converged Application Server が行う SIP リクエストへの応答は次のようになります。

ステートレス プロキシとして振る舞う場合、リクエストは自動的にアウトバウンド プロキシ (コンフィグレーションされている場合) に転送されます (「proxy - アウトバウンド プロキシ サーバの設定」を参照してください)。プロキシが定義されていないと、Oracle Communications Converged Application Server は、リクエスト URI が SIP サーブレット コンテナの既知のローカル アドレスまたはサーバに対してコンフィグレーションされているロード バランサ アドレスの IP とポート番号に一致しない場合にのみ、指定されたリクエスト URI にプロキシします。これにより、リクエストが絶えず同じサーバにループすることが防止されます。リクエスト URI がローカル コンテナ アドレスまたはロード バランサ アドレスと一致する場合、Oracle Communications Converged Application Server は UA として振る舞います。

default-servlet-name

この要素は、受け取った最初のリクエストがデプロイ済みサーブレットに対応しない場合に呼び出すデフォルト SIP サーブレットの名前を指定します (sip.xml の標準 servlet-mapping 定義を使用します)。default-servlet-name 要素に指定する名前は、デプロイ済みの SIP サーブレットの servlet-name 値と一致する必要があります。次に例を示します。 

<default-servlet-name>myServlet</default-servlet-name>

default-servlet-name に定義されている名前がデプロイ済みサーブレットに対応しない場合、または、値が何も指定されていない (デフォルト コンフィグレーションが使用された) 場合は、com.bea.wcp.sip.engine.BlankServlet という名前がデフォルト サーブレットとして登録されます。BlankServlet 名は、default-servlet-name として登録されたデプロイ済みサーブレットがコンテナからアンデプロイされた場合にも使用されます。

Blankservlet の動作は、default-behavior 要素によりコンフィグレーションされます。デフォルトでは、このサーブレットは対応しないすべてのリクエストをプロキシします。しかし、default-behavior 要素が「ua」モードに設定されている場合、blankservlet は CANCEL リクエストと BYE リクエストに対して 481 応答を返し、それ以外のすべてのケースでは 500/416 応答を返します。BlankServlet は ACK は返しません。常にアプリケーション セッションを無効にします。

retry-after-value

5xx 応答のためにRetry-Afterヘッダに使用された、秒単位を指定します。この値には、「Retry-After: 18000;時間=3600」または「Retry-After: 120 (私は会議中です)」のようなパラメータまたは理由コードも含めることができます。

この値がコンフィグレーションされていないと Oracle Communications Converged Application Server は デフォルト値の 180 秒を使用します。

sip-security

Oracle Communications Converged Application Server では、認証が行われない 1 つまたは複数の信頼性のあるホストをコンフィグレーションすることができます。Oracle Communications Converged Application Server は SIP メッセージを受け取ると、SIP サーブレット メッセージに対して getRemoteAddress() を呼び出します。このアドレスがサーバの信頼性のあるホストのリストで定義されているアドレスと一致する場合は、メッセージに対してそれ以上認証は行われません。

sip-security 要素は、認証が行われない 1 つまたは複数の信頼性のあるホストを定義します。sip-security 要素には 1 つまたは複数の trusted-authentication-host 要素または trusted-charging-host 要素が含まれ、それぞれの要素には信頼性できるホストの定義が含まれます。信頼性のあるホストの定義は ip アドレス (ワイルド カード プレースホルダ有りまたは無し) または DNS 名から成ります。コード リスト 1-4 に、サンプル sip-security コンフィグレーションを示します。

コード リスト 1-4 ホストのサンプル コンフィグレーション 
<sip-security>
   <trusted-authentication-host>myhost1.mycompany.com</trusted-authentication-host>
   <trusted-authentication-host>172.*</trusted-authentication-host>
</sip-security>

route-header

3GPP TS 24.229 Version 7.0.0 では、新しいリクエストを (B2BUA などとして) 生成する IMS アプリケーション サーバに対して、S-CSCF ルート ヘッダを含めることが要求されています。Oracle Communications Converged Application Server では、この S-CSCF ルート ヘッダは、sipserver.xml の route-header 要素の値として静的に定義する必要があります。次に例を示します。 

<route-header>
   <uri>Route: sip:wlss1.bea.com</uri>
</route-header>

engine-call-state-cache-enabled

Oracle Communications Converged Application Server は呼状態データの一部をローカルにキャッシュするオプションをエンジン層サーバに提供し、これを SIP データ層内でも行うことで SIP-aware ロード バランサのパフォーマンスを向上させます。ローカル キャッシュを使用すると、エンジン層サーバは最初に既存の呼状態データのローカル キャッシュをチェックします。キャッシュに必要なデータが含まれており、かつデータのローカルコピーが (SIP データ層コピーと比較して) 最新データの場合、エンジンは SIP データ層の呼状態をロックしますが、直接キャッシュから読み込みます。

デフォルトでは、エンジン層キャッシュは有効です。キャッシュを無効化するには、engine-call-state-cache-enabled を false に設定します。 

<engine-call-state-cache-enabled>false</engine-call-state-cache-enabled>

詳細については、『コンフィグレーション ガイド』の「エンジン層キャッシュの使用」を参照してください。

server-header

Oracle Communications Converged Application Server は、サーバ ヘッダが SIP メッセージに挿入された時に制御可能にします。この機能により、サーバ ヘッダを制限または削除することで、ワイヤレス ネットワークに対するメッセージ サイズを減少したり、セキュリティを増強することができます。

デフォルトでは、Oracle Communications Converged Application Server は、サーバ ヘッダを SIP メッセージに挿入しません。server-header に、以下のいずれかの文字列値を設定し動作をコンフィグレーションします。

たとえば、以下の要素は、すべての生成された SIP メッセージに対してサーバ ヘッダを挿入するように Oracle Communications Converged Application Server をコンフィグレーションします。 

<server-header>all</server-header>

「server-header-value」も参照してください。

server-header-value

Oracle Communications Converged Application Server は、生成されたメッセジのサーバ ヘッダに挿入された、テキストの制御を有効化します。これは SIP メッセ-ジ サイズやセキュリティ強化のためサーバ エンティティをマスクすることも可能な追加制御を提供します。デフォルトで、Oracle Communications Converged Application Server は、生成された SIP メッセ-ジにサーバ ヘッダを挿入しません。(「server-header」を参照してください)。サーバ ヘッダ挿入が有効化されていて、Server-header-value が指定されていない場合、Oracle Communications Converged Application Server は、「WebLogic SIP Server」値を挿入します。ヘッダ コンテンツをコンフィグレーションするために、文字列値を入力してください。次に例を示します。 

<server-header-value>MyCompany Application Server</server-header-value>

persistence

persistence 要素は、RDBMS もしくはリモートの地理的に冗長な Oracle Communications Converged Application Server のインストールに呼状態の書込みを有効化するか、無効化するかを定義します。地理的に冗長なレプリケーション機能を利用するサイトのために、persistence 要素は、呼状態データが有効化されるサイト ID と URL についても定義します。

persistence 要素には、表 1-4 で説明するサブ要素が含まれます。

表 1-４ ネストされた永続化要素
要素
説明
default-handling
Oracle Communications Converged Application Server が、RDBMS 永続化もしくは地理的な冗長に対する永続化ヒントを監視するかどうかを決定する。この要素は、以下のいずれかの値がある。
  • all — 呼状態データが RDBMS ストアと地理的に冗長な Oracle Communications Converged Application Server インストールの両方に永続化できるよう指定する。これはデフォルトの動作である。どちらの送り先へ実際のレプリケーションをする場合も、利用可能なリソース (JDBC データソースと リモート JMS キュー) を準備しておく必要がある。
  • db 必要な JDBC データソースとスキーマが利用可能な場合、存続時間が長い呼状態データが RDBMS にレプリケーションされることを指定する。
  • geo コンフィグレーションされた サイト URL に必要な JMS リソースが含まれてる場合、リモート、地理的に冗長なサイトに対する呼状態データを永続化することを指定する。
  • none SIP データ層クラスタでは他のレプリカに対するインメモリ レプリケーションだけ実行されることを指定する。呼状態データは、RDBMS または外部サイトに対して永続化されない。
geo-site-id
このインストールのサイト ID を指定する。地理的に冗長なレプリケーションに属するすべてのインストールは一意なサイト ID が必要である。
geo-remote-t3-url
このサイトは、呼状態データをレプリケーションするリモート Oracle Communications Converged Application Server インストールを指定する。リモートインストールのエンジン層クラスタに対応する単一 URL を指定することができる。各エンジン層サーバに対応するアドレスのカンマ区切りのリストを指定することもできる。URL には、t3 プロトコルを指定する必要がある。

コード リスト 1-5 は、存続時間が長い呼状態および地理的に冗長なレプリケーションのために RDBMS ストレージを使用するコンフィグレーション サンプルを示します。呼状態は、リモートのロケーションにおいて 2 つのエンジン層サーバにレプリケートされます。

コード リスト 1-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>

詳細については、『コンフィグレーション ガイド』の「長期間維持する呼状態データの RDBMS への格納」と「地理的に冗長なインストールのコンフィグレーション」を参照してください。

use-header-form

この要素は、SIP メッセージにコンパクト ヘッダを使用または保持するためのサーバ全体のデフォルト動作をコンフィグレーションします。この要素は、以下のいずれかの値に設定できます。

enable-dns-srv-lookup

この要素は、Oracle Communications Converged Application Server DNS ルックアップ機能を有効化または無効化します。要素を「true」に設定した場合、サーバは DNS を使用できます。

プロキシ検出のために Oracle Communications Converged Application Server は、SIP トランザクション毎に一度 DNS 解決を使用して転送、IP とポート番号に関する情報を決定します。すべての再送信、ACKs または CANCEL リクエストは同じ転送を使用して同じアドレスとポートに配信されます。DNS 解決をどのように実行するかについての詳細については、「RFC 3263: セッション 開始 プロトコル (SIP): SIP Servers の配置」を参照してください。

プロキシから応答メッセージを送信する必要がある場合、Oracle Communications Converged Application Server は sent-by フィールドと via ヘッダで提供された情報によっては送信先の IP アドレスおよびポート番号を決定するため DNS ルックアップを使用する。

デフォルトでは、DNS 解決は使用しません(「false」)。

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

connection-reuse-pool

Oracle Communications Converged Application Server には、SBC (Session Border Control) 機能または S-CSCF (Serving Call Session Control Function) との通信オーバーヘッドを最小限に抑える接続プール メカニズムが備わっています。別々のアドレスに複数の固定接続プールをコンフィグレーションできます。

Oracle Communications Converged Application Server は、要求に応じて接続プールから新しい接続を開き、サーバはコンフィグレーションされたアドレスにリクエストをします。サーバは接続の切断と再確立を繰り返す代わりに、既に開いている接続を使用して、新しい SIP リクエストを多重送信します。開いた接続はラウンドロビン方式で再使用されます。開いた接続はリモート アドレスによって明示的に終了されるまで閉じられるまで開いたままです。

接続再使用プールは、コンフィグレーションされたアドレスからの受信リクエストには使用されません。

接続再使用プールをコンフィグレーションするために、表 1-5 の 4 つのネストされた要素を定義します。

表 1-5 ネストされた connection-reuse-pool 要素
要素
説明
pool-name
このプールの名前を識別する文字列値である。すべてのコンフィグレーションされた pool-name 要素はドメインに対して一意である必要がある。
destination
送信先 SBC または S-CSCF の IP アドレスまたはホスト名前を指定する。Oracle Communications Converged Application Server は、コンフィグレーションされたアドレスにリクエストをする場合に限り、このプールに接続を開くか、再使用します。
destination-port
送信先 SBC または S-CSCF のポート番号を指定する。
maximum-connections
このプールで保持する開いた接続の最大数を指定する。

コード リスト 1-6 は、2 つのプールがあるコンフィグレーション「connection-reuse-pool」サンプルを表示されます。

コード リスト 1-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>

globally-routable-uri

この要素は、ネットワーク要素とコミュニケーションする際に Oracle Communications Converged Application Server が Contact および Route-Set ヘッダに自動的に挿入される Globally-Routable User Agent URI (GRUU) を指定できるようにします。この要素に指定された URI は、すべての Oracle Communications Converged Application Server クラスタに対する GRUU である必要があります。(単位サーバ ドメンでは、GRUU をサーバ自体のために使用します。)

一般にユーザ エージェント (UAs) は、登録リクエスト経由で GRUUs を入手して Oracle Communications Converged Application Server にデプロイします。この場合、アプリケーション コードは、リクエストとその後に GRUU を処理することの両方を担当します。GRUU をリクエストするため、GRUU を必要とする各 Contact の「+sip.instance」Contact ヘッダ フィールド パラメータを UA に含めます。GRUU を受信すると、UA は新しいリクエストの生成に際して GRUU を Contact ヘッダ フィールドの URI として使用します。

domain-alias-name

この要素は Oracle Communications Converged Application Server で担当する 1 つ以上のドメインを定義します。メッセージが domain-alias-name 要素で指定するドメインと同じ出力先のドメインを持っている場合、Oracle Communications Converged Application Server はメッセージを転送せずローカル処理をします。

sipserver.xml コンフィグレーション ファイルには、複数の main-alias-name 要素を持つことができます。各要素は以下のどちらも指定することができます。

注意 : これらのドメイン名は SipServer Administration console の拡張の [コンフィグレーション｜一般] タブの [ドメイン エリアス] フィールドを使用して識別することができます。

enable-rport

この要素は UAC として動作する場合、Oracle Communications Converged Application Server が自動的に report パラメータを Via ヘッダに追加するかどうかを決定する。デフォルトでは、サーバは rport パラメータを追加しないため、要素を「true」に設定して rport をサーバで生成されたリクエストに自動的に追加します。

注意 : SipServer administration コンソールの拡張の [コンフィグレーション｜一般] タブで [対称応答ルーティング オプション] を選択してこのパラメータを「true」に設定することができます。

「RFC 3581」で説明するように、rport パラメータは対称応答ルーティングに対して使用されます。Oracle Communications Converged Application Server などの RFC 3581 対応サーバでメッセージを受信すると、サーバは Via ヘッダで指定されたポート番号ではなく、メッセージを受信したリモート UDP ポート番号を使用して応答します。Network Address Translation (NAT) を行うゲートウェイ機器がサーバ内にある場合、この動作がひんぱんに行われます。NAT 機器は内部ポート番号と外部ポート番号間のバインディングを維持し、通信はすべてゲートウェイ ポートを通じて起動する必要があります。

Oracle Communications Converged Application Server は、RFC 3581 に準拠し、enable-rport 要素を「false」に設定する場合でも、rport パラメータを有効になります。enable-rport 要素は、サーバが自動的にリクエストを rport に追加するかどうかのみを指定します。UAC として動作する場合に生成します。rport 処理を完全に (RFC 3581 サポートを無効化) 無効化にするには、コマンドライン オプション -Dwlss.udp.uas.rport=false を使用してサーバを起動しなければなりません。

注意 : RFC3581 で説明される rport サポートは、元の SIP 要求のソース ポートを含む SIP 応答を必要とします。ソース ポート情報は極秘データとして扱われることが多いので、TLS 転送を使用することをお勧めします。

rport パラメータを使用した SIP および NAT の間の対話のサンプルについては、『ネットワーク リソースのコンフィグレーション』の「ベースのコンフィグレーション」を参照してください。

image-dump-level

この要素は Oracle Communications Converged Application Server 診断イメージファイルで記録する詳細のレベルを指定します。この要素は、以下のいずれかの値に設定できます。

注意 : イメージ ファイルへの呼状態データの記録には、時間がかかることがあります。デフォルトでは、イメージ ダンプ ファイルは basic オプションを使用して記録されます。
注意 : SipServer Administration console の拡張の [コンフィグレーション｜一般] タブを使用してこのパラメータを設定することもできます。

診断イメージファイルの詳細については、『操作ガイド』の「WebLogic Server 診断フレームワーク (WLDF) の使用」を参照してください。

stale-session-handling

Oracle Communications Converged Application Server はメッセージに関連付けられた呼状態およびアプリケーション セッションを識別するためエンコードされた URI を使用する。アプリケーションが新しいバージョンにアンデプロイ、またはアップグレードされた場合、着信リクエストは「古くなった」、または存在しないコールやセッション ID を指定するエンコードされた URI を持っている可能性があります。stale-session-handling 要素を使用すると、Oracle Communications Converged Application Server がリクエストに含まれた古いセッション データを検出した場合、Oracle Communications Converged Application Server が取るアクションをコンフィグレーションすることができます。以下のアクションが可能です。

注意 : 古くなったセッション データを検出すると、Oracle Communications Converged Application Server は default-behavior 要素の値を考慮する前に stale-session-handling で指定したアクションを適用します。つまり、continue の動作を行うために stale-session-handling をコンフィグレーションした場合のみ、default-behavior が実行されます。

enable-contact-provisional-response

デフォルトでは、Oracle Communications Converged Application Server は To ヘッダを持つ信頼性のない暫定 (1xx) 応答には Contact ヘッダを設定しません。このような 1xx 形式の応答に Contact ヘッダを必要とするアプリケーションをデプロイする場合は、この要素を以下のように「true」に設定します。 

<enable-contact-provisional-response>true</enable-contact-provisional-response>

この要素を true に設定しても、100 回の試行応答には影響しません。

app-router

app-router スタンザは、SIP Servlet v1.1 プリケーション ルータの動作をコンフィグレーションするいくつかの要素を含めます。「use-custom-app-router」、「app-router-config-data」、「custom-app-router-jar-file-name」および「default-application-name」を参照してください。

use-custom-app-router

use-custom-app-router 要素は、Oracle Communications Converged Application Server がデフォルトで custom-app-router-jar-file-name 要素で組み込みアプリケーション AR (AR) またはカスタム AR を使用するかどうかを決定します。デフォルト値「false」は、デフォルト AR を使用するためサーバをコンフィグレーションします。詳細については、『SIP アプリケーションの開発』の「カスタム アプリケーション ルータのコンフィグレーション」を参照してください。

app-router-config-data

app-router-config-data 要素は、init メソッド内で デフォルトまたはカスタム Application Router (AR) を渡すプロパティを定義します。すべてのコンフィグレーション プロパティを Java プロパティ形式に準拠している必要があり、それぞれのプロパティは、スペースや改行をしないで別々の行に入れます。DAR プロパティは、「SIP サーブレット仕様 v1.1」の付録 C で説明される詳細のプロパティ形式を準拠している必要があります。コード リスト 1-7 はコンフィグレーションの例を示します。

コード リスト 1-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>

必要に応じて、-Djavax.servlet.sip.ar.dar.configuration Java オプションを含めることで Oracle Communications Converged Application Server インスタンスを起動する場合、AR 初期化プロパティを指定します。(URI ではなくプロパティ ファイルを指定するには、プリフィックス file:/// を含む) Java 起動オプションを指定した場合、コンテナは、app-router-config-data に定義されたコンフィグレーション プロパティを無視します。プロパティをいつでも変更できますが、-Djavax.servlet.sip.ar.dar.configuration オプションを指定せずにサーバを再起動しないまでにプロパティが AR に渡されません。

詳細については、『SIP アプリケーションの開発』の「カスタム アプリケーション ルータのコンフィグレーション」を参照してください。

custom-app-router-jar-file-name

custom-app-router-jar-file-name 要素は、使用する JAR ファイルとしてパッケジ化されたカスタム Application Router (AR) のファイル名を指定します。カスタム AR 実装は、$DOMAIN_HOME/approuter サブディレクトリに配置する必要があります。

詳細については、『SIP アプリケーションの開発』の「カスタム アプリケーション ルータのコンフィグレーション」を参照してください。

default-application-name

default-application-name 要素は、カスタム アプリケーション ルータ (AR) が初期リクエストを処理するためのアプリケーションが見つからない場合は、コンテナが呼び出す必要のあるデフォルト アプリケーションの名前を指定します。デフォルト アプリケーションを指定しない場合、AR がアプリケーションを選択できない場合、コンテナは 500 エラーを返します。

注意 : デフォルト アプリケーション名 の値としてアプリケーションの名前を指定する前にそれをデプロイする必要があります。

詳細については、『SIP アプリケーションの開発』の「カスタム アプリケーション ルータのコンフィグレーション」を参照してください。


  ページの先頭       前  次