How Close To Your Phones Does a CUCM Cluster Have To Be?

The first things involved in designing a Unified Communications network are deciding where to put the Cisco Unified Communications Manager (CUCM) clusters, and how many clusters to have. And some of the major factors to consider are “Where are the phones? How many are there, and how close to the phones does a cluster have to be?” Ideally, you’d want as few clusters as possible for lower overhead costs, and you would only have more than one cluster if you needed to support more devices than a cluster could support (today, around 30,000 devices per cluster). But there are distance limitations, too. Put a cluster too far away from the phones, and you end up with delay-related call-setup issues, which turn out to be hard to diagnose.

It’s very difficult to determine what the distance limitation should be. Cisco IT has phones in Europe that are about 2000 miles away from the CUCM cluster in Amsterdam. We also used to have phones in Johannesburg, South Africa, connected to the cluster in Amsterdam over 5,000 miles away, but ended up creating a separate Johannesburg cluster for these phones and others nearby, due to some sporadic call set-up issues. Still, this was quite a while ago, when we were running very early versions of CUCM. Perhaps that wouldn’t be an issue today – and some of our engineers talk about connecting Johannesburg back to our Amsterdam-based cluster.  I’ve spoken with customers more recently who tell me that their clusters are in the US, but they connect to phones all over the world – possibly 10,000 miles or more away. (I’ll note that Cisco IT has a single TelePresence cluster in San Jose, supporting TelePresence units over 10,000 miles away.  But that’s TelePresence). So, what ARE the rules?

There appear to be some hard and fast rules for how far away clusters can be located; but no real consensus. Only one part is clear. Distance is not really the issue: its delay (sometimes called latency). Delay is determined by a lot of things – distance, of course, as well as the bandwidth connecting phones to clusters, and to a lesser extent, the number of intervening routers, noise or jitter on the line, the voice compression process, and more. As every network is different, there are no good rules for translating delay into real-world distance.  Pinging different endpoints on your network is probably the only way to find out. (For a good analysis of all the Voice over IP variables that can add delay, see “Understanding Delay in Packet Voice Networks“) This same document says that “For private networks 200 milliseconds of (one-way) delay is a reasonable goal and 250 milliseconds a limit”, yet then points out that 400 milliseconds should be the hard upper limit, while noting that “in some exceptional cases this limit is exceeded.”

One official statement from the Cisco Solution Reference Network Design (SRND) for CUCM 9 is that the cluster must be within a 150 milliseconds one-way delay. “… One-way delay [that] exceeds 150 milliseconds, introduces issues not only with the quality of the voice call but also with call setup and media cut-through times because several call signaling messages need to be exchanged between each device and the call processing application in order to establish the call.” (See the “Delay in IP Voice Networks” section of the SRND; emphasis mine).

As you see – there’s no real strong consensus on exactly how far away a cluster can be from its phones.  For a more real-world point of view, our IT UC engineer, Kees Gerritsen, tells me that our rule of thumb is closer to 200 milliseconds, one-way; and that we still violate this rule if needed. He says “For Real-time Transport Protocol latency, the longer the distance the more user impact you will notice.  For conferencing, this delay effect can be increased as the media mixer is in between. Within Cisco IT, we allow signaling (between phone and cluster) with a latency of 200 milliseconds, one-way delay, which is acceptable. At the same time we have one exception cluster, our TelePresence cluster (located in San Jose, but controlling the 1600 TelePresence units located all over the globe) which is far more than 200 milliseconds one-way.”

So – apologies in advance – I have to end this blog with the same question I started with, and I’ll ask you:  How far away are YOUR IP Phones from their CUCM cluster? Do you experience any problems with delay? What were your solutions if you experienced any issues?

Share