第 3 章 Communications Server の既知の問題点と制限事項

ここでは、Communications Server ソフトウェアに関する既知の問題とそれに関連する解決策について説明します。問題の説明にプラットフォームが明記されていない場合、その問題はすべてのプラットフォームに当てはまります。この節は次の項目から構成されています。

• 「Communications Server の管理」

• 「融合ロードバランサ」

• 「グローバル化」

• 「インストール」

• 「セキュリティー」

• 「SIP コンテナ」

Communications Server の管理

SIP/SIPS ポートがバインドされなくても Communications Server インスタンスが起動する (Issue Number 998)

説明

SIP または SIPS ポートをバインドできない場合でも、Communications Server インスタンスが起動します。

解決方法

サーバーインスタンスを起動する前に、ポートが開放されていることを確認します。ログファイル (server.log) で、起動時に SIP コンテナのエラーや例外が発生していないことを確認します。

ログファイルの表示方法については、TBDlink を参照してください。

Communications Server が、––javahome オプションで指定した JDK を使用しない (Issue Number 789)

説明

––javahome オプションを使用すると、デフォルトのバージョンの代わりにインストール済みの JDK をインストールで使用できます。デフォルトでは、Communications Server は as-install/jdk の JDK バージョンを使用します。

解決方法

asenv.conf ファイルの AS_JAVA 変数は、常に as-install/jdk をポイントします。別のバージョンの JDK を使用する場合は、asenv.conf ファイルを手動で更新し、AS_JAVA の値を変更します。

3.5G バイトの Java ヒープを使用すると、トラフィックが存在する間にインスタンスが再起動する (Issue 1169)

説明

JVM ヒープサイズが 3.5G バイトに設定されている場合、トラフィックを受信するとインスタンスでエラーが発生し再起動します。

解決方法

最大の JVM ヒープサイズが 3.0G バイト以下に設定されていることを確認します。JVM ヒープサイズを変更する手順については、TBDlink を参照してください。

マルチコアシステムで 1 つのコアだけを使用しているときに、Communications Server による CPU 使用状況のレポートが正しくない (Issue 1344)

説明

Solaris プラットフォームでは、Communications Server は CPU 使用状況を、利用可能なプロセッサの数とコアごとの CPU 使用状況に基づいて計算します。このとき、Communications Server は JVM が使用しているコアの数ではなく、コアの数の静的な値を使用して計算を行います。

解決方法

マシンのすべてのコアが使用されていない場合は、CPU のしきい値を再計算してください。

融合ロードバランサ

融合ロードバランサの asadmin コマンドを使用すると、ドメインのステータスが「Restart required」に変化する (Issue 333)

説明

融合ロードバランサに関連する asadmin コマンドを使用すると、ドメインを再起動する必要がない場合でも、ドメインステータスが「Restart required」に変更されます。ドメインステータスは asadmin list-domains コマンドで確認できます。

解決方法

ドメインの再起動は必要ありません。ドメインステータスを無視してください。

アプリケーション配備のあとに融合ロードバランサの動的再構成によって、ログに SEVERE メッセージが記録される (Issue 1161)

説明

ターゲットで融合ロードバランサの構成を変更してアプリケーションを再配備する場合、インスタンスのログに SEVERE メッセージが記録されます。

解決方法

これらのメッセージは、融合ロードバランサやその他のインスタンスの動作に影響しません。メッセージを無視してください。

完全 URI を使用すると、Contact ヘッダーの BEKey パラメータが正しくエスケープされない (Issue 1466)

説明

融合ロードバランサで、BEKey パラメータに完全な URI を返すデータ中心ルールファイルを使用すると、Contact ヘッダーの BEKey パラメータが正しくエスケープされません。RFC 3261 で説明されているように、「:」文字は正しくエスケープされません。

解決方法

現在のところ解決策はありません。

グローバル化

融合ロードバランサに関するオンラインヘルプが日本語と韓国語に関して抜け ている (1564)

説明

「融合ロードバランサ」もしくは「融合ロードバランサを編集する」画面に おいて、ブラウザの優先言語が日本語もしくは韓国語に設定された状態でユー ザーがヘルプボタンをクリックすると 404 エラーが表示されます。これらの抜 けているページは課題 1562 で報告されているものに関連しています。英語と比 較した場合、融合ロードバランサに関する下記のファイルが存在しません。 clbconfigsettings.html clbdetails.html clbmanageclbhostingtargets.html clbmanageclbreftargets.html clbnew.html clbreftargetdetails.html clbreftargets.html clbs.html

解決方法

ユーザーがブラウザの優先言語を英語に設定します。

インストール

Communications Server インストーラが Linux でクラッシュする (6739013)

説明

この問題は、環境変数 MALLOC_CHECK_ に 2 を設定して Linux を実行しているシステムで観察されています。

解決方法

環境変数 MALLOC_CHECK_ を 0 に設定してください。export コマンドを次のように実行します。

export MALLOC_CHECK_

セキュリティー

trust-auth-realm-ref プロパティーが sun-sip.xml に指定されていない場合、Communications Server が例外をスローする (CR 6786131)

説明

sun-sip.xml で P-Asserted-Identity が設定されているときに、レルムが設定されていないと、Communications Server が Null ポインタの例外をスローします。

解決方法

sun-sip.xml で trust-auth-realm-ref プロパティーを使用してレルムを設定します。このプロパティーの設定については、TBDlink を参照してください。

SIP コンテナ

SIP コンテナが 100 の応答を送信したときに CANCEL を処理できない (Issue 712)

説明

100 の応答が送信された場合、SIP コンテナは CANCEL 要求を処理できません。

解決法

アプリケーションはプロビジョナルな応答 (1xx など) を送信して、リモート側が INVITE 要求に対して CANCEL を実行できるようにする必要があります。

SIP セッションおよび HTTP セッションに、同じセッション有効期限モデルが適用されない (Issue 1180)

説明

SIP セッションのセッション有効期限モデルは、HTTP の有効期限ロジックと異なります。HTTP の場合、HTTP セッション内で新しい HTTP 要求を受信すると、アプリケーションによる制御を必要とせずに、自動的にセッションが延長されます。

SIP セッションの場合、SIP コンテナによって許可されれば、アプリケーションが SipApplicationSession (SAS) の期間を管理します。アプリケーションは setExpires メソッドを使用して、SAS の有効期限を指定できます。setExpires は、setExpires メソッドが呼び出された時点からの相対時間で有効期限を定義します。コンテナは、setExpires で指定された期限を変更、拒否、または承諾することができます。セッションが無効になっていない場合は、setExpires で定義された時間に、sessionExpired のコールバックが実行されます。このコールバックで、再度コンテナによって変更、拒否、または承諾されれば、アプリケーションは新しい setExpires を呼び出して、SAS の期限の延長を試みることができます。

このため、HTTP セッション上で同じ有効期限の SipApplicationSession (SAS) で開始される融合アプリケーションは、HTTP セッションが新しいリクエストを受信した場合、HTTP セッションの前に SAS の有効期限が切れることを通知されます。

解決方法

SIP セッションおよび HTTP セッションを処理する有効期限が異なる場合は、アプリケーションセッションが存続すると予想される (いくつかの HTTP リクエストを含む)、十分な長さの SAS 有効期限を指定して開始することが最善の方法です。特に、invalidateWhenReady セマンティクスが使用されている場合は、SAS の有効期限を無期限に設定することもできます。この場合、最後のプロトコルの子セッションが無効になるときに、SipApplicationSession が無効になります。SAS の初期有効期限は、配備記述子で設定できます。

最大の総期間を前もって予測できて、追加のコードが必要ない場合は、SAS の期限が切れるときに SIP セッションと HTTP セッションの両方を無効にするのが適切です。最大期間を予測できない場合は、次のコードスニペットのように、SipApplicationSession を延長できます。

SipApplicationSessionListener の実装で、次のような処理を行えます。

public void sessionExpired(SipApplicationSessionEvent sasEvent) {

                // check if the SAS needs to be extended first, if so:

		int granted = sasEvent.getApplicationSession().setExpires(2);

		if (granted <= 0) {

			System.out.println("extension rejected");

		} else if (granted < 2) {

			System.out.println("extension granted with lower value " + granted);

		} // else allowed 

	}

コンテナが sessionExpired にコールバックしたあとに SIP セッションが存続する (Issue 1265)

説明

これはときどき発生する問題です。セッションが削除されていることを示す NOTIFY に対する 200 と、NOTIFY を受信したときにクライアントが送信する SUBSCRIBE に競合状態がある場合、SIP コンテナは、「481 Call/Transaction does not exist」メッセージの代わりに「500 Server internal error」メッセージを返すことがあります。

解決方法

クライアントはサブスクリプションが期限切れになる前に、SUBSCRIBE を更新する必要があります。

Communications Server が最初に UAS として、続いてプロキシとして動作し、NOP を生成する (Issue 1432)

説明

Communications Server は INVITE リクエストを受信すると、最初に UAS として動作し、このリクエストに 1XX で応答します。次に、この INVITE リクエストを別のインスタンスにプロキシ処理し、このインスタンスが 200 OK で応答します。1xx は内部仮想ブランチを作成しますが、200 メッセージは実ブランチを作成します。B から 200 OK を受信したら、内部仮想ブランチは取り消されるべきです。

解決方法

この例外トレースは、仮想プロキシブランチの動作に影響しません。

getLastAccessedTime メソッドが正確な結果を返さない (Issue 1351)

説明

SIP セッションの getLastAccessedTime メソッドが、正確な結果を返しません。

解決方法

lastAccessedTime を正確に追跡する必要があるアプリケーションは、自身でこれを SipApplicationSession に保存する必要があります。

synchronized (sas) {

	Long last = (Long) sas.getAttribute("myLastAccessedTime");

	if (last == null) {last = 0};

	// do something with the last one

	// and...

	// set the new one.

	sas.setAttribute("myLastAccessedTime", System.currentTimeMillis());

}

削除した SIP リスナーが一定期間アクティブなままになる (Issue 1249)

説明

TCP および UDP リクエストに対して設定した SIP リスナーを削除したあと、リスナーが一定期間アクティブなままになります。リスナーに送信された UDP リクエストが、リスナーからの応答を受信する場合があります。

解決方法

現在のところ解決策はありません。SIP リスナーは一定期間のあと、UDP リクエストの待機を終了します。この問題は TCP リクエストには影響しません。

「<>」のない Contact ヘッダーを受信すると、Communications Server が例外をスローする (Issue 1489)

説明

Communications Server は、「<>」がない Contact ヘッダーを受信したときに例外をスローします。SIP RFC 3261 では、アドレスでの「<>」の使用は必須ではありません。これにより、ほかの SIP 互換デバイスで相互運用性の問題が発生する場合があります。

解決法

Contact ヘッダーでは「<>」を使用してください。

無効な UUID 値で Communications Server が例外をスローする (Issue 1494)

説明

Communications Server は、無効な UUID 値で 400 Bad Request を返す代わりに例外をスローします。UUID 値は SIP Contact ヘッダーの sip.instance 値にあります。

解決方法

現在のところ解決策はありません。

Windows: Communications Server で UDP メッセージが受信されない (ID なし)

説明

この問題は Windows のみで、ときどき発生します。UDP メッセージが Communications Server で受信されません。

解決方法

JVM オプションを次のように設定して、Communications Server を再起動します。

org.jvnet.glassfish.comms.disableUDPSourcePort=true