SIP-Container

SIP-Container kann ABBRECHEN nicht verarbeiten, wenn die Antwort 100 gesendet wurde (Problem 712)

Beschreibung

Der SIP-Container kann eine Anforderung des Typs ABBRECHEN nicht verarbeiten, wenn die Antwort 100 gesendet wurde.

Lösung

Die Anwendung muss eine provisorische Antwort senden (wie z.B. 1xx), sodass die Remote-Seite die Anforderung INVITE ABBRECHEN kann.

SIP-Sitzungen und HTTP-Sitzungen wenden nicht dasselbe Zeitmodell für den Sitzungsablauf an (Problem 1180)

Beschreibung

Das Modell für den Ablauf von SIP-Sitzungen unterscheidet sich von dem für den Ablauf von HTTP-Sitzungen. In HTTP wird die Sitzung außerhalb der Kontrolle der Anwendung jedes Mal automatisch verlängert, wenn eine neue HTTP-Anforderung in dieser HTTP-Sitzung erhalten wird.

Bei SIP-Sitzungen hat die Anwendung Kontrolle über die Dauer der SipApplicationSession (SAS), abhängig von der Zustimmung des SIP-Containers. Anwendungen können mithilfe der Methode setExpires angeben, wann SAS ablaufen soll. setExpires definiert eine Ablaufzeit abhängig von dem Zeitpunkt, zu dem die setExpires-Methode aufgerufen wird. Der Container kann die in setExpires angegebene Dauer ändern, ablehnen oder akzeptieren. Wenn die Sitzung nicht ungültig gemacht wird, wird der Rückruf sessionExpired zu dem in setExpires definierten Zeitpunkt ausgeführt. In diesem Rückruf kann die Anwendung versuchen, die Dauer der SAS durch Aufruf einer neuen setExpires -Methode zu verlängern, was wieder abhängig von der Änderung, Ablehnung oder Annahme durch den Container ist.

Aus diesem Grund stellen konvergierte Anwendungen, die mit derselben Ablaufzeit der SipApplicationSession (SAS) und der HTTP-Sitzung starten, fest, dass die SAS vor der HTTP-Sitzung abläuft, wenn in der HTTP-Sitzung neue Anforderungen eingegangen sind.

Lösung

Aufgrund der unterschiedlichen Handhabung der Ablaufzeit von SIP- und HTTP-Sitzungen sollten Sie mit einer ausreichend langen SAS-Ablaufzeit beginnen, die der voraussichtlichen Gesamtdauer der Anwendungssitzung entspricht (inklusive mehrerer HTTP-Anforderungen). Die SAS-Dauer kann sogar auf unbegrenzt eingestellt werden, insbesondere bei Verwendung von invalidateWhenReady-Semantik. In diesem Fall wird SipApplicationSession ungültig gemacht, wenn die letzte untergeordnete Protokollsitzung ungültig wird. Die anfängliche Ablaufzeit der SAS kann in der Bereitstellungsbeschreibung konfiguriert werden.

Wenn die maximale Gesamtdauer vorab abgeschätzt werden kann, ist kein weiterer Code erforderlich, da es in diesem Fall angebracht ist, sowohl die SIP-Sitzung als auch die HTTP-Sitzung ungültig zu machen, wenn SAS abläuft. Wenn die maximale Dauer nicht vorab abgeschätzt werden kann, kann SipApplicationSession nach Ablauf verlängert werden, wie im Code-Snippet unten gezeigt.

In der Implementierung SipApplicationSessionListener können Sie Folgendes ausführen:

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 
	}

SIP-Sitzung dauert weiter an, nachdem Container-Rückruf zur Sitzung abgelaufen ist (Problem 1265)

Beschreibung

Dieses Problem tritt zeitweise auf. Der SIP-Container antwortet zeitweise mit dem internen Serverfehler 500 anstatt mit der Fehlermeldung 481 "Aufruf/Transaktion existiert nicht", wenn eine Gleichzeitigkeitsbedingung zwischen 200 für BENACHRICHTIGEN, was darauf hinweist, dass die Sitzung entfernt wurde, und dem vom Client gesendeten ABONNIEREN bei Erhalt von BENACHRICHTIGEN besteht.

Lösung

Der Client muss ABONNIEREN aktualisieren, lange bevor das Abonnement abläuft.

Communications Server verhält sich zuerst als UAS, dann als Proxy, und generiert einen Leerlaufprozess (Problem 1432)

Beschreibung

Bei Erhalt einer INVITE-Anforderung verhält sich Communications Server zuerst als UAS, antwortet auf diese Anforderung mit 1XX und übermittelt die INVITE-Anforderung dann an eine andere Instanz, die mit 200 OK antwortet. 1xx erstellt eine interne virtuelle Verzweigung, wohingegen die Meldung 200 eine echte Verzweigung erstellt. Bei Erhalt von 200 OK von B sollte die interne virtuelle Verzweigung abgebrochen werden.

Lösung

Diese Ausnahmeverfolgung betrifft die Funktionalität der virtuellen Proxy-Verzweigung nicht.

Die Methode "getLastAccessedTime" führt zu keinen genauen Ergebnissen (Problem 1351)

Beschreibung

Die getLastAccessedTime-Methode einer SIP-Sitzung stellt keine genauen Ergebnisse bereit.

Lösung

Anwendungen, die lastAccessedTime genau verfolgen müssen, müssen die Informationen selbst in SipApplicationSession speichern.

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-Zielgerät bleibt nach seiner Löschung noch eine Zeit lang aktiv (Problem 1294)

Beschreibung

Nach Löschen eines für TCP- und UDP-Anforderungen konfigurierten SIP-Zielgeräts bleibt das Zielgerät eine Zeit lang aktiv. UDP-Anforderungen, die an das Zielgerät gesendet werden, können eine Antwort vom Zielgerät erhalten.

Lösung

Keine bekannte Lösung. Das SIP-Zielgerät reagiert nach einer bestimmten Zeit nicht mehr auf UDP-Anforderungen. Dieses Problem betrifft TCP-Anforderungen nicht.

Communications Server löst bei Erhalt einer Kontakt-Kopfzeile ohne "<>" eine Ausnahme aus (Problem 1489)

Beschreibung

Communications Server löst bei Erhalt einer Kontakt-Kopfzeile ohne “<>” eine Ausnahme aus. Laut SIP RFC 3261 ist es nicht obligatorisch, dass "<>" in der Adresse enthalten ist. Dies kann zu Interoperabilitätsproblemen mit anderen SIP-kompatiblen Geräten führen.

Lösung

Verwenden Sie "<>" in der Kontakt-Kopfzeile.

Communications Server löst eine Ausnahme bei ungültigem UUID-Wert aus (Problem 1494)

Beschreibung

Communications Server löst eine Ausnahme bei ungültigem UUID-Wert aus, anstatt die Unzulässige Anforderung 400 zurückzugeben. Der Wert UUID befindet sich im sip.instance-Wert der SIP-Kontakt-Kopfzeile.

Lösung

Keine bekannte Lösung.

Windows: Manchmal kann Communications Server UDP-Meldungen nicht empfangen (Keine ID)

Beschreibung

Dieses Problem tritt nur bei Windows zeitweise auf. Communications Server empfängt keine UDP-Meldungen.

Lösung

Stellen Sie folgende JVM-Optionen folgendermaßen ein und starten Sie Communications Server neu.

org.jvnet.glassfish.comms.disableUDPSourcePort=true