SIP 容器

SIP 容器無法在已傳送 100 回應時處理取消請求 (問題 712)

說明

SIP 容器無法在已傳送 100 回應時處理取消請求。

解決方案

應用程式需要傳送暫時性的回應 (例如 1xx)，以便遠端能夠取消此 INVITE 請求。

SIP 階段作業和 HTTP 階段作業沒有套用相同的階段作業過期時間模型 (問題 1180)

說明

SIP 階段作業的階段作業過期模型和 HTTP 過期時間邏輯不同。在 HTTP 方面，每當在 HTTP 階段作業中接收到新的 HTTP 請求時，該階段作業會自動延伸，並不會受到應用程式的控制。

而在 SIP 階段作業方面，應用程式會在 SIP 容器的許可下，控制 SipApplicationSession (SAS) 的持續時間。應用程式可以使用 setExpires 方法指出 SAS 何時應過期。setExpires 會相對於呼叫 setExpires 方法的時間來定義過期時間。容器可以修改、拒絕或接受 setExpires 中所指出的持續時間。如果階段作業沒有失效，則會在 setExpires 定義的時間執行 sessionExpired 回呼。在此回呼中，應用程式可以嘗試呼叫新的 setExpires 以延伸 SAS 的持續時間，但仍會受到容器的修改、拒絕或接受控制。

因此，使用與 SipApplicationSession (SAS) 相同的過期時間啟動且位於 HTTP 階段作業的整合應用程式，在 HTTP 階段作業中接收到新的請求時，會發現 SAS 在 HTTP 階段作業前逾時。

解決方案

對於 SIP 和 HTTP 階段作業兩者不同的過期時間處理，最好的應付方式是啟動階段作業時使用夠長的 SAS 過期時間，此一過期時間即為應用程式階段作業預期存在 (包括數個 HTTP 請求) 的總時間長度。SAS 使用期限甚至可以設為無限，特別是使用 invalidateWhenReady 語義時，在這個情況下，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 階段作業仍持續 (問題 1265)

說明

這是偶爾會發生的問題。當指出階段作業已移除的 200 通知訊息，以及用戶端在收到該通知時所傳送的訂閱之間發生競爭情況時，SIP 容器偶爾會使用 500「伺服器內部錯誤」訊息回應，而非使用 481「呼叫/作業事件不存在」訊息回應。

解決方案

用戶端需要在訂閱到期前儘早更新訂閱。

Communications Server 會先後扮演 UAS 和代理的角色執行動作並產生 NOP (問題 1432)

說明

當它接收到邀請請求時，Communications Server 會先扮演 UAS 的角色，以 1XX 回覆此請求，然後會代理此邀請請求傳送給另一個實例，該實例會以 200「確定」訊息回覆。1xx 會建立內部虛擬分支，而 200 訊息會建立實際分支。在從 B 接收到 200「確定」訊息後，內部虛擬分支應會取消。

解決方案

此一異常追蹤不會影響虛擬代理分支的功能。

getLastAccessedTime 方法未提供精確的結果 (問題 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 偵聽程式在刪除後一段期間內仍維持作用中的狀態 (問題 1294)

說明

在刪除針對 TCP 和 UDP 請求所配置的 SIP 偵聽程式後，偵聽程式在一段期間內仍維持作用中的狀態。傳送給偵聽程式的 UDP 請求可能會接收到來自偵聽程式的回應。

解決方案

無已知解決方案。在一段時間之後，SIP 偵聽程式會停止偵聽 UDP 請求。這個問題並不會影響 TCP 請求。

Communications Server 在接收到不含「<>」的連絡標頭時丟出異常 (問題 1489)

說明

Communications Server 在接收到不含「<>」的連絡標頭時丟出異常。根據 SIP RFC 3261，位址中並非一定要使用「<>」。這可能會導致與其他 SIP 相容裝置間的互通性問題。

解決方案

請在使用連絡標頭中使用「<>」。

Communications Server 針對無效的 UUID 值丟出異常 (問題 1494)

說明

Communications Server 會針對無效的 UUID 值丟出異常，而非傳回 400「錯誤的請求」訊息。UUID 值位於 SIP 連絡標頭的 sip.instance 值之中。

解決方案

無已知解決方案。

Windows：有時 Communications Server 沒有收到 UDP 訊息 (無 ID)

說明

這是 Windows 作業系統上偶爾會發生的問題。Communications Server 沒有收到 UDP 訊息。

解決方案

將下列 JVM 選項依照下面的方式設定，並重新啟動 Communications Server。

org.jvnet.glassfish.comms.disableUDPSourcePort=true