Cderen,

Thanks, I just found out that this location has T3 MPLS circuit, and the bandwidth should be good enough to put a local subscriber at this location as a primary and backed up by remote subscriber.

There are 17 more sites, but the number of IP Phones at those locations are no more than 700. Would 3845/SRST would be an optimal solution as a backup.

3845 would do the job, but I would again think about putting subscriber(s) at locations with 700 phones. Keep in mind that you can have up to 8 call processing servers in a cluster.

Chris

Chris,

Thanks ! The site varies, but I can tell you that four major sites have the following counts.

599 users

566 users

559 users

499 users

476 users

The rest are below 400.

I think that for these sites Dual 3800 should be an optimal solution with one SRST as a Primary and the other one as a Secondary.

Note: I thought that 6.1X cluster can support more than 8 subscribers in a cluster.

Regards,

You can have up to 20 server in a cluster, but only 8 of them can be call processing subscribers. The rest would be Pub, TFTP, MOH, CFB, etc.

So, what is the total number of phones you will have? Do you have other applications such as UCCE in this cluster?

Chris

Here is the details:

Total IP Phones: 6121

Total Voice Mail: 6300

UCCE either express or enterprise

Total number of sites 17

Customer requires high availibility and redundancy and also wants servers to be co-located between two data centers which are just less than 5 miles a part with lot of bandwidth. Here is what I am going to purpose:

Data Center 1: (1) Publisher/TFTP

(1) Subscriber (P)

(1) Subscriber (S)

(1) Unity (1 0f 2) Servers

(1) CER (1 of 2)

Data Center 2: (1) Subscriber (P)

(1) Subscriber (S)

(1) Unity (2 0f 2) Servers

(1) CER (2 of 2)

Each Data Center will have 5 IP Phones, and I will purpose dual 2851 Routers at each data center.

Site with 1500 users: (1) Local Subscriber(P)

(2) 3845 VG w/O SRST

Note: The backup subscriber would be in a data center.

Rest of the sites with have primary subscriber through Data Center and the backed up by SRST 3845 or should I purpose CUME/SRST.

I am also going to purpose one port VWIC 2nd generation card instead of two port. I have heard that that the two port card has issues with clocking that generates CRC, Line Code Violation etc.

Regards,

I would strongly suggest you run your numbers against the capacity calulator as I dont think you have enough subsribers, especially if you are planning on having UCCE agents as that decreases number of phones allowed per subscribers significantly (with 7845 you can only have about 250-300 agent phones). Theoretically a 7845 can support 5,000 phones, but that's assuming very basic config of simple database, no other applications, etc. Alos, you are saying you will not have SRST at the large location, what if your WAN goes down and the server goes down? I would recommand 1 sub at that locaiton and SRST capable GW for redundancy.

I love CME/SRST and would configure it instead of simple SRST everywhere.

I would argue with the VWIC analysis as if you are planning on putting the cards in HWIC slots they are still clocking of off the same router backplane which is a single clocking domain, to avoid possible clocking issues when you connect to seperate providers you would need NM-HDV cards with VWICs as they are on their own clocking domein.

Capacity calculator:

http://www.cisco.com/cgi-bin/CT/PGWCT/ct.cgi

HTH, please rate all helpful post!

Chris

Chris,

Thanks for the feedback, and I really appreciate your inputs.

First, they only have 115 agents. I took your suggestion and ran some basic numbers through the capacity tool, and ironically it calculated total number of servers only 3 with same MGCP errors.

The reason I said that I would not run SRST at the site with 1500 users as I thought that I could provide the backup through the subscriber at the remote location.

Thanks for clearing the issue with VWIC. I thought I could either use NM-HDV slot instead of HWIC for separate clocking or 1-port VWIC card per HWIC slot.