Meine Videoanrufe an Cisco Webex Video Platform-Sitzungen werden nach 15 Minuten (oder nach einer bestimmten Zeit) abgebrochen.

Meine Videoanrufe zu Cisco Webex Video Platform-Sitzungen werden nach 15 Minuten (oder nach einer bestimmten Zeit) abgebrochen.

Videoanrufverbindungen zur Cisco Webex Video Platform trennen die Verbindung nach 15 Minuten.

SIP-Anrufe werden nach einem festgelegten Zeitintervall abgebrochen.

Endpunktverbindungen zur Cisco Webex Video Platform trennen die Verbindung nach 15 Minuten.

Videoanrufe werden nach 15 Minuten abgebrochen.

 

Dieser Artikel entstand in englischer Sprache und wurde maschinell übersetzt. Es wird keinerlei Gewährleistung, weder ausdrücklich noch stillschweigend, hinsichtlich der Genauigkeit, Korrektheit oder Zuverlässigkeit von Maschinenübersetzungen, die aus dem Englischen in eine andere Sprache ausgeführt werden, übernommen. Cisco ist nicht verantwortlich für ungenaue Informationen, Fehler oder Schäden, die durch eine fehlerhafte Übersetzung des Inhalts oder die Verwendung der Informationen verursacht wurden.

Hinweis: CMR Cloud wurde in Cisco Webex Video Platform umbenannt. Einige Links und Texte können sich noch auf CMR Cloud beziehen, aber Informationen sollten immer noch für den umbenannten Dienst gelten.

Ursache: Wenn Videoanrufe nach genau 15 Minuten getrennt werden, ist das häufig auftretende Problem, dass das im Netzwerk konfigurierte TCP-Timeout (Firewall / Router) weniger als der SIP-Sitzungszeitgeber ist. In CallManager ist der SIP Session Expire Timer standardmäßig auf 1800 Sekunden eingestellt.

Lösung:

Um dies zu überprüfen:

  1. Öffnen Sie die Cisco Unified Communications Manager-Administration (CM).
  1. Klicke auf System > Service-Parameter.
  2. Unter Wählen Sie Server und Dienst, in dem Bedienung Wählen Sie im Dropdown-Listenfeld aus Cisco Call Manager (aktiv):
Vom Benutzer hinzugefügte Abbildung
  1. Suche nach SIP-Sitzung läuft ab:
Vom Benutzer hinzugefügte Abbildung

Alle in CUCM registrierten Endpunkte verwenden diesen Timer. Befindet sich der Endpunkt in einem Anruf mit einem anderen entfernten Endpunkt, muss eine der Parteien die Sitzung aktualisieren und eine erneute Einladung oder Aktualisierung senden. Diese Aktualisierung muss vor der Hälfte des Session-Ablaufzeit-Timers gesendet werden (1800/2 = 900 Sekunden = 15 Minuten). Wenn keine Aktualisierungsnachricht empfangen wird, wird der Anruf getrennt.

Überprüfen Sie den Sitzungszeitgeber in der ersten EINLADUNG. Eine Aktualisierung (INVITE / UPDATE) sollte vor Ablauf dieser Zeit empfangen werden:
Vom Benutzer hinzugefügte Abbildung

Basierend auf der ersten UAC / UAS-Verhandlung (User Agent Client / User Agent Server) aktualisiert einer der Endpunkte die Sitzung, wenn er eine erneute Einladung sendet. Wenn die Auffrischung UAC ist, ist der Initiator des Anrufs dafür verantwortlich, die Sitzung zu aktualisieren. Wenn es sich bei der Aktualisierung um UAS handelt, muss der Server die Sitzung aktualisieren. Sammeln Sie die SIP-Debug-Protokolle von beiden Endpunkten und überprüfen Sie diese Elemente:

Beispiel: Aufruf von Partei A an CUCM an Partei B. Wenn die Auffrischung UAC auf Party A und UAS auf Party B ist:

1.     Partei A muss das erneute EINLADEN / UPDATE an den CUCM senden.
2.     CUCM muss ein erneutes EINLADEN / UPDATE an Partei B senden.
3.     Teilnehmer B empfängt die erneute EINLADUNG und antwortet auf diese Nachricht mit einem 200 OK.
4.     CUCM muss 200 OK an Partei A senden.

Wenn ein Endpunkt die erneute INVITE-Nachricht an den CUCM sendet, sendet CUCM eine erneute INVITE an den anderen Teilnehmer. Wenn dies jedoch nicht von der Remote-Seite empfangen wird, kann dies an einigen Netzwerkgeräten liegen. Es ist sehr wahrscheinlich, dass die erneute EINLADUNG / Antwort aufgrund einer SIP-Prüfung oder Netzwerkeinstellungen nicht zu einer der Seiten gelangt.
Wenn die Endpunkte die erneute EINLADUNG nicht initiieren, kann dies ein Problem mit dem Endpunkt sein. Binden Sie das Cisco Technical Assistance Center (TAC) ein, um weitere Untersuchungen durchzuführen.
 
In der Liste der Dinge, die Sie ausprobieren können [falls dies noch nicht geschehen ist] im erweiterten Konfigurationsbereich der Zone, der zu Webex geht:
Drehe die SIP UDP / IX-Filtermodus zu auf [nicht die Standardeinstellung]:
Vom Benutzer hinzugefügte Abbildung
Überprüfen Sie auch die SIP-Sitzungstimer auf VCS-e.
 
Unsere Standardeinstellung ist 1800s [15 Minuten]. Dies ist Standard und Sie sollten sicherstellen, dass der TCP-Timer Ihrer Firewall auch hier übereinstimmt. Sie können dies jedoch etwas erhöhen, um zu sehen, ob es auch Auswirkungen auf Ihre Firewall hat VCS.

Das ist unter Aufbau > Protokolle > SCHLUCK:
Vom Benutzer hinzugefügte Abbildung

Beachten Sie, dass das Sitzungsaktualisierungsintervall (Sekunden) auf den Standardwert eingestellt ist. Möglicherweise versuchen Sie es mit 3600. Die eigentliche Wurzel des Problems liegt hier jedoch, wenn die FW der Meinung ist, dass eine Sitzung nicht mehr verwendet wird [Fall 1], wenn das VCS tatsächlich der Meinung ist, dass es in Ordnung ist und dass die Sitzung noch nicht beendet ist, aber keine FIN / close-Anweisung vorliegt Sitzung / Port und Versuche, es erneut zu verwenden, und der Anruf wird abgebrochen. [Fall 2] ist, dass die FW die Verbindung ordnungsgemäß schließt und ein FIN / close sendet und VCS ein normales Löschen / Löschen eines Anrufs aufzeichnet, und der Anruf stirbt ebenfalls. Das Ändern des Sitzungszeitgebers steuert hier lediglich, wann VCS eine Sitzung aufgibt, nachdem es keine ACKs für eine versuchte Kommunikation über den Status des Anrufs erhalten hat.
 
Es kann uns jedoch helfen, das Problem ein wenig besser zu lokalisieren. Es ist auch möglich, diesen Wert in Abhängigkeit von der FW-Einstellung für diesen Timer zu verringern.

War dieser Artikel hilfreich für Sie?