Moje rozmowy wideo ze spotkaniami z obsługą urządzeń wideo są przerywane po 15 minutach (lub po określonym czasie)

Moje rozmowy wideo ze spotkaniami z włączonymi urządzeniami wideo są przerywane po 15 minutach (lub po określonym czasie).

Połączenia połączeń wideo ze spotkaniami Cisco Webex Video Device-Enabled są rozłączane po 15 minutach.

Połączenia SIP są przerywane po ustalonym przedziale czasu.

Połączenia ze spotkaniami z obsługą urządzeń wideo są rozłączane po 15 minutach.

Rozmowy wideo są końcem 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ż czasomierz wygaśnięcia sesji SIP. Domyślnie w CallManager czasomierz wygaśnięcia sesji SIP jest ustawiony na 1800 sekund.

Rozwiązanie:

Aby tosprawdzić:

  1. Otwórz okno Cisco Unified Communications Manager (CM) Administration.
  1. Kliknij Parametry usługi systemowej >.
  2. W obszarze Wybierz serwer iusługę w polu listy rozwijanej Usługa wybierz pozycję Cisco Call Manager (Active):
Obraz dodany przez użytkownika
  1. Poszukaj timera wygaśnięcia sesjiSIP:
Obraz dodany przez użytkownika

Wszystkie urządzenia zarejestrowane w CUCM używają tego timera. Gdy urządzenie jest w rozmowie 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 połową timera wygasa sesji (1800/2 = 900 sekund = 15 minut). Jeśli nie zostanie odebrany komunikat o odświeżeniu, połączenie zostanie rozłączone.

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

Na podstawie początkowej negocjacji User Agent Client /User Agent Server (UAC/UAS), jedno z urządzeń odświeża sesję po wysłaniu Ponownego ZAPROSZENIA. Jeśli odświeżaczem jest Kontrola konta użytkownika, 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 ze strony A do CUCM do strony B. Jeśli odświeżaczem jest kontrola konta użytkownika na stronie A i UAS na stronie B:

1.     Strona A musi wysłać ponowne ZAPROSZENIE / AKTUALIZACJĘ do CUCM.
2.     CUCM musi wysłać ponowne ZAPROSZENIE / AKTUALIZACJĘ do strony 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śli jedno urządzenie wyśle wiadomość o ponownym ZAPROSZENIU do CUCM, CUCM wyśle ponowne ZAPROSZENIE do drugiej Strony. Jeśli jednak nie zostanie to odebrane przez stronę zdalną, może to być spowodowane niektórymi urządzeniami sieciowymi pomiędzy. Jest wysoce prawdopodobne, że ponowne ZAPROSZENIE/odpowiedź nie dotrze do jednej ze stron z powodu inspekcji SIP lub ustawień sieciowych.
Jeśli urządzenia nie zainicjują ponownego zaproszenia, może to być 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 zrobiło] w zaawansowanym obszarze konfiguracji strefy przechodzącej do Webex:
Włącz tryb filtra SIP UDP / IX [nie domyślny]:
Obraz dodany przez użytkownika
I sprawdź również timery sesji SIP na VCS-e.
 
Naszym domyślnym ustawieniem jest 1800s [15 min], co jest standardem i będziesz chciał upewnić się, że zegar TCP na zaporze ogniowej pasuje również tutaj, ale możesz to trochę podbić, aby sprawdzić, czy ma to również wpływ na VCS.

To jest w obszarze Konfiguracja > protokołów > SIP: Zwróć
Obraz dodany przez użytkownika

uwagę, że interwał odświeżania sesji (sekundy) 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 faktycznie myśli, że jest w porządku i że sesja jest nadal włączona, ale nie odbiera FIN / zamknięcia na tej sesji / porcie i próbuje go ponownie użyć, a połączenie umiera. [przypadek 2] to FW prawidłowo zamyka połączenie i wysyła FIN /close, a VCS rejestruje normalne połączenie drop/clearing, a połączenie również umiera. Modyfikowanie czasomierza sesji tutaj tylko kontroluje, kiedy VCS zrezygnuje z sesji po tym, jak nie otrzyma żadnych ACH dla jakiejkolwiek próby komunikacji dotyczącej statusu połączenia.
 
Może nam to jednak pomóc nieco lepiej określić problem. Możliwe jest również, że będziemy musieli obniżyć tę wartość w zależności od ustawienia FW dla tego timera.

Czy ten artykuł był pomocny?