Thanks for your feedback.
Feedback?Calls to CMR Hybrid and Video Device-Enabled Meetings (V1, V2) are disconnecting during the call.
Calls to CMR Hybrid are disconnecting during the call.
How do I configure TCP timers on my firewall for Video Device-Enabled Meetings?
Calls to Cisco Webex Video Device-Enabled Meetings (V1, V2) (formerly CMR) Meetings are disconnecting during the call.
How do I configure TCP timers on my firewall for Webex Cloud Connected Audio?
Note: CMR Hybrid becomes End of Support effectively on February 28, 2021. After 02/28/2021, CMR Hybrid service will continue till April 2021 (End of Life) and at that point, CMR Hybrid customers will be auto migrated to the latest version of CMR Cloud.
Solution:
Firewall TCP Timers and their Use within:
- Collaboration Meeting Rooms (CMR) Hybrid
- Cisco Webex Video Device-Enabled Meetings (V1, V2) (formerly CMR)
- Webex Cloud Connected Audio ((formerly CCA)
In customer environments with strict firewall settings it is imperative to consider the importance of TCP sessions inside of the CMR solution.
In CMR or Video Device-Enabled Meetings, there is an active bi-directional TCP session between the customer Cisco Expressway and the Webex Edge components. The Webex Edge component has a default TCP connection timer of 30 minutes. A Cisco Expressway will have a default TCP connection timer of 2 hours.
When configuring your firewall it is important that the firewall never be allowed to silently drop the TCP connection in less than 30 minutes.
If a firewall is configured to silently drop a TCP connection in less than 30 minutes a SIP re-invite may be sent to the Cisco Expressway on the TCP connection that has been closed. The Firewall will drop that connection. Webex will timeout the Re-Invite and subsequently send a BYE message to the customer. This Bye message will usually use the same TCP port and may be dropped as well.
Later on the Cisco Expressway will send an invite to the Webex side. The Re-invite will use a new or non-terminated TCP connection. As such it will be allowed through the firewall and reach Webex. Webex will respond with an error code (481 Call/Transaction Does Not Exist) indicating the call does not exist.
It is also important to note that a TCP session is not unique on a per call basis. If the Cisco Expressway or Webex edge is sending a message to the same destination and already has (what it believes to be) an open TCP connection to that destination IP address the same port will be used for multiple conferences or calls.
This can cause multiple calls or conferences to be torn down at the same or similar times.
See the below diagram for details on the issue:
