Cisco Preferred Architecture for Enterprise Collaboration 11.0, CVD

What’s New in This Chapter

Table 3-1 lists the topics that are new in this chapter or that have changed significantly from previous releases of this document.

Core Components

The core architecture contains these key conferencing elements:

• Cisco TelePresence Server for audio and video conference resources
• Cisco TelePresence Conductor for management of audio and video resources as well as TelePresence Server resource licenses
• Cisco TelePresence Management Suite (TMS) for conference provisioning, monitoring, and scheduling
• Cisco TelePresence Management Suite Extension for Microsoft Exchange (TMSXE) for interfacing with Microsoft Exchange room and resource calendars
• Cisco TelePresence Management Suite Provisioning Extension (TMSPE) for configuring Cisco Collaboration Meeting Rooms (CMRs) as well as provisioning multiparty licenses for users
• Cisco WebEx Software as a Service (SaaS) for scheduled audio and web conferences and hybrid video and web conferences

In addition, Cisco TMS architecture includes these non-Cisco components:

• Microsoft SQL database
• Microsoft Active Directory
• Microsoft Exchange or Microsoft Office 365
• Network Load Balancer

Key Benefits

• Simplified, optimal user experience for conference participants
• Flexible, extendable architecture that supports deployment of one or more permanent, scheduled, and/or instant conference resources
• Dynamic optimization of conference resources on the TelePresence Server for inbound calls
• High availability of conference resources and processes
• Resilience in the video network
• A single tool for hosts to schedule participants and conference rooms for a meeting
• Ability to integrate the WebEx and video participants into a single meeting without additional end-user intervention
• Multiparty licensing that enables full access to all conference resources and simplifies the deployment process of the TelePresence Server

Conference Types

The conferencing solution supports the conference types and conferencing features listed in Table 3-2 and Table 3-3 .

Role of the TelePresence Conductor

TelePresence Conductor manages the TelePresence Server resources for all types of conferences. It selects which TelePresence Server to host a specific conference, and it balances the conference load across the TelePresence Servers in the defined pools. Unified CM is unaware of the individual TelePresence Servers in the network and communicates only with the TelePresence Conductor. When Multiparty Licensing mode is enabled in TelePresence Conductor, it can centrally manage licenses for all TelePresence Servers.

Using TelePresence Conductor for conferences and license management has several benefits, including:

• Increased efficiency by sharing resources from TelePresence Servers for conferences
• Better user experience with the advanced TelePresence Server features such as ActiveControl and dynamic optimization of resources
• Simpler deployment options through provisioned CMRs
• Single deployment model for all types of conferences
• Simplify TelePresence Server deployment process

TelePresence Conductor optimizes TelePresence Server resources dynamically when the Optimize resources setting is enabled in the TelePresence Conductor conference template. This enforces maximum resource usage of a participant based on the maximum receive bandwidth advertised by them at conference join. This can reduce the amount of resources conference calls use and allow more concurrent connections to take place. For more information, see the TelePresence Server release notes.

Role of TelePresence Servers

TelePresence Servers are conference bridges that operate in remotely managed mode and are grouped into pools in TelePresence Conductor. TelePresence Conductor applies service preferences to prioritize the pools for conferencing. The bridge pool can be shared between scheduled and non-scheduled conferences or dedicated to either type of conference.

Role of Cisco TMS

Cisco TMS integrates the conference room endpoints, TelePresence Conductor, and connections to the WebEx cloud in a manner that provides an end user with a unified experience for scheduled conferencing. Unified CM maintains the configuration control for endpoints, and TMS is then able to push the calendar to those endpoints. Administrators are able to set the parameters for the default conference for their organization, and then individual conferences will be created according to this template.

Some of the TMS features are not used in the Preferred Architecture – for example, phone books, software management, and reporting functions.

Cisco TelePresence Management Suite Provisioning Extension (TMSPE) supports automated bulk provisioning by administrators of personal Collaboration Meeting Rooms (CMRs) and a user portal for individuals to define and manage their own personal CMRs. CMRs are used for non-scheduled conferencing where specific endpoints are not identified, and the user simply dials in to the CMR number. In addition, TMSPE provides an interface for Multiparty License provisioning.

Role of Cisco TMS Extensions for Microsoft Exchange

When end users schedule a meeting in Microsoft Outlook with multiple conference room resources, the Exchange Web Services (EWS) feature of Exchange synchronizes that event into TMS as a scheduled conference. This synchronization is bidirectional, allowing an administrator or support staff to update meetings as well without the need to access the meeting organizer's Outlook event. All endpoint resources within the organization that are intended to be in the conference must be listed on a single Exchange meeting request.

Deployment Overview

The standard deployment uses multiple Unified CM nodes for call control. The TelePresence Conductor is connected to Unified CM with SIP trunks that manage TelePresence Servers to provide conference resources. (Figure 3-3) TelePresence Servers are used to bridge calls, and Cisco TMS provides conference management facilities and scheduling.

Figure 3-3 Standard Deployment

The standard deployment has several TelePresence Servers behind TelePresence Conductor, combined with Unified CM for call control and endpoint management, and Cisco TMS for conference management. The same conferencing infrastructure can be used for both non-scheduled and scheduled conferencing as well as CMR Hybrid services. WebEx provides scheduled audio and video web conferencing. These elements together provide voice and video conferencing for the local enterprise.

Requirements and Recommendations

• Early Offer is required for CMR Hybrid calls and for some third-party services such as Microsoft Lync.
• Early Offer messaging is recommended for all SIP trunks connected to Unified CM that carry TelePresence calls.
• All TelePresence Servers should be configured in remotely managed mode and placed behind TelePresence Conductor as conferencing resources for all conference types.
• Enable Multiparty Licensing in TelePresence Conductor for TelePresence Server resource license management.
• The Multiway ^TM method of escalated conferencing is not recommended.
• Audio conferencing on the TelePresence Server does not support join or leave tones.

Conference Call Flows

Unified CM provides device registration and routing of voice and video calls between the connected endpoints. Permanent, instant, and scheduled conference calls are carried over SIP trunks. XML-RPC connections are configured on the Unified CM publisher and connect over HTTP between Unified CM call processing subscriber nodes and TelePresence Conductor nodes.

Figure 3-4 Unified CM, and TelePresence Conductor SIP Trunks

CMR and scheduled conference calls are routed over the same trunk from Unified CM. In contrast, instant conference calls route directly to a TelePresence Conductor template from the Unified CM that created the conference, so multiple trunks may exist for instant conferences, one for each type. Each trunk has an associated XML-RPC connection. Their originating Unified CM controls instant conferences, so a SIP API trunk pair is required per instant conference type from each Unified CM cluster that supports instant conferencing to the local TelePresence Conductor.

Instant call flows that are managed by Unified CM cannot be used to add participants to conferences created by any other method, such as scheduled conferences. Other call flows cannot be used to add participants to instant conferences. The instant call escalation method is supported only in an instant conference that was created by it, and conferences generated by other methods cannot be extended by the instant mechanism. This avoids any potential for chained conferences.

Note Unified CM delivers instant conferences to different IP addresses than CMR and scheduled conferences on TelePresence Conductor. Multiple Unified CM clusters can access the same IP address on TelePresence Conductor. However, this document assumes that a TelePresence Conductor cluster is dedicated to each Unified CM cluster.

Instant Conferences

Instant conferences are configured on the TelePresence Conductor, so the conference is never statically defined on a single TelePresence Server. TelePresence Conductor load-balances the conferences across the available TelePresence Servers in a pool, increasing conference resilience. Instant conferences require a SIP trunk with an associated XML-RPC connection between Unified CM and each TelePresence Conductor node. Unified CM routes the instant conference participants to the IP addresses of these SIP trunks.

Permanent Conferences with Collaboration Meeting Rooms

Permanent conferences are deployed using Personal Collaboration Meeting Rooms (CMRs). Personal CMRs provide a permanent-type conference that is created with Cisco TMSPE in conjunction with the Conductor Provisioning API. Users can dial the conference alias at any time to start a meeting.

Individual end-users create their own CMRs through the Cisco TMSPE user portal, based on group-level templates provisioned by their administrator. Each CMR created through the user portal has a corresponding conferencing bundle entity (ConfBundle) on TelePresence Conductor, which is created and managed through the Conductor Provisioning API and contains the data required to create a conference for one or more users, including conference template information, a set of conference aliases, a set of auto-dialed participants, and a conference name. ConfBundles are reported in the web UI as "Collaboration meeting rooms." CMRs created using Cisco TMSPE cannot be modified through the TelePresence Conductor web UI. Conversely, conference templates and aliases created using TelePresence Conductor cannot be modified through Cisco TMSPE. CMR conferences require a SIP trunk between Unified CM and each TelePresence Conductor node. Unified CM routes the CMR conference participants to the IP addresses of these SIP trunks.

Configuration Information

• For details about Cisco TMSPE settings, see the Cisco TelePresence Management Suite Provisioning Extension with Cisco Unified CM Deployment Guide, available at

http://www.cisco.com/c/en/us/support/conferencing/telepresence-management-suite-provisioning-extension/model.html

• For details about the Conductor Provisioning API, see Cisco TelePresence Conductor API Guide, available at

http://www.cisco.com/c/en/us/support/conferencing/telepresence-conductor/products-programming-reference-guides-list.html

Scheduled Conferences

This solution supports scheduling of conferences through TelePresence Conductor. Scheduling is performed with Cisco TMS. Scheduled conferences require a SIP trunk between Unified CM and each TelePresence Conductor node. Unified CM routes the scheduled conference participants to the IP addresses of these SIP trunks. These trunks are the same trunks used for CMR conferences.

Two deployments for scheduling TelePresence Server resources are possible when using TelePresence Conductor: Conferencing resources can be dedicated for scheduled conferencing or they can be shared resources for both scheduled and non-scheduled conferencing. Some advantages and disadvantages are covered in Table 3-4 .

• Dedicated TelePresence Servers — Deploy one or more TelePresence Servers that are dedicated just for scheduled conferences, with each TelePresence Server in a separate bridge pool and service preference of its own (Figure 3-5). Optionally, a second bridge and pool combination can be used as a backup.

Figure 3-5 Dedicated Scheduling TelePresence Server

• Shared TelePresence Servers — Allow TelePresence Servers to be used for non-scheduled as well as scheduled conferences (Figure 3-6). In this case, resource availability for scheduled conferences cannot be guaranteed because the necessary resources might already be in use by non-scheduled conferences. All TelePresence Servers can be configured into a single bridge pool if they are of similar size.

Figure 3-6 Shared Scheduling TelePresence Server

Tip TelePresence Servers can be set up in the TelePresence Conductor to host instant conferences only, CMR conferences only, scheduled conferences only, or all three. Using a single TelePresence Server pool can minimize the number of TelePresence Servers needed because you can provision for the overall maximum number of conference participants.

Multiway

Multiway is a method for instant conferencing, but is not used in this Enterprise Collaboration Preferred Architecture. In Unified CM deployments as described in this document, instant conferences should be initiated using the conference button on the device instead. Using both types of instant conferencing simultaneously is not supported.

Third-Party Endpoints

Endpoints from other equipment providers can participate in instant, scheduled, and CMR conferences using standard SIP. Only endpoints registered to Unified CM that support the conference button can initiate an instant conference. Cisco Expressway or Cisco VCS can be used to interwork H.323 calls to SIP, allowing H.323 endpoints to join conferences.

Cisco WebEx Software as a Service (SaaS)

Cisco WebEx Software as a Service (SaaS) is a cloud hosted solution that provides audio and video web conferencing with rich content collaboration. We recommend using this service when hosting scheduled audio conferences. It is also used to create CMR Hybrid conferences, as described in the next section.

Cisco CMR Hybrid

Cisco WebEx and TelePresence users can participate jointly in scheduled meetings or the users’ personal Collaboration Meeting Rooms (CMRs). Both SIP and PSTN-based audio are supported for the audio portion of the call between Cisco WebEx and the TelePresence Servers. (The audio connections between WebEx participants and the WebEx conference can be PSTN audio, SIP audio, or computer telephony.)

Cisco WebEx Meetings Server

For some deployments, a cloud-based collaboration service might not be suitable. For these customers we recommend using Cisco WebEx Meetings Server instead as an on-premises solution. This server does not integrate with TelePresence the way the Software as a Service version of WebEx does, but instead acts as a standalone audio, video, and collaboration web conferencing service. For installation instructions, refer to the WebEx Meetings Server product documentation at

http://www.cisco.com/c/en/us/support/conferencing/webex-meetings-server/products-installation-guides-list.html

Collaboration Meeting Rooms (CMR) Cloud

Cisco CMR Cloud is an alternate conferencing deployment model that negates the need for any on-premises conferencing resource or management infrastructure. CMR Cloud is a simple-to-use cloud hosted meeting room solution that is offered as an add-on option to a Cisco WebEx Meeting Center subscription, and it is delivered through the Cisco WebEx Cloud. The solution enables meetings in the cloud that can scale to support up to 25 standards-based video endpoints and up to 500 video-enabled and 500 audio-only WebEx Meeting Center users, with a total of up to 1,025 participants in a single meeting. This guide does not cover deployment of CMR Cloud. For CMR Cloud deployment details, refer to Cisco Collaboration Meeting Rooms (CMR) Cloud Enterprise Deployment Guide, available at

http://www.cisco.com/c/en/us/support/conferencing/webex-meeting-center/products-installation-and-configuration-guides-list.html

High Availability for Conferencing

High availability must be considered at several levels with the conferencing solution and is achieved in different ways depending on the service being considered.

For both scheduled and non-scheduled conferences, high availability involves Unified CM, the TelePresence Server, and TelePresence Conductor.

TelePresence Server High Availability

In the event of a TelePresence Server failure, the conference can take place on another TelePresence Server as long as there is an available resource within the Service Preference in TelePresence Conductor. The conference number remains identical, and therefore this is seamless as far as the end user is concerned. However, if the TelePresence Server fails while hosting a live conference, users need to redial the same number to join the conference on the new TelePresence Server.

TelePresence Conductor High Availability

A full-capacity standard TelePresence Conductor can be part of a cluster of up to three Conductor nodes. Each node must be within 30 ms round trip delay to every other node. Calls can flow through any nodes in the cluster. If a node becomes unavailable, the remaining TelePresence Conductor nodes can be used to join conferences.

TelePresence Conductor clusters are used for redundancy; when the primary conductor fails, a secondary or tertiary conductor is available to manage the current and future conferences. This redundancy works seamlessly for instant and permanent conferencing. For scheduled conferencing, however, this redundancy is not automatic but requires manual intervention to fail-over to a secondary or tertiary TelePresence Conductor. The reason for this is that Cisco TMS recognizes only one TelePresence Conductor node. If that cluster node should fail, Cisco TMS scheduling will be unavailable until that node is brought back up or Cisco TMS is updated to communicate with a different TelePresence Conductor node in the cluster.

Cisco TMS considers each alias configured on a TelePresence Conductor as a separate set of TelePresence Server resources. If an alias has no available resources to schedule a call, then the next aliases are considered in priority order. Where multiple TelePresence Conductors are configured (one per TelePresence Conductor cluster), then these are also considered by Cisco TMS for scheduled conferences. Cisco TMS uses the IP Zone configuration of the TelePresence Conductor and the endpoints scheduled at the time of the booking to decide which TelePresence Conductor should be preferred in the booking.

TMS High Availability

High availability deployment of Cisco TMS includes: Two TMS front-end servers that also host the TMS Provisioning Extension (TMSPE) application, two servers running TMSXE, a network load balancer, and an external Microsoft SQL database (see Figure 3-2). TMS resiliency supports only two servers – one active node and one passive node – and this model does not increase or decrease the capacity of the TMS deployment. The network load balancer (NLB) is deployed in front of the TMS servers. Inbound traffic to TMS goes through the NLB, which forwards it to the active node. Outbound traffic from TMS is sent directly to the destination without going through the NLB. If the NLB detects a failure on the existing active node, it automatically switches to the new active node without any user intervention.

This document assumes that the WebEx Cloud is used for scheduled audio conferences. WebEx Cloud has built-in high availability and therefore has no additional resiliency considerations beyond normal telephony and web connectivity. If Cisco WebEx Meetings Server is used instead, then high availability must be considered for the servers, but this approach is not discussed in this document.

Security for Conferencing

The Preferred Architecture fully supports media and signaling encryption; but for simplicity, the solution presented in this document implements non-secure SIP trunks between Unified CM and TelePresence Conductor for all conferences. An exception to this is the solution requirement that API communications between TelePresence Conductor and the TelePresence Server must be encrypted, and therefore HTTPS must be used in this case. It is also a requirement for communications between Cisco Expressway and the WebEx Cloud to use valid Certificate Authority signed certificates to enable encrypted media and signaling.

Another level of security can be added to restrict access to the conferences themselves with PINs or passwords. Any scheduled conference or CMR conference can have a PIN set so that all participants are challenged to enter the PIN before being allowed to connect. With CMR Hybrid, a PIN can be used to protect the TelePresence portion of the conference, and a password can be added or auto-generated for the WebEx portion of the conference.

Scaling the Conferencing Solution

You can scale the conferencing solution primarily by increasing the number of available TelePresence Servers.

The total number of TelePresence Servers is limited by the capacity of TelePresence Conductor. Each full-capacity TelePresence Conductor (or each cluster) can manage up to 30 TelePresence Servers or 2,400 concurrent conference calls. Clustering does not increase the maximum number of TelePresence Servers or concurrent calls that can be supported.

If a deployment grows beyond the capacity of a single TelePresence Conductor, it is possible to create a new independent cluster and continue to add TelePresence Servers there.

Use an independent TelePresence Conductor cluster for each regional Unified CM cluster. For example, if your deployment has three Unified CMs clusters, then you should also deploy three TelePresence Conductor clusters, one in each region.

1. Plan the Conferencing Deployment

Before deploying the conferencing solution, plan for the following aspects:

Requirements

• Provision IP addresses; each TelePresence Conductor node requires an IP address for itself and up to 64 additional IP addresses, depending on the conference services deployed.
• Order and install encryption keys on all TelePresence Servers.
• CMR Hybrid has a number of requirements that should be understood in advance to ensure everything that is required is in place. For example, an option key must be ordered for Cisco TMS, and Cisco Expressway-E must have a publicly signed certificate from an appropriate Certificate Authority and must trust the WebEx root certificate in order to allow CMR Hybrid to function.

Product Models

Cisco makes several different models of the TelePresence Conductor and TelePresence Server. It is important to understand the differences between these models so you can choose the best option for your deployment.

There are three models of TelePresence Conductor. Use the full-capacity version for enterprise deployments because it supports up to 2,400 concurrent calls and up to three Conductor nodes in a cluster.

Any TelePresence Server may be used for scheduled or non-scheduled conferences behind TelePresence Conductor. TelePresence Servers on virtual machines are available in several capacities. If larger capacities are required, the MSE 8000 chassis-based Multiparty Media 820 (MM820) blade can be used. The MM820 supports two blades per cluster, which doubles the capacity of the MM820. A cluster behaves as if it is a single device.

Any of these devices can be configured to run in remotely managed mode and therefore work with TelePresence Conductor.

Licensing

Licenses must be installed on various products:

• Cisco TMS must have enough device licenses installed for the deployment.
• A full version of TelePresence Conductor comes with the required licenses installed.
• TelePresence Conductor manages TelePresence Servers using Multiparty licensing.

Multiparty is a user-based licensing model that is centrally managed by TelePresence Conductor. It comes with two variations: Personal and Shared. Personal Multiparty (PMP) is for specific named hosts while Shared Multiparty (SMP) is for conference room systems or for sharing between users. Each license entitles a user to host a conference with unlimited participants and up to 1080p video resolution. Table 3-5 summarizes the features included in the Personal and Shared Multiparty licenses.

Multiparty licensing is the license model used in the Preferred Architecture. For more information on Multiparty licenses, refer to Cisco Multiparty Licensing At-a-Glance, available at

http://www.cisco.com/c/dam/en/us/solutions/collateral/collaboration/pervasive-conferencing/at-a-glance-c45-729835.pdf

Cisco TelePresence Management Suite

Before beginning the installation and configuration process, you must decide on several items to align with the specific structure and preferences of your organization. Additionally, some specific settings must be used during the configuration process and should be gathered prior to beginning the install process.

Microsoft SQL

Cisco TMS utilizes an external Microsoft SQL database to store all data regarding meetings, users, and systems. During the installation process, TMS and associated software extensions create a number of specific databases. The TMS application does not allow users to log into the web page if communication is not currently active with the tmsng database. This dependency on constant communication with the SQL database requires the SQL database to utilize Microsoft's methods for making the database resilient as well. The databases will vary in size depending upon the deployment size and number of scheduling events; but as a general guideline, 1 GB of initial storage will suffice for most organizations.

Table 3-6 lists the Microsoft SQL 2012 specifics required to support Cisco TMS, TMSXE, and TMSPE.

Note While other modes of SQL resiliency are supported by TMS, any method besides AlwaysOn Failover Cluster requires manual adjustments by the TMS administrator during an SQL outage situation.

Active Directory

Cisco TMS functions using many aspects of Microsoft Active Directory, and the server must be added to the organization's domain,. All TMS users must be imported from and authenticated with Active Directory.

During the configuration process, you must enter an AD Service account username and password for TMS to import users. This is a read-only account, and TMS does not modify any information in Active Directory. This account should have access to the highest level of the AD structure that enables all subsequent end users to access its functionality. In organizations with multiple domains, the TMS user account must be associated with the top level domain. An additional service account is required for the TMSXE application for end-user booking of Exchange resources. This should also be a read-only service account, and end user credentials are used for the actual event booking. TMSXE user account permits only the TMSXE application to authenticate and communicate with the Exchange Servers through Exchange Web Services.

Additionally, identify existing, or create new, Groups with AD that will serve to synchronize TMS administrators and end users with scheduling access to TMS.

Note Local machine accounts on the TMS server should not be used because they are not duplicated between front-end servers, and the user credentials would not be available if the other node became active.

Email Integration

TMS sends automated emails to users when they schedule meetings, with all connection information included for the participants. During the installation process, you must enter the "from" address that end users will see as the originating for these emails, so select an address such as collabconferencing@ent-pa.com or a similar address not currently used in your organization.

You will also need to enter the SMTP address of the outgoing mail server.

Zones

Cisco TMS uses a concept called zones to provide guidance to the scheduling engine on how to build the calls and keep the traffic localized as much as possible. Endpoints, conferencing resources, and ISDN gateways are all assigned to these zones. The zones define where to use which kind of network connections. The Preferred Architecture is based upon all endpoints being able to use a single IP network for connections, and ISDN would be used only for connecting outside of the organization. (See Figure 3-7.)

Figure 3-7 Cisco TMS IP Zones

IP Zones

IP zones refer to areas of the network that share a common primary data center, and they are used primarily to identify "local" conferencing resources. During the configuration process, add IP zones for each location where conferencing resources will be placed. As shown in Figure 3-8, the USHQ TelePresence Conductor is selected because most participants are connected from that zone.

Figure 3-8 Cisco TMS Uses IP Zones to Select Best TelePresence Conductor for a Conference

ISDN Zones

ISDN zones are similar to IP zones, but specific to any deployment of ISDN gateways in the organization. If no ISDN functionality is needed, you still have to configure a single ISDN zone for the entire enterprise during the installation.

Endpoint Naming Conventions

Endpoints are added to Cisco TMS for two reasons:

• Correlation with Exchange resources for conference resource allocation
• Enabling TMS to provide One Button to Push connection information on the endpoint user interface

As endpoints are added to TMS, use the same character string as the room or resource name in Exchange. This provides uniformity and consistency to end users when system names appear in the call history and fill the text of on-screen labels from conferencing resources.

An organized plan for how to use the folder structure of TMS Systems Navigator will also assist the administrator in having a simplified interface.

Default Conference Parameters for Your Organization

These settings are customizable for each organization and should be used in accordance with your own network considerations, meeting flows, and corporate culture. The default conference settings are used for all meetings scheduled by end users through Outlook. For all possible settings of the default conference, refer to the Cisco TelePresence Management Suite Administrator Guide, available at

http://www.cisco.com/c/en/us/support/conferencing/telepresence-management-suite-tms/products-maintenance-guides-list.html

WebEx Site for CMR Hybrid

Be sure that you have the hostname and site name for your WebEx site. Then configure this WebEx site for integration between the on-premises TelePresence conferencing infrastructure and the WebEx cloud. For details, refer to Cisco Collaboration Meeting Rooms (CMR) Hybrid Configuration Guide, available at

http://www.cisco.com/c/en/us/support/conferencing/collaboration-meeting-rooms-cmr/products-installation-and-configuration-guides-list.html

CMR Provisioning

An understanding of how the organization plans to utilize Collaboration Meeting Rooms leads to an understanding of the workflow that end users expect for meetings. Some organizations may choose to leverage CMRs instead of scheduled resources for certain meeting types, especially in cases where workers are in separate locations and not able to gather in a common conference room.

Location of Servers

Both the active and passive nodes for a redundant TMS deployment must be configured with the same time zone within the server operating system. In addition, this must be the same time zone as the SQL server. Support of TMS redundancy is limited to the same local network for both the active and passive nodes, along with the SQL server.

2. Deploy TelePresence Servers

This section describes the major tasks required to deploy TelePresence Servers and prepare them for use with TelePresence Conductor. These TelePresence Servers can be used for scheduled and non-scheduled conferences.

Overview

Deployment Considerations

The physical location of a TelePresence Server is important to consider because media traffic flows between it and each participant in the conference. To provide the best experience for participants, centralize the location of the TelePresence Servers in each region where they will be deployed.

Set the TelePresence Servers to remotely managed mode, which is a system-wide setting that enables a more advanced API and requires that API to be used for all operations. Remotely managed mode is the only mode available on the Cisco TelePresence Server on Virtual Machine, while other variants of the TelePresence Server can use either remotely managed mode or locally managed mode (which cannot be used with TelePresence Conductor).

Caution In remotely managed mode certain features are not available from the TelePresence Server interface, and management of conferences and pre-configuration of endpoints are done at the TelePresence conductor level instead. Changing the operating mode requires the TelePresence Server to be rebooted, and any conferences configured on the TelePresence Server in locally managed mode are lost when the unit reboots.

---

TelePresence Conductor manages the TelePresence Servers via an XML-RPC API. TelePresence Conductor also routes SIP signaling to the TelePresence Servers via its Back-to-Back User Agent (B2BUA).

The TelePresence Server has the ability to use a secure connection for communications. These security features are enabled with the activation key. Encrypted communication between TelePresence Server and TelePresence Conductor is mandatory. The media encryption key allows TelePresence Server to use encrypted media via SRTP.

Instant, Permanent, and Scheduled Conferences

Figure 3-9 Instant Conference Call Flow

Figure 3-10 Permanent or Scheduled Conference Call Flow

Deployment Tasks for TelePresence Servers

First apply an activation key to all TelePresence Servers. This allows the use of encrypted signaling with HTTPS and TLS. Then enable and configure the HTTPS and encrypted SIP (TLS) services in the TelePresence Servers. If the deployment requires encrypted media, apply the media encryption feature key.

To enable TelePresence Conductor to communicate with the TelePresence Server, create an API access user account on the TelePresence Server that TelePresence Conductor uses for API authentication.

Disable all H.323 settings on the TelePresence Server, and enable call direct mode in SIP settings using TLS for outbound transport. This is required because TelePresence Conductor uses SIP only.

Then set the TelePresence Server to remotely managed mode. This enables TelePresence Conductor to communicate with the server. This task is not relevant for Cisco TelePresence Server on Virtual Machine that always runs in remotely managed mode.

Summary

After completing the above tasks, TelePresence Servers will be ready to add to TelePresence Conductor.

3. Deploy TelePresence Conductor

This section describes the major tasks required to deploy TelePresence Conductor for scheduled and non-scheduled conferences.

Overview

Deployment Considerations

Note Before configuring TelePresence Conductor, clear all alarms to allow the product to function.

To enable instant, CMR, and scheduled conferencing, the system administrator needs to complete the configuration on TelePresence Conductor and Unified CM. These two products share the responsibility for conference creation logic. While TelePresence Conductor maintains exclusive connectivity to the TelePresence Servers, it acts similarly to an MCU as far as Unified CM is concerned, and it makes decisions on conference placement based on requests from Unified CM.

TelePresence Conductor should be deployed regionally in a centralized manner so that each regional Unified CM cluster has a TelePresence Conductor cluster associated with it that manages all the TelePresence Servers in the region, as illustrated in Figure 3-1.

TelePresence Conductor should be deployed using its Back-to-Back User Agent (B2BUA). Unified CM communicates with TelePresence Conductor using an XML-RPC API and SIP trunks, similar to the way TelePresence Conductor communicates with the TelePresence Server. (Figure 3-11)

Figure 3-11 API and SIP Trunk Connections Between Unified CM and TelePresence Conductor

Instant and Scheduled Conferences

Figure 3-12 TelePresence Conductor Internal Configuration Flow for Instant Conferences

Figure 3-13 TelePresence Conductor Internal Configuration Flow for Scheduled Conferences

Deployment Tasks Common to Instant and Scheduled Conferences on TelePresence Conductor

Resolve all alarms within TelePresence Conductor before starting configuration. Unresolved alarms prevent TelePresence Conductor from functioning. Also change the root and administrator passwords, and create an API user that Unified CM will use to authenticate in order to access the TelePresence Conductor API. Enable Multiparty Licensing for TelePresence Servers in TelePresence Conductor.

Figure 3-14 shows in detail what elements must be configured within TelePresence Conductor for scheduled and instant conferences that use the TelePresence Server pool.

Figure 3-14 TelePresence Conductor Configuration

Each TelePresence Server in the deployment must be assigned to a bridge pool in TelePresence Conductor. A TelePresence Server can belong to only one bridge pool. Bridge pools must reflect the physical location of the TelePresence Server, and if a bridge pool contains multiple TelePresence Servers, they should all be of a similar size. Each TelePresence Conductor is dedicated to a region; therefore, in this document we assume that all TelePresence Servers are in the same physical location. If there are multiple physical locations, you must configure a location and pool for each one in order to maintain call admission control by Unified CM. As discussed previously, if you are using a dedicated scheduling model, only a single TelePresence Server dedicated for scheduling should appear in a bridge pool, whereas a shared model can have multiple TelePresence Servers in the bridge pool.

A service preference is a prioritized list of bridge pools set up through TelePresence Conductor, and it defines the order for using pools if conference resources are limited. For any particular conference, the administrator can determine the order of preference for the pools that TelePresence Conductor will attempt to use to host that conference. If no TelePresence Servers in the first bridge pool can be used to host a conference (for example, insufficient resources are available to meet the conference requirements), TelePresence Conductor will check the second bridge pool in the list. The scheduled conferences and instant conferences shown in Figure 3-14 all use the same service preference and therefore use the same bridge pool. It is possible that each could use a different service preference and therefore a different bridge pool, or that multiple bridge pools could be defined in a service preference.

A service preference can contain 1 to 30 conference bridge pools, and a single conference bridge pool can be used in any number of service preferences.

As with pools, all TelePresence Servers configured in a TelePresence Conductor service preference must be in the same physical location to ensure that media is always sent to the same physical location and therefore bandwidth usage is understood.

Each SIP trunk between Unified CM and TelePresence Conductor must use a unique IP address. The IP addresses must correspond to the IP addresses configured in the locations within TelePresence Conductor. A location may be dedicated to instant, CMR/scheduled, or both conference types. If both conference types are enabled for a location, that location requires two IP addresses. (Figure 3-15)

Up to 64 IP addresses can be configured on TelePresence Conductor to accommodate many different conference types and locations.

Note Each TelePresence Conductor node must have a unique set of IP addresses.

Figure 3-15 TelePresence Conductor Location and Unified CM IP Addresses

Deployment Tasks for Instant Conferences on TelePresence Conductor

Once IP addresses have been added to TelePresence Conductor, TelePresence Servers have been assigned to bridge pools, and bridge pools have been added to service preferences, you can create the first template for instant conferences. Each template should have the relevant quality settings to provide correct resource usage by participants. For example, the audio template should be set to mono audio only, with no video or content.

Figure 3-16 shows the elements that must be configured to enable instant video conferencing. As illustrated in Figure 3-15, each type of instant service (video and audio) must have a unique location and template.

Figure 3-16 TelePresence Conductor Instant Video Conference Location and Template

Create a unique location for each instant conference template. A single location may be used for both an instant template and scheduled/CMR conferences. For instant conferences, the two most important location configuration parameters are the instant conference template and the IP address dedicated to instant conferences. Unified CM uses this IP address to send requests to TelePresence Conductor to create an instant conference, and TelePresence Conductor uses the template to determine the maximum quality for the created conference.

Deployment Tasks for Scheduled Conferences on TelePresence Conductor

Scheduled conferences are enabled through a template that is configured to allow scheduling. Multiple templates may be configured; for instance, it might be necessary to create a second template configured for multi-screen systems. Each of these templates should have the relevant quality settings to provide correct resource usage by participants.

Figure 3-17 shows the elements that must be configured to enable scheduled conferencing.

Figure 3-17 TelePresence Conductor Scheduled Template

TelePresence Conductor uses conference aliases to choose the relevant conference template for an incoming call to a location. Aliases use Regex and can match based on the dialed number. The incoming number range is limited by the Unified CM route pattern assigned to the SIP trunk using the TelePresence Conductor Rendezvous IP address (configured later). Although Unified CM can point a large range of numbers to the SIP trunk, TelePresence Conductor aliases may be used to divide this range into smaller segments, each of which may use a different template. This is done by using Regex to match only a portion of the number range for each alias.

Create a location within TelePresence Conductor for conferences. A single configured location may be used for both an instant template and scheduled conferences. For scheduled conferences, the most important location configuration parameter is the Rendezvous IP address. Unified CM uses this IP address to send call signaling to TelePresence Conductor for CMR and scheduled calls. To facilitate outbound dialing from TelePresence Conductor, add up to three trunk IP addresses to the location, using Unified CM call processing subscriber node IP addresses that should receive these calls.

To route outbound calls to the correct SIP trunk, assign the relevant location to the bridge pool used for CMR and scheduled conferences.

Summary

After you complete the deployment tasks outlined above, TelePresence Conductor will be ready to add to Unified CM.

4. Enable Unified CM for Scheduled and Non-Scheduled Conferences

This section describes the major tasks required to enable Unified CM for scheduled and non-scheduled conferences.

Overview

Deployment Considerations

Unified CM is the first point of logic that decides how to route a call and that chooses the TelePresence Conductor template used for a conference based on its configuration. Unified CM has different configuration procedures for instant and CMR or scheduled conferences because the mechanism for joining each type of conference is different.

Note The endpoint used to initiate an instant conference must have a conference button. Endpoints that do not have a conference button can still be participants in an instant conference, but they must be added to the conference by an endpoint that has a conference button.

Instant and Permanent Conferences

Figure 3-18 Unified CM Internal Configuration Flow for Instant Conferences

Figure 3-19 Unified CM Internal Configuration Flow for CMR and Scheduled Conferences

Deployment Tasks to Enable Unified CM for Instant Conferences

It is important to understand the relationship between the Unified CM configuration and the TelePresence Conductor configuration. For this deployment two locations were configured in TelePresence Conductor, and in each an Ad hoc IP address was added for instant conferences. Any calls sent to one of these IP addresses uses the conference template configured with it in the location. To route calls correctly, it is important to understand which SIP trunks in Unified CM should point to which IP addresses configured within TelePresence Conductor.

Figure 3-20 Unified CM and TelePresence Conductor Instant Relationship

Each type of instant conference requires a unique SIP trunk and conference bridge configured in Unified CM to communicate with TelePresence Conductor. Each SIP trunk can be used for only one instant conference, and CMR or scheduled conferences require their own SIP trunks. Each TelePresence Conductor node also requires a unique set of SIP trunks and conference bridges.

SIP trunks to TelePresence Conductor require a customized SIP profile in order to support calls in all scenarios. To create the SIP profile, copy the Standard SIP Profile for TelePresence Conferencing and name the copy Standard SIP Profile for TelePresence Conductor, then change the settings as indicated in Table 3-7 .

SIP trunks inform Unified CM where to route SIP traffic. In the case of instant conferences, the SIP trunks also inform Unified CM where to direct API requests, and they are used in the conference bridge configuration. SIP trunks connected to TelePresence Conductor can be configured to be secure; but for the purpose of this guide, they are assumed to be configured as non-secure.

Figure 3-21 Unified CM Instant Configuration

Conference bridge configuration provides two key pieces of information to Unified CM: the API credentials to communicate with TelePresence Conductor and the destination address for that communication. The username and password can be the same for each conference bridge that points to TelePresence Conductor. These credentials should match those configured in the TelePresence Conductor configuration. The SIP trunk configured in the conference bridge indicates to Unified CM where to send HTTP API traffic. Configure each SIP trunk with the settings indicated in Table 3-8 .

Once all conference bridges are configured, they can be added to media resource groups (MRG). Each media resource group should represent one type of instant conference and should contain one conference bridge from each TelePresence Conductor node, so that if communication with one TelePresence node is not possible, then calls can be routed to another node.

Each media resource group can then be added to its own media resource group list (MRGL). The media resource group list can be assigned to devices or the device pool in Unified CM and used when those devices escalate a point-to-point call to a conference call using the conference button.

In total, two MRGLs should be configured: one for instant audio conferences and one for instant video conferences. These two MRGLs should each point to a different location configured within TelePresence Conductor and reference the instant template configured within the location.

Deployment Tasks to Enable Unified CM for CMR and Scheduled Conferences

CMR and scheduled conferences are configured on Unified CM in a similar way to instant conferences, but they require a dial plan to be configured rather than media resources.

Figure 3-22 Unified CM and TelePresence Conductor CMR and Scheduled Relationship

First configure a SIP trunk to connect to TelePresence Conductor, using the relevant IP address configured in the TelePresence Conductor locations created for your deployment. Each TelePresence Conductor node requires a unique SIP trunk. Use the same SIP profile for CMR and scheduled conferences that you created for instant conferences, with the settings indicated in Table 3-8 .

Figure 3-23 Unified CM CMR and Scheduled Configuration

After configuring all the SIP trunks, create a route group for each of them.

Add each route group for a particular conference type into a unique route list. There should be one route list per TelePresence Conductor location. The route list is chosen when a call matches a route pattern that points to it.

To route calls through the relevant SIP trunk to the relevant location within TelePresence Conductor, configure a route pattern for the route list. The route pattern should match with the alias range configured for the required template(s), as indicated in Table 3-9 .

Summary

After you complete the deployment tasks outlined above, Unified CM should be able to communicate with TelePresence Conductor.

5. Deploy TelePresence Management Suite

This section describes the deployment tasks for Cisco TMS for scheduled conferences using TelePresence Conductor.

Overview

Cisco TMS can provide the following services within a conferencing deployment:

• Performs scheduling and conference control functions for scheduled conferences
• Enables the provisioning and monitoring of personal collaboration meeting rooms (CMRs) in conjunction with TelePresence Conductor (See the section 6. Deploy Cisco Collaboration Meeting Rooms.)
• Manages and allocates resources for CMR Hybrid (See section 6. Deploy Cisco Collaboration Meeting Rooms.)

Deployment Tasks for Cisco TMS High Availability

This section describes the tasks required to deploy Cisco TMS with high availability.

Install and Configure Cisco TMS on Active and Passive Nodes

Cisco TelePresence Management Suite (TMS) should be installed for redundant deployments according to the guidelines in the Cisco TelePresence Management Suite Installation and Upgrade Guide, available at

http://www.cisco.com/c/en/us/support/conferencing/telepresence-management-suite-tms/products-installation-guides-list.html

• Install the application on the primary server.
• Point to the external SQL resource configured in the planning stage.
• Make note of the encryption key.
• Verify basic operation by logging into the web portal and enabling TMS redundancy.
• Install the application on the second server using the encryption key from the first server, and using the same SQL credentials as the first server.

Both servers will access the single SQL database that holds all conferencing and configuration data. In the active and passive node configuration, a single encryption key and certificate are used for both servers. Having this encryption key and certificate on each server allows for all communications from end users to TMS, and from TMS to managed devices, to be done using secure protocols.

Install and Configure Network Load Balancer (NLB)

The specifics of the network load balancing configuration are left to the instructions of the load balancer chosen by the customer. The following are functional requirements that must be configured:

• Forward HTTP, HTTPS, and SNMP traffic to the active node.
• Configure the network load balancer probe to the Probe URL within Cisco TMS.
• Push all traffic to the active node.

The Cisco TMS server sends outbound communications directly to managed devices without routing that traffic through the NLB. However, all return communications from managed devices and all web portal requests must be routed through the NLB. The communication path permits end users and endpoints to use a single address, regardless of which TMS server node is in active mode.

Configure TMS Network Settings to the FQDN of the TMS address configured on the network load balancer. This setting within TMS will populate the address that the managed devices use to initiate communications to TMS. By using a FQDN of tms.company.com that resolves to the load balancer, all inbound traffic from endpoints or end user web clients will be directed through the NLB and resolve to the active node. (See Figure 3-24.)

Figure 3-24 NLB Directs Communications from Managed Devices to the Active TMS Node

Configure File Sharing Between Active and Passive Node Servers

While the SQL database is used for all operational data, some application specific files are stored within the file structure of the host server. These customizable files are added by the TMS application and must be synchronized between the two servers when using a redundant deployment. The files include software and images that can be uploaded to Cisco TMS, and images created by Cisco TMS.

In a default installation the files are located at:

C:\Program Files\TANDBERG\TMS\Config\System\

C:\Program Files\TANDBERG\TMS\Data\GenericEndpoint\

C:\Program Files\TANDBERG\TMS\Data\SystemTemplate\

C:\Program Files\TANDBERG\TMS\wwwTMS\Data\CompanyLogo\

C:\Program Files\TANDBERG\TMS\wwwTMS\Data\ExternalSourceFiles\

C:\Program Files\TANDBERG\TMS\wwwTMS\Public\Data\SystemSoftware\

Use the Distributed File System (DFS) function within the Windows Server operating system to complete this replication process between the two servers. DFS will keep these folds in sync between the two servers when the "Full mesh" configuration is used.

Deployment Tasks for Cisco TMS Basic Configuration

Perform the following additional configuration tasks during the installation of Cisco TMS to make the deployment function as intended in the Preferred Architecture:

• ISDN and IP Zones
• Active Directory Integration, Group Structure, and Users
• System Navigator Folder Structure
• Default Conference Settings
• Default Conference Settings
• Modify Email Templates within TMS

ISDN and IP Zones

Configure additional IP zones for each location that will have conferencing resources.

Each location that has conferencing resources should be identified with a unique IP Zone.

Note Be sure to populate the Prefer IP calls over ISDN to these IP Zones according to your network configuration (see Figure 3-25). By default, all new IP Zones will "prefer" ISDN over IP to all other existing IP Zones. Failure to make this selection could cause a failure in conference configuration by TMS because TMS will not see any way to route calls between zones.

Figure 3-25 Configure IP Zones to Prefer IP Calls over ISDN

Configure any additional ISDN zones.

For each intended ISDN gateway, create an additional ISDN Zone in TMS. This will make endpoints use your intended ISDN gateway for all scheduled calls, as defined in the Collaboration Edge chapter. Each of your ISDN gateways will have a prefix for dialing externally, and that prefix must be configured into TMS.

Active Directory Integration, Group Structure, and Users

Verify that all of the information is correctly entered for your Active Directory service account.

Note Make sure all of your settings for AD connectivity are correct, and test the connection. Other AD interfacing commands within TMS might not display errors, even if AD synchronization is not functioning.

Build a group structure to match your organizational needs using Active Directory Groups.

Three different groups are created by default during the TMS installation:

• Users
• Video Unit Administrator
• Site Administrator

These groups may be modified to meet customer needs, but they cannot be removed. By default, all groups have the same access permissions as Site Administrator.

These default groups are limited to manual entry of users; therefore groups should be imported from Active Directory, and existing Active Directory Groups should be used to manage end user access to TMS functions. Be sure to consider groups for support desk personnel and technical administrators as well as end users who schedule conferences.

For additional information about groups, see the Cisco TelePresence Management Suite Administrator Guide, available at

http://www.cisco.com/c/en/us/support/conferencing/telepresence-management-suite-tms/products-maintenance-guides-list.html

Using the Import from AD feature allows for a single point of end user job function management. When employees are added or removed, or job functions change and organizational Active Directory groups are modified, TMS permissions are automatically updated.

Once you have imported groups from Active Directory, assign appropriate permissions to each group. On the screen that appears, simply uncheck any permissions that you do not want that group to have. Failure to restrict these permissions can result in unintended configuration changes.

Also, be sure to select the appropriate default group for all users.

Note Anyone accessing Cisco TMS will be added automatically to the Users group, and this cannot be unselected. De-select any permissions that the administrator does not want everyone within the organization to have.

Import Users

Once permissions are set for groups, import users using the Synchronize All Users with AD function. Depending upon organization size and number of groups involved, the synchronization can take many minutes to complete.

Note Users will not appear in the list of users until they log into TMS for the first time.

System Navigator Folder Structure

The TMS System Navigator utilizes a folder structure to group devices logically for the administrator. Build a folder structure to match your organization’s physical deployment. These folders are visible only to the administrators, not to end users. Arrange the folders according to the logical flow for your organization. For example, create a folder for each geography, and then create a sub-folder for the infrastructure and another folder for conference room endpoints. Folders within the System Navigator may contain endpoints and/or infrastructure devices that receive connection instructions from TMS.

Default Conference Settings

Before scheduling conferences, the administrator should understand the end user community usage model as well as any endpoint limitations. Important Cisco TMS settings to consider include:

• One Button to Push
• Bandwidth
• Add WebEx to all Conferences
• Allow Participants to Join 5 minutes Early

One Button to Push

One Button to Push enables end users to see a calendar of the day’s meetings for a particular room and to launch the connection to the conference. Cisco TMS gives users 72 hours worth of calendar information per request.

Bandwidth

This setting is per endpoint. Adjust the bandwidth to the desired setting for your network. To allow for HD main channel and maximum resolution of content, the default bandwidth for non-immersive systems should be set to 2048 kbps. Any endpoint that has a lower setting for maximum bandwidth will join at its maximum bandwidth.

Add WebEx to all Conferences

This setting should be selected to provide a full collaboration experience for each meeting. Select the option to set the Method of User Access to WebEx (Username). This setting will cause the username of the person scheduling the meeting to appear in the WebEx portion of the invitation, and it allows the meeting to populate that end user's Jabber or WebEx mobile client agenda.

Allow Participants to Join 5 minutes Early

This setting should be selected to allow for slight variations of end-user time interfaces. Allowing users to join prior to the exact time of the TMS server provides a more consistent end-user experience and prevents end users from receiving an "unable to connect" message if they attempt to connect to a meeting a few minutes before the meeting start time.

Modify Email Templates within TMS

Cisco TMS contains the templates used to notify conference organizers. However, Cisco TMSXE can inject errors, warnings, and informational text into email messages sent by Cisco TMS. These messages can be modified by the administrator. Avoid removing or changing text in curly brackets – for example, {MEETING_TITLE}, {CONTACT_HOST}, and so forth – because these are variables that embed other specific content from the scheduled event.

Look at all email templates to ensure that communications automatically generated by TMS align with your intended procedures. Many of these templates might be rather simplistic and are intended to be enhanced by individual organizations. The templates may be modified using any standard HTML editor.

Deployment Tasks for Cisco TMS for Scheduled Conferences

For Cisco TMS to build scheduled conferences, you must add the needed components into TMS as systems. Unified CM is added to TMS to allow the TMS scheduling mechanisms be aware of the call control entity for all devices. TMS does not control any settings on Unified CM, but it does communicate directly to conference room endpoints managed by Unified CM. (See Figure 3-26.)

Figure 3-26 Cisco TMS Communicates Directly with Unified CM Managed Endpoints

Integrate TelePresence Conductor with TMS

To allow Cisco TMS to perform scheduling and conference control for scheduled conferences, add one TelePresence Conductor node from each TelePresence Conductor cluster. The TelePresence Servers should then be added to Cisco TMS also.

Cisco TMS and TelePresence Conductor must be configured with similar aliases, and these are used by Cisco TMS to determine where a scheduled call is placed. Conferences cannot exceed the size of any single TelePresence Server if cascading is not enabled, which it would not be if you are using a dedicated TelePresence Server deployment.

Add one TelePresence Conductor from each TelePresence Conductor cluster to Cisco TMS. Add them to the appropriate folder and assign them the correct IP zone, using an administrator account configured on the TelePresence Conductor. For each TelePresence Conductor configured in Cisco TMS, set the parameters as listed in Table 3-10 .

After adding TelePresence Conductor, add each TelePresence Server to Cisco TMS in a way similar to the above method for TelePresence Conductor. Once all TelePresence Servers are added, perform a forced refresh on TelePresence Conductor and then on all the added TelePresence Servers.

As part of preparing to install the TelePresence Conductor for scheduled calls, you created conference alias and identified a numeric range for the TelePresence Conductor to use as part of the dial plan and designated in the SIP trunks. Table 3-11 lists the TelePresence Conductor dial plan parameter settings.

Leave all other settings as defaults, and save the configuration to add the TelePresence Conductor to TMS.

Cisco TMS will populate the dial plan numbers provided in the previous steps into both E.164 aliases and SIP URIs. However, the implementation of E.164 logic within TMS differs from its use elsewhere in the Preferred Architecture. TMS associates an E.164 alias with H.323 communication only. It is therefore necessary to adjust the integrated ticket system of TMS to ignore certain warnings for the TelePresence Conductor.

Once the TelePresence Conductor has been added to TMS, adjust the Ticket Filters for this entry by adding the filter for Gatekeeper Mode Off.

Create an alias in Cisco TMS under the TelePresence Conductor tab to use for scheduled calls. As shown in Table 3-12 , the lower settings are visible only after clicking Save because they are read-only.

Create the corresponding alias in TelePresence Conductor. First copy the regular expression generated in Cisco TMS in the alias Regular Expression field under the TelePresence Conductor tab. In the case shown in Table 3-12 , the generated alias would be (8099[^@]*).*.

In TelePresence Conductor, create a new conference alias and configure it as shown in Table 3-13 .

Select the TelePresence Conductor within Cisco TMS and Force refresh of the device. Additional information is then listed under Service Preferences within the TelePresence Conductor tab.

TelePresence Conductor reports the total capacity of a service preference to Cisco TMS. The Capacity Adjustment setting allows you to specify what percentage of the total capacity will be available for scheduling conferences with this Service Preference.

If you are using bridge pools that are reserved only for scheduling, do not change this setting. If, however, instant and CMR conferences share the bridge pools being used for scheduling, setting the percentage to less than 100% reserves capacity for non-scheduled conferences.

It is also possible to set the percentage higher than 100%. If users regularly book more capacity than they use (for example, 10 dial-ins for a conference where only 5 are ever used), you should set the Capacity Adjustment to 120% or higher.

To use the TelePresence Conductor for scheduled calls, you must edit TelePresence Conductor settings within Cisco TMS. H.323 dialing should be disabled in both directions, Allow Booking should be enabled, and SIP dialing should be enabled in both directions.

Previously within the alias in Cisco TMS, a wild card was configured, and the number range used in place of this wild card must be configured so that the scheduled conference number range matches that configured on Unified CM. Edit the Extended Settings of the TelePresence Conductor in Cisco TMS as listed in Table 3-14 . The numeric ID should match the route pattern configured for the trunk to TelePresence Conductor from Unified CM.

It is important to configure Cisco TMS to use TelePresence Conductor for scheduling, otherwise scheduling will fail. In Administrative Tools > Configuration > Conference Settings, edit the settings as shown in Table 3-15 .

Integrate Unified CM with TMS

While Unified CM administers the conference room endpoints for all other aspects of configuration and management, the Unified CM cluster must be added into TMS to allow for booking and connection initiation. To add Unified CM to TMS, perform the following tasks:

• Create an Application User for Cisco TMS within Unified CM
• Add the Publisher for each Unified CM Cluster in Your Environment

Adding multiple Unified CM clusters requires adherence to the dial plan configuration outlined in the Call Control chapter.

Create an Application User for Cisco TMS within Unified CM

This application user allows TMS to communicate with endpoints controlled by Unified CM. This user must be assigned all of the conference room devices within Unified CM that will be scheduled. This user must also be added to a user group just for Cisco TMS, with the following roles:

• Standard AXL API Access
• Standard CTI Enabled
• Standard SERVICEABILITY
• Standard CCM Admin Users
• Standard RealtimeAndTraceCollection

For more information, refer to the Cisco Unified Communication Manager Configuration Guide for the Cisco TelePresence System.

Add the Publisher for each Unified CM Cluster in Your Environment

Adding the Unified CM publisher to TMS makes TMS aware of the call control authority for its endpoints. Without knowledge of Unified CM, the TMS scheduling engine cannot properly utilize the full functionality of your deployment, and connection failures could occur.

Add the publisher by the same method used for other devices, by using the application user you created in the above step for the user name and password when prompted by TMS.

Add Conference Room Endpoints to TMS

Rather than adding devices by IP address or DNS name, use the From List tab and then select Unified CM. Select all the conference room TelePresence devices that you wish to have available through the scheduling interfaces of TMS. Be sure to select the appropriate IP Zone for each endpoint. This IP Zone will be used to select the best TelePresence Server available for the endpoints in any conference. Make sure the DN for each endpoint in Unified CM complies with the E.164 guidelines listed in the Call Control chapter.

Do not add personal TelePresence devices (for example, Cisco TelePresence DX Series endpoints) that will not be scheduled through Exchange as resources to TMS.

Install and Configure TMS Extensions for Microsoft Exchange

Cisco TelePresence Management Suite Extension for Microsoft Exchange (Cisco TMSXE) is an extension for Cisco TelePresence Management Suite that enables videoconference scheduling via Microsoft Outlook, and it replicates Cisco TMS conferences to Outlook room calendars.

This software extension to TMS requires a license key to activate the functionality within TMS. This key must be installed in TMS before installing the TMSXE software. For deployments with more than 50 scheduled endpoints, TMSXE must be installed on its own server or virtual machine instance.

Prerequisites

Before installing Cisco TMSXE, make sure both Outlook and Exchange are already set up so that users are able to book meetings that include room mailboxes (see Figure 3-27). This integration is licensed either by groups of endpoints or as an Application Integration license key. The correct key must be procured and entered into TMS before proceeding with the installation. If both option keys are added, only the Application Integration Package option will be used by Cisco TMS

Cisco TMSXE may use Microsoft Exchange Resources that are either on-premises, Office 365 hosted deployments, or hybrid customer deployments. Consult the Microsoft Exchange administration and deployment guides for any guidelines or recommendations that might apply to specific customer environments.

Figure 3-27 Sample Flow for Scheduling a Conference by an End User

Once the per-system option key has been activated in Cisco TMS, the Allow Remote Bookings setting determines whether each system is using a license. This setting allows the administrator to select which endpoints are able to be booked by end users and consume one of the individual endpoint licenses. This setting is void and hidden if the Application Integration Package option is used.

Before endpoints can be added to Cisco TMSXE, they must be represented by a room mailbox in Exchange. To simplify TMSXE setup, we recommend using the endpoint's Cisco TMS display name as the mailbox name (with any spaces removed). This provides commonality across all methods by which end users would see the system name appear.

Special Notes About Privacy Features of Exchange:

All room mailboxes added to Cisco TMSXE must be configured to handle booking subjects and privacy settings in the same way. This means that the following settings must be applied to either all or none of the mailboxes:

• Delete the subject

We recommend not using this feature so that support staff is able to identify a particular meeting in the Conference Control Center. Also, this will allow the meeting title to appear on the One Button to Push interface of capable endpoints.

• Add the organizer's name to the subject

Use of this setting should be considered very carefully, and will depend upon organizational culture and practices. Keep in mind that if one person schedules meetings for multiple groups, those meetings will be listed by that scheduler's user name and not by the meeting subject, which might be more beneficial. On the other hand, if meetings are scheduled by their respective hosts, then it would be easy to identify "Bob's meeting" instead of remembering the specific meeting title. For most organizations, we recommend not using this setting.

• Remove the private flag on an accepted meeting

While the "private" flag is respected within the Outlook client, it is not supported by Cisco TMS, and meeting subjects will be freely viewable:

– In Cisco TMS

– On endpoints that support the Meetings calendar, if other individuals also have use of a room used for a meeting where the subject title should not be public within the organization. (For example, if a "Merger meeting" for the chief executive is scheduled in a room also used by lower-level employees who would not need to have knowledge of a pending merger, those lower-level employees would be able to see the meeting on a room system calendar.)

– If a booking that has a "private" flag in Exchange has its participants or recurrence pattern modified in Cisco TMS, the "private" flag will be removed when these changes are replicated to Exchange.

Create TMSXE User

• Create a TMSXE user in Active Directory and import that user into TMS.
• In TMS, the user needs to be in a new or existing group with the following permissions enabled under Booking:

– Read

– Update

– Book on Behalf of

– Approve Meeting

Install Certificates

Cisco TMSXE and TMS communicate using HTTPS. The certificate also allows for secure communications between the TMSXE server and the Exchange environment. As with the TMS application server, the same certificate is loaded on both the active and passive nodes of TMSXE, and the certificate DNS entry points to the entry of the Network Load Balance address used for TMSXE.

Run Software Installer

• Be sure to select TMS Booking Service to allow use of WebEx Productivity Tools for scheduling.
• Select the appropriate redundancy option for active or passive nodes.
• Complete the software installation on both active and passive nodes.

Once both the active and passive nodes have been installed, configure the Network Load Balancer with the probe URL for each node.

Configure Cisco TMSXE

• Cisco TMS Connection Information

Configure TMS connection information using the TMSXE account created in Active Directory to allow the TMSXE application to communicate with the TMS application.

• Configure Exchange Web Services

Configure Exchange Web Services (EWS) to allow TMSXE to communicate with the Exchange servers for user and resource mailboxes. The credentials used for this connection are also the same TMSXE credentials used elsewhere.

• Align Exchange and TMS Resources

Align Exchange resources to TMS System IDs. This may be done individually or by using a.csv file as outlined in the Cisco TelePresence Management Suite Extension for Microsoft Exchanged Deployment Guide.

Use of WebEx Productivity Tools for End Users

To provide the best experience for end-user collaboration tool usage, deploy WebEx Productivity Tools for all users. WebEx Productivity Tools for CMR Hybrid allow users to synchronously book and configure:

• CMR Hybrid meetings that include both WebEx and TelePresence
• WebEx-only meetings
• TelePresence-only meetings

The panel provides access to simple and advanced settings for both WebEx and TelePresence, including the option to add call-in and call-out TelePresence participants and to allow WebEx participants to join the meeting ahead of start time.

Note that all organizers must be set up with a WebEx user for Productivity Tools to work, even when booking TelePresence-only meetings.

Detailed instructions on configuration and deployment of WebEx Productivity Tools with TelePresence can be found in Cisco WebEx Site Administration User's Guide, which is available as web help and a PDF file from your WebEx site.

Summary

After you complete the deployment tasks outlined above, Cisco TMS will be configured to communicate with TelePresence Conductor for scheduled conferencing.

6. Deploy Cisco Collaboration Meeting Rooms

This section describes the major tasks required to deploy Cisco Collaboration Meeting Rooms (CMR).

Overview

Deployment Considerations

Cisco Collaboration Meeting Rooms (CMRs) are similar to permanent conferences created in the TelePresence infrastructure that resides in the enterprise's data center. Each CMR has a unique set of video addresses that a user can call into to start a meeting at any time, and the video addresses can be in the format of numeric aliases or SIP URIs. Each CMR can be associated with an individual user and can be created through the user's Cisco TelePresence Management Suite Provisioning Extension (TMSPE) portal.

Cisco CMR provides an easy way for participants to join a conference using TelePresence, regardless of where those participants are located. Everyone dials into the same virtual meeting room from their laptop, telepresence room, desktop endpoint, or mobile device.

Deploying CMR involves the deployment of Unified CM, TelePresence Conductor, and Cisco TMSPE. The following sections describe the high-level process for deploying each component for CMR.

Tip Before starting CMR, decide on the format of the conference aliases (numeric or SIP URI).

Deployment Tasks for Unified CM for CMR

The main function of Unified CM is to handle call routing to and from TelePresence Conductor. Connect Unified CM to TelePresence Conductor with a SIP trunk enabled for Early Offer. (Use the same trunk as previously configured for scheduled conferences: ST_CONDUCTOR_CMR_SCHED.) When a user dials the CMR conference alias, the call is sent to TelePresence Conductor via the SIP trunk. Similarly, TelePresence Conductor can send calls to Unified CM through the SIP trunk for auto-dial participants. The conference alias has two formats: SIP URI or numeric. The dial plan design should include the call routing for both the numeric alias and SIP URI for CMR. For dial plan design details, refer to the Call Control chapter.

Cisco Collaboration Meeting Rooms (CMR) can be created for each individual user, and the CMR numeric alias can be based upon the user's DID number. Table 3-16 shows the CMR numeric alias ranges for a deployment using the dial plan example from Call Control chapter.

For numeric aliases, configure a route pattern for each site that routes to the TelePresence Conductor route list for permanent conferences, as shown in Table 3-17 .

For SIP URIs for CMR, keep the domain part the same as the end user directory URI, and manipulate the user part of the URI; for example, {username}.cmr@ent-pa.com. Using a single domain for both directory and CMR URI dialing simplifies the dial plan design if CMRs are hosted in more than one Conductor system or cluster. In addition, users need to enter only the user part of the URI to enter the CMR, and Unified CM automatically appends the domain part to complete the dialing. This greatly enhances the user experience.

To set up the call routing for the URIs, create an Imported Global Dial Plan Catalog with the Route String cmr.route, for example. Then create a list of CMR SIP URIs for all users in the system (and whenever new users are added to the system), and use the Bulk Administration Tool (BAT) to import the URIs into the global dial plan catalog. After that, configure a Domain Routing SIP Route Pattern with the global catalog's route string that routes to the TelePresence Conductor route list for permanent conferences, as shown in Table 3-18 .

Deployment Tasks for TelePresence Conductor for CMR

TelePresence Conductor should be configured with one or more bridge pools and service preferences. All CMRs created through the Cisco TMSPE portal will be hosted in this TelePresence Conductor. TelePresence Conductor and Unified CM are connected through an Early Offer SIP trunk. The bridge pools and service preferences configured previously in TelePresence Conductor for scheduled conferences can be reused for CMR if you are using a shared resource model. Otherwise, use the bridge pools and service preferences configured previously in TelePresence Conductor for instant conferences for CMR. In addition, create an administrator account with read/write access level and API access enabled inside the TelePresence Conductor. Cisco TMSPE uses this administrator account to access TelePresence Conductor for creating CMRs.

Tip The Aliases and templates configured in TelePresence Conductor are not used by TMSPE; instead, the aliases and templates are configured within TMSPE.

Deployment Tasks for Cisco TMSPE for CMR

Cisco TMSPE, together with Cisco TMS, provides a portal for users to create CMRs, and this requires Cisco TMSPE to be installed and activated in Cisco TMS. Cisco TMSPE enables the administrator to create or import users into one or more user groups that entitle the users to have CMRs. For example, the user groups can match with the groups in Active Directory where the users are members, or the user groups can match with an organization unit (OU) of Active Directory where the users reside. In Cisco TMSPE, create the user groups Executive and Marketing, and import users from Active Directory that belong to the corresponding AD groups. Table 3-19 lists the Active Directory search filters for importing users into user groups. The TelePresence Conductor settings option within TMSPE allows the administrator to specify which TelePresence Conductor will be used for the CMR deployment. For each TelePresence Conductor cluster, the administrator must create only one record pointing to one of the Conductor nodes. The administrator account created in TelePresence Conductor is used here to configure the TelePresence Conductor settings.

A CMR template corresponds to a conference template and a conference alias on TelePresence Conductor. The CMR template allows the administrator to specify the conference attributes (for example, conference quality, content quality, conference PIN, and so forth), conference alias (SIP URI and/or numeric alias), and TelePresence Conductor for CMR creation. Also, the CMR template allows the administrator to assign multiparty licenses (PMP or SMP) to users within the group. Assign one CMR template to each user group to enable users in that group to set up their own CMR through the Cisco TMSPE portal.

When a user creates a CMR, Cisco TMSPE applies the settings that have been defined in the CMR template associated with that user’s group, and it makes a provisioning API call to create the conference on TelePresence Conductor. No further interaction is needed from the administrator.

Note CMRs created by using Cisco TMSPE cannot be modified through the TelePresence Conductor web interface. Conference templates and aliases created by using TelePresence Conductor cannot be modified through Cisco TMSPE.

Summary

After you complete the deployment tasks outlined above, users can log in to their Cisco TMSPE portal to create a CMR and generate the corresponding SIP URI and numeric alias. Users can then dial the SIP URI or numeric alias to start the meeting.

7. Deploy Collaboration Meeting Rooms (CMR) Hybrid

This section describes the major tasks required to enable Cisco CMR Hybrid.

Overview

Deployment Considerations

Cisco CMR Hybrid provides the following key features:

• Two-way video with up to 720p screen resolution between the WebEx application and telepresence devices
• Integrated audio and presentation sharing, including application and desktop content sharing capability for all users in a meeting
• Network-based recording of meetings, including content sharing, chat, and polling
• Integrated conference scheduling using Cisco TelePresence Management Suite (Cisco TMS), which enables users to easily schedule Cisco CMR Hybrid meetings
• Secure call control and connectivity enabled by media encryption provided by Cisco Expressway-E
• Management and conference resource allocation of TelePresence Servers provided by Cisco TelePresence Conductor
• Interoperability with third-party telepresence devices

Each user who will schedule Cisco CMR Hybrid meetings in Cisco TMS, must have a host account on the WebEx site.

Tip We recommend using WBS29 or later version of Cisco WebEx Meeting Center for CMR Hybrid deployments.

CMR Hybrid can be deployed using either SIP audio or PSTN audio. It can be scheduled either by using integration to Microsoft Outlook, using the Cisco Smart Scheduler, or using the Cisco WebEx Scheduling Mailbox.

Deployment Tasks for TelePresence Conductor for CMR Hybrid

The previously configured TelePresence Conductor and alias for scheduled conferences can be used for CMR Hybrid conferences.

Deployment Tasks for Unified CM for CMR Hybrid

The previous configuration to enable Unified CM to communicate with Cisco Expressway and TelePresence Conductor for scheduled conferences, is also valid to enable communication with CMR Hybrid. One additional configuration is required to ensure calls made from TelePresence Conductor to the WebEx site are routed correctly: configure a SIP route pattern that matches the WebEx site (for example, yoursite.example.com) to route to the Expressway-C route list.

Deployment Tasks for Expressway for CMR Hybrid

Cisco Expressway-E must have a server certificate that is signed by specific Root Certificate Authorities and that trusts both the DST Root CA certificate for the WebEx cloud and the CA certificate of the CA that issued the server certificate. For a list of supported Root CAs, refer to the Cisco Collaboration Meeting Rooms (CMR) Hybrid Configuration Guide, available at

http://www.cisco.com/c/en/us/support/conferencing/telepresence-management-suite-tms/products-installation-and-configuration-guides-list.html

Configure a new DNS zone on the Expressway-E that has TLS verify enabled and that uses sip.webex.com as the TLS verify name. Configure a search rule to point to this DNS zone that matches the WebEx domain.

Caution Do not use static NAT with Expressway-E, due to a defect that will cause the media part of a call to fail. If static NAT is required, refer to the recommended workarounds in the Cisco Collaboration Meeting Rooms (CMR) Hybrid Configuration Guide.

---

Deployment Tasks for Cisco TMS for CMR Hybrid

To benefit from Cisco CMR Hybrid, connections must be made to the organization's WebEx site. Verify that the settings in Table 3-20 have been made within TMS.

The settings in Table 3-20 allow TMS to communicate with the organization's WebEx site on behalf of the end user during scheduling. By automatically adding WebEx to every conference, even if the administrator needs to generate a meeting through methods other than WebEx Productivity Tools, a WebEx link will be made available to end users. The SSO settings allow end users to use a single set of credentials to access all collaboration services, because WebEx services are able to leverage AD credentials for end users to access WebEx tools.

Add the WebEx site to Cisco TMS to initiate the connection to the site.

To schedule meetings using Cisco TMS, users must have a username and password that the server is configured to trust. Users from Active Directory are trusted but must have the following information stored in their Cisco TMS user profile:

• WebEx username
• WebEx password (unless single sign-on is enabled)
• The WebEx site on which they have an account.

Deployment Tasks for Cisco TMSXE for CMR Hybrid

To allow all client types to use Cisco TMSXE to book meetings, enable the following two options for scheduling CMR Hybrid conferences using Cisco TMSXE:

• Using the WebEx Productivity Tools Plug-In for Microsoft Outlook

Users add WebEx to their meeting by using the WebEx Meeting Options panel in Microsoft Outlook.

• Using WebEx Scheduling Mailbox

Users add WebEx to their meeting invitation directly from their email client by including a special invitee: the WebEx mailbox.

The TMSXE booking service should be configured as normal.

Meeting organizers who want to schedule meetings using the WebEx and TelePresence Integration to Outlook plug-in, must download and install the WebEx Productivity Tools with TelePresence from the WebEx site.

To enable a WebEx scheduling Mailbox, create a new user mailbox in Microsoft Exchange that is used as a scheduling participant whenever a meeting is enabled for CMR Hybrid. Turn off the Calendar Attendant for this mailbox, and disable the AddNewRequestsTentatively setting to prevent new requests from being marked as tentative. Also disable the AD User associated with the account.

Configure the new mailbox in TMSXE as the WebEx Scheduling Mailbox so that TMSXE knows which account to monitor for CMR Hybrid bookings.

Deployment Tasks for Audio for CMR Hybrid

CMR Hybrid supports the following audio connection options, and the choice of method depends on customer preference:

• SIP audio:

– Configure the WebEx site in Cisco TMS to use SIP audio.

– Enable hybrid mode on the WebEx Site.

• PSTN audio:

– Configure the WebEx Site in Cisco TMS to use PSTN audio.

– Enable hybrid mode on the WebEx site (optional).

– Configure PSTN calls to pass through a PSTN gateway to WebEx.

• TSP audio:

– Configure the MACC Domain Index and Open TSP Meeting Room WebEx settings.

– Configure the TSP dial string.

– Configure how the conference is opened.

– Configure TSP audio for the meeting organizer.

Deployment Tasks for WebEx Site Administration for CMR Hybrid

Configure the WebEx Site to enable CMR Hybrid to function. The key settings are:

• Allow Cisco WebEx OneTouch meetings (Meeting Center only)
• Cisco TMS booking service URL
• List Cisco TelePresence meetings on calendar
• Send invitation email to meeting host
• Display toll-free number to attendees
• Set the VoIP and video connection to Automatically encrypted UDP/TCP SSL.
• The relevant audio settings based on the desired audio connectivity

The Meeting Center TelePresence session type must be assigned the host accounts in the WebEx Site to complete the setup. This can be done either by opening the Edit User screens for an individual user or by selecting the appropriate session type for each user from the Edit User List screen.

Summary

After you complete the deployment tasks outlined above, CMR Hybrid should be ready for users to create TelePresence and CMR Hybrid meetings.