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