Was this article helpful?
Thanks for your feedback.
Video Calls to Webex Meeting Disconnect after 15 Minutes
Feedback?CUCM/VCS administrators can review this guide for steps to resolve the issue where video devices disconnect at exactly 15 minutes after joining a Webex meeting.
ISSUE
When joining a Webex Meeting with a CUCM-registered video device, the call disconnects at exactly 15 minutes.
RESOLUTION
Review the steps below:
- Open Cisco Unified Communications Manager (CM) Administration.
- Click on System > Service Parameters.
- Under Select Server and Service, in the Service drop-down list box, select Cisco Call Manager (Active):
- Look for the SIP Session Expires Timer:
All the devices registered to CUCM use this timer. When the device is on a call with another remote device, one of the parties has to refresh the session and sends a re-INVITE or UPDATE. This refresh has to be sent before half of the Session Expires Timer ( 1800/2 = 900 seconds = 15 minutes). If there is no refresh message received, the call is disconnected.
Check for session timer in the initial INVITE. A refresh (INVITE / UPDATE) should be received before this time expires:
Based on the initial User Agent Client /User Agent Server (UAC/UAS) negotiation, one of the devices refreshes the session when it sends a Re-INVITE. If the refresher is UAC, the initiator of the call has the responsibility to refresh the session. If the refresher is UAS, the server has to refresh the session. Collect the SIP debug logs from both endpoints and check these items:
Example: Call made from Party A to CUCM to Party B. If the refresher is UAC on Party A and UAS on Party B:
1. Party A has to send the re-INVITE / UPDATE to the CUCM.
2. CUCM has to send a re-INVITE / UPDATE to Party B.
3. Party B receives the re-INVITE and responds to that message with a 200 OK.
4. CUCM has to send 200 OK to Party A.
If one device sends the re-INVITE message to the CUCM, CUCM sends a re-INVITE to the other Party. However, if this is not received by the remote side then this could be because of some network devices in between. It is highly possible that the re-INVITE/response does not get to one of the sides due to SIP inspection or network settings.
If the devices do not initiate the re-INVITE, it could be a problem with the device. Involve Cisco Technical Assistance Center (TAC) in order to investigate further.
On the list of things to try [if this hasn't already] in the advanced config area of the zone going to Webex:
Turn the SIP UDP/IX filter mode to on [not the default]:
And check the SIP session timers on VCS-e as well.
Our default is 1800s [30 mins], which is standard and you’ll want to make sure the TCP timer on your Firewall matches here as well, but you could bump this up a little to see if it has an effect as well on your VCS.
This is under Configuration > Protocols > SIP:
Note the Session refresh interval (seconds) is set to the default value. You might try 3600. But the actual root of the problem here is when the FW thinks that a session is no longer in use [case 1], when VCS actually think it's ok and that the session is still up but doesn’t receive a FIN/close on that session/port and attempts to re-use it and the call dies. [case 2] is the FW properly closes the connection and sends a FIN/close and VCS records a normal call drop/clearing and the call also dies. Modifying the session timer here just controls when VCS will give up on a session after it has failed to receive any ACKs for any attempted communication regarding the status of the call.
It can help us pinpoint the problem a little better though. It’s also possible we need to lower this value depending on the FW setting for this timer.
CAUSE
When video calls disconnect at exactly 15 minutes, the common problem is that the TCP timeout configured on the network (firewall/routers) is less than the SIP session expires timer. By default on CallManager, the SIP Session Expire Timer is set to 1800 seconds.
Was this article helpful?
