表 2-1 解決済みの問題
|
|
|
|
|
SIP リクエストがアプリケーション コードを使用して送信したとき、実際のメッセージはアプリケーションのサービス メソッドを終了した後のみ送信する必要があっても、WebLogic SIP Server が直ちにトランザクション タイマを開始しました。アプリケーション コード (またはシステムの負荷) によりサービス メソッドの終了に遅延が引き起こされた場合、コンフィグレーションされた SIP タイマーが示すよりも短い時間でリクエストの再送信が行われる可能性があります。（極端な例では、アプリケーション リクエストとその再送信がほとんど同時に起こることがあります。）
この問題に対処するため、リクエストとともにタイマー スケジューリングをバッファするようにコードが修正されました。これにより、タイマーの動作の精度が高まります。
|
|
|
以前のバージョンでは、 setCharacterEncoding() は UnsupportedEncodingException を送出しませんでした。このメソッドを呼び出して、 UnsupportedEncodingException に対して catch 句を使用した既存のサーブレット コードは、Weblogic Sip server へのデプロイメントのために再コンパイルする前に修正が必要でした。この問題はコードの修正によって解決されました。
|
|
|
JRockit JVM のある Windows プラットホーム上で WebLogic SIP Server を実行した場合、SSL を使用するために JRockit のネイティブ IO を無効にする必要がありました。ネイティブ IO を無効にしないと、次のような例外が発生しました。
java.io.IOException: couldn't initialize IOPort: The parameter is incorrect.
|
|
|
ACK メッセージのプロキシ中に TooManyHopsException が送出されると、WebLogic SIP Server は ACK へ応答を送信しようとしました。これにより、次の例外が発生しました。
この状況でメッセージをログ記録した後に ACK を削除するように、コードが修正されました。再送信リクエストを受信すると、ACK は UAC によって 再送信されます。
|
|
|
WebLogic SIP Server では、各スキーマに適合しないデプロイメント記述子で SIP アプリケーションをデプロイすることができました。このため、実行時に例外やその他の予期しない動作が発生する可能性がありました。デプロイメント記述子がスキーマに適合しない場合はアプリケーションのデプロイメントを拒否するように、コードが修正されました。
|
|
|
WebLogic SIP Server は、 WLSS-Default-Handler ヘッダが作成されてサーバ コードによって使用される場合でも、このヘッダに対して「unknown header」メッセージがログされることがあります。ヘッダが登録され、エラー メッセージは生成されなくなりました。
|
|
|
TCP でリクエストをプロキシするときに IOException が発生した場合、WebLogic SIP Server は例外をログ記録しましたが、最終的な応答を送信しませんでした。そのため、UAC では Invite リクエストが正常にプロキシされたかどうかわかりませんでした。プロキシ時に転送エラーを検出し、エラーに対応するために 503 エラー応答を作成して送信するように、コードが修正されました。
|
|
|
最初のリクエスト時ではなく 起動時にサーブレットを初期化するためにサーブレットが load-on-startup デプロイメント記述子を使用し、 init メソッドが新しい呼び出し状態を作成した場合、SIP データ層のいずれかのパーティションがまだオンラインになっていないと、WebLogic SIP Server は次の例外を送出しました。
次の条件をすべて満たす場合はサーブレットの初期化を遅らせるように、コードが修正されました。
サーブレットが load-on-startup を使用する。 サーブレットが SipServlet.init メソッドをオーバーライドする。 サーブレットが管理サーバにデプロイされていない。 コンフィグレーション済みのパーティションがまだオンラインでない。
初期化の遅延は管理サーバのデプロイメントには適用されないことに注意してください。遅延でレプリカ サーバがロードできなくなるためです。プロダクション システム内の管理サーバにはどのようなアプリケーションもデプロイしないでください。
|
|
|
WebLogic SIP Server は 30 秒間一定の負荷を使用しました。これにより、パフォーマンスが落ち、 wlss.transport ワーク マネージャ キューで定期的に負荷が上がり、過負荷状態が続きました。最初の過負荷期間を 512 ミリ秒に設定し、過負荷状態の反復的な発生に応じて期間を動的に長くなるように、コードが修正されました。
|
|
|
Windows プラットフォーム上で、他のフォルダにネストされている WebLogic SIP Server 製品をインストールすると、パスが長すぎるため Administration Console 拡張がロードできませんでした。この問題に対処するために、管理サーバを起動する前に次の環境変数を設定する必要がありました。
set JAVA_OPTIONS=-Dweblogic.j2ee.application.tmpDir=d:/TEMP
このオプションは、サーバ起動スクリプト commEnv.sh に自動的に含まれるようになりました。
|
|
|
WebLogic SIP Server では、デプロイ済みの SIP アプリケーションの廃棄バージョンに SIP リクエストがアクセスできました。この動作は、ベースとなる Weblogic Server アプリケーションのアップグレード機能と整合性がありませんでした。そのため、廃棄バージョンへの HTTP リクエストは許可されません。たとえば、コンバージド SIP アプリケーションを破棄した場合、アプリケーションへの SIP リクエストは許可されますが、HTTP リクエストは拒否されました。WebLogic Server の動作と整合性を保つようにコードが修正されました。現在は、WebLogic Server は、SIP リクエストは廃棄バージョンへのアクセスは許可されません。
|
|
|
以前の WebLogic SIP Server バージョンでは、 SipServletMessage.setCharacterEncoding() メソッドを介して設定されたエンコーディングは無視され、 setContent() メソッドの contentType 引数を使用して設定されたエンコーディングだけが受け入れられました。この問題はコードの修正によって解決されました。
|
|
|
SIP コンテナ ランタイム Mbeans は、互換性のある MBean サーバといっしょに登録されませんでした。このため、次のような例外が発生する可能性がありました。
|
|
|
地理的に冗長なインストールで WebLogic SIP Server を使用する場合、セカンダリ サイトへの各書き込みで次のようなエラーメッセージが記録されることがありました。
<Dec 13, 2006 12:48:08 PM PST> <Error> <Security> <BEA-090513> <ServerIdentity failed validation, downgrading to anonymous.>
|
|
|
WebLogic SIP Server には、SCTP 接続のためのタイムアウト時間をコンフィグレーションする方法がありませんでした。カスタム チャネル プロパティ SctpConnectTimeoutMillis を受け入れてプロパティをコンフィグレーションできるように、コードが修正された。「ネットワーク リソースのコンフィグレーション」の「 カスタム タイムアウト、MTU および他のプロパティのコンフィグレーション」を参照してください。
|
|
|
WebLogic SIP Server では、PRACK メッセージの To ヘッダ内のタグ パラメータが削除されることがありました。PRACK メッセージに必ず To タグが含まれるように、コードが修正されました。
|
|
|
Sun JVM を使用すると、Sun Sparc Enterprise T2000 サーバ上で WebLogic SIP Server のスケーラビリティ パフォーマンスが低下しました。これらのパフォーマンスの問題は、Sun JVM のリリース 13 で対処されます。
|
|
|
アプリケーションが SipServletSnmpTrapRuntimeMBean を使用して do xxx メソッドの外に SNMP トラップを生成すると、WebLogic SIP Server が NullPointerException を送出しました。 do xxx メソッドの外にトラップを生成できるように、コードが修正されました。 doxxx メソッドの外に生成するトラップは、Servlet 名ではなく、「Non Sip-Servlet Scope Application」文字列を使用することに注意してください。
|
|
|
Diameter 実装で、 Requested-Action AVP の CHECK_BALANCE 値および PRICE_ENQUIRY 値に対し不正な値 (3 および 4) が使用されました。 RFC4006 に記載されている正しい値 (2 および 3) を使用するように、コードが修正されました。
|
|
|
Diameter 実装で、Diameter アプリケーションが ASR リクエストを受信して処理できませんでした。これは、Diameter アプリケーションが終了 CCR に AVP を追加できなかったか、セッションの終了時に通知を受けなかったことを意味します。 SessionListener が登録されている場合は、Diameter 実装が処理のためにアプリケーション リスナに ASR リクエストを渡すように、コードが修正されました。この場合、CCR の生成と ASA の送信はアプリケーションが行う必要があります。
|
|
|
Oracle Communications Converged Application Server では、Administration Console の [モニタリング｜チャネル] タブで UDP を使用するネットワーク チャネルのモニタリングがサポートされませんでした。この問題はコードの修正によって解決されました。
|
|
|
RO アプリケーションだけをコンフィグレーションすると、Diameter CER には Supported-Vendor-Id AVP がありませんでした。1 つまたは複数の supported-vendor-id 要素において、 diameter.xml 内の Supported-Vendor-Id 値をコンフィグレーションできるように、コードが修正されました。
|
|
|
JRockit JVM を使用すると、Sun Sparc Enterprise T2000 サーバ上での WebLogic SIP Server のスケーラビリティ パフォーマンスが低下しました。これらのパフォーマンスの問題は、 JRockit R27.3.1 へのパッチで解決されました。
|
|
|
レプリケートされないインストールによってパフォーマンスを向上させるため、RDBMS 永続性が Oracle Communications Converged Application Server に対して可能な場合はいつでもローカル シリアライゼーションが実行されます。RDBMS 永続性機能がデフォルトで、すべてのインストールに対して可能となっているため、リプリケートされたドメインにおいてもローカル シリアライゼーションがデフォルトで実行されています。ただし、ローカル シリアライゼーションが、リプリケートされたドメインの機能によって使用されないことと、そうした機能を妨害しないことに注意してください。
|
|
|
バッファ オーバーフロー攻撃の可能性を減少させるために、Oracle Communications Converged Application Server は UDP メッセージの総サイズを 64K に制限します。
TCP メッセージ ヘッダはデフォルトで前のリリースのように 2048 バイトに制限されます。ただし、起動時に TCP ヘッダ サイズは必要に応じて、 -Dwlss.header.maxSize=size オプションを指定することで増加できます。
|
