Collaborative Conferencing
Revised: March 30, 2012, OL-27011-01
When there are three or more participants involved in a call, the call becomes a conference. In collaborative conferencing, the audio, video and content from some or all of the attendees in a meeting is mixed into a single stream and the stream is sent back to the attendees. The processing of audio and video is performed by a Multipoint Control Unit (MCU) or some multipoint devices. Figure 8-1 illustrates a conference involving both internal and external participants, mobile and remote workers, or even attendees from different organizations.
Figure 8-1 Conceptual View of Collaborative Conferencing
Conference Type
Most conferencing products support two types of conference, ad-hoc and scheduled. Scheduled conferences require a special tool such as Cisco TelePresence Management Suite (TMS), for example, that integrate with the calendar applications such as Microsoft Exchange or IBM Domino to provide the scheduling functionality.
Ad-hoc Conference
In ad-hoc conferences, the conference initiator creates the conference and invites participants to join without sending any prior notification about the conference information. Typically, the conference initiator creates the conference by pressing the Conference key on the endpoint and calls the participants to add them to the conference. Endpoints that do not have the Conference key cannot initiate the conference but can be invited to join the conference. Resources for an ad-hoc conference cannot be reserved. The conference can be created only if enough resources are available at the conference creation time. In this case, the call processing agent (Cisco Unified Communications Manager, for example) controls the conference.
Scheduled Conference
In this type of conference, the conference organizer schedules the conference using the product scheduling tool or calendar application that integrated with the conference product scheduling function. The conference resources are reserved at the time the conference is scheduled. The conference cannot be scheduled if there are insufficient resources. To join the conference, attendees can dial into the conference directly or click on the conference link inside the meeting invitation and have the system call the attendees. In this case, the multipoint device controls the conference and the call processing agent routes the dialed call to the correct multipoint device.
Conferencing Infrastructure
As shown in Figure 8-2, the call processing agent and multipoint device are the main components in the conferencing infrastructure. The call processing agent handles the signal and controls the call on the endpoints. In the case of a scheduled conference, the call processing agent routes the call to the multipoint device. Cisco Unified Communications Manager (Unified CM) and the Cisco TelePresence Video Communication Server (VCS) are the most common call processing agents used in the Cisco video conference products. Unified CM can interconnect with VCS through a SIP trunk so that endpoints registered to one agent can call or conference in endpoints registered to the other agent.
Figure 8-2 Conferencing Components
The main function of the multipoint device is to handle the media (audio and video) from the endpoints during the conference. Typically, the connection between the call processing agent and the multipoint device is SIP or H.323.
Conference Multipoint Device
The multipoint device is the central component in the conferencing infrastructure and it can be hardware or software based. The multipoint device processes video streams from all participating endpoints and transmits a composite image of all participants back to the originating endpoint devices. This composite view enables all participants to see each other simultaneously. The continuous presence view can display multiple windows (participants) in a variety of layouts. Each layout offers the ability to make one of the windows voice-activated, which is useful if there are more participants in the conference than there are windows to display them all in the composite view.
Transcoding and Switching
The multipoint platform can be based upon either a transcoding or switching architecture. Both architectures provide advantages that need to be considered when selecting a multipoint platform for deployment.
•Transcoding involves specialized video hardware that decodes the incoming video stream and then re-encodes it before sending it on. For example, the Cisco TelePresence Server, Cisco Media Experience Engine (MXE), and Cisco Multipoint Control Unit (MCU) all use the transcoding architecture.
•Switching does not require specialized video hardware but uses software instead. The incoming video and audio streams are copied and redirected to the correct endpoints in the conference, with no manipulation of the video stream. For example, the Cisco TelePresence Multipoint Switch uses the switching architecture.
Table 1 describes the advantages and disadvantages of the transcoding and switching architectures of the multipoint platform.
Table 8-1 Comparison of Transcoding and Switching
|
|
|
Transcoding |
•Active presence support1 •Ability for endpoints to connect at different bandwidth speeds and resolutions •Often endpoints with Far End Camera Control (FECC) can customize layouts •Ability to scale video (translate) between endpoints •Supports Telepresence Interoperability Protocol (TIP) and standards-based endpoints |
•Latency is introduced due to decoding and re-encoding video •Higher cost per port •Typically harder to scale |
Switching |
•Latency is low (less than 10 ms) •Lower cost per port |
•Limited to basic full-screen video switching (No active presence; only one site is visible on each screen) •Endpoints must support and agree on a single resolution and frame rate2 |
Multipoint Deployment Guidelines
There are two options for deploying any multipoint technology, namely centralized and distributed. It is important to think through the deployment strategy to optimize the user experience, localize resources, and ensure reliable multipoint calls. Consider the followings when designing your multipoint solution deployment:
•The number of endpoints, which in turn determines the number of multipoint devices required
•The geographic location of the endpoints
Together these factors determine the multipoint deployment option (centralized or distributed), the number of multipoint devices, and the physical location of the multipoint devices.
Centralized Deployment
Centralized designs are recommended for multipoint device deployments with a small number of endpoints, or for larger deployments that cover a limited geographic area.
In centralized deployments, the multipoint device can be located in a regional or headquarters campus site with the necessary WAN bandwidth available to each of the remote sites (as well as the necessary LAN bandwidth within the campus). Cisco recommends that you locate the multipoint device centrally based on the geographic location of the endpoints. (However, this might not be possible in all network layouts.) Centrally locating the multipoint device prevents unnecessary latency caused by backhauling calls to a site at the far edge of the network.
Figure 8-3 illustrates a deployment with a small number of endpoints that uses the multipoint device placed centrally in the headquarters to minimize latency for multipoint meetings.
Figure 8-3 Centralized Multipoint Deployment
The multipoint device should be located at a site that provides network latency that adheres to the solution requirements. Also, the site should be provisioned with adequate bandwidth for the number of endpoints deployed on the network. Bandwidth requirements vary depending on the desired maximum call rate of endpoints and the number of endpoints connecting to the multipoint device. Provision based on the maximum bandwidth that a particular endpoint requires for the desired rate and resolution. For details on network latency and bandwidth requirements, refer to the respective solution deployment or design guide available at http://www.cisco.com.
Distributed Deployment
Cisco recommends the distributed configuration for large deployments or deployments with a small number of endpoints in separate geographical regions. As the network grows, it is very advantageous to localize multipoint devices to minimize latency and save bandwidth.
Figure 8-4 illustrates the deployment where the multipoint devices are placed centrally in each region (NA and EMEA) but are distributed globally.
Figure 8-4 Distributed Multipoint Deployment
In the distributed environment, multipoint devices should be located at sites that provide network latency adhering to solution requirements and adequate bandwidth for the number of endpoints supported by each site.
The following additional guidelines should be observed when deploying multipoint devices:
•Build a resilient multipoint solution architecture using multiple multipoint devices. In case one of the multipoint devices fails, conferences can still be started from the operational device.
•Cascade multipoint devices to support a larger conference deployment and to minimize bandwidth consumption. Cisco TelePresence Conductor can be used to cascade multipoint devices.
•Use Cisco TelePresence Conductor to preferentially select a multipoint device for conferences based on their properties (for example, geographic location or video quality).
•Choose a deployment that allows you to build a scalable multipoint solution. For example, if you have endpoints deployed in multiple geographical regions and expect the number of endpoints to grow in each regions, use the distributed multipoint deployment
•Configure a solution so that traffic is load-balanced to the multipoint devices in order to achieve maximum resource utilization.
•Cisco recommends using the scheduling option for larger deployments. This would simplify the conference creation.
•Wherever possible, Cisco recommends dual-registering (SIP and H.323) the MCU in mixed environments so that endpoints can connect in their native protocol without interworking.
Multipoint Solution Selection
When deciding on the multipoint solution suitable for your deployment, you need to consider several factors (such as your organization's current deployment and the intended endpoint combinations) and to decide which multipoint features have priority. Some common factors to consider when designing the multipoint solution architecture include:
•Active presence
•Scalability
•Network latency
•Endpoints support
•Multi-screen compatibility
•Collaboration (content sharing)
•Scheduling
Multipoint Selection Based on Endpoints
When deciding on a multipoint device, start with your endpoints. In some cases, a combination of endpoints could help eliminate or determine the multipoint device option for the deployment, as in the following scenarios:
•In a deployment with heterogeneous endpoints that support different video formats, video codecs, resolutions, or frame rates, the best option would be multipoint devices that can do both transcoding and transrating. In this case, the Cisco TelePresence Multipoint Switch would not be a good choice because it is based on a switching architecture.
•A deployment that contains both Telepresence Interoperability Protocol (TIP) and standards-based endpoints would require a video gateway to inter-operate between the protocols. For example, if the conference environment has a Cisco TelePresence Multipoint Switch and a mix of Cisco TelePresence System 3200 Series, Cisco IP Video Phone E20, and Cisco TelePresence System EX90 endpoints registered to Cisco Unified CM, the Cisco Media Experience Engine (MXE) might be the obvious option to add (from a budget perspective) because it allows interoperability between endpoints.
However, in most cases there can be more than one option, so you should also consider the features that you require.
Multipoint Selection Based on Features
The multipoint solution options can be further narrowed down by focusing on which features have the highest priority for your conferencing deployment. The following partial list represents features that affect the decision of which multipoint solution to choose:
•Support for Telepresence Interoperability Protocol (TIP), standards-based, or third-party endpoints
•Multi-screen or single-screen support
•Support for One Button To Push (OBTP)
•Active presence or continuous presence
•Content sharing
•H.239, Binary Floor Control Protocol (BFCP), or Auto Collaborate content sharing translation
•WebEx OneTouch integration
•Layout changes possible from endpoints
•Switching policy support (room versus speaker switching)
•SIP and H.323 support
For a complete list of features supported in each multipoint product, refer to the respective product data sheet available at http://www.cisco.com.
Conference Resource Capacity Planning
There are several factors involved in determining the types and number of video conferences that the multipoint device can support. These sizing factors are different for different multipoint products. Multipoint devices can also support higher capacity when using standard definition (SD) as compared to high definition (HD) for video conference.
Conference capacity depends on the following factors:
•Type of resolution or video format required for the video conference
•Total number of ports that the multipoint device can support
•Number of ports that the multipoint device can dedicate to each protocol
•Whether the multipoint devices are cascaded
If the video conference utilizes a Cisco High-Density Packet Voice Video Digital Signal Processor Module (PVDM3) or later model of digital signal processor (DSP) on a Cisco Integrated Services Router (ISR) as the bridge, use the DSP calculator in the Cisco Unified Communications Sizing Tool to determine the conference capacity. The Cisco Unified Communications Sizing Tool (Unified CST) is available to Cisco employees and partners with proper login authentication at http://tools.cisco.com/cucst.