-
Cisco Unified Communications SRND Based on Cisco Unified Communications Manager 6.x
-
Preface
-
Introduction
-
Unified Communications Deployment Models
-
Network Infrastructure
-
Gateways
-
Cisco Unified CM Trunks
-
Media Resources
-
Music on Hold
-
Call Processing
-
Call Admission Control
-
Dial Plan
-
Emergency Services
-
Third-Party Voicemail Design
-
Cisco Unity
-
Cisco Unity Express
-
Cisco Unified MeetingPlace Integration
-
Cisco Unified MeetingPlace Express
-
IP Video Telephony
-
LDAP Directory Integration
-
IP Telephony Migration Options
-
Voice Security
-
Unified Communications Endpoints
-
Device Mobility
-
Cisco Unified Presence
-
Cisco Unified CM Applications
-
Cisco Mobility Applications
-
Network Management
-
Cisco Unified Communications Manager Business Edition
-
Recommended Hardware and Software Combinations
-
Glossary
-
Index
-
Table Of Contents
Cisco Unified MeetingPlace Express
Unified MPE Capacity and Sizing
Multisite WAN with Centralized Call Processing
Multisite WAN with Distributed Call Processing
Call Admission Control, Bandwidth, and QoS
Bandwidth Considerations for Web Applications and Screen Sharing
External Directory Integration via Unified CM
H.323 and SIP Integration with Unified CM
Redundancy Using H.323 Gateway Integration
Redundancy Using SIP Trunk Integration
Other Important Design Considerations
Cisco Unified MeetingPlace Express
Cisco Unified MeetingPlace Express 2.0 is a rich-media appliance for voice, video and web collaboration. This chapter addresses system-level design considerations around integrating Cisco Unified MeetingPlace Express into a Cisco Unified Communications environment. For detailed product information, refer to the Cisco Unified MeetingPlace Express product documentation available on
Overview
Cisco Unified MeetingPlace Express (Unified MPE) is a voice, video, and web conferencing solution for mid-market to small enterprise customers. The solution implements common industry protocols such as H.323 and Session Initiation Protocol (SIP) to ensure interoperability with various devices in the network. Unified MPE supports both scheduled and reservationless voice, video, and web conferencing. The mixing of voice, video, and web conferencing is provided by software-controlled mixing in the base system. This video mixing does not utilize the Cisco Unified Videoconferening MCU 3500 system and does not integrate to that advanced video solution. The Unified MPE scheduled system supports only basic videoconferencing features and functions such as voice-activated conferencing. If you need advanced videoconferencing features, use a standalone Cisco Unified Videoconferening MCU 3500 or Cisco Unified MeetingPlace system.
Unified MPE Video Telephony is a separate product and is sold as an ad-hoc system only. It does not support scheduled or reservationless meetings. The two systems currently must be deployed on separate Cisco Media Convergence Servers.
Conferencing Support
Unified MPE has different levels of conferencing support when it integrates with the following call processing agents.
•
Unified MPE supports scheduled and reservationless voice and web conferencing with Cisco Unified Communications Manager (Unified CM, formerly Cisco Unified CallManager) 3.x and later.
•
•
•
Video Support
Any H.323, SIP, or Unified CM SCCP endpoint that joins a video conference provided by Unified MPE must be capable of mid-call video escalation. Any industry-standard video endpoints following either the ITU-T H.323 specification or SIP RFC-3261 are able to participate in a video session on Unified MPE, as are all of the supported SCCP third-party endpoints from Sony, Tandberg, or Polycom available on various releases of Unified CM. The H.323 industry endpoints may be registered to either a Cisco IOS Gatekeeper or Unified CM, with dial plan resolution configured for the Unified MPE dial-in numbers.
The following video attributes must be supported by the video endpoint participating in Unified MPE video sessions:
•
•
•
•
•
1. Users can attend video meetings, host video meetings, and reserve video ports.
2. Users can attend video meeting and host video meetings if video ports are available (not scheduled for another meeting).
3. Users can attend video meetings.
Video participant can join a meeting with a bit rate from 64 kbps to 768 kbps. No participant is allowed to join the conference at a bit rate higher than the maximum configured bit rate. If a participant joins the conference at a bit rate lower than the maximum bit rate, the additional capacity will remain in the overall system capacity pool and will be utilized for other participants. Unified MPE cannot transrate among various call speeds; therefore the established video session will use the lowest call speed for all participants per meeting.
Unified MPE uses voice activation mode for the video conference, automatically selecting the dominant speaker by determining which conference participant is speaking the loudest and the longest. The video stream of the active speaker is sent to all endpoints in the conference, and the video stream of the previous speaker is sent to the current active speaker. As conditions change throughout the conference, Unified MPE automatically selects a new dominant speaker and switches the video to display that participant. The active speaker (one image, or 1x1 layout) uses Common Intermediate Format (CIF) dimensions only.
Unified MPE Capacity and Sizing
Unified MPE on a Cisco MCS-7845 server can support up to 150 concurrent users of video conferencing and 200 concurrent users of voice conferencing (each video endpoint uses one voice port and one video port per complete meeting), along with 200 concurrent users of web conferencing, all on a single server.
For specific server models and supported capacities, refer to the latest Cisco Media Convergence Server (MCS) product data sheets and release notes available at
Note that G.729a codec and high-bandwidth video conferences can affect overall system capacity. For assistance with sizing parameters based on the MCS server size, use the Solution Expert Tool, which is available (with appropriate login authentication) at
System Resource Unit (SRU)
A system resource unit (SRU) is a way to allocate various types of resources based on the CPU size of the Cisco Media Convergence Server (MCS) deployed.
A video session with a bit rate of 384 kbps or less requires one SRU. Two SRUs are required for any video session between 384 to 768 kbps. A voice session with a G.711 codec requires one SRU, and a voice session with a G.729a codec requires five audio SRUs. Web conferencing requires two SRUs per user license. The Solution Expert Tool can assist in sizing the correct MCS for your future needs. Also, the Meeting Configuration page in the Web Administration Center enables installed systems to determine how many SRUs are available given a particular G.729a codec and video configuration.
When a participant joins the video conferencing with a call speed of 384 kbps or less, Unified MPE allocates two SRUs, one video user license (UL), and one audio UL for this participant. If this same video endpoint joins with a G.729a codec, then six SRUs are allocated for the voice and video portion of the call, and one voice UL and one audio UL as before.
Unified MPE does not take the flow-controlled bit rate into account for its system capacity calculation. For example, if a 384 kbps participant joins a conference with a video-session bit rate of 768 kbps, that participant lowers the session bit rate to 384 kbps, but Unified MPE still holds two video ULs for the existing session.
Protocol Support
Table 16-1 lists the standard protocols used to integrate Unified MPE with various devices in the Cisco Unified Communications environment.
Table 16-1 Protocols Supported by Unified MPE
Unified CM
H.323, SIP
Gatekeeper
H.323
Directory server via Unified CM only (no direct LDAP)
LDAP
Exchange server
XML
Cisco Unified Personal Communicator
HTTP, HTTPS
Network Time Protocol (NTP) server
NTP1
Web PC
HTTP, HTTPS
1 Unified MPE must be associated with the appropriate NTP server so that Unified MPE can schedule meetings and send out meeting notifications with the correct time.
DTMF Support
Unified MPE supports the following standard dual-tone multifrequency (DTMF) transmission methods:
•
•
For detailed information of DTMF transmission, see the chapter on Media Resources, page 6-1.
Deployment Models
This section describes design recommendations for integrating Unified MPE with the following Cisco Unified Communications deployment models:
•
•
In addition to these deployment models, this section covers deployments based on a demilitarized zone (DMZ). The DMZ deployment is treated separately because it is applicable to each of the deployment models listed above. (See DMZ Deployment.) For detailed information on design rules for the various deployment models, see the chapter on Unified Communications Deployment Models, page 2-1.
Single Site
In a single-site deployment, all call processing is local and all participants are local as well. In this model, Unified MPE connects to Unified CM through an H.323 or SIP connection (see Figure 16-1). In the single-site deployment, use of the G.711 codec is recommended because bandwidth is usually not a concern as it would be in multisite deployments. H.323 video endpoints may be registered to either a Cisco IOS Gatekeeper or Unified CM, with dial plan resolutions between the systems to Unified MPE dial-in numbers. Cisco Unified Videoconferencing 3500 Series Gateways can be deployed to allow external H.320 video clients (which support H.245 Alphanumeric or H.245 Signal for DTMF transmission) to participate in video conferences.
Figure 16-1 Single-Site Deployment
Multisite WAN with Centralized Call Processing
In a multisite WAN deployment with centralized call processing, the Unified MPE server is usually located in the central site, where all call processing occurs. (See Figure 16-2.)
Figure 16-2 Multisite WAN Deployment with Centralized Call Processing
Compared to local participants, remote participants usually require the following additional considerations:
•
•
•
•
•
Multisite WAN with Distributed Call Processing
In a multisite WAN deployment with distributed call processing, Unified MPE is usually located in a site local to Unified CM. Figure 16-3 depicts an example of a multisite WAN deployment with distributed call processing.
Figure 16-3 Multisite WAN Deployment with Distributed Call Processing
Each site in the distributed call processing model can be one of the following:
•
•
•
All the design considerations that have been discussed in the previous two call processing models are also applicable to the multisite WAN deployment with distributed call processing.
Unified MPE is a single server with no cascading, mirroring, or redundancy capabilities, so a single active server at a single site would be typical. There is no communication between different Unified MPE servers, such as the Unified MPE server in central site and the one at branch A in Figure 16-3. An additional server as a secondary active server may be deployed but would not allow for a true failover environment. (See the section Redundancy, for more information.) To have a multisite redundant and distributed collaboration system, consider Cisco Unified MeetingPlace as an option. (See the chapter on Cisco Unified MeetingPlace Integration, page 15-1, for more information.)
The call processing agent at a branch site (for example, branch B in Figure 16-3) can directly route calls to the central-site Unified MPE. This can be done by defining an H.323 gateway or SIP trunk on the branch call processing agent, which points to the central-site Unified MPE. Having multiple call processing agents pointing to the same Unified MPE is not a recommended practice. In order for branch B Unified CM to route calls to the central-site Unified MPE, Cisco recommends routing calls to the central-site Unified CM first, which then directs the calls to its local Unified MPE. Call admission control is performed by the central-site call processing agent or the gatekeeper that is responsible for the intercluster call processing.
Clustering Over the WAN
In a deployment with clustering over the WAN, the Unified CM cluster is split across one or more locations separated by high-capacity and high-speed WAN or MAN links. (See Figure 16-4.) In this call processing model, the maximum one-way delay for all priority Intra-Cluster Communication Signaling (ICCS) traffic between any two Unified CM servers must not exceed 40 ms total round-trip time (RTT) with Unified CM 6.0 or 80 ms RTT with Unified CM 6.1 and later releases.
Figure 16-4 Clustering Over the WAN
Unified MPE does not have any server-to-server redundancy and cannot fully utilize the high-availability nature of this call processing model. An additional server as a secondary active server may be deployed at the alternate site, but it would not allow for a true failover environment. See the section on Redundancy, for more information.
Placement and design considerations for Unified MPE in this model are identical to the previous deployment model, Multisite WAN with Distributed Call Processing.
To have a multisite redundant and distributed collaboration system, consider Cisco Unified MeetingPlace as an option.See the chapter on Cisco Unified MeetingPlace Integration, page 15-1, for more information.
DMZ Deployment
Deploying Unified MPE in a demilitarized zone (DMZ) enables external users (users external to the private network) to participate in web conferences across the Internet. Unified MPE provides the option to use either a single Unified MPE server or Segmented Meeting Access (SMA). SMA allows external users to join publicly listed meetings across the Internet while still keeping voice, video, and privately listed meetings internal to the private network.
There are two approaches to implement Unified MPE servers:
•
•
The first approach is a single-server deployment. A Unified MPE server is deployed inside the DMZ (as in Figure 16-5) to process both the internal (voice, video, and web) and external (voice and web) meeting requests. Profile users, or internal participants, are allowed to schedule meetings on Unified MPE and to list them publicly to anyone who accesses that open system. External meeting participants are not allowed to schedule or find meetings. In order to attend a meeting, external participants must be notified with the meeting information beforehand. Only voice and web meetings can be listed publicly. With this approach, all voice, video, and web conferences are hosted on the Unified MPE server in the DMZ. Appropriate firewall ports would have to be opened between the internal network devices and the DMZ.
External voice calls come into a voice gateway and be treated the same as internal calls being sent into the DMZ to connect to Unified MPE. External web collaboration comes into the DMZ through the external corporate firewall, and internal web collaboration comes through the internal corporate firewall (see Figure 16-5).
Figure 16-5 Single-Server DMZ Deployment
Table 16-2 lists the ports that must be open on the internal corporate firewall so that the firewall will not block communications between Unified MPE and various devices that are located on the internal network.
The following design considerations apply to the firewall configuration:
•
•
•
The second approach is to deploy a secondary SMA server in the DMZ, as shown in Figure 16-6. This approach allows for a complete separation between private and public web meetings and allows for the most secure voice, video, and web conferencing deployment. This approach is highly recommended for most customer scenarios.
Figure 16-6 Dual-Server DMZ Deployment
All private meetings (voice, video, and web) are hosted on the internal Unified MPE server, which is on the internal network but outside the DMZ. Internal participants can schedule both private and public meetings, and external participants can only attend the public meetings. For a public meeting, internal participants send their web and voice streams to the internal Unified MPE server (which is on the internal network but outside the DMZ), while external participants send their web traffic across the Internet to the external web server inside the DMZ and their voice streams to the internal Unified MPE server through the voice gateway on the internal network. For public web collaboration, the meetings are actually hosted on two Unified MPE web instances, one running on the internal Unified MPE server that is on the internal network but outside the DMZ and the other running on the external web server inside the DMZ. Both web instances communicate with each other via HTTP or HTTPS protocol.
The Web module on the external web server connects to the integrated web component of Unified MPE via HTTP or Reliable Multicast Transport Protocol (RMTP). All HTTP and RMTP traffic is tunneled in HTTPS with TCP port 4443. The internal Unified MPE server also sends voice conferencing events to the external web server via SSH protocol (TCP port 22). Both TCP port 4443 and port 22 must be open on the internal corporate firewall to allow communications between the two servers. With the placement of the external web server inside the DMZ, the Web user licenses (ULs) are shared between the external web server and the internal Unified MPE server.
There is another deployment option with the dual-server approach, which can increase system scalability. You can designate the second Cisco Media Convergence Server (MCS) to HOST ALL WEB MEETINGS. This second web-only server can be deployed either internally (on the internal network but outside the DMZ) for private web meetings or externally (inside the DMZ) to allow external participants to join public web meetings. The primary MCS (which is on the internal network but outside the DMZ) serves only voice and video meeting requests, and it provides more capacity for G.729a codec and high-bandwidth video conferencing capacity. With such a setup, internal participants always send their web traffic to the secondary web server for all web meetings, whether public or private. The internal Unified MPE server can then allocate all of its system resources to voice and video meetings if desired. This deployment option should be used only in certain high-capacity scenarios based on customer usage, and it is not recommended for typical customer deployments. For information on platform capacities for this configuration option, refer to the Cisco Media Convergence Server (MCS) release notes and product data sheets available on http://www.cisco.com.
Call Admission Control, Bandwidth, and QoS
This section describes important call admission control, bandwidth, and QoS considerations for Unified MPE deployments.
Call Admission Control
Unified MPE should be treated as a telephony gateway for purposes of call admission control. Unified CM can perform both static-location and RSVP-enabled location call admission control for the voice and video conferences that are hosted on Unified MPE. For additional guidance on call admission control, see the chapter on Call Admission Control, page 9-1.
Bandwidth Considerations for Web Applications and Screen Sharing
Screen sharing consumes large amounts of bandwidth, depending on what a user is sharing. Many colors, content with pictures, and so forth, can cause very large bandwidth requirements. If media imaging, pictures, or high-resolution graphics are shared, that will require higher capacity network bandwidth. Because of the excessive bandwidth and bursty nature of screen sharing, the following design considerations must be observed.
Design Considerations
Use of 100 Mbps for LAN connectivity will limit the number of concurrent web collaboration sessions. When possible, use 1 Gbps connections to the two switch ports.
Users at remote sites that cause web collaboration to traverse a WAN will require special consideration. The client flash session bandwidth or room bandwidth setting for these users should be lowered, reducing the load across the WAN. Because web collaboration data is delivered unicast, the largest burst of data should be multiplied by the number of clients at a remote site. For example, assume a remote site has 100 users, 10 of which are on a web collaboration session at any one time. If bursts of 1.5 Mbps occur in the data from the remote server to each user, 15 Mbps bursts can be experienced across the WAN connection.
When WAN links become congested from excessive web collaboration data or other sources, the degradation of all traffic is compounded by packet loss, retransmissions, and increased latency. Sustained congestion will have a sustained degrading impact on all remote collaboration sessions.
The following settings on the client web collaboration sessions control the rate at which the participant receives data as well as the rate at which the presenter sends data:
•
•
•
Bandwidth bursts above 1,500 kbps are possible if high-resolution images or photos are shared. Sharing normal to complex presentations or documents should not generate bursts above 1,500 kbps unless large complex images are embedded. Bandwidth settings are not automatically adjusted when congestion occurs; they must be adjusted manually. Bandwidth settings default to LAN and must be set at the initialization of each collaboration session. A new session is set to LAN regardless of previous settings.
Bandwidth settings can be adjusted in the following locations in the web collaboration client screen:
•
–
–
–
•
–
–
Note
Note
The client resolution setting also impacts the bandwidth used by limiting the bits per image. A meeting room set at 640x480 pixels will typically generate less than one-third of the traffic compared to a setting of 1280x1024 pixels.
Design Recommendations Summary
•
•
QoS
Quality of Service (QoS) must be implemented in the network to minimize quality impairments such as packet loss, delay, and delay variation, so that participants have a good user experience during the meeting. Unified MPE uses the Differentiated Services Code Point (DSCP) mechanism for its traffic marking and classification.
Traffic from Unified MPE is classified or marked as follows:
•
•
•
•
•
Voice and Call Control Traffic
Voice and call control traffic should be classified with the standard classifications as described in the chapter on Network Infrastructure, page 3-1. If the connection between Unified MPE and the call processing agent extends over a WAN connection, call control traffic should be re-marked to CS3 (DSCP 24).
Web Interface Traffic
No prioritization is recommended for the main web interface. Web traffic to Unified MPE should be treated the same as traffic to other internal web application servers.
Flash Web Collaboration Traffic
Because of the large amounts of bandwidth consumed and the bursty nature of this data as described in the previous section, prioritization of web collaboration traffic across the WAN is not recommended. If you attempt to prioritize the web collaboration traffic, classify it separately and lower than other prioritized data.
External Directory Integration via Unified CM
Integrating an external directory with Unified MPE through Unified CM provides two main functions:
•
•
When Unified MPE is integrated with Unified CM and an external LDAP directory, user profiles are created automatically the first time users log into Unified MPE. The profiles enable users to schedule meetings immediately and use the system.
To log into Unified MPE, the user must have a profile with the correct UserID and password configured natively Unified MPE or the user must be authenticated against the external corporate directory with which Unified CM is integrated.
Cisco Unified CM releases 3.3 and higher as well as 4.x require the application of the Unified CM LDAP plugin, but Unified CM 5.x and 6.x do not require any schema changes to the external LDAP system. Unified MPE supports only the same external LDAP systems and versions as Unified CM supports. Unified MPE integrates with Unified CM 6.x via Cisco AVVID XML Layer (AXL) Simple Object Access Protocol (SOAP). Unified MPE does not support direct LDAP integration to an external corporate directory.
Note
For more information, refer to the Administrator's Configuration and Maintenance Guide for Cisco MeetingPlace Express, available at
H.323 and SIP Integration with Unified CM
Integration with Unified CM can be accomplished by several methods. This section examines two of those methods, H.323 and SIP direct integration, while the third method (H.323 via gatekeeper) is examined in the next section.
The Unified MPE system contains imbedded IP gateway software that integrates to standards-based H.323 and/or SIP systems. Unified CM is the most frequently provided integration with the H.323 gateway configuration. Integration with Unified CM allows Unified CM to perform dial plan resolution, toll-fraud control, and call admission control for conferences hosted by Unified MPE. Any call control system can send inbound calls into Unified MPE without any configuration necessary on the Unified MPE system. (No blocking is done inbound by Unified MPE until all the Voice User Licenses are in use, then busy tone would be returned to the caller.) Only "outdial" configuration on Unified MPE is required for sending any outdial requests to either the H.323 or SIP gateway (but not both). The outdial calls must be resolved by the call processing system for providing Automated Alternate Routing (AAR), toll-fraud control, routing, and so forth, because Unified MPE has no facilities to perform any of those functions.
Customers can publish up to four different numbers to dial into a Unified MPE voice and video system. These numbers are automatically available on the notification templates and consist of the following types:
•
•
•
•
H.323 Gateway
The simplest integration option is to define Unified MPE as an H.323 gateway in Unified CM. You must also configure one or more route patterns in Unified CM, based on customer requirements and pointing to the defined Unified MPE Ethernet IP address.
SIP Trunk
To integrate Unified MPE with Unified CM via a SIP connection, you can configure a SIP trunk directly from Unified CM to Unified MPE. The following design rules apply to this type of integration:
•
•
•
Note
Gatekeeper Integration
Unified MPE can be integrated into a gatekeeper environment in accordance with the design considerations presented in this section. Integration as an H.323 gateway or via a SIP trunk directly from Unified CM is still an option in a gatekeeper environment. The gatekeeper registration method is as a gateway, using a single E.164 address with the registration. Unified MPE will always initiate a video conference as an audio-only session and then escalate to the video conference after the system locates a video-capable endpoint. Unified MPE will send a Bandwidth Request (BRQ) message to the gatekeeper to confirm the requested bandwidth before it starts media capability exchange with the video endpoint. If there is not enough bandwidth for the video escalation, the connection will stay as an audio-only session.
The design considerations in this section must be taken into account when designing a Unified MPE system for use in a gatekeeper environment.
Design Considerations
Note
To force Unified MPE to use a specific local zone, use the no zone command on all zones where you do not want Unified MPE to register. For example, the following commands force Unified MPE (with address 10.20.110.50) to register to testzone2:
gatekeeperzone local mp2-gk1 mp2.com 10.20.105.50zone local testzone2 mp2.comno zone subnet mp2-gk1 10.20.110.50/32 enable
Note
Unified MPE registers as a single E.164 address, so extensions for direct meeting dial-in cannot be reached through a gatekeeper without adding manual entries to the gatekeeper by one of the methods shown in the following examples.
Option 1: Use Zone Prefix to Route (Recommended)
This example routes extensions 1000 through 1009 to Unified MPE.
gatekeeperzone local mp2-gk1 mp2.com 10.20.105.50zone prefix mp2-gk1 100.gw-type-prefix 1#* default-technology gw ipaddr 10.20.110.50 1720Option 2: Use Static E.164 Addresses (Not Recommended)
gatekeeperalias static 10.20.110.50 1720 gkid mp2-gk1 gateway voip ras 10.20.110.50 62675 e164 1005 e164 1008 e164 1007 e164 1006show gatekeeper endpointsCallSignalAddr Port RASSignalAddr Port Zone Name Type Flags--------------- ----- --------------- ----- --------- ---- -----10.20.110.50 1720 10.20.110.50 62675 mp2-gk1 UNKN-GW SE164-ID: 1000H323-ID: MeetingPlaceE164-ID: 1005 (static)E164-ID: 1008 (static)E164-ID: 1007 (static)E164-ID: 1006 (static)Redundancy
This section describes the following types of redundancy:
•
•
•
•
Unified MPE Server Redundancy
Unified MPE is a standalone server with no redundancy built in, except for some server components which are themselves redundant. Mirrored drives, dual power supplies, redundant fans, and so forth, give a high level of internal server redundancy and availability. Other methods outside of the server may be incorporated to enhance redundancy characteristics for calls sent from or delivered to Unified MPE.
Cascaded conferencing between separate Unified MPE servers is not available. Unified MPE and the external web server share one internal database. Although Unified MPE is a standalone server, multiple Unified MPE servers can be deployed using the same Unified CM directory. This configuration enables users to log into an alternate server via the common directory and quickly reschedule meetings if the server they were originally using should fail. Two or more fully licensed Unified MPE servers are need for this option.
Physical Network Redundancy
Unified MPE has two Ethernet ports that are utilized for different purposes: one for call control, web scheduling and administration interfaces, and media; and the other for web collaboration. While traffic rerouting should occur, these ports cannot be relied upon for redundancy. If one port on the server or switch (or the cable between them) fails, the server might not operate properly.
Redundancy Using a Gatekeeper
Inbound Calls
The only other redundancy with respect to inbound calls is gatekeeper redundancy, which would apply to outbound calls as well. You can implement gatekeeper redundancy by either of the following methods:
•
In this method, gatekeepers are set up in a redundant gatekeeper cluster. Unified MPE registers with its defined gatekeeper. Upon registration, the gatekeeper informs Unified MPE of an alternate gatekeeper in the cluster for use in the event of a failure.
•
In this method, two gatekeepers share a single HSRP IP address. In the case of failure, Unified MPE registers to the secondary gatekeeper using the same gatekeeper IP address.
Note
Detailed information about gatekeeper redundancy can be found in the section on Gatekeeper Redundancy, page 8-17.
Outbound Calls
Multiple Unified CM servers in a single cluster can register to a gatekeeper for redundancy. The gatekeeper will choose an active Unified CM to complete an outdial from Unified MPE.
Gatekeeper redundancy as described in the previous section (Inbound Calls) applies to outbound calls as well.
Redundancy Using H.323 Gateway Integration
Inbound Calls
If you integrate Unified MPE as an H.323 gateway, inbound calls will be sent from an available Unified CM server within a cluster. If the server fails, inbound calls will automatically be sent from another server in the cluster.
Outbound Calls
Unified MPE allows for definition of multiple H.323 outdial connections that point to Unified CM, Unified CME, and other H.323-compliant call processing agents. Unified MPE keeps sending outbound calls to the first H.323-compliant call processing agent in the list until an outdial call failure occurs. Then Unified MPE automatically sends an H.225 setup message to the next available call processing agent in the list. Failure of the call processing agent does not affect existing calls. The existing media connection is torn down after the user disconnects.
Redundancy Using SIP Trunk Integration
Inbound Calls
If you integrate Unified MPE using a SIP trunk, inbound calls will be sent from an available Unified CM server within a cluster. If the server fails, inbound calls will automatically be sent from another server in the cluster.
Outbound Calls
Unified MPE allows for definition of multiple SIP outdial connections that point to Unified CM, Unified CME, and other SIP-compliant call processing agents. Unified MPE keeps sending outbound calls to the first SIP-compliant call processing agent in the list until an outdial call failure occurs. Then Unified MPE automatically sends a SIP Invite message to the next available call processing agent in the list. Failure of the call processing agent does not affect existing calls. The existing media connection is torn down after the user disconnects.
Note
Other Important Design Considerations
This section lists other important design considerations not covered previously in this chapter.
Network Connectivity
•
•
IP Telephony Gateways
•
•
