| Oracle® WebLogic Server SIP Container管理者ガイド 11g リリース1(11.1.1) B61429-02 |
|
 前 |
 次 |
次の項では、sipserver.xmlというエンジン層構成ファイルの完全なリファレンスを提供します。
sipserver.xmlファイルは、サーバー・インストールのエンジン層でOracle WebLogic Server SIP Containerインスタンスによって提供されるSIPコンテナ機能を構成するXMLドキュメントです。sipserver.xmlは、DOMAIN_DIR/config/customサブディレクトリに保存されています。ここで、DOMAIN_DIRは、Oracle WebLogic Server SIP Containerドメインのルート・ディレクトリです。
通常操作中はsipserver.xmlの移動、変更、および削除は絶対に行わないでください。
ファイルを手動で編集するのではなく、管理コンソールを使用してsipserver.xmlを間接的に変更することをお薦めします。管理コンソールを使用すると、sipserver.xmlドキュメントが常に有効なXMLを含むことが保証されます。構成ガイドのWLST (JMX)の使用によるコンテナ・プロパティの構成に関する項を参照してください。
Oracle WebLogic Server SIP Containerのインストール時またはアップグレード時に、問題のある構成のトラブルシューティングを実行したり、破損したファイルを修復したり、あるいはカスタム構成を多数のマシンにロール・アウトしたりするには、sipserver.xmlを手動で表示または編集する必要があります。手動でsipserver.xmlを編集するとき、変更を適用するにはOracle WebLogic Server SIP Containerインスタンスを再起動する必要があります。
|
注意: 実行中のOracle WebLogic Server SIP Containerデプロイメントを変更するには、管理コンソールまたはWLSTユーティリティでSipServerノードを常に使用します。 |
本番システムでsipserver.xmlを変更する必要がある場合、次の手順に従います。
テキスト・エディタを使用し、DOMAIN_DIR/config/custom/sipserver.xmlファイルを開きます。ここで、DOMAIN_DIRは、Oracle WebLogic Server SIP Containerドメインのルート・ディレクトリです。
必要に応じてsipserver.xmlファイルを変更します。XML要素の完全な説明は、A.3項「XMLスキーマ」を参照してください。
変更を保存し、テキスト・エディタを終了します。
サーバーを再起動して、変更内容を有効にします。
|
注意: 実行中のOracle WebLogic Server SIP Containerデプロイメントを変更するには、管理コンソールまたはWLSTユーティリティでSipServerノードを常に使用します。 |
更新後のシステムをテストして、構成を検証します。
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 Server SIP Containerは、構成されたリリース値が観察されるか、またはサーバーの容量制約サイズが削減されるまで、「503 Service Unavailable」を表示して新規SIPリクエストを破棄します(A.5.2.3項「容量制限に基づいた過負荷制御」を参照)。
ユーザーの構成による過負荷制御が適用されるのは、初期SIPリクエストのみです。過負荷条件が発生したときにすでにアクティブになっていたSIPダイアログは、規制されないSIPリクエストをさらに生成することがあります。
過負荷制御を構成するには、表A-1で説明されている3つの要素を定義します。
表A-1 ネストされたoverload要素
| 要素 | 説明 |
|---|---|
threshold-policy |
過負荷条件のモニターに使われる測定のタイプを指定する文字列値。
過負荷制御を定義するには、前述のポリシーの内いずれか1つのみ使用する必要があります。詳細は、A.5.2.1項「適切なオーバーロード・ポリシーの選択」を参照してください。 |
threshold-value |
Oracle WebLogic Server SIP Containerが過負荷状態を認識し、新規SIPリクエストの制限を開始する測定値を指定します。
|
release-value |
Oracle WebLogic Server SIP Containerにオーバーロード条件および新しいSIPリクエストの規制を停止させる測定値を指定します。
|
Oracle WebLogic Server SIP Containerは、SIPリクエストを制限するための2種類のポリシーを提供します。
session-rateポリシーは、新しいSIPセッションの構成率(1秒当たりのセッション数)に達したときセッションを規制します。
queue-lengthポリシーは、wlss.connectワーク・マネージャとwlss.timer.capacity容量制限コンポーネントの合計サイズが構成されたサイズに達した後、リクエストを規制します。
利用可能なオーバーロード・ポリシーは1つしか選択できません。同時に両方のポリシーを使用することはできません。
既知の最大スループット(RDBMSなど)を持つバックエンド・リソースがSIP呼出しの設定に使用されている場合は、session-rateポリシーが―般的に使用されます。この場合は、session-rateポリシーを使用すると、バックエンド・リソースの既知のスループット機能にOracle WebLogic Server SIP Containerオーバーロード・ポリシーを関連付けることができます。
queue-lengthポリシーでは、Oracle WebLogic Server SIP Containerはオーバーロード状態を診断するためCPUとI/Oボトル・ネックの両方をモニターします。queue-lengthポリシーは、一般的に呼出し率に関連付けられた予測可能な上限を持たないシステム内でCPU集中SIPアプリケーションとともに使用されます。
以下、これらのポリシーについて詳しく説明します。
Oracle WebLogic Server SIP Containerは、直前の5秒間に作成されたアプリケーション・セッションの数をモニターすることで、セッション生成率(1秒当たりのセッション数)を計算します。セッション生成率がthreshold-valueで指定された率を超えると、Oracle WebLogic Server SIP Containerは初期SIPリクエストを規制し、セッション生成率がrelease-valueで指定された値より小さくなるまでこの規制を続けます。
次の例では、50セッション/秒 を超える率で新しいセッションが作成されたときOracle WebLogic Server SIP Containerが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 SIP Containerのconfig.xmlファイルで構成されます。また、-Dweblogic.threadpool.MinPoolSize=number_of_threadsという起動オプションを使用して、起動時に追加スレッドをサーバーに追加できます。
Oracle WebLogic Server SIP Containerは、構成容量制限の合計長をモニターすることにより、queue-length過負荷制御を行います。この2つの制限の合計長がthreshold-value要素で指定された長さを超えると、Oracle WebLogic Server SIP Containerは初期SIPリクエストを規制し、合計長がrelease-valueで指定された値まで減少するまでこの規制を続けます。
例A-1は、sipserver.xmlからのサンプルoverload構成を示します。ここで、Oracle WebLogic Server SIP Containerは、制約の組合せサイズが200回のリクエスト数を超過するとき、SIPリクエストの制限を開始します。組み合された長さが200以下の同時リクエスト数に戻るとき、制限は中断されます。
ユーザーが構成したオーバーロード制御は(sipserver.xmlに定義されたように)Oracle WebLogic Server SIP Containerで供給された過負荷保護の最初の重大度レベルを示します。ユーザーが構成したオーバーロード制御は、オーバーロード条件の起動をマークし、ドロップされた呼出しを回避する単純な対策を開始します(新しいリクエストに対して503のレスポンスを生成)。
オーバーロードの原因となった条件が永続化したり悪化した場合は、SIPサーブレット・コンテナでワークの実行に使用するワーク・マネージャ・コンポーネント自体がオーバーロードとなる可能性があります。この時点でサーバーは503レスポンスの生成にスレッドの使用をやめ、そのかわりにドロップ・メッセージを開始します。このように、SIPコンテナのワーク・マネージャ・コンポーネントの構成サイズは、サーバーで使用する過負荷保護の2番目の最終レベルを示します。
sipserver.xmlにおいてはオーバーロード制御を慎重に構成し、適宜オーバーロードを引き起こした状況を解決します。
message-debug要素は、Oracle WebLogic Server SIP Containerのログ・ローテーションを使用したアクセス・ロギングの有効化および構成に使用されます。この要素は、アクセス・ロギングがすべてのSIPリクエストおよびレスポンスをロギングするため、開発環境でのみ使用する必要があります。
RFC 3261では、アウトバウンド・プロキシを「リクエスト-URIによって解決されるサーバーではない場合でも、クライアントからリクエストを受信するプロキシ。通常、UAはアウトバウンド・プロキシを使用して手動で構成されるか、または自動構成プロトコルを通して認識できます」と定義しています。
Oracle WebLogic Server SIP Containerでは、アウトバウンド・プロキシ・サーバーは、sipserver.xmlでproxy要素を使用して指定されます。proxy要素は、1つ以上のプロキシ・サーバーのURIを定義します。proxy-policyタグを使用してプロキシ・ポリシーを設定することによって、プロキシ・プロセスの動作を変更できます。例A-0は、使用可能なproxy要素の値を説明しています。
デフォルト動作は、proxyポリシーが実施されているようなものです。proxyポリシーとは、リクエストが構成されたアウトバウンド・プロキシへ送信され、リクエストのルート・ヘッダーがOracle WebLogic Server SIP Containerによって実行されるルーティング判定を保存することを意味します。これによって、アウトバウンド・プロキシは、リクエスト上でアクションを実行した後に、リクエストを指定した受信者に送信できるようになります。proxyポリシーは、初期リクエストにのみ有効です。後続のリクエストに関しては、ルート設定がダイアログの任意のポリシー全体に優先します。(アウトバウンド・プロキシがルート設定になる場合、レコード・ルーティングをオンにできます。)
また、Oracle WebLogic Server SIP Containerで書き込まれたプロキシ・アプリケーションが、アウトバウンド・プロキシ・トラバースの構成された動作をオーバーライドきする場合、名前が「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 Server SIP Containerドメインのデフォルト・プロキシ構成を示します。この場合のリクエストは、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 Server SIP Containerは、SIPプロトコルのデフォルト値である500ミリ秒を使用します。
この要素は、SIPプロトコルのT2タイマーの値をミリ秒単位で設定します。タイマーT2は、INVITEレスポンスおよびINVITE以外のリクエストの再送信間隔を定義します。SIPタイマーの詳細は、「SIP: Session Initiation Protocol」を参照してください。
t2-timeout-intervalが構成されていない場合、Oracle WebLogic Server SIP Containerは、SIPプロトコルのデフォルト値である4秒を使用します。
この要素は、SIPプロトコルのT4タイマーの値をミリ秒単位で設定します。タイマーT4は、メッセージがネットワーク内に留まる時間の最大長を指定します。また、タイマーT4はタイマーIおよびKの初期値も指定し、これらの値はUDP経由のACKおよびレスポンスの再送信を待機する時間を制御します。
t4-timeout-intervalが構成されていない場合、Oracle WebLogic Server SIP Containerは、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 Server SIP Containerがセッションを無効にするまでに、SIPアプリケーション・セッションが存続時間の最大値を分単位で指定します。max-application-session-lifetimeは、sip.xmlファイルでsession-timeout要素を使用するか、またはsetExpires APIを使用することによって、任意のタイムアウト値の上限として機能します。
-1 (デフォルト)は、構成したタイムアウト値に対する上限が存在しないことを示します。
enable-local-dispatchはサーバーの最適化で、メッセージの送信時および転送時に不要なネットワーク・トラフィックを避けるのに役立ちます。この要素を「true」に設定すると最適化を有効にできます。enable-local-dispatchが有効化されるとき、サーバー・インスタンスがメッセージを送信または転送し、メッセージの宛先がエンジン層クラスタ・アドレスまたはローカル・サーバー・アドレスの場合に、メッセージはネットワーク経由で送信されず、ローカル・サーバーへ内部ルーティングされます。この最適化を使用すると、連鎖アプリケーションが同一リクエストを処理するとき、パフォーマンスを動的に向上できます。
内部メッセージのルーティングがエンジン層のサーバーの負荷を歪めるような気がして、構成されたロード・バランサを通じてすべてのリクエストをルーティングしたいと思うなら、この最適化を無効にするほうがよいでしょう。
デフォルトでは、enable-local-dispatchは「false」に設定されます。
cluster-loadbalancer-map要素は、Oracle WebLogic Server SIP Containerソフトウェアをアップグレードするとき、または本番SIPサーブレットを新しいバージョンへアップグレードするときにのみ使用されます。通常のサーバー操作では不要または使用されません。
ソフトウェアのアップグレード時には、ソフトウェアの古いバージョンと新しいバージョンをホストするために複数のエンジン層クラスタを定義します。A cluster-loadbalancer-mapは、アップグレード用に構成したエンジン層クラスタに対応する仮想IPアドレスを定義します(ロード・バランサ上で定義)。Oracle WebLogic Server SIP Containerはこのマッピングを使用して、呼出し状態データとタイマーに対するエンジン層リクエストが間違いなくクラスタの正しい「バージョン」から受信されるようにします。リクエストがソフトウェアの間違ったバージョンから来た場合、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 Server SIP Containerインスタンスのデフォルト動作を定義します。有効な値は次のようです。
proxy: プロキシ・サーバーとして機能します。
ua: ユーザー・エージェントとして機能します。
proxyは、値を指定しない場合にデフォルトとして使用されます。
ユーザー・エージェント(UA)として機能するとき、Oracle WebLogic Server SIP Containerは、SIPリクエストに応答して次のように動作します。
ACKリクエストは通知なしに破棄されます。
CANCELまたはBYEリクエストはレスポンス・コード481 (トランザクションが存在しない)を受け取ります。
それ以外のすべてのリクエストはレスポンス・コード500 (内部サーバー・エラー)を受け取ります。
プロキシとして機能するとき、構成済の場合にリクエストはアウトバウンド・プロキシ(A.5.4項「proxy: アウトバウンド・プロキシ・サーバーの設定」を参照)へ自動的に転送されます。プロキシが定義されていない場合、Oracle WebLogic Server SIP Containerは、リクエストURIがSIPサーブレット・コンテナの既知のローカル・アドレスまたはサーバーに構成されたロード・バランサ・アドレスのIPおよびポート番号に一致しない場合のみ、指定されたリクエストURIへプロキシします。これによって、リクエストが同一のサーバーへ継続してループしないことが保証されます。リクエストURIがローカル・コンテナ・アドレスまたはロード・バランサ・アドレスに一致するとき、Oracle WebLogic Server SIP ContainerはかわりにUAとして機能します。
この要素は、受信初期リクエストがデプロイ済サーブレットに照合できない場合、呼び出すデフォルトのSIPサーブレットの名前を指定します(sip.xmlで標準のservlet-mapping定義を使用します)。default-servlet-name要素で指定された名前は、デプロイされたSIPサーブレットのservlet-nameの値に一致する必要があります。例:
<default-servlet-name>myServlet</default-servlet-name>
default-servlet-nameで定義される名前がデプロイ済サーブレットに一致しない場合、または値が指定されていない場合(デフォルト構成)、Oracle WebLogic Server SIP Containerはcom.bea.wcp.sip.engine.BlankServletという名前をデフォルト・サーブレットとして登録します。default-servlet-nameとして登録されたデプロイ済のサーブレットがコンテナからデプロイ解除される場合、BlankServletという名前も使用されます。
BlankServletの動作は、default-behavior要素を使用して構成されます。デフォルトでは、サーブレットはすべての一致しないリクエストをプロキシします。ただし、default-behavior要素が「ua」モードに設定されている場合、BlankServletは、CANCELおよびBYEリクエストに対して481レスポンスを戻し、その他のすべての場合には500/416レスポンスを戻します。BlankServletはACKに応答せず、常にアプリケーション・セッションを無効にします。
5xxレスポンスのRetry-Afterヘッダーで使用される秒数を指定します。この値は、「Retry-After: 18000;duration=3600」または「Retry-After: 120 (I'm in a meeting)」などのパラメータまたは理由コードも含みます。
この値が構成されていない場合、Oracle WebLogic Server SIP Containerは、デフォルト値の180秒を使用します。
Oracle WebLogic Server SIP Containerを使用すると、認証が実行される1つ以上の信頼できるホストを構成できるようになります。Oracle WebLogic Server SIP Containerが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 Server SIP Containerでは、S-CSCFルート・ヘッダーは、sipserver.xmlでroute-headerの値として静的に定義される必要があります。例:
<route-header> <uri>Route: sip:wlss1.bea.com</uri> </route-header>
Oracle WebLogic Server SIP Containerは、SIPを認識できるロード・バランサを使用してパフォーマンスを向上するために、エンジン層サーバーが呼出し状態データの一部をローカルおよびSIPデータ層にキャッシュするためのオプションも提供します。ローカル・キャッシュが使用されるとき、エンジン層サーバーはまず既存の呼出し状態データのローカル・キャッシュをチェックします。キャッシュに必要なデータが含まれ、データのローカル・コピーが(SIPデータ層コピーに比べて)最新の場合、エンジンはSIPデータ層の呼出し状態をロックしますが、そのキャッシュから直接読み取ります。
デフォルトでは、エンジン層キャッシュは有効化されています。キャッシュを無効化するには、engine-call-state-cache-enabledをfalseに設定します。
<engine-call-state-cache-enabled>false</engine-call-state-cache-enabled>
Oracle WebLogic Server SIP Containerを使用すると、サーバー・ヘッダーがSIPメッセージに挿入されるタイミングを制御できるようになります。この機能を使用して、ワイヤレス・ネットワークのメッセージ・サイズを削減したり、セキュリティを向上したりするために、サーバー・ヘッダーを制限または削除できます。
デフォルトでは、Oracle WebLogic Server SIP Containerはサーバー・ヘッダーをSIPメッセージに挿入しません。この動作を構成するには、server-headerを次の文字列値のいずれかに設定します。
none (デフォルト)は、サーバー・ヘッダーを挿入しません。
requestは、サーバーによって生成されたSIPリクエストに対してのみサーバー・ヘッダーを挿入します。
responseは、サーバーによって生成されたSIPレスポンスに対してのみサーバー・ヘッダーを挿入します。
allは、すべてのSIPリクエストおよびレスポンスに対してサーバー・ヘッダーを挿入します。
たとえば、次の要素は、すべての生成されたSIPメッセージに対してサーバー・ヘッダーを挿入するようにOracle WebLogic Server SIP Containerを構成します。
<server-header>all</server-header>
詳細は、A.5.20項「server-header-value」を参照してください。
Oracle WebLogic Server SIP Containerを使用すると、生成されたメッセージのサーバー・ヘッダーに挿入されるテキストを制御できるようになります。これによって、SIPメッセージのサイズ全体を追加で制御し、また、セキュリティ上の目的からサーバー・エンティティをマスクできるようになります。デフォルトでは、Oracle WebLogic Server SIP Containerは、サーバー・ヘッダーを生成されたSIPメッセージに挿入しません(A.5.19項「server-header」を参照)。サーバー・ヘッダーの挿入が有効化されていても、server-header-valueが指定されていない場合、Oracle WebLogic Server SIP Containerは「WebLogic SIP Server」という値を挿入します。ヘッダー・コンテンツを構成するには、文字列値を入力します。例:
<server-header-value>MyCompany Application Server</server-header-value>
persistence要素は、RDBMSまたは地理的に冗長なリモートのOracle WebLogic Server SIP Containerインストール(あるいはその両方)への呼出し状態データの書込みを、有効化/無効化することを定義します。地理的に冗長なレプリケーション機能を活用するサイトでは、persistence要素は、呼出し状態データを保持する対象のサイトIDおよびURLも定義します。
persistence要素には、表A-1で説明されているサブ要素が含まれます。
表A-4 ネストされたpersistence要素
| 要素 | 説明 |
|---|---|
default-handling |
Oracle WebLogic Server SIP Containerが、RDBMS永続性または地理的冗長性(あるいはその両方)の永続性ヒントを保持するかどうかを決定します。この要素は、次の値のいずれかを持ちます。
|
geo-site-id |
このインストールのサイトIDを指定します。地理的に冗長なレプリケーションに属するすべてのインストールは一意なサイトIDが必要です。 |
geo-remote-t3-url |
このサイトが呼出し状態データをレプリケートする先のリモートOracle WebLogic Server SIP Containerインストールを指定します。リモート・インストールのエンジン層クラスタに対応する単一のURLを指定できます。また、各エンジン層サーバーに対応するアドレスのカンマ区切りリストも指定できます。URLはt3プロトコルを指定する必要があります。 |
例A-5は、存続期間の長い呼出し状態のRDBMSストレージおよび地理的に冗長なレプリケーションを使用するサンプル構成を示します。呼出し状態はリモート・ロケーションの2つのエンジン層サーバーへレプリケートされます。
この要素は、SIPメッセージにコンパクト・ヘッダーを使用または保持するためのサーバー全体のデフォルト動作を構成します。この要素は、次のいずれかの値に設定できます。
compact: Oracle WebLogic Server SIP Containerは、システムが生成したヘッダーのすべてに圧縮形式を使用します。ただし、発信元のメッセージからコピーされるヘッダー(生成されたものではない)は、元の形式を使用します。
force compact: Oracle WebLogic Server SIP Containerは、すべてのヘッダーに圧縮形式を使用し、既存メッセージのロング・ヘッダーを必要に応じて圧縮ヘッダーに変換します。
long: Oracle WebLogic Server SIP Containerは、システムが生成したヘッダーのすべてに詳細形式を使用します。ただし、発信元のメッセージからコピーされるヘッダー(生成されたものではない)は、元の形式を使用します。
force long: Oracle WebLogic Server SIP Containerは、すべてのヘッダーに詳細形式を使用し、既存メッセージの圧縮ヘッダーを必要に応じてロング・ヘッダーに変換します。
この要素は、Oracle WebLogic Server SIP ContainerのDNS参照機能を有効化/無効化します。この要素を「true」に設定する場合、サーバーは次の目的でDNSを使用できます。
リクエストがSIP URIに送信されるとき、プロキシ・サーバーのトランスポート、IPアドレス、およびポート番号を検出します。
「Sent-by」フィールドの内容に基づいて、レスポンスのルーティングの際にIPアドレスとポート番号を解決します。
プロキシの検出では、Oracle WebLogic Server SIP Containerは、トランスポート、IP、およびポート番号情報を判定するためにSIPトランザクションごとに1回のみDNS解決を使用します。すべての再送信、ACK、またはCANCELリクエストは、同一のトランスポートを使用して同一のアドレスおよびポートに送信されます。DNS解決発現の方法に関する詳細は、RFC 3263: Session Initiation Protocol (SIP): Locating SIP Servers (http://www.ietf.org/rfc/rfc3263.txt)を参照してください。
レスポンス・メッセージの送信にプロキシが必要なとき、Oracle WebLogic Server SIP Containerは、Sent-byフィールドおよびヘッダーによって提供される情報に応じて、宛先のIPアドレスまたはポート番号(あるいはその両方)を決定するためにDNS参照を使用します。
デフォルトでは、DNS解決は使用されません(「false」)。
|
注意: DNS解決はSIPメッセージ処理のコンテキスト内で実行されるため、どのようなDNSパフォーマンス問題でも待機時間パフォーマンス増加の原因となります。潜在的なパフォーマンス問題を削減するために本番環境ではキャッシングDNSサーバーを使用することをお勧めします。 |
Oracle WebLogic Server SIP Containerには、接続プール・メカニズムが含まれます。このメカニズムは、SBC (Session Border Control)機能またはS-CSCF (Serving Call Session Control Function)を使用して通信オーバーヘッドを最小化するために使用できます。接続の複数の固定プールを異なるアドレスに構成できます。
Oracle WebLogic Server SIP Containerは、サーバーが構成されたアドレスにリクエストを送信する必要に応じて、接続プールから新規接続を開きます。次に、サーバーは、新規接続の終了と再作成を繰り返さずに、すでに開かれた接続を使用して新規SIPリクエストをアドレスへ多重送信します。開かれた接続はラウンドロビン方式で再使用されます。開かれた接続は、リモート・アドレスによって明示的に閉じられるまで開いたままになります。
接続再使用プールは、構成されたアドレスからの受信リクエストには使用されません。
接続再使用プールを構成するには、表A-1で説明されているネストされた4つの要素を定義します。
表A-5 ネストされたconnection-reuse-pool要素
| 要素 | 説明 |
|---|---|
pool-name |
文字列の値はこのプールの名前を識別します。すべての構成された |
destination |
宛先SBCまたはS-CSCFのIPアドレスおよびホスト名を指定します。Oracle WebLogic Server SIP Containerは、リクエストを構成されたアドレスに送信するときのみ、このプールで接続を開くか、または再使用します。 |
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 Server SIP Containerが自動的に連絡先およびルート設定ヘッダーに挿入するGRUU (Globally-Routable User Agent URI)を指定できます。この要素で指定されるURIは、Oracle WebLogic Server SIP Containerクラスタ全体のGRUUである必要があります。(単一サーバーのドメインでは、サーバー自体にGRUUを使用します)
Oracle WebLogic Server SIP Containerでデプロイ済ユーザー・エージェント(UA)は、通常、登録リクエスト経由でGRUUを取得します。この場合、アプリケーション・コードはGRUUのリクエストおよび後続の処理を実行します。GRUUをリクエストするには、UAが、GRUUがリクエストされる各Contactで「+sip.instance」という連絡先ヘッダー・フィールドのパラメータを含む必要があります。GRUUを受信すると、UAは新規リクエストを生成するときに連絡先ヘッダー・フィールドのURIとしてGRUUを使用します。
この要素は、Oracle WebLogic Server SIP Containerが実行する1つ以上のドメインを定義します。メッセージが、domain-alias-nameを使用して指定されたドメインに一致する宛先ドメインを持つ場合、Oracle WebLogic Server SIP Containerは、メッセージを転送せずにローカルで処理します。
sipserver.xml構成ファイルは、複数のmain-alias-name要素を持つ可能性があります。各要素は次のいずれかを指定できます。
myserver.mycompany.comなどの個別の完全修飾ドメイン名、または
*.mycompany.comなどの先頭がワイルドカード文字で始まるドメイン名。これはすべての照合ドメインを表すために使用されます。単一のワイルドカード文字のみサポートされているため、ドメイン名の最初の要素として使用する必要があります。
|
注意: また、これらのドメイン名をSipServer管理コンソール拡張の「構成」>「全般」タブの「ドメイン別名」フィールドを使用して識別できます。 |
この要素は、Oracle WebLogic Server SIP Containerが、UACとして機能するときに自動的にrportパラメータをViaヘッダーに追加するかどうかを決定します。デフォルトでは、サーバーはrportパラメータを追加しません。この要素を「true」に設定すると、自動的にrportがサーバーによって生成されたリクエストに追加されます。
|
注意: また、SipServer管理コンソール拡張の「構成」>「全般」タブの「対称レスポンス・ルーティング」オプションを選択することによって、このパラメータを「true」に設定できます。 |
rportパラメータは、RFC 3581 (http://www.ietf.org/rfc/rfc3581.txt)で説明されているように、対称レスポンス・ルーティングに使用されます。メッセージが、Oracle WebLogic Server SIP ContainerなどのRFC 3581に準拠したサーバーによって受信されるとき、サーバーは、Viaヘッダーで指定されたポート番号ではなく、メッセージが受信されたリモートUDPポート番号を使用して応答します。この動作は、ネットワーク・アドレス変換(NAT)を実行するゲートウェイ・デバイスの背後にサーバーが存在するときによく使用されます。NATデバイスは内部および外部のポート番号間のバインドを維持するため、すべての通信はゲートウェイ・ポート経由で発信される必要があります。
Oracle WebLogic Server SIP ContainerはRFC 3581に準拠しているため、enable-rport要素を「false」に設定する場合でも、rportパラメータを適用します。enable-rport要素は、サーバーが自動的にrportを、サーバーがUACとして機能するときに生成するリクエストへ追加するかどうかのみを指定します。rport処理を完全に無効化(RFC 3581対応を無効化)するには、-Dwlss.udp.uas.rport=falseというコマンドライン・オプションを使用してサーバーを起動する必要があります。
|
注意: RFC3581で説明されるrportサポートは、元のSIPリクエストのソース・ポートを含むSIPレスポンスを必要とします。ソース・ポート情報は極秘データとして扱われることが多いので、TLSトランスポートを使用することをお薦めします。 |
この要素は、Oracle WebLogic Server SIP Containerの診断イメージ・ファイルに記録する詳細レベルを指定します。この要素を次の2つの要素のいずれかに設定できます。
basic: 呼出し状態データ以外のすべての診断データを記録します。
full: 呼出し状態データを含むすべての診断データを記録します。
|
注意: イメージ・ファイルへの呼出し状態データの記録には、時間がかかることがあります。デフォルトでは、イメージ・ダンプ・ファイルはbasicオプションを使用して記録されます。
また、SipServer管理コンソール拡張の「構成」>「全般」タブを使用してこのパラメータを設定できます。 |
Oracle WebLogic Server SIP Containerは、メッセージに関連付けられた呼出し状態およびアプリケーション・セッションを識別するために、エンコードされたURIを使用します。アプリケーションがデプロイ解除されるか、または新しいバージョンへアップグレードされるとき、受信リクエストは、呼出し/セッションIDが「無効」または存在しないことを指定するエンコードされたURIを持つ場合があります。stale-session-handling要素を指定すると、Oracle WebLogic Server SIP Containerがリクエスト内で無効なセッション・データを検出するときに、実行するアクションを構成できるようになります。次のアクションが可能です。
drop: エラーをロギングせずにメッセージを削除します。この設定は、Oracle WebLogic Server SIP Containerのインプレース・アップグレード機能を使用してアプリケーションを頻繁にアップグレードするシステムに理想的です。dropアクションを使用すると、デプロイされたアプリケーションの古くて互換性がないバージョンを対象とするメッセージが削除されることが保証されます。
error: UACが問題を修正するように、エラーを含めて応答します。これはデフォルトのアクションです。To:タグを含むメッセージは、481 Call/Transaction Does Not Existエラーを表示し、このタグを含まないメッセージは404 Not Foundエラーを表示します。
continue: 古いセッション・データを無視し、リクエストの処理を継続します。
|
注意: 古いセッション・データを検出するとき、Oracle WebLogic Server SIP Containerは、default-behavior要素の値を考慮する前に、stale-session-handlingによって指定されたアクションを適用します。これは、default-behaviorが、continueアクションを実行するためにstale-session-handlingを構成したときにのみ実行されることを意味します。 |
デフォルトでは、Oracle WebLogic Server SIP Containerは、Toヘッダーを含む信頼性の低い暫定(1xx)レスポンスにContactヘッダーを配置しません。Contactヘッダーがそのような1xxレスポンスに存在することを期待するアプリケーションをデプロイする場合、この要素を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 Server SIP Containerが、custom-app-router-jar-file-name要素を使用して指定するデフォルト、組込みアプリケーションAR (AR)、またはカスタムARを使用するかどうかを決定します。デフォルト値の「false」を指定すると、サーバーはデフォルトARを使用するように構成します。
app-router-config-data要素は、initメソッドでデフォルトまたはカスタム・アプリケーション・ルーター(AR)へ渡すプロパティを定義します。すべての構成プロパティはJavaプロパティ形式に準拠する必要があり、各プロパティは改行やスペースなしに個別に1行で入力される必要があります。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>
-Djavax.servlet.sip.ar.dar.configurationというJavaオプションを含めることによって、Oracle WebLogic Server SIP Containerインスタンスの起動時に、任意でAR初期化プロパティを指定できます。(プロパティ・ファイルを指定するには、URIではなく、file:///という接頭辞を含めます)Java起動オプションを指定する場合、コンテナはapp-router-config-dataで指定された構成プロパティをすべて無視します。プロパティはいつでも変更できますが、-Djavax.servlet.sip.ar.dar.configurationオプションを省略してサーバーが再起動されるまで、プロパティはARへ渡されません。
custom-app-router-jar-file-name要素は、JARファイルとしてパッケージ化された使用するカスタム・アプリケーション・ルーター(AR)のファイル名を指定します。カスタムAR実装は、$DOMAIN_HOME/approuterサブディレクトリに配置される必要があります。
default-application-name要素は、カスタム・アプリケーション・ルーター(AR)が初期リクエストを処理するためのアプリケーションを検出できないとき、コンテナが呼び出すデフォルト・アプリケーション名を指定します。デフォルト・アプリケーションが指定されていない場合、ARがアプリケーションを選択できないとコンテナは500エラーを戻します。
|
注意: アプリケーション名をデフォルト・アプリケーション名の値として指定する前に、アプリケーションをデプロイする必要があります。 |
