This article relates to the Cisco TelePresence MCU 4203, Cisco TelePresence MCU MSE 8420, Cisco TelePresence IP VCR 2210, Cisco TelePresence VCR MSE 8220, Cisco TelePresence ISDN GW 3241, Cisco TelePresence ISDN GW MSE 8321, Cisco TelePresence IP GW 3510, Cisco TelePresence MCU 4505 and Cisco TelePresence MCU MSE 8510 products.
A. This FAQ is under revision
The following products do not impose call duration limits:
TANDBERG Telepresence Servers
TANDBERG Codian MCUs
TANDBERG Codian IP Gateways
TANDBERG Codian IP VCRs
Many ISDN Gateways including the TANDBERG Codian ISDN GW have a configurable maximum time in call which can be found in Settings > ISDN
Most gatekeepers including the TANDBERG VCS and TANDBERG Gatekeeper can be configured to allow a maximum call duration.
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:
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.
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.
Timeouts applied on other endpoints and MCUs - for example, the MaxTimeInCall setting on the Polycom MGC.
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 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 Codian product 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.
Revision | Publish Date | Comments |
---|---|---|
1.0 |
23-Apr-2015 |
Initial Release |