Cisco Preferred Architecture for Enterprise Collaboration 10.x, CVD

Cisco Preferred Architecture for Enterprise Collaboration 10.x, CVD

C H A P T E R

3

Conferencing

Revised: January 22, 2015

This chapter describes the components and deployment of video and audio conferencing in an enterprise deployment. The chapter describes the

Architecture for conferencing and then outlines the major tasks

involved in the Conferencing Deployment Process .

Each major task of the

Conferencing Deployment Process starts with an Overview section listing the

steps required for that task, followed by a section on the important Deployment Considerations for that task, and then a section (or sections) detailing the deployment tasks listed in the Overview section.

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

Cisco Preferred Architecture for Enterprise Collaboration 10.x

3-1

January 22, 2015

Chapter 3 Conferencing

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

.

Table 3-1 Types of Conferences

Conference Type

Instant conferences

Description

Manually escalated from a point-to-point call hosted on Unified CM, to a three-party call hosted on a conference bridge. (Also referred to as ad hoc conference.) Instant conferences are not scheduled or arranged prior to the conference.

Permanent conferences Predefined addresses that allow conferencing without previous scheduling.

The conference host shares the address with other users, who can call in to that address at any time. (Also referred to as meet-me, static, or rendezvous conferences.) Permanent conferences covered in this chapter use Cisco

Personal Collaboration Meeting Rooms.

Scheduled conferences Conferences booked via Cisco TMS and/or integration using Cisco TMS with a start and end time, optionally with a predefined set of participants.

Cisco Personal

Collaboration Meeting

Rooms (CMR)

Permanent conferences that are provisioned from Cisco TMS with a portal to allow users to manage items such as their conference name, layouts, and

PIN.

Cisco CMR Hybrid

(formerly, WebEx

Enabled TelePresence)

Personal Multiparty

Similar to scheduled conferences, but with a link to Cisco WebEx Meeting

Center to allow TelePresence and WebEx participants to join the same meeting and share voice, video, and content.

Personal Multiparty involves a user-based licensing approach that provides instant, permanent, scheduled, and CMR conferences that a named host may use for meetings with any number of participants and maximum resolution of 1080p. Personal Multiparty conferences must use TelePresence Servers behind TelePresence Conductor.

3-2

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 3 Conferencing

Architecture

Table 3-2 Alternative Solutions

Solution Type

Cisco WebEx Meetings

Server

Description

Where cloud-based web and audio conferencing is not suitable, it is possible to use the on-premises WebEx Meetings Server solution. This product does not currently offer hybrid conferencing with TelePresence, but it offers a standalone audio, video, and collaboration web conferencing platform.

Cisco CMR Cloud Cisco CMR Cloud is an alternate conferencing deployment model that negates the need for any on-premises conferencing resources or management infrastructure. It supports standards-based video including TelePresence, audio, and WebEx participants in a single call, all hosted in the cloud.

Architecture

TelePresence Conductor manages the conference bridges for all types of conferences. Use SIP trunks to connect the bridges to the TelePresence Conductor and to connect the TelePresence Conductor to

Unified CM. (

Figure 3-1 )

All XML Remote Procedure Call (RPC) connections that Unified CM uses to control conference bridges via an application programming interface (API) over HTTP also go through the TelePresence Conductor.

Cisco TMS also uses XML-RPC connections to link to the TelePresence Conductor for provisioning and

scheduled conference management. ( Figure 3-1

)

The architecture as shown in Figure 3-1

uses SIP exclusively. Conferencing with H.323 endpoints requires interworking by a Cisco Video Communication Server (VCS) or Cisco Expressway-C.

Figure 3-1 Architecture Overview

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

3-3

Chapter 3 Conferencing

Architecture

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.

3-4

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 3 Conferencing

Architecture

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.

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

3-5

Chapter 3 Conferencing

Architecture

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.

3-6

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 3 Conferencing

Architecture

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-provisioningextension/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-programmin g-reference-guides-list.html

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

3-7

Chapter 3 Conferencing

Architecture

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

3-8

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 3 Conferencing

Architecture

Table 3-3 Dedicated versus Shared TelePresence Server Resources

Type of

Resource Deployment Details

Dedicated Service preference: Dedicated

TelePresence Server pool for scheduled conferences.

Single pool, with a single

TelePresence Server in the pool.

Pool marked to be used for scheduling in the TelePresence

Conductor Service Preference. Pool is reported to TMS in capacity information requests.

Service Preferences can optionally have a non-scheduled bridge pool for high availability, which contains additional dedicated TelePresence

Server resources. (For more

information see High Availability for Conferencing, page 3-11

.)

Advantages Disadvantages

By dedicating conferencing resources to scheduled conferences, there is no risk of non-scheduled conferences using resources and, provided that enough resources are provisioned, causing scheduled conferences to fail due to lack of resource availability.

Takes up a TelePresence Server exclusively for scheduling.

Non-scheduled conferences would need to use a different TelePresence

Server.

Inefficient use of conferencing resources when users use more non-scheduled conferencing over a given period. More resources are necessary to handle the fluctuation in usage patterns.

Benefits of optimized resources are negated because no non-scheduled conferences can use the available resources.

Cascaded conferencing does not occur. And to avoid wasting resources, cascading should be disabled.

Shared Service preference: Shared-use

TelePresence Servers for scheduled and non-scheduled conferences.

One or more pools shared for scheduled and non-scheduled conferences.

More efficient utilization of resources. When users use more or fewer scheduled resources, there is no impact on the number of resources left idle, as can happen with dedicated resources that are not used.

Conference resources are not guaranteed to be available for scheduled conferences because non-scheduled conferences could use up all of the resources. Ensuring that enough resources are provided to service high utilization can reduce this risk.

Cascaded conferencing is available

(if enabled).

One or more Service Preferences.

Each Service Preference has all bridge pools enabled for scheduling within TelePresence Conductor and can contain multiple TelePresence

Server conference bridges. Service

Preferences can optionally have a non-scheduled bridge pool for high availability that contains additional dedicated or shared TelePresence

Server resources. (For more

information see High Availability for Conferencing, page 3-11

.)

Targeted management of

TelePresence Server resources is possible.

Non-scheduled conferences are able to use resources available due to resource optimization of scheduled conferences where this occurs.

Over time, monitoring of use patterns can identify the most appropriate pool configuration.

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

3-9

Chapter 3 Conferencing

Architecture

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-installationguides-list.html

3-10

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 3 Conferencing

Architecture

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

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

3-11

Chapter 3 Conferencing

Architecture

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), page 5-33

.

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.

3-12

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 3 Conferencing

Conferencing Deployment Process

Conferencing Deployment Process

To deploy the conferencing solution, perform the following major tasks in the order listed here:

1. Plan the Conferencing Deployment

2. Deploy TelePresence Servers

3. Deploy TelePresence Conductor

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

5. Enable TelePresence Management Suite for Conferencing

6. Deploy Cisco Collaboration Meeting Rooms

7. Deploy WebEx and Collaboration Meeting Rooms (CMR) Hybrid

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.

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

3-13

Chapter 3 Conferencing

Conferencing Deployment Process

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 Tasks for TelePresence Servers :

1.

2.

3.

Install an encryption feature key.

Create a new API access user for TelePresence Conductor to use.

Enable the HTTPS and Encrypted SIP (TLS) services, and disable H.323 services.

4.

5.

Set SIP settings to Call Direct and use TLS, and disable H.323 gatekeeper registration.

Set the server to remotely managed mode, if it has that option, and reboot.

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

3-14

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 3 Conferencing

Conferencing Deployment Process

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.

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

3-15

Chapter 3 Conferencing

Conferencing Deployment Process

3. Deploy TelePresence Conductor

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

Overview

Deployment Tasks Common to Instant and Scheduled Conferences on TelePresence Conductor :

1.

Create an API user in TelePresence Conductor.

2.

3.

Create a Shared Personal Multiparty bridge pool and add the TelePresence Servers to the bridge pool. In the case of a dedicated model, create several bridge pools and add one TelePresence

Server to each bridge pool.

Create a Personal Multiparty service preference and add the bridge pool(s) to the service preference.

4.

Assign one IP address to TelePresence Conductor for each conference type:

Instant audio Personal Multiparty conferences

Instant video Personal Multiparty conferences

CMR and scheduled Personal Multiparty conferences

Repeat this process on each TelePresence Conductor node in the cluster. Each node requires a unique set of IP addresses.

Deployment Tasks for Instant Conferences on TelePresence Conductor :

5.

To configure TelePresence Conductor for instant conferences, create a template for each conference type:

Instant audio Personal Multiparty template

Instant video Personal Multiparty template

6.

In video template, set Optimize resources to yes.

Create a unique location for each instant conference template. Only one template can be assigned per location:

Instant audio Personal Multiparty location

Instant video, CMR, and scheduled Personal Multiparty location

7.

Assign the relevant instant template to the relevant location, and assign an Ad hoc IP address to each. Each Ad hoc IP address is used by Unified CM to communicate with TelePresence

Conductor via SIP and the API.

3-16

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 3 Conferencing

Conferencing Deployment Process

Deployment Tasks for Scheduled Conferences on TelePresence Conductor

:

8.

Edit the previously created instant video, CMR, and scheduled Personal Multiparty location.

Change its type to Both and assign it a Rendezvous IP address. The Rendezvous IP address is used by Unified CM to communicate with TelePresence Conductor via SIP.

Using Unified CM call processing subscriber node IP addresses, add up to three trunk IP addresses to the instant video, CMR, and scheduled Personal Multiparty location.

9.

Edit the previously created bridge pool(s), and assign the Personal Multiparty location to the

Shared Personal Multiparty bridge pool. If there is more than one pool, add the same location to every pool.

10.

To configure TelePresence Conductor for scheduled conferences, create template:

Scheduled Personal Multiparty 720p HD video template

Assign the service preference to the template. In the template, set Optimize resources to yes and set Scheduled conference to yes.

11.

The unique incoming alias for the scheduling template is created during Cisco TMS configuration. Edit the service preference and ensure that the bridge pool has the Pools to use for

scheduling radio button selected. This should be set only on bridge pools that should report their capacity to TelePresence Conductor.

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 )

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

3-17

Conferencing Deployment Process

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

Chapter 3 Conferencing

Instant and Scheduled Conferences

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

3-18

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 3 Conferencing

Figure 3-10

Conferencing Deployment Process

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

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

3-19

Chapter 3 Conferencing

Conferencing Deployment Process

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.

3-20

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 3 Conferencing

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

Conferencing Deployment Process

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.

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

3-21

Conferencing Deployment Process

Figure 3-13

Chapter 3 Conferencing

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.

3-22

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 3 Conferencing

Figure 3-14 TelePresence Conductor Scheduled Template

Conferencing Deployment Process

Summary

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.

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

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

3-23

Chapter 3 Conferencing

Conferencing Deployment Process

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 Tasks to Enable Unified CM for Instant Conferences :

1.

Create a new SIP profile named Standard SIP Profile for TelePresence Conductor.

2.

Create three SIP trunks and point each SIP trunk to the relevant IP address configured in the

TelePresence Conductor location for each type of instant conference:

Instant audio Personal Multiparty SIP trunk

3.

Instant video Personal Multiparty SIP trunk

This step must be repeated for each TelePresence Conductor node. For example, if there are three

TelePresence Conductor nodes, there should be three sets of two SIP trunks configured, one set of two for each TelePresence Conductor node.

Create two conference bridges and add a SIP trunk (configured in task 2) to each. Each conference bridge should contain the relevant trunk:

Instant audio Personal Multiparty conference bridge

Instant video Personal Multiparty conference bridge

Configure each conference bridge with the username and password created on TelePresence

Conductor for API usage.

4.

This step must be repeated for each TelePresence Conductor node. For example, if there are three

TelePresence Conductor nodes, there should be three sets of two conference bridges configured, one set of two for each TelePresence Conductor node.

Create two media resource groups (MRGs):

Instant audio Personal Multiparty MRG

Instant video Personal Multiparty MRG

5.

Add all conference bridges of the matching type (one per TelePresence Conductor node) to the relevant MRG. If you are using three TelePresence Conductor nodes, then each MRG should have three conference bridges in it, each pointing to the same instant template at the relevant IP address on each node.

Create two media resource group lists (MRGLs) and add one MRG to each:

Instant audio Personal Multiparty MRGL

Instant video Personal Multiparty MRGL

To allow an endpoint to use instant conferencing, assign the appropriate MRGL to the device pool or the device itself.

3-24

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 3 Conferencing

Conferencing Deployment Process

Deployment Tasks to Enable Unified CM for CMR and Scheduled Conferences :

6.

Create a SIP trunk and point it to the relevant IP address configured in the Rendezvous IP field in the TelePresence Conductor location:

CMR and Scheduled Personal Multiparty conferences

(ST_CONDUCTOR_PM_CMR_SCHED1-1)

7.

8.

9.

This step must be repeated for each TelePresence Conductor node. For example, if there are three

TelePresence Conductor nodes, there should be three SIP trunks configured, one for each

TelePresence Conductor.

Create a route group:

CMR and Scheduled Personal Multiparty route group (MULTIPARTY_CMR_SCHED)

Add all SIP trunks to the route group. If you are using three TelePresence Conductor nodes, then the route group should have three SIP trunks in it, each pointing to the relevant IP address of each

TelePresence Conductor node.

Create a route list and add the route group to it:

CMR and Scheduled Personal Multiparty route list (RL_PM_CMR_SCHED)

Create a route pattern that matches the scheduled alias configured in TelePresence Conductor created earlier (8099[12]XXX). Further route patterns are required to configure CMR, and they

are discussed in section 6. Deploy Cisco Collaboration Meeting Rooms, page 3-37 .

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

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

3-25

Conferencing Deployment Process

Figure 3-16

Chapter 3 Conferencing

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

3-26

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 3 Conferencing

Conferencing Deployment Process

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 .

Table 3-4 Settings for SIP Profile

Setting

Timer Invite Expires

(seconds)

Early Offer support for voice and video calls

Value

30

Comment

Causes the trunk timer to expire at the same time as

TelePresence Conductor's timer

Best Effort (no

MTP inserted)

This is the recommended configuration for all Unified CM trunks. Best Effort Early Offer trunks never use MTPs to create an Early Offer and, depending on the calling device, may initiate an outbound SIP trunk call using either Early

Offer or Delayed Offer. In the context of this design, outbound calls always use Early Offer.

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.

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

3-27

Conferencing Deployment Process

Figure 3-18 Unified CM Instant Configuration

Chapter 3 Conferencing

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

.

3-28

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 3 Conferencing

Conferencing Deployment Process

Table 3-5

Setting

Name

Description

Device Pool

SIP Trunk Settings for Instant Conferences

Value

ST_CONDUCTOR_ADHOC_AUDIO1-1

Media Resource Group List

AAR Group

Transmit UTF-8 for Calling

Party Name

Trunks_and_Apps

<None>

Default

Checked

Comment

Prefix "ST_" to avoid name collisions with other devices stored in the same table internally.

The remainder of the name identifies the conference type and TelePresence

Conductor node that the trunk points to.

Some meaningful description

Common device pool for central trunks

Use the MRGL defined on the device pool

Same everywhere

This will allow the ASCII Alerting Name to be transmitted to devices that support

UTF-8 characters

PSTN Access

Run On All Active Unified CM

Nodes

Not checked

Checked This settings is recommended on all SIP trunks. It makes sure that outbound calls to

SIP do not require intra-cluster control signaling between Unified CM call processing subscribers.

Inbound Calls

Calling Search Space

AAR Calling Search Space

Outbound Calls

Use Device Pool Called Party

Transformation CSS

Use Device Pool Calling Party

Transformation CSS

SIP Information

Destination

TelePresenceConferencing

PSTNReroute

Checked

Checked

10.X.X.2

As defined in the

Call Control

chapter

SIP Trunk Security Profile

SIP Profile

Non Secure SIP Trunk Profile

Standard SIP Profile for TelePresence

Conductor

TelePresence Conductor audio Ad hoc IP address

Default SIP trunk security profile

Use the SIP profile created above

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.

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

3-29

Chapter 3 Conferencing

Conferencing Deployment Process

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

.

3-30

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 3 Conferencing

Figure 3-20 Unified CM CMR and Scheduled Configuration

Conferencing Deployment Process

January 22, 2015

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

.

Table 3-6

Pattern

8099[12]XXX

Route Pattern for Scheduled Conference Route List

Partition

ESN

Gateway or Route List

RL_PM_CMR_SCHED

Description

Pattern to match scheduled

Personal Multiparty alias range

Cisco Preferred Architecture for Enterprise Collaboration 10.x

3-31

Chapter 3 Conferencing

Conferencing Deployment Process

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

1.

2.

3.

4.

5.

Deployment Tasks for Cisco TMS for Scheduled Conferences

:

Add one TelePresence Conductor from each TelePresence Conductor cluster.

Add the TelePresence Servers behind TelePresence Conductor.

Force refresh of TelePresence Conductor and all added TelePresence Servers.

Create the scheduled alias(es) in Cisco TMS.

6.

7.

Use the regular expression generated by Cisco TMS, and create a conference alias within

TelePresence Conductor. Use the conference template assigned to scheduling earlier in this document.

Force refresh of TelePresence Conductor within Cisco TMS.

8.

Edit the TelePresence Conductor settings within Cisco TMS: select Allow booking and Allow

incoming and outgoing SIP URI Dialing, and disable H.323 dialing in both directions.

Edit the TelePresence Conductor extended settings within Cisco TMS to ensure the numeric quantity is set not to exceed the route pattern range configured within Unified CM.

9.

Edit the Cisco TMS configuration conference settings and set the Preferred MCU Type in

Routing to Cisco TelePresence Conductor.

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.

Cisco Preferred Architecture for Enterprise Collaboration 10.x

3-32

January 22, 2015

Chapter 3 Conferencing

Conferencing Deployment Process

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 .

Table 3-7 Cisco TMS Parameter Settings for TelePresence Conductor

Setting

IP Zone

Username

Value

Region IP zone

TMSadmin

Comment

This setting tells Cisco TMS the physical location of this device

This setting should match the username configured on the TelePresence Conductor

Password

Usage Type

<password>

Other

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.

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

3-33

Chapter 3 Conferencing

Conferencing Deployment Process

Table 3-8 Cisco TMS Alias Settings for TelePresence Conductor

Setting

Name

Alias Pattern

Priority

Description

Prefer for

Multiscreen

Allow Booking

Allow Booking with WebEx

Max Participants per Conference

Max Screens per

Participant

Regular

Expression

Value Comment

Scheduled meeting Give the alias a name; for example, Scheduled meeting.

8099% The pattern can be fixed or can contain a variable, which is denoted by %. The alias pattern must match the route pattern on Unified CM.

Note that the variable part of the alias will be generated by Cisco TMS from the

Numeric ID Base configured for the TelePresence Conductor in Systems >

Navigator > select the TelePresence Conductor > Extended Settings.

1 Give the alias a priority. The alias with the lowest number has the highest priority, and it will be used first when Cisco TMS creates a conference. If that alias has no available resources, the alias with the next highest number will be used, and so on.

Default scheduled conference

No

The priority can be any number between 0 and 65535.

Enter a description of this alias.

Cisco TMS uses aliases with this field checked when selecting aliases for conferences including immersive TelePresence systems. The alias with the highest priority will be chosen first.

Yes

Yes

N/A

N/A

N/A

Service Preference N/A

If all the immersive aliases are in use, a non-immersive alias will be used for the conference

If checked, ensure that the TelePresence Conductor conference template that this alias is configured to use has Allow multiscreen set to Yes.

If No is selected, this alias will not be used by Cisco TMS in any bookings.

This setting could be used if you want to stop using a particular alias that has a number of future bookings and therefore cannot be deleted. Disabling booking by using this setting will enable the alias to be deleted once the final booking has taken place.

Set to Yes to allow this alias to be used in bookings including Cisco Collaboration

Meeting Rooms (CMR) Hybrid.

When booking a conference with this alias, if more than this number of participants is selected, it will not be possible to save the conference.

The number is a theoretical maximum; the actual number of possible participants in a conference could be much lower, depending on how the associated TelePresence

Conductor conference templates are set up.

This field is populated only if there is a corresponding alias on the TelePresence

Conductor.

The maximum number of screens per participant for this alias.

This field is populated only if there is a corresponding alias on the TelePresence

Conductor.

The regular expression of the alias that must be configured on TelePresence

Conductor.

The Service Preference that this alias is linked to.

This field will display None if there is no corresponding alias on the TelePresence

Conductor.

3-34

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 3 Conferencing

Conferencing Deployment Process

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 .

TelePresence Conductor Alias Table 3-9

Setting

Name

Value

Default scheduled meeting

Incoming alias (8099[^@]*).*

Conference name \1

Comment

Give the alias a name; for example, Scheduled meeting.

Paste the regular expression you copied from Cisco TMS.

Enter a regular expression (regex) replacement string that defines how the incoming alias will be modified to result in the conference name; for example, \1.

Entering a static value here will not allow concurrent use of the same alias. Make sure that if your alias pattern has a dynamic part, the regex string you enter here reflects that.

Priority

Conference template

Role type

Allow conference to be created

1

Scheduled

Personal

Multiparty 720p

HD video template

Select one of the conference templates that you assigned for scheduling in the

TelePresence Conductor configuration section.

Participant

Note that the TelePresence Conductor Conference name as defined by this field is unrelated to the Conference Title in Cisco TMS.

Enter the priority for this conference alias. The priority is used when the alias that has been dialed matches more than one conference alias. In such cases, the conference alias with the highest priority (closest to 0) will be used.

No

This setting determines the privileges that will be assigned to a caller dialing in to the conference using this conference alias. The options that are available are determined by the template that has been selected.

This setting determines whether participants dialing this conference alias can create the conference. Scheduled conferences are always created by Cisco TMS and therefore this setting should not be enabled.

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.

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

3-35

Chapter 3 Conferencing

Conferencing Deployment Process

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.

Table 3-10 Extended Settings for TelePresence Conductor

Setting

Numeric ID Base

Numeric ID Step

Numeric ID Quantity

Conference Layout

Limit Ports to Number of

Scheduled Participants

Value

1000

1

1999

Comment

The first number Cisco TMS uses when creating the variable part of the alias. The combination of the non-variable part of the alias and this number will give the dial string used by participants dialing into the scheduled conference; for example, 80991000.

Cisco TMS will add this number to the Numeric

ID Base to avoid duplicated aliases. As conferences finish, the alias will be made available to new conferences.

The number of times Cisco TMS will increase the number from the Numeric ID Base, using the

Numeric ID Step increment. This number should be set so that the highest number does not exceed the allocated range for scheduling: 80991000 to

80992999.

Set the default layout for all conferences.

Default View

Family

On Limit ports to the number of scheduled audio and video participants for all conferences to the number scheduled at time of conference booking.

No additional participants will be able to join conferences.

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

.

Table 3-11 Cisco TMS Conference Settings

Setting

Preferred MCU Type in Routing

Value

Cisco TelePresence

Conductor

Comment

Prefers TelePresence Servers for scheduling over other devices

Summary

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

3-36

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 3 Conferencing

Conferencing Deployment Process

6. Deploy Cisco Collaboration Meeting Rooms

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

Overview

Deployment Tasks for Unified CM for CMR

:

1.

Configure an Early Offer SIP trunk between Unified CM and TelePresence Conductor. The SIP trunk ST_CONDUCTOR_PM_CMR_SCHED1-1 configured previously can be used here.

2.

3.

Set up new route pattern(s) for CMR numeric alias that point to the route list containing the relevant trunks. The route list RL_PM_CMR_SCHED configured previously can be used here.

Create an Imported Global Dial Plan Catalog with the Route String cmr.route, for example, and use the Bulk Administration Tool (BAT) to import CMR SIP URIs into the global dial plan catalog.

4.

Create a SIP route pattern with the global catalog's route string for CMR URI that points to the route list (RL_PM_CMR_SCHED) used in task 2.

Deployment Tasks for TelePresence Conductor for CMR :

5.

Configure one or more bridge pools and service preferences. Use either the same bridge pools used for scheduling if using a shared scheduling model, or create new bridge pools dedicated to non-scheduled conferences if using a dedicated model.

6.

Create an administrator account within TelePresence Conductor with read/write access level and

API access enabled.

Deployment Tasks for Cisco TMSPE for CMR :

7.

Install and activate Cisco TMSPE in Cisco TMS.

8.

9.

Create the user groups Executive and Marketing, and import users from Active Directory who belong to the corresponding AD groups.

Add only a single TelePresence Conductor node from each cluster to TMSPE, using the

TelePresence Conductor setting option.

10.

Create CMR templates that define the conference settings and conference alias, and change the default settings as required.

11.

Assign a CMR template to each user group that entitles the users to have CMRs.

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.

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

3-37

Chapter 3 Conferencing

Conferencing Deployment Process

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.

Table 3-12

Site

SJC

RTP

RCD

CMR Numeric Alias Ranges

+E.164 DID Range

+1 408 555 4XXX

+1 919-555 1XXX

+1 972 555 5XXX

CMR Numeric Alias Range

8-004-4XXX

8-005-1XXX

8-006-5XXX

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 .

Table 3-13 Route Patterns Configuration for CMR Numeric Alias

Pattern

80044XXX

80051XXX

80065XXX

Partition

ESN

ESN

ESN

Gateway or Route List Description

RL_PM_CMR_SCHED Pattern to match SJC DID range

RL_PM_CMR_SCHED Pattern to match RTP DID range

RL_PM_CMR_SCHED Pattern to match RCD DID range

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}[email protected] 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

3-38

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 3 Conferencing

Conferencing Deployment Process

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 .

Table 3-14

Pattern

cmr.route

SIP Route Pattern Configuration for CMR URI

Partition

URI

Gateway or Route List

RL_PM_CMR_SCHED

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.

Table 3-15

User Group

Executive

Marketing

Search Filter for Importing Users into User Groups

Search Filter

(&(objectClass=user)(memberof=cn=executive, ou=enterprise, dc=ent-pa, dc=com))

(&(objectClass=user)(memberof=cn=marketing, ou=enterprise, dc=ent-pa, dc=com))

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

3-39

Chapter 3 Conferencing

Conferencing Deployment Process

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.

3-40

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 3 Conferencing

Conferencing Deployment Process

7. Deploy WebEx and Collaboration Meeting Rooms (CMR) Hybrid

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

Overview

Deployment Tasks for TelePresence Conductor for CMR Hybrid

:

1.

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

:

2.

Configure a SIP route pattern that matches the WebEx site and points to the Expressway-C route list.

Deployment Tasks for Expressway for CMR Hybrid

:

3.

Create a new DNS zone that uses TLS verify, forces encryption, and uses the TLS verify name

sip.webex.com.

4.

Create a search rule that matches any URI that contains the WebEx domain and removes any appended characters.

Deployment Tasks for Cisco TMS for CMR Hybrid

:

5.

Install the WebEx integration option key.

6.

7.

Add the WebEx site to Cisco TMS.

Configure the following attributes in the Cisco TMS user profiles of the users who are enabled to use CMR Hybrid:

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 :

8.

Download and install the WebEx and TelePresence Integration to Outlook plug-in for relevant users.

9.

Configure a WebEx scheduling Mailbox, such as [email protected], with the following settings:

Turn off the Calendar Attendant.

10.

Set AddNewRequestsTentatively to Disabled.

Configure the WebEx scheduling mailbox inside TMSXE so that TMSXE monitors this mailbox for CMR Hybrid bookings.

Deployment Tasks for Audio for CMR Hybrid :

11.

Chose the best audio connection type for the deployment requirements, and enable the relevant settings.

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

3-41

Chapter 3 Conferencing

Conferencing Deployment Process

Deployment Tasks for WebEx Site Administration for CMR Hybrid

:

12.

Enable Cisco TelePresence Integration (Meeting Center only).

13.

Configure the following additional settings:

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.

Set relevant audio settings based on the desired audio connectivity.

14.

Assign the Meeting Center TelePresence session type to all users who use CMR Hybrid.

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.

3-42

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 3 Conferencing

Conferencing Deployment Process

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

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

3-43

Chapter 3 Conferencing

Conferencing Deployment Process

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.

3-44

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 3 Conferencing

Related Documentation

Summary

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

Related Documentation

Cisco Personal Multiparty At-A-Glance http://www.cisco.com/c/dam/en/us/solutions/collateral/collaboration/pervasive-conferencing/at-aglance-c45-729835.pdf

Cisco TelePresence Management Suite (TMS) and CMR Hybrid deployment guides http://www.cisco.com/c/en/us/support/conferencing/telepresence-management-suite-tms/productsinstallation-and-configuration-guides-list.html

Cisco TelePresence Conductor and Collaboration Meeting Rooms (CMR) Premises (optimized conferencing) deployment guides http://www.cisco.com/c/en/us/support/conferencing/telepresence-conductor/products-installation-a nd-configuration-guides-list.html

Cisco TelePresence Conductor API guides http://www.cisco.com/c/en/us/support/conferencing/telepresence-conductor/products-programmin g-reference-guides-list.html

Cisco TelePresence Server release notes http://www.cisco.com/c/en/us/support/conferencing/telepresence-server/products-release-notes-list

.html

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

3-45

Related Documentation

Chapter 3 Conferencing

3-46

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement

Table of contents