Причина. При отключении видеозвонков через один раз в 15 минут общая проблема заключается в том, что время истечения времени TCP в сети (брандмауэр/маршрутизатор) меньше времени, задаваемое для истечения сеанса SIP. По умолчанию в CallManager значение 'Истечении срока действия сеанса SIP' составляет 1800 секунд.

Решение.

Чтобы проверить это,

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

2. Щелкните Параметры > услуг.
3. В области Выбор сервера и службы в раскрывающийся список службы выберите Cisco Call Manager (Активный).

4. Наыть время истечения сеанса SIP:

Для всех устройств, зарегистрированных в CUCM, используется этот часовой сигнал. Если устройство во время вызова с другим удаленным устройством, один из участников должен обновить сеанс и отправить повторно ПРИГЛАСИТЬ или ОБНОВИТЬ. Это обновление необходимо отправить до истечения получаса сеанса (1800/2 = 900 секунд = 15 минут). Если сообщение об обновлении не получено, вызов отключается.

Проверьте, нет ли в начальном INVITE времени для сеанса. Обновление (INVITE / UPDATE) должно быть получено до истечения этого времени:


На основании первоначального согласования клиента/агента пользователя (UAC/UAS) одно из устройств обновляет сеанс при отправке повторного приглашения. Если переподдерживателем является UAC, инициатор вызова несет ответственность за обновление сеанса. Если перезаверка является UAS, сервер должен обновить сеанс. Соберйте журналы от debug SIP с обеих конечных точек и проверьте эти элементы.Пример

: Вызов, сделанный из стороны A в CUCM участнику B. Если перезап. – UAC для стороны A и UAS для стороны B:

1.     Участник A должен отправить повторное ПРИГЛАШЕНИЕ / ОБНОВЛЕНИЕ в CUCM.
2.     CUCM должен отправить повторное ПРИГЛАШЕНИЕ / ОБНОВЛЕНИЕ участнику B.
3.     Сторона Б получает повторное ПРИГЛАШЕНИЕ и отвечает на это сообщение ОК 200.
4.     CUCM должен отправить 200 OK участнику A.

Если одно устройство отправит сообщение повторного ПРИГЛАШЕНИЯ в CUCM, CUCM отправит повторное ПРИГЛАШЕНИЕ другому участнику. Однако, если удаленный стороной это не получено, то это может быть вследствие того, что некоторые сетевые устройства будут работать в период между. Высокая возможность того, что вследствие проверки SIP или настроек сети запрос повторного приглашения или отклика не дойди с одной из сторон.
Если устройства не инициируют повторное приглашение, это может быть проблемой с устройством. Привлечение центра технической поддержки Cisco (TAC) для дальнейшего исследования.
 
В списке действий, которые необходимо попробовать [если это еще не было] в области advanced config зоны, которая будет переходить к Webex:
Turn the SIP UDP/IX filter mode to on [not the default]:
And check the SIP session timers on VCS-e, а также.

 
По умолчанию [15 минут] – это стандартный стандарт, и вы также хотите убедиться в том, что значение TCP в брандмауэре совпадает, однако это можно сделать лишь в том случае, если он оказывает влияние на ваш VCS.

Это значение находится в области > протоколов > SIP.Обратите
внимание, что для интервала обновления сеанса (в секундах) установлено значение по умолчанию.

Попробуйте 3600. Однако фактический корень проблемы заключается в том, что FW считает, что сеанс больше не используется [случай 1], когда VCS действительно полагает, что все в порядке и что сеанс все еще в сети, но не получает fin/close на этом сеансе/порту и пытается повторно использовать его и позвонить. [case 2] является FW надлежащим образом закрывает соединение и отправляет FIN/close, и VCS записи обычного сброса/сброса вызова, а также соединения. Изменение времени сеанса здесь лишь управляет тем, что VCS отзовется от сеанса после того, как ему не удастся получить какие-либо ACC для любых попыток сообщения о состоянии вызова.
 
Это может помочь нам указать проблему немного лучше. Это значение также может быть снижено в зависимости от настройки FW для этого параметра.