Cisco Unified Communications SRND Based on Cisco Unified CallManager 4.x
Cisco Unified MeetingPlace Integration
Downloads: This chapterpdf (PDF - 758.0KB) The complete bookPDF (PDF - 13.07MB) | Feedback

Cisco Unified MeetingPlace Integration

Table Of Contents

Cisco Unified MeetingPlace Integration

MeetingPlace Server Recommendations

Deployment Models

MeetingPlace Components

MeetingPlace Audio Server

MeetingPlace H.323/SIP IP Gateway

Sizing a MeetingPlace Deployment

Sizing Voice Conferencing Usage

Sizing Web Conferencing Usage

Video Integration and Sizing the MCU

MeetingPlace Network Infrastructure

Connectivity Between MeetingPlace and IP Telephony Components

Quality of Service (QoS)

Traffic Classification

Call Admission Control and Bandwidth Provisioning

Rate and Codec Selection for Audio and Video

MeetingPlace Web Session Network Utilization

Jitter

Domain Name System (DNS)

Network Time Protocol (NTP)

Demilitarized Zone (DMZ) Requirements

Interoperability Protocols

Internet Protocol (IP) Network

Protocols Supported by the MeetingPlace Audio Server

Protocols Supported by Other MeetingPlace Components

Public Switched Telephone Network (PSTN)

Digital Trunks

Conferencing

Audio Conferencing

Call Flow

Meeting Type

Port Management

Scheduling

Audio Conference Cascading

Dialing into an Audio-Only Conference Using Video Endpoints

Web Conferencing

MeetingPlace Web Server

SQL Database

Meeting Type

Web Conference Cascading

Segmented Meetings

Video Conferencing

Voice Link

MeetingPlace Video

MCU Configuration

Enhanced Media Processor (EMP) Requirement

Port Management

Scheduling

Attending a Video Conference

Meeting Type

Video Conference Call Flow

Video Conference Cascading

Gatekeeper and Dial Plan

Dynamic H.323 Addressing in Cisco Unified CallManager

Cisco Unified CallManager Redundancy Groups and H.323 Clients

MCU Registration

MeetingPlace

Reservationless Single Number Access (RSNA)

Redundancy and Load Balancing

MeetingPlace Audio Server

MeetingPlace H.323/SIP IP Gateway

MeetingPlace Web

Cisco Unified CallManager

MeetingPlace Video

MCU


Cisco Unified MeetingPlace Integration


Last revised on: February 13, 2008

 

This chapter describes the technical and design issues for incorporating Cisco Unified MeetingPlace into an existing Cisco Unified Communications network. The fundamental network infrastructure and IP Telephony design considerations for MeetingPlace remain the same as the IP Telephony design considerations for Cisco Unified CallManager, and this chapter assumes that you have basic knowledge and experience with Cisco Unified Communications.

This chapter focuses mainly on the integration and design issues for combining both Cisco Unified MeetingPlace and IP Telephony in one converged network. The time-division multiplexing (TDM) connection from MeetingPlace to the public switched telephone network (PSTN) is not a consideration for this setup because the PSTN access is typically provided through Cisco Unified CallManager by means of a voice gateway.

This chapter does not cover other MeetingPlace components that do not affect the integration, such as the MeetingPlace components for Outlook, Lotus Notes, Email (Simple Mail Transfer Protocol, or SMTP), Directory Services, and Instant Messaging. Also, specific product-level information about MeetingPlace (such as feature descriptions and configuration options) is beyond the scope of this document. For more information about MeetingPlace, refer to the product documentation available at http://www.cisco.com.

MeetingPlace Server Recommendations

Table 15-1 lists the recommended Cisco Media Convergence Server (MCS) models to use in various deployment scenarios.

 

Table 15-1 MCS Deployment Recommendations 

MeetingPlace Components on the Server
Up to 480 Voice User Licenses
More than 480 Voice User Licenses

All bundles (including H.323/SIP IP Gateway, Web User Interface, Email Gateway)

Outlook or Notes

Directory Services

Video Gateway

MCS 7835

MCS 7845

Web Conferencing

Add one MCS 7845 for each 200 web user licenses

Instant Messaging (IM) Gateway

Add one MCS 7835


The following guidelines also apply to MCS deployments:

Deployments with up to 50 Web Conferencing user licenses can run web conferencing on the same MCS with the bundled software and other options.

Deployments with more than 50 Web Conferencing user licenses should move Outlook or Notes and the Web Conferencing Schedule, Find, and Attend functions to an MCS 7845 dedicated to Web Conferencing.

Deployments with more than 100 Web Conferencing user licenses should not use Microsoft Desktop Engine (MSDE) 2000 because it is limited to eight concurrent connections for scheduling and web conferences. SQL 2000 is required and must be provided by the customer. Large installations (more than 500 user licenses) should run SQL 2000 on a dedicated server.

Deployments with more than 200 voice user licenses (typically more than 10,000 records) require a dedicated MCS 7835 for Directory Integration.

Deployment Models

This section covers the major deployment models used to deploy MeetingPlace with Cisco Unified CallManager. For the purpose of this section, assume that the MeetingPlace system is placed at a major site that includes a Cisco Unified CallManager cluster.

Figure 15-1 shows Cisco Unified MeetingPlace 5.3 integrated with a comprehensive Cisco IP Communications topology. The Cisco Unified CallManager cluster (running Cisco Unified CallManager 4.0 or above) includes a video deployment (both SCCP and H.323 video endpoints) with the video conferencing capability provided by a Multipoint Control Unit (MCU). The H.323-to-H.320 video gateway handles video calls to the PSTN. Through the MeetingPlace H.323/SIP IP Gateway, Cisco Unified CallManager fully utilizes the rich-media features provided by MeetingPlace with its audio, video, and web conferencing solution, which external users can also access from the Internet.

Figure 15-1 Example Topology for Integrating MeetingPlace with IP Telephony

The following sections describe the major deployment models for integrating MeetingPlace with Cisco Unified CallManager.

Single Site

The single-site model for IP Telephony and MeetingPlace consists of a call processing agent located at a single site and a LAN or metropolitan area network (MAN) to carry voice, video, and collaboration traffic throughout the site. Conference participants beyond the LAN or MAN use the public switched telephone network (PSTN). If an IP WAN is incorporated into the single-site model, it is for data and web collaboration traffic only; no telephony services are provided over the WAN.

For a more detailed explanation of the IP Telephony single-site deployment model, see the chapter on IP Telephony Deployment Models, page 2-1.

MeetingPlace should be deployed within the data center to provide maximum resilience for the conferencing and collaboration system. Cisco recommends using Media Gateway Control Protocol (MGCP) voice gateways in a single-site model; however, an H.323/H.320 Cisco Unified Videoconferencing Gateway is required to support external video participants. The recommended method for providing external access is to use either a toll-free service or dedicated direct inward dial (DID) numbers for the MeetingPlace pilot numbers via Cisco Unified CallManager gateways, but you also have the option to use dedicated PSTN T1 or E1 lines directly connected to MeetingPlace. Typical systems include a single toll-free number, a single DID or central office (CO) number, and an internal dialing number provided for users to dial into an audio conference session. Unique DID numbers can be used for dedicated crisis management or unique meeting IDs that are always available (24/7/365) for other applications.

Multisite WAN with Centralized Call Processing

The multisite WAN model with centralized call processing consists of a single call processing agent that provides services for many sites and uses the IP WAN to transport voice and /or video traffic between the sites. The IP WAN also carries call control signaling between the central site and the remote sites.

For a more detailed explanation of the IP Telephony multisite deployment model with centralized call processing, see the chapter on IP Telephony Deployment Models, page 2-1.

MeetingPlace should be deployed at the main site to provide centralized conferencing and collaboration services for all sites. When considering the number of conference participants from each site, plan for the required WAN bandwidth and/or the number of PSTN calls to the central-site MeetingPlace. If there is insufficient bandwidth on the WAN, users will have to redial via the PSTN using either a toll-free service or a dedicated CO or DID number. If remote sites enter Survivable Remote Site Telephony (SRST) mode or switch to Cisco Unified CallManager Express for connectivity loss to the central Cisco Unified CallManager cluster, then the only access to MeetingPlace conferencing is via the PSTN, and video support is not automatically included. The web collaboration traffic, however, could still use a backup data path if one is available.

Multisite WAN with Distributed Call Processing

The multisite WAN model with distributed call processing consists of multiple independent sites, each with its own call processing agent connected to an IP WAN that carries voice and video traffic between the distributed sites.

For a more detailed explanation of the IP Telephony multisite deployment model with distributed call processing, see the chapter on IP Telephony Deployment Models, page 2-1.

MeetingPlace may be deployed at one, some, or all of the distributed call processing sites. Access to the various MeetingPlace systems in different Cisco Unified CallManager clusters is by means of intercluster trunks and/or the PSTN. Web collaboration is always via the IP WAN. For maximum flexibility, implement a uniform dial plan to ensure that MeetingPlace is accessible by any user on any Cisco Unified CallManager cluster using a MeetingPlace connected to the same or any other Cisco Unified CallManager cluster. MeetingPlace also provides a feature called multiserver meetings, which are cascaded conferences that can conserve bandwidth or PSTN calls when multiple users at multiple sites are in the same conference. (For more information on multiserver meetings, see the chapter on Conferencing.)

Clustering Over the IP WAN

This model deploys a single Cisco Unified CallManager cluster across multiple sites that are connected by an IP WAN with QoS features enabled.

For a more detailed explanation of clustering over the WAN, see the chapter on IP Telephony Deployment Models, page 2-1.

With clustering over the WAN, you can deploy multiple MeetingPlace Audio Servers at different Cisco Unified CallManager sites. (See the information on Dual Conference Servers in the section on Disaster Recovery.) The user profile information can be synchronized between the servers by using the MeetingPlace Directory Service Integration option.

On Cisco Unified CallManager, you can configure route groups and route lists so that, if one of the MeetingPlace Audio Servers fails, the calls will still be routed to another MeetingPlace system. The meeting information does not transfer between servers, so the administrator must manually upload the meeting information from the failed system onto another system for use.

If there is a WAN outage, each server is still able to operate and serve its local users. For remote users to join the meeting on the same audio server, you can configure route groups and route lists on Cisco Unified CallManager to reroute the calls.

With multiple audio servers, Cisco highly recommends turning off the Vanity ID feature (which allows users to choose and set their own meeting IDs) in order to support failover mode and reduce the probability that meeting IDs would conflict during uploads.

MeetingPlace Components

This section describes the following major components that affect the design of a MeetingPlace system:

MeetingPlace Audio Server

MeetingPlace H.323/SIP IP Gateway

MeetingPlace Audio Server

The MeetingPlace Audio Server (8112 or 8016) provides digital signal processor (DSP) resources for audio conferencing capability. Additionally, the MeetingPlace server acts as a scheduling module for web, audio, and video conferences. Based on the reservation, the MeetingPlace server will control how many users can join the conference as well as the duration of the meeting.

MeetingPlace H.323/SIP IP Gateway

The MeetingPlace Audio Server was originally designed for TDM connectivity, via T1/E1 trunks, either to a service provider or behind a PBX. To incorporate it into an existing Cisco Unified Communications network, the MeetingPlace H.323/SIP IP Gateway is required to link the two networks. Although it is called a gateway, it is not a hardware gateway but a software application that resides on an MCS server and is used to communicate between the MeetingPlace Audio Server and Cisco Unified CallManager. (See Figure 15-2.)

Figure 15-2 MeetingPlace H.323/SIP IP Gateway Used to Interface

The MeetingPlace H.323/SIP IP Gateway supports H.323 and SIP simultaneously. For details on the protocols supported by the MeetingPlace H.323/SIP IP Gateway, refer to the section on Interoperability Protocols.

MeetingPlace audio servers can support mixed TDM and IP connections. The capacities for a mixed environment depend on the combination of both TDM ports and IP cards (user licenses) in the system.

Although the MeetingPlace H.323/SIP IP Gateway can coexist on the same Cisco Media Convergence Server (MCS) with other MeetingPlace applications (such as MeetingPlace Web, SMTP Email, Video Integration, and so forth), in a pure IP setup Cisco recommends that you install the MeetingPlace H.323/SIP IP Gateway independently on a single MCS so that audio communications will not be affected if any problems occur with the web or video portions. However, for small deployments the MeetingPlace H.323/SIP IP Gateway can coexist with the MeetingPlace Web Conferencing Service, and the performance and capacity of the web conference should not be impacted significantly because it does not use much of the MCS CPU resources.

A single MeetingPlace Audio Server can be connected to multiple MeetingPlace H.323/SIP IP Gateways. If one MeetingPlace H.323/SIP IP Gateway fails, calls in progress are dropped, and new calls are routed to the secondary MeetingPlace H.323/SIP IP Gateway. For outdialing from the MeetingPlace Audio Server, the server chooses the MeetingPlace H.323/SIP IP Gateway with the least activity. For more information, refer to the section on Redundancy and Load Balancing.

Each MeetingPlace H.323/SIP IP Gateway can support only one Cisco Unified CallManager without using a gatekeeper, and multiple Cisco Unified CallManagers with a gatekeeper. Each MeetingPlace Audio Server can connect to a maximum of 16 MeetingPlace H.323/SIP IP Gateways for the purposes of redundancy, load balancing, and support for multiple Cisco Unified CallManager clusters.

An Audio Server can support up to a maximum of 16 GWSIM MCS servers with MeetingPlace applications installed, so multiple IP gateways can be supported (until the combined MCS application server count = 16).


Note Do not use Network Address Translation (NAT) between the MeetingPlace Audio Server and the MeetingPlace H.323/SIP IP Gateway.


The MeetingPlace H.323/SIP IP Gateway can communicate with Cisco Unified CallManager in one or more of the following ways:

Cisco Unified CallManager communicates directly with the MeetingPlace H.323/SIP IP Gateway via SIP

To implement this method, configure the connection to the MeetingPlace H.323/SIP IP Gateway as a SIP Trunk in Cisco Unified CallManager.

Cisco Unified CallManager communicates directly with the MeetingPlace H.323/SIP IP Gateway via H323

To implement this method, configure the connection to the MeetingPlace H.323/SIP IP Gateway as an H.323 gateway in Cisco Unified CallManager.

Cisco Unified CallManager communicates with the MeetingPlace H.323/SIP IP Gateway through a gatekeeper

In this method, Cisco Unified CallManager and the MeetingPlace H.323/SIP IP Gateway register with a gatekeeper, and the gatekeeper handles the call routing.

Sizing a MeetingPlace Deployment

Sizing a Cisco Unified MeetingPlace deployment involves the following major considerations:

Voice user licenses, or audio ports

Web conferencing licenses

Video conferencing IP/VC MCU sizing

When sizing a MeetingPlace system, always start with the 8100 Audio Server, and use the most accurate estimate available for the average conferencing minutes per month. This estimate can be derived from current billing information obtained from the conferencing service provider(s). For example, if the billing information contains a yearly total conferencing minutes, then you can either divide the total by 12 or select a peak month to use as the estimate. User surveys and feedback can also be helpful in deriving the average monthly usage.

In addition, you should add some growth factor (typically 10% to 30%) for at least the first year and possibly subsequent years. If you are incorporating the Cisco Unified MeetingPlace Outlook Integration option (which enables end users to easily schedule, notify, and attend voice, web, or video meetings), then your growth factor might be larger (possibly 30% to 50%) based on projected usage.

Use the following general guidelines when sizing a MeetingPlace solution:

The actual conferencing usage from current service provider bills is the best measurement.

Always add a growth percentage (typically 10% to 30%) for at least the first year before applying the sizing formulas.

If you do not know the current conferencing usage (rare), then you can apply the following assumptions:

Statistically, every 20 telephony users need at least one audio conference port (license) for MeetingPlace audio service. (For example, 2500 users / 20 = 125 voice user licenses required.)

Each user averages 100 conferencing minutes per month. (For example, 5500 users * 100 = 550,000 minutes per month.)

You can also use these assumptions to compare to the billing data.

Sizing Voice Conferencing Usage

The general equation for calculating the number of required voice user licenses is:

Number of MeetingPlace voice user licenses =

(Average conferencing minutes per month + growth factor) / Baseline

Round any fractions up to the next whole number.

Table 15-2 lists the baseline values to use in this equation.

 

Table 15-2 Baseline Values for Calculating the Number of Required User Licenses 

Average Minutes per Month
Baseline (Minutes per User License)

50,000 to 300,000

2,000

300,000 to 700,000

2,500

700,000 to 1,000,000

3,000

1,000,000 to 2,000,000

3,500

Above 2,000,000

4,000


For example, if you estimate the average monthly usage of your system to be 528,000 conferencing minutes, the required number of user licenses would be:

Number of MeetingPlace voice user licenses = 528,000 * (1 + 20%) / 2500 = 254

Sizing Web Conferencing Usage

You can calculate the number of required web user licenses based on either a ratio of the total voice user licenses or service provider billing information about web conference usage. Typical deployments use 25% to 50% as many web conferencing licenses as voice conferencing licenses (25% is most common), but some enterprises deploy equal number of voice and web user licenses.

For example, a deployment with 240 voice user licenses would need 60 web user licenses to provide 25% coverage for web users. One MCS 7845 could handle the web services for this system, while also providing for growth up to 200 web user licenses.

Web conferencing directly affects the number of Cisco MCS 7800 Series servers that are required. An MCS 7835 co-located with other MeetingPlace integration modules can accommodate approximately 50 web sessions, while an MCS 7845 can accommodate up to approximately 200 web sessions (depending on the actual type of usage at a particular peak time). Therefore, sizing the web conferencing resources is critical to the overall design and placement of the solution in the enterprise data environment.

Web conferencing usage typically experiences faster growth rates than voice conferencing usage, and it depends on the amount of web collaboration used within the enterprise. For web conferencing, try to estimate growth for the next two to five years (typically 20% to 30% growth per year).

Video Integration and Sizing the MCU

MeetingPlace Video Integration is a system-wide software module, and no user licenses are required for video conferencing. The number of supported video users depends on the number of H.323 ports available on the MCU for MeetingPlace to control. The IP/VC 3511 MCU provides 15 ports (either H.323 or SCCP but not both), and the 3540 MCU provides 30, 60, or 100 ports (either H.323, SCCP, or a mixture of both). (See Table 15-3.)

MeetingPlace Video Integration allows users to schedule video conferences with only a single IP/VC MCU. MeetingPlace currently does not support multiple MCUs or cascaded video meetings. You may deploy other third-party MCUs to support other videoconferencing applications that do not integrate with the MeetingPlace Video Integration solution.

MeetingPlace Video can reside on only one MeetingPlace Web MCS in the system, which can be either an internal or external web server (but not both). Video meetings are enabled only on the web server where MeetingPlace Video is installed, and they are not supported on any other web server in the system. Voice and web conferences are still supported on all servers. The MeetingPlace Video Integration software can reside on the same MCS as the Web Conferencing module, along with other MeetingPlace integration modules (such as Outlook, Notes, Directory Services, and so forth), depending on the expected number of web user licenses and the total number of web servers.

Because it can reside on only one web server, the MeetingPlace Video solution does not currently provide redundancy.

You can use the same Cisco Unified Videoconferencing 3540 or 3511 MCU for MeetingPlace video integration with other SCCP video telephony endpoints, and a single IP/VC 3540 MCU can support both ad-hoc video telephony calls (SCCP controlled) and MeetingPlace H.323 conferences. In such a deployment, you allocate some of the ports on the MCU to support SCCP for video telephony and the rest of the ports to support H.323 for MeetingPlace. This dual mode is not supported on the IP/VC 3511 MCU. To support both modes with the IP/VC 3511 MCU, you would have to deploy one 3511 MCU for video telephony and a separate 3511 MCU for MeetingPlace Video Integration. (See Table 15-3.)

 

Table 15-3 Possible MCU Port Allocations for SCCP and H.323 

IP/VC-3511-MCU
(15 ports) 1
IP/VC-3540-MC03A
(30 ports)
IP/VC-3540-MC06A
(60 ports)
IP/VC-3540-MC10A
(100 ports)
H.323
SCCP
H.323
SCCP
H.323
SCCP
H.323
SCCP

100%

0%

100%

0%

100%

0%

100%

0%

0%

100%

50%

50%

75%

25%

70%

30%

   

0%

100%

50%

50%

50%

50%

       

25%

75%

30%

70%

       

0%

100%

0%

100%

1 This MCU supports 16 ports for SCCP at 128 or 384 kbps.


MeetingPlace Network Infrastructure

This section explains the requirements of the network infrastructure needed to build a MeetingPlace conferencing solution in an existing Cisco Unified Communications enterprise environment. The requirements in this section must be used in conjunction with the network infrastructure requirements described in the chapter on Network Infrastructure, page 3-1.

Figure 15-3 illustrates a typical network configuration for a MeetingPlace conferencing solution.

Figure 15-3 Typical MeetingPlace Conferencing Solution in an Enterprise IP Telephony Network

The following sections list the main requirements for the network that connects the MeetingPlace Audio Server and its components to the IP Telephony infrastructure:

Connectivity Between MeetingPlace and IP Telephony Components

Quality of Service (QoS)

Connectivity Between MeetingPlace and IP Telephony Components

Adhere to the following practices when connecting MeetingPlace to the IP Telephony network:

Manually configure switch ports and MeetingPlace components to be 100 MB full duplex or 1000 MB full duplex.

Physically co-locate the MeetingPlace components.

Build redundant network connections between the MeetingPlace infrastructure and other IP Telephony products to ensure survival during WAN failure conditions.

Quality of Service (QoS)

This section discusses the following QoS mechanisms as they relate to MeetingPlace:

Traffic Classification

Call Admission Control and Bandwidth Provisioning

Jitter

Traffic Classification

Traffic classification is a keystone for voice quality in congested networks. Voice packets must be classified or differentiated from data packets and must be handled with high priority. Some of the voice traffic is marked at its source, but other traffic needs to be classified as close as possible to the entry points of the network.

The MeetingPlace Audio Server has the following traffic classification characteristics:

It does not support Layer 2 Class of Service (CoS) marking.

It does not support Layer 3 voice signaling marking.

It supports marking Real-Time Transport Protocol (RTP) packets at the source, if enabled.

The MeetingPlace Audio Server allows one of the following Layer 3 settings to be applied to RTP packets:

IP Precedence

Type of Service (ToS)

Differentiated Services Code Point (DSCP, or DiffServ)


Note The IP Precedence setting overwrites the DSCP value. Therefore, if you want to use the DSCP setting, you must manually configure the IP Precedence and ToS settings as unused. If the DSCP field is set to the desired value and IP Precedence and ToS are set to 0, RTP traffic will not be marked from the MeetingPlace Audio Server.


There is no mechanism within the MeetingPlace Audio Server to mark the voice signaling traffic at its source. The traffic between all MeetingPlace components must be marked as soon as it enters the network. The traffic between MeetingPlace components is usually from the Gateway System Integrity Manager (GWSIM) application, which is loaded on an MCS 8100 Series server and is always present with the MeetingPlace integration software modules (Web, Outlook, Notes, Video, and so forth). When this traffic traverses the WAN, it must be given the same priority as the other voice signaling traffic.

Cisco recommends that you use packet markings that are consistent with other devices. Refer to the chapter on Network Infrastructure, page 3-1, for detailed information.

Call Admission Control and Bandwidth Provisioning

The MeetingPlace Audio Server and other MeetingPlace components do not have any call admission control mechanisms of their own. The MeetingPlace Audio Server can accept IP calls or conference requests until all ports or resources have been exhausted. This behavior can result in degraded voice quality for all audio streams across a given link if sufficient bandwidth is not available.

Call admission control should be implemented in deployments involving bandwidth-restricted links such as WAN links. Refer to the chapter on Network Infrastructure, page 3-1, for detailed information regarding call admission control.

Rate and Codec Selection for Audio and Video

Audio

In an audio- only conference, the audio codec selected for a voice call depends on the regions configuration in Cisco Unified CallManager. The codec specified in the regions configuration in Cisco Unified CallManager must match the audio codec for which the MeetingPlace Audio Server is configured. Most commonly used codecs are G.711 A-law or mu-law and G.729. MeetingPlace supports both types of codecs, but only G.711 is enabled by default. If G.729 support is also desired, you should enable it during Audio Server initialization.

Video

Cisco Unified CallManager Release 5.0 supports H.261, H,263, and H.264 codecs. For a video conference, the video rate can be configured in the following places:

MCU service view

Cisco Unified CallManager region

MeetingPlace user profile

The maximum video rate in a MeetingPlace user profile is set to 384 kbps. The video rate specified in the Cisco Unified CallManager region configuration will take effect only if the bandwidth requested or the video rate configured in the MCU or MeetingPlace user profile exceeds the region configuration.

For example, consider the following video bandwidth settings:

Cisco Unified CallManager regions: 512 kbps

MCU service view: 384 kbps

MeetingPlace user profile: 256 kbps

In this case, if a video user dials into the MCU to join the conference, the video rate selected will be 384 kbps which corresponds to the setting on the MCU service view. The video bandwidth setting in the MeetingPlace user profile will not take effect at all because MeetingPlace Video is not involved in the call flow.

In the case of outdialing to a user, the MeetingPlace Video application will pass the video bandwidth value (256 kbps) in the MeetingPlace user profile for this user to the MCU. The MCU compares this value with its own service view value (384 kbps) and selects the lowest bandwidth value (in this case, 256 kbps) for the video conference and extends a call request to the Cisco Unified CallManager video telephony endpoint or the H.323 video endpoint. The video bandwidth selected for the call depends on the video endpoint. In the case of a Skinny Client Control Protocol (SCCP) video endpoint, the bandwidth is selected according to the video rate settings on the MCU service view and the Cisco Unified CallManager region. (In this case 384 kbps is selected.) However, in the case of an H.323 video endpoint, the bandwidth selection is based on all three video rate settings. (In this case, 256 kbps is selected.)

Figure 15-4 shows the algorithm for selecting the video bandwidth.

Figure 15-4 Algorithm for Selecting the Video Bandwidth

The Cisco Unified CallManager region bandwidth setting (512 kbps in our example) takes effect only when the MCU or MeetingPlace Video application requests more bandwidth than the region setting (in this case, more than 512 kbps) and the endpoint dials into the video meeting. If the endpoint user employs the outdial feature to connect, then the MeetingPlace profile bandwidth setting is used.

MeetingPlace Web Session Network Utilization

MeetingPlace Web sessions generate the following amounts of network traffic:

A first-time participant downloads approximately 1 MB of data and might be asked to accept a security notice and close the browser to reset.

Each participant downloads between 0.5 to 0.75 MB of data at the start of the meeting.

The average baseline utilization is about 600 Bytes/second per participant.

In application mode, the amount of data sent when the presenter changes the view depends on the amount of color and graphics being displayed. The following general guidelines apply in such cases:

Low-complexity presentations send about 10 kB of data per participant.

Medium-complexity presentations send about 50 kB of data per participant.

High-complexity presentations send about 430 kB of data per participant.

Most presentations are in the low to medium range.

Cisco Unified MeetingPlace Web Conferencing will transmit 24-bit color if the bandwidth is available and will automatically reduce it to 8-bit color for slower connections. This determination is made automatically by attempting to transmit at the higher rate and reducing that rate if data is significantly delayed or lost.

Jitter

Variations in the packet delay, known as jitter, can seriously affect the voice quality. A jitter buffer smooths out variations in network delay. The MeetingPlace Audio Server contains the following parameters for setting the jitter buffer:

Jitter Buffer Minimum Size — The jitter buffer automatically adapts to changing jitter values, but this parameter defines a minimum value for the jitter buffer.

Jitter Buffer Optimization — This value controls how quickly the jitter buffer can react to network jitter.

In most cases, you should not change the default values of these parameters. These values may be adjusted if voice quality issues are encountered.

Domain Name System (DNS)

The MeetingPlace Audio Server does not support DNS internally. Cisco recommends assigning static IP addresses to all MeetingPlace Audio Server components and MCS components in your implementation. The Audio Server attempts to use IP addresses when accessing other servers. MeetingPlace components (such as MeetingTime System Administration client) may use host names to contact the MeetingPlace Audio Server. MeetingPlace components may also use host names to communicate with other Cisco Unified Communications products.

Network Time Protocol (NTP)

The MeetingPlace Audio Server uses NTP to synchronize its clock with the network time server. The MeetingPlace Audio Server may be configured with up to three NTP servers. MeetingPlace windows-based components can use the w32time.exe service to act as the NTP client or server. Cisco highly recommends that you use only one NTP server across the entire enterprise network so that the clocks are synchronized on all components.

Demilitarized Zone (DMZ) Requirements

MeetingPlace components placed in a DMZ allow external users access to meetings. For external users to access web conferences, a separate MeetingPlace Web server can be placed in the DMZ. Internal users can still have confidential meetings using an internal MeetingPlace Web server.

In a DMZ deployment, internal users have full web access and MeetingPlace capabilities (schedule, find, attend, access attachments, and record), while external users are allowed only to attend meetings. When the meeting starts, the internal users are redirected to the external web server.

Figure 15-5 illustrates this type of deployment.

Figure 15-5 MeetingPlace Web Conferencing with a DMZ for External Users

If MeetingPlace components in a DMZ are separated from internal MeetingPlace components by security policies such as a firewall, it will be necessary to open certain Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) ports through the firewall for integration to work properly.

No ports need to be opened from the DMZ to the internal network, but the following ports from the internal network to the DMZ are needed:

TCP 80 or 443 for web conferencing

TCP 5003 bidirectionally for communication between the Audio Server and Web server

TCP 5005 for attachment and recording

TCP 1503, optionally, for Microsoft NetMeeting

TCP 1627, optionally, for higher performance with web conferencing

The following ports are open between the DMZ and the Internet:

TCP 80 or 443

TCP 1503, optionally, for Microsoft NetMeeting

TCP 1627, optionally, for higher performance with web conferencing

The DNS service must be split (one internal DNS server and one external DNS server) for the following reasons:

Ease of use — With a single click, internal and external users can attend a meeting.

Security — External users cannot find out information about the internal network.

Increased performance — This deployment removes the load of internal requests from the external DNS server.

The internal DNS server resolves queries from inside the corporate network only, while the external DNS server holds the publicly addressable entities for the corporation's domain. The DNS servers must map both URLs and IP addresses.


Note NAT is not supported between the MeetingPlace Audio Server and other MeetingPlace components due to the IP address being embedded in the data.


Table 15-4 lists all the TCP and UDP ports used by the MeetingPlace Audio Server and its components.

 

Table 15-4 TCP and UDP Ports Used by the MeetingPlace Audio Server 

TCP or UDP Port
Protocols and/or Applications

TCP 21

FTP

TCP 23

Telnet

TCP 25

Between the MeetingPlace Email Gateway and the Simple Mail Transfer Protocol (SMTP) server

TCP 161

Simple Network Management Protocol (SNMP)

TCP 389

Between the MeetingPlace Directory Services Gateway and the enterprise corporate directory

TCP 443

Secure Socket Layer (SSL)

TCP 1443

MeetingPlace database

TCP 1627

Direct inbound access to host a meeting with WebShare

TCP 3336

Cisco Unified MeetingPlace Video integration with the IP/VC MCU

TCP 5001

Cisco MeetingTime (Opened from client to Audio Server)

TCP 5003

Cisco Unified MeetingPlace Gateway System Integrity Manager (SIM)

TCP 5005

File transfer between an Audio Server and Cisco Unified MeetingPlace Web or a gateway. (Opened from client to server)

UDP 53

DNS

UDP 123

Network Time Protocol (NTP)


Interoperability Protocols

This section describes the communication protocols used by the MeetingPlace Audio Server and its components to achieve interoperability with other Cisco products. Interoperability with the Cisco Unified MeetingPlace conferencing solution involves integration with up to two networks:

IP Network

The MeetingPlace components (MeetingPlace H.323/SIP IP Gateway, MeetingPlace Web server, and MeetingPlace Video application) integrate directly with other products, and the MeetingPlace components then communicate with the MeetingPlace Audio Server.

Public Switched Telephony Network (PSTN)

The MeetingPlace Audio Server integrates directly with other products through a TDM interface on the Audio Server.

Internet Protocol (IP) Network

This section describes the protocols used to integrate MeetingPlace components with an IP network. The protocols are of the following types:

Protocols Supported by the MeetingPlace Audio Server

Protocols Supported by Other MeetingPlace Components

Protocols Supported by the MeetingPlace Audio Server

The MeetingPlace Audio Server uses the following protocols or applications to integrate with an IP Communications system:

GWSIM

The Gateway System Integrity Manager (GWSIM) is a proprietary application that serves as an interface between the MeetingPlace Audio Server and its components. The Cisco Unified MeetingPlace GWSIM is based on a client/server architecture, which provides a means of exchanging information with the remote MeetingPlace components. The MeetingPlace Audio Server manages all the meeting information using a System Integrity Manager (SIM). The SIM uses the IP network to exchange all signaling and conferencing information with the GWSIM agent installed on the MeetingPlace components. This communication uses a proprietary Cisco protocol using TCP ports 5001 and 5003, and it is commonly referred to as GWSIM communication.

Real-Time Transport Protocol (RTP)

The MeetingPlace Audio Server uses User Datagram Protocol (UDP) for transmission of real-time audio directly to the endpoints (such as IP phones, IP/VC MCU, and so forth). The Audio Server, by default, is enabled to use only the G.711 codec for RTP. However, you can change this default to the desired codec by using the command line interface.

The MeetingPlace Audio Server requires use of the MeetingPlace H.323/SIP IP Gateway in order to support H.323 and SIP.

Protocols Supported by Other MeetingPlace Components

This section describes the protocols used by MeetingPlace components, other than the MeetingPlace Audio Server, to integrate with IP Communications networks.

H.323

H.323 networks can be integrated with MeetingPlace for a feature-rich conferencing solution. As mentioned earlier, because the MeetingPlace Audio Server does not natively support H.323, the MeetingPlace H.323/SIP IP Gateway is required to provide H.323 protocol support. The Cisco Unified MeetingPlace H.323/SIP IP Gateway supports H.323 and communicates directly with the other H.323 elements in the network to enable conferencing with the Audio Server.

The MeetingPlace H.323/SIP IP Gateway integrates directly with Cisco Unified CallManager or Cisco Unified CallManager Express using H.323. The number of simultaneous H.323 calls that a MeetingPlace H.323/SIP IP Gateway can handle depends on the maximum IP port limits of the Audio Server. Optionally, a gatekeeper can also be used for address resolution and bandwidth control when integrating with Cisco Unified CallManager or CallManager Express.

The MeetingPlace H.323/SIP IP Gateway uses the following TCP and UDP ports for the indicated purposes:

H.323

Call setup for H.225 uses static TCP port 1720.

Call setup for H.245 uses a random TCP port in the address range 1024 to 65535.

RTP voice streams use random UDP ports in the range 5000 to 65535.

Gatekeepers

Require static UDP port 1719 for Registration Admission Status (RAS).


Note The MeetingPlace H.323/SIP IP Gateway does not support H.323 Fast Start. However, even if it receives an inbound H.323 fast-start call, the call is completed using normal H.323 signaling procedures.


Figure 15-6 shows the interoperability of MeetingPlace with Cisco Unified CallManager and CallManager Express.

Figure 15-6 Integration with Cisco Unified CallManager and CallManager Express Using H.323

SIP

The MeetingPlace H.323/SIP IP Gateway also provides the ability to interconnect Session Initiation Protocol (SIP) networks to the Cisco Unified MeetingPlace Audio Server. The MeetingPlace H.323/SIP IP Gateway integrates directly with a SIP proxy server or SIP gateway and converts the SIP messages to GWSIM messages, thus allowing SIP endpoints to use the MeetingPlace Audio Server for conferencing.

Cisco Unified CallManager Release 4.2 can be integrated directly with the MeetingPlace H.323/SIP IP Gateway using a SIP trunk on Cisco Unified CallManager. Using a SIP trunk between Cisco Unified CallManager and the MeetingPlace H.323/SIP IP Gateway has three significant requirements:

The use of media termination points (MTPs) is required.

Due to the requirement of statically enabled MTPs, only the G.711 codec is supported.

UDP Transport must be used, and TCP is not supported. (Outgoing Transport Type must be set to UDP in the trunk configuration in Cisco Unified CallManager.)

The MeetingPlace H.323/SIP IP Gateway uses the following UDP ports for SIP:

Call setup uses static UDP port 5060.

RTP voice streams use random UDP ports in the range 5000 to 65535.

Figure 15-7 shows the interoperability of MeetingPlace with Cisco Unified CallManager.

Figure 15-7 SIP Integration


Note The MeetingPlace H.323/SIP IP Gateway can support H.323 and SIP connections simultaneously.


XML Application

The MeetingPlace Audio Server can handle only audio communications. To support video conferencing, it requires an external MeetingPlace Video application that integrates directly with the IP/VC Multipoint Control Unit (MCU). Cisco Unified MeetingPlace Video Integration communicates with the Cisco Unified Videoconferencing MCU using XML messaging through TCP port 3336.

Figure 15-8 shows the interoperability of MeetingPlace with the IP/VC MCU:

Figure 15-8 Video Integration

Public Switched Telephone Network (PSTN)

The Cisco Unified MeetingPlace Audio Server connects to the PSTN either directly or through a PBX using digital (T1 or E1) or analog trunks. The MeetingPlace Audio Server is also reachable by PSTN via Cisco Unified CallManager with a voice gateway connected.

Digital Trunks

Cisco Unified MeetingPlace supports T1 and E1 digital trunks, as described in the following sections.

T1

Cisco Unified MeetingPlace supports the following protocols for T1 digital trunks:

T1-CAS (loop start, wink start, or ground start)

T1-PRI (AT&T PRI, Nortel PRI, or Bell PRI)

T1 Smart Blades support T1 directly connected from either the PSTN or PBXs. The multi-access blades (MA-4 or MA-16) support T1-PRI or E1-PRI digital connections to a PBX or to the PSTN. The framing for the digital lines can be either Extended Superframe (ESF) or D4 framing. The digital lines can use either Binary 8-Zero Substitution (B8ZS) or Alternate Mark Inversion (AMI) coding.


Note Cisco recommends using ESF framing and B8ZS coding.


Digital connections usually provide either E&M or ground start (GST) signaling. On T1 circuits configured for E&M signaling, MeetingPlace can receive only dialed number information - either Direct Inward Dial (DID/DDI) or Dialed Number Identification Service (DNIS). MeetingPlace can use dialed number information to connect the caller directly to a meeting or to determine the MeetingPlace services to which the caller has access.

Cisco Unified MeetingPlace also supports fractional T1 services.

E1

Cisco Unified MeetingPlace supports the following protocols for E1 digital trunks:

Euro-ISDN (ETSI 300-102)

QSIG (ECMA version) — Channels are numbered 1 to 30

QSIG (ETSI version) — Channels are numbered 1 to 15 and 17 to 31


Note The Cisco Unified MeetingPlace system supports only E1-PRI protocols; it does not support E1-CAS protocols.


Each E1 protocol allows software configuration of signaling options. The signaling options must match with the options configured on the PBX or PSTN switch.


Note Cisco does not support mixing protocols on the MeetingPlace Audio Server, except in combination with IP ports. For example, a Cisco Unified MeetingPlace Audio Server cannot have both T1 and E1 ports configured on the same system, but it can have T1 (either PRI or CAS) and IP ports, or E1 and IP ports. Also, a Cisco Unified MeetingPlace Audio Server cannot have both T1-CAS and T1-PRI ports configured on the same system. (See Table 15-5 through Table 15-7.)


 

Table 15-5 Port Capacities for a Mixed System with T1 and IP Ports 

Number of IP ports

0

96

192

240

480

576

600

960

Maximum number of T1 DS0s

1152

960

768

576

576

394

192

0

Total ports

1152

1056

960

816

1056

960

792

960


 

Table 15-6 Port Capacities for a Mixed System with T1-PRI and IP Ports 

Number of IP ports

0

120

400

480

960

Maximum number of PRI ports

736

368

368

368

0

Total ports

736

488

768

848

960


 

Table 15-7 Port Capacities for a Mixed System with E1 and IP Ports 

Number of IP ports

0

120

384

480

960

Maximum number of E1 ports

960

480

480

480

0

Total ports

960

600

864

960

960


For more information, refer to the Getting Started Guide for Cisco Unified MeetingPlace Audio Server and the Configuration Guide for Cisco Unified MeetingPlace Audio Server, both available at

http://www.cisco.com/en/US/products/sw/ps5664/ps5669/tsd_products_support_series_home.html

Conferencing

Cisco Unified MeetingPlace supports the following types of conferencing:

Audio Conferencing

Web Conferencing

Video Conferencing

Audio Conferencing

There are two platforms for the MeetingPlace Audio Server:

Cisco Unified MeetingPlace 8106 Audio Server

Maximum of 480 IP ports in increments of 24 or 30 user licenses

Maximum of 536 T1-CAS ports in increments of 24 user licenses

Maximum of 480 T1-PRI or E1 ports in increments of 24 user licenses

Cisco Unified MeetingPlace 8112 — Supports up to 960 IP ports

Maximum of 960 IP ports in increments of 24 or 30 user licenses

Maximum of 1152 T1-CAS ports in increments of 24 user licenses

Maximum of 960 T1-PRI or E1 ports in increments of 24 user licenses

The maximum number of simultaneous meetings equals the number of ports divided by two. The servers support up to 550 sessions (participants) per meeting. However, you can cascade up to three Audio Servers to achieve a total of 1650 audio sessions in a single meeting.

Call Flow

The media request (signaling) is handled by the MeetingPlace H.323/SIP IP Gateway on behalf of the MeetingPlace Audio Server, while the media stream flows directly between the MeetingPlace Audio Server and IP phones. Figure 15-9 illustrates the call flow for inbound calls, and Figure 15-10 illustrates the call flow for outbound calls.

Figure 15-9 Audio Dial-in Call Flow for MeetingPlace Integrated with Cisco Unified CallManager

Figure 15-10 Audio Outdial Call Flow from Web Interface

Meeting Type

MeetingPlace supports two main types of audio meetings:

Standard (scheduled) meeting

While scheduling this type of meeting, you can specify the meeting parameters, such as meeting ID, number of participants, and so forth. When participants join, they are connected directly to the main meeting. Immediate meetings are basically scheduled meetings in terms of the resource reservation, with the only difference being the start time (starting immediately rather than in the future).

Reservationless meeting

Any profile user can start a reservationless meeting from the phone if that feature is enabled. The user must sign in with a profile ID and password, which starts the meeting. The database also stores information about who started the meeting.

Reservationless mode is both a system-wide parameter and a user group parameter. It can be turned on for the whole system and off for a particular set of end users, but not the reverse. This parameter will change the prompts that play when participants join the meetings.

Both types of meetings can reside on the same MeetingPlace Audio Server, and they share the same pool of conference ports. Enabling the reservationless mode does not affect the capability to schedule the standard type of meetings simultaneously. However, reservationless meetings automatically set the user's profile number as the meeting ID. Therefore, if the reservationless mode is enabled, user profile numbers become reserved and cannot be assigned manually as meeting IDs for standard scheduled meetings.

Port Management

The MeetingPlace Audio Server provides the following types of ports:

Access ports

These ports are reserved for scheduling, attending, and listening to recorded meetings.

Conference ports

These ports are the ones in use or reserved for meetings. Conference ports also include the following types of special-usage ports:

Contingency ports are those conference ports reserved to handle call transfers. The system keeps them in reserve, making it possible for meeting participants to reach a contact person or attendant for assistance during a meeting and for the system manager to dial into meetings.

Floating ports are configured to handle unexpected meeting attendance. They can float between meetings, taking up the slack when an extra person attends a meeting that is already full.

Overbook ports

These ports do not exist physically. They are software ports configured to allow users to schedule more ports than are actually available, based on the assumption that there are usually some reserved but unused ports in some scheduled conferences. Because these ports do not exist physically, there is no limit to the number that can be configured.

Scheduling

The audio conference can be scheduled through any of the following interfaces:

MeetingPlace Web User Interface (UI)

Email Calendar Integration (Outlook or Lotus Notes)

MeetingTime client

Cisco Unified IP Phone XML Service

Audio Conference Cascading

Conference cascading is also known as a multiserver meeting. This feature provides a virtual link between different MeetingPlace systems so that users on each server can communicate with each other as if they were in the same meeting. When users schedule multiserver meetings, they use the web schedule on the primary server to select the secondary servers required for the meeting. At the start of the meeting, the primary server places a call to the secondary servers. The secondary servers then add the primary server to the meeting, just as they would with any participant who dialed into their system.

You can cascade up to three Audio Servers for a single meeting.

Cisco recommends configuring Network Time Protocol (NTP) servers on all MeetingPlace Audio Servers to synchronize time across all the servers.

For more information on multiserver meetings, refer to the Administration Guide for Cisco Unified MeetingPlace Audio Server, available at

http://www.cisco.com/en/US/products/sw/ps5664/ps5669/prod_maintenance_guides_list.html

Dialing into an Audio-Only Conference Using Video Endpoints

Video endpoints can join audio-only conferences by dialing into the MeetingPlace Audio Server directly. MeetingPlace supports both out-of-band and in-band DTMF digits from the endpoints. When using the outdial feature from the Web server, a user must enter the video endpoint extension in the audio endpoint phone number box.


Tip For Polycom H.323 devices, users must press the # key first, then a small telephone keypad appears on the screen. Polycom devices send in-band DTMF digits, which work only when using the G.711 codec.


Web Conferencing

Web conferencing involves the following MeetingPlace components:

MeetingPlace Web Server

SQL Database

MeetingPlace Web Server

The MeetingPlace Web application provides the following primary functions:

MeetingPlace Web User Interface

This feature provides scheduling, meeting room, meeting controls, reference center, and account management.

MeetingPlace Web Conferencing

This feature provides collaboration, whiteboard, application sharing, file uploads, and more.

Converting audio file

If MeetingPlace Web is installed with the audio service option, it first converts MeetingPlace voice (.mpv) files to .wav format, then you can choose to convert them to one of the other supported audio formats, such as Windows Media (.wma), RealAudio (.ra or .rm), and MP3. These files can be downloaded and made available to other applications such as a custom website or a CD.

Synchronized audio-web recording

The .wav file is used by MeetingPlace Web to create a synchronized audio/web recording if the optional voice and web recording is enabled on the system.

MeetingPlace Web requires a Media Convergence Server (MCS) with the IIS service running, and it uses a Microsoft SQL database that is automatically synchronized with the MeetingPlace 8100 Audio Server master database.

The Cisco MCS 7835 server supports up to 50 simultaneous user sessions and the MCS 7845 supports up to 200 simultaneous user sessions, but there is a limit of 150 user sessions per meeting. In addition, there is a limit of 100 simultaneous web conferences for application sharing or 150 for presentation mode on a single Web server. (Presentation mode involves an uploaded presentation that is converted to JPEG format and downloaded individually to the local browser cache as each participant joins the web conference.)

Deployments with more than 100 Web Conferencing user licenses should not use Microsoft Desktop Engine (MSDE) 2000 because it is limited to eight concurrent connections for scheduling and web conferences. SQL 2000 is required and must be provided by the customer. Large installations (more than 500 user licenses) should run SQL 2000 on a dedicated server.

To increase performance in terms of capacity and load balancing, you can group MeetingPlace Web servers into clusters. The MeetingPlace Web cluster can support a maximum of six Web servers in either internal or external configurations.


Note Do not use any Cisco or third-party web balancing products with the MeetingPlace solution. MeetingPlace Web has the correct web balancing built into the product, and other balancers will not work with this particular application.


Clients can connect to MeetingPlace Web via either HTTP or HTTP over Secure Socket Layer (HTTPS). The following destination ports are used on the MeetingPlace Web server:

TCP port 5003 is used to communicate to the MeetingPlace Audio Server via GWSIM.

TCP port 5005 is used for attachment and recording.

TCP port 80 or 443 is used for scheduling and displaying web pages.

TCP port 1627 (tunnel through port 80 if not open) or 443 is used for web conferencing when Secure Socket Layer (SSL) is deployed on that server. You must supply the SSL certificates for deployment on the MeetingPlace Web server.

SQL Database

The Microsoft SQL database on the Web server includes profile information as well as meeting information. The type of meeting information depends on whether the Web server is internal (hosting all internal and external meetings) or external (hosting only external meetings). The primary database is on the Audio Server. When a meeting is scheduled, the meeting information is also copied to the appropriate Web server to facilitate certain functions without having to go through the Audio Server for all requests.

Beginning with MeetingPlace 5.3, the database contains the following data:

Cached MeetingPlace data

Web server/site configuration data

Tables used by Microsoft Outlook and Lotus Notes to translate new, shorter Click-To-Attend links into their longer equivalents

Most English and localized strings used in the Web user interface

Any strings that the system administrator has customized

WebPolls along with their results

Microsoft Outlook and Lotus Notes do not use the database directly. They make requests to MeetingPlace Web to store Click-To-Attend links and then to attend meetings using those links.

MeetingPlace Video does not use the SQL database at all.


Note Cisco Security Agent currently is not supported for all the MeetingPlace servers, but the Cisco-approved virus protection programs are supported.


Meeting Type

The MeetingPlace Web application supports the following types of web conferences:

Open Forum Meeting

Each attendee can speak and listen equally.

Lecture-Style Meeting

The majority of attendees can enter as listeners by default, with one or more designated speakers. Listeners cannot speak during a meeting.

Immediate Meeting

This meeting is scheduled using the default system parameters. Users are not allowed to specify their own meeting parameters with this scheduling method.

Reservationless Meeting

This type of meeting has no requirement for resource reservation and meeting ID assignment in advance. The MeetingPlace Audio Server must be set to reservationless mode before this type of meeting can be initiated. Attendees in a reservationless meeting are placed in a waiting room until the meeting moderator logs into the meeting. Attendees in the waiting room cannot speak with each other.

Continuous Meeting

Only a System Manger can set up a continuous meeting (via the MeetingTime client) that is always available (24/7/365). These meeting ports are dedicated for this meeting only and are not available to the Audio system scheduling tasks.

Reserve All Ports

This feature is used by system administrators to busy-out all ports on the MeetingPlace Audio Server to provide a maintenance window.

Web Conference Cascading

Web conferences cannot be cascaded; all the participants must be on the same MeetingPlace Web server.

Segmented Meetings

For external users to attend the web conference via the Internet, Cisco recommends deploying another external MeetingPlace Web server in a demilitarized zone (DMZ). This arrangement will keep the internal network confidential inside the firewall. For details on this type of deployment, see Demilitarized Zone (DMZ) Requirements.

Video Conferencing

Although the MeetingPlace solution supports both H.323 and SIP, currently only H.323 video endpoints are supported for video conferences, which are handled by the MCU. All of the video conferences created by MeetingPlace are H.323 conferences, so MeetingPlace Video Integration requires H.323 resources on the MCU. In this solution, MeetingPlace plays the role of controlling application while the MCU provides the real resources and does bridging. In order to communicate with audio-only participants on the MeetingPlace Audio Server, a voice link is set up between the MCU and Audio Server, acting as a single audio participant of the video conference on the MCU.

Once MeetingPlace controls the MCU, all the H.323 ports are controlled, preventing conferences from being created directly on the MCU. MeetingPlace checks on a regular basis to ensure availability of the H.323 ports.

If the MCU is configured to allocate some resources for SCCP conferences as well, then they will still be usable for Cisco Unified CallManager to set up SCCP ad-hoc video conferences.

Voice Link

When a video endpoint participates in a conference, a special link called a voice link is established between the MeetingPlace Audio Server and the MCU. It acts as an audio participant dialing into the video conference on the MCU from the MeetingPlace Audio Server. All the audio endpoints of the conference connect to the MeetingPlace Audio Server, while all the video endpoints connect to the MCU. They communicate with each other via the voice link. The voice link is not established until the first video participant joins the conference. When the first video user joins the meeting, the MCU signals the MeetingPlace Video application, which causes the MeetingPlace Audio server to initiate the voice link to the MCU.

If there are multiple MeetingPlace H.323/SIP IP Gateways with various E.164 numbers used for the same Audio Server, all of these E.164 numbers must be entered in the MeetingPlace Video configuration page. The E.164 number being used depends on which MeetingPlace H.323/SIP IP Gateway that Audio Server has chosen for outdialing. The MeetingPlace Video application must be aware of all the possible E.164 numbers for the Audio Server in order to accept the voice link, no matter which number is chosen.

To utilize all the MeetingPlace features for pure video conferencing with no audio-only endpoints, the voice link still is required to connect the two systems because this link supports some advanced features on the MeetingPlace Audio Server, such as scheduling and recording the web and/or audio portion of the video conference.

Video recording is not supported on MeetingPlace Video Integration. MeetingPlace can be used to record the audio and web portions of video conferences. Third-party recording systems may be used to record the video sessions.

MeetingPlace Video

MeetingPlace Video is an application installed on an MCS that acts as a conference authorizer to the MCU. When the MCU receives a request to create a video conference or admit additional participants into an existing video conference, the MCU sends that request to MeetingPlace Video for approval.

One MeetingPlace Video application can communicate with only a single MeetingPlace Web server, and it must be installed on a machine running MeetingPlace Web 5.3. If there are multiple MeetingPlace Web servers being attached to a MeetingPlace Audio Server, only one of the Web servers can have MeetingPlace Video installed or enabled. Other MeetingPlace Web servers cannot provide the video feature for users.

If users outside the firewall need the video features, MeetingPlace Video must be enabled on the Web server located in the DMZ. Web collaboration for external users is supported via the Internet, but at this time the assumption is that external telephone and video participants will use the PSTN (or ISDN) to access gateways connected either to Cisco Unified CallManager or directly to MeetingPlace.

With MeetingPlace Video running in the DMZ, only external video meetings can be scheduled. Requests to schedule internal video meetings will fail.

If a meeting is scheduled with a request for video ports, the web conference for that meeting will be held on the MeetingPlace Web server where the MeetingPlace Video application is installed.

MCU Configuration

Cisco Unified MeetingPlace video conferencing can be integrated with Cisco Unified Videoconferencing MCUs. The MCU must be configured to authorize MeetingPlace to take control of scheduling and managing the conferences as a third-party agent. In the conference management configuration on the MCU, the External conference authentication policy must be set to Authorize.

Inbound calls can be routed to the MCU in either of the following ways:

Through Cisco Unified CallManager

On Cisco Unified CallManager, configure the route pattern for the MCU service prefix to route to the MCU directly (defined as a gateway).

Through a gatekeeper

On Cisco Unified CallManager, you can configure the route pattern for the MCU service prefix to route to the H.225 trunk to the gatekeeper.

Outbound calls from the MCU always require a gatekeeper for the following reasons:

The H.323 service code defined on the MCU must be registered to the gatekeeper so that the call can be routed to the gatekeeper when a caller dials in to the conference.

A gatekeeper is needed for address resolution because the MCU itself does not resolve the address from the H.323 video terminal.

The MCU is able to register with the gatekeeper either as a gateway or as an MCU (see Figure 15-11). Usually the MCU is registered as a gateway, but for MeetingPlace the MCU should register as an MCU. If the MCU is registered as an MCU instead of a gateway, it acts more like a terminal, with the service prefix registered to the gatekeeper as an E.164 number.

Figure 15-11 Two Methods of Registering the MCU with a Gatekeeper

A unique service code (prefix) must be configured on the MCU to be used by MeetingPlace. The protocol must be H.323. The service prefix must be the same as the prefix configured in the route pattern in Cisco Unified CallManager for routing video conference calls to the MCU. For more details, see Video Conference Call Flow.

MeetingPlace Video requires at least one conference view to be in the designated service code, and the view must be a single-panel view. The administrator can provide the second view to take advantage of MeetingPlace Web options for switching between voice-activated (VA) and continuous-presence (CP) viewing modes. (Cisco recommends using an Enhanced Media Processor module if you want to run CP mode.) The second view must be a multi-panel view.

Enhanced Media Processor (EMP) Requirement

The Cisco Unified Videoconferencing Enhanced Media Processor (EMP) is a powerful DSP resource module that can be installed on the MCU for more complicated computing and processing. Although the EMP is not required for most video conferencing capability (either voice activated or continuous presence for H.323), it is still strongly recommended because it provides better quality with the latest MeetingPlace Video software.

To run continuous presence on SCCP video devices, EMP is always required. From the MCU's perspective, the conference is still an H.323 conference instead of an SCCP conference.


Note MeetingPlace video integration does not support the Rate Matching Module and the Data Collaboration Server on Cisco Unified Videoconferencing MCU platforms.


Port Management

MeetingPlace Video provides the following types of ports:

Video Conference Ports

These ports are assigned dynamically based on the setup of the service code configured on the MCU. MeetingPlace Video periodically verifies if the resources (maximum number of video ports and conferences) have been modified in the MCU, and it updates the MeetingPlace Audio Server accordingly.

Video Floating Ports

These ports are allocated from the pool of video conference ports. They enable the system administrator to reserve a number of video ports for conferences that require more video ports than originally scheduled. A minimum number of floating ports is required to facilitate Voice Links. The formula for calculating this minimum number of floating ports is documented in the Administrator's Guide for Cisco Unified MeetingPlace Video Integration, available at

http://www.cisco.com/en/US/products/sw/ps5664/ps5669/prod_maintenance_guides_list.html

Video Overbook Ports

These ports do not exist physically. They are software ports configured to allow users to schedule more ports than are actually available, based on the assumption that there are usually some reserved but unused ports in some scheduled conferences. Because these ports do not exist physically, there is no limit to the number that can be configured.

Scheduling

The MeetingPlace video conference can be scheduled through the following interfaces only:

Web interface

Outlook or Notes interface

MeetingTime

Currently the Voice User Interface does not support video scheduling capability.

The video conference is not set up until the first video participant joins the conference. Users cannot get the video resources on the fly. The conference must be scheduled in advance or it must be reservationless.

The video conference is created using the designated service code defined on the MCU. Only one service code is allowed for MeetingPlace video integration. That service code controls the behavior and default parameters of all the MeetingPlace video conferences.

The dial-in number for the each created conference is unique and has the following format:

Designated service code (configured on MCU) + Meeting ID (assigned by MeetingPlace)

Either immediate or reservationless meetings can be created.

Attending a Video Conference

Video endpoints can join the meeting in either of the following ways:

Outdial from MeetingPlace

Users join the conference first via MeetingPlace Web or MeetingPlace Outlook. The endpoint address is part of the user's profile and will appear in the video endpoint address box. The user then clicks to have MeetingPlace outdial to the video endpoint. This is the easier way for the video endpoints to join a meeting.

Dial into the MCU

The number to dial is formatted as described in the section on Scheduling. This method is different than the typical user experience for audio-only endpoints because the prompts do not ask the video user to enter the meeting ID, as is the case when dialing into the MeetingPlace Audio Server. Because video conferencing does not currently use authentication, meetings with the following characteristics will not allow video dial-in:

Password-required meeting

Invitation-only or profile-only meeting (vs. public/anyone meeting)

For these types of meetings, users join from the MeetingPlace Web interface or Outlook.

Outdialing to video endpoints is not automatic for video conferences because the endpoints cannot be defined when the meeting is scheduled. After the meeting has started, users can click on the profile (phone number) to outdial.

Meeting Type

All video conferences are created on an ad-hoc basis using one of the following types:

Standard reserved or scheduled meeting

Continuous meeting

As with a scheduled meeting, the video conference is created when the first video user joins the conference. The video conference does not terminate until the entire meeting (audio and video) has been terminated by the MeetingPlace platform. The voice link between the Audio Server and the MCU will terminate 5 minutes after the last video participant leaves the conference.

Immediate meeting (system without reservationless meetings enabled)

Even if MeetingPlace does not have reservationless mode enabled, users still can start the immediate type of meetings via the Web interface as long as the current conference number and video ports in use do not exceed the capacity in the MCU.

Reservationless meeting

This type of meeting does not reserve any video ports in advance. Users may join this type of meeting as long as there are video conference slots and floating ports available. If a video user joins the reservationless meeting before it starts, the corresponding video conference will be created but the user will be put in the waiting room first until the conference initiator joins the meeting from the audio side. While in waiting mode, users cannot communicate with each other and will see a visual message stating that the meeting is not yet in session.

Lecture-style meeting

There are two types of participants in these meetings: speakers and listeners. Video users are always treated as listeners when they join, and they have no way to enable themselves as speakers even if they are really scheduled as speakers. The only way to join the lecture-style conference as a speaker is join the conference as an audio participant rather than a video participant. The speaker has the ability to choose starting the meeting with participants in the waiting room (muted and video blocked), as listeners (muted but able to see the image), or as an open floor (can communicate with audio and video immediately).

Multiserver meeting

See the section on Video Conference Cascading.

Video Conference Call Flow

When the first video participant joins a conference, MeetingPlace Video opens an XML control channel to the MCU and initiates an outdial from the audio server to the MCU, joining the audio conference to the video conference. The link behaves as an audio participant in both conferences.

Figure 15-12 illustrates the process involved in creating the voice link when the first conference participant initiates the video conference. Before a user can initiate the video conference, the MCU must first be registered to the gatekeeper as an MCU, and the MCU must also be defined in Cisco Unified CallManager as an H.323 gateway.

Figure 15-12 Video Conference Initiation Process

Figure 15-12 illustrates the following steps in the video conference initiation process:

1. The first video participant dials 8151234 (where 1234 is the meeting ID created by MeetingPlace), and the call is routed to Cisco Unified CallManager.

2. In Cisco Unified CallManager, the call matches route pattern 815XXXX, which points to the H.323 gateway that is defined in Cisco Unified CallManager to represent the MCU.

3. The call is routed to the MCU.

4. The MCU sends authorization to MeetingPlace Video to verify the meeting and participant information.

5. The MCU also registers the newly generated conference number (8151234) with the gatekeeper as an additional E.164 number.

6. MeetingPlace Video notifies the Audio Server to create the voice link.

7. The Audio Server dials 8151234 (the MCU) to join the video conference.

8. The call is directed to Cisco Unified CallManager, and again the same route pattern for this number is matched to route the call.

9. This call from the Audio Server is routed to the MCU.

10. The voice link is created between the Audio Server and the MCU.

11. The audio and video streams for the first video participant are set up between the endpoint and the MCU.

For the second and later video participants, the call flow follows steps 1, 2, 3, 4, and 11.

For video outdialing, the request is passed to the MCU from the MeetingPlace Video Integration (see Figure 15-14). For dial-in to the MCU from endpoints, the call flow is identical to the normal dial-in video call flow, with MeetingPlace getting involved only to check the user authentication (see Figure 15-15).

Figure 15-13 Call Flow for Video Conference Initiation (Voice Link Creation)

Figure 15-14 Call Flow for Video Conference Outdialing

Figure 15-15 Call Flow for Video Conference Dial-In

Video Conference Cascading

Currently video cannot be cascaded between MCUs in the MeetingPlace implementation. Different MeetingPlace Audio Servers can be cascaded for the same conference, which is referred to as a multiserver meeting, with the various MeetingPlace systems communicating with each other via the voice links. With a multiserver meeting, all participants are on the Web server associated with the primary Audio Server. Video participation can occur if the Web server used has video integration installed.

For more information on multiserver meetings, refer to the Administration Guide for Cisco Unified MeetingPlace Audio Server, available at

http://www.cisco.com/en/US/products/sw/ps5664/ps5669/prod_maintenance_guides_list.html

Gatekeeper and Dial Plan

A gatekeeper is a required component when H.323 video terminals are integrated with an IP Communications system. The gatekeeper mainly provides address resolution for the H.323 endpoints when they initiate calls.

With Cisco IOS Release 12.3(8)T or later, Cisco Unified CallManager can register itself to a via-zone gatekeeper as an IP-to-IP gateway (a new software feature in Cisco voice gatekeepers). Also, it can register H.323 endpoints with aliases (dynamic addresses) rather than with static IP addresses. These new features greatly influence H.323 video design with regard to MeetingPlace Video Integration, as described in the following sections.

When using multiple Cisco Unified CallManager clusters with a centralized gatekeeper providing intercluster trunk call admission control, the recommendation is to separate the gatekeepers used for video endpoints from those used for intercluster trunks. This practice allows for a more flexible dial plan. If the video zone and the intercluster trunk zone are configured on the same gatekeeper, the zone prefix for the intercluster trunk zone cannot overlap any endpoint numbers.

For more detailed information regarding the Gatekeeper and the Dial Plan, see the chapter on Dial Plan, page 10-1.

Dynamic H.323 Addressing in Cisco Unified CallManager

In Cisco Unified CallManager 4.0, H.323 clients are configured with static IP addresses. In Cisco Unified CallManager 4.1 and higher, H.323 clients can also be configured with E.164 addresses. E.164 addressing simplifies H.323 client administration for deployments where H.323 clients are configured for Dynamic Host Configuration Protocol (DHCP). E.164 addressing works in conjunction with a via-zone gatekeeper, which can be configured to route every call to Cisco Unified CallManager (acting as an IP-to-IP gateway) in the outvia zone (which is the Cisco Unified CallManager zone).

With this configuration, Cisco Unified CallManager can automatically create a special trunk, called the RasAggregator trunk, and register it to the gatekeeper. As the name suggests, this trunk is used for Registration Admission Status (RAS) and to administer and manage all the dynamically addressed H.323 devices defined in Cisco Unified CallManager as an aggregated device registered to the same gatekeeper. Whenever there are calls involving those H.323 devices, the gatekeeper communicates with Cisco Unified CallManager through this RasAggregator trunk.

Cisco Unified CallManager Redundancy Groups and H.323 Clients

The Cisco Unified CallManager redundancy group defined in the device pool of an H.323 client is important because it affects how calls may be placed using Cisco Unified CallManager and, if configured incorrectly, can cause calls to fail. The following rules apply when configuring redundancy groups:

If an H.323 endpoint uses peer-to-peer mode instead of a gatekeeper, the H.323 client must be configured to use the subscribers in the same priority order as listed in the redundancy group for that H.323 client device on Cisco Unified CallManager.

For each Cisco Unified CallManager redundancy group, you must configure a unique zone per gatekeeper.

MCU Registration

If the MCU registers with the gatekeeper as a gateway, its service prefix (for example, 85) is registered as a technology prefix. If an incoming call to the gatekeeper has a matching technology prefix in the called number, the gatekeeper will first try to look for the IP-to-IP gateway that is registered with that particular prefix in the via-zone. Therefore, when an H.323 endpoint dials into the MCU (using an access code of 851234, for example), the dialed number matches the technology prefix of 85 but the call fails because the IP-to-IP gateway (which is Cisco Unified CallManager) is actually registered with a technology prefix of 1#.

To avoid unwanted matches with the technology prefix, Cisco recommends registering the MCU as an MCU rather than a gateway. Registering the MCU as an MCU eliminates the technology prefix registration, thereby preventing the gatekeeper from finding an IP-to-IP gateway with that particular technology prefix.

Cisco also recommends configuring the MCU to register the conference IDs so that individual E.164 numbers are registered with the gatekeeper whenever a conference ID is created.

MeetingPlace

Because MeetingPlace registers with the gatekeeper as a terminal, you can put the MeetingPlace H.323/SIP IP Gateway in one zone with all other H.323 video endpoints. The RasAggregator trunk from Cisco Unified CallManager also registers to this same zone.

Reservationless Single Number Access (RSNA)

The Reservationless Single Number Access (RSNA) feature enables multiple MeetingPlace Audio Servers to appear as one server to the user community. This feature is designed primarily for reservationless meetings. With this feature, users can dial a single directory number to access multiple Audio Servers deployed in one location. Users dial in and enter their reservationless ID, and the system directs the calls to the appropriate server for that meeting. This feature also enables users in a remote location to dial the local server.

RSNA relies on SIP endpoints that support the REFER method. Cisco Unified CallManager 5.0 supports REFER, thus allowing RSNA to be implemented. Previous versions of Cisco Unified CallManager did not support REFER or RSNA.

For more details, refer to the MeetingPlace product documentation, available at

http://www.cisco.com/en/US/products/sw/ps5664/ps5669/tsd_products_support_series_home.html

Redundancy and Load Balancing

This section describes redundancy and load balancing considerations for the following MeetingPlace components:

MeetingPlace Audio Server

MeetingPlace H.323/SIP IP Gateway

MeetingPlace Web

Cisco Unified CallManager

MeetingPlace Video

MCU

MeetingPlace Audio Server

If the MeetingPlace Audio Server fails, calls in progress will be dropped. If the Audio Server is unreachable by the MeetingPlace H.323/SIP IP Gateway, the MeetingPlace H.323/SIP IP Gateway will immediately reject any incoming calls. If the MeetingPlace H.323/SIP IP Gateway is down, Cisco Unified CallManager will be unable to establish an H.323 connection with the MeetingPlace H.323/SIP IP Gateway. There is no automatic failover mechanism available for the MeetingPlace Audio Server.

Disaster Recovery

A disaster recovery plan provides for orderly restoration of the database, computing, and services. The plan usually includes the following provisions:

Redundancy (spare parts of hardware)

Data and software backups

Alternate emergency locations

Operations split across multiple sites

A component called the MeetingPlace Network Backup Gateway enables system mangers to transfer multiple copies of the MeetingPlace database (audio configuration files and scheduled meeting information) from the Audio Server to a designated storage server on the network. Files are encrypted for security. A maximum of three Network Backup Gateways per system can be implemented, but only one of them can make the database transfer at a time.

Redundancy

If two or more MeetingPlace Audio Servers are deployed, any of the following plans for redundancy can be implemented:

Shadow Server

A shadow server is a redundant MeetingPlace Audio Server that is not active until the primary Audio Server fails. During the disaster, the shadow server must be switched from shadow mode to active mode using the command line interface (CLI). Once active, the shadow server can store only limited information, such as profile information, meeting information (past, present, and future), and participant information. Recording, attachments, hardware and network configuration, and automatic software upgrades are not available on the shadow server. The shadow server has the following network connectivity requirements:

Less than 250 ms round trip delay

Less than 1% packet loss

Minimum bandwidth of 384 kbps

Dual Conference Servers

In this plan, two MeetingPlace Audio Servers are active production servers and each one can overflow to the other. Profiles are synchronized automatically between the servers through the Directory Services. Automatic failover between the two Audio Servers does not occur. Meetings have to be uploaded to the remaining server during an emergency, and users must rejoin the meetings manually. On Cisco Unified CallManager, you can configure route groups and route lists so that if one MeetingPlace Audio Servers fails, the calls will be routed to the other active MeetingPlace Audio Server.

Continuous Meeting Server

In this plan, a MeetingPlace Audio Server is implemented with a set of critical meetings pre-created and always available. This deployment is suitable for any crisis management application, with features such as blast outdial to crisis management teams.

MeetingPlace H.323/SIP IP Gateway

The following redundancy and load balancing considerations apply to the MeetingPlace H.323/SIP IP Gateway.

Redundancy

If the MeetingPlace H.323/SIP IP Gateway fails, calls in progress will be dropped.

Two or more MeetingPlace H.323/SIP IP Gateways can connect to the same MeetingPlace Audio Server. Dial-in redundancy can be implemented in the following ways:

Configure all of the MeetingPlace H.323/SIP IP Gateways on Cisco Unified CallManager and put them in the same route group. If the link between Cisco Unified CallManager and the MeetingPlace H.323/SIP IP Gateway fails, Cisco Unified CallManager chooses the next MeetingPlace H.323/SIP IP Gateway in the current route group. This same method also works for load balancing.

Have all the MeetingPlace H.323/SIP IP Gateways register to an H.323 gatekeeper in a specific zone, then the gatekeeper can take care of the failover. Configure gw-priority on the gatekeeper to specify the chosen priority of each MeetingPlace H.323/SIP IP Gateway.

For outdial, the MeetingPlace Audio Server uses the following algorithm:

If all the MeetingPlace H.323/SIP IP Gateways are functioning correctly with no outdial failures at all, the Audio Server will choose the least busy gateway for outdial, thus load balancing between them.

If any of the MeetingPlace H.323/SIP IP Gateways has a failure, the Audio Server will skip that one and do load balancing on the remained gateways that do not have failures.

If all the servers have had failures, then the Audio Server will choose the one with the oldest failure time and will keep using that same gateway until it fails again.

Load Balancing

For dial-in load balancing, you can use either of the following same approaches as for redundancy:

Use a route group in Cisco Unified CallManager, but choose Circular instead of Top down for the Distribution Algorithm. Cisco Unified CallManager will distribute the outbound calls between the gateways in round-robin fashion.

Use a gatekeeper. For purposes of load balancing, do not configure gw-priority to specify a preferred gateway. Instead, let the gatekeeper distribute the calls in round-robin fashion to all the registered gateways.

As explained in the previous section, load balancing for outdial is done only among those MeetingPlace H.323/SIP IP Gateways that never have outdial failures.

MeetingPlace Web

The following redundancy and load balancing considerations apply to the MeetingPlace Web.

Redundancy

If a web-conferencing server fails during a web conference, all users are disconnected from the web portion of the meeting, and the current web conference cannot continue. Users can rejoin their web conference on another active web server. If the SQL server database is on the failed server, all web conferencing servers in the cluster become nonfunctional and users will be unable to conduct web conferences until the database is restored.

Load Balancing

MeetingPlace Web servers can be grouped into clusters to increase performance for load balancing (to distribute the meeting requests to different web servers) and to increase the capability of handling more meetings. The MeetingPlace Web cluster can contain a maximum of six web servers in either internal or external configurations.

The MeetingPlace WebConnect feature provides integration between multiple internal and external MeetingPlace systems through a single URL. It can schedule across multiple Audio Servers. If there is not enough capacity on the first Audio Server, it will try the second, and so on.

Cisco Unified CallManager

The following redundancy and load balancing considerations apply to Cisco Unified CallManager.

Redundancy

If Cisco Unified CallManager fails, MeetingPlace calls in progress using that Cisco Unified CallManager will be dropped, and users must rejoin the meeting. For dial-in from endpoints, redundancy is achieved with redundancy groups configured in the Cisco Unified CallManager cluster.

For outdialing from MeetingPlace through a MeetingPlace H.323/SIP IP Gateway, each MeetingPlace H.323/SIP IP Gateway can communicate with only one Cisco Unified CallManager. Therefore, the following guidelines apply to redundancy:

If the MeetingPlace H.323/SIP IP Gateway is configured to communicate with Cisco Unified CallManager directly as a gateway, redundancy can be implemented only by connecting two or more MeetingPlace H.323/SIP IP Gateways to the same MeetingPlace Audio Server.

If the MeetingPlace H.323/SIP IP Gateway is registered to a gatekeeper, then the gatekeeper will handle the failover situation, routing calls to an active Cisco Unified CallManager.

Load Balancing

For dial-in from endpoints to MeetingPlace, load balancing for calls is achieved through Cisco Unified CallManager redundancy groups and route group configurations.

For outdialing from MeetingPlace through a MeetingPlace H.323/SIP IP Gateway, the same guidelines apply for load balancing as for redundancy.

MeetingPlace Video

The following redundancy and load balancing considerations apply to the MeetingPlace Video.

Redundancy

Only one MeetingPlace Video application can be implemented in a MeetingPlace 5.3 system. MeetingPlace Video must be installed on a server running MeetingPlace Web 5.3. MeetingPlace Video can communicate with only one MeetingPlace Web server.

If a meeting is scheduled with video ports requested, the web conference for that meeting will be held on the MeetingPlace Web server where MeetingPlace Video is installed. If that server fails, the meeting will roll over to another server after a period equal to five times the Load Stats Poll Period configured on the site administration UI page. (The default is one minute.) If a conference with scheduled video ports has rolled over to another web server, no video features will be provided in the GUI. Users will not be able to outdial, but they can still choose to dial in.

Load Balancing

Because only one MeetingPlace Video application can be active at a time, there is no load balancing for MeetingPlace Video.

MCU

Currently with MeetingPlace 5.3 video integration, you can have only one MCU per MeetingPlace Audio Server. Therefore, there is no redundancy or load balancing for the MCU.