Meine Videoanrufe an videogerätefähige Meetings fallen nach 15 Minuten (oder nach einem bestimmten Zeitpunkt) weg

Meine Videoanrufe an videogerätefähige Meetings fallen nach 15 Minuten (oder nach einem bestimmten Zeitraum) weg.

Videoanrufverbindungen Cisco Webex Videogerät-fähige Meetings werden nach 15 Minuten getrennt.

SIP-Anrufe fallen nach einem festgelegten Zeitintervall weg.

Verbindungen zu Videogerät-fähigen Meetings werden nach 15 Minuten getrennt.

Videoanrufe werden nach 15 Minuten wieder fallen.

 

Ursache: Wenn Videoanrufe nach genau 15 Minuten getrennt werden, ist das häufige Problem das im Netzwerk konfigurierte TCP-Timeout (Firewall/Router) ist kleiner als der Timer der SIP-Sitzung. Standardmäßig ist der Timer für das Ablaufen der SIP-Sitzung in CallManager auf 1800 Sekunden festgelegt.

Lösung:

So überprüfen Sie dies:

  1. Öffnen Cisco Unified Communications Manager(CUCM) (CM) Administration.
  1. Klicken Sie auf System > Serviceparameter.
  2. Wählen Sie unter Server und Dienst auswählen im Feld Dienstverwaltung Drop-down-Liste Cisco Call Manager (Aktiv):
Vom Benutzer hinzugefügte Abbildung
  1. Suchen Sie nach dem Timer für abgelaufene SIP-Sitzungen:
Vom Benutzer hinzugefügte Abbildung

Alle geräte, die in CUCM registriert sind, verwenden diesen Timer. Wenn sich das Gerät mit einem anderen Remote-Gerät in einem Gespräch befindet, muss einer der Parteien die Sitzung aktualisieren und eine erneute EINLADUNG oder AKTUALISIERUNG senden. Diese Aktualisierung muss vor der Hälfte der Sitzung Ablauf-Timer gesendet werden ( 1800/2 = 900 Sekunden = 15 Minuten). Wenn keine Aktualisierungsnachricht empfangen wird, wird der Anruf getrennt.

Überprüfen Sie in der anfänglichen INVITE auf den Timer für die Sitzung. Vor Ablauf dieser Zeit sollte eine Aktualisierung (INVITE/UPDATE) empfangen werden:
Vom Benutzer hinzugefügte Abbildung

Basierend auf der anfänglichen Verhandlung des Benutzeragenten-Clients /User Agent Servers (UAC/UAS) aktualisiert eines der Geräte die Sitzung, wenn eine erneute EINLADUNG gesendet wird. Wenn die Aktualisierung 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-Debugprotokolle von beiden Endpunkten und überprüfen Sie diese Elemente:

Beispiel: Anruf von Partei A an CUCM an Partei B. Wenn das Aktualisieren auf Partei A und UAS auf Partei B:

1 UAC ist.     Partei A muss die erneute EINLADUNG/AKTUALISIERUNG an den CUCM senden.
2.     CUCM muss eine erneute EINLADUNG/AKTUALISIERUNG an Partei B senden.
3.     Partei B erhält die erneute EINLADUNG und antwortet auf diese Nachricht mit einem 200 OK.
4.     CUCM muss 200 OK an Partei A senden.

Wenn ein Gerät die re-INVITE-Nachricht an den CUCM sendet, sendet CUCM eine erneute EINLADUNG an die andere Partei. Wenn dies jedoch nicht von der Fernbedienung empfangen wird, kann dies an einigen Netzwerkgeräten liegen, die zwischen ihnen liegen. Es ist sehr möglich, dass die erneute EINLADUNG /Antwort aufgrund der SIP-Überprüfung oder Netzwerkeinstellungen nicht auf eine der Seiten kommt.
Wenn die Geräte die erneute EINLADUNG nicht initiieren, kann es ein Problem mit dem Gerät sein. Beziehen Sie das Cisco Technical Assistance Center (TAC) ein, um weitere Untersuchungen zu erhalten.
 
In der Liste der zu probierenden Dinge [wenn dies noch nicht der Fall ist] im erweiterten Konfigurationsbereich der Zone, die zu Webex gehen:
Aktivieren Sie den SIP UDP/IX-Filtermodus [nicht als Standard]:
Vom Benutzer hinzugefügte AbbildungÜberprüfen Sie auch die SIP-Sitzungszeitler auf VCS-e.

 
Unser Standard beträgt 1800 [15 Minuten]. Hierbei handelt es sich um einen Standard, und Sie sollten sicherstellen, dass auch der TCP-Timer in Ihrer Firewall hier stimmt. Sie können dies jedoch etwas anheben, um zu sehen, ob er auch auf Ihren VCS auswirkungen hat.

Dies finden Sie unter Konfiguration > Protokolle > SIP:
Vom Benutzer hinzugefügte Abbildung

Beachten Sie, dass das Sitzungsaktualisierungsintervall (Sekunden) auf den Standardwert gesetzt ist. Sie können 3600 testen. Die eigentliche Ursache des Problems liegt hier jedoch, wenn die FW der Meinung ist, dass eine Sitzung [Fall 1] nicht mehr verwendet wird, wenn VCS es für ok hält und die Sitzung noch in Ordnung ist, aber in dieser Sitzung/diesem Port keine FIN/close-Sitzung mehr erhält und versucht, sie wieder zu nutzen, und der Anruf abfängt. [Fall 2] ist, dass der FW die Verbindung ordnungsgemäß schließt und eine FIN/close sendet. VCS zeichnet eine normale Anrufsende/-verrechnung auf und der Anruf spricht ebenfalls. Durch Ändern des Sitzungszeitreglers hier wird nur kontrolliert, wann VCS eine Sitzung auf gibt, nachdem er keine ACKs für die fehlgeschlagene Kommunikation über den Anrufstatus empfangen konnte.
 
Es kann uns jedoch helfen, das Problem etwas besser zu finden. Es ist auch möglich, dass wir diesen Wert abhängig von der FW-Einstellung für diesen Timer senken müssen.

War dieser Artikel hilfreich für Sie?