大型企业是指超过三万门分机以上的企业，且分布的节点数量相对较多，对系统的各方面的要求都较高，如思科当前的用户中有：美洲银行18万部IP电话，波音15万部IP电话，福特5万部IP电话，思科自己4万部IP电话等等，对于这类型的客户，其需要的Callmanager集群数量已超过一个，往往需要多个。
对于这一类型的客户可以使用专门的思科CallManager软硬件平台，基于企业内部IP网实施，其主要包括：
放置于一个或多个中心节点的多台CallManager系统，这些系统构成一个逻辑上的控制中心-----CM集群。
在需要本地接入的节点配置语音网关设备，并为提高该远程节点的可靠性，语音网关配置SRST功能
在有通话需求的地方布置IP电话
以下将通常的几种实施方式介绍如下：
1）采用集中式呼叫处理方式
采用集中式呼叫处理的多地点WAN模式包括一个可以为多个地点提供服务的呼叫处理代理，它利用IP WAN在不同的地点之间传输语音流量。IP WAN还负责在中央地点和远程地点之间传输呼叫控制信号。这种模式适用于下面这种情况：一个主要地点通过一个支持QoS的WAN与多个较小的远程地点连接，但是在WAN发生中断时并不需要全部的特性和功能。
图1-2 集中式呼叫处理部署模式
在部署采用集中式呼叫处理的多地点WAN模式时，请遵循下列原则和最佳实践：
最大限度地降低Cisco CallManager和远程地点之间的延时，以缩短语音直通延时（也被称为削波）。
对于集中星型拓扑，使用Cisco CallManager中的位置机制对进出远程分支机构的呼叫进行准入控制。如果WAN使用Cisco IOS多协议标签交换（MPLS）
位置机制可以跨越多台采用Cisco CallManager 3.1及其以上版本的服务器。当Cisco CallManager运行在所支持的最大的服务器上时，这种配置最多可以支持3万部IP电话。
每个分支机构在可存活远程地点电话（SRST）模式下支持的IP电话和号码的个数取决于分支机构的路由器平台，所安装的内存的容量，以及CiscoIOS的版本。（如需查看最新的SRST平台和代码规格，请参考Cisco.com提供的SRST文档） 但是一般而言，为一个指定地点选择集中式呼叫处理还是分布式呼叫处理方法取决于多个因素，例如：
- IP WAN带宽或者延时限制
- 语音网络的重要性
- 功能集需求
- 可扩展性
- 管理的方便性
- 成本
针对集中式呼叫处理的呼叫准入控制
多地点部署需要某种形式的呼叫准入控制，以确保在带宽有限的网络连接上传输的呼叫的语音质量。Cisco CallManager为在采用集中式呼叫处理的多地点WAN部署中实施呼叫准入控制提供了一种被称为“位置”的简便机制。
z 位置机制需要一个集中星型网络拓扑。
z 在Cisco CallManager中为每个地点设置一个单独的位置。
z 根据每个地点所使用的编解码器的类型，为每个地点设置适当的带宽限制。
z 将Cisco CallManager中设置的各个设备分配到某个位置。如果您将某个设备移动到另外一个地点，您需要更改它的位置设置。
2）采用分布式呼叫处理的多地点WAN
采用分布式呼叫处理的多地点WAN模式包括多个独立的地点，每个都配有自己的呼叫处理代理，并连接到一个IP WAN。这个WAN负责在分散的地点之间传输语音流量。这种模式中的IP WAN不需要在地点之间传输呼叫控制信号，因为每个地点都拥有自己的呼叫处理代理。
这种模式适用于下面这种情况：一个拥有超过3万条线路的大型中央地点，或者一个系统中包含6个通过支持QoS的WAN相连的大型地点（线路总数超过3万条）。
图1-3 分布式呼叫处理模式
采用分布式呼叫处理的多地点WAN的很多要求与采用集中式呼叫处理的单一地点和多地点WAN相同。
关守是采用分布式呼叫处理的多地点WAN模式中的核心组件之一。
关守是一种可以提供呼叫准入控制和E.164拨号计划解析的H.323设备。在使用关守时，应当遵循下列最佳实践：
为关守使用一个逻辑上的集中星型拓扑。关守可以管理进出某个地点的带宽，或者同一个地点中的不同区域之间的带宽，但是它并不能感知拓扑结构。
为了提高关守的可用性，应使用热备用路由器协议（HSRP）关守对、关守群集和替代关守支持。此外，应使用多个关守在网络中提供冗余。
在WAN中只使用一种编解码器，因为H.323标准并不支持在带宽请求中使用第二层、IP、用户数据协议（UDP）或者实时传输协议（RTP）报头负载。（报头负载只能用在分组的有效负荷或者经过编码的语音部分中）在WAN上只使用一种编解码器让用户无需通过过度使用IP WAN应付最坏的情况，因而可以简化容量规划。
z 关守网络可以拓展到数百个地点，设计方案只受限于集中星型拓扑。
针对分布式呼叫处理的呼叫准入控制
多地点部署需要采取某种形式的呼叫准入控制，以确保在带宽有限的网络连接上传输的呼叫的语音质量。对于一个采用分布式呼叫处理的多地点WAN部署，您可以根据需要采用下列呼叫准入控制方式中的一种：
z 对于部署在一个高速LAN或者WAN上的Cisco CallManager群集，使用群集间中继
z 对于公用电话旁路或者与某个现有H.323环境的集成，建议使用H.225关守控制中继
z 对于一个采用集中星型（即星型）拓扑的WAN，建议使用群集间关守控制中继
z 对于所有其他情况，包括没有采用集中星型拓扑的网络，您可以将位置和关守机制结合起来使用。使用群集间关守控制中继和位置机制，如图1-4所示
图1-4 将位置与关守呼叫准入控制结合到一起
3）基于IP WAN 的群集
这种模式是指在多个通过一个支持QoS功能的IP WAN相连的地点之间部署统一的Cisco CallManager群集。
这种模式适用于通过一个支持QoS的WAN连接最多六个大型站点（线路总数不超过3万条）的网络部署。
基于WAN的群集可以支持两种部署：
z 本地故障恢复部署模式，如图1-5所示
图1-5 针对两地点配置的本地故障恢复模式
z 本地故障恢复需要您将Cisco CallManager主用和备用服务器放在同一个地点，而且两者之间没有WAN连接。这种部署模式适用于下面这种情况：有两个或者三个配有Cisco CallManager服务器的地点，每个地点分别最多有5000或者2500部IP电话。这种模式让两地点配置和三地点配置分别最多可以支持10000部和7500部IP电话。
z 总而言之，在使用本地故障恢复模式时应当遵循下列原则：
z 通过设置，让每个地点至少包含一个主Cisco CallManager服务器和一个备用服务器。
z 设置Cisco CallManager 群组和设备池，以便让该地点的设备在任何情况下只注册到该地点中的服务器。
z 思科强烈建议您复制每个配有IP电话的地点的关键服务（TFTP、DNS、DHCP、LDAP和IP电话服务）、所有媒介资源（会议桥和等待音乐）和网关，以提供最高级别的永续性。您还可以进一步扩大这种做法的范围，在每个地点添加一个语音邮件系统。在WAN发生故障的情况下，只有无法访问发布端数据库的地点会损失少量功能。
z 群集中的每1万个忙时呼叫请求（BHCA）需要900kbps的带宽传输群集间通信信号（ICCS）。这是最大限度的带宽要求，因而带宽是以900 kbps 倍数的形式提供的。
z 除了实时ICCS带宽以外，SQL、CTI Manager和LDAP流量还需要群集间带宽。所需要的额外带宽取决于系统的具体应用。例如，移动分机功能的使用会增加服务器之间传输的SQL流量。
z Cisco CallManager群集中的任何两台路由器之间的最大往返时间（RTT）不超过40ms。这相当于单程延时最大不超过20ms，或者在理想情况下传输大约1860英里（3000公里）的距离。
z 远程故障恢复部署模式，如图1-6所示
z 图1-6 包含四个地点的远程故障恢复模式
远程故障恢复让您可以在WAN上部署备用服务器。利用这种部署模式，您最多可以在6个地点中部署Cisco CallManager主服务器，并且其中的一个或者两个地点部署Cisco CallManager备用服务器。这种部署可以在用户需要的地点中共享最多1万部IP电话。
总而言之，在使用远程故障恢复模式时应当遵循下列原则：
z 通过设置，让每个地点至少包含一个主Cisco CallManager服务器，如有必要还可以添加一个可选的备用服务器。
z 您可以设置Cisco CallManager 群组和设备池，从而让设备可以注册到WAN上的服务器。
z 思科强烈建议您复制每个配有IP电话的地点的关键服务（TFTP、DNS、DHCP、LDAP和IP电话服务）、所有媒介资源（会议桥和等待音乐）和网关，以提供最高级别的永续性。您还可以进一步扩大这种做法的范围，在每个地点添加一个语音邮件系统。在WAN发生故障的情况下，只有无法访问发布端数据库的地点会损失少量功能。
z 群集中的每1万个忙时呼叫请求（BHCA）需要900kbps的带宽传输群集间通信信号（ICCS）。这是最低限度的带宽要求，因而带宽是以900 kbps 倍数的形式提供的。
z 除了实时ICCS带宽以外，SQL、CTI Manager和LDAP流量还需要群集间带宽。所需要的额外带宽取决于系统的具体应用。例如，移动分机功能的使用会增加服务器之间传输的SQL流量。
z 当设备通过WAN，注册到位于同一个群集中的远程Cisco CallManager服务器时，信令或者控制面板流量将需要额外的带宽。
z Cisco CallManager群集中的任何两台路由器之间的最大往返时间（RTT）不超过40ms。这相当于单程延时最大不超过20ms，或者在理想情况下传输大约1860英里（3000公里）的距离。
来源：中国VOIP论坛
