Jots for today

MULTISITE DISTRIBUTED AND CLUSTERING DEPLOYMENT MODELS

MULTISITE DISTRIBUTED MODEL:

-multiple independent sites, with own call-processing agent cluster connected to an IP WAN

A distributed call-processing site may consist of:

-single site with its own call-processing agent (may be CUCM or CUCM Express, or other IP PBX)

-a centralized call-processing site and all of its associated remote sites.

-legacy PBX with VOIP gateway

IP WAN interconnects all the distributed call-processing sites - PSTN serves as a backup connection between sites in case of IP WAN failure. A site connected only thru the PSTN is a standalone site and is not covered by dist call-proc mod.

WAN CONNECTIVITY OPTIONS:


-leased lines

-Frame Relay

-ATM

-ATM and Frame Relay service internetworking (SIW)

-Multiprotocol label switching (MPLS) VPN

-Voice and video Enabled VPN (V3PN) IPSec protocol

Multisite dist call proc allows each site to be independent.
IP WAN failure or insufficient bandwidth wiil not cause a site to lose call-proc service or functionality. CUCM simply send all calls between the sites across the PSTN.

DESIGN CHARACTERISTICS:

-SCCP or SIP IP PHONES

Max 30,000 Skinny CCP (SCCP) or Session IP (SIP) IP phones or SCCP video endpoints per cluster

-MGCP GATEWAYS or H.323 devices

1,100 per CUCM cluster

-PSTN

for external call

-DSP resources

for conferencing, transcoding and MTP

-Voice mail and unified messaging

-legacy PBX and voice-mail systems

-H.323 clients, multipoint control units, H.323/H.320 gateways

Multipoint control unit resources

required for multipoint video-conferencing.

H.323/H.320 video gateways: needed to comm with H.323 video conferencing devices on the ISDN network.


-High-bandwidth audio:


-High-bandwidth video


-Min of 768kbps or higher WAN link speeds - video not recomm for WAN links with speed lower than 768kbps.


-CUCM locations and automated alternate routing (AAR) - CUCM provides CAC.


BENEFITS OF THE MULTISITE WAN WITH DIST CALL PROC:

-Cost savings on using IP WAN for calls between sites

-Use of IP WAN for tail-end hop-off (TEHO) - IP WAN is used to bypass toll charges by routing calls thru remote gateways closer to the PSTN number dialed.

- Max util of avail bandwidth by allowing the voice traffic to share the IP WAN with other types of traffic

-No loss of functionality during an IP WAN failure

-Scalability to hundreds of sites

BEST PRACTISE

A multisite dist call proc deployment is a superset of the Single-site deployment and the multisite WAN with centralized call proc - follow the best practises of both.

Some KEY ELEMENTS:

Gatekeeper or SIP proxy servers are among key elements in this model

-they provide dial plan resolution, with gatekeeper providing CAC.

-a gatekeeper is an H.323 device that provides CAC and E.164 dial plan resolution.


BEST PRACTICES FOR USING A GATEKEEPER:

-use a Cisco IOS gatekeeper

-use HSRP gatekeeper pairs, gatekeeper clustering and alternate gatekeeper support

-size platforms appropriately

-use only one type of codec on the WAN - because H.323 does not allow for Layer 2, IP, UDP, or RTP header overhead in the bandwidth request.

Gatekeeper networks can scale to hundreds of sites.


SIP devices provide provide resolution of E.164 numbers as well as SIP Uniform Resource Identifiers (URIs) to enable endpoints place calls to each other. CUCM supports the use of E.164 numbers only

BEST PRACTICES FOR SIP PROXIES:

-provide adequate redundancy for the SIP proxies

-ensure that the SIP proxies have the capcity for the call rate and number of calls reqd in the network.

RECOMMENDED CALL-PROC AGENTS FOR DIST CALL PROC:

1. CUCM EXPRESS:

-recommended size: up to 240 phones

-small remote sites

-capacity depends on IOS

2. CUCM:

-recommended size: 50 to 30,000 phones

-small to large sites depnding on size of the CUC

-supports centralized or dist

3. Legacy PBX with VOIP gateway:

-recommended size: depends on PBX

-number of IP WAN calls and functionality depends on the PBX-to-VOIP gateway protocol and the gateway



CLUSTERING OVER THE IP WAN DEPLOYMENT:

A single CUCM cluster and its subscriber servers are split across multiple sites connected via a QoS-enabled WAN

TWO TYPES OF DEPLOYMENTS SUPPORTED HERE|:

1. local failover deployment model


CUCM subscriber and backup server have to be at the same site with no WAN in between. Ideal for 2 or 4 sites with CUCM.

2. remote failover deployment model

Backup servers are allowed to be deployed over the WAN. can have up to 8 sites with CUCM subscribers being backed up CUCM subscribers at another site.

Might need higher bandwidth because of a large amount of intracluster traffic

A combo of both deployments can also be used.

ADVANTAGES OF CLUSTERING OVER THE IP WAN:

-single point of administration for users for all sites within the cluster

-feature transparency

-shared line appearances

-extension mobility within the cluster

-unified dial plan

Ideal as a disaster recovery plan

-useful for customers who require more functionality than the limited feature set offered by the SRST

-allows remote offices to support more Cisco IP phones than SRST does in the event connection to CUCM is lost.


WAN CONSIDERATIONS:

The Intra-Cluster Communication Signaling (ICCS) between CUCM servers consists of many traffic types. The ICCS traffic types are classified as either priority or best effort.

Priority ICCS traffic is marked with IP Precedence 3 (DSCP 24 or PHB CS3). Best-effort ICCS traffic is marked with IP Precedence 0 (DSCP 0 or PHB BE).

The following design guidelines apply to the indicated WAN characteristics:

-delay

The maximum one-way delay between any UCM servers for all priority ICCS
traffic should not exceed 20 ms, or 40 ms round-trip time (RTT). Delay for other
ICCS traffic should be kept reasonable to provide timely database access.
Propagation delay between two sites introduces 6 microseconds per kilometer without
any other network delays being considered. This equates to a theoretical maximum
distance of approximately 3000 km for 20 ms delay or approximately 1860
miles.

-jitter

Jitter is the varying delay that packets incur through the network because of
processing, queue, buffer, congestion, or path variation delay. Jitter for the IP
Precedence 3 ICCS traffic must be minimized using QoS features.

-packet loss and error

The network should be engineered to provide sufficient prioritized
bandwidth for all ICCS traffic, especially the priority ICCS traffic. Standard
QoS mechanisms must be implemented to avoid congestion and packet loss. If packets
are lost due to line errors or other “real world” conditions, an ICCS packet will be
retransmitted because it uses the TCP protocol for reliable transmission. The retransmission might result in a call being delayed during setup, disconnect
(teardown), or other supplementary services during the call. Some packet-loss conditions could result in a lost call, but this scenario should be no more likely than errors occurring on a T1 or E1, which affect calls via a trunk to the PSTN/ISDN

-bandwidth

Provision the correct amount of bandwidth between each server for the
expected call volume, type of devices, and number of devices. This bandwidth is in
addition to any other bandwidth for other applications sharing the network, including
voice and video traffic between the sites. The bandwidth provisioned must have
QoS enabled to provide the prioritization and scheduling for the different classes of
traffic. The general rule for bandwidth is to overprovision and undersubscribe.

-QoS

The network infrastructure relies on QoS engineering to provide consistent and
predictable end-to-end levels of service for traffic.