Причина: Когато видео разговорите прекъснат точно на 15 минути, често срещаният проблем е, че времето за изчакване на TCP, конфигурирано в мрежата (защитна стена/рутери), е по-малко от таймера за изтичане на SIP сесията. По подразбиране в CallManager таймерът за изтичане на SIP сесията е зададен на 1800 секунди.

Решение:

За да потвърдите това:

1. Отворете администрацията на Cisco Unified Communications Manager (CM).

2. Кликнете върху Система > Параметри на услугата.
3. Под Избор на сървър и услуга в полето с падащ списък Услуга изберете Cisco Call Manager (активен):

4. Потърсете Таймера за изтичане на SIP сесията:

Всички устройства, регистрирани в CUCM, използват този таймер. Когато устройството е в разговор с друго отдалечено устройство, една от страните трябва да обнови сесията и изпраща повторна ПОКАНА или АКТУАЛИЗАЦИЯ. Това опресняване трябва да бъде изпратено преди половината от таймера за изтичане на сесията (1800/2 = 900 секунди = 15 минути). Ако няма получено съобщение за опресняване, обаждането се прекъсва.

Проверете за таймер за сесия в първоначалната ПОКАНА. Опресняване (ПОКАНА / АКТУАЛИЗИРАНЕ) трябва да бъде получено преди изтичането на това време:


Въз основа на първоначалното договаряне клиент на потребителски агент/сървър на потребителски агент (UAC/UAS), един от устройствата опресняват сесията, когато изпращат Re-INVITE. Ако опресняването е UAC, инициаторът на повикването носи отговорността да обнови сесията. Ако опресняването е UAS, сървърът трябва да обнови сесията. Съберете SIP регистрационните файлове за отстраняване на грешки от двете крайни точки и проверете тези елементи:

Пример: Обаждане, извършено от страна A към CUCM към страна B. Ако опресняването е UAC от страна A и UAS от страна B:

1.     Страна А трябва да изпрати повторната ПОКАНА/АКТУАЛИЗАЦИЯ до CUCM.
2.     CUCM трябва да изпрати повторна ПОКАНА / АКТУАЛИЗАЦИЯ на страна Б.
3.     Страна Б получава повторната покана и отговаря на това съобщение с 200 OK.
4.     CUCM трябва да изпрати 200 OK на страна A.

Ако едно устройство изпрати съобщението RE-INVITE до CUCM, CUCM изпраща повторно INVITE на другата страна. Ако обаче това не се получи от отдалечената страна, това може да се дължи на някои мрежови устройства между тях. Много е възможно повторното ПОКАНА/отговорът да не стигне до една от страните поради проверка на 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 за този таймер.