Причина. Коли відеодзвінки відключаються рівно через 15 хвилин, поширеною проблемою є тайм-аут TCP, налаштований у мережі (брандмауер/маршрутизатори), менший, ніж таймер закінчення сесії SIP. За замовчуванням для менеджера викликів таймер закінчення сеансу SIP встановлено на 1800 секунд.

Рішення:

Щоб підтвердити це, виконайте наведені нижче дії.

1. Відкрийте адміністрування Cisco Unified Communications Manager (CM).

2. Клацніть System > Service Parameters (Система > Сервісні параметри).
3. У розділі Select Server and Service (Вибрати сервер і службу) у спадному списку Service (Служба) виберіть Cisco Call Manager (Active) (Менеджер викликів Cisco (активний)):

4. Шукайте таймер закінчення сесії SIP:

Усі пристрої, зареєстровані в CUCM, використовують цей таймер. Коли пристрій здійснює дзвінок з іншим віддаленим пристроєм, одна зі сторін повинна оновити сеанс і надіслати повторне ОНОВЛЕННЯ АБО ОНОВЛЕННЯ. Це оновлення потрібно надіслати до того, як закінчиться половина таймера сеансу ( 1800/2 = 900 секунд = 15 хвилин). Якщо повідомлення про оновлення не надійшло, дзвінок буде від 'єднано.

Перевірте таймер сеансу в початковому ЗАПРОШЕННІ. Оновлення (ЗАПРОШЕННЯ / ОНОВЛЕННЯ) має бути отримано до закінчення цього часу:


На основі початкового узгодження клієнта агента користувача/сервера агента користувача (UAC/UAS), один з пристроїв оновлює сеанс, коли він надсилає Re-INVITE. Якщо оновлення UAC, ініціатор виклику несе відповідальність за оновлення сеансу. Якщо оновлення здійснюється за допомогою БпАК, сервер має оновити сеанс. Зберіть журнали зневаджування SIP з обох кінцевих точок і перевірте ці елементи:

Приклад: Виклик здійснюється від Сторони А до CUCM Стороні Б. Якщо підвищення є UAC на Стороні А та UAS на Стороні Б:

1.     Сторона А повинна надіслати повторне розслідування / ОНОВЛЕННЯ до CUCM.
2.     CUCM має надіслати повторну інформацію / ОНОВЛЕННЯ Стороні B.
3.     Сторона Б отримує повторний запит та відповідає на це повідомлення літерою 200 OK.
4.     CUCM має надіслати 200 OK Стороні А.

Якщо один пристрій надсилає повідомлення про повторне інвідування CUCM, CUCM надсилає повторне інвідування іншій Стороні. Однак, якщо це не отримано віддаленою стороною, то це може бути через деякі мережеві пристрої між ними. Цілком можливо, що повторне введення/відповідь не потрапить до однієї зі сторін через перевірку SIP або налаштування мережі.
Якщо пристрої не ініціюють повторне введення, це може бути проблемою з пристроєм. Залучайте Центр технічної допомоги Cisco (TAC) для подальшого дослідження.
 
У списку речей, які слід спробувати [якщо цього ще не було] у розширеній області налаштування зони, що переходить до Webex:
увімкніть режим фільтрування SIP UDP/IX [не за замовчуванням]:

і перевірте таймери сеансів SIP на VCS-e також.
 
Нашим стандартом є 1800s [15 хвилин], що є стандартним, і ви хочете переконатися, що таймер TCP на вашому брандмауері також збігається тут, але ви можете трохи підняти його, щоб побачити, чи він також впливає на ваш VCS.

Це в розділі Конфігурація > Протоколи > SIP:


Зауважте, що інтервал оновлення сеансу (секунди) встановлено на значення за замовчуванням. Ви можете спробувати 3600. Але фактичний корінь проблеми тут полягає в тому, коли FW вважає, що сеанс більше не використовується [випадок 1], коли VCS насправді вважає, що це нормально, і що сеанс все ще вичерпаний, але не отримує FIN/Close на цьому сеансі/порту і намагається використовувати його повторно, і виклик помирає. [випадок 2] - FW належним чином закриває з 'єднання і надсилає FIN/Close, і VCS записує звичайне скидання/очищення виклику, і виклик також помирає. Зміна таймера сеансу тут лише контролює, коли VCS відмовиться від сеансу після того, як йому не вдалося отримати жодного ACK для будь-якого спроби зв 'язку щодо стану виклику.
 
Хоча це може допомогти нам трохи краще визначити проблему. Також можливо, що нам потрібно знизити це значення залежно від налаштування FW для цього таймера.