この章では、SIP サーブレット v1.0 仕様に基づく既存のアプリケーションの Oracle WebLogic Communication Services への移植に関するガイドラインと問題点、および SIP サーブレット v1.1 の仕様について説明します。以下の節で構成されています。
SIP サーブレット v1.1 仕様では、OWLCS で完全に実装された正式アプリケーションの選択と構成処理について説明します。すべての新しい開発に対して SIP Servlet v1.1 の手法を使用します。OWLCS の以前のバージョンで説明したアプリケーション構成手法は非推奨になっています。
OWLCS では、以下の条件に限って SIP サーブレット バージョン 1.0 の構成手法を使用してアプリケーションに下位互換性を提供します。
カスタム アプリケーション ルータがコンフィグレーションされない。
また、デフォルトのアプリケーション ルータ プロパティがコンフィグレーションされない。
SIP サーブレット v1.1 仕様では、SipSession
および SipApplicationSession
インタフェースをシリアライズできません。OWLCS は、旧 v1.0 仕様のバイナリ互換性を維持します。したがって、これらのインタフェースをシリアライズ可能なオブジェクトとして扱うコンパイルされたアプリケーションも操作できます。ただし、このアプリケーションを OWLCS で再コンパイルする前に、アプリケーションのソース コードを変更する必要があります。
TimerService.createTimer
API を使用して、SipSession
をシリアライズ可能な Info オブジェクトとして保存するバージョン 1.0 サーブレットでは、SipSession
ID をシリアライズ可能な info
オブジェクトとして保存することによって同様な機能を達成できます。タイマー有効期限のコールバックを受け取ったら、アプリケーションが SipApplicationSession
および ServletTimer
によって返されたシリアライズされた ID オブジェクトを使用して SipApplicationSession
内に、取得された ID で SipSession
を検索する必要があります。詳細については、SIP Servlet v1.1 API JavaDoc を参照してください。
SipServletResponse.setCharacterEncoding()
は UnsupportedEncodingException
を送出しなくなりました。このメソッドで UnsupportedEncodingException
を明示的に捕捉するアプリケーションがある場合、既存のコンパイルされたアプリケーションを変更せずにそのまま OWLCS にデプロイできます。ただし、再コンパイルする前に例外を捕捉しないように、ソースコードを変更する必要があります。
SIP サーブレット v1.1 は SipServletRequest
および SipServletResponse
オブジェクトが SIP トランザクションに属することを認証します。仕様では、メッセージのコミットの条件も定義されます。これをした後、どのアプリケーションもメッセージを変更または、再送信できません。SIP メッセージをコミットする条件のリストについては、『SIP サーブレット仕様 v1.1』 (http://jcp.org/en/jsr/detail?id=289
) の「5.2 暗黙的なトランザクション状態」を参照してください。
この変更により、コミットされたメッセージを変更 (ヘッダの設定、追加または削除)、または送信しようとする場合、IllegalStateException
が発生されます。既存のコードによって、SipServletMessage.isCommitted()
を使用して、メッセージを変更または送信する前に、メッセージがコミットされいることを確認する必要があります。
SIP サーブレット v1.1 は、さまざまな SIP ヘッダのパラメータをアクセス、作成、および変更するために新しい javax.servlet.sip.Parameterable
インタフェースを紹介します。表 D-1 に示したシステム ヘッダ パラメータは不変であり、この新しいインタフェースを使用して変更できないことに注意してください。
表 D-1 不変なシステム ヘッダ パラメータ
ヘッダ |
不変パラメータ |
From |
タグ |
To |
タグ |
Via |
branch、received、rport、wlsslport、wlssladdr、maddr、ttl |
Record-Route |
すべてのパラメータは不変です。 |
Route |
初期リクエストの場合、Route ヘッダをプッシュするアプリケーションは、ヘッダのパラメータを変更できます。他の場合、Route ヘッダのパラメータは不変です。 |
Path |
登録リクエストの場合、Path ヘッダをプッシュするアプリケーションは、ヘッダのパラメータを変更できます。他の場合、Path ヘッダのパラメータは不変です。 |
OWLCS 内のアプリケーションでは、プロキシがいつもトランザクション的にステートフルであることを必要とします。プロキシ オブジェクトをステートレスに設定しても効果がありません。
Proxy.setStateful()
および Proxy.getStateful()
メソッドが冗長です。Proxy.getStateful()
は常に true を返し、Proxy.setStateful()
は操作しません。
OWLCS は、コンパイル済みの v1.0 デプロイメントを自動的に検出し、下位互換性を保持するために、SIP コンテナの動作を変更します。以下の節では、v1.0 SIP サーブレットを OWLCS にデプロイするときに発生する動作の違いについて説明します。
SIP サーブレット v1.1 仕様では、サーブレット デプロイメントの、以前の仕様より厳密検証を必要とします。以下の場合、v1.0 SIP サーブレットが正常に OWLCS にデプロイされますが、デプロイメント時に警告メッセージが表示されます。
v1.0 のデプロイメント記述子の listener-class
要素にリスナーが宣言されますが、対応するクラスは EventListener
インタフェースを実装していない場合、デプロイメント時に警告が表示されます。(リスナーを宣言するバージョン 1.1 SIP サーブレットは EventListener
を実装する必要があります。そうしなければアプリケーションをデプロイすることができません)。
v1.0 のデプロイメント記述子の servlet-class
要素に SIP サーブレットが宣言されますが、対応するクラスは SipServlet
抽象クラスを拡張しない場合、警告が表示されます。(バージョン 1.1 SIP サーブレットは SipServlet
を拡張する必要があります。そうしなければアプリケーションをデプロイすることができません)。
SIP サーブレット v1.1 仕様では、アプリケーションがコミット メッセージを変更しようとすると、SIP コンテナが IllegalStateException
を送出することを推奨しています。下位互換性を保つために、OWLCS は、バージョン 1.1 SIP サーブレット デプロイメントにより、コミット メッセージが変更される場合のみ、IllegalStateException
を送出します。
SIP サーブレット v1.1 仕様では、Path
ヘッダがシステム ヘッダとして定義されます。これはアプリケーションによって変更できなくなりました。バージョン 1.0 SIP サーブレットでは Path
ヘッダを変更しようとすると、警告メッセージが生成されます。バージョン 1.0 SIP サーブレットは Path
ヘッダの変更を試行している場合、IllegalArgumentException
で失敗します。
OWLCS では、SipServletResponse.createPrack()
によってバージョン 1.1 SIP サーブレットの場合のみ、Rel100Exception
が送出されます。下位互換性を保つするために、createPrack()
はバージョン 1.0 SIP サーブレットの場合、例外を送出しません。
バージョン 1.1 SIP サーブレットによって Proxy.proxyTo(uri)
または Proxy.proxyTo(uris)
で重複するブランチ URI が指定された場合、OWLCS によって IllegalStateException
が送出されます。下位互換性を保つするために、バージョン 1.0 SIP サーブレットがこれらのメソッドで重複する URI を指定された場合、OWLCS によって無視されます (例外が送出されません)。
SIP サーブレット v1.1 では、シーケンシャルやパラレルの両方のプロキシ処理のプロキシ分岐の行動に影響をもたらすいくつかのプロトコルの変更があります。
v1.1 仕様では、シーケンシャル プロキシ処理については、OWLCS によって、sip.xml
または SIP プロトコル Timer C (3 分以上) にコンフィグレーションされた sequential-search-timeout
の最大な値を使用してブランチ タイマーを起動することを必要とします。OWLCS の旧バージョンでは、常に sequential-search-timeout
の値を使用してシーケンシャル ブランチ プロキシ タイムアウトが設定されます。この動作は v1.0 デプロイメントに対して維持されます。
パラレル プロキシ処理について、v1.1 仕様は、プロキシ処理をコントロールする新しい proxyTimeout
値を提供します。この仕様は、OWLCS が、SIP サーブレット v1.0 仕様.が必要とする Timer C 値ではなく、コンフィグレーションした proxyTimeout
値を使用してブランチ タイマーをリセットすることを必要とします。Timer C 値は v1.0 デプロイメントのためにまだ使用されます。
WebLogic SIP Server の以前のバージョンは、SIP サーブレット v1.0 仕様でサポートされない機能および RFC をサポートするため、独自の API を提供します。SIP サーブレット v1.1 仕様により、新しい RFC サポートおよび機能が追加され、独自の API が冗長になります。表 D-2 には、非推奨となった WebLogic SIP Server のメソッドの代わりに使用できる新しい SIP サーブレット v1.1 メソッドを示します。v1.0 アプリケーションに下位互換性を提供するため、非推奨のメソッドはまだこのリリースで利用可能です。
表 D-2 非推奨となった API
非推奨のメソッド (WebLogic SIP Server 独自) |
置き換えメソッド (SIP サーブレット v1.1) |
|
|
|
|
|
|
|
|
|
表 6–1「コンバージド アプリケーションのセッション」を参照してください。 |
OWLCS の前のバージョンの SNMP MIB 定義は WebLogic MIB の命名規約に準拠していませんでした。特に、MIB テーブル カラム名のラベルはテーブル名から始まっていません。OWLCS は、WebLogic の命名規約に準拠するおよびメタデータ ファイルを生成する WebLogic ツールとの互換性を提供するためにラベルの先頭に sipServer
を追加します。
たとえば、バージョン 3.x での SipServerEntry
MIB 定義は以下に示します。
SipServerEntry ::= SEQUENCE { sipServerIndex DisplayString, t1TimeoutInterval INTEGER, t2TimeoutInterval INTEGER, t4TimeoutInterval INTEGER, .... }
OWLCS での定義は以下のようになります。
SipServerEntry ::= SEQUENCE { sipServerIndex DisplayString, sipServerT1TimeoutInterval Counter64, sipServerT2TimeoutInterval INTEGER, sipServerT4TimeoutInterval INTEGER, ..... }
アプリケーションまたはスクリプトが直接に MIB テーブル カラム名のラブルを使用している場合は、この MIB の変更により下位互換性の問題が生じる場合があります。テーブル名を先頭にするように、iso.org.dod.internet.private.enterprises.bea.wlss.sipServerTable.t1TimeoutInterval
のようなハードコード化されたラベルをすべて変更する必要があります (iso.org.dod.internet.private.enterprises.bea.wlss.sipServerTable.sipServerT1TimeoutInterval
) 。
注意 : 常に、クライアントサイドの SNMP ツールによって MIB がロードされ、MIB のロードされたラベルに基づく値を取得するコマンドが発行されます。これらのツールは上記の変更に影響を受けません。OWLCS の完全な MIB ファイルは $WLSS_HOME/server/lib/wlss/BEA-WLSS-MIB.asn1 としてインストールされます。 |
OWLCS において提供された診断モニタと診断アクションの先頭に occas/
が付加されます。たとえば、SIP Server 3.1 Sip_Servlet_Before_Service
モニタは今 occas/Sip_Servlet_Before_Service
として名付けられます。既存のどんな診断コンフィグレーション ファイルまたは OWLCS と連動できる前のプレフィックスでない名前を参照するアプリケーションを更新する必要があります。