5 SIPアプリケーションの構成

この章では、Oracle WebLogic Server SIP Containerアプリケーションの構成機能を使用する方法を説明します。内容は次のとおりです。

• 5.1項「アプリケーション構成モデル」

• 5.2項「デフォルト・アプリケーション・ルーターの使用」

• 5.3項「カスタム・アプリケーション・ルーターの構成」

• 5.4項「セッション・キーに基づくリクエストのターゲット」

  
  

  注意: SIPサーブレットv1.1仕様(http://jcp.org/en/jsr/detail?id=289)では、正式なアプリケーションの選択および構成処理が説明されており、これはOracle WebLogic Server SIP Containerに完全に実装されています。新規の開発についてはすべて、このドキュメントで説明されているSIPサーブレットv1.1の手法を使用します。Oracle WebLogic Server SIP Containerの前のバージョンで説明されているアプリケーション構成手法は非推奨になっています。 Oracle WebLogic Server SIP Containerでは、次の場合にかぎって、バージョン1.0の構成手法を使用してアプリケーションに下位互換性を提供します。 カスタム・アプリケーション・ルーターを構成しない場合、および デフォルトのアプリケーション・ルーター・プロパティを構成しない場合。

  
  

5.1 アプリケーション構成モデル

アプリケーション構成は、SIPリクエストにサービスを適用するための複数のSIPアプリケーションを論理パスにチェーンする処理です。SIPサーブレットv1.1仕様は、SIPアプリケーションの構成に重要な役割を果たすアプリケーション・ルーター(AR)デプロイメントを導入します。アプリケーション・ルーターは、初期のSIPリクエストを調べて、カスタム・ロジックを使用して、リクエストを処理するSIPアプリケーションを決定します。Oracle WebLogic Server SIP Containerでは、初期リクエストが、まずリクエストを処理するのに使用するアプリケーションを決定するARに送信されます。

Oracle WebLogic Server SIP Containerでは、テキスト・ファイルを使用して構成できるデフォルト・アプリケーション・ルーターを提供します。ただし、ほとんどのインストールでは、SipApplicationRouterインタフェースを実装することでカスタム・アプリケーション・ルーターを開発およびデプロイします。カスタム・アプリケーション・ルーターを使用すると、リクエストを処理するSIPアプリケーションを決定するときデータ・ストアを調べることができます。

アプリケーション・ルーターと違って、メッセージを処理するために使用可能なSIPアプリケーションの情報を必要としません。個々のSIPアプリケーションがお互いに独立しています。個別のアプリケーションは、システムにデプロイされている他のアプリケーションを認識する必要がなく、SIPリクエストに対して特定のサービスを実行します。(アプリケーション・ルーターにはデプロイされているアプリケーションの認識が必要で、SipApplicationRouterインタフェースによって自動的にアプリケーションのデプロイメントおよびアンデプロイメントが通知されます。)

個別SIPアプリケーションは、プロキシ処理またはリレー処理で初期リクエストの処理を完了するか、UAS(User Agent Server)としてリクエストを終了します。初期リクエストがプロキシまたはリレーされていた場合、SIPコンテナによってリクエストが再びアプリケーション・ルーターに転送され、リクエスト用のサービスを提供する次のSIPアプリケーションが選択されます。このように、ARはリクエストを処理するのに必要である複数のSIPアプリケーションをチェーンすることができます。チェーン処理が次の場合に、終了されます。

• 選択したSIPアプリケーションはチェーンを終了させるUASとして動作する場合、または

• そのリクエストに対して選択できるアプリケーションがない場合(この場合、リクエストが出力されます。)

チェーンが終了され、リクエストが送信された場合、SIPコンテナは、後続のリクエストを処理するためにアプリケーションの定義されたパスを使用します。ARは調べられません。

図5-1は、アプリケーション・ルーターを使用してSIPリクエストに複数のサービスを適用する方法を示します。

図5-1 構成されたアプリケーション・モデル

「図1-5 構成されたアプリケーション・モデル」の説明

ARはリモートおよびローカルの両方のアプリケーションを選択でき、サービスのチェーンを同じOracle WebLogic Server SIP Containerコンテナに配置する必要はありません。

5.2 デフォルト・アプリケーション・ルーターの使用

Oracle WebLogic Server SIP Containerには、基本機能のあるDAR(デフォルト・アプリケーション・ルーター)が含まれており、基本機能はSIPサーブレット仕様v1.1(http://jcp.org/en/jsr/detail?id=289)の付録C「Default Application Router」に説明されています。Oracle WebLogic Server SIP Container DARは、SipApplicationRouterインタフェースのメソッドをすべて実装し、v1.1仕様で説明されている単純なJavaプロパティ・ファイルを使用して構成されます。

DARプロパティ・ファイルの各行に1つ以上のSIPメソッドが指定され、カンマで区切った形式でSIPルーティング情報も指定されます。起動時にDARは最初にプロパティ・ファイルを読み込みます。また、SIPアプリケーションがコンテナにデプロイまたはアンデプロイされるたびにもプロパティ・ファイルを読み込みます。

DARによって使用される構成ファイルの場所を指定するには、「カスタム・アプリケーション・ルーターの構成」の説明に従って管理コンソールを使用してプロパティを設定するか、またはOracle WebLogic Server SIP Containerインスタンスを起動するときに次のパラメータを含めます。

-Djavax.servlet.sip.ar.dar.configuration

(プロパティ・ファイルを指定するには、URIではなく、file:///という接頭辞を含めます)。このJavaパラメータはコマンド・ラインで指定されるため、サーバー起動スクリプトに含めることができます。

デフォルト・アプリケーション・ルーターで使用されるルーティング情報の形式の詳細は、SIPサーブレット仕様v1.1(http://jcp.org/en/jsr/detail?id=289)の付録Cを参照してください。

Oracle WebLogic Server SIP Container DARでは、「発信」、「終了」、「ニュートラル」のほかにルート・リージョン文字列を受け入れます。新しい各文字列値は、拡張されたルート・リージョンとして扱われます。また、Oracle WebLogic Server SIP Container DARでは、構成ファイルのプロパティの順序を使用してルート・エントリ・シーケンスを判定します。state_info値は、DAR構成で指定される場合効果がありません。

5.3 カスタム・アプリケーション・ルーターの構成

デフォルトでは、Oracle WebLogic Server SIP Containerは、独自のDAR実装を使用します。

カスタム・アプリケーション・ルーターを開発する場合、ARの実装をドメイン・ホーム・ディレクトリの/approuterサブディレクトリに保存する必要があります。ARのサポートティング・ライブラリは、/approuter内の/libサブディレクトリに保存できます。(SipApplicationRouterの複数の実装があれば、どちらを使用するかを指定するには、起動時に-Djavax.servlet.sip.ar.spi.SipApplicationRouterProviderのオプションを使用します)。

注意: クラスタ環境の場合、カスタムARはドメインの全体のエンジン層インスタンスにデプロイされます。同じドメインに別のAR実装がデプロイできません。

AR機能の詳細は、SIPサーブレット仕様v1.1(http://jcp.org/en/jsr/detail?id=289)の15項を参照してください。カスタムARを実装する方法の詳細は、SIPサーブレットv1.1 APIを参照してください。

5.4 セッション・キーに基づくリクエストのターゲット

SIPサーブレット・バージョン1.1の仕様では、初期リクエストを既存のSipApplicationSessionオブジェクトに関連付けるためのメカニズムも提供します。このメカニズムはセッション・キー・ベースのターゲットと呼ばれます。セッション・キー・ベースのターゲットを使用して、特定のサブスクライバ(リクエストURI)、地域またはその他の機能を持つ初期リクエストを、新しいセッションを生成することなく、既存のSipApplicationSessionに送ります。アプリケーションにおいてこのターゲットのメカニズムを使用するには、一意のキーを生成するメソッドを作成し、このメソッドに@SipApplicationKeyアノテーションを付けます。SIPコンテナがアプリケーションを選択する場合(たとえば、初期リクエストに対してARによって選択されたアプリケーション)、アノテーション付きのメソッドを使用してキーを取得します。そして、SipApplicationSessionが存在するかどうかを判別するには、キーおよびアプリケーション名を使用します。存在する場合、コンテナは、新しいセッションを生成ではなく、既存のセッションに新しいリクエストを関連付けます。

注意: ターゲットのメカニズムを使用してスパイラル・プロキシ・アプリケーションを開発し、アプリケーションによって複数回にレコード・ルーターが変更される場合は、レコード・ルーター・ホップの実行時に、必要に応じて、初期リクエストに対して異なるキーが生成される必要があります。生成されない場合、アプリケーションは後続リクエスト用のレコード・ルーター・ホップを差別できません。

セッション・キー・ベースのターゲットの使用の詳細は、SIPサーブレット仕様v1.1(http://jcp.org/en/jsr/detail?id=289)の15項を参照してください。