Portfolio Simplification

This topic describes the simplification of the video endpoint portfolio.

The video endpoints portfolio was simplified and the number of SKUs was reduced from more than 60 to fewer than 20 :

Because customers had difficulties in distinguishing among all the different video endpoints, Cisco simplified the video endpoint portfolio. The figure shows the new video endpoint groupings. For more detail on collaboration endpoints, go to http://www.cisco.com/c/en/us/products/collaboration-endpoints/index.html.

Automated Provisioning with Cisco VCS and TMS

This topic describes how Cisco Jabber Video for TelePresence is autoprovisioned to register with Cisco TelePresence Video Communication Server (VCS).

  1. Administrator imports users from Active Directory and creates provisioning profiles.
  2. Provisioning extension (PE) replicates the provisioning data to the cluster and Cisco TMS emails the account credentials to users.
  3. VCS challenges users for credentials. When authenticated, endpoint receives provisioning profile by a SIP notify message.

The figure shows how Cisco Jabber Video for TelePresence autoregisters. Note that users can also be configured manually.

In addition to Step 3, where the client successfully registers with Cisco VCS, the following happens:

  • The endpoint registers to a Cisco VCS per the provisioning profile and the endpoint is ready for SIP calls.
  • The endpoint subscribes to Cisco VCS for directory services.

Provisioning extension characteristics are as follows:

  • Provisioning of Cisco Jabber Video endpoints has evolved from provisioning agent to provisioning extension.
  • Provisioning extension is the only method for newer endpoints such as the EX series, C Series, and Cisco Jabber Video starting in Cisco TelePresence Management Suite (TMS) Release 14.1 and later.
  • Provisioning extension is a feature activated on the Cisco TMS server and stores endpoint configuration data in an SQL database.
  • Endpoints send SIP subscribe messages to the VCS, which retrieves the data from the Cisco TMS provisioning extension database and provides those settings to the endpoint.

DNS SRV Records

This topic describes the DNSSRV for Cisco Jabber Video for TelePresence registration inside and outside the enterprise.

  • DNS service records, defined in RFC 2782, are a method to define a DNS record for a service instead of a specific host.
  • The DNS SRV record resolves to one or more hostnames of servers and port numbers where the desired service may be found.
  • Can be used to implement location-specific registration behavior.

Internal DNS records: Load balancing for endpoint registrations to VCS-C cluster

_service._protocol.domain TTL  class SRV priority weight port target 
_sip._tcp.clustername.internal.com. 86400 IN SRV 10 60 5060 server1.cisco.com.
_sip._tcp.clustername.internal.com. 86400 IN SRV 10 60 5060 server2.cisco.com.
_sip._tcp.clustername.internal.com. 86400 IN SRV 10 60 5060 server3.cisco.com.
_sip._tls.clustername.internal.com. 86400 IN SRV 10 60 5061 server1.cisco.com.
_sip._tls.clustername.internal.com. 86400 IN SRV 10 60 5061 server2.cisco.com.
_sip._tls.clustername.internal.com. 86400 IN SRV 10 60 5061 server3.cisco.com.

External DNS records: Provides a single service view to external endpoints and hides server names

_service._protocol.domain TTL  class SRV priority weight port target 
_sip._tcp.express.external.com. 86400 IN SRV 10 60 5060 server1.external.com.
_sip._tcp.express.external.com. 86400 IN SRV 10 60 5060 server2.external.com.

For registration within the enterprise, set up the DNS SRV records for the client to register to the Cisco TelePresence Video Communication Server cluster, where the devices use round-robin registration according to the DNS settings shown in the figure.

For external access, Cisco Jabber Video for TelePresence connects to the Cisco TelePresence Video Communication Server Expressway using firewall traversal.

Cisco Jabber Video for TelePresence (Movi)

This topic describes the Cisco Jabber Video for TelePresence client, which was formerly known as Movi.

Comparison of Cisco Jabber and Cisco Jabber Video

  • Cisco Jabber is a presence- and IM-centric client with rich media functionality.
  • Cisco Jabber Video is a video-centric client that can only be registered with Cisco VCS.

The presence functionality is limited to the Cisco TelePresence Video Communication Server (VCS) cluster and only to video endpoints.

Cisco Jabber requires Cisco Unified Communications Manager and Cisco Unified Communications IM and Presence to register and is a rich media-enabled client.

Cisco Jabber Video for TelePresence is a video-centric client that can only be registered with Cisco TelePresence VCS and can reach other clients on Cisco Unified Communications Manager via a SIP trunk. There is also a cloud-based solution, where you can register the Cisco Jabber Video for TelePresence client as well. Cisco Jabber Video for TelePresence uses the Cisco Precision Video Engine technology, which is also used by the Cisco TelePresence EX60 and EX90 systems.

The software requirements to deploy Cisco Jabber Video for TelePresence are as follows:

  • Cisco TelePresence Video Communication Server
  • Cisco TelePresence Management Suite

The provisioning option must be enabled on both products.

Cisco recommends using the Cisco TelePresence PrecisionHD USB Camera for Cisco Jabber Video for TelePresence on your PC for the best video and audio user experience.

To register, the client needs to locate the provisioning service and register with Cisco TelePresence Video Communication Server. You must set up the following to successfully register Cisco Jabber Video for TelePresence:

  • SIP domain on the Cisco VCS with which the client will register
  • DNS address of the primary Cisco VCS control cluster
  • (Optional) DNS address of a Cisco VCS Expressway cluster

These settings can be preset by the administrator so that users do not have to set these parameters. In fact, if these settings are configured, users cannot change them.

Cisco TelePresence Conductor

his topic describes the Cisco TelePresence Conductor functionality.

  • Improved user experience
    1. Simple to use
  • Maximize reliability
    1. Always available
  • Zero downtime
    1. Extended scale
  • Enhanced conference size
    1. Intelligent resource usage
  • Any-to-any collaboration
    1. Interoperable
    2. Standards-based

Instead of managing the MCUs directly with Cisco TelePresence Video Communication Server (VCS) or Cisco Unified Communications Manager, the MCUs are managed by Cisco TelePresence Conductor. There are two reasons for virtualizing and centralizing MCU management:

  • You can have multiple MCUs, cascade them geographically, and define backup conference resources.
  • Because pervasive video is complex and the call can happen anywhere in the organization, this approach allows optimal resources to be found, depending on the device location.

For example, assume that there are three locations, one each in Asia, Europe, and America. When the Europe conference bridge is fully utilized, users should not get a failure message saying that there are no video resources available, or fall back to audio only. Cisco TelePresence Conductor manages this situation by automatically choosing an underutilized conference bridge, but always using local resources first, based on the location configuration. With preferences set, an overflow situation selects the next best conference bridge. Cisco TelePresence Conductor is best described as a centralized MCU controller.

Cisco TelePresence Conductor is mandatory for the new pervasive conferencing platforms such as Cisco TelePresence Server on a VM and TelePresence Server on the Cisco Multiparty Media 310/320.

Multiparty Conferencing

This topic describes multiparty conference systems.

  • Cisco TelePresence Server and Cisco TelePresence Conductor form a multiparty solution:
    1. Any-to-any device connectivity, from mobile to immersive, bringing together video, web, and voice conferencing
    2. Platforms to suit all deployment scenarios with a common application and industry-leading user experience
  • MCU hardware platforms can run Cisco TelePresence Server software.
    1. Customers migrate when appropriate

*Valid service contract required for installation of TS software on platform; additional screen licenses may be required .

With universal encoding you can optimize the quality for users with different video qualities, for example, in a mixed video conference with participants using 360p, 720p, and 1080p resolution. In addition, the bandwidth is adapted between users with limited and slow Internet lines such as a 1-Mbps connection and users having 100 Mbps and more. Every single connection is transcoded to its best possible quality, forming a multiparty solution.


This topic describes conferencing in general.

Conferencing is used if there are more than two participants:

  • Multipoint meeting is a conference
  • Most often just video terminals (endpoints)
  • Also used in other use cases, for example, call recording
  • Different visual experiences such as Cisco ActivePresence, advanced continuous presence, voice-switched
  • Different conference types such as ad hoc, scheduled, and rendezvous

Conferencing occurs when more than two participants join a meeting with a voice or video device. The challenge is to have a consistent user experience in voice or video conferences and to select the correct conference resource, depending on the device, especially when mixing standard-definition and high-definition video devices.

The Cisco focus for the future is Cisco ActivePresence using Cisco TelePresence Server instead of multipoint control units with many different layouts.

Ad hoc conferences are impromptu meetings. They are not scheduled and do not require an administrator to initiate them. Ad hoc conferences are suitable for smaller, on-the-fly meetings. A point-to-point call that is escalated to a multipoint call is considered an ad hoc conference.

Rendezvous conferences are also called Meet-Me, permanent, or static conferences. These conferences require that endpoints dial into a predetermined number and are often used for recurring group meetings that involve different endpoints each time.

Scheduled conferences provide a guarantee that endpoints and multipoint resources will be available at a certain time. Endpoints join manually or are automatically connected by the multipoint resource.

Continuous Presence Layouts

  • More than 50 layouts, depending on the MCU

Cisco ActivePresence

  • Up to 9 ActivePresence windows per screen

The Cisco TelePresence MCU 5300 Series, for example, offers more than 50 layouts for continuous presence. All ports on this multipoint control unit also support advanced continuous presence.

The future trend is active presence supported by Cisco TelePresence Server. Cisco ActivePresence capability supports a full-screen immersive view of the primary speaker with an overlay of others who are participating in the call. ActivePresence is designed to maximize the large-scale immersive experience and is available on all ports of the Cisco TelePresence Server. The server interworks with Polycom RPX and TPX telepresence systems while preserving the full Cisco ActivePresence view. Four layout families are provided for single-screen endpoints, including panel-switched Cisco ActivePresence capability.

Up to 9 ActivePresence windows are supported on a single screen at one time. In a triple-screen system, a total of 27 ActivePresence windows are supported.

Dial Plans

This topic describes the dial plans in Cisco Unified Communications Manager and Cisco TelePresence Video Communication Server (VCS).

Two major dial plan types exist:

  • Numeric dial plan
  • Alphanumeric URI dial plan
Address Scheme Example Cisco Unified Communications Manager Registration Cisco VCS Registration
E.164 14081234567 Supported as Directory Number (DN) H.323 E.164 Registration
E.164-based URI 14081234567@cisco.com Supported from Cisco Unified Communications Manager 9 and higher Supported H.323 ID and SIP URI
Alphanumeric URI john.doe@cisco.com Supported from Cisco Unified Communications Manager 9 and higher Supported H.323 ID and SIP URI

In Cisco Unified Communications Manager, the E.164 or +E.164 numbers are used for call routing. URI dialing is used in the Cisco VCS. Both dial plans are relevant:

  • E.164 addresses allow easy integration with the PSTN and audio-only endpoints.
  • URI addresses allow easier back-to-back communications using domain names and are generally more intuitive for end users.

Cisco Unified Communications Manager and Cisco TelePresence VCS do not share a database, so default routes are required between these systems. As an example, you dial jdoe@cisco.com on Cisco Unified Communications Manager but cannot find the user on Cisco Unified Communications Manager. The call is sent to Cisco VCS via the default route. There are two possibilities now. First, you find a match for jdoe@cisco.com and you extend the call to the user phone. The second option is that Cisco VCS does not find a match and routes the call back. These systems will prevent looping after a certain number of hops.

In the past, E.164 was usually used in voice networks and H.323 and URI were used within SIP networks. In the future, collaboration services, instant messaging (IM), voice, video, and social communication will converge more and more. The endpoints and the infrastructure will need to support both address schemes to support scalable and consistent dialing.

Connecting Cisco Unified Communications Manager and VCS Clusters

This topic describes how Cisco Unified Communications Manager and Cisco TelePresence Video Communication Server (VCS) are connected and how the information flows between these systems.

  • SIP trunk connects Cisco Unified Communications Manager call control with Cisco VCS call control.
  • H.323, SCCP, and MGCP are translated to SIP before being sent to a Cisco VCS call control cluster.
  • Encryption for video is supported.
  • Recently implemented SIP connection features in Cisco Unified Communications Manager help in connecting to Cisco VCS:
    1. Replace IP address with OTLD in call signaling
    2. Support for 80-bit authentication tag for encryption in addition to 32-bit

H.323 = allows dissimilar communication devices to communicate with each other; MGCP = Media Gateway Control Protocol; SCCP = Skinny Client Control Protocol.

With Cisco Unified Communications Manager 10.x, the name or IP address of a server is replaced by the OTLD in outgoing messages, for example, cisco.com. This change allows you to call john.doe@cisco.com instead of dialing john.doe@cucm1.cisco.com. The enhanced security support for 80-bit authentication tags was implemented for military customers to secure video communications.

In connecting Cisco Unified Communications Manager with a cluster of Cisco VCS peers, there are two methods of providing Unified Communications Manager with the addresses of the VCS cluster peers:

  • The trunk to the Cisco VCS specifies the DNS SRV address for the VCS cluster. Each peer should be set with an equal priority and weight in SRV records on the DNS server.
  • The trunk to the Cisco VCS specifies a list of VCS peers as IP addresses. You can also set up multiple SIP trunks to each peer in the VCS cluster. This option is preferred when using flat dial plans.

When connecting Cisco TelePresence VCS to a cluster of Cisco Unified Communications Manager nodes, VCS must be able to route calls to each Unified Communications Manager node. This routing can be done in the following two ways (in order of preference):

  • Route calls using a single neighbor zone in VCS with the Unified Communications Manager nodes listed as location peer addresses.
  • Route calls using DNS SRV records and a VCS DNS zone.

Note that both options ensure that the Cisco VCS-to-Unified Communications Manager call load is shared across Unified Communications Manager nodes.

Call Control Terminology

This topic presents the call-processing terminology for Cisco Unified Communications Manager and Cisco TelePresence Video Communication Server (VCS).

This table presents the terms of the different call-processing systems:

Cisco Unified Communications Manager Cisco VCS
Directory Number (DN) Device ID
Route Pattern Search Rule
Translation Pattern Search Rule or Transform
Trunk Neighbor or DNS Zone
Cisco Unified Mobility FindMe
Locations and Regions Links and Pipes
Ad hoc Conferencing Multiway and Conductor

DNS = Domain Name System

This table helps you distinguish between the terms that are used in the different call-processing systems.