Moje połączenia wideo ze spotkaniami obsługującymi urządzenia wideo są przerywane po 15 minutach (lub po określonym czasie)

Moje rozmowy wideo ze spotkaniami obsługującymi urządzenia wideo są przerywane po 15 minutach (lub po określonym czasie).

Połączenia wideo do spotkań Cisco Webex Video Device-Enabled Meetings są rozłączane po 15 minutach.

Połączenia SIP są przerywane po określonym przedziale czasu.

Połączenia ze spotkaniami obsługującymi urządzenia wideo są rozłączane po 15 minutach.

Rozmowy wideo kończą się po 15 minutach.

 

Przyczyna: Gdy połączenia wideo rozłączają się dokładnie po 15 minutach, częstym problemem jest to, że limit czasu TCP skonfigurowany w sieci (zapora/routery) jest krótszy niż czas wygaśnięcia sesji SIP. Domyślnie w CallManager licznik czasu wygaśnięcia sesji SIP jest ustawiony na 1800 sekund.

Rozwiązanie:

Aby to zweryfikować:

  1. Otwórz administrację Cisco Unified Communications Manager (CM).
  1. Kliknij kolejno System > Parametry usługi.
  2. W obszarze Wybierz serwer i usługę w polu listy rozwijanej Usługa wybierz opcję Cisco Call Manager (aktywny):
Obraz dodany przez użytkownika
  1. Poszukaj Licznika czasu wygaśnięcia sesji SIP:
Obraz dodany przez użytkownika

Wszystkie urządzenia zarejestrowane w CUCM używają tego timera. Gdy urządzenie jest w trakcie połączenia z innym urządzeniem zdalnym, jedna ze stron musi odświeżyć sesję i wysłać ponowne ZAPROSZENIE lub AKTUALIZACJĘ. To odświeżenie musi zostać wysłane przed upływem połowy licznika czasu wygaśnięcia sesji (1800/2 = 900 sekund = 15 minut). Jeśli nie odebrano wiadomości o odświeżeniu, połączenie zostanie rozłączone.

Sprawdź licznik czasu sesji w początkowym zaproszeniu INVITE. Odświeżenie (ZAPROSZENIE/AKTUALIZACJA) powinno zostać odebrane przed upływem tego czasu:
Obraz dodany przez użytkownika

Na podstawie początkowej negocjacji klienta klienta użytkownika/serwera agenta użytkownika (UAC/UAS), jedna z urządzenie odświeża sesję po wysłaniu ponownego zaproszenia. Jeśli odświeżaniem jest UAC, inicjator połączenia jest odpowiedzialny za odświeżenie sesji. Jeśli odświeżaczem jest UAS, serwer musi odświeżyć sesję. Zbierz dzienniki debugowania SIP z obu punktów końcowych i sprawdź następujące elementy:

Przykład: Połączenie wykonane od strony A z CUCM do strony B. Jeśli przypomnienie to kontrola konta użytkownika strony A i UAS strony B:

1.     Strona A musi wysłać ponowne ZAPROSZENIE/AKTUALIZACJA do CUCM.
2.     CUCM musi wysłać ponowne ZAPROSZENIE/AKTUALIZACJĘ do Grupy B.
3.     Strona B otrzymuje ponowne ZAPROSZENIE i odpowiada na tę wiadomość 200 OK.
4.     CUCM musi wysłać 200 OK do Strony A.

Jeżeli jedno urządzenie wyśle do CUCM wiadomość o ponownym ZAPROSZENIU, CUCM wyśle ponowne ZAPROSZENIE do drugiej Strony. Jeśli jednak nie zostanie to odebrane przez stronę zdalną, może to być spowodowane przez niektóre urządzenia sieciowe pomiędzy nimi. Jest bardzo prawdopodobne, że ponowne ZAPROSZENIE/odpowiedź nie dotrze do jednej ze stron z powodu kontroli SIP lub ustawień sieci.
Jeśli urządzenia nie zainicjują ponownego ZAPROSZENIA, może to oznaczać problem z urządzeniem. Zaangażuj Centrum pomocy technicznej Cisco (TAC) w celu dalszego zbadania.
 
Na liście rzeczy do wypróbowania [jeśli jeszcze tego nie zrobiono] w obszarze konfiguracji zaawansowanej strefy przechodzącej do Webex:
Włącz tryb filtra SIP UDP/IX na włączony [nie domyślnie]:
Obraz dodany przez użytkownika
Sprawdź także zegary sesji SIP na VCS-e.
 
Naszym ustawieniem domyślnym jest 1800 s [15 minut], co jest standardem i będziesz chciał się upewnić, że zegar TCP w Twojej zaporze również pasuje tutaj, ale możesz to trochę podnieść, aby sprawdzić, czy ma to również wpływ na twoją VCS.

To jest w Konfiguracja > Protokoły > SIP:
Obraz dodany przez użytkownika

Zauważ, że interwał odświeżania sesji (w sekundach) jest ustawiony na wartość domyślną. Możesz spróbować 3600. Ale faktycznym źródłem problemu jest to, że FW myśli, że sesja nie jest już używana [przypadek 1], kiedy VCS rzeczywiście myśli, że jest w porządku i że sesja jest nadal aktywna, ale nie otrzymuje FIN/zamknięcia na ten temat sesji/portu i próbuje go ponownie użyć, a połączenie zostaje przerwane. [przypadek 2] czy FW prawidłowo zamyka połączenie i wysyła FIN/zamknięcie, a VCS rejestruje normalne zerwanie/rozliczenie połączenia, a połączenie również zostaje przerwane. Modyfikacja zegara sesji w tym przypadku kontroluje tylko, kiedy VCS zrezygnuje z sesji po tym, jak nie otrzyma żadnego potwierdzenia ACK dla jakiejkolwiek próby komunikacji dotyczącej statusu połączenia.
 
Pomoże nam to jednak nieco lepiej określić problem. Możliwe jest również, że musimy obniżyć tę wartość w zależności od ustawienia FW dla tego timera.
Czy ten artykuł był pomocny?