-
Cisco TelePresence Network Systems 2.0 Design Guide
-
Cisco TelePresence Solution Overview
-
Connecting the Endpoints
-
TelePresence Network Deployment Models
-
Quality of Service Design for TelePresence
-
Campus QoS Design for TelePresence
-
Branch QoS Design for TelePresence
-
Call Processing Overview
-
Capacity Planning and Call Admission Control
-
Call Processing Deployment Models
-
Cisco TelePresence Multipoint Solution Essentials
-
Cisco Multipoint Technology and Design Details
-
Cisco TelePresence Multipoint Solution Circuit and Platform Recommendations
-
Internal Firewall Deployments with Cisco TelePresence
-
Cisco Services for Cisco TelePresence
-
Table Of Contents
Cisco TelePresence Multipoint Solution Essentials
Overview of Multipoint Conference Technologies
Components of the Cisco TelePresence Multipoint Solution
Multipoint Virtual Meetings Which Include Only CTS Endpoints
Multipoint Virtual Meetings Which Also Include Traditional Video Conferencing Systems
Cisco TelePresence Multipoint Switch Overview
Geographical Resource Management
Cisco TelePresence Multipoint Solution Essentials
Overview of Multipoint Conference Technologies
This section briefly discusses some of the methods and technologies used to currently provide multipoint conferencing.
Figure 10-1 shows the simplest form of multipoint conferencing in which each video endpoint (also known as a video terminal when referring to H.323 based-systems) simply sends unicast video and audio streams to every other video endpoint in the multipoint call.
Figure 10-1 Multipoint Conferencing Using Point-to-Point Unicast Streams
This form of multipoint video conferencing has limited scalability. Each endpoint has to mix the audio and video from every other endpoint in order to determine which video stream to display at any given time. Alternatively, the endpoints may display video from each of the other endpoints in a small section of the display, for example four or eight boxes of video. Audio must still be mixed at the video endpoint and played out on the speaker(s). The addition of each new video endpoint results in every other endpoint having to both send and receive a new video and audio stream. For a conference of N video endpoints, each endpoint has to both send and receive N-1 unicast video and audio streams. Bandwidth utilization is somewhat inefficient for this reason.
Figure 10-2 shows a second form of multipoint conferencing in which an endpoint multicasts its video and audio stream to every other endpoint in the multipoint call.
Figure 10-2 One-Way Multipoint Conferencing Using a Multicast Stream
This form of multipoint conferencing requires multicast friendly media, such as a LAN/WAN infrastructure which is IP multicast enabled. It is not possible to implement this over point-to-point media such as ISDN. Typically this form of video conferencing is used for one-way multipoint conferences, with a single endpoint functioning as the "presenter" and the remaining endpoints functioning as the "audience." The presenter may have a camera, but no video display. Likewise the audience may have video displays, but no cameras. A unicast data path or audio stream (often through a voice conferencing bridge) is sometimes utilized to allow the audience to ask questions and provide feedback to the presenter.
Full two-way video conferencing using IP multicasting is not extensively utilized. Each video endpoint would need to multicast to a separate IP address to achieve this. Although less inefficient in terms of network utilization than point-to-point unicast streams, it suffers from the same scalability issue in that each video endpoint has to mix the audio and video streams from every other endpoint in order to determine which video stream to display at any given time.
Figure 10-3 shows a third form of multipoint conferencing in which each video endpoint sends unicast audio and video streams to a centralized multipoint switch or multipoint control unit (MCU).
Figure 10-3 Multipoint Conferencing Using a Multipoint Switch / MCU
The multipoint switch/MCU mixes the audio and video streams from each video endpoint and transmits a single audio and video stream back to each endpoint. It should be noted that if multiple displays or speakers exist at an endpoint, multiple video and audio streams may be sent by the multipoint switch/MCU to that endpoint.
If audio or video transcoding or transrating are required, a more traditional MCU function can be deployed which decodes and re-encodes the audio or video streams to each endpoint. This can lead to somewhat higher latency (end-to-end delay) of the audio and video. When transcoding or transrating are not required—as with the Cisco TelePresence solution—a multipoint switch which simply mixes and switches audio and video streams to each endpoint can be deployed. This leads to much lower latency. Since the mixing and potentially transcoding or transrating functionality has been offloaded to the multipoint switch/MCU, scalability can be greatly enhanced by deploying custom-built platforms for this functionality. Enhancements to this technology also make use of voice activity switching, in which voice activity from the audio streams of the endpoints is used to signal which endpoints should be sending video to the multipoint switch/MCU. In this way, only the endpoints which are actively speaking send video to the multipoint switch/MCU, which then transmits the video and audio to the other endpoints.
The Cisco TelePresence suite of virtual meeting solutions utilizes this third method of providing multipoint virtual meetings via the Cisco TelePresence Multipoint Switch (CTMS).
Components of the Cisco TelePresence Multipoint Solution
This section presents the hardware and software components required to deploy multipoint TelePresence within the network infrastructure.
Overview
Figure 10-4 shows the components required for a Cisco multipoint TelePresence virtual meeting.
Figure 10-4 Components of a Cisco TelePresence Multipoint Meeting
Depending upon whether the TelePresence virtual meeting includes only Cisco TelePresence Systems (CTS) endpoints or also includes traditional video conferencing endpoints, the required components differ. The following sections list the components for each type of meeting.
Multipoint Virtual Meetings Which Include Only CTS Endpoints
The right side of Figure 10-4 shows the components required for a TelePresence meeting which consists of CTS endpoints only. The components are:
•
Cisco TelePresence Multipoint Switch
•
•
•
•
Multipoint Virtual Meetings Which Also Include Traditional Video Conferencing Systems
If traditional video conferencing systems (non-Cisco TelePresence endpoints) are required to attend the virtual meeting, the components on the left side of Figure 10-4 may also be required, in addition to the components listed on the right side. They are:
•
•
•
•
This document only discusses multipoint TelePresence meetings which consist of Cisco TelePresence endpoints. Future versions may include interoperability with traditional video conferencing systems.
Cisco TelePresence Multipoint Switch Overview
The Cisco TelePresence Multipoint Switch (CTMS) is a purpose built multipoint appliance developed by Cisco to directly address multipoint requirements for Cisco TelePresence. The patent pending software architecture of the CTMS provides extremely low-latency video and audio switching, adding less than 10ms of delay to any multipoint meeting. In combination with the CTS Manager, CTMS provides a scalable multipoint solution for a Cisco TelePresence network of any size.
CTMS provides a very scalable architecture supporting up to 48 simultaneous table segments—a table segment being defined as a display and camera on any CTS system. CTS-3000 and CTS-3200 systems consist of three table segments, while CTS-1000 and CTS-500 systems consist of a single table segment. Each CTMS provides support for up to 16 CTS-3000s or CTS-3200s, 48 CTS-1000s or CTS-500s, or any combination up to 48 table segments in a single meeting or any number of meetings.1
The high-performance, server-based architecture and Linux-based Cisco Voice Operating system of the CTMS provides a familiar and reliable platform. CTMS provides system management via Secure Shell (SSH), Hyper-Text Transfer Protocol over Secure Sockets Layer (HTTPS) and Cisco Discovery Protocol (CDP). From an administrator's perspective, CTMS is managed using tools and methodologies that are consistent with those used for Cisco Unified Communications Manager, CTS Manager, and CTS rooms.
Figure 10-5 Cisco TelePresence Multipoint Switch
Meeting Types
The CTMS supports multiple meeting types, providing users with a number of scheduled and non-scheduled meetings to choose from based on their meeting requirements. CTMS supports scheduled meetings, non-scheduled (static or ad hoc) meetings, or a combination of both meeting types in a single deployment environment. CTS Manager is required for scheduled meetings. It provides CTMS resource management and integration with Microsoft Exchange or IBM Domino. All supported meeting types are defined below.
Static Meetings
Static meetings are non-scheduled meetings configured on the CTMS through the administration GUI. An example is shown in Figure 10-6.
Figure 10-6 Static Meeting Configuration
A meeting scheduler or administrator, who sets up the static meeting, manually assigns a meeting access number that is used to access the meeting. Meeting access numbers must be chosen from the range of numbers between the Route Pattern Start and Route Pattern End configured on the Access Settings page of the CTMS, as shown in Figure 10-7.
Figure 10-7 Dial Pattern Range Configured on the CTMS
The start and stop of the route pattern should correspond to the range of numbers configured within CUCM for the SIP trunk corresponding to the CTMS. Static meetings are always available to any CTS room. They are accessed by manually dialing the static meeting telephone number or using a speed dial entry on the Cisco 7975G IP Phone associated with the CTS device within the TelePresence room. Static meetings are the equivalent of a meet-me meeting in the voice world.
A meeting scheduler or administrator may add additional CTS rooms to the meeting at any time using the CTMS administrative GUI. The meeting scheduler or administrator also determines the meeting features for the static meeting, each of which is discussed in the following sections.
Static meetings may be hosted or non-hosted. Hosted static meetings require the meeting scheduler or administrator to pre-assign a host room to be present in order to start the meeting. The telephone number of the host room is configured within the static meeting. All meeting rooms which dial-in before the host room are placed on hold until the host room joins the meeting. All rooms are disconnected once the host room leaves the meeting.
Ad Hoc Meetings
Ad hoc meetings are non-scheduled, administrator-initiated, dial-out meetings. A meeting scheduler or administrator initiates the meeting through the CTMS administrative GUI by listing the telephone number of the rooms which will participate in the multipoint meeting, as shown in Figure 10-8.
Figure 10-8 Ad Hoc Meeting Configuration
The CTMS dials out to each of the rooms, thereby requiring no end user interaction. Ad hoc meetings cannot be accessed by dialing in from a CTS system; rooms must be added by the meeting scheduler or administrator using the CTMS administrative GUI.
Scheduled Meetings
Multipoint TelePresence meetings are scheduled by end users using Microsoft Exchange or IBM Domino clients in the same manner that point-to-point meetings are scheduled. Scheduled meetings require no CTMS administrator interaction. CTS Manager is a required component for scheduled meetings. It provides the interface between Microsoft Exchange or Lotus Domino and the CTMS, allowing the appropriate resources on the CTMS to be reserved for the multipoint meeting.
Figure 10-9 shows the interaction between the CTS Manager, Microsoft Exchange, CTMS, and the CTS endpoints when scheduling a multipoint TelePresence meeting.
Figure 10-9 Information Flow When Scheduling a Multipoint Meeting
CTS Manager uses the WebDav protocol to communicate with Exchange in order to update scheduled meetings. CTS Manager also uses AXL/SOAP and JTAPI to discover and monitor the CTS endpoints defined within CUCM. When an end user schedules a meeting within Outlook, CTS Manager reads the meeting events scheduled within the mailboxes defined for each CTS room within Exchange. CTS Manager sends the meeting details to CTMS via XML in order to allocate the necessary resources from the Schedulable Segments resource pool. The primary codec of the CTS endpoint then updates the schedule on the associated IP 7975G phone via XML as well. Finally, the CTS Manager confirms the meeting reservation to the end user, once the CTMS and CTS endpoint resources have been confirmed. It does this via the mailbox configured for the CTS Manager device within Exchange.
Scheduled meetings can be accessed by using the one-button-to-push meeting access feature. Additional rooms can be added to active scheduled meetings at any time during the meeting by the meeting scheduler or administrator, using the CTMS administrative GUI. It should be noted that additional rooms added by a meeting scheduler or administrator count against the Ad hoc Segments resource pool and not the Schedulable Segments resource pool. Multipoint Resources discusses these resource pools.
CTMS Meeting Features
The CTMS supports a number of meeting features that provide flexibility and security for multipoint meetings. Each multipoint meeting is configured with a default meeting policy that may be modified by the system administrator before or during the multipoint meeting. Figure 10-10 shows an example of the default meeting settings for a CTMS.
Figure 10-10 CTMS Default Meeting Settings
When individual meetings are configured, the default features can be overridden. The following sections discuss these features in detail.
Switching Policy
The switching policy has two choices, room switching and speaker switching. Room switching applies to multipoint calls which include CTS endpoints with multiple cameras and displays, such as the CTS-3000 and the CTS-3200. Speaker switching applies to all CTS endpoints.
Room Switching
Room switching switches the video from all table segments of a particular room to all other rooms in a multipoint meeting. For CTS endpoints with multiple screens, if the active speaker (loudest speaker for approximately two seconds) changes, all table segments in the new active speaker's room are displayed in all other rooms at the same time, replacing the previously active speaker's room. The position of each of the screens—left, center, or right—on the active speaker's room is maintained on each of the other rooms. Figure 10-11 shows an example of room switching with CTS-3000s.
Figure 10-11 Room Switching with CTS-3000s
As can be seen, Room 3 has become the active speaker. Video is displayed from the cameras in Room 3 to both of the other rooms. Since Room 2 was the previously active speaker room, video from Room 2 is still displayed on the screens of Room 3.
Room switching can also be applied to multipoint conferences which include both CTS-3000s and CTS-1000s. This is shown in Figure 10-12.
Figure 10-12 Room Switching with CTS-1000s and CTS-3000s
In this case, when a particular table segment at a CTS-3000 room becomes the active speaker, only that table segment is displayed on all CTS-1000 rooms. However, if there were other CTS-3000s in the call, all three table segments from the active speaker's room would be displayed on the other CTS-3000 rooms.
Also notice in Figure 10-12 that as each CTS-1000 enters the multipoint meeting, it is assigned a display position on the CTS-3000s within the meeting. Positions start with the center, followed by the left, and then right. The position of a particular CTS-1000 is maintained until either the room leaves the conference, or a different position on the CTS-3000s is vacant and the system is currently sharing the current CTS-1000 position with another CTS-1000. CTS-1000 rooms which share positions on CTS-3000 rooms are switched by the CTMS based upon voice activity from the particular room.
Speaker Switching
Speaker switching allows each table segment to be switched independently, so that at any given time a room may be viewing three different rooms. The new active speaker's table segment is displayed in all other rooms in its proper position. Figure 10-13 shows an example of speaker switching with CTS-1000s and CTS-3000s.
Figure 10-13 Speaker Switching with CTS-1000s and CTS-3000s
As each CTS-1000 enters the multipoint meeting, it is again assigned a display position on the CTS-3000s within the meeting. The position of a particular CTS-1000 is maintained until the room leaves the conference.
Room Switching versus Speaker switching has implications regarding the bursts generated on the network when a new room or table segment becomes the active speaker. Generally speaker switching is less bursty than room switching. This is discussed in more detail in Estimating Burst Sizes within Multipoint TelePresence Calls.
Maximum Number of Rooms
The Maximum Rooms setting allows the administrator to limit the number of rooms allowed to join the meeting. The maximum number of rooms supported in a single call, and by the CTMS overall, is currently 48 rooms as of CTMS version 1.1. Prior to version 1.1 the maximum number of rooms supported was 36. It should be noted that Maximum Rooms actually refers to the maximum number of segments supported, where a CTS-3200 or CTS-3000 counts as three segments and a CTS-1000 or CTS-500 counts as one segment. The Maximum Rooms setting works hand-in-hand with CTMS resource management as discussed in Multipoint Resources.
Video Announce
The Video Announce feature causes a Cisco TelePresence room which joins the conference to be displayed to all other rooms for approximately two seconds. This prevents a muted room from joining without being noticed.
The Video Announce feature also has implications regarding the bursts generated on the network when a new site joins the conference. This is discussed in more detail in Estimating Burst Sizes within Multipoint TelePresence Calls.
Lock Meeting
Administrators can lock a meeting through the administrative GUI after a meeting is in progress. This prevents any additional rooms from joining the meeting. Additional TelePresence systems can be added to a meeting that is locked, but only by the meeting scheduler or administrator through the administrative GUI.
Quality
The quality setting allows the configuration of 1080p or 720p on a per call basis. It is important that meetings are configured to support the lowest resolution Cisco TelePresence room participating in the multipoint meeting because the CTMS does not perform any transcoding or transrating.
Cisco TelePresence systems have the ability to negotiate down from 1080p to 720p, allowing systems configured for 1080p to join a meeting configured for 720p. However, Cisco TelePresence systems configured for 720p cannot negotiate up to 1080p and therefore will not connect to a meeting configured for 1080p.
VIP Mode
VIP Mode is a switching feature which is useful for meetings in which one site or segment of a site is more important than the rest of the sites. VIP Mode can be configured using either a "hard-lock" or "soft-lock." When using a "hard-lock," the video from the VIP site or segment is always displayed at the other sites, regardless of who is the active speaker. When using a "soft-lock," the video from the VIP site or segment is temporarily switched when a speaker at another site talks, but is automatically switched back after the speaker stops talking, without the VIP site having to talk. This ensures the focus of the meeting is always on the VIP site.
Multipoint Resources
Multipoint resources are configured on the CTMS based on table segments. As mentioned above, each CTMS supports a maximum of 48 segments that can be allocated for scheduled or ad hoc meetings. Resources are defined in the CTMS administrative GUI as maximum segments, ad hoc segments, and schedulable segments. Figure 10-14 shows the multipoint resource configuration options.
Figure 10-14 CTMS Resource Management Configuration
•
•
•
It is possible to define multiple static meetings, the total of which exceeds the Ad hoc Segment resource pool. Static meetings are basically permanent meetings that can be utilized at any time without the administrator being notified. Because ad hoc meetings and static meetings are deducted from the same resource pool, it is possible to have insufficient table segments available for an ad hoc meeting due to ongoing static meetings and vice versa. Further, as mentioned earlier, when a meeting scheduler or administrator adds another TelePresence room to a scheduled meeting, the resources for that room are deducted from the Ad hoc Segments resource pool. It is therefore possible to have insufficient resources to add the room to the scheduled meeting due to ongoing static or ad hoc meetings.
Because of these issues, it is recommended that in distributed CTMS deployments which support combined scheduled and non-scheduled meetings, separate CTMS units be deployed for static meetings. One set of CTMS units should be allocated for scheduled and ad hoc meetings and the second set for static meetings. This is discussed further in Deployment Models.
Geographical Resource Management
When multiple CTMS devices are available in a multipoint deployment, it is important that multipoint meetings are hosted on the appropriate CTMS based on proximity to CTS endpoints. This helps regionalize multipoint meetings, conserve bandwidth between regions, and ensure the lowest latency for each meeting. Managing large, distributed multipoint deployments without geographical resource management is an unmanageable task.
Geographical resource management requires CTS Manager (CTS-MAN) and is only available for scheduled meetings. Currently geographical selection is based on time zones. For each scheduled multipoint meeting, CTS-MAN selects the CTMS whose GMT timezone is closest to the calculated mean GMT, checks for available resources on the selected CTMS, and schedules the meeting. If there are no resources available on the selected CTMS, CTS-MAN works its way down the list of CTMS devices until available resources are found. Figure 10-15 illustrates the CTMS selection process.
Figure 10-15 CTMS Selection Example
The time zone of each CTS endpoint is determined by the Date/Time Group to which it is assigned within the CUCM configuration. However, CUCM devices are not directly assigned to a specific Date/Time Group. Instead, separate Device Pools must be created for each individual time zone. The CTS endpoints are then assigned to the Device Pool which holds the Date/Time Group corresponding to the time zone within which the endpoint is located. For a distributed multipoint design to function correctly, it is therefore necessary to have CTS units assigned to multiple Device Pools which reflect their correct geographic location. Note that this is not necessarily a requirement of a centralized multipoint design, since all CTS endpoints utilize the single CTMS regardless of time zone in such a deployment.
The time zone of the CTMS is configured directly on the CTMS under System Configuration-->CTM Settings, as shown in Figure 10-16. Note that the SIP Trunk configuration for the CTMS within CUCM also has a Device Pool setting. The time zone configured within the CTMS should match the time zone configured within the CUCM Device Pool.
Figure 10-16 CTMS Location Configuration
Note
Quality of Service
The DSCP markings for both the media (audio and video) as well as the signaling from the CTMS are controlled via the QoS Settings screen within the CTMS, shown in Figure 10-17.
Figure 10-17 QoS Settings for the CTMS
Cisco recommends the DSCP marking for audio and video media from the CTMS be CS4, based on RFC 4594. Likewise the recommended DSCP marking for signaling from the CTMS is CS3. This is consistent with recommendations for CTS endpoints defined within CUCM for point-to-point TelePresence meetings.
Meeting Security
Providing secure multipoint meetings is a requirement for any technology—audio, video conferencing, or Cisco TelePresence. Although it is important to provide users with options for multipoint meetings, it is also important that meetings provide the appropriate level of security for participants.
Meeting security can be broken down into three broad categories:
•
•
•
Administrative Access Control
The CTMS provides administrative access control via the Access Management screen as shown in Figure 10-18.
Figure 10-18 Administrative Roles for CTMS Access Control
The CTMS includes three different roles which provide three levels of administrative access control, administrator, meeting scheduler, and diagnostic technician. Multiple instances of each role (i.e., multiple administrators, meeting schedulers, and diagnostic technicians) may be defined within a single CTMS. For each of the three administrative roles, passwords are stored via the local database within the CTMS only. Strong authentication via Radius or TACACS+ to a centralized authentication server is currently not supported.
From a meeting security standpoint, only the administrator and meeting scheduler roles have the ability to schedule meetings. Administrators have full access to the CTMS. Therefore it is recommended to restrict administrator access to a limited set of administrators. Multiple meeting schedulers may be defined within the CTMS. However, it should be noted that resource allocation is not divided among meeting schedulers. In other words, any meeting scheduler has access to all meeting resources within the CTMS. Therefore, meeting security is only as good as the controls which safeguard the access to the CTMS administrator and meeting scheduler roles.
Meeting Access Control
The CTMS provides three types of meetings, as described above, each providing different levels of access control to join the meeting. Scheduled and ad hoc meetings are inherently secure, not allowing uninvited Cisco TelePresence rooms to randomly dial into a meeting. Cisco TelePresence rooms may be added to these meetings once the call is in progress, but only by a meeting scheduler or administrator through the CTMS administrative GUI.
Static meetings are always available, non-scheduled dial-in meetings that are less secure than scheduled and ad hoc meetings, since any room can dial into them at any time. Configuring a hosted static meeting adds a measure of security, in that the host room must at least attend in order for the conference to begin.
The following additional features can be added to multipoint meetings in order to provide an additional level of meeting access control. The Video Announce feature forces each new site entering the conference to be visible to the other sites for approximately two seconds. This minimizes the chance of an unauthorized site "lurking" on the multipoint meeting. Selecting a static meeting in which the number of rooms defined for the static meeting, via the Maximum Rooms parameter, matches the number of rooms for the conference, minimizes the chance of an unauthorized site being able to access the call. Finally having a meeting scheduler or administrator implement the Lock Meeting feature guarantees that no unauthorized sites can join a meeting once it is ongoing. Note that all meeting features listed above (except Maximum Rooms, which is only available for static and hosted static meetings) may be applied to static, scheduled, or ad hoc meetings.
Meeting Confidentiality
Encryption of the media between CTS endpoints in a point-to-point call has been supported as of CTS version 1.2. Therefore, the recommended method of providing meeting confidentiality for point-to-point TelePresence meetings is to enable meeting encryption via the CTS endpoints themselves. However, as of software version 1.1, the CTMS does not support encryption. Therefore, the only method of providing meeting confidentiality for multipoint TelePresence meetings is to provide encryption between sites via network components (IPsec encryption). Future versions of CTMS software will include the ability of the CTMS to support encryption.
Meeting Management
Multipoint meeting management is available through the CTMS Web interface, allowing administrators to monitor and or modify active multipoint meetings. The active meetings page allows the administrator to view active meeting details and participants. Administrators can also make the following changes to any active multipoint meeting from the active meeting page:
•
•
•
•
•
Figure 10-19 shows the meetings management page of the CTMS.
Figure 10-19 Meeting Management
For centralized multipoint deployments with one CTMS, locating an active multipoint meeting is not an issue. However, for large deployments with multiple CTMS devices, locating a specific multipoint meeting can be a challenge. In any scheduled meeting environment it is recommended that CTS Manager be used to view and manage all meetings. CTS Manager provides a central location to view all past, active, and pending meetings. Figure 10-20 shows the meetings page in CTS Manager.
Figure 10-20 Meetings Page in CTS Manager
Using the meetings page, you can locate the CTMS a specific multipoint meeting is hosted on by selecting the meeting and clicking Details. In the meeting details you see the CTMS hosting the meeting at the bottom of the page. Proceed to the MCU devices page on CTS Manager, click on the appropriate CTMS, and you are linked directly to the CTMS Web interface. From the active meetings page you can monitor or modify an active meeting.
From the MCU devices page you can also view all past, active, or pending meetings for any CTMS device by selecting the device and clicking View Meetings. From this page you can also export CDR information for all meetings hosted on each CTMS by using the Export Data function.
1 CTMS version 1.0 supports a maximum of 36 table segments. CTMS version 1.1 extends this to a maximum of 48 table segments.
