Der SIP-Container kann eine Anforderung des Typs ABBRECHEN nicht verarbeiten, wenn die Antwort 100 gesendet wurde.
Die Anwendung muss eine provisorische Antwort senden (wie z.B. 1xx), sodass die Remote-Seite die Anforderung INVITE ABBRECHEN kann.
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.
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 }
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.
Der Client muss ABONNIEREN aktualisieren, lange bevor das Abonnement abläuft.
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.
Diese Ausnahmeverfolgung betrifft die Funktionalität der virtuellen Proxy-Verzweigung nicht.
Die getLastAccessedTime-Methode einer SIP-Sitzung stellt keine genauen Ergebnisse bereit.
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()); }
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.
Keine bekannte Lösung. Das SIP-Zielgerät reagiert nach einer bestimmten Zeit nicht mehr auf UDP-Anforderungen. Dieses Problem betrifft TCP-Anforderungen nicht.
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, anstatt die Unzulässige Anforderung 400 zurückzugeben. Der Wert UUID befindet sich im sip.instance-Wert der SIP-Kontakt-Kopfzeile.
Keine bekannte Lösung.
Dieses Problem tritt nur bei Windows zeitweise auf. Communications Server empfängt keine UDP-Meldungen.
Stellen Sie folgende JVM-Optionen folgendermaßen ein und starten Sie Communications Server neu.
org.jvnet.glassfish.comms.disableUDPSourcePort=true