Call Manager Clusters

[samorange]

Hello,

We are planning to design a global solution for an international company, they have offices in europe, LAM, NAM and APAC. My question is what are the parameters that we have to take into consideration to know how many clusters we need to deploy.

For example do we need one in each region or one in AM and one in APAC and Europe.

Is latency is a factor although RTD values are less than 150ms. and as i know RTP is only between phones so CCM is not in the loop.

any thoughts?

[Brandon Buffin]

In my opinion, the fewer clusters the better for reasons of administration, feature transparency, extension mobility, etc. That being said, there are reasons to consider multiple cluster such as > 30k phones, delay, administrative separation, etc. To have servers within a single cluster seperated by a WAN, you need at most 40ms round-trip delay. Take a look at the following link for other considerations regarding choosing a deployment model.

http://www.cisco.com/en/US/customer/products/sw/voicesw/ps556/products_implementation_design_guide_chapter09186a00806e8c27.html

Hope this helps. If so, please rate the post.

Brandon

[samorange]

Thanks Brandon.

First the total number of IP Phones is 3500.

Second point. I understand the limitation for clustering over the WAN. My question is about considerations of deploying multiple clusters.

Why I have to choose 4 clusters in 4 regions to support the 3500 IP Phone and not one cluster that can support all the IP Phones.

In other words:

First Sol:

A Centralized cluster for each region and there is inter-cluster communication between the clusters

Second Sol:

One cluster that servers all the globe.

the second one is the cost effective one but is it recommended ? What are the parameters that determine that?

hope my question is clear this time

[Brandon Buffin]

You could certainly have one cluster that would support 3500 phones. The two driving factors for multiple clusters are the number of phones and latency. The number of phones would not be an issue in your case, but latency could be as packets will be traveling a long distance between sites. I think clustering over the WAN would be a good option if you can meet the 40ms requirement. It would offer centralized administration and local call siganlling which would mitigate the latency involved with phones registering and signalling across the WAN.

Brandon

[samorange]

For the one cluster option . Is latency a factor ?, I know that call manager has nothing to do with calls between phones. right?

do you mean skinny between the phones and Call manager? what is the min latency required?

[mchandak]

The acceptable one way delay for audio is 150 ms. But the roundtrip delay between 2 CMs cannot be more than 40 ms. SDL Link between CallManagers is very sensitive to delay and can cause a lot of replication issues.

[samorange]

i'm asking about skinny

if i have a phone in Sydney and the call manager in Seatle .. is that a problem

i.e phone registeration, conference calls, ..etc any type of communication between the phone and the Call manager that need a min. latency. hope my question is clear now

[JeffG1]

One consideration? if you want to stick your callmanagers all at one site, plan that at some point your wan links to the cluster will go down.. You should plan on SRST for the remote sites. Because of this the current limit of SRST is like 700 phones or something? So once you get to that point it probably better to put a local CCM cluster.

So as I see it you have three options actually.

CCM clusters at each region / site

One CCM cluster with subs at each region / site (limited to 40 ms between subs and pub)

One CCM cluster at one site with SRST at remotes or multiple CCM clusters and SRST?

[samorange]

Thanks Jeff

Iunderstand your point and i already have SRST in my design

My worries are on the one CCM and latency between this CCM and all IP Phones in the world .. Any latency issues would impact the phones registeration right ? so what is the min ? and what are the other factors (other than latency that i have to consider)

For example:-

conference call

applications ( IPMA, attendant console..) those are Microsoft applications that would need min. latency if you will is that right?

make sense?

[eug-c]

Hi,

I guess one of the key concerns is latency and bandwidth.

The features that use lots of bandwidth would prob be the streamings, such as voicemail, MOH. So you either have to have seperate unity servers which have been configured to provide G729 streaming. Multicast MOH can be configured to be provided from the remote voice gateways too.

There is also a minimum bandwidth requirement for each phone signalling. I am still trying to find that number.

Too high latency would cause delays at the user end, example, picking up the phone, you have to wait for a short while before you hear the dial tone. You can do some test by maybe having one phone shipped to the remote offices and doing a simple test. Latency affects all features, users hate this. :(

The WAN link between the countries must be very stable too. Any flapping would cause the phones to register and unregister making the phone totally unusable and you got to put some access list so that at least the phone goes to SRST mode and the users would be able to use the phone.

Hope that helps.

Eugene

[richard-o]

I have used an IP Phone at a remote node connecting to a central CCM Cluster via a satellite connection. The round trip latency of the link depending upon the type of satellite used has varied between 600 - 1000ms. The phones work fine, however there is obviously a large delay for any features.

The main problem encountered was the reliability of the satellite connection rather then the latency. Everything worked perfectly... until the satellite dropped out.

Since then, we've configured CCME in all the remote nodes and entered them as a h323 gateway within CCM

[anthonymd]

Did you ever get the answer to the latency question? I'm curious myself as we are getting ready for a similar deployment and am researching which is the best model.