SRST remote site vs. Cluster over WAN

Unanswered Question
Mar 8th, 2007

Hi, tech seniors,

I am in a dilema in a IPT design.

I am adding a remote site into our existing CallManager cluster.Tt will be a big big remote campus site with around 800 to 1,200 phones. I have two options here:

1. Typical SRST remote site.

2. Local CallManager Subscriber for cluster over WAN.

The pro to do with SRST remote site is I do not need to worry about the bandwidth and delay over WAN, since we already have remote subscriber at another remote site. The con is I need to set up complicated SRST call routing at the remote site gateways, since the remote site itself is a campus.

I am wondering which solution would you guys prefer? And for best practice, have you ever heard about SRST remote site with that many phones?

Thanks a lot,

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (1 ratings)
lfulgenzi Thu, 03/08/2007 - 15:00

We were (are) in the same boat. We had to decide on whether to put a subscriber out to a remote site or use SRST. We opted for SRST for a number of reasons. Here are just a few:

- Using a subscriber is not scalable. If you have the potential for multiple sites, then you will run out of subscribers, since each cluster can only handle 5 (I think) (for now).

- A subscriber has to be updated far more often than a router. Unless the remote site is down the road, co-ordinating these efforts can be difficult and expensive.

- Max end devices on SRST routers has steadily been increasing. The 3845 can handle up to 720 phones. Might not sound like a lot, but do you really need ALL your phones working in the event of a WAN failure?

- Assuming you need a voicegateway anyways, the incremental cost of sizing up your router is likely less than the cost of another subscriber.

- The feature set of SRST is getting better and better, I was quite impressed with what is available in the event of a failure. As long as your clients are properly prepared and briefed, many of them will likely not even notice.

- As far as complicated call routing, I'm not sure what you mean. All the routing would be handled by CallManager. In the event SRST kicks in, dial-peers take over. With CoR lists you can do a pretty good job of assigning classes of service. There are limitations for sure, but it's still pretty good.

- As far as hearing about that many phones, we are planning a deployment of about 300 - 400 phones and I haven't heard any warnings. The only thing you have to worry about is memory on the router. Buy lots. Unfortunately, there is no memory calculator and the TAC can't even provide recommendations or rough estimates.

Hope that helps.

soupseven Fri, 03/09/2007 - 06:03


It makes sense.

The remote site is a campus having many satellite sites, where also will be deployed local gateways. So we may have many dial peer setup during SRST. I also have to consider the link outage between the satellite sites.

Any other concerns?

lfulgenzi Fri, 03/09/2007 - 06:37

That will definately be more complex. But if you think of each site (whether campus or satellite) as an SRST site, and use the same dial-peers, you should be OK. When you configure the dial-peers, use a trunk group, so all you have to do is copy the dial-peers over and modify the trunk group. Other than local 7 and 10 digit dialing, you shouldn't have to make too many changes.

That's what I would do.

Work with your business office to give you a little slack with respect to your SRST configs, let them know that not everything will be the same, and they should be OK with that.


This Discussion