Cisco Preferred Architecture for Enterprise Collaboration 10.x, CVD - April 2015

What’s New in This Chapter

This chapter has been revised extensively for Cisco Collaboration System Release (CSR) 10.6. In particular, the recommended deployment for scheduled conferences has changed from directly managed TelePresence Servers to TelePresence Servers managed by TelePresence Conductor. We recommend that you read this entire chapter before attempting to deploy conferencing in your collaboration solution.

Core Components

The core architecture contains these key conferencing elements:

• Cisco TelePresence Server for audio and video conference resources
• Cisco TelePresence Conductor for audio and video resource management
• Cisco TelePresence Management Suite (TMS) for conference provisioning, monitoring, and scheduling
• Cisco WebEx Software as a Service (SaaS) for scheduled audio and web conferences and hybrid video and web conferences

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
• Resilience in the video network

Conference Types

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

Role of the TelePresence Conductor

TelePresence Conductor manages the TelePresence Server resources for all types of conferences. It selects which TelePresence Server or bridge pools to use 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.

Using TelePresence Conductor for conferences 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

In certain cases 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 allows more concurrent connections to take place. For more information, see the TelePresence Server release notes.

Role of Cisco TMS

For scheduled conferences, Cisco TMS performs conference scheduling and conference control 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.

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.

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-2) TelePresence Servers are used to bridge calls, and Cisco TMS provides conference management facilities and scheduling.

Figure 3-2 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.
• 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-3 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 may be the same as the 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-3 .

• 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-4). Optionally, a second bridge and pool combination can be used as a backup.

Figure 3-4 Dedicated Scheduling TelePresence Server

• Shared TelePresence Servers — Allow TelePresence Servers to be used for non-scheduled as well as scheduled conferences (Figure 3-5). 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-5 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

Cisco does not recommend using Multiway (the Cisco VCS method of instant escalation) in this deployment. Multiway should be used only in Cisco VCS-only deployments. In Unified CM deployments as described in this document, the conference button escalation method should be used 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.

Configuration Information

For guidance on using Cisco TMS to schedule conferences, see the section on Conference Scheduling with Cisco TelePresence Management Suite (TMS) in the Core Applications chapter.

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.

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.

Note There are two other models of TelePresence Conductor that are not discussed in this document: TelePresence Conductor Select supports two Conductor nodes in a cluster, but TelePresence Conductor Essentials does not support clustering.

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 of Unified CM and Cisco TMS, including TMSPE, is discussed in the section on Conference Scheduling with Cisco TelePresence Management Suite (TMS).

This document assumes that audio conferences are scheduled utilize the WebEx Cloud and therefore have 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

This solution does not use media and signaling encryption; instead, non-secure SIP trunks are implemented 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 the encryption feature key must be installed on TelePresence Servers and 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 TelePresence Servers available or increasing the number of connections a TelePresence Server can support by adding licenses.

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. For example, if three Unified CMs exist, then three TelePresence Conductor clusters should be deployed, 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 MSE 8710 blade can be used. The MSE 8710 supports up to four blades in a cluster, which increases the capacity of the MSE 8710 up to four times. 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 requires the WebEx Integration key to be installed for CMR Hybrid.
• For purposes of this guide, TelePresence Servers are licensed using Personal Multiparty Advanced.
• A full version of TelePresence Conductor comes with the required licenses installed.

Personal Multiparty is a user-based licensing model with two variations: Basic and Advanced. This guide considers only the Advanced option. Each license entitles a user to a conference space for any number of participants with up to 1080p video quality. Two Full Conductor Licenses are included with a Personal Multiparty Advanced order. A TelePresence Conductor cluster is used to provision Personal Multiparty conferences. TelePresence Servers must be dedicated for use with Personal Multiparty licensing. TelePresence Servers licensed with Personal Multiparty do not require screen licenses to be purchased (although licenses received through Personal Multiparty licensing must still be applied to the devices).

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 encryption feature key. The encryption feature key is required for TelePresence Conductor to communicate with the TelePresence Server; unencrypted communication is not supported.

Instant, Permanent, and Scheduled Conferences

Figure 3-6 Instant Conference Call Flow

Figure 3-7 Permanent or Scheduled Conference Call Flow

Deployment Tasks for TelePresence Servers

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

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-8)

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

Instant and Scheduled Conferences

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

Figure 3-10 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.

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

Figure 3-11 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-11 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-12)

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-12 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-13 shows the elements that must be configured to enable instant video conferencing. As illustrated in Figure 3-12, each type of instant service (video and audio) must have a unique location and template.

Figure 3-13 TelePresence Conductor Video Screen License Location and Instant 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-14 shows the elements that must be configured to enable scheduled conferencing.

Figure 3-14 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 Personal Multiparty 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-15 Unified CM Internal Configuration Flow for Instant Conferences

Figure 3-16 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-17 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-4 .

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-18 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-5 .

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 Personal Multiparty conferences and one for instant video Personal Multiparty 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-19 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-5 .

Figure 3-20 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 to the relevant SIP trunk and therefore 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-6 .

Summary

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

5. Enable TelePresence Management Suite for Conferencing

This section describes the major tasks required to configure Cisco TMS to schedule conferences using TelePresence Conductor.

Overview

Deployment Considerations

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

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

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.

Deployment Tasks for Cisco TMS for Scheduled Conferences

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-7 .

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.

Create an alias in Cisco TMS under the TelePresence Conductor tab to use for scheduled calls. As shown in Table 3-8 , 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-8 , the generated alias would be (8099[^@]*).*.

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

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 could 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-10 . 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-11 .

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_PM_CMR_SCHED1-1.) 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-12 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-13 .

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-14 .

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-15 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. 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 WebEx and 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 as the minimum version for 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

First install the WebEx integration option key on Cisco TMS; without this key it is not possible to schedule CMR Hybrid meetings. 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.