Чи була ця стаття корисною?
Дякуємо за відгук.
Відеовиклики на нараду Webex Від’єднано за 15 хвилин
Надіслати відгук?Адміністратори CUCM/VCS можуть ознайомитися з цим посібником щодо кроків для вирішення проблеми, під час якої відеопристрої відключаються рівно за 15 хвилин після приєднання до наради Webex.
ПРОБЛЕМА
У разі приєднання до Наради Webex за допомогою зареєстрованого CUCM відеопристрою виклик відключається рівно за 15 хвилин.
РОЗДІЛЬНА ЗДАТНІСТЬ
Перегляньте наведені нижче кроки.
- Відкрийте адміністрування Cisco Unified Communications Manager (CM).
- Клацніть System > Service Parameters (Система > Сервісні параметри).
- У розділі Select Server and Service (Вибрати сервер і службу) у спадному списку Service (Служба) виберіть Cisco Call Manager (Active) (Менеджер викликів Cisco (активний)):
- Шукайте таймер закінчення сесії SIP:
Усі пристрої, зареєстровані в CUCM, використовують цей таймер. Коли пристрій здійснює дзвінок з іншим віддаленим пристроєм, одна зі сторін повинна оновити сеанс і надіслати повторне ОНОВЛЕННЯ АБО ОНОВЛЕННЯ. Це оновлення потрібно надіслати до того, як закінчиться половина таймера сеансу ( 1800/2 = 900 секунд = 15 хвилин). Якщо не отримано повідомлення про оновлення, виклик буде відключено.
Перевірте таймер сеансу в початковому ЗАПРОШЕННІ. До закінчення цього часу необхідно отримати оновлення (ЗАПРОСИТИ/ОНОВИТИ):
На основі початкових переговорів із клієнтом оператора користувача /сервером оператора користувача (UAC/UAS) один із пристроїв оновлює сеанс, коли надсилає повторне ЗАПРОШЕННЯ. Якщо оновлення UAC, ініціатор виклику несе відповідальність за оновлення сеансу. Якщо оновлення здійснюється за допомогою БпАК, сервер має оновити сеанс. Зберіть журнали налагодження SIP з обох кінцевих пристроїв і перевірте ці елементи:
Приклад: Виклик, здійснений зі сторони A до CUCM до партії B. Якщо оновлювачем є UAC для партії A та UAS для партії B:
1.Сторона повинна надіслати повторне ЗАПРОШЕННЯ/ОНОВЛЕННЯ до CUCM.
2.Користувач CUCM повинен надіслати повторне ЗАПРОШЕННЯ/ОНОВЛЕННЯ партії B.
3. Сторона B отримує повторне ЗАПРОШЕННЯ й відповідає на це повідомлення 200 OK.
4.Користувач CUCM має надіслати 200 OK партії А.
Якщо один пристрій надсилає повідомлення про повторне ЗАПРОШЕННЯ CUCM, CUCM надсилає повторне ЗАПРОШЕННЯ іншій Стороні. Однак, якщо це не отримано віддаленою стороною, то це може бути через деякі мережеві пристрої між ними. Цілком можливо, що повторне запрошення/відповідь не надійде до однієї зі сторін через перевірку SIP або налаштування мережі.
Якщо пристрої не ініціюють повторне ЗАПРОШЕННЯ, виникла проблема з пристроєм. Залучайте Центр технічної допомоги Cisco (TAC) для подальшого дослідження.
У списку речей, які необхідно спробувати [якщо цього ще не було] в області розширеної конфігурації зони, яка йде до Webex:
Увімкніть режим фільтра SIP UDP/IX на [не за замовчуванням]:
Також перевірте таймери сеансу SIP на VCS-e.
Наше значення за замовчуванням — 1800-ті [30 хвилин], що є стандартним, і тут потрібно переконатися, що таймер TCP на брандмауері також збігається, але можна трохи збільшити його, щоб побачити, чи він також впливає на ваш VCS.
Це в розділі Конфігурація > Протоколи > SIP.
Зверніть увагу, що інтервал оновлення сеансу (у секундах) встановлено значення за замовчуванням. Ви можете спробувати 3600. Але фактичний корінь проблеми тут полягає в тому, коли FW вважає, що сеанс більше не використовується [випадок 1], коли VCS насправді вважає, що це нормально, і що сеанс все ще вичерпаний, але не отримує FIN/Close на цьому сеансі/порту і намагається використовувати його повторно, і виклик помирає. [випадок 2] - FW належним чином закриває з 'єднання і надсилає FIN/Close, і VCS записує звичайне скидання/очищення виклику, і виклик також помирає. Зміна таймера сеансу тут лише контролює, коли VCS відмовиться від сеансу після того, як йому не вдалося отримати жодного ACK для будь-якого спроби зв 'язку щодо стану виклику.
Однак це може допомогти нам трохи краще прояснити проблему. Також можливо, що нам потрібно знизити це значення залежно від налаштування FW для цього таймера.
ПРИЧИНА
Коли відеовиклики відключаються рівно за 15 хвилин, поширеною проблемою є те, що тайм-аут TCP, налаштований в мережі (брандмауер/маршрутизатори), є меншим, ніж таймер завершення терміну дії сеансу SIP. За замовчуванням у CallManager таймер завершення терміну дії сеансу SIP встановлено на 1800 секунд.
Чи була ця стаття корисною?
