Cisco TelePresence MSE 8000 Series

My calls involving a Cisco TelePresence MCU, IP GW, IP VCR, ISDN GW, Serial Gateway, Telepresence Server, VCS, Content Server, or endpoint disconnect unexpectedly after a fixed period of time

This article applies to the following products:

• Cisco TelePresence IP GW 3500 / MSE IPGW blade
• Cisco TelePresence IP VCR 2200 / MSE VCR blade
• Cisco TelePresence ISDN GW 3200 and 3241 / MSE 8310 and 8321 ISDN blades
• Cisco TelePresence MCU 4200 Series
• Cisco TelePresence MCU 4500 Series
• Cisco TelePresence MCU 5300 Series
• Cisco TelePresence MCU MSE Series
• Cisco TelePresence Serial GW 3340 / MSE 8330

The following products do not impose call duration limits:

• Cisco TelePresence Servers
• Cisco TelePresence MCUs
• Cisco TelePresence IP Gateways
• Cisco TelePresence IP VCR

Many Gateways including the Cisco TelePresence ISDN GW and Cisco TelePresence Serial Gateway have a configurable maximum time in call which can be found in Settings.

While these limits are of value in preventing unintended costs when a user fails to disconnect their call properly, they can cause frustrating disconnection problems.

In addition, many common firewalls impose a limit on call duration by default. Mismatched Ethernet port settings can cause high packet loss, resulting in calls being dropped.

If you find that calls to or from a certain endpoint always disconnect after a certain amount of time, investigate the following:

1. Duration limits imposed by any gatekeepers involved in a call. The endpoint and the unit could be registered with different gatekeepers; even if the call is being dialed by IP address, rather than by E.164 number, the gatekeepers could still be involved in setting up and tearing down the call.

2. Duration limits applied to network connections by firewalls. For example, a Cisco PIX firewall may have a timeout command of the form:

   timeout conn 1:00:00 udp 0:02:00 h225 1:00:00 h323 2:00:00<

   (i.e. a list of recognized protocol names each followed by a timeout in hours, minutes and seconds). This example imposes a 2-hour limit on H.323 connections; however, it also imposes limits on other protocols which would also affect a video call (UDP and H225). Many different network protocols are involved in an IP video call. A timeout applied to any of them could result in the call being torn down.

3. Timeouts applied on other endpoints and MCUs - for example, the MaxTimeInCall setting on the Polycom MGC.
4. Ethernet switch port settings mismatched. When there is no pattern to the times after which calls disconnect, and the disconnect reasons in the event log include 'H.245 Network Connection Error', it is possible that the Ethernet port settings of your Cisco acquired Codian product do not match those of the switch that it is plugged into.

   It is very important that the Ethernet port settings on your Cisco acquired Codian product or Cisco GW MSE 8330 match those on your switch.

   When settings are mismatched, packet loss can occur, and when packet loss exceeds a certain level, calls between your MCU and your endpoints can be dropped. If one side is set for auto-negotiation, the other side must be set for auto-negotiation ('Auto' must always be used for Gigabit Ethernet). If one side is hard-wired to a certain value (for example, 100 Mbps Full duplex) the other side must be set to the same.

   If both sides are set for auto-negotiation but random disconnections are still occurring, it's a good troubleshooting step to hard-wire both sides to 100 Mbps Full duplex. This will eliminate auto-negotiation issues as the source of your problems.

   Of all these, firewall timeouts are probably the hardest to troubleshoot, because you may not necessarily be aware of the firewall's existence, and even if you are, its configuration is not likely to be readily accessible.